5.1. Reference Topology

This document refers to the following topology when describing the procedures of egress node protection.¶

               services 1, ..., N
     =====================================> tunnel
                                                 
   I ------ R1 ------- PLR --------------- E ----
ingress          penultimate hop        egress    \
                        |  .           (primary    \    
                        |  .            service     \
                        |  .            instances )  \
                        |  .                          \
                        |  .                           \   service
                        |  .                             destinations
                        |  .                           / (CEs, sites)
                        |  .                          /
                        |  . bypass                  /
                        |  . tunnel                 /
                        |  .                       /
                        |  ...............        /
                        R2 --------------- P ----
                                       protector
                                      (protection
                                       service
                                       instances) 

5.2. Egress Node Failure and Detection

An egress node failure refers to the failure of an MPLS tunnel's egress router. At the service level, it is also a service instance failure for each IP/MPLS service carried by the tunnel.¶

An egress node failure can be detected by an adjacent router (i.e., PLR in this framework) through a node liveness detection mechanism or a mechanism based on a collective failure of all the links to that node. The mechanisms MUST be reasonably fast, i.e., faster than control-plane failure detection and remote failure detection. Otherwise, local repair will not be able to provide much benefit compared to control-plane convergence or global repair. In general, the speed, accuracy, and reliability of a failure detection mechanism are the key factors to decide its applicability in egress node protection. This document provides the following guidelines for network operators to choose a proper type of protection on a PLR.¶

• If the PLR has a mechanism to detect and differentiate a link failure (of the link between the PLR and the egress node) and an egress node failure, it SHOULD set up both link protection and egress node protection and trigger one and only one protection upon a corresponding failure.¶

• If the PLR has a fast mechanism to detect a link failure and an egress node failure, but it cannot distinguish them, or if the PLR has a fast mechanism to detect a link failure only, but not an egress node failure, the PLR has two options:¶

  1. It MAY set up link protection only and leave the egress node failure to be handled by global repair and control-plane convergence.¶
  2. It MAY set up egress node protection only and treat a link failure as a trigger for the egress node protection. The assumption is that treating a link failure as an egress node failure MUST NOT have a negative impact on services. Otherwise, it SHOULD adopt the previous option.¶

5.3. Protector and PLR

A router is assigned to the "protector" role to protect a tunnel and the services carried by the tunnel against an egress node failure. The protector is responsible for hosting a protection service instance for each protected service, serving as the tail end of a bypass tunnel, and performing context label switching and/or context IP forwarding for rerouted service packets.¶

A tunnel is protected by only one protector. Multiple tunnels to a given egress router may be protected by a common protector or different protectors. A protector may protect multiple tunnels with a common egress router or different egress routers.¶

For each tunnel, its penultimate hop router acts as a PLR. The PLR pre-establishes a bypass tunnel to the protector and pre-installs bypass forwarding state in the data plane. Upon detection of an egress node failure, the PLR reroutes all the service packets received on the tunnel through the bypass tunnel to the protector. For MPLS service packets, the PLR keeps service labels intact in the packets. In turn, the protector forwards the service packets towards the ultimate service destinations. Specifically, it performs context label switching for MPLS service packets, based on the service labels assigned by the protected egress router; it performs context IP forwarding for IP service packets, based on their destination addresses.¶

The protector MUST have its own connectivity with each service destination, via a direct link or a multi-hop path, which MUST NOT traverse the protected egress router or be affected by the egress node failure. This also means that each service destination MUST be dual-homed or have dual paths to the egress router and a backup egress router that may serve as the protector. Each protection service instance on the protector relies on such connectivity to set up forwarding state for context label switching and context IP forwarding.¶

5.4. Protected Egress

This document introduces the notion of "protected egress" as a virtual node consisting of the egress router E of a tunnel and a protector P. It is denoted by an ordered pair of {E, P}, indicating the primary-and-protector relationship between the two routers. It serves as the virtual destination of the tunnel and the virtual location of service instances for the services carried by the tunnel. The tunnel and services are considered as being "associated" with the protected egress {E, P}.¶

A given egress router E may be the tail end of multiple tunnels. In general, the tunnels may be protected by multiple protectors, e.g., P1, P2, and so on, with each Pi protecting a subset of the tunnels. Thus, these routers form multiple protected egresses, i.e., {E, P1}, {E, P2}, and so on. Each tunnel is associated with one and only one protected egress {E, Pi}. All the services carried by the tunnel are then automatically associated with the protected egress {E, Pi}. Conversely, a service associated with a protected egress {E, Pi} MUST be carried by a tunnel associated with the protected egress {E, Pi}. This mapping MUST be ensured by the ingress router of the tunnel and the service (Section 5.5).¶

The two routers X and Y may be protectors for each other. In this case, they form two distinct protected egresses: {X, Y} and {Y, X}.¶

5.5. Egress-Protected Tunnel and Service

A tunnel, which is associated with a protected egress {E, P}, is called an egress-protected tunnel. It is associated with one and only one protected egress {E, P}. Multiple egress-protected tunnels may be associated with a given protected egress {E, P}. In this case, they share the common egress router and protector, but they may or may not share a common ingress router or a common PLR (i.e., penultimate hop router).¶

An egress-protected tunnel is considered as logically "destined" for its protected egress {E, P}. Its path MUST be resolved and established with E as the physical tail end.¶

A service, which is associated with a protected egress {E, P}, is called an egress-protected service. Egress router E hosts the primary instance of the service, and protector P hosts the protection instance of the service.¶

An egress-protected service is associated with one and only one protected egress {E, P}. Multiple egress-protected services may be associated with a given protected egress {E, P}. In this case, these services share the common egress router and protector, but they may or may not be carried by a common egress-protected tunnel or a common ingress router.¶

An egress-protected service MUST be mapped to an egress-protected tunnel by its ingress router, based on the common protected egress {E, P} of the service and the tunnel. This is achieved by introducing the notion of a "context ID" for a protected egress {E, P}, as described in Section 5.7.¶

5.6. Egress-Protection Bypass Tunnel

An egress-protected tunnel destined for a protected egress {E, P} MUST have a bypass tunnel from its PLR to protector P. This bypass tunnel is called an egress-protection bypass tunnel. The bypass tunnel is considered as logically "destined" for the protected egress {E, P}. Due to its bypass nature, it MUST be established with P as the physical tail end and E as the node to avoid. The bypass tunnel MUST NOT be affected by the topology change caused by an egress node failure; thus, it MUST contain a property that protects it from this scenario.¶

An egress-protection bypass tunnel is associated with one and only one protected egress {E, P}. A PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}.¶

5.7. Context ID, Context Label, and Context-Based Forwarding

In this framework, a globally unique IPv4 or IPv6 address is assigned as the identifier of the protected egress {E, P}. It is called a "context ID" due to its specific usage in context label switching and context IP forwarding on the protector. It is an IP address that is logically owned by both the egress router and the protector. For the egress router, it indicates the protector. For the protector, it indicates the egress router, particularly the egress router's forwarding context. For other routers in the network, it is an address reachable via both the egress router and the protector (Section 5.8), similar to an anycast address.¶

The main purpose of a context ID is to coordinate the ingress router, egress router, PLR, and protector to establish egress protection. The procedures are described below, given an egress-protected service associated with a protected egress {E, P} with a context ID.¶

• If the service is an MPLS service, when E distributes a service label binding message to the ingress router, E attaches the context ID to the message. If the service is an IP service, when E advertises the service destination address to the ingress router, E attaches the context ID to the advertisement message. The service protocol chooses how the context ID is encoded in the messages. A protocol extension of a "context ID" object may be needed, if there is no existing mechanism for this purpose.¶
• The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation. The semantics of the context ID is transparent to the ingress router. The ingress router only treats the context ID as an IP address of E, in the same manner as establishing or resolving a regular transport tunnel.¶
• The context ID is conveyed to the PLR by the signaling protocol of the egress-protected tunnel or learned by the PLR via an IGP (i.e., OSPF or IS-IS) or a topology-driven label distribution protocol (e.g., LDP). The PLR uses the context ID as the destination to establish or resolve an egress-protection bypass tunnel to P while avoiding E.¶
• P maintains a dedicated label space and a dedicated IP address space for E. They are referred to as "E's label space" and "E's IP address space", respectively. P uses the context ID to identify the label space and IP address space.¶
• If the service is an MPLS service, E also distributes the service label binding message to P. This is the same label binding message that E advertises to the ingress router, which includes the context ID. Based on the context ID, P installs the service label in an MPLS forwarding table corresponding to E's label space. If the service is an IP service, P installs an IP route in an IP forwarding table corresponding to E's IP address space. In either case, the protection service instance on P constructs the forwarding state for the label route or IP route based on P's own connectivity with the service's destination.¶
• P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP address space. Therefore, it is called a "context label".¶
• The PLR may establish the egress-protection bypass tunnel to P in several manners. If the bypass tunnel is established by RSVP, the PLR signals the bypass tunnel with the context ID as the destination, and P binds the context label to the bypass tunnel. If the bypass tunnel is established by LDP, P advertises the context label for the context ID as an IP prefix Forwarding Equivalence Class (FEC). If the bypass tunnel is established by the PLR in a hierarchical manner, the PLR treats the context label as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass tunnel to P's loopback IP address). If the bypass tunnel is constructed by using Segment Routing, the bypass tunnel is represented by a stack of Segment Identifier (SID) labels with the context label as the inner-most SID label (Section 5.9). In any case, the bypass tunnel is an ultimate hop-popping (UHP) tunnel whose incoming label on P is the context label.¶
• During local repair, all the service packets received by P on the bypass tunnel have the context label as the top label. P first pops the context label. For an MPLS service packet, P looks up the service label in E's label space indicated by the context label. Such kind of forwarding is called context label switching. For an IP service packet, P looks up the IP destination address in E's IP address space indicated by the context label. Such kind of forwarding is called context IP forwarding.¶

5.8. Advertisement and Path Resolution for Context ID

Path resolution and computation for a context ID are done on ingress routers for egress-protected tunnels and on PLRs for egress-protection bypass tunnels. Given a protected egress {E, P} and its context ID, E and P MUST coordinate on the reachability of the context ID in the routing domain and the TE domain. The context ID MUST be advertised in such a manner that all egress-protected tunnels MUST have E as the tail end, and all egress-protection bypass tunnels MUST have P as the tail end while avoiding E.¶

This document suggests three approaches:¶

• 1. The first approach is called "proxy mode". It requires E and P, but not the PLR, to have the knowledge of the egress protection schema. E and P advertise the context ID as a virtual proxy node (i.e., a logical node) connected to the two routers, with the link between the proxy node and E having more preferable IGP and TE metrics than the link between the proxy node and P. Therefore, all egress-protected tunnels destined for the context ID will automatically follow the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate hop but rather as two hops away from the proxy node, via E. The PLR will be able to find a bypass path via P to the proxy node, while the bypass tunnel is actually terminated by P.¶
  2. The second approach is called "alias mode". It requires P and the PLR, but not E, to have the knowledge of the egress protection schema. E simply advertises the context ID as an IP address. P advertises the context ID and the context label by using a "context ID label binding" advertisement. In both the routing domain and TE domain, the context ID is only reachable via E. Therefore, all egress-protected tunnels destined for the context ID will have E as the tail end. Based on the "context ID label binding" advertisement, the PLR can establish an egress-protection bypass tunnel in several manners (Section 5.9). The "context ID label binding" advertisement is defined as the IGP Mirroring Context segment in [RFC8402] and [RFC8667]. These IGP extensions are generic in nature and hence can be used for egress protection purposes. It is RECOMMENDED that a similar advertisement be defined for OSPF as well.¶
  3. The third approach is called "stub link mode". In this mode, both E and P advertise the context ID as a link to a stub network, essentially modeling the context ID as an anycast IP address owned by the two routers. E, P, and the PLR do not need to have the knowledge of the egress protection schema. The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the anycast IP address performed by the ingress routers and PLR. Therefore, care MUST be taken for the applicability of this approach to a network.¶

This framework considers the above approaches as technically equal and the feasibility of each approach in a given network as dependent on the topology, manageability, and available protocols of the network. For a given context ID, all relevant routers, including the primary PE, protector, and PLR, MUST support and agree on the chosen approach. The coordination between these routers can be achieved by configuration.¶

In a scenario where an egress-protected tunnel is an inter-area or inter-Autonomous-System (inter-AS) tunnel, its 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. The propagation process of the context ID SHOULD be the same as that of an IP address in an inter-area or inter-AS environment.¶

5.9. Egress-Protection Bypass Tunnel Establishment

A PLR MUST know the context ID of a protected egress {E, P} in order to establish an egress-protection bypass tunnel. The information is obtained from the signaling or label distribution protocol of the egress-protected tunnel. The PLR may or may not need to have the knowledge of the egress-protection schema. All it does is set up a bypass tunnel to a context ID while avoiding the next-hop router (i.e., egress router). This is achievable by using a constraint-based computation algorithm similar to those commonly used for traffic engineering paths and Loop-Free Alternate (LFA) paths. Since the context ID is advertised in the routing domain and in the TE domain by IGP according to Section 5.8, the PLR is able to resolve or establish such a bypass path with the protector as the tail end. In the case of proxy mode, the PLR may do so in the same manner as transit node protection.¶

An egress-protection bypass tunnel may be established via several methods:¶

• 1. It may be established by a signaling protocol (e.g., RSVP), with the context ID as the destination. The protector binds the context label to the bypass tunnel.¶
  2. It may be formed by a topology-driven protocol (e.g., LDP with various LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, with the context label bound to it.¶
  3. It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (Section 5.8), the PLR will have the knowledge of the context ID, context label, and protector (i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarchical manner, with the context label as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e.g., loopback address). This regular bypass tunnel may be established by RSVP, LDP, Segment Routing, or another protocol.¶

5.10. Local Repair on PLR

In this framework, a PLR is agnostic to services and service labels. This obviates the need to maintain bypass forwarding state on a per-service basis and allows bypass tunnel sharing between egress-protected tunnels. The PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}. During local repair, the PLR reroutes all service packets received on the egress-protected tunnels to the egress-protection bypass tunnel. Service labels remain intact in MPLS service packets.¶

Label operation performed by the PLR depends on the bypass tunnel's characteristics. If the bypass tunnel is a single level tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to the outgoing label of the bypass tunnel. If the bypass tunnel is a hierarchical tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label and pushing the outgoing label of a regular bypass tunnel. If the bypass tunnel is constructed by Segment Routing, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label and pushing the stack of SID labels of the bypass tunnel.¶

5.11. Service Label Distribution from Egress Router to Protector

When a protector receives a rerouted MPLS service packet, it performs context label switching based on the packet's service label, which is assigned by the corresponding egress router. In order to achieve this, the protector MUST maintain the labels of egress-protected services in dedicated label spaces on a per-protected-egress {E, P} basis, i.e., one label space for each egress router that it protects.¶

Also, there MUST be a service label distribution protocol session between each egress router and the protector. Through this protocol, the protector learns the label binding of each egress-protected service. This is the same label binding that the egress router advertises to the service's ingress router, which includes a context ID. The corresponding protection service instance on the protector recognizes the service and resolves forwarding state based on its own connectivity with the service's destination. It then installs the service label with the forwarding state in the label space of the egress router, which is indicated by the context ID (i.e., context label).¶

Different service protocols may use different mechanisms for such kind of label distribution. Specific extensions may be needed on a per-protocol or per-service-type basis. The details of the extensions should be specified in separate documents. As an example, the LDP extensions for pseudowire services are specified in [RFC8104].¶

5.12. Centralized Protector Mode

In this framework, it is assumed that the service destination of an egress-protected service MUST be dual-homed to two edge routers of an MPLS network. One of them is the protected egress router, and the other is a backup egress router. So far in this document, the focus of discussion has been on the scenario where a protector and a backup egress router are co-located as one router. Therefore, the number of protectors in a network is equal to the number of backup egress routers. As another scenario, a network may assign a small number of routers to serve as dedicated protectors, each protecting a subset of egress routers. These protectors are called centralized protectors.¶

Topologically, a centralized protector may be decoupled from all backup egress routers, or it may be co-located with one backup egress router while decoupled from the other backup egress routers. The procedures in this section assume that a protector and a backup egress router are decoupled.¶

               services 1, ..., N
     =====================================> tunnel
                                                 
   I ------ R1 ------- PLR --------------- E ----
ingress          penultimate hop        egress    \
                        |  .           (primary    \    
                        |  .            service     \
                        |  .            instances)   \
                        |  .                          \
                        |  . bypass                    \   service
                       R2  . tunnel                      destinations
                        |  .                           / (CEs, sites)
                        |  .                          /
                        |  .                         /
                        |  .                        /
                        |  .    tunnel             /
                        |   =============>        /
                        P ---------------- E' ---
                    protector        backup egress
                   (protection         (backup
                    service             service
                    instances)          instances) 

Like a co-located protector, a centralized protector hosts protection service instances, receives rerouted service packets from PLRs, and performs context label switching and/or context IP forwarding. For each service, instead of sending service packets directly to the service destination, the protector MUST send them via another transport tunnel to the corresponding backup service instance on a backup egress router. The backup service instance in turn forwards the service packets to the service destination. Specifically, if the service is an MPLS service, the protector MUST swap the service label in each received service packet to the label of the backup service advertised by the backup egress router, and then push the label (or label stack) of the transport tunnel.¶

In order for a centralized protector to map an egress-protected MPLS service to a service hosted on a backup egress router, there MUST be a service label distribution protocol session between the backup egress router and the protector. Through this session, the backup egress router advertises the service label of the backup service, attached with the FEC of the egress-protected service and the context ID of the protected egress {E, P}. Based on this information, the protector associates the egress-protected service with the backup service, resolves or establishes a transport tunnel to the backup egress router, and sets up forwarding state for the label of the egress-protected service in the label space of the egress router.¶

The service label that the backup egress router advertises to the protector can be the same as the label that the backup egress router advertises to the ingress router(s), if and only if the forwarding state of the label does not direct service packets towards the protected egress router. Otherwise, the label MUST NOT be used for egress protection, because it would create a loop for the service packets. In this case, the backup egress router MUST advertise a unique service label for egress protection and set up the forwarding state of the label to use the backup egress router's own connectivity with the service destination.¶