MPLS Working Group Katherine Zhao
Internet-Draft Renwei Li
Intended status: Standards Track Huawei Technologies
Expires: January 7, 2013 Christian Jacquenet
France Telecom Orange
July 6, 2012
Fast Reroute Extensions to Receiver-Driven RSVP-TE for Multicast Tunnels
draft-zlj-mpls-mrsvp-te-frr-00.txt
Abstract
This document specifies fast reroute procedures to protect multicast
LSP tunnels built by mRSVP-TE, a receiver-driven extension to RSVP-TE
specified by [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te].
This document is motivated by the observation that the existing FRR
solution specified by [RFC4090] and [RFC4875] for the sender-driven
RSVP-TE is no longer applicable to the receiver-driven RSVP-TE.
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 7, 2013.
Copyright Notice
Copyright (c) 2012 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
Zhao, et al. Expires January 7, 2013 [Page 1]
Internet-Draft mRSVP-TE FRR July 2012
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Zhao, et al. Expires January 7, 2013 [Page 2]
Internet-Draft mRSVP-TE FRR July 2012
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Link Protection and Node Protection with mRSVP-TE . . . . 5
2.2. Primary and Backup LSP . . . . . . . . . . . . . . . . . . 8
2.3. Detour Backup and Facility Backup . . . . . . . . . . . . 8
3. Detour Backup for mRSVP-TE . . . . . . . . . . . . . . . . . . 9
3.1. Link Protection in Detour Backup Mode . . . . . . . . . . 9
3.1.1. Detour LSP Setup Scenario for Link Protection . . . . 9
3.1.2. Label Allocation for Link Protection . . . . . . . . . 10
3.1.3. Link Failure Repair in Detour Mode . . . . . . . . . . 11
3.1.4. Re-convergence after Local Repair . . . . . . . . . . 12
3.2. Node Protection in Detour Backup Mode . . . . . . . . . . 12
3.2.1. Detour LSP Setup for Node Protection . . . . . . . . . 12
3.2.2. Label Allocation and Binding for Node Protection . . . 13
3.2.3. Node Failure Repair in Detour Mode . . . . . . . . . . 14
3.2.4. Re-Convergence after Local Repair . . . . . . . . . . 14
4. Facility Backup for mRSVP-TE . . . . . . . . . . . . . . . . . 14
4.1. Link Protection in Facility Backup Mode . . . . . . . . . 15
4.1.1. Backup LSP Setup for Link Protection . . . . . . . . . 15
4.1.2. Label Allocation for Link Protection . . . . . . . . . 15
4.1.3. Link Failure Repair in Facility Mode . . . . . . . . . 17
4.1.4. Re-Convergence after Local Repair . . . . . . . . . . 18
4.2. Node Protection in Facility Backup Mode . . . . . . . . . 18
4.2.1. Backup LSP setup in Facility Mode . . . . . . . . . . 18
4.2.2. Label Allocation for Node Protection . . . . . . . . . 19
4.2.3. Node Failure Repair and Packet Encapsulation . . . . . 22
4.2.4. Re-convergence after Local Repair . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Manageability Considerations . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Zhao, et al. Expires January 7, 2013 [Page 3]
Internet-Draft mRSVP-TE FRR July 2012
1. Terminology
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 [RFC-
WORDS]. The reader is assumed to be familiar with the terminology in
[RSVP], [RSVP-TE] and [mRSVP-TE].
This document uses same terminologies stated in
[I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te],
[RFC4090],[RFC4875] and other FRR related IETF documents. In
addition, some key notions and terminologies for this document are
explained as follows:
o mLSP, Multicast Label Switched Path, is either a P2MP or MP2MP LSP
consisting of one or more sub-LSPs.
o mRSVP-TE, Multicast Resource Reservation Protocol-Traffic
Engineering, is used to distinguish from the regular sender-driven
RSVP-TE. One major difference between RSVP-TE and mRSVP-TE is
that the tunnel setup is initiated and driven by the data receiver
instead of the data sender. The receiver-driven mRSVP-TE is best
applicable to the setup of multicast LSP tunnels.
o PLR: Point of Local Repair, an LSR that detects a local failure
event and redirects traffic from protected mLSP to a backup mLSP
tunnel which is supposed to locally repair the protected tunnel.
o MP: Merge Point, an LSR that merges the traffic from backup
tunnels with primary LSP at the forwarding engine. In the
receiver-driven RSVP-TE for multicast tunnels, MP is the LSR that
initiates backup mLSP setup taking PLR as the root of backup LSR.
o N: The node to be protected.
o Pn: The node(s) on the backup path for protecting the node N.
o Root: A router where an mLSP is rooted at. Data enters the root
and then is distributed to leaves along the P2MP/MP2MP LSP.
o FRR Domain: A set of links and LSRs cross over a protected sub-LSP
and backup LSP, which is between PLR and MP(s).
2. Introduction
Fast Reroute technology has been well accepted and deployed to
provide millisecond-level protection in case of node/link failures.
Zhao, et al. Expires January 7, 2013 [Page 4]
Internet-Draft mRSVP-TE FRR July 2012
FRR employs some local repair mechanisms to meet the fast reroute
requirements by computing and provisioning backup tunnels in advance
of failure and by redirecting traffic to such backup tunnels as close
to the failure point as possible.
The fast reroute extensions to RSVP-TE are specified in [RFC4090] and
[RFC4875]. Such extensions work well with the sender-driven RSVP-TE,
but they are no longer applicable to the receiver-driven RSVP-TE for
multicast tunnels described in the draft
[I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te].
In the receiver-driven paradigm of mRSVP-TE, the procedure to set up
an LSP tunnel is inverted from that in the sender-driven RSVP-TE, and
thus the backup mLSP setup and failover handling mechanism will have
to be different from what has been specified for the sender-driven
RSVP-TE. From the signaling point of view, the behavior of PLR and
MR are inverted from the sender-driven paradigm of RSVP-TE, the setup
for a backup mLSP is initiated by MP with PLR being taken as the root
of a P2MP/MP2MP tree. The RSVP PATH message is sent from MP towards
PLR with the FAST_REROUT, DETOUR as well as other FRR related objects
conveyed in the PATH message. RSVP RESV message is sent from PLR
towards MP carrying FRR information such as the inner label used to
represent a protected mLSP tunnel, etc.
On the other hand, from the packet forwarding point of view, the
behavior of PLR and MP are not inverted comparing to the sender-
driven RSVP-TE. The traffic switchover and redirecting are still
initiated by PLR, and the data traffic is merged at MP in the same
way as what is specified for the sender-driven RSVP-TE.
This document will describe various FRR protection methods and
behavior changes for the receiver-driven mRSVP-TE, and specify fast-
reroute extensions to the RSVP-TE messages, mechanisms and procedures
specified in the mRSVP-TE draft
[I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te].
2.1. Link Protection and Node Protection with mRSVP-TE
FRR link protection aims to protect a direct link between two LSRs
(Label Switch Routers). An LSR at one end of the link is called PLR
(Point of Local Repair), and the other LSR on the other end of the
link is called MP (Merge Point). A backup LSP whose setup is
originated at MP and terminated at PLR will be established to protect
the primary LSP crossing over the link. The LSR over the backup path
is called Pn. These connected LSRs and links are called an FRR
domain in this document. An example of an FRR domain supporting link
protection is shown in Figure 1.
Zhao, et al. Expires January 7, 2013 [Page 5]
Internet-Draft mRSVP-TE FRR July 2012
Protected
+---------+ Link +--------+
Sender --- | R1(PLR) |------------| R2(MP) | --- Receiver
+---------+ +--------+
* *
* * Backup Tunnel
* *
+---------+
| R3(Pn) |
+---------+
Figure 1: Basic FRR Link Protection
In an FRR domain constructed by mRSVP-TE, MP initiates both the
primary and the backup LSP setup at the signaling control plane, and
merges the traffic from the backup LSP into the primary LSP at the
data forwarding plane. The PLR works with the MP to set up LSP at
the signaling control plane accordingly, and detects link failure and
initiates local repair at the data forwarding plane. In Figure 1, we
use hyphen - to denote a primary tunnel between LSRs; use asteroid *
to denote a backup tunnel. The same symbols will be applied to all
figures throughout the document.
Node protection is a technique used to protect a node N that resides
between PLR and MP over a primary LSP. An example of node protection
is shown at Figure 2.
Protected
Sender Node Receiver
+---------+ +---------+ +--------+
---- | R1(PLR) |-----------| R2(N) |-----------| R3(MP) | ---
+---------+ +---------+ +--------+
* *
* *
* +---------+ +---------+ *
********| R4(Pn1) |******| R5(Pn2) |********
+---------+ +---------+ Backup Tunnel
Figure 2: Basic FRR Node Protection
N (R2) denotes a node being protected over a primary LSP, its
upstream node plays the role of PLR and downstream node plays the
role of MP. Pn denotes a transit node over its backup LSP. Note
that there can be multiple Pn's over a backup tunnel. Pn does not
play a significant role for FRR but works as a regular LSR to receive
and transmit multicast data and signaling messages over backup LSPs.
Zhao, et al. Expires January 7, 2013 [Page 6]
Internet-Draft mRSVP-TE FRR July 2012
Besides the basic P2P node protection, mRSVP-TE is more interested on
the P2MP and MP2MP node protection, as shown at Figure 3 and Figure
4. Because the same protection mechanism can be commonly used for
both P2MP and MP2MP, this document uses P2MP as example for the
discussion, and mention MP2MP only if there is a difference from
P2MP.
There are two typical methods to protect a P2MP multicast tree, one
uses a P2MP tree as a backup LSP to protect a primary mLSP (see
Figure 3), and the other uses multiple P2P LSPs to protect a P2MP
mLSP(see Figure 4).
Protected
Sender Node Receiver
+-------+ +-------+ +-------+
-----|R1(PLR)|--------------| R2(N) |-------|R3(MP1)|---- PE1
+-------+ +-------+ +-------+
* \ *
* \ *
* \*
Backup Tunnel *\
* * \
* * \
* +-------+ +-------+ +-------+
****|R4(Pn1)|*******|R5(Pn2)|******|R6(MP2)|---- PE2
+-------+ +-------+ +-------+
Figure 3: P2MP Node Protection in Facility Mode
+---------+ +---------+ Backup Tunnel
********| R4(Pn1) |******| R5(Pn2) |********
* +---------+ +---------+ *
* +--------+
Sender * Protected Node -----| R3(MP) |---- PE
+---------+ +---------+ | +--------+
---- | R1(PLR) |-----------| R2(N) |------|
+---------+ +---------+ | +--------+
* -----| R3(MP) |---- PE
* +--------+ Receiver
* +---------+ +---------+ *
********| R6(Pn3) |******| R7(Pn4) |********
+---------+ +---------+ Backup Tunnel
Figure 4: Multiple P2Ps Protecting a P2MP LSP
Zhao, et al. Expires January 7, 2013 [Page 7]
Internet-Draft mRSVP-TE FRR July 2012
2.2. Primary and Backup LSP
A router that experiences a node/link failure must have pre-
determined which alternate reroute path to protect such a failure.
The alternate backup path should be established before a protected
LSP is broken. Anything such as backup route computation and
configuration required for local repair should be done prior to
failure occurrence so that the failover time can be reduced to
minimum.
On the control plane, the backup LSP will be set up along with its
primary LSP setup. The PATH/RESV refresh messages are transmitted
over both protected and backup LSPs before failover. However on the
data plane, there are two implementation options for traffic
forwarding. One option is that the user traffic does not transmit on
backup LSP tunnel until a failure is detected and the local repair
takes place. The second option is to have user traffic transmitted
on both protected and backup mLSPs before failover, LSR at Merge
Point will drop the packets from backup path before switchover. The
second option can further reduce traffic switchover time but causes
more overhead. This document leaves the flexibility for
implementation to decide which option to choose, but will use the
first option for the discussion, i.e. we assume that the traffic only
transmits on the primary LSP before switchover.
2.3. Detour Backup and Facility Backup
Due to historic reasons and implementation preferences, two
independent methods of doing fast reroute have been developed. One
backup method is called detour backup that is specially designed for
1:1 protection. And the other one is called facility backup that is
specially designed for 1: N protection, where N can be equal to or
more than 1. From the point of view of applications, the facility
backup method can support both 1:N and 1:1, but from the technical
point of view, they are two different methods requiring different
implementations with respect to their label stacks when forwarding
packets.
The detour backup creates a dedicated LSP to protect an LSP and uses
a single MPLS label for packet encapsulation; its implementation is
simpler but consumes more label resources. The facility backup
creates a common LSP to protect a set of LSPs that have similar
backup constraints, this method takes advantage of MPLS label
stacking and uses dual-label encapsulation, thus it can save some
label resources compared to the detour backup method.
These two solutions have co-existed as options for vendors and
service providers to choose. This document will specify both the
Zhao, et al. Expires January 7, 2013 [Page 8]
Internet-Draft mRSVP-TE FRR July 2012
methods. Throughout the document, the detour method is used to
represent 1:1 protection while facility method is used to represent
1: n protection. The term detour LSP is specially used for 1:1
protection while backup LSP is used for 1: N protection, but
sometimes the later one can be used for common cases when no
ambiguity arises.
3. Detour Backup for mRSVP-TE
This section specifies mechanisms and procedures for mRSVP-TE fast
reroute by using the detour backup method. The term detour LSP will
be used to represent the LSP in the detour mode and for one-to-one
protection without special remark.
3.1. Link Protection in Detour Backup Mode
3.1.1. Detour LSP Setup Scenario for Link Protection
A detour LSP setup is initiated by MP along with the setup of the
protected LSP (refer to Figure 1 for the topology), which is one of
the major differences from the procedure stated in [RFC4090] and
[RFC4875]. Following the LSP setup procedure specified by the draft
[I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te], MP sends RSVP
PATH messages towards the sender over a primary path. For the link
protection, MP and PLR are directly connected by the link being
protected, hence the PATH message is sent from MP to PLR directly
upstream.
MP is not necessarily the originator of the primary LSP, but is the
first LSR entering an FRR domain along the primary route, and thus
our discussion for LSP setup starts from MP.
Once the PATH message is sent out, MP will check to see if there is
detour route available for the detour link protection. The detour
route calculation can be done by running CSPF on the link state
database produced by IGP protocols with TE extensions. There is no
change required for backup route computation, and the LSP computation
will be based on this assumption without additional explanation.
If the CSPF stack returns 'no detour route found' after the
calculation, MP stops the detour LSP setup and traverses to the NHOP
over the primary path. It considers NHOP as another MP and starts
the FRR process again. If at least one detour route is found by
CSPF, MP selects the shortest route and initiates the detour LSP
setup. MP considers PLR as the end point of detour LSP and sends a
PATH message towards PLR hop by hop. In the example of Figure 1, the
PATH message will be sent to Pn (R3) and then relayed to PLR (R1).
Zhao, et al. Expires January 7, 2013 [Page 9]
Internet-Draft mRSVP-TE FRR July 2012
PLR replies such a PATH message with a RESV message towards MP
through Pn(s). The transit node Pn(s) just relay the PATH/RESV
messages without any special process required for the link
protection. Detour LSP setup is done once RESV is received and
processed by MP.
3.1.2. Label Allocation for Link Protection
Because the detour method uses a dedicated backup LSP to protect a
primary LSP, one-to-one binding can be made for a pair of primary and
backup LSPs, a single MPLS label encapsulation will be sufficient for
packet forwarding and local failure repair. DLA (downstream label
allocation) can be used as the label assignment method over the
detour tunnel for the link protection. With mRSVP-TE, a downstream
label is assigned by an LSR that is sending PATH message to its
upstream router, and an upstream label is assigned by an LSR that is
sending the RESV message to its downstream router. The label
allocation, however, is more complicated when the primary LSP is a
P2MP or MP2MP tree. A special upstream label allocation and resource
preemption method is introduced and discussed to handle the
protection for P2MP and MP2MP tree structures in a later section.
An example of the label allocation for link protection in the detour
mode is given in Figure 5. For the sake of readability, we use label
Lp to represent the label assigned to the primary tunnel, label Lb
assigned to the backup tunnel. For example, Lp2 represent a
downstream label assigned for LSR R2 to receive incoming data over
the primary tunnel. Lb2 represents a downstream label assigned for
R2 to receive data over a detour LSP.
Lp1->Lp2,MP Lp2->Lp-pe,PE
Lp1->Lb3,Pn Lb2->Lp-pe,PE
Lp1 +---------+ Lp2 +--------+ Lp-pe
Sender --- | R1(PLR) |------------| R2(MP) |-------PE, Receiver
+---------+ Protected +--------+
* Link *
* * Backup Tunnel
Lb3 * * Lb2
+---------+
| R3(Pn) |
+---------+
Lb3->Lb2,MP
Figure 5: Label Allocation for Link Protection in Detour Mode
In the example of Figure 5, MP assigns label Lp2 and sends it to PLR
Zhao, et al. Expires January 7, 2013 [Page 10]
Internet-Draft mRSVP-TE FRR July 2012
via the PATH message over the link {MP-PLR} to set up the primary
LSP. For the detour route {MP-Pn-PLR}, MP assigns a label Lb2 and
sends it to Pn via the PATH message. MP binds label Lp2 with label
Lb2 for this pair of the primary and detour LSPs. An entry
'Lp2->Lp-pe, PE' will be added into MP's FIB for packet forwarding
over the protected LSP. Another entry 'Lb2-> Lp-pe, PE' will be
added and used when traffic is received from the detour tunnel upon
switchover.
Pn (transit node) on the detour tunnel receives Lb2 from MP. Pn
assigns a downstream label Lb3 and sends it to PLR via a PATH
message. Pn will add an entry 'Lb3->Lb2, MP' to its FIB for packet
forwarding. Note that Pn is not aware of the primary traffic so
there is only one forwarding entry needed in its FIB.
PLR receives two PATH messages from MP and Pn respectively. Then it
binds label Lp2 from the primary LSP with label Lb3 from the detour
LSP. The detour LSP ends at PLR while the primary LSP may not end at
PLR if PLR is not the root of the P2MP tree. PLR will allocate a
downstream label Lp1 and sends it to its upstream router, which is
outside of the FRR domain in this example thus not shown at Figure 5.
There will be two entries added into PLR's FIB: one entry 'Lp1->Lp2,
MP' for the primary traffic forwarding, and the another entry
'Lp1->Lb3, Pn' for the detour traffic forwarding upon failover.
PLR processes PATH messages from MP and sends RESV messages towards
MP. If the primary sub-LSP is over a P2MP tree, PLR will not
allocate upstream labels for receiving traffic from the downstream
node (MP or Pn in this example) because the traffic is
unidirectional. If the sub-LSP is over an MP2MP tree, PLR will
allocate an upstream label for receiving traffic from opposite
direction, Pn(s) will repeats the same and allocate upstream label
for MP2MP. Detour LSP setup is completed once MP has received and
processed the RESV message originated by PLR. Figures 5 shows the
summary of labels allocated and FIB entries created on each node in
the FRR domain.
3.1.3. Link Failure Repair in Detour Mode
Link failure can be detected by, for example, BFD (Bidirectional
Forwarding Detection) along the protected LSP. The failure detection
algorithm is the same as what is used for the sender-driven RSVP-TE.
Once a link failure is detected by PLR and all switchover criteria
are met, PLR will redirect the traffic to the detour LSP based on the
forwarding entry 'Lp1->Lb3, Pn'. The entry 'Lp1->Lp2, MP' for
primary path will be deactivated.
Zhao, et al. Expires January 7, 2013 [Page 11]
Internet-Draft mRSVP-TE FRR July 2012
Pn works as a normal label switch router and forward MPLS packet to
MP. MP receives the packet and figures out that the packet is from
the detour path, so the packet will be forwarded to PE based on the
entry 'Lb2->Lp-pe, PE'. The detour traffic is therefore merged back
to the primary LSP towards PE, which completes the link failure
repairing by detouring and merging the traffic.
3.1.4. Re-convergence after Local Repair
Routers outside of the FRR domain are not impacted by the link
failure and local repair for the protection mechanism discussed in
the previous sub-sections. Traffic is transmitted over a detour LSP
after a link failure and local repair. Usually the detour path is
not the shortest path so the network will eventually re-converge and
a new shortest path will be calculated by the MPLS control plane.
Once a new primary path is determined, the traffic is no longer
transmitted through the detour LSP and PLR will be notified to tear
down the detour LSP and clean up its internal stack. PLR will send a
PathTear message to Pn and MP for tearing down the detour LSP and
release backup labels. Re-convergence procedure is the same as the
procedure used for sender-driven RSVP-TE FRR.
3.2. Node Protection in Detour Backup Mode
3.2.1. Detour LSP Setup for Node Protection
The detour LSP setup for the node protection is similar to the link
protection. Take Figure 2 as an example, where the node N being
protected resides between MP and PLR. In this case the two sub-links
{MP-N} and {N-PLR} are also to be protected in conjunction with the
node N protection. It is assumed that the link protection mechanism
given in the previous sub-section is applicable to the sub-link
protection in this situation. Hence this section will focus on the
procedure to handle the node protection. A combined solution for
providing the node protection in conjunction with the link protection
can be derived from the discussions in section 3.1 and this section.
For the node protection shown in Figure 2, MP(R3) sends a PATH
message to N for the primary LSP setup, the primary LSP in the FRR
domain goes through the route {MP-N-PLR}. Once the PATH message is
sent out to N, MP checks to see if there is a detour path available
for node N by using CSPF computation, which would indicate N as a
node to be avoided on the detour path. If no detour route is found,
skip the detour LSP setup. If a detour route is found, MP initiates
the detour LSP setup and consider PLR as the terminator of the detour
LSP. MP sends a PATH message towards PLR over the detour route hop
by hop, in the example of Figure 2, the detour route is in the order
of {MP-Pn2-Pn1-PLR}. Similar to the link protection, PLR sends back
Zhao, et al. Expires January 7, 2013 [Page 12]
Internet-Draft mRSVP-TE FRR July 2012
RESV message towards MP through Pn(s). Transit node Pn(s) just relay
the PATH and RESV messages without special processes required for the
node protection. The detour LSP setup is completed once the RESV
message is received and processed by MP.
Figure 2 shows a case of the basic node protection where N is not a
branch node; it will be more complicated when N is a branch node over
a P2MP / MP2MP tree structure. The mechanism for these cases will be
given later in section 5.2.2.
3.2.2. Label Allocation and Binding for Node Protection
Same as the link protection, the node protection uses the single
label encapsulation and downstream label allocation method in the
detour backup mode. An example of the label allocation for the node
protection is given in Figure 6.
Lp1->Lp2,N Lp3->Lp-pe,PE
Lp1->Lb4,Pn1 Lp2->Lp3,MP Lb3->Lp-pe,PE
Lp1 +---------+ Lp2 +---------+ Lp3 +--------+ Lp-pe
---- | R1(PLR) |---------| R2(N) |--------| R3(MP) |------PE
+---------+ +---------+ +--------+
Sender * * Receiver
* *
* Lb4 +---------+ Lb5 +---------+ Lb3 *
******| R4(Pn1) |******| R5(Pn2) |******
+---------+ +---------+
Lb4->Lb5,Pn1 Lb5->Lb3,MP
Figure 6: Node Protection in Detour Mode
MP (R3) assigns a label Lp3 for the primary LSP and sends it to node
N via a PATH message over the protected route {MP-N-PLR}, N will
allocate a downstream label Lp2 and sends it to PLR via a PATH
message. MP also assigns a label Lb3 for the detour LSP and sends it
to Pn2 via a PATH message over the detour route {MP-Pn2-Pn1-PLR}. MP
binds label Lp3 with label Lb3 for this pair of primary and backup
LSP. An entry 'Lp3->Lp-pe, PE' will be added to MP's FIB for primary
packet forwarding over the protected LSP. Another entry 'Lb3->Lp-pe,
PE' will be kept in the FIB and used when a failover takes place and
traffic is redirected to the detour LSP.
There could be multiple transit nodes Pn(s) along the detour LSP,
each of which will allocate a downstream label and sends it to its
upstream router. Eventually PLR receives the PATH message from the
Zhao, et al. Expires January 7, 2013 [Page 13]
Internet-Draft mRSVP-TE FRR July 2012
protected node N and the transit node Pn1 in this example. PLR binds
primary label Lp2 with the detour label Lb4, and adds two entries
into its FIB: One entry 'Lp1->Lp3, N' for the primary traffic
forwarding, and another entry 'Lp1->Lb4, Pn1' for the detour traffic
forwarding. The allocated labels and FIB entries in the FRR domain
can be found in Figure 6.
3.2.3. Node Failure Repair in Detour Mode
Once the node N failure is detected by PLR, it will redirect the
traffic from the primary LSP to its detour LSP based on the binding
and forwarding entry 'Lp1->Lb4, Pn1'. The data packet is forwarded
through LSR->Pn1-Pn2->MP. Eventually MP will receive the packet from
the detour path. Consulting its FIB forwarding entry 'Lb3->Lp-pe,
PE', the data packet will be forwarded to PE, therefore the detoured
traffic gets merged into the primary path.
The local repair mechanism for the node protection is the same as the
link protection in the detour mode except that there are two links
{MP-N} and {N-PLR} to be protected in conjunction with the node N
protection. The FRR domain must be configured so that both the link
failure detection and node failure detection methods are specified.
For example, BFD may be used for this purpose and are configured as
follows:
o BFD1 between MP and N;
o BFD2 between N and PLR;
o BFD3 between PLR and MP;
PLR and MP can apply either link repair or node repair or both
depending on the results of BFD detection.
3.2.4. Re-Convergence after Local Repair
After a node failure takes place, the network topology will change.
And therefore the network will eventually re-converge and a new best
path will be found the primary LSP. PLR will be notified as soon as
the new primary path is signaled and set up. PLR will send
notification message to Pn1 and MP for tearing down the detour LSP
and withdraw backup labels.
4. Facility Backup for mRSVP-TE
This section specifies mechanisms and procedures for mRSVP-TE fast
reroute by using the facility backup method. The term backup LSP
Zhao, et al. Expires January 7, 2013 [Page 14]
Internet-Draft mRSVP-TE FRR July 2012
will be used to represent the LSP in the facility mode for 1: N
protection without any special remark. Note that the term 'detour
LSP' is no longer used in this section for the Facility backup.
The backup LSP differs from the detour LSP in that one single backup
LSP is used to protect multiple primary LSPs. General speaking, two
labels will be used for the backup LSP with the inner label being
used to indicate which primary LSP is being protected.
4.1. Link Protection in Facility Backup Mode
4.1.1. Backup LSP Setup for Link Protection
Same as in the detour LSP setup, MP sends a RSVP PATH message towards
PLR over the primary route. Once the PATH message is sent out, MP
will execute the backup LSP procedures in the following steps:
o Check if there has been a backup LSP created to protect the link
between PLR and MP. If a backup LSP is found, skip the further
process at MP, e.g. does not send a PATH message over the backup
route for LSP setup. However it does not mean that no process is
needed for the link protection. Later on PLR will allocate an
inner label for each newly created primary LSP and send it to
Pn(s) and MP via the RESV message. The details for label
allocation and packet encapsulation will be discussed in the next
section 4.1.2.
o If there is no existing backup LSP available, MP initiates the
backup LSP setup: MP calculates a backup route by using CSPF by
taking PLR as the endpoint of the back LSP and sends a PATH
message towards PLR hop by hop over the backup route. In the
example of Figure 1, PATH will be sent from MP to Pn (R3) and
relayed to PLR (R1). PLR will then send MP a RESV message to
complete the backup LSP setup. The next sub-section will specify
the details about the label allocation and binding.
4.1.2. Label Allocation for Link Protection
As a backup LSP protects one or more primary LSPs, Facility
Protection uses dual-label for packet forwarding, in which the outer
label is used for regular packet forwarding hop by hop over the
backup LSP while the inner label is used to represent a primary LSP
and used by MP to merge the backup traffic to its corresponding
primary LSP. Multiple primary LSPs will share the common outer label
while the inner label is unique for each protected LSP. Figure 7
below shows how dual-label stack is assigned and used for the
facility backup. There are two primary LSPs to be protected by a
common backup LSP in this example.
Zhao, et al. Expires January 7, 2013 [Page 15]
Internet-Draft mRSVP-TE FRR July 2012
in PLR FIB in MP FIB
LSP1-Entry Lp11->Lp12,MP Lp12->Lp-pe1,PE1
FRR:Lp12,Lp11->Lb3,Pn FRR:Lp12,Lb2->Lp-pe1,PE1
LSP2-Entry Lp21->Lp22,MP Lp22->Lp-pe2,PE2
FRR:Lp22,Lp21->Lb3,Pn FRR:Lp22,Lb2->Lp-pe2,PE2
LSP1-Lbl Lp11 Lp12 Lp-pe1
LSP2-Lbl Lp21+---------+ Lp22 +--------+ Lp-pe2
-------| R1(PLR) |------------| R2(MP) |-------PE1,Receiver
Sender +---------+ Protected +--------+-------PE2,Receiver
* Link *
* * Backup Tunnel
Lb3 * * Lb2
+---------+
| R3(Pn) |
+---------+
FRR:Lp12,Lb3->Lb2,MP
FRR:Lp22,Lb3->Lb2,MP
Figure 7: Label Allocation for Link Protection in Facility Mode
Assume that the primary LSP1 is created first, MP assigns a
downstream label Lp12 for LSP1 being protected and sends the label to
PLR via a PATH message over route {MP-PLR}. Because the primary LSP1
is the first LSP created over this route, MP also assigns a
downstream label Lb2 for the backup LSP and sends it to Pn via a PATH
message over the backup route {MP-Pn-PLR}. Pn allocates a downstream
label Lb3 and sends it to PLR via a PATH message.
Once PATH messages are received from MP and Pn respectively, PLR will
allocate an inner label to represent the primary LSP1 for the backup
LSP. The method to allocate the inner label is up to implementation.
In this example, label Lp12 is used as the inner label to represent
primary LSP1 over the backup LSP. LSR at merge point uses the inner
label to locate the corresponding primary LSP. The inner label is
propagated from PLR to MP by a RESV message. Note that PLR and MP
are the LSRs that actually see, use or process the inner label, while
other transit node Pns do not process the inner label.
The process for the second or more primary LSPs protected by the same
backup LSP is different from that for the first one. MP does not
allocate any new downstream label for the backup LSP since the backup
LSP for the first primary LSP is shared between all the primary LSPs
protected by the same backup LSP. But the PLR is required to
allocate an inner label for each newly created primary LSP and sends
it to MP hop by hop via a RESV message.
Zhao, et al. Expires January 7, 2013 [Page 16]
Internet-Draft mRSVP-TE FRR July 2012
We use Figure 7 as an example to show the packet forwarding FIB entry
by using the following format:
FRR:(inner label),(incoming outer label)->(outgoing outer label),NHOP
When MP allocates the downstream label Lp12 for the primary LSP1, an
entry 'Lp12->Lp-pe1, PE1' is added into MP's FIB. Another FRR entry
'FRR: Lg12, Lb2->Lp-pe1, PE1' is added when MP receives a RESV
message that carries an inner label Lg12 and binding information with
LSP1. So the MP will have two forwarding entries for each protected
LSP. In this example MP will have four entries in FIB for the two
protected paths LSP1 and LSP2:
Lp12->Lp-pe1, PE1
Lp22->Lp-pe2, PE2
FRR: Lp12, Lb2 -> Lp-pe1, PE1
FRR: Lp22, Lb2 -> Lp-pe2, PE2
PLR creates a forwarding entry for a primary LSP whenever it receives
a PATH message for the setup of a new primary LSP. For each primary
path LSP1, once PLR receives the PATH message from the backup route,
PLR allocates an inner label for the primary LSP and creates an FRR
entry in FIB. PLR FIB will have these entries for the two protected
LSP LSP1 and LSP2:
Lp11 ->Lp12, MP
Lp21->Lp22, MP
FRR: Lp12, Lp11 -> Lb3, MP
FRR: Lp22, Lp21 -> Lb3, MP
Note that the transit routers Pn uses the outer label for packet
forwarding and keeps the inner label untouched.
4.1.3. Link Failure Repair in Facility Mode
Before a link failure is detected, PLR encapsulates user packets with
a single label Lp1 and forwards the packet to MP. MP also uses a
single label encapsulation and forwards the packet to PE.
After a link failure is detected, PLR, for example, R1 in Figure 7,
will encapsulate user packets with dual-label stack with outer label
Lb2 used for packet forwarding in the backup path and inner label Lp2
Zhao, et al. Expires January 7, 2013 [Page 17]
Internet-Draft mRSVP-TE FRR July 2012
used to map to the corresponding primary LSP. MP will pop out outer
label Lb2 if needed, swap inner label Lp12 with Lp-pe1, and then
forward the packet to PE1.
4.1.4. Re-Convergence after Local Repair
After a link failure occurs, the network will reconverge. PLR will
be notified as soon as a new best path for the primary LSP will be
found and activated. Then PLR will tear down the backup LSP, release
backup labels and clean up entries in the FIB.
4.2. Node Protection in Facility Backup Mode
4.2.1. Backup LSP setup in Facility Mode
Two methods for node protection in facility mode have been
illustrated in Figure 3 and Figure 4. The method shown in Fig 3 uses
a P2MP or MP2MP backup LSP to protect a branch node N; the method
shown in Fig 4 uses multiple LSPs to protect the node N. It is seen
that the first method can reduce the traffic replication on the
backup LSP; the second method suffers from traffic overhead because
multiple backup sub-LSPs are used. Which method to use is an
implementation option. In this document we will use the method shown
in Fig 3 to describe the node protection mechanism in the facility
mode.
Some special processes are needed for the P2MP or MP2MP tree setup
and label allocation. Assume that LSR PE1 joins a primary P2MP tree
structure in the example of Fig 3. PE1 sends a RSVP PATH message to
MP1 for LSP setting up, this PATH message will be relayed to PLR
through node N being protected. MP1 calculates the backup route with
a constraint to avoid the node N; it initiates the backup LSP setup
by sending a PATH message over the backup path {MP1-Pn2-Pn1-PLR}.
RSVP RESV messages will be replied by PLR to MP1 through the primary
route {PLR-N-MP1} and the backup route {PLR-Pn1-Pn2-MP1}
respectively.
Later on, another LSR PE2 joins the P2MP tree by sending a PATH
message to MP2. MP2 will relay the PATH message to the node N being
protected. Now N becomes a branch node and the PATH message sending
to PLR can be suppressed. MP2 performs the same procedure as MP1 did
for the first branch {PE1-MP1-N}, a backup route {MP2-Pn2-Pn1-PLR}
will be found by CSPF calculation, the node Pn2 now becomes a branch
node crossing over the backup P2MP tree. The PATH message supose to
send from Pn2 to PLR can be suppressed by the branch node Pn2. RSVP
RESV messages will be replied by PLR to MP2 through the primary route
{PLR-N-MP2} and the backup route {PLR-Pn1-Pn2-MP2} respectively.
Zhao, et al. Expires January 7, 2013 [Page 18]
Internet-Draft mRSVP-TE FRR July 2012
Whenever the second or more primary LSP(s) are added going through
the same node N and PLR, all these primary LSPs can be protected by
the single backup LSP. The procedure to setup the primary LSP is the
same as what is used for the first primary LSP setup, the key
technique is to allocate unique identifier of a primary LSP and bind
it with the backup LSP, the mechanism will be discussed in the next
sub-section.
4.2.2. Label Allocation for Node Protection
In order to achieve 1:n protection in Facility mode, a unique
identifier must be assigned to represent each primary LSP being
protected. This identifier should be advertized to all LSRs in a FRR
domain and used for traffic switchover in case of node N failure.
There are many ways to assign and use the identifier, this document
gives an sample mechanism about how to use ULA (upstream label
allocation) to assign a MPLS label and apply it as the identifier of
a primary LPS. Figure 8 gives an example of label allocation and FIB
entry creation for the node protection in Facility mode.
Entry in PLR: Entry in N: Entry in MP1:
Lp1->Lpu,N Lpu->Lpu,MP1 Lpu->Lp-pe1,PE1
FRR:Lpu,Lp1->Lb4,Pn1 Lpu->Lpu,MP2 FRR:Lpu,Lbu->Lp-pe1
Lp1 +-------+ Lpu +-------+ Lpu +-------+ Lp-pe1
-----|R1(PLR)|--------------| R2(N) |-------|R3(MP1)|------- PE1
+-------+ +-------+ +-------+
Sender * Protected \ * Receiver
* Node \ *
* Backup \*
* Tunnel *\
* Lbu * \Lpu
* * \
Lb4 * +-------+ Lb5 +-------+ Lbu +-------+ Lp-pe2
****|R4(Pn1)|*******|R5(Pn2)|******|R6(MP2)|-------- PE2
+-------+ +-------+ +-------+
Entry in Pn1
FRR:Lpu,Lb4->Lb5,Pn1
Entry in Pn2:
FRR:Lpu,Lb5->Lbu,MP1
FRR:Lpu,Lb5->Lbu,MP2
Entry in MP2:
Lpu->Lp-pe2,PE2
FRR:Lpu,Lbu->Lp-pe2,PE2
Figure 8: Label Allocation for P2MP Node Protection in Facility Mode
In the FRR domain of Figure 8, an identical label Lpu is assigned to
Zhao, et al. Expires January 7, 2013 [Page 19]
Internet-Draft mRSVP-TE FRR July 2012
these sub-LSPs over the primary LSP: {PLR-N}, {N-MP1} and {N-MP2}.
Lpu can be allocated by the branch node N for the primary LSP and
used as the identifier of the primary LSP. If there are multiple
primary LSPs crossover the same node N and to be protected by the
single backup LSP, there will be multiple Lpu labels assigned for
each of the primary LSP accordingly. In order to guarantee the
uniqueness of Lpu in node N and MPs, the LSRs are required to have
ULA capability in FRR domain. In addition an algorithm for ULA
assignment and negotiation among the LSRs will need to be further
specified by the later IETF draft.
During normal operation, PLR encapsulates sender`s packet with the
label Lpu and forwards the packet to the node N over the primary LSP.
The node N as a branch node will replicate the traffic to MP1 and MP2
using label Lpu in this example. When a node failure is detected PLR
will redirect the traffic to the backup LSP, and the dual-label stack
will be used for packet encapsulation over the backup LSP, where the
inner label is Lpu to represent a primary LSP; the outer label is
allocated by MP and Pn(s) using DLA (downstream label allocation),
which is used for packet forwarding over backup LSP via regular
RSVP-TE mechanism.
Detailed label allocation on each LSR is described at below.
1. Label Allocation and FRR Entry on MP1 and MP2:
For the first primary LSP setup, MP1 assigns a downstream label Lpdla
for the primary LSP and sends it to the protected node N via PATH
message. The node N discards Lpdla and uses ULA to assign a new
label Lpu that will be used as a downstream label for N to send
packet to MP1.
Node N sends the label Lpu to MP1 via RESV message; MP1 replaces its
downstream assigned label Lpdla with Lpu. If Lpu has been used by
other tunnel on the LSR, MP1 will request the node N to reassign the
Lpu. In case of conflict an ULA negotiation procedure bas to be
executed (this procedure is TBD).
MP1 too assigns a downstream label Lbdla for the backup LSP and sends
it to Pn2 via PATH message over the backup route {MP1-Pn2-Pn1-PLR}.
Pn2 is a branch node so it will perform the same procedure as the
branch node N on the primary LSP. Pn2 discards the label Lbdla
received from the PATH message, assigns a new label Lbu and sends it
to MP1 via RESV message.
Once a RESV message is originated by PLR and sent through the backup
route, MP1 will get an inner label Lpu that represents the primary
LSP in this example. MP1 adds FRR entry with both inner and outer
Zhao, et al. Expires January 7, 2013 [Page 20]
Internet-Draft mRSVP-TE FRR July 2012
label. MP1 FIB will have two forwarding entries for the LSP being
protected in Facility mode:
Lpu->Lp-pe1, PE1
FRR: Lpu, Lbu->Lp-pe2, PE2
With the same process, MP2 will have two forwarding entries for the
LSP being protected:
Lpu->Lp-pe2, PE2
FRR: Lpu, Lbu->Lp-pe2, PE2
2. Label Allocation and FRR Entry on Pn2 and Pn1:
As mentioned in the last paragraph, when Pn2 (transit branch node)
receives PATH message from MP1 and MP2 respectively, it will allocate
label Lbu and sends to each MP. Pn2 will have two forwarding entries
for the LSP being protected:
FRR: Lpu, Lb5->Lbu, MP1
FRR: Lpu, Lb5->Lbu, MP2
Pn1 is a transit node and has only one FRR entry for the LSP being
protected:
FRR: Lpu, Lb4->Lb5, Pn2
3. Label Allocation and FRR Entry on PLR:
PLR receives a PATH message from the node N that carriers a
downstream label Lpu; and a PATH message from Pn1 that carries a
downstream label Lb5. PLR uses Lpu as an inner label for the primary
LSP and sends it to Pn1 towards MPs via RESV message. PLR will have
two entries for a LSP being protected:
Lp1->Lpu, N
FRR: Lpu, Lp1->Lb1, Pn1
For every add-in primary LSP being protected by the same backup LSP,
PLR will assign an inner label and send it to LSRs cross the backup
LSP so that each of LSR can add corresponding FRR entry into FIB and
use them for traffic switchover during local repair.
Zhao, et al. Expires January 7, 2013 [Page 21]
Internet-Draft mRSVP-TE FRR July 2012
4.2.3. Node Failure Repair and Packet Encapsulation
Once protected node N fails and the failure is detected by PLR, it
will initiate a switchover by redirecting the traffic to backup LSP.
Packet encapsulation in each LSR over the backup LSP will be done
based on the FRR entries in its FIB. For example a packet arrived on
PLR suppose to be forwarded to node N by using entry 'Lp1->Lpu, N',
now should be forwarded to Pn1 based on entry 'FRR: Lpu,Lp1->Lb4,
Pn1'. PLR encapsulates the packet with Lpu as inner label, Lb4 as
outer label and forwards it to Pn1. Pn1 will swap outer label for
packet forwarding and keep inner label untouched.
Once the packet reaches MP1, it will pop out the outer label, swap
inner label with outgoing label Lp-pe1 and forward the packet to NHOP
PE1 with a single label Lp-pe1, the packet de-capsulation /
encapsulation is based on the entry 'FRR: Lpu, Lbu->Lp-pe1, PE1'.
The dual label stack packet is terminated at MP1 and the traffic is
merged with the primary path. The same procedure is applicable to
receiver LSR MP2.
4.2.4. Re-convergence after Local Repair
Routers outside of FRR domain are not impacted by the link failure
and local repair. However the network will eventually re-converge
and a new best path to the sender or root will be found by PE1 and
PE2. PLR will be notified as soon as the new primary path is
determined. PLR will send notification message to Pn and MP for
tearing down the detour LSP and withdraw backup labels. There is no
difference between facility and detour method in terms of re-
convergence process.
5. IANA Considerations
TBD.
6. Manageability Considerations
TBD.
7. Security Considerations
TBD.
Zhao, et al. Expires January 7, 2013 [Page 22]
Internet-Draft mRSVP-TE FRR July 2012
8. Acknowledgements
We would like to thank Quintin Zhao, Lin Han, Emily Chen, and Robert
Tao for discussions and comments.
9. References
9.1. Normative References
[I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]
Li, R., Zhao, Q., and C. Jacquenet, "Receiver-Driven
Multicast Traffic Engineered Label Switched Paths",
draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00 (work
in progress), March 2012.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
9.2. Informative References
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
Zhao, et al. Expires January 7, 2013 [Page 23]
Internet-Draft mRSVP-TE FRR July 2012
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003.
Authors' Addresses
Katherine Zhao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: katherine.zhao@huawei.com
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com
Christian Jacquenet
France Telecom Orange
4 rue du Clos Courtel
35512 Cession Sevigne,
France
Email: christian.jacquenet@orange.com
Zhao, et al. Expires January 7, 2013 [Page 24]