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]