Label Switched Path Node Protection via Shared Label Context
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In MPLS networks, LSPs that share labels face challenges in providing node protection due to the inability to determine the correct backup path when a node fails, as traditional methods rely on distinct labels for each path.
Innovation Solution
Implementing pop-and-forward labels and context tables within RSVP-TE LSPs to create separate backup paths and resolve the correct backup path in case of failures, using Point of Local Repair (PLR) nodes to manage label stacks and identify backup paths based on Record Route Object (RRO) information.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If LSPs share labels to reduce the number of labels maintained in the data plane, then resource consumption and processing demands are reduced, but the ability to provide node protection is lost because the network node cannot determine which backup path to use when a failure occurs
Solution Approach 1:
The patent segments the single shared label into multiple distinct labels, each associated with a specific next-hop node. This allows the network to maintain separate label bindings for different potential backup paths, enabling the network to select the appropriate backup path when a failure occurs, thus restoring node protection capability while still reducing the overall number of labels compared to maintaining separate labels for every LSP.
Solution Approach 2:
The patent introduces a new dimension of label organization by associating labels not just with LSPs but with specific next-hop nodes. This dimensional change allows the same label to be shared across multiple LSPs that have the same next-hop, while still maintaining the ability to identify and switch to alternative next-hops for backup paths when needed.
2Reliability
If traditional MPLS methods are used with distinct labels for each LSP, then node protection can be provided through backup paths, but the number of labels that must be maintained and updated in the data plane becomes very large
Solution Approach 1:
The patent merges the label maintenance functions by allowing multiple LSPs to share the same label binding to a next-hop node. Instead of maintaining separate labels for each LSP, the system combines them into shared label bindings, significantly reducing the number of labels that need to be maintained in the data plane while preserving node protection through alternative shared labels for backup paths.
Solution Approach 2:
The patent makes labels universal by allowing a single label to serve multiple LSPs that share the same next-hop node. This multi-functionality reduces label proliferation while the existence of alternative universal labels provides backup capability, solving both the label quantity and reliability concerns.
3Stability of the object's composition
If labels are frequently added and deleted in traditional configurations to reflect LSP changes, then the data plane state remains synchronized with control plane state, but processing demands and update frequency increase significantly
Solution Approach 1:
The patent merges multiple LSP label requirements into shared label bindings at the data plane. When LSPs are added or removed, if they share the same next-hop node, the label binding remains valid and does not require updates. This significantly reduces the frequency of label updates while maintaining synchronization between control and data planes, as updates only occur when the actual next-hop associations change.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The disclosed computer-implemented method may include (1) receiving, at a network node within a network, a packet from another network node within the network, (2) identifying, within the packet, a label stack that includes a plurality of labels that collectively represent at least a portion of a label-switched path within the network, (3) popping, from the label stack, a label that corresponds to a next hop of the network node, (4) determining, based at least in part on the label, that the next hop has experienced a failure that prevents the packet from reaching a destination via the next hop, (5) identifying a backup path that merges with the label-switched path at a next-to-next hop included in the label-switched path, and then (6) forwarding the packet to the next-to-next hop via the backup path. Various other methods, systems, and apparatuses are also disclosed.