Network Working Group M. Bhatia
Internet-Draft Alcatel-Lucent
Intended status: Standards Track L. Jin
Expires: November 20, 2011 ZTE
F. Jounay
France Telecom
May 19, 2011
Extensions to Resource Reservation Protocol - Traffic Engineering
(RSVP-TE) for Bi-directional Label Switched Paths (LSPs)
draft-bhatia-mpls-rsvp-te-bidirectional-lsp-01
Abstract
There are several applications that require symmetric Multiprotocol
Label Switching (MPLS) path between two points. This cannot be
achieved with regular MPLS as the LSPs are unidirectional. If
symmetry is required, a separate LSP in each direction is required
for bidirectional traffic flow. Generalized MPLS on the other hand,
has provisions for setting up a bidirectional LSP. This document
uses the extensions introduced for GMPLS and applies it to regular
MPLS for establishing bidirectional LSPs. Additionally, it also
describes how bi-directional symmetrical Fast Reroute using both one-
to-one and facility backup can be achieved.
Requirements Language
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 [RFC2119].
When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in
RFC2119 [RFC2119].
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
Bhatia, et al. Expires November 20, 2011 [Page 1]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
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 November 20, 2011.
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
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.
Bhatia, et al. Expires November 20, 2011 [Page 2]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. RSVP-TE to signal Bi-directional LSP . . . . . . . . . . . . . 4
3. Fast Reroute mechanisms . . . . . . . . . . . . . . . . . . . 5
3.1. Discovering Upstream Labels . . . . . . . . . . . . . . . 6
3.2. Failure detection between PLR and MP . . . . . . . . . . . 7
4. Behavior of various network elements in FRR . . . . . . . . . 7
4.1. The Head-End Router Behavior . . . . . . . . . . . . . . . 7
4.2. The Point of Local Repair (PLR) Behavior . . . . . . . . . 8
4.2.1. PLR Behavior during one-to-one backup for a node
failure . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. PLR Behavior during facility backup for a node
failure . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. The Merge Point (MP) Router Behavior . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Bhatia, et al. Expires November 20, 2011 [Page 3]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
1. Introduction
There are several applications that require symmetrical paths between
a pair of speakers. One such application is 1588 [IEEE-1588] which
requires that the Delay_Resp message takes the same path as the
associated Delay_Req message. [I-D.ietf-tictoc-1588overmpls]
describes a method for transporting PTP messages (PDUs) over an MPLS
network to enable proper handling of these packets. Currently, the
only way to ensure that the different PTP messages follow a
symmetrical path is by statically configuring the RSVP-TE LSPs. This
is unscalable and will not work in case of network failures as MPLS
FRR may not guarantee symmetrical alternate paths.
This document describes how RSVP-TE can be used for setting up bi-
directional LSPs for regular MPLS and the extensions required in FRR
to ensure that the alternate paths are also symmetrical.
2. RSVP-TE to signal Bi-directional LSP
[RFC3473] describes a point-to-point bidirectional LSP mechanism for
the GMPLS architecture, where a bidirectional LSP setup is indicated
by the presence of an Upstream Label in the Path message. The
Upstream_Label object has the same format as the generalized label,
and uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the
label being used.
For regular MPLS the Upstream_Label object will be used with C-Type
value of 1.
Typically, a node initiates an RSVP session by adding the RRO to the
Path message. The initial RRO contains only one subobject - the
sender's IP addresses. If the node also desires label recording, it
sets the Label_Recording flag in the SESSION_ATTRIBUTE object. This
document extends this mechanism by also adding the Upstream label
that has been advertised in the RRO subobject. Thus the initial RRO
will now contain the sender's IP address and the Upstream label
advertised by it. The upstream label subobject in RRO object will be
with type 0x04 and same C-type with label object.
It is necessary to ensure the PLR and MP to bind to the same
bidirectional protection tunnel (bypass tunnel or detour tunnel),
this draft introduces a new subobject in RRO object to indicate the
tunnel that PLR or MP binds.
Bhatia, et al. Expires November 20, 2011 [Page 4]
Internet-Draft RSVP-TE Bidirectional LSP May 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 | Length | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+
Type 0x05 Protection bidirectional tunnel ID
Length The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is always 8.
The tunnel ID and extended tunnel ID is derived from session object,
LSP ID is derived from sender_template object of protection LSP.
3. Fast Reroute mechanisms
[RFC4090] extensions can be used to perform fast reroute for the
mechanism described in this document when applied within packet
networks. This section only applies to LSRs that support [RFC4090].
This section uses terminology defined in [RFC4090], and fast reroute
procedures defined in [RFC4090] MUST be followed unless specified
below. The head-end and transit LSRs MUST follow the
SESSION_ATTRIBUTE and FAST_REROUTE object processing as specified in
[RFC4090] for each Path message.
Since its a bi-directional LSP the detour LSPs and the bypass tunnels
that are used for the protected LSP must also be bi-directional.
This is required so that path symmetry is maintained even in an event
of a network failure.
It should be noted that in case of bi-directional LSPs, the LSRs
involved will play the role of both the Point-of-Local-Repair (PLR)
and Merge Point (MP) at the same time during the failure. The router
that is the PLR will become the MP for the traffic thats coming from
the opposite direction.
In the Figure 1 assume that ABCD is the protected LSP. For
protecting link BC, there is a bidirectional bypass tunnel BEFC (or a
detour LSP in case of 1-on-1). B is the PLR and C is the MP for the
traffic flowing from A towards D and B is the MP, and C the PLR for
traffic flowing in the opposite direction (from D towards A).
Bhatia, et al. Expires November 20, 2011 [Page 5]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
A - B ------- C - D
| |
+- E - F -+
Fig 1: Topology for
link protection
In the Figure 2 ABCDE is the protected LSP and BFGD is the bypass
tunnel for protecting the node C. In this case B is the PLR and D the
MP for traffic from A towards E, and the roles reverse, i.e. B
becomes the MP and D the PLR for traffic flowing in the opposite
direction (from E towards A).
A - B -- C -- D - E
| |
+- F - G -+
Fig 2: Topology for
node protection
3.1. Discovering Upstream Labels
To support facility backup, the PLR must determine a label that will
indicate to the MP that packets received with that label should be
switched along the protected LSP. This can be done without
explicitly signaling the backup path if the MP uses a label space
global to that LSR.
As described in [RFC4090], the head-end LSR MUST set the "label
recording requested" flag in the SESSION_ATTRIBUTE object for LSPs
requesting local protection. This will cause (as specified in
[RFC3209]) all LSRs to record their INBOUND labels and to note via a
flag whether the label is global to the LSR. Thus, when a protected
LSP is first signaled through a PLR, the PLR can examine the RRO in
the Resv message and learn about the incoming labels that are used by
all downstream nodes for this LSP. Similarly the MP, which will
become the PLR for the reverse direction will learn about the
upstream labels that are being used by the upstream nodes for this
LSP by examining the upstream label subobject in RRO in the Path
message.
The bypass tunnels and the detour tunnels that are set up for a
bidirectional LSP must be bidirectional as well. They can internally
use the Upstream_label technique that was described earlier to
establish a bidirectional LSP.
Bhatia, et al. Expires November 20, 2011 [Page 6]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
3.2. Failure detection between PLR and MP
It is required that PLR and MP should detect the failure at the same
time, then the two nodes could switch with traffic to the protection
tunnel (bypass tunnel or detour tunnel) simultaneously. Such kind of
detection mechanism could be BFD [RFC5880], RSVP-TE hello, or other
proper mechanism.
For the link protection scenario, the detection mechanism should be
enabled between PLR and MP. When a failure happens, both PLR and MP
could detect the failure simultaneously, and switch the traffic to
the protection tunnel.
For the node protection scenario, it is required to setup two co-
related detection sessions. For the figure2 topology in section 3,
the PLR node B and MP node D will do the node protection for the
protected tunnel. There will be a detection session1 on the link
between B and C, and session2 between C and D.. When a link failure
happens between B and C, B could detect the failure by the session1,
C should notify the link failure event to D by setting the diagnostic
code to 6 (Concatenated Path Down) in BFD control packet [RFC5880].
Then D could detect failure through BFD control packets in session 2.
An alternative way is to do protected LSP segment detection between
PLR and MP. When the link or node failed, the protected LSP segment
detection session will be down, and both PLR and MP could detect the
failure.
4. Behavior of various network elements in FRR
When a failure happens in the network the PLR router closest to the
failure must perform the traffic protection. The MP router is the
router that is the next hop to the failure point and merges the
protected traffic back to the original path. In case of
bidirectional LSPs, the same LSR is PLR in one direction and the MP
for the other. Let us examine in detail what each network element
does for the MPLS FRR.
4.1. The Head-End Router Behavior
The Head-End router originates the bi-directional LSP that needs to
be protected. It's here that the desired protection type (one-to-one
or facility backup) is also defined.
The Path message which has the FRR information in the
SESSION_ATTRIBUTE object is propagated from the head-end LSR to the
Tail router. Each hop sees the FRR flags and assumes the PLR role
Bhatia, et al. Expires November 20, 2011 [Page 7]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
and tries to establish a bi-directional tunnel. Every hop reports
the availability of the FRR protection if its able to establish a bi-
directional tunnel successfully. This is done via setting the RRO
flags in the Resv message.
When a network failure occurs the PLR, or router upstream of the
failure to be precise, uses FRR to reroute the traffic around the
failure, and notifies the head-end LSR by (i) setting the FRR "Local
protection in use" flag (0x2) in the RRO object of the Resv message
and (ii) by sending a PathErr message with an ERROR object with code
0x19 - RSVP Notify Error and error value 0x3 - Tunnel locally
repaired. The router that is downstream of the failure
(traditionally the MP in case of unidirectional LSPs) also uses FRR
to reroute the traffic around the failure. It does not send any
message to the head-end LSR.
The head-end LSR upon recieving this indication tries to switch the
traffic to a secondary LSP if its available. In case its not active,
the head-end LSR signals this LSP via make-before-break mechanism.
4.2. The Point of Local Repair (PLR) Behavior
The PLR router of the protected LSP is also the origination point
(head-end Router) of the protection tunnel (detour LSP or bypass
tunnel). It is also the MP for the reverse protection tunnel at the
same time. When an intermediate LSR receives a Path message carrying
a SESSION_ATTRIBUTE with the FRR flags set, it assumes the role of a
PLR and starts signaling a bi-directional FRR protection tunnel. In
case facility backup is requested by the head-end LSR, the PLR
signals a new bi-directional tunnel only if a bypass tunnel
fulfilling the requirements does not already exist.
In the sections that follow the terms upstream and downstream are
used in reference to the direction of traffic flow from the head-end
towards the tail end. Thus router the tail router is downstream to
the head-end.
When a network failure happens, the upstream router local to the
failure assumes the role of the PLR and switches the traffic to the
protection tunnel. This PLR is from now on referred to as the
"upstream PLR". The downstream router, local to the failure also
assumes the role of the PLR and switches the traffic to the
bidirectional protection tunnel that is set up. This PLR is referred
to as the "downstream PLR". These routers can use either the bi-
directional detour LSP or a bi-directional bypass tunnel, depending
upon what was requested by the head-end LSR.
The egress label that each PLR uses depends upon the kind of
Bhatia, et al. Expires November 20, 2011 [Page 8]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
protection provided. The subsequent sections only describe the
behavior of the "upstream PLR" that is different with the protection
mechanisms as described in [RFC4090].
Once the traffic gets switched to the protection path, the
"downstream" PLR does not need to inform the HE router about the
network failure.
4.2.1. PLR Behavior during one-to-one backup for a node failure
For the one-to-one backup, MP should bind the backup tunnel to
protected LSP before replying the RESV message of detour LSP. When
the PLR setup the detour LSP and bind to the protected LSP
successfully, that also indicates that MP has bound successfully.
In case of one-to-one backup, the protection or the detour tunnel is
a regular LSP. The downstream PLR uses the label that was
distributed by the immediate upstream router on the detour LSP
(detour label) to detour traffic arriving from the downstream router
of the protected LSP. The label arriving from the immediate
downstream router of the protected tunnel is swapped with the detour
label, and the traffic is sent through the detour LSP.
Head Upstream Downstream Tail
End PLR PLR Router
<-uL1 <-uL2 <-uL3 <- uL4
A ------ B ------ C ------ D --------- E
| |
| | | ^
udL1 | | | | udL2
V | | |
| |
+------- F -------+
Fig 3: one-to-one FRR protection
ABCDE is a bi-directional protected LSP
BFD is a bi-directional detour LSP
The above figure describes this mechanism. udL1 is the Upstream_label
advertised by B when setting up the bi-directional detour LSP from B
to D. Similarly, udL2 is the Upstream_label advertised by F to D,
when setting up this LSP. uL1, uL2, uL3 and uL4 are the
Upstream_labels advertised when setting up the bi-directional
protected tunnel ABCDE.
Bhatia, et al. Expires November 20, 2011 [Page 9]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
When a network failure happens, in this case the LSR router between B
and D fails, the node D will assume the role of a downstream PLR and
would need to switch the traffic from the protected LSP to the detour
LSP. D does this by programming a Swap operation on the egress of
the protected LSP path to the egress of the detour LSP. The uL4
label is thus swapped with udL2 during the failure, instead of label
uL3.
4.2.2. PLR Behavior during facility backup for a node failure
For the facility backup, when the PLR successfully bind the
protection tunnel to the protected LSP, it SHOULD insert the
Protection Tunnel subobject in RRO object in the path message, and
send downstream.
In the case of facility backup, the data from the protected LSP is
tunneled through the bypass tunnel. Therefore, the outer label of
the tunneled packet in the reverse direction is the label distributed
by the immediate upstream router of the bypass tunnel. The
"downstream PLR" also needs to know what label was expected by the
router where this tunneled traffic merges (MP) at the upstream. The
record label option makes this information available from the RRO in
the Path messages for the protected LSP. This is the inner label
that must be in the tunneled packet. Thus, the "downstream PLR"
swaps the incoming label from the immediate downstream router in the
protected path with these two labels and sends the path through the
bypass tunnel.
Head Upstream Downstream Tail
End PLR PLR Router
<-uL1 <-uL2 <-uL3 <- uL4
A ------ B ------ C ------ D --------- E
| |
| | | ^
udL1 | | | | udL2
V | | |
| |
+------- F -------+
Fig 4: Facility backup protection
ABCDE is a bi-directional protected LSP
BFD is a bi-directional bypass tunnel
The above figure describes the topology and the labels exchanged.
Bhatia, et al. Expires November 20, 2011 [Page 10]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
udL1 is the Upstream_label advertised by B when setting up the bi-
directional facility bypass tunnel from B to D. Similarly, udL2 is
the Upstream_label advertised by F to D, when setting up this tunnel.
uL1, uL2, uL3 and uL4 are the Upstream_labels advertised when setting
up the bi-directional protected tunnel ABCDE.
The "downstream" PLR router (D in this case) knows the label (uL2 in
this case) that the upstream NNHop router expects because it has
received a Path message which had this Upstream_label recorded in the
RRO.
When a network failure happens, in this case the LSR router between B
and D fails, the node D will assume the role of a "downstream" PLR
and reroutes the traffic from the protected LSP through the bypass
tunnel as follows:
o PLR D performs a swap operation to change the transport label.
Since it knows that its doing node protection over the bypass
tunnel, it will use the label that the NNHop router ("upstream"
MP) expects instead of the label that the Nhop router (failed LSR)
expects. D thus, swaps out uL4 and replaces it with uL2, instead
of uL3 as it would normally have done.
o D also pushes the label udL2 on top of the label stack. This
label would be used to switch the packet on the bypass tunnel and
would finally reach the MP, which happens to be B in our case.
4.3. The Merge Point (MP) Router Behavior
The MP router is the LSR where the protection tunnel (detour LSP or
bypass tunnel) and the protected LSP meet. It is the termination
point (Tail router) of the protection tunnel. For a bi-directional
protection tunnel the MP router in one direction becomes the PLR in
the other.
Bhatia, et al. Expires November 20, 2011 [Page 11]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
Head Upstream Downstream Tail
End MP MP Router
A ------ B ------ C ------ D --------- E
| |
| |
| |
| |
| |
+------- F -------+
Fig 5: Merge Points in bi-directional FRR
ABCDE is a bi-directional protected LSP
BFD is a bi-directional protection tunnel
Figure 5 shows two MPs associated with a bi-directional protection
tunnel. This document refers to the MP defined in [RFC4090] as a
downstream MP. This document does not change the behavior of the
downstream MP. This means that it is still responsible for
maintaining the protection tunnel's state by sending the Resv
messages to the PLR and is also responsible for maintaining the state
of the protected tunnel during the network failure. The upstream MP,
defined in this document, is not required to do any of these. Its
only responsible for merging the reverse traffic back to the
protected path.
In one-to-one backup, the tail-end of backup LSP should consider it
as MP. When the tail-end receives the Path message, and before
sending RESV, it should try to bind the backup tunnel to protected
tunnel. When binding successfully, MP sends the RESV message
upstream for the backup tunnel.
During one-to-one backup the MP performs a swap operation on the
ingress label of bi-directional detour LSP with the egress label of
the bi-directional protected LSP.
In facility protection, when the LSR receives the Path message with
RRO object, indicating the Previous_Hop or Previous_Previous_Hop with
Protection Tunnel subobject, it should consider itself as MP. And it
SHOULD try to bind the same protection tunnel indicated by Protection
Tunnel subobject to the protected LSP. The protection tunnel would
be expected to be from MP to PLR, with same tunnel-ID and LSP-ID
indicated by the subobject.
During facility protection, the traffic arrives with a bypass tunnel
label. The MP pops out this label to expose the original protected
tunnel label that was distributed to the immediate downstream router
Bhatia, et al. Expires November 20, 2011 [Page 12]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
via the Upstream_label mechanism in the Path message on the protected
tunnel. Since this label is already programmed, the traffic is
switched out correctly.
The Resv message from MP to PLR should be sent in the protection LSP
since there is a LSP path from MP to PLR.
5. Security Considerations
This document raises no new security concerns.
6. IANA Considerations
No requests for IANA at this point of time.
7. References
7.1. Normative References
[IEEE-1588]
"IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[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.
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 5467, March 2009.
7.2. Informative References
[I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Martini, L., Bhatia, M., and P.
Roberts, "Transporting PTP messages (1588) over MPLS
Bhatia, et al. Expires November 20, 2011 [Page 13]
Internet-Draft RSVP-TE Bidirectional LSP May 2011
Networks", draft-ietf-tictoc-1588overmpls-00 (work in
progress), January 2011.
[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.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
Authors' Addresses
Manav Bhatia
Alcatel-Lucent
India
Email: manav.bhatia@alcatel-lucent.com
Lizhong Jin
ZTE
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
Email: frederic.jounay@orange-ftgroup.com
Bhatia, et al. Expires November 20, 2011 [Page 14]