SD-WAN Service Chaining for Bidirectional VPN Segment Routing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current SD-WAN technologies fail to efficiently manage bidirectional traffic and maintain VPN segment preservation while allowing scalability for service chain elements, leading to issues such as data packet dropping and violation of security constraints.

Innovation Solution

A hub node in the SD-WAN network extracts and removes source VPN segment information from data packets before diverting them to service chain elements, and upon return, retrieves this information using packet tuple data to route packets back to the original destination VPN segment, ensuring scalable and secure service chaining.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If service chain elements use their own service chain VPN segments, then network security is improved, but bidirectional traffic management becomes complex and packets may be dropped

Engineering Contradiction:

Improvenetwork securityVSAvoidbidirectional traffic management

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The hub node acts as an intermediary that receives packets from the service chain element on the service chain VPN segment, extracts the original source VPN segment information from stored flow information, and forwards packets to the correct source VPN segment. This mediator resolves the complexity of bidirectional traffic by centralizing the VPN segment mapping function at the hub node.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs preliminary action by storing flow information including source VPN segment data before packets need to be routed in reverse direction. When a packet arrives from a service chain element, the hub node already has the pre-stored flow information to quickly determine the correct source VPN segment without complex real-time analysis.

Inventive Principle:

Principle #10Preliminary action

2Device complexity

If service chain elements do not communicate source VPN segment information, then service chain element simplicity is improved, but packet routing in reverse direction fails causing packet loss

Engineering Contradiction:

Improveservice chain element structureVSAvoidpacket delivery

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The hub node serves as an intermediary that maintains the mapping between service chain VPN segments and source VPN segments. Instead of requiring service chain elements to communicate source VPN information, the hub node uses stored flow information to translate destination VPN segments back to source VPN segments, ensuring reliable packet routing without increasing service chain element complexity.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system implements feedback by storing flow information that includes source VPN segment data when packets are initially routed through service chain elements. This stored information is then used to feedback the correct routing decision when reverse direction packets arrive, ensuring packets are delivered to the correct source VPN segment without requiring the service chain element to remember or communicate source information.

Inventive Principle:

Principle #23Feedback

3Reliability

If current solutions are used for service chaining, then some security requirements are met, but scalability is limited and SD-WAN segmentation purpose is defeated

Engineering Contradiction:

Improvesecurity requirementsVSAvoidscalability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The hub node implements a universal solution by maintaining flow information that works for all service chain elements and all VPN segments. Instead of requiring separate routing logic for each service chain element or VPN segment combination, the hub node uses a single flow information storage mechanism that universally handles bidirectional routing across the entire SD-WAN fabric, enabling scalability.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system preserves SD-WAN segmentation by maintaining distinct VPN segments while enabling service chaining. The hub node stores flow information that maps between different VPN segments, allowing packets to be routed through service chain elements on service chain VPN segments while still being delivered to the correct source VPN segments, thus maintaining segmentation integrity while enabling scalable service chaining.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS12556476B2Automatic service chaining of bi-directional transit traffic

Publication Date: 2026.02.17 CISCO TECHNOLOGY INC

AI summary

A system facilitates communication between branches of an SD-WAN and a service chain element. A hub node receives a data packet of a flow from a source branch over a VPN segment to be transmitted to a destination branch, extracts flow information from the data packet including VPN segment information to be stored in a flow table before transmitting the data packet to the service chain element over a service chain VPN. Upon return of the data packet from the service chain element, the hub node uses packet tuple information to retrieve the flow information with VPN segment information from the flow table. The hub node can then forward the data packet to the destination branch over the VPN segment. The hub node can generate and store an Auto Service Chaining Key that connects bidirectional flows so that the hub node can apply service-chaining to bidirectional traffic.