Co-Routed Bidirectional MPLS TE Tunnels for Path Consistency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In IP RAN networks, bidirectional MPLS TE tunnels are not co-routed, leading to issues in ensuring high reliability of services due to unidirectional MPLS TE LSPs, where forward detection messages are sent through MPLS TE LSPs but reverse detection messages are sent through alternative paths, resulting in incorrect path status settings.
Innovation Solution
A method and device for establishing Multiprotocol Label Switching (MPLS) traffic engineering tunnels by reversing path information to create co-routed forward and reverse tunnels, using BGP update messages to identify VPN instances and establish MPLS TE tunnels between them, ensuring that both directions of the tunnel are established and coordinated.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If unidirectional MPLS TE LSPs are used for service transmission, then service bandwidth and flexibility are improved, but path detection reliability deteriorates because forward and reverse detection messages traverse different paths
Solution Approach 1:
The patent applies inversion by establishing the reverse MPLS TE LSP first, then using its path information to guide the establishment of the forward MPLS TE LSP. This ensures that both forward and reverse tunnels traverse identical network paths, resolving the reliability issue where detection messages previously took different routes. The reverse tunnel's path becomes the template for the forward tunnel, inverting the traditional unidirectional establishment approach.
Solution Approach 2:
The patent implements preliminary action by pre-establishing the reverse MPLS TE LSP and obtaining its path information before establishing the forward tunnel. This preliminary establishment of the reverse tunnel allows the system to determine the optimal path in advance, which is then used to configure the forward tunnel to match, ensuring path consistency from the outset rather than attempting to synchronize paths after both tunnels are created.
2Adaptability or versatility
If bidirectional MPLS TE tunnels are established independently without path coordination, then tunnel establishment flexibility is improved, but path consistency deteriorates causing incorrect BFD status settings
Solution Approach 1:
The patent implements feedback by using the path information obtained from the reverse MPLS TE LSP as input for establishing the forward tunnel. The reverse tunnel's established path serves as feedback that guides the configuration of the forward tunnel, ensuring both tunnels maintain path consistency. This feedback mechanism prevents the BFD status inconsistency problem where independent tunnel establishment would cause detection messages to traverse different routes.
Solution Approach 2:
The patent applies asymmetry in the establishment sequence and methodology of forward and reverse tunnels, while achieving symmetric path traversal. The reverse tunnel is established first with specific path constraints, then the forward tunnel is established using the reverse tunnel's path information. This asymmetric process creates symmetric path consistency, allowing both tunnels to traverse identical network routes despite being established in different sequences.
Data Source
AI summary
Embodiments of the present invention provide a Multiprotocol Label Switching traffic engineering tunnel establishing method and device. A tunnel establishing method includes: receiving, by a second routing device, an identifier, which is sent by a first routing device, of an MPLS TE tunnel from a first VPN instance to a second VPN instance; acquiring, by the second routing device according to the identifier, path information of the MPLS TE tunnel from the first VPN instance to the second VPN instance; and establishing an MPLS TE tunnel from the second VPN instance to the first VPN instance according to the acquired path information. Therefore, forward and reverse bidirectional tunnels are co-routed or partially co-routed, thereby solving a problem caused by non-co-routing during BFD.