Internet Engineering Task Force R. Aggarwal Internet-Draft Y. Shen, Ed. Intended status: Standards Track Juniper Networks Expires: January 12, 2012 July 11, 2011 PW Endpoint Fast Failure Protection draft-shen-pwe3-endpoint-fast-protection-00 Abstract This document specifies a mechanism for protecting pseudowires (PW) against egress attachment circuit (AC) failure and egress PE failure. Designed on the basis of multi-homed CE, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed immediately upon a failure. In particular, the router at point of local repair (PLR) can redirect PW traffic to a protector PE via a bypass LSP in the order of tens of milliseconds, achieving fast protection that is comparable to MPLS fast reroute. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 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 Aggarwal & Shen Expires January 12, 2012 [Page 1] Internet-Draft PW Endpoint Fast Failure Protection July 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. Reference Model and Failure Cases . . . . . . . . . . . . . . 3 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6 4.1. Segment and Context Identifier . . . . . . . . . . . . . . 6 4.2. Protector PE and Protection Models . . . . . . . . . . . . 7 4.3. Context Identifier Advertisement by IGP . . . . . . . . . 8 4.4. Forwarding State on Protector PE . . . . . . . . . . . . . 9 4.5. PW Label Distribution from Primary PE to Protector PE . . 10 4.6. PW Label Distribution from Backup PE to Protector PE . . . 12 4.7. PW and Context Identifier Association at Ingress . . . . . 13 4.8. Bypass LSP . . . . . . . . . . . . . . . . . . . . . . . . 13 4.8.1. RSVP-TE Signaled Bypass LSP and Backup LSP . . . . . . 14 4.8.2. LDP Signaled Bypass LSP . . . . . . . . . . . . . . . 14 4.9. CSPF Computation for Path to Context Identifier . . . . . 14 5. Egress Link Failure . . . . . . . . . . . . . . . . . . . . . 15 5.1. Co-located Protector PE . . . . . . . . . . . . . . . . . 15 5.2. Centralized Protector PE . . . . . . . . . . . . . . . . . 16 6. Egress Node Failure . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Aggarwal & Shen Expires January 12, 2012 [Page 2] Internet-Draft PW Endpoint Fast Failure Protection July 2011 1. Introduction This document specifies a fast-protection mechanism for pseudowires (PW) against the following failure cases. a. Egress link failure: Failure of an egress attachment circuit (AC). b. Egress node failure: Failure of an egress PE. The procedures in this document are relevant only when a CE is multi- homed to two or more PEs. They are designed on the basis of MPLS upstream label assignment and context specific label switching [RFC 5331]. Fast-protection refers to the ability to provide local repair upon a failure in the order of tens of milliseconds, which is comparable to MPLS fast-reroute [RFC 4090]. This is achieved by establishing local protection as close to a failure as possible. Compared with the existing global repair mechanisms that rely on control plane convergence, these procedures can provide faster restoration for PW traffic. However, they are intended to complement the global repair mechanisms, rather than replacing them in any way. The procedures are relevant to both LDP PWs and BGP based L2VPN. 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 RFC 2119. 3. Reference Model and Failure Cases This document refers to the following topology to describe the solution and failure cases. Aggarwal & Shen Expires January 12, 2012 [Page 3] Internet-Draft PW Endpoint Fast Failure Protection July 2011 CE1 -- PE3.........PW2.........PE4 -- CE2 \ / \ / \ .........PW1......... / PE1 PE2 / .........PW3......... \ / \ / \ CE3 -- PE5.........PW4.........PE6 -- CE4 Figure 1 The MPLS network consists of PE-routers and P-routers (not shown). It provides emulation of layer-2 services between CE1 and CE2, and between CE3 and CE4. For the purpose of resiliency and fast restoration, each CE is multi-homed to two PEs, and there are two divergent paths between each pair of CEs. o For layer-2 service emulation between CE1 and CE2, the first path uses PW1 established between PE1 and PE2, connecting the AC CE1- PE1 and the AC CE2-PE2; while the second path uses PW2 established between PE3 and PE4, connecting the AC CE1-PE3 and the AC CE2-PE4. o For layer-2 service emulation between CE3 and CE4, the first path uses PW3 established between PE1 and PE2, connecting the AC CE3- PE1 and the AC CE4-PE2; while the second path uses PW4 established between PE5 and PE6, connecting the AC CE3-PE5 and the AC CE4-PE6. At any given time, each CE sends traffic on only one AC and receives traffic on only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CE and its peer CE. The AC used for the CE to receive traffic is determined by the MPLS network. From the perspective of traffic towards a given a CE, the set of associated PWs, PEs and ACs can be viewed to serve primary and backup roles. When the MPLS network is in a stable condition, the PW that is intended for carrying the traffic to the CE is referred to as a primary PW. The PE at the egress endpoint of the primary PW is a primary PE. The AC connecting the CE and the primary PE is a primary AC. All the other PWs that may be used to carry the traffic to the CE in the event of a network failure are referred to as backup PWs. The PE at the egress endpoint of a backup PW is a backup PE. The AC connecting the CE and a backup PE is a backup AC. In Figure 1, the following primary and backup roles are assigned to the PWs, PEs and ACs. Aggarwal & Shen Expires January 12, 2012 [Page 4] Internet-Draft PW Endpoint Fast Failure Protection July 2011 o For traffic that CE1 sends to CE2: Primary PW: PW1 Primary PE: PE2 Primary AC: CE2-PE2 Backup PW: PW2 Backup PE: PE4 Backup AC: CE2-PE4 o For traffic that CE2 sends to CE1: Primary PW: PW1 Primary PE: PE1 Primary AC: CE1-PE1 Backup PW: PW2 Backup PE: PE3 Backup AC: CE1-PE3 o For traffic that CE3 sends to CE4: Primary PW: PW3 Primary PE: PE2 Primary AC: CE4-PE2 Backup PW: PW4 Backup PE: PE6 Backup AC: CE4-PE6 o For traffic that CE4 sends to CE3: Primary PW: PW3 Primary PE: PE1 Aggarwal & Shen Expires January 12, 2012 [Page 5] Internet-Draft PW Endpoint Fast Failure Protection July 2011 Primary AC: CE3-PE1 Backup PW: PW4 Backup PE: PE5 Backup AC: CE3-PE5 There are two types of PW endpoint failures, egress link failure and egress node failure. o An egress link failure refers to the failure of a primary AC. In Figure 1, for traffic sent by CE1, an egress link failure is the failure of the AC CE2-PE2. Similarly, for traffic sent by CE2, it is the failure of the AC CE1-PE1. o An egress node failure refers to the node failure of a primary PE. In the above example, for traffic sent by CE1, it is the failure of PE2, and for traffic sent by CE2, it is the failure of PE1. 4. Theory of Operation The fast-protection mechanism in this document relies on local repair to be performed at a PLR (point of local repair) that is as close to a failure as possible. In case of an egress link failure, the PLR is considered as the primary PE that is connected to the failed primary AC. While in case of an egress node failure, the PLR is the node that is the penultimate hop of the transport LSP of the primary PW connecting the ingress PE to the primary PE that failed. In both cases, the PLR MUST redirect traffic (i.e. PW packets) to a "protector PE" (Section 4.2) that is protecting the failed AC or PE. 4.1. Segment and Context Identifier Each multi-homed CE is said to connect to the PEs on a "segment". A segment is the set of ACs, including one primary AC and one or more backup ACs, that a multi-homed CE uses to connect to a primary PE and one or more backup PEs for a given layer-2 service emulation. A CE MAY have multiple segments connected to the same set of primary PE and backup PEs. A given set of primary PE and backup PEs MAY have multiple CEs connected to them on multiple segments. Each segment is assigned with a context identifier on the primary PE. The context identifier is an IP address that is either globally unique or unique in the private address space of the VPN that the segment belongs to. The granularity of a context identifier is Aggarwal & Shen Expires January 12, 2012 [Page 6] Internet-Draft PW Endpoint Fast Failure Protection July 2011 {Primary PE, segment} tuple. However, a given context identifier MAY be assigned to one or multiple segments. For example, a primary PE MAY have a single context identifier for all segments, which is the coarsest granularity of a context identifier. Or, the primary PE MAY have a unique context identifier for each segment, which is the finest granularity of a context identifier. A given context identifier MUST NOT be used by more than one primary PE. In Figure 1, the following segments and context identifiers are assigned for the topology. o CE1 is dual-homed to PE1 (primary PE) and PE3 (backup PE) on segment1 with context1. o CE2 is dual-homed to PE2 (primary PE) and PE4 (backup PE) on segment2 with context2. o CE3 is dual-homed to PE1 (primary PE) and PE5 (backup PE) on segment3 with context3. o CE4 is dual-homed to PE2 (primary PE) and PE6 (backup PE) on segment4 with context4. 4.2. Protector PE and Protection Models A PE that protects one or more segments is referred to as a protector PE. For a given segment, the protector PE MAY be a backup PE on the segment, or an egress PE that is not directly connected to the segment. Hence, there are two protection models based on the location and role of a protector PE. 1. Co-located protector PE In this model, the protector PE is a backup PE on the protected segment. It is co-located with the primary PE on the segment, and it has a direct connection to the CE via a backup AC. In the event of an egress link or node failure, the protector PE receives traffic from the PLR, and sends the traffic directly to the CE via the backup AC. In this model, the coarsest granularity of context identifier assignment is per {primary PE, protector PE}. In Figure 1, PE1 is a primary PE that has two segments, segment1 and segment3. PE3 is the protector PE for segment1, and PE5 is the protector PE for segment3. PE3 and PE5 are directly connected to the respective segments. When segment 1 fails, the Aggarwal & Shen Expires January 12, 2012 [Page 7] Internet-Draft PW Endpoint Fast Failure Protection July 2011 PLR sends traffic to PE3, and PE3 in turn sends the traffic to CE1. Similarly, when segment3 fails, the PLR sends traffic to PE5, and PE5 in turn sends the traffic to CE3. 2. Centralized protector PE In this model, the protector PE is a PE that serves as a centralized protector for multiple or all segments which it MAY or MAY NOT have a direct connection to. In the event of an egress link or node failure, for a directly connected segment, the protector PE receives traffic from the PLR and sends traffic to the CE via a backup AC. For a segment that is not directly connected to, the protector PE MUST send the traffic to a backup PE on that segment, which in turn sends the traffic to the CE via a backup AC. In this model, the coarsest granularity of context identifier assignment is per primary PE. In Figure 1, PE2 is a primary PE that has two segments, segment2 and segment4. Both segments are protected by PE4, which acts as a centralized protector PE. PE4 has a direct connection only to segment2, not to segment4. When segment2 fails, the PLR sends traffic to PE4, and PE4 in turn sends the traffic to CE1. However, when segment4 fails, the PLR sends traffic to PE4, and PE4 MUST send the traffic to PE6 which in turn sends traffic to CE4. A network MAY use either protection model or a combination of both, depending on requirements. 4.3. Context Identifier Advertisement by IGP IGP MUST advertise context identifiers to allow computation of TE paths for bypass LSPs and PW transport LSPs that are destined for context identifiers. The details of these LSPs and the TE path computation will be described later in Section 4.7, Section 4.8, and Section 4.9. A primary PE MUST advertise a context identifier as a stub link. it MUST NOT advertise it in IGP TE. A protector PE MUST also advertise the context identifier as a stub link, but with a metric that is higher than the metric of the stub link advertised by the primary PE. The protector PE MUST NOT advertise the context identifier in IGP TE. Aggarwal & Shen Expires January 12, 2012 [Page 8] Internet-Draft PW Endpoint Fast Failure Protection July 2011 In Figure 1, PE1, i.e. the primary PE, advertises context1 and context3 in IGP as stub links with metric X1 and X2, respectively. Meanwhile, PE3 and PE5, i.e. the protector PEs, also advertise context1 and context3 in IGP as stub links with metric Y1 and Y2, respectively. It is required that metric X1 SHOULD be lower than Y1, and metric X2 be lower than Y2. 4.4. Forwarding State on Protector PE A protector PE MUST learn the forwarding state of all the segments that it protects from the primary PEs, and maintain the forwarding state in context-specific label spaces on a per primary PE basis. In particular, the protector PE MUST learn the labels that the primary PEs have assigned to the primary PWs on the segments, as well as the context identifiers of the segments. For each PW label with an associated context identifier, the protector PE MUST map the context identifier to a context-specific label space [RFC 5331], and program the PW label in that label space in forwarding plane. For a given primary PE, the protector PE MAY maintain state for only a subset of the segments or for all the segments. In the centralized protection model, for each segment that is not directly connected, a protector PE MUST also learn the forwarding state from at least one backup PE of the segment. This is the backup PE that the protector PE will forward traffic to upon a failure of the segment. In particular, the protector PE MUST learn the PW label that the backup PE has assigned to its backup PW. In Figure 1, PE3 is a co-located protector PE protecting segment1 for PE1, i.e. the primary PE. PE3 learns the label that PE1 has assigned for PW1, and context1 that PE1 has assigned to segment1. PE3 maintains the PW label to segment1 binding in the context-specific label space for PE1. This is the context-specific label space that context1 is mapped to. In Figure 1, PE4 is a centralized protector PE protecting both segment2 and segment4 for PE2, i.e. the primary PE. PE4 learns the labels that PE2 has assigned to PW1 and PW3, and context2 and context4 that PE2 has assigned to the segments. PE4 maintains the PW label to segment bindings in the context-specific label space for PE2. This is the context-specific label space that both context2 and context4 are mapped to. Since PE4 does not have a direct connection to segment4, it also learns the label that PE6 has assigned to PW4. When PE4 forwards packets to PE6, it swaps the PW label (assigned by PE2) in the received packets to this PW label. In Figure 1, if context1 is different from context3, PE3 and PE5 have the entire forwarding state of PE1 for context1 and context3 Aggarwal & Shen Expires January 12, 2012 [Page 9] Internet-Draft PW Endpoint Fast Failure Protection July 2011 respectively. In this case, PE3 and PE5 can protect against both egress link and node failures for segment1 and segment3 respectively. However, if context1 and context3 are the same, the centralized protector PE model MUST be adopted, and one of PE3 and PE5 or some other PE MUST act as a centralized protector PE. 4.5. PW Label Distribution from Primary PE to Protector PE A primary PE MUST distribute PW label to segment bindings to the protector PE that protects the segments. These PW labels are considered as upstream assigned labels from the protector PE's perspective. For BGP signaled PWs, distribution of such labels from a primary PE to a protector PE is relatively straightforward, as IBGP updates are received by all PEs, and this provides the protector PE with the necessary information. For LDP signaled PWs, a primary PE MUST establish a targeted LDP session with each protector PE that protects its segments. For each segment, the primary PE MUST advertise a Protection FEC Element via Label Mapping message. The Protection FEC Element is a new LDP FEC, and its encoding is described below. A label is encoded in the message using the Upstream-Assigned Label TLV defined in [LDP- UPSTREAM]. This MUST be the same label that the primary PE has assigned to the PW for the primary AC. The Protection FEC Element and the PW label together represent the primary PE's forwarding state for the segment. The Label Mapping message MUST also carry an IPv4 IF_ID TLV [LDP-UPSTREAM, RFC 3471] with an IPv4 address encoded with the context identifier of the segment. The protector PE that receives this Label Mapping message MUST program a forwarding state for the PW label in the context-specific label space identified by the context identifier. The next-hop of the forwarding state MUST allow sending packets to the CE via a backup AC or to a backup PE. Protection FEC Element The Protection FEC Element has type 0x83, and it is defined as follows: Aggarwal & Shen Expires January 12, 2012 [Page 10] Internet-Draft PW Endpoint Fast Failure Protection July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x83) | Reserved | Encoding Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ PW Information ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - Encoding Type Type of format that the PW Information field is encoded. - Length Length of the PW Information field in octets. - PW Information Field of variable length that specifies a PW of a protected segment. In this document, only Encoding Type 1 is defined to represent the format of PWid FEC Element [RFC 4447]. In this case, a Protection FEC element looks like below. Aggarwal & Shen Expires January 12, 2012 [Page 11] Internet-Draft PW Endpoint Fast Failure Protection July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x83) | Reserved | Enc Type(1) | Length(16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - Ingress PE Address IP address of the ingress PE of the PW. - Group ID An arbitrary 32-bit value that represents a group of PWs that is used to create groups in the PW space. - PW ID A non-zero 32-bit connection ID that, together with the PW type, identifies a particular PW. - Control word bit (C) The bit (C) is used to flag the presence of a control word. If C = 1, control word is present on this PW; If C = 0, no control word is present on this PW. - PW Type A 15-bit quantity containing a value that represents the type of PW. 4.6. PW Label Distribution from Backup PE to Protector PE In the centralized protector PE model, if a protector PE does not have a direct connection to a protected segment, the protector PE MUST learn the PW label to segment binding from a backup PE on that segment. Aggarwal & Shen Expires January 12, 2012 [Page 12] Internet-Draft PW Endpoint Fast Failure Protection July 2011 For BGP signaled PWs, such label distribution from a backup PE to a protector PE can rely on normal IBGP updates, as they are received by all PEs. For LDP signaled PWs, a protector PE MUST establish a targeted LDP session with a backup PE on each segment that the protector PE does not have a direct connection to. The backup PE MUST advertise a Protection FEC Element for the segment via Label Mapping message. The content of this Protection FEC Element MUST be the same as the Protection FEC Element that the primary PE sends to the protector PE (Section 4.5). The Label Mapping message MUST also include a Generic Label TLV encoded with the label that the backup PE has assigned to a backup PW. No context identifier SHOULD be encoded in this message. The Protection FEC Element and the PW label represent the backup PE's forwarding state for the segment. The protector PE that receives this Label Mapping message MUST associate the PW label with the PW label learned from the primary PE, using the common Protection FEC Element. It MUST program a forwarding state with label swap from the primary PE's PW label to the backup PE's PW label, in the context- specific label space indentified by the context identifier. The next-hop of the forwarding state MUST allow sending packets to the backup PE. 4.7. PW and Context Identifier Association at Ingress The ingress PE of a primary PW MUST be able to associate the PW with the primary PE, using a context identifier. This is the context identifier that the primary PE has assigned to the segment that hosts the remote egress AC. For LDP PWs, the above information can be learned by the ingress PE based on configuration. Alternatively, the primary PE can advertise the context identifier in Label Mapping message as a "third party next-hop" using the IPv4 IF_ID TLV [RFC 3471, RFC 3472] by encoding the IPv4 context identifier as an IPv4 IF_ID TLV. The ingress PE MUST also use the context identifier as a destination address to resolve a transport LSP for the PW. If the transport LSP is an RSVP-TE signaled LSP, the ingress PE MUST be able to compute a TE path to the context identifier (Section 4.9). If the transport LSP is an LDP signaled LSP, the primary PE MUST advertises the context identifier as an LDP IPv4 FEC. 4.8. Bypass LSP An LSP MUST be either manually or automatically provisioned on a PLR to enable the PLR to send traffic to a protector PE, in the event of an egress link or node failure. This LSP is referred to as a bypass Aggarwal & Shen Expires January 12, 2012 [Page 13] Internet-Draft PW Endpoint Fast Failure Protection July 2011 LSP. The bypass LSP MUST be a LSP with ultimate hop popping (UHP) [RFC 3031]. That is, the protector PE MUST assign an un-reserved label to the bypass LSP. When the protector PE receives PW packets on the bypass LSP from a PLR, it MUST rely on the bypass LSP's UHP label to determine the context-specific label space to forward the packets. 4.8.1. RSVP-TE Signaled Bypass LSP and Backup LSP If a bypass LSP is an RSVP-TE signaled LSP, its destination MUST be the context identifier of the protected segment. The path taken by the bypass LSP MAY be statically configured or dynamically computed by CSPF (Section 4.9). In case of egress node protection, the signaling of the bypass LSP MUST be triggered by the "local protection desired" and "node protection desired" bits in SESSION_ATTRIBUTE of Path message of the transport LSP [RFC 2205, RFC 3209, RFC 4090]. After the bypass LSP is established, the PLR MUST set the "local protection available" and "node protection" bits in RRO of Resv message of the transport LSP. The PLR MUST also signal a backup LSP [RFC 4090] to the protector PE through the bypass LSP before an egress node failure. The protector PE MUST terminate the backup LSP as an egress. With this pre- signaled backup LSP, the protector PE is ready to process LSP ping and traceroute for the transport LSP immediately after an egress node failure without delay. Once the local repair takes effect, the PLR MUST set the "local protection in use" bit in RRO of Resv message of the transport LSP. 4.8.2. LDP Signaled Bypass LSP If a bypass LSP is a LDP signaled LSP, the LDP FEC for this LSP MUST be the context identifier of the protected segment. 4.9. CSPF Computation for Path to Context Identifier CSPF computation for path to a context identifier MAY be required for an RSVP-TE signaled transport LSP at an ingress (Section 4.7), or for an RSVP-TE signaled bypass LSP at a PLR (Section 4.8.1). For a transport LSP, the mechanism relies on procedures that are similar to how inter-domain RSVP-TE LSPs are computed. The router first checks if the destination, i.e. the context identifier, is reachable in the TE domain. In this case, it is not, as the context identifier is not advertised in IGP TE. The router then checks to see if there is an IGP route to that destination. In this case, there is an IGP route, as the context identifier is advertised by Aggarwal & Shen Expires January 12, 2012 [Page 14] Internet-Draft PW Endpoint Fast Failure Protection July 2011 both the primary PE and the protector PE as a stub link in IGP. The router then selects the PE that is advertising the context identifier with the lowest metric, i.e. the primary PE, and runs CSPF to compute a TE path to it. Finally, the router appends the context identifier as a loose ERO hop to the computed TE path to form a final explicit route. For a bypass LSP, the mechanism is similar to the above, except that it MUST exclude the primary PE when selecting an advertising router of the context identifier. Hence, the protector PE SHOULD be selected. The computed path SHOULD start from the PLR and end at the protector PE, avoiding the primary PE. 5. Egress Link Failure This section summarizes the procedures described in Section 4 for the scenario where only egress link protection is desired. It is assumed that ACs, PWs and transport LSPs have been provisioned. 5.1. Co-located Protector PE A primary PE and a protector PE (i.e. backup PE) both advertise the context identifier of a protected segment in IGP as a stub link, with the primary PE advertising a lower metric than the protector PE. The primary PE (i.e. PLR) establishes a bypass LSP to the protector PE. The destination address of the bypass LSP is the context identifier. If TE path computation is needed for the bypass LSP, the primary PE MUST use the procedure described in Section 4.9. If RSVP is used to signal the bypass LSP, the bypass LSP must be signal with non-PHP bit, as specified in [RSVP-NON-PHP-OOB]. The protector PE learns the PW label to segment binding and the context identifier from the primary PE via targeted LDP or BGP. The protector PE programs forwarding state in a way that packets received on the bypass LSP will be forwarded based on PW label in the context-specific label space of the primary PE that is indicated by the UHP label of the bypass LSP, i.e. the context identifier. When the primary PE receives a PW packet from the MPLS network, if the egress AC is down, the primary PE tunnels the packet through the bypass LSP to the protector PE. The protector PE identifies the forwarding context of the primary PE based on the top label of the packet which is the UHP label of the bypass LSP. The protector PE then forwards the packet based on a second label lookup in the primary PE's context label space. This second label is the PW label that was assigned by the primary PE. This label lookup results in forwarding the packet to the CE via a backup AC. Aggarwal & Shen Expires January 12, 2012 [Page 15] Internet-Draft PW Endpoint Fast Failure Protection July 2011 5.2. Centralized Protector PE The scheme outlined in Section 5.1 requires a bypass LSP for each context identifier where the granularity of a context identifier allocation is {Primary PE, Protector PE}. There may be as many protector PEs as the number of backup PEs. It is desirable to support a scheme where a single protector PE is used to protect all segments, irrespective of whether this protector PE has direct connections to the segments or not. To achieve this, only a single context identifier is assigned by a primary PE to all protected segments. The primary PE then maintains a targeted LDP session with the protector PE to distribute PW labels. For each segment that is not directly connected to the protector PE, at least one backup PE needs to maintain a targeted LDP session with the protector PE to distribute its PW labels. The primary PE and the protector PE both advertise the context identifier in IGP as a stub link, with the primary PE advertising a lower metric than the protector PE. The primary PE (i.e. PLR) establishes a bypass LSP to the protector PE. The destination address of the bypass LSP is the context identifier. If TE path computation is needed for the bypass LSP, the primary PE MUST use the procedure described in Section 4.9. If RSVP is used to signal the bypass LSP, the bypass LSP must be signal with non-PHP bit, as specified in [RSVP-NON-PHP-OOB]. The protector PE learns the PW label to segment binding and the context identifier from the primary PE via targeted LDP or BGP. The protector PE programs forwarding state in a way that packets received on the bypass LSP will be forwarded based on PW label in the context-specific label space of the primary PE that is indicated by the UHP label of the bypass LSP, i.e. the context identifier. When the PLR receives a PW packet from the MPLS network, if the egress AC is down, the PLR tunnels the packet through the bypass LSP to the protector PE. The protector PE identifies forwarding context of the primary PE based on the top label that is the UHP label of the bypass LSP. It then forwards the packet based on a second MPLS label lookup in the primary PE's context label space. This second MPLS label is the PW label that was assigned by the primary PE. If the protector PE has a direct connection to the protected segment, this label lookup results in forwarding the packet to the CE via a backup AC. Otherwise, the protector PE swaps the PW label in the received packet to the PW label assigned by a backup PE, and then forwards the packet to that backup PE. Aggarwal & Shen Expires January 12, 2012 [Page 16] Internet-Draft PW Endpoint Fast Failure Protection July 2011 6. Egress Node Failure For egress node protection, the procedures for co-located protector PE and centralized protector PE are similar to Section 5.1 and Section 5.2 respectively, with a few differences outlined below. o The PLR is the penultimate hop of the transport LSP. When it receives a packet of the transport LSP, if the egress PE is down, it tunnels the PW packet through a bypass LSP to the protector PE. o If the bypass LSP is an RSVP-TE signaled LSP, its establishment MUST be triggered by the node protection signaling of the transport LSP. The PLR MUST also pre-signal a backup LSP through a bypass LSP to the protector PE, before an egress node failure occurs. 7. IANA Considerations IANA maintains a registry of LDP FECs at the registry "Label Distribution Protocol" in the sub-registry called "Forwarding Equivalence Class (FEC) Type Name Space". This document defines a new LDP Protection FEC Element in Section 4.5. IANA has assigned the type value 0x83 to it. 8. Security Considerations The security considerations discussed in RFC 5036, RFC 5331, RFC 3209, and RFC 4090 apply to this document. 9. Acknowledgements This document leverages work done by Hannes Gredler, Yakov Rekhter and several others on LSP tail-end protection. Thanks to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their contribution. 10. References 10.1. Normative References [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. Aggarwal & Shen Expires January 12, 2012 [Page 17] Internet-Draft PW Endpoint Fast Failure Protection July 2011 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Constraint- based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [LDP-UPSTREAM] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for LDP", draft-ietf-mpls-ldp-upstream (work in progress), 2011. [RSVP-NON-PHP-OOB] Ali, A., Swallow, Z., and R. Aggarwal, "Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no-php-oob-mapping (work in progress), 2011. 10.2. Informative References [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Aggarwal & Shen Expires January 12, 2012 [Page 18] Internet-Draft PW Endpoint Fast Failure Protection July 2011 Authors' Addresses Rahul Aggarwal Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089 USA Phone: +1 4089362720 Email: rahul@juniper.net Yimin Shen (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Phone: +1 9785890722 Email: yshen@juniper.net Aggarwal & Shen Expires January 12, 2012 [Page 19]