MPLS Egress Protection Framework
Extracted elements (28)
For scalability and performance, a PLR is intentionally agnostic to services and service labels, maintaining bypass forwarding state per transport tunnel rather than per service destination or service label. This allows bypass tunnel sharing among multiple egress-protected tunnels and avoids state explosion at the PLR.
The framework defines two protector modes: co-located (protector and backup egress router are the same router, forwarding directly to service destinations) and centralized (protector is a dedicated router that tunnels traffic to separate backup egress routers). Centralized mode reduces the number of routers requiring full protection service instances at the cost of an extra tunnel hop.
The framework does not require extensions to existing signaling and label distribution protocols (RSVP, LDP, BGP) for transport and bypass tunnel establishment, relying on generic protocol procedures. Extensions to IGPs and service label distribution protocols are needed only for specific procedures such as context ID advertisement and context label switching setup.
Three approaches are defined for advertising the context ID — proxy mode (virtual proxy node with asymmetric IGP/TE metrics), alias mode (context ID label binding advertisement via IGP, e.g., IS-IS Mirroring Context segment per RFC 8667), and stub link mode (anycast address, no schema knowledge required on PLR/E) — to accommodate different network topologies and protocol capabilities without mandating a single approach.
Broadcast, multicast, and unknown unicast traffic in VPLS and EVPN are out of scope because either the protector cannot pre-establish the forwarding state for egress protection, or the PLR must not reroute traffic to other routers to avoid duplication; these cases are left for future study.
Services using upstream-assigned service labels are explicitly out of scope and left for future study, as the framework assumes downstream-assigned service labels that can be distributed from the egress router to the protector.
An egress-protected service MUST be mapped to an egress-protected tunnel by its ingress router based on the common protected egress {E, P}, and a service associated with a protected egress {E, Pi} MUST be carried by a tunnel associated with the same protected egress.
An egress-protection bypass tunnel MUST be established with protector P as the physical tail end and egress router E as the node to avoid, and MUST NOT be affected by the topology change caused by an egress node failure.
Failure detection mechanisms used by the PLR MUST be reasonably fast — faster than control-plane failure detection and remote failure detection — otherwise local repair provides no benefit over control-plane convergence.
If PLR, protector, and backup egress router are not in the same administrative domain, a certain level of trust MUST be established between them for protocols to run securely across the domain boundary.
If the PLR has a mechanism to detect and differentiate a link failure from an egress node failure, it SHOULD set up both link protection and egress node protection and trigger only the appropriate one per failure type.
In a scenario where an egress-protected tunnel is inter-area or inter-AS, the associated context ID MUST be propagated by IGP or BGP from the original area or AS to the area or AS of the ingress router, following the same propagation process as for a regular IP address.
In centralized protector mode, a protector MUST send service packets via a transport tunnel to the corresponding backup service instance on a backup egress router, rather than forwarding directly to the service destination. For MPLS services, the protector MUST swap the service label to the backup egress router's label before pushing the tunnel label.
In centralized protector mode, there MUST be a service label distribution protocol session between the backup egress router and the protector. The backup egress router MUST advertise a unique service label for egress protection (not its regular label) if the regular label's forwarding state would route packets toward the protected egress router, to avoid a loop.
It is RECOMMENDED that the framework be used in conjunction with control-plane convergence or global repair, so that egress protection provides fast temporary repair while convergence or global repair provides ultimate permanent repair.
The context ID MUST be advertised such that all egress-protected tunnels have E as tail end and all egress-protection bypass tunnels have P as tail end while avoiding E. For all relevant routers (primary PE, protector, PLR), they MUST support and agree on the chosen advertisement approach.
The destination (a CE or site) of a service MUST be dual-homed or have dual paths to an MPLS network via two MPLS edge routers — one the egress router, the other a backup egress router — for egress protection to be applicable.
The protector MUST have its own connectivity with each service destination via a direct link or multi-hop path that MUST NOT traverse the protected egress router or be affected by the egress node failure. Each service destination MUST therefore be dual-homed or have dual paths.
The protector MUST maintain the labels of egress-protected services in dedicated label spaces on a per-protected-egress {E, P} basis — one label space per egress router it protects — to support context label switching.
There MUST be a service label distribution protocol session between each egress router and its protector so the protector learns the label bindings of egress-protected services and can install them in the appropriate per-egress label space.
To defeat CE-based attacks that simulate link failures and trigger cascading egress link protection, a damping mechanism SHOULD be used by the egress router to suppress the services associated with the offending link or CE, effectively detaching them from the network.
A 'context ID' is a globally unique IPv4 or IPv6 address assigned to a protected egress {E, P}. It is logically owned by both E and P: for the egress router it indicates the protector; for the protector it indicates the egress router's forwarding context; for other routers it is reachable via both, similar to an anycast address.
A 'context label' is a non-reserved MPLS label assigned by a protector P to a context ID. In the data plane it represents the context ID and indicates E's dedicated label space and IP address space on P; the bypass tunnel is always a UHP tunnel whose incoming label on P is the context label.
A 'protected egress' {E, P} is a virtual node consisting of an ordered pair of egress router E and protector P. It serves as the virtual destination of an egress-protected tunnel and the virtual location of service instances; one egress router may form multiple protected egresses with different protectors.
An egress-protection bypass tunnel runs from a PLR to protector P and logically targets protected egress {E, P}. It may be established via RSVP (with context ID as destination), LDP (context label advertised as IP prefix FEC), hierarchical tunneling (context label as one-hop LSP over a regular bypass tunnel), or Segment Routing (SID stack with context label as innermost SID).
'Context IP forwarding' is IP forwarding performed by a protector in the IP address space of the failed egress router as indicated by the context label, enabling correct forwarding of rerouted IP service packets using routes from the protected egress router's address space.
'Context label switching' is label switching performed by a protector in the label space of the failed egress router as indicated by the popped context label, enabling correct forwarding of rerouted MPLS service packets using labels originally assigned by the protected egress router.
The framework requires a service label distribution protocol session between each egress router and its protector over a secure session. No new security requirements or guarantees are introduced; the security properties depend entirely on the underlying protocol chosen, and its associated security considerations apply.