| Network Working Group | M. Bhatia |
| Internet-Draft | Alcatel-Lucent |
| Intended status: Standards Track | April 15, 2011 |
| Expires: October 17, 2011 |
Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Bi-directional Label Switched Paths (LSPs)
draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00
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.
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].
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 October 17, 2011.
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.
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.
[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.
[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.
A - B ------- C - D
| |
+- E - F -+
Fig 1: Topology for
link protection
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).
A - B -- C -- D - E
| |
+- F - G -+
Fig 2: Topology for
node 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).
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 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.
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.
The Head-End router originates the bi-directional LSP that needs to be protected. Its 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 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.
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 protection provided. The behavior of the "upstream PLR" remains unchanged for both one-to-one backup and facility backup protection mechanisms as described in [RFC4090]. The subsequent sections thus only explain the behavior of the "downstream PLR" during these two protection modes.
Once the traffic gets switched to the protection path, the "downstream" PLR does not need to inform the HE router about the network failure.
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.
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.
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. 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:
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.
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 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, 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 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.
This document raises no new security concerns.
No requests for IANA at this point of time.
| [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. |
| [I-D.ietf-tictoc-1588overmpls] | Davari, S, Oren, A, Bhatia, M, Roberts, P and L Montini, "Transporting PTP messages (1588) over MPLS Networks", Internet-Draft draft-ietf-tictoc-1588overmpls-02, October 2011. |
| [RFC4090] | Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. |
| [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. |