Network working group M. Chen Internet Draft J. Dong Intended status: Standards Track X. Guo Expires: January 2011 Huawei Technologies July 5, 2010 GACH Based Bidirectional LSP Association draft-chen-mpls-tp-bidir-lsp-association-00.txt Abstract This document defines a mechanism to bind two unidirectional LSPs into an associated bidirectional LSP and perform related operations, including update, withdrawal and verification of the association without a control plane. This is achieved using Generic Associated Channel. 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 January 5, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires January 5, 2011 [Page 1] Internet-Draft GACH Based Path Association July 2010 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. 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 RFC-2119 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. GACH based Path Association..................................3 3. Operation....................................................6 3.1. Binding of Two Unidirectional LSPs......................6 3.2. Binding Relationship Verification.......................7 3.3. Binding Update/Withdrawal...............................8 3.4. Association on Intermediate Nodes.......................8 4. Security Considerations......................................9 5. IANA Considerations..........................................9 6. Contributors................................................10 7. Acknowledgments.............................................10 8. References..................................................10 8.1. Normative References...................................10 8.2. Informative References.................................10 Authors' Addresses.............................................11 1. Introduction Based on the definition of associated bidirectional path in MPLS-TP Requirement [RFC5654], an associated bidirectional path comprises a pair of unidirectional paths which are setup, monitored, and protected independently and are associated with one another at the path's ingress/egress points. [RFC5654] specifies the requirements about associated bidirectional paths in requirement 7, 11, 12: MPLS-TP MUST support associated bidirectional point-to-point transport paths, the end points of an Chen, et al. Expires January 5, 2011 [Page 2] Internet-Draft GACH Based Path Association July 2010 associated bidirectional path MUST be aware of the pairing relationship of the forward and reverse paths, and intermediate nodes on the path which are transited by both the forward and backward directions SHOULD be aware of the pairing relationship of the forward and the backward directions of the associated bidirectional path. GMPLS based signaling [RFC4974] [RFC4872] [HIERACHY-BIS] may be used (directly or with some extensions) to achieve the association of two unidirectional LSPs. Since MPLS-TP MUST support the capability for network operation without the use of control plane, a method to bind the forward and backward unidirectional paths into an associated bidirectional path in the absence of control plane may be desired. Normally the binding of two unidirectional paths occurs when there are established unidirectional paths in each direction and an associated bidirectional path is needed to provide some kind of service. After the binding of the two unidirectional paths, there MAY be requirement to verify the binding relationship during the lifetime of the associated bidirectional path. In addition, the operator MAY need to update or withdraw the previous binding of the two unidirectional LSPs. 2. GACH based Path Association This document provides a GACH [RFC5586] based method to achieve the binding of two unidirectional LSPs. A new channel type (TBA) called Path Binding is defined for this purpose. Format of the Path Binding message is as below: Chen, et al. Expires January 5, 2011 [Page 3] Internet-Draft GACH Based Path Association July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ACH TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |U|V| Flags | Return Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type is one of the following: Value Meaning ----- ------- 1 Request 2 Response The Flags field is an 8-bit vector. The U (Update) flag indicates this message is used to update or withdraw previous binding relationship. The V (Verification) flag indicates this message is used to verify the binding relationship. The other undefined flags are set to zero on transmission and ignored on reception. The Return Code is only applicable in Response message, and is set to zero in Request message. The receiver of the Request message uses this field to carry information about the binding result back to the initiator. This document defines some return codes as follows. Additional return codes can be defined if needed. Chen, et al. Expires January 5, 2011 [Page 4] Internet-Draft GACH Based Path Association July 2010 Value Meaning ----- ------- 0 Operation success 1 Malformed message received 2 Binding not accepted 3 Binding inconsistency 4 Update/Withdrawal not accepted The Sequence Number is assigned by the sender of the Request message and returned unchanged by the receiver in the Response message. It can be used to matching up requests with responses. This document defines IPv4/IPv6 Bidirectional LSP ID TLVs. The proposed format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Bi-dir. LSP ID TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Number | Source LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Tunnel Number | Destination LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chen, et al. Expires January 5, 2011 [Page 5] Internet-Draft GACH Based Path Association July 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Bi-dir. LSP ID TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Node ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Number | Source LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination Node ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Tunnel Number | Destination LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The definition of Global ID, Node ID, Tunnel Number and LSP Number are specified in [TP-IDENTIFIER]. They are used to identify the unidirectional LSP in each direction and in combination to identify the associated bidirectional LSP. In order to identify the unidirectional LSP in the reverse direction, a Destination LSP Number field is also needed. The source ID fields, i.e. the Source Global ID, Source Node ID, Source Tunnel Number and Source LSP Number MUST be filled in by the local LER with information of the forward LSP. According to different situations, the destination IDs MAY be explicitly specified by the initiating LER, or be set to zero when do not know which reverse LSP to be bound. Detailed procedures are specified in next section. 3. Operation 3.1. Binding of Two Unidirectional LSPs One of the LERs initiates the request for the path association by sending a Path Binding Request to the remote LER with flag U and V cleared. The initiating LER SHOULD fill the Bidirectional LSP ID TLV with the IDs of the two unidirectional LSPs to be bound The request message is sent along the forward LSP with the GACH encapsulation. On receipt of a Path Binding Request message, the receiving LER SHOULD check the IDs of the two LSPs to determine if the binding request is acceptable based on local policy and other information. Chen, et al. Expires January 5, 2011 [Page 6] Internet-Draft GACH Based Path Association July 2010 If the binding is accepted, it SHOULD send a Path Binding Response message to the initiating LER with flag U and V cleared and the return code set to 0 (Operation success). If the specified reverse LSP does not exist, or the binding is not acceptable based on its local policy, the receiving LER SHOULD send a Response message with return code 2 (Binding not accepted). The Bidirectional LSP ID TLV MAY be copied from the Request message to the Response message. In some scenarios both LERs MAY send Path Binding Request messages to each other independently, flag U and V MUST be cleared. On receipt of the Path Binding Request message, both LERs SHOULD check the Bidirectional LSP ID TLV of the message. If the binding information in both requests are the same, then the binding is successfully finished, and Response messages SHOULD be sent to remote LER with flag U and V cleared and the return code set to 0 (Operation success). If the binding information in one Request message differs from the information in the other Request message, the LER with greater Node ID SHOULD discard the received Request message and MAY send a Response with return code set to 2 (Binding not accepted). Based on local policy and other information, The LER with smaller Node ID SHOULD determine to accept or reject the binding request. If the binding is accepted, the receiving LER SHOULD send a Path Binding Response message with flag U and V cleared and the return code set to 0 (Operation success). Otherwise, the receiving LER SHOULD send a Response message with return code 2 (Binding not accepted). The Bidirectional LSP ID TLV MAY be copied from the Request message to the Response message. 3.2. Binding Relationship Verification After binding the two unidirectional LSP into an associated bidirectional LSP, there MAY be requirement to check the binding relationship, since some configuration errors may change the binding relationship on some nodes. This is achieved using the path binding message. One of the LER SHOULD send a path binding message with message type set to "Request" and the V flag set. The Bidirectional LSP ID TLV specifies the associated bidirectional LSP to be verified. On receipt of the binding Request message with V flag set, the remote LER SHOULD check if the binding relationship in the message is consistent with the local binding relationship. If the binding relationship is consistent, the remote LER SHOULD sent a Response message with V flag set, and the return code set to 0. If there is any inconsistency between the local binding information and the information in the received message, it SHOULD sent a Response message with V flag set, and the return code set to 3 (Binding Chen, et al. Expires January 5, 2011 [Page 7] Internet-Draft GACH Based Path Association July 2010 inconsistency). The Bidirectional LSP ID TLV MAY be copied from the Request message to the Response message. 3.3. Binding Update/Withdrawal When the operator needs to update or withdraw the binding of two unidirectional LSPs, one of the LERs SHOULD send a path binding message with the message type set to "Request", and the U flag MUST be set. If it is to update the binding of forward LSP with another backward LSP, then the Destination ID fields SHOULD be filled with IDs of the new reverse LSP to be bound. If it is to withdraw the current binding, the destination ID fields SHOULD be set to zero. On receipt of the update/withdraw Request message, if the new binding or the withdrawal is accepted, the remote LER SHOULD update local binding relationship, and send a Response message with the U flag set and the return code set to 0. Otherwise it SHOULD send a response message with the U flag set and the return code set to 4 (Update/Withdrawal not accepted). The Bidirectional LSP ID TLV MAY be copied from the Request message to the Response message. 3.4. Association on Intermediate Nodes [RFC5654] specifies that the intermediate nodes traversed by both the forward and backward directions of the associated bidirectional LSP SHOULD be aware of the pairing relationship. In some scenarios the edge nodes may have knowledge of the intermediate nodes traversed by both directions of the associated bidirectional LSP. In this case, after the successful LSP binding on the two edge nodes, the LER with greater Node ID SHOULD send Path Binding Request messages with flag U and V cleared to each intermediate node traversed by both directions. This is achieved by setting the TTL of the topmost label to hop value to the specific intermediate node. The Bidirectional LSP ID TLV MUST be filled with IDs of the forward and backward LSP. On receipt of this message, the intermediate nodes SHOULD interpret this as a path binding notification, since it is not the edge node of the LSPs identified in the Bidirectional LSP ID TLV. Then it SHOULD check if it is on both directions of the associated LSP, if so it SHOULD create the association relationship of the two unidirectional LSPs, if not it SHOULD silently discard the received message. No response is needed from the intermediate node to the initiating node. Chen, et al. Expires January 5, 2011 [Page 8] Internet-Draft GACH Based Path Association July 2010 In scenarios where the edge nodes do not know the intermediate nodes traversed by both directions of the associated bidirectional LSP, the LER with greater Node ID SHOULD form a Path Binding Request message with the flag U and V cleared. The Bidirectional LSP ID TLV MUST be filled with IDs of the forward and backward LSP. Then the Route Alert Label (label value 1) SHOULD be encapsulated as the topmost label. In this way, each intermediate node will process the message locally and send it further along the path. According to the Bidirectional LSP ID TLV in the message, intermediate nodes which are traversed by both directions will create the association relationship, and nodes not on both directions will not perform the association. 4. Security Considerations This document does not change the security properties of MPLS-TP. Spurious path binding messages may be used to perform attacks. However, since these messages are carried in a control channel, one would have to gain access to the nodes providing the service to initiate such attack, which makes the threats less likely. To protect against such attack the Authentication TLV MAY be carried in the ACH TLV field. 5. IANA Considerations IANA is requested to make the following allocations from registries under its control. A new ACH Channel Type is defined in this document. Channel Type Description ------------ -------------------- TBA Path Binding message Two TLVs are defined for Path Binding message: Type Description ---- ------------------- 1 IPv4 Bi-dir. LSP ID TLV Chen, et al. Expires January 5, 2011 [Page 9] Internet-Draft GACH Based Path Association July 2010 2 Ipv6 Bi-dir. LSP ID TLV 6. Contributors Li Xue xueli@huawei.com 7. Acknowledgments The authors would like to thank ... for their valuable comments. 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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5586] Bocci, M., Vigoureux, M. and Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M. et al., "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [TP-IDENTIFIER] Bocci, M., Swallow, G., "MPLS-TP Identifiers", draft-ietf-mpls-tp-identifiers-01 (work in progress), March 2010. 8.2. Informative References [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. Chen, et al. Expires January 5, 2011 [Page 10] Internet-Draft GACH Based Path Association July 2010 [HIERACHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", work in progress, draft-ietf-ccamp-lsp-hierarchy-bis. Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co.,Ltd. Huawei Building, No.3 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China EMail: mach@huawei.com Jie Dong Huawei Technologies Co.,Ltd. Huawei Building, No.3 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China EMail: dongjie_dj@huawei.com Xinchun Guo Huawei Technologies Co.,Ltd. Huawei Building, No.3 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: guoxinchun@huawei.com Chen, et al. Expires January 5, 2011 [Page 11]