SRv6 to SR-MPLS Interworking via Binding SID Translation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current technologies face challenges in seamlessly interworking between Segment Routing (SR) over IPv6 (SRv6) and Multi-Protocol Label Switching (MPLS) networks, requiring cross-domain state management which is inefficient and resource-intensive.
Innovation Solution
The implementation of a software-defined networking process that enables SRv6 and SR-MPLS interworking without the need for cross-domain state, achieved through translation of SRv6 segments to SR-MPLS segments and vice versa using cross-data plane binding Service Identifiers, with a Path Computation Engine providing SID lists for routing packets between nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If cross-domain state management is used for SRv6 and MPLS interworking, then network interworking capability is improved, but system complexity and resource consumption increase
Solution Approach 1:
The patent extracts and removes the cross-domain state management requirement from the SRv6-MPLS interworking system. By using binding SIDs that embed destination domain information directly in the packet header, the system eliminates the need for separate cross-domain state tables in intermediate nodes, thereby reducing complexity while maintaining interworking capability
Solution Approach 2:
The patent uses binding SIDs that copy essential routing information (destination domain identifier) directly into the packet header. This allows intermediate nodes to forward packets based on the embedded SID information without maintaining separate state, effectively copying the necessary routing state into the packet itself to avoid external state management
2Measurement precision
If cross-domain state is maintained for packet routing, then routing accuracy is improved, but memory resources and processing overhead increase
Solution Approach 1:
The binding SID copies the destination domain identifier directly into the packet header, allowing intermediate nodes to perform accurate routing decisions using only the information embedded in the packet itself, without needing to store or access external cross-domain state tables
Solution Approach 2:
The packet carries its own routing information (destination domain identifier) within the binding SID in the header. Intermediate nodes can perform routing decisions using only the packet's own information, making the packet self-sufficient for routing purposes and eliminating the need for nodes to maintain external state
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Network interworking with no cross-domain state may be provided. First, an edge node may receive a packet from an intermediate node in a first domain. The edge node may be between the first domain and a second domain. Next, the edge node may pop, in response to a first Service Identifier (SID) in the packet, headers corresponding to the first domain from the packet. The edge node may then push, in response to the first SID, a label stack corresponding to the second domain onto the packet. The first SID may include data corresponding to the label stack. Then the edge node may route the packet to the second domain destine to an end node in the second domain.