RFC 8104
Pseudowire (PW) Endpoint Fast Failure Protection
Pages: 43
Proposed Standard
Proposed Standard
Part 1 of 2 – Pages 1 to 29
Internet Engineering Task Force (IETF) Y. Shen Request for Comments: 8104 Juniper Networks Category: Standards Track R. Aggarwal ISSN: 2070-1721 Arktan, Inc. W. Henderickx Nokia Y. Jiang Huawei Technologies Co., Ltd. March 2017 Pseudowire (PW) Endpoint Fast Failure ProtectionAbstract
This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8104.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Specification of Requirements . . . . . . . . . . . . . . . . 5 3. Reference Models for Egress Endpoint Failures . . . . . . . . 5 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 6 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 9 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 10 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Local Repair . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Context Identifier . . . . . . . . . . . . . . . . . . . 14 4.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 15 4.3.2. FEC . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.3. IGP Advertisement and Path Computation . . . . . . . 16 4.4. Protection Models . . . . . . . . . . . . . . . . . . . . 17 4.4.1. Co-located Protector . . . . . . . . . . . . . . . . 17 4.4.2. Centralized Protector . . . . . . . . . . . . . . . . 19 4.5. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 20 4.6. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Examples of Forwarding State . . . . . . . . . . . . . . 22 4.7.1. Co-located Protector Model . . . . . . . . . . . . . 22 4.7.2. Centralized Protector Model . . . . . . . . . . . . . 26 5. Restorative and Revertive Behaviors . . . . . . . . . . . . . 29 6. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Egress Protection Capability TLV . . . . . . . . . . . . 31 6.2. PW Label Distribution from Primary PE to Protector . . . 32 6.3. PW Label Distribution from Backup PE to Protector . . . . 33 6.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 34 6.4.1. Encoding Format for PWid with IPv4 PE Addresses . . . 35 6.4.2. Encoding Format for Generalized PWid with IPv4 PE Addresses . . . . . . . . . . . . . . . . . . . . . . 36 6.4.3. Encoding Format for PWid with IPv6 PE Addresses . . . 37 6.4.4. Encoding Format for Generalized PWid with IPv6 PE Addresses . . . . . . . . . . . . . . . . . . . . . . 38 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.1. Normative References . . . . . . . . . . . . . . . . . . 40 9.2. Informative References . . . . . . . . . . . . . . . . . 41 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction
Per [RFC3985], [RFC8077], and [RFC5659], a pseudowire (PW) or PW segment can be thought of as a connection between a pair of forwarders hosted by two PEs, carrying an emulated Layer 2 service over a packet switched network (PSN). In the single-segment PW (SS-PW) case, a forwarder binds a PW to an attachment circuit (AC). In the multi-segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW segment to an AC, while a forwarder on a switching PE (S-PE) binds one PW segment to another PW segment. In each direction between the PEs, PW packets are transported by a PSN tunnel, which is also called a transport tunnel. In order to protect the PW service against network failures, it is necessary to protect every link and node along the entire data path. For the traffic in a given direction, this includes ingress AC, ingress (T-)PE, intermediate routers of the transport tunnel, S-PEs, egress (T-)PE, and egress AC. To minimize service disruption upon a failure, it is also desirable that each of these components is protected by a fast protection mechanism based on local repair. Such mechanisms generally involve a bypass path that is pre-computed and pre-installed in the data plane on the router upstream adjacent to an anticipated failure. This router is referred to as a "point of local repair" (PLR). The bypass path has the property that it can guide traffic around the failure, while remaining unaffected by the topology changes resulting from the failure. When the failure occurs, the PLR can invoke the bypass path to achieve fast restoration for the service. Today, fast protection against ingress AC failure and ingress (T-)PE failure can be achieved by using a multihomed CE and redundant ACs, such as a multi-chassis link aggregation group (MC-LAG). Fast protection against the failure of an intermediate router of the transport tunnel can be achieved through RSVP fast reroute [RFC4090] or IP/LDP fast reroute [RFC5286] [RFC5714]. However, there is no equivalent mechanism that can be used against an egress AC failure, an egress (T-)PE failure, or an S-PE failure. For these failures, service restoration has to rely on global repair or control-plane convergence. Global repair normally involves the ingress CE or the ingress (T-)PE switching traffic to an alternative path, based on remote failure detection via PW status notification, end-to-end Operations, Administration, and Maintenance (OAM), and others. Control-plane convergence relies on control protocols to react on the topology changes due to a failure. Compared to local repair, these mechanisms are relatively slow in reacting to a failure and restoring traffic.
This document addresses the above need. It specifies a fast
protection mechanism based on local repair to protect PWs against the
following endpoint failures:
a. Egress AC failure.
b. Egress PE failure: Link or node failure of an egress PE of an
SS-PW or a T-PE of an MS-PW.
c. Switching PE failure: Link or node failure of an S-PE of an
MS-PW.
The mechanism is applicable to LDP-signaled PWs. It is relevant to
networks with redundant PWs and multihomed CEs. It is designed on
the basis of MPLS upstream label assignment and context-specific
label switching [RFC5331]. Fast protection refers to its ability to
restore traffic in the order of tens of milliseconds. Compared with
global repair and control-plane convergence, this mechanism can
provide faster service restoration. However, it is intended to
complement these mechanisms, rather than replacing them, as networks
rely on them to eventually move traffic to fully functional
alternative paths.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Reference Models for Egress Endpoint Failures
This document refers to the following topologies to describe egress
endpoint failures and protection procedures.
3.1. Single-Segment PW
|<-------------- PW1 --------------->| - PE1 -------------- P1 ---------------- PE2 - / \ / \ CE1 CE2 \ / \ / - PE3 -------------- P2 ---------------- PE4 - |<-------------- PW2 --------------->| Figure 1 In Figure 1, the IP/MPLS network consists of PE and P routers. It provides a PW service between CE1 and CE2. Each CE is multihomed via two ACs to two PEs. This forms two divergent paths between the CEs. The first path uses PW1 between PE1 and PE2, and the second path uses PW2 between PE3 and PE4. For clarity, the transport tunnels of the PWs and other links between the routers are not shown in this figure. In general, a CE may operate the ACs in two modes when sending traffic to the remote CE, i.e., active-standby mode and active-active mode. o In the active-standby mode, the CE chooses one AC as the active AC and the corresponding path as the active path, and it uses the other AC as the standby AC and the corresponding path as the standby path. The CE only sends traffic on the active AC as long as the active path is operational. The CE will only send traffic on the standby AC after it detects a failure of the active path. Note that the CE may receive traffic on the active or standby AC, depending on whether the remote CE chooses the same active path for the traffic of the reverse direction. In this document, even if both CEs choose the same active path, each CE should still anticipate receiving traffic on a standby AC, because the traffic may be redirected to the standby path by the fast protection mechanism. o In the active-active mode, the CE treats both ACs and their corresponding paths as active and sends traffic on both ACs in a load-balancing fashion. In the reverse direction, the CE may receive traffic on both ACs. The above modes assume the traffic to be data traffic, which is not bound to a specific AC. This does not include control-protocol
traffic between the CEs, when the CE-CE control-protocol sessions or adjacencies established on the two ACs are considered as distinct rather than having a primary and backup relationship. In general, a dual-homed CE should not make any explicit or implicit assumptions regarding the specific AC from which it receives packets from the remote CE. For either mode, when considering the traffic flowing in a given direction over an active path, this document views the ACs, PEs, and PWs as serving primary or backup roles. In particular, the ACs, PEs, and PWs along this active path have primary roles, while those along the other path have backup roles. Note that in the active-active mode, each AC, PE, and PW on an active path has a primary role and also a backup role protecting the other path, which is also active. For Figure 1, the following roles are assumed for the traffic going from CE1 to CE2 via PW1. Primary ingress AC: CE1-PE1 Primary ingress PE: PE1 Primary PW: PW1 Primary egress PE: PE2 Primary egress AC: PE2-CE2 Backup ingress AC: CE1-PE3 Backup ingress PE: PE3 Backup PW: PW2 Backup egress PE: PE4 Backup egress AC: PE4-CE2 Based on this schema, this document describes egress endpoint failures and the fast protection mechanism on the per-active-path and per-direction basis. In this case, an egress AC failure refers to the failure of the AC PE2-CE2, and an egress node failure refers to the failure of PE2. The ultimate goal is that when a failure occurs, the traffic should be locally repaired, so that it can eventually reach CE2 via the backup egress PE (PE4) and the backup egress AC (PE4-CE2).
Subsequent to the local repair, either the current active path should heal after the control plane converges on the new topology or the ingress CE should switch traffic from the primary path to the backup path, depending on the failure scenario. In the latter case, the ingress CE may perform the path switchover triggered by end-to-end OAM (in-band or out-band), PW status notification, CE-PE control protocols (e.g., the Link Aggregation Control Protocol (LACP)), and others. In the active-standby mode, this will promote the standby path to a new active path. In the active-active mode, it will make the other active path carry all the traffic between the two CEs. In any case, this phase of restoration falls into the control-plane convergence and global repair category; hence, it is out of the scope of this document. The purpose of the fast protection mechanism in this document is to reduce traffic loss before this phase of restoration takes place. Note that in Figure 1, if the traffic in the reverse direction (i.e., from CE2 to CE1) traverses the AC CE2-PE2 and PE2 as an active path, the failure of PE2 and the failure of the AC PE2-CE2 will be considered as ingress failures of the traffic. If CE2 can detect the failures, it may protect the traffic by switching it to the backup path via the AC CE2-PE4 and PE4. However, this is categorized as ingress endpoint failure protection; hence, it is not handled by the mechanism described in this document. Figure 2 shows another possible scenario, where CE1 is single-homed to PE1, while CE2 remains multihomed to PE2 and PE4. From the perspective of egress endpoint protection for the traffic going from CE1 to CE2 over PW1, this scenario is the same as the scenario shown in Figure 1. |<-------------- PW1 --------------->| ------------- P1 ---------------- PE2 - / \ / \ CE1 -- PE1 CE2 \ / \ / ------------- P2 ---------------- PE4 - |<-------------- PW2 --------------->| Figure 2
For clarity, primary egress AC, primary egress PE, backup egress AC, and backup egress PE may simply be referred to as primary AC, primary PE, backup AC, and backup PE, respectively, when the context of a discussion is egress endpoint.3.2. Multi-Segment PW
|<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 -------------- SPE1 --------------- TPE2 - / \ / \ CE1 CE2 \ / \ / - TPE3 -------------- SPE2 --------------- TPE4 - |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 3 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW environment. PW1 and PW2 are both MS-PWs. PW1 is established between TPE1 and TPE2 and switched between segments SEG1 and SEG2 at SPE1. PW2 is established between TPE3 and TPE4 and switched between segments SEG3 and SEG4 at SPE2. CE1 is multihomed to TPE1 and TPE3. CE2 is multihomed to TPE2 and TPE4. For clarity, the transport tunnels of the PW segments are not shown in this figure. In this document, the following primary and backup roles are assigned for the traffic going from CE1 to CE2: Primary ingress AC: CE1-TPE1 Primary ingress T-PE: TPE1 Primary PW: PW1 Primary S-PE: SPE1 Primary egress T-PE: TPE2 Primary egress AC: TPE2-CE2 Backup ingress AC: CE1-TPE3
Backup ingress T-PE: TPE3
Backup PW: PW2
Backup S-PE: SPE2
Backup egress T-PE: TPE4
Backup egress AC: TPE4-CE2
In this case, an egress AC failure refers to the failure of the AC
TPE2-CE2. An egress node failure refers to the failure of TPE2. An
S-PE failure refers to the failure of SPE1.
For consistency with the SS-PW scenario, primary T-PEs and primary
S-PEs may simply be referred to as primary PEs in this document,
where specifics are not required. Similarly, backup T-PEs and backup
S-PEs may be referred to as backup PEs.
4. Theory of Operation
The fast protection mechanism in this document provides three types
of protection for PWs, corresponding to the three types of failures
described in Section 1:
a. Egress AC protection
b. Egress (T-)PE node protection
c. S-PE node protection
4.1. Applicability
The mechanism is applicable to LDP-signaled PWs in an environment
where an egress CE is multihomed to a primary PE and a backup PE and
there exists a backup PW, as described in Section 3. The procedure
for S-PE node protection is applicable when there exists a backup
S-PE on the backup PW.
The mechanism assumes IP/MPLS transport tunnels and is applicable to
tunnels with single path and equal-cost multipaths (ECMPs). As an
example of ECMPs, imagine a tunnel carrying one or multiple PWs and
traversing a router with ECMPs to a primary PE. The ECMPs consist of
at least one direct link to the PE and some multi-hop paths to the
PE. Due to the direct link, the router is considered as a
penultimate hop of the tunnel and can perform local detection and
repair for an egress node failure. The router normally uses a
hashing algorithm to distribute PW packets over the ECMPs, on a
per-PW or per-flow basis. Upon a failure of the direct link, i.e., transit link failure, the router removes the link from the hashing algorithm, which automatically redistributes the traffic of the link to the other paths of the ECMPs, achieving local repair. This scenario is not the focus of this document. Upon a failure of the PE, i.e., egress node failure, the router SHOULD perform local repair by rerouting the entire traffic of the ECMPs, as the failure will affect every path. If the router does not have a fast or reliable mechanism to detect the egress node failure, it is RECOMMENDED that the router SHOULD treat the failure of the direct link as an egress node failure. The mechanism is applicable to both best-effort and traffic engineering (TE) transport tunnels. For TE transport tunnels that require bandwidth protection, TE bypass tunnels with reserved bandwidth MAY be used to avoid congestion for rerouted traffic. It is also RECOMMENDED that the mechanism SHOULD be used in conjunction with global repair and control-plane convergence, in such a manner that the mechanism temporarily repairs a failed path by using a bypass tunnel, and global repair and control-plane convergence eventually move traffic to a fully functional alternative path.4.2. Local Repair
The fast protection ability of the mechanism comes from local repair performed by routers upstream adjacent to failures. Each of these routers is referred to as a PLR. A PLR MUST be able to detect a failure by using a rapid mechanism, such as physical-layer failure detection, Bidirectional Forwarding Detection (BFD) [RFC5880], Seamless BFD (S-BFD) [RFC7880], and others. In anticipation of the failure, the PLR MUST also pre-establish a bypass tunnel to a "protector" and pre-install a bypass route for the bypass tunnel in the data plane. The protector is either a backup PE or a router that will forward traffic to a backup PE. The bypass tunnel MUST have the property that it will not be affected by the topology changes due to the failure. Specifically, it MUST NOT traverse the primary PE or the penultimate link of the protected transport tunnel or share any shared risk link groups (SRLGs) with the penultimate link. Upon detecting the failure, the PLR invokes the bypass route in the data plane and reroutes PW traffic to the protector through the bypass tunnel. The protector in turn sends the traffic to the target CE. This procedure is referred to as local repair. Different routers may serve as PLR and protector in different scenarios.
o In egress AC protection, the PLR is the primary PE, and the
protector is the backup PE (Figure 4).
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ---------------- PE2 -
/ PLR \
/ | \
CE1 bypass| CE2
\ | /
\ | /
- PE3 -------------- P2 ---------------- PE4 -
protector
|<-------------- PW2 --------------->|
Figure 4
o In egress PE node protection, the PLR is the penultimate hop
router of the transport tunnel of the primary PW, and the
protector is the backup PE (Figure 5).
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- PE3 -------------- P2 ---------------- PE4 -
protector
|<-------------- PW2 --------------->|
Figure 5
o In S-PE node protection, the PLR is the penultimate hop router of
the transport tunnel of the primary PW segment, and the protector
is the backup S-PE (Figure 6).
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 6
In egress AC protection, a PLR realizes its role based on
configuration of a "context identifier", which is introduced in this
document (Section 4.3). The PLR establishes a bypass tunnel to the
protector in the same fashion as a normal PSN tunnel.
In egress PE and S-PE node protection, a PLR is a transit router on
the transport tunnel, and it normally does not have knowledge of the
PW(s) carried by the transport tunnel. In this document, the PLR
simply computes and establishes a node-protection bypass tunnel in
the same fashion as the normal IP/MPLS node protection, except that
with the notion of the context identifier, the bypass tunnel will be
established from the PLR to the protector (Section 4.6). Conversely,
when the router is no longer a PLR for egress PE or S-PE node
protection due to a change in network topology or the transport
tunnel's path, the router should revert to the role of regular
transit router, including PLR for transit link and node protection.
In local repair, a PLR simply switches all the traffic received on
the transport tunnel to the bypass tunnel. This requires that the
protector given by the bypass tunnel MUST be intended for all the PWs
carried by the transport tunnel. This is achieved by the ingress PE
using a context identifier to associate a PW with the specific pair
of {primary PE, protector} and map the PW to a transport tunnel
destined for the same {primary PE, protector}. The ingress PE MAY
map multiple PWs to the transport tunnel, if they share the {primary
PE, protector} in common.
In local repair, the PLR keeps the PW label intact in packets. This obviates the need for the PLR to maintain bypass routes on a per-PW basis and allows bypass tunnel sharing between PWs. On the other hand, this imposes a requirement on the protector that it MUST be able to forward the packets based on a PW label that is assigned by the primary PE and ensure that the traffic MUST reach the target CE via a backup path. From the protector's perspective, this PW label is an upstream assigned label [RFC5331]. To achieve this, the protector MUST learn the PW label from the primary PE prior to the failure and install a proper forwarding state for the PW label in a dedicated label space associated with the primary PE. During local repair, the protector MUST perform PW label lookup in this label space. The previous examples have shown the scenarios where the protectors are backup (T-/S-)PEs. It is also possible that a protector is a dedicated router to serve such a role, separate from the backup (T-/S-)PE. During local repair, the PLR still reroutes traffic to the protector through a bypass tunnel. The protector then forwards the traffic to the backup (T-/S-)PE, which further forwards the traffic to the target CE via a backup AC or a backup PW segment. More detail is included in Section 4.4.4.3. Context Identifier
A protector may protect multiple primary PEs. The protector MUST maintain a separate label space for each primary PE. Likewise, the PWs terminated on a primary PE may be protected by multiple protectors, each for a subset of the PWs. In any case, a given PW MUST be associated with one and only one pair of {primary PE, protector}. This document introduces the notion of a context identifier to facilitate protection establishment. A context identifier is an IPv4/v6 address assigned to each ordered pair of {primary PE, protector}. The address MUST be globally unique or unique in the address space of the network where the primary PE and the protector reside.
4.3.1. Semantics
The semantics of a context identifier is twofold: o A context identifier identifies a primary PE and an associated protector. It represents the primary PE as the PW destination on a per-protector basis. A given primary PE may be protected by multiple protectors, each for a subset of the PWs terminated on the primary PE. A distinct context identifier MUST be assigned to each {primary PE, protector} pair. The ingress PE of a PW learns the context identifier of the PW's {primary PE, protector} from the primary PE via the Interface_ID TLV [RFC3471] [RFC3472] in the LDP Label Mapping message of the PW. The ingress PE then sets up or resolves a transport tunnel with the context identifier, rather than a private IP address of the primary PE, as the destination. This destination not only makes the transport tunnel reach the primary PE but also conveys the identity of the protector to the PLR, which MUST use the context identifier as the destination for the bypass tunnel to the protector. The ingress PE MUST map only the PWs terminated by the exact primary PE and protected by the exact protector to the transport tunnel. o A context identifier indicates the primary PE's label space on the protector. The protector may protect PWs for multiple primary PEs. For each primary PE, it MUST maintain a separate label space to store the PW labels assigned by that primary PE. It associates a PW label with a label space via the context identifier of the {primary PE, protector}, as below. In addition to the normal LDP PW signaling, the primary PE MUST have a targeted LDP session with the protector and advertise PW labels to the protector via LDP Label Mapping messages (Section 6). The primary PE MUST attach the context identifier to each message. Upon receiving the message, the protector MUST install the advertised PW label in the label space identified by the context identifier. When a PLR sets up or resolves a bypass tunnel to the protector, it MUST use the context identifier rather than a private IP address of the protector as the destination. The protector MUST use the bypass tunnel, either the MPLS tunnel label or the IP tunnel destination address, as the pointer to the corresponding label space. The protector MUST forward PW packets received on the bypass tunnel based on label lookup in that label space.
4.3.2. FEC
In an MPLS network, a context identifier represents a Forwarding Equivalence Class (FEC) for transport tunnels and bypass tunnels destined for it. For example, it may be encoded in an LDP Prefix FEC Element or in the "tunnel endpoint address" of an RSVP Session object. The FEC is associated with a unique forwarding state on PLRs and the protector, which cannot be shared with other FECs. Some MPLS protocols (e.g., LDP) support FEC aggregation [RFC3031]. In this case, FEC aggregation MUST NOT be applied to a context identifier's FEC, and every router MUST assign a unique label to the FEC.4.3.3. IGP Advertisement and Path Computation
Using a context identifier as the destination for both the transport tunnel and bypass tunnel requires coordination between the primary PE and the protector in IGP advertisement of the context identifier in the routing domain and TE domain. The context identifier should be advertised in such a way that all the routers on the tunnels MUST be able to independently reach the following common view of paths: o The transport tunnel MUST have the primary PE as the path endpoint. o The bypass tunnel MUST have the protector as the path endpoint. In egress PE and S-PE node protection, the path MUST avoid the primary PE. There are generally two categories of approaches to achieve the above: o The first category does not require an ingress PE or a PLR to have knowledge of the PW egress endpoint protection schema. It does not require any IGP extension for context identifier advertisement. A context identifier is advertised by the primary PE and the protector as an address reachable via both routers. The ingress PE and the PLR can compute paths by using a normal method, such as Dijkstra, constrained shortest path first (CSPF), Loop-Free Alternate (LFA) [RFC5286], and Maximally Redundant Tree (MRT) [RFC7812]. One example is to advertise a context identifier as a virtual proxy node connected to the primary PE and the protector, with the link between the proxy node and the primary PE having a more preferable IGP and TE metric than the link between the proxy node and the protector. The transport tunnel will follow the shortest path or a TE path to the primary PE and be terminated by the primary PE. The PLR will no longer view itself as a penultimate hop of the transport tunnel, but rather two hops away from the proxy node, via the primary PE. Hence, a node-
protection bypass tunnel will be available via the protector to
the proxy node, but it will actually be terminated by the
protector.
o The second category requires a PLR to have knowledge of the PW
egress endpoint protection schema. The primary PE advertises the
context identifier as a regular IP address, while the protector
advertises it by using an explicit "context identifier object",
which MUST be understood by the PLR. The context identifier
object requires an IGP extension. In both the routing domain and
the TE domain, the context identifier is only reachable via the
primary PE. This ensures that the transport tunnel is terminated
by the primary PE. The PLR views itself as the penultimate hop of
the transport tunnel, and based on the IGP context identifier
object, it establishes or resolves a bypass tunnel to the
advertiser (i.e., the protector), while avoiding the primary PE.
The mechanism in this document intends to be flexible on the approach
used by a network, as long as it satisfies the above requirements for
the transport tunnel path and bypass tunnel path. In theory, the
network can use one approach for context ID X and another approach
for context ID Y. For a given context ID, all relevant routers,
including primary PE, protector, and PLR, must support and agree on
the chosen approach. The coordination between the routers can be
achieved by configuration.
4.4. Protection Models
There are two protection models based on the location of a protector:
the co-located protector model and the centralized protector model.
A network MAY use either model or both.
4.4.1. Co-located Protector
In this model, the protector is a backup PE that is directly
connected to the target CE via a backup AC, or it is a backup S-PE on
a backup PW. That is, the protector is co-located with the backup
(S-)PE. Examples of this model are shown in Figures 4, 5, and 6 in
Section 4.2.
In egress AC protection and egress PE node protection, when a
protector receives traffic from the PLR, it forwards the traffic to
the CE via the backup AC. This is shown in Figure 7, where PE2 is
the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4
(backup PE) is the protector.
|<-------------- PW1 --------------->| - PE1 -------------- P1 ------- P3 ----- PE2 ---- / PLR \ PLR \ / \ | \ CE1 bypass\ |bypass CE2 \ \ | / \ \ | / - PE3 -------------- P2 ---------------- PE4 ---- protector |<-------------- PW2 --------------->| Figure 7 In S-PE node protection, when a protector receives traffic from the PLR, it forwards the traffic over the next segment of the backup PW. The T-PE of the backup PW in turn forwards the traffic to the CE via a backup AC. This is shown in Figure 8, where P1 is the PLR for SPE1 failure, and SPE2 (backup S-PE) is the protector for SPE1. SPE2 receives traffic from P1, swaps SEG1's label to SEG4's label, and forwards the traffic over a transport tunnel to TPE4. |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - protector |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 8 In the co-located protector model, the number of context identifiers needed by a network is the number of distinct {primary PE, backup PE} pairs. From the perspective of scalability, the model is suitable for networks where the number of primary PEs and the average number of backup PEs per primary PE are both relatively low.
4.4.2. Centralized Protector
In this model, the protector is a dedicated P router or PE router that serves the role. In egress AC protection and egress PE node protection, the protector may or may not be a backup PE directly connected to the target CE. In S-PE node protection, the protector may or may not be a backup S-PE on the backup PW. In egress AC protection and egress PE node protection, if the protector is not directly connected to the CE, it forwards the traffic to a backup PE, which in turn forwards the traffic to the CE via a backup AC. This is shown in Figure 9, where the protector receives traffic from P3 (PLR for egress PE failure) or PE2 (PLR for egress AC failure), swaps PW1's label to PW2's label, and forwards the traffic via a transport tunnel to PE4 (backup PE). The protector may be protecting other PWs and other primary PEs as well; for clarity, this is not shown in the figure. |<------------- PW1 --------------->| - PE1 ------------- P1 ------- P3 ----- PE2 -- / PLR \ PLR \ / \ / \ / bypass\ /bypass \ / \ / \ CE1 protector CE2 \ \ / \ transport\ / \ tunnel \ / \ \ / - PE3 ------------- P2 -----------------PE4 -- |<------------- PW2 --------------->| Figure 9 In S-PE node protection, if the protector is not a backup S-PE, it forwards the traffic to the backup S-PE, which in turn forwards the traffic over the next segment of the backup PW. Finally, the T-PE of the backup PW forwards the traffic to the CE via the backup AC. This is shown in Figure 10, where the protector receives traffic from P1 (PLR), swaps SEG1's label to SEG3's label, and forwards the traffic via a transport tunnel to SPE2 (backup S-PE). SPE2 in turn performs MS-PW switching from SEG3's label to SEG4's label and forwards the traffic over a transport tunnel to TPE4 (backup T-PE). The protector may be protecting other PW segments and other primary S-PEs as well; for clarity, this is not shown in the figure.
|<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ / bypass\ \ / \ \ CE1 protector CE2 \ \ / \ transport\ / \ tunnel \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 10 The centralized protector model allows multiple primary PEs to share one protector. Each primary PE may need only one protector. Therefore, the number of context identifiers needed by a network may be bound to the number of primary PEs.4.5. Transport Tunnel
A PW is associated with a pair of {primary PE, protector}, which is represented by a unique context identifier. The ingress PE of the PW sets up or resolves a transport tunnel by using the context identifier rather than a private IP address of the primary PE as the destination. This not only ensures that the PW is transported to the primary PE but also facilitates bypass tunnel establishment at PLR, because the context identifier contains the identity of the protector as well. This is also the case for a multi-segment PW, where the ingress PE and egress PE are T-/S-PEs. An ingress PE learns the association between a PW and a context identifier from the primary PE, which MUST advertise the context identifier as a "third-party next hop" via the IPv4/v6 Interface_ID TLV [RFC3471] [RFC3472] in the LDP Label Mapping message of the PW. In an ECMP scenario, a transport tunnel may have multiple penultimate hop routers. Each of them SHOULD act as a PLR independently. Also in an ECMP scenario, a penultimate hop router may have ECMPs to the primary PE. At least one path of the ECMPs must be a direct link to the primary PE, qualifying the router as a penultimate hop. The other paths of the ECMPs may be direct links or indirect paths to the
primary PE. In egress PE node protection and S-PE node protection, when a node failure is detected, or a link failure is detected on a direct link and treated as a node failure, the penultimate hop router SHOULD act as a PLR and reroute the entire traffic of the ECMPs to the protector.4.6. Bypass Tunnel
A PLR may protect multiple PWs associated with one or multiple pairs of {primary PE, protector}. The PLR MUST establish a bypass tunnel to each protector for each context identifier associated with that protector. The destination of the bypass tunnel MUST be the context identifier (Section 4.3.1). Since the PLR is a transit router of the transport tunnel, it SHOULD derive the context identifier from the destination of the transport tunnel. For example, in Figures 7 and 9, a bypass tunnel is established from PE2 (PLR for egress AC failure) to the protector, and another bypass tunnel is established from P3 (PLR for egress node failure) to the protector. In Figures 8 and 10, a bypass tunnel is established from P1 (PLR for S-PE failure) to the protector. In local repair, a PLR reroutes traffic to the protector through a bypass tunnel, with the PW label intact in the packets. This normally involves pushing a label to the label stack, if the bypass tunnel is an MPLS tunnel, or pushing an IP header to the packets, if the bypass tunnel is an IP tunnel. Upon receipt of the packets, the protector forwards them based on the PW label. Specifically, the protector uses the bypass tunnel as a context to determine the primary PE's label space. If the bypass tunnel is an MPLS tunnel, the protector should have assigned a non-reserved label to the bypass tunnel; hence, this label can serve as the context. This label is also called a "context label", as it is actually bound to the context identifier. If the bypass tunnel is an IP tunnel, the context identifier should be the destination address of the IP header. To be useful for local repair, a bypass tunnel MUST have the property that it is not affected by any topology changes caused by the failure. It MUST NOT traverse the primary PE or the penultimate link of the transport tunnel, or share any SRLG with the penultimate link. A bypass tunnel may be a TE tunnel with reserved bandwidth to avoid traffic congestion for rerouted traffic. A bypass tunnel should remain effective during local repair, until the traffic is moved to an alternative path, i.e., either the same PW over a fully functional transport tunnel or another fully functional PW.
There is little or no benefit to protect a bypass tunnel. Therefore, a bypass tunnel SHOULD NOT be protected against a transit link failure, transit node failure, or egress node failure.4.7. Examples of Forwarding State
This section provides some detailed examples of forwarding state on the PLR, protector, and other relevant routers. A protector learns PW labels from all the primary PEs that it protects (Section 6.2) and maintains the PW labels in separate label spaces on a per-primary-PE basis. In the control plane, each label space is identified by the context identifier of the corresponding {primary PE, protector}. In the forwarding plane, the label space is indicated by the bypass tunnel(s) destined for the context identifier.4.7.1. Co-located Protector Model
In Figure 11, PE4 is a co-located protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, PE4}. It learns PW1's label from PE2 and installs a forwarding entry for the label in that label space. The next hop of the forwarding entry indicates a label pop with an outgoing interface pointing to the backup AC PE4-CE2.
|<-------------- PW1 --------------->| - PE1 -------------- P1 ------- P3 ----- PE2 ------ / PLR \ PLR \ / \ | \ / \ | \ CE1 bypass P4 P5 bypass CE2 \ \ | / \ \ | / \ \ | / - PE3 -------------- P2 ---------------- PE4 ------ protector |<-------------- PW2 --------------->| PW1's label assigned by PE2: 100 PW2's label assigned by PE4: 200 On P3: </t> Incoming label of transport tunnel to PE2: 1000 Outgoing label of transport tunnel to PE2: implicit null Outgoing label of bypass tunnel to PE4: 2000 On PE2: Outgoing label of bypass tunnel to PE4: 3000 On PE4: Context label (incoming label of bypass tunnels): 999 Forwarding state on P3: label 1000 -- primary next hop: pop, to PE2 backup next hop: swap 2000, to P4 Forwarding state on PE2: label 100 -- primary next hop: pop, to CE2 backup next hop: push 3000, to P5 Forwarding state on P4: label 2000 -- next hop: swap 999, to PE4 Forwarding state on P5: label 3000 -- next hop: swap 999, to PE4 Forwarding state on PE4: label 200 -- next hop: pop, to CE2 label 999 -- next hop: label table of PE2's label space Label table of PE2's label space on PE4: label 100 -- next hop: pop, to CE2 Figure 11
In Figure 12, SPE2 is a co-located protector that protects PW1 against S-PE failure. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, SPE2}. It learns SEG1's label from SPE1 and installs a forwarding entry in the label space. The next hop of the forwarding entry indicates a label swap to SEG4's label and a label push with the label of a transport tunnel to TPE4.
|<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P1 ----- SPE1 --- P3 ------- TPE2 - / PLR \ \ / \ \ CE1 bypass P2 CE2 \ \ / \ \ / - TPE3 --------------- SPE2 --- P4 ------- TPE4 - protector |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| SEG1's label assigned by SPE1: 100 SEG2's label assigned by TPE2: 200 SEG3's label assigned by SPE2: 300 SEG4's label assigned by TPE4: 400 On P1: Incoming label of transport tunnel to SPE1: 1000 Outgoing label of transport tunnel to SPE1: implicit null Outgoing label of bypass tunnel to SPE2: 2000 On SPE1: Outgoing label of transport tunnel to TPE2: 3000 On SPE2: Outgoing label of transport tunnel to TPE4: 4000 Context label (incoming label of bypass tunnel): 999 Forwarding state on P1: label 1000 -- primary next hop: pop, to SPE1 backup next hop: swap 2000, to P2 Forwarding state on SPE1: label 100 -- next hop: swap 200, push 3000, to P3 Forwarding state on P2: label 2000 -- next hop: swap 999, to SPE2 Forwarding state on SPE2: label 300 -- next hop: swap 400, push 4000, to P4 label 999 -- next hop: label table of SPE1's label space Label table of SPE1's label space on SPE2: label 100 -- next hop: swap 400, push 4000, to P4 Figure 12
4.7.2. Centralized Protector Model
In the centralized protector model, for each primary PW of which the protector is not a backup (S-)PE, the protector MUST also learn the label of the backup PW from the backup (S-)PE (Section 6.3). This is the backup (S-)PE that the protector will forward traffic to. The protector MUST install a forwarding entry with a label swap from the primary PW's label to the backup PW's label and a label push with the label of a transport tunnel to the backup (S-)PE. In Figure 13, the protector is a centralized protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, protector}. It learns PW1's label from PE2 and PW2's label from PE4. It installs a forwarding entry for PW1's label in the label space. The next hop of the forwarding entry indicates a label swap to PW2's label and a label push with the label of a transport tunnel to PE4. |<-------------- PW1 --------------->| - PE1 ------------- P1 ------- P3 ------ PE2 ---- / PLR \ PLR \ / \ / \ / bypass P5 P6 bypass \ / \ / \ / \/ \ CE1 protector CE2 \ \ / \ transport \ / \ tunnel P7 / \ \ / \ \ / - PE3 ------------- P2 ----------------- PE4 ---- |<-------------- PW2 --------------->| PW1's label assigned by PE2: 100 PW2's label assigned by PE4: 200 On P3: Incoming label of transport tunnel to PE2: 1000 Outgoing label of transport tunnel to PE2: implicit null Outgoing label of bypass tunnel to protector: 2000 On PE2: Outgoing label of bypass tunnel to protector: 3000 On protector: Context label (incoming label of bypass tunnels): 999 Outgoing label of transport tunnel to PE4: 4000
Forwarding state on P3: label 1000 -- primary next hop: pop, to PE2 backup next hop: swap 2000, to P5 Forwarding state on PE2: label 100 -- primary next hop: pop, to CE2 backup next hop: push 3000, to P6 Forwarding state on P5: label 2000 -- next hop: swap 999, to protector Forwarding state on P6: label 3000 -- next hop: swap 999, to protector Forwarding state on P7: label 4000 -- next hop: pop, to PE4 Forwarding state on PE4: label 200 -- next hop: pop, to CE2 Forwarding state on protector: label 999 -- next hop: label table of PE2's label space Label table of PE2's label space on protector: label 100 -- next hop: swap 200, push 4000, to P7 Figure 13 In Figure 14, the protector is a centralized protector that protects the PW segment SEG1 of PW1 against the node failure of SPE1. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, protector}. It learns SEG1's label from SPE1 and SEG3's label from SPE2. It installs a forwarding entry for SEG1's label in the label space. The next hop of the forwarding entry indicates a label swap to SEG3's label and a label push with the label of a transport tunnel to TPE4.
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 --- P2 -------- TPE2 -
/ PLR \ \
/ \ \
/ bypass P4 \
/ \ \
/ \ \
CE1 protector CE2
\ \ /
\ \ /
\ transport P5 /
\ tunnel \ /
\ \ /
- TPE3 -------------- SPE2 --- P3 -------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
SEG1's label assigned by SPE1: 100
SEG2's label assigned by TPE2: 200
SEG3's label assigned by SPE2: 300
SEG4's label assigned by TPE4: 400
On P1:
Incoming label of transport tunnel to SPE1: 1000
Outgoing label of transport tunnel to SPE1: implicit null
Outgoing label of bypass tunnel to protector: 2000
On SPE1:
Outgoing label of transport tunnel to TPE2: 3000
On SPE2:
Outgoing label of transport tunnel to TPE4: 4000
On protector:
Context label (incoming label of bypass tunnel): 999
Outgoing label of transport tunnel to SPE2: 5000
Forwarding state on P1:
label 1000 -- primary next hop: pop, to SPE1
backup next hop: swap 2000, to P4
Forwarding state on SPE1:
label 100 -- next hop: swap 200, push 3000, to P2
Forwarding state on P4:
label 2000 -- next hop: swap 999, to protector
Forwarding state on P5:
label 5000 -- next hop: pop, to SPE2
Forwarding state on SPE2: label 300 -- next hop: swap 400, push 4000, to P3 Forwarding state on protector: label 999 -- next hop: label table of SPE1's label space Label table of SPE1's label space on protector: label 100 -- next hop: swap 300, push 5000, to P5 Figure 14
(page 29 continued on part 2)