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]