MPLS Working Group F. Zhang Internet-Draft F. Yang Intended status: Standards Track L. Jin Expires: September 2, 2010 W. Jiang ZTE Corporation March 1, 2010 RSVP-TE Extentions to Realize Dynamic Binding of Associated Bidirectional LSP draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-00 Abstract This document provides a method to realize dynamic binding control of associated bidirectional LSP, by extending the ASSOCIATION object defined in RFC 4872 and RFC 4873. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 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 Zhang, et al. Expires September 2, 2010 [Page 1] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 (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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Extension to the ASSOCIATION object. . . . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Master/slave mode . . . . . . . . . . . . . . . . . . . . . 6 4.2. Peer mode . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Acknowledgement of the binding . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative references . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Zhang, et al. Expires September 2, 2010 [Page 2] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 1. Introduction According to [RFC5654], the MPLS-TP's control plane MUST support establishing associated bidirectional P2P LSP. Furthermore, this requirement is elaborated as follows, and repeated in [tp-cp-framework]: 10 All nodes on the path of a co-routed bidirectional transport path in the same (sub)layer as the path MUST be aware of the pairing relationship of the forward and the backward directions of the transport path. 11 The end points of an associated bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service. 12 Nodes on the path of an associated bidirectional transport path where both the forward and backward directions transit the same node in the same (sub)layer as the path SHOULD be aware of the pairing relationship of the forward and the backward directions of the transport path. Although the co-routed bidirectional LSP always exists in transport networks, but the forward and backward paths are signalled/routed independently in IP/MPLS networks. In this situation, the association is useful for protection switching, for OAM that requires a reply (from MIP or MEP), and for defect correlation. The ASSOCIATION object, as defined in [RFC4872] and [RFC4873] respectively, is used to provide end-to-end and segment recovery. This document extends the ASSOCIATION object to realize dynamic binding control of associated bidirectional LSP. 2. Conventions used in this document 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. 3. Extension to the ASSOCIATION object. The ASSOCIATION object is used to associate LSPs with each other. The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format: Zhang, et al. Expires September 2, 2010 [Page 3] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IPv4 ASSOCIATION object The IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 2) has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 ASSOCIATION object Now, the following values of the Association Type have been defined. Value Type ----- ---- 0 Reserved 1 Recovery (R) 2 Resource sharing In order to bind two reverse unidirectional LSPs to be an associated bidirectional LSP, this document defined two new values: Zhang, et al. Expires September 2, 2010 [Page 4] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 Value Type ----- ---- 3 Association (master/slave mode) 4 Association (peer mode) Just likes the other two types, these newly defined Association Types are only carried in PATH messages also, such identification only takes place based on PATH state. An ASSOCIATION object with an Association Type set to the value "Association" is used to bind two reverse unidirectional LSP to be an associated bidirectional LSP. Any node originating a LSP need to be bound MUST insert an ASSOCIATION object with the following setting: The Association Type MUST be set to the value "Association" in the Path message of the LSP. The Association ID MUST be set to be set to a value that uniquely identifies the association of LSPs, this SHOULD be set to the Tunnel ID of the bound LSP (master/slave mode) or the Tunnel ID of the binding LSP (peer mode). The (IPv4/IPv6) Association Source SHOULD be set to the Tunnel Sender Address of the bound LSP (master/slave mode) or the Tunnel Sender Address of the binding LSP (peer mode), MAY be set to the Tunnel End Point Address. Terminating (the same transit) nodes MUST (SHOULD) use received ASSOCIATION object(s) with the Association Type set to the value "Association" to bind the two reverse unidirectional LSPs together. Once included, an ASSOCIATION object with an Association Type "Association" SHOULD NOT be removed from the PATH messages associated with an LSP. Any node processing a PATH message which contains an ASSOCIATION object with an Association type, examines existing LSPs for matching Association Type, Association Source, and Association ID values. If any match is found, then dynamic binding of the two reverse LSPs SHOULD be provided. 4. Operation Consider the following example: Zhang, et al. Expires September 2, 2010 [Page 5] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 A-------D-------B \ / \ / \ / C Figure 3: An Example of Associated Bidirectional LSP Two reverse unidirectional LSPs are established, the forward LSP1 is from A to B over [A,D,B], and the associated backward LSP2 is from B to A over [B,D,C,A]. 4.1. Master/slave mode In this mode, the ingress node sends the PATH message, inserting ASSOCIATION object; and the egress node sets up a backward LSP triggered by the ASSOCIATION object. That is to say, the ingress node can actively setup the forward LSP and trigger the egress node to setup backward LSP. The procedure can be as follows:: (1) Node A sends PATH message of LSP1, inserting the ASSOCIATION object. Association Type is set to Association, Association ID is the Tunnel ID of LSP1, and Association Source is the Tunnel Sender Address, for example, the IP address of Node A. (2) When node D receives the PATH message of LSP1, it needs to check ASSOCIATION object. If it does not know this Association Type, just ignore it and forward it to the next node. Of course, Node D can send PathErr Message indicating that it does not know this Association Type, but this would increase the failed possibility of establishing LSP1. If the Association Type is Association, it indicates that Node D should bind one backward LSP with LSP1 to form an associated bidirectional LSP if it is the same node of these two LSPs. (3)Similarly with node D, when node B receives the PATH message of LSP1, it needs to check ASSOCIATION object also. For node B is the end point of LSP1 with master/slave mode, and it SHOULD be triggered to set up the backward LSP2 to bind it with LSP1. So it sends PATH message of LSP2, inserting the ASSOCIATION object, which has the same value as it is in the PATH message of LSP1. In other words, Association Type is Association, Association ID is Tunnel ID1, Association Source is the IP address of node A. (4) When node D receives the PATH message of LSP2, it checks Zhang, et al. Expires September 2, 2010 [Page 6] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 ASSOCIATION object and finds that it needs to bind LSP2 with another LSP, examining existing LSPs for matching Association Type, Association ID and Association Source. Obviously, LSP1 and LSP2 match with each other, so they will be bound together. (5) For node C, because it is not the same middle node of LSP1 and LSP2, so it can not find matched LSPs, but this does not affect the setting up of the two reverse unidirectional LSPs. (6)Node A behaves the same with node D, except that it is the end point of LSP2. 4.2. Peer mode In this mode, the ingress node sends the PATH message, inserting ASSOCIATION object, indicating to bind which backward LSP with the forward LSP. Then the egress node sets up the corresponding backward LSP with the Tunnel ID carried in the ASSOCIATION object of the forward LSP, and there is no need to insert the ASSOCIATION object in the PATH message of the backward LSP. Ingress/egress and the same transit node compare the Tunnel ID carried in the ASSOCIATION object of the forward LSP and the Tunnel ID of the backward LSP, and bind them together if the two Tunnel IDs are the same. 4.3. Acknowledgement of the binding In the description above, The Ingress node do not know whether the binding of the Egress and the same transit nodes are successful or not. This can be done by putting the ASSOCIATION object in the RESV refresh message of the bound LSP if the binding is successful. 5. IANA Considerations Within the current document, a new Association Type is defined. 6. Security Considerations TBD. 7. Acknowledgement The author would like to thank Xihua, Fu and Bo, Wu for their useful discussion. Zhang, et al. Expires September 2, 2010 [Page 7] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. 8.2. Informative References [tp-cp-framework] Loa, Andersson., Lou, Berger., Luyuan, Fang., and Bitar. Nabil, "MPLS-TP Control Plane Framework", February 2010. Authors' Addresses Fei Zhang ZTE Corporation 4C, RD Building 2, Zijinghua Road Yuhuatai District, Nanjing 210012 P.R.China Phone: +86 025 52877612 Email: zhang.fei3@zte.com.cn Fan Yang ZTE Corporation 3C, RD Building 1, Zijinghua Road Yuhuatai District, Nanjing 210012 P.R.China Phone: +86 025 52872302 Email: yang.fan5@zte.com.cn Zhang, et al. Expires September 2, 2010 [Page 8] Internet-Draft RSVP-TE Extentions of Associated LSP March 2010 LZ Jin ZTE Corporation 889, Bibo Road, Zijinghua Road Pudong District, Shanghai 201203 P.R.China Phone: +86 021 68896273 Email: lizhong.jin@zte.com.cn WL jiang ZTE Corporation 3C, RD Building 1, Zijinghua Road GYuhuatai District, Nanjing 210012 P.R.China Phone: +86 025 52877315 Email: jiang.weilian@zte.com.cn Zhang, et al. Expires September 2, 2010 [Page 9]