MPLS Working Group F. Zhang Internet-Draft ZTE Corporation Intended status: Standards Track March 07, 2012 Expires: September 8, 2012 RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 Abstract The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] specifies an initial set of identifiers, such as local assigned tunnel number and Global_ID, which can be used to form Maintenance Entity Point Identifier (MEP_ID). As to some Operation, Administration and Maintenance (OAM) functions, such as Connectivity Verification (CV) [RFC6428], source MEP_ID must be inserted in the OAM packets, so that the peer endpoint can compare the received and expected MEP_IDs to judge whether there is a mismatch [RFC6371], which means that the two MEP nodes need to pre-store each other's MEP_IDs. This document defines the signaling extensions to exchange the Label Switched Path (LSP) identifiers. 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 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 September 8, 2012. Copyright Notice Copyright (c) 2012 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 Zhang Expires September 8, 2012 [Page 1] Internet-Draft RSVP-TE Extensions for LSP Identifiers March 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Co-routed Bidirectional LSP . . . . . . . . . . . . . . . . 3 3.2. Associated Bidirectional LSP . . . . . . . . . . . . . . . 4 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Association Type . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative references . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Zhang Expires September 8, 2012 [Page 2] Internet-Draft RSVP-TE Extensions for LSP Identifiers March 2012 1. Introduction The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] specifies a initial set of identifiers, such as local assigned tunnel number (Tunnel_Num) and Global_ID, which can be used to form Maintenance Entity Point Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID is Node_ID::Tunnel_Num::LSP_Num, and in situations where global uniqueness is required, this becomes: Global_ID::Node_ID:: Tunnel_Num::LSP_Num. In order to realize some Operation, Administration and Maintenance (OAM) functions, such as Connectivity Verification (CV) [RFC6428], source MEP-ID MUST be inserted in the OAM packets, in this way the peer endpoint can compare the received and expected MEP-IDs to judge whether there is a mismatch [RFC6371]. Hence, the two MEP nodes must pre-store each other's MEP-IDs before sending the CV packets. Obviously, the exchange of MEP_IDs can be accomplished by the Network Management System (NMS), but it is complex when the LSPs cross different adiminstration domains, which involves the cooperation of NMSs. When the LSPs are set up by control plane, Resource ReserVation Protocol Traffic Engnieering (RSVP-TE) messages will be more suitable to realize the exchange of MEP_IDs. Since the LSP identifiers can be carried in an Extended ASSOCIATION object, which may also be used in a single session [I-D.ietf-ccamp-assoc-ext], it is naturally to define the signaling extensions of co-routed and associated bidirectional LSP to exchange the LSP identifiers based on the Extended ASSOCIATION object. 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. Operation 3.1. Co-routed Bidirectional LSP Consider that LSP1 is across different administration domains, which is initialized at A1 node with an Extended ASSOCIATION object inserted in Path message. Association Type is set to "LSP Identifers", Association ID set to A1-Tunnel_Num, Association Source set to A1-Node_ID, Global Association Source set to A1-Global_ID, and the Extended Association ID field is omitted. Upon receipt of the Extended Association Object, the terminating node Z9 checks the Zhang Expires September 8, 2012 [Page 3] Internet-Draft RSVP-TE Extensions for LSP Identifiers March 2012 Association Type field. If it is "LSP Identifiers" and an Upstream_Label exists in Path message, the Extended ASSOCIATION object must be carried in the Resv message also. Similarly, Association Type is set to "LSP Identifiers", Association ID set to Z9-Tunnel_Num, Association Source set to Z9-Node_ID, Global Association Source set to Z9-Global_ID, and the Extended Association ID field is omitted. 3.2. Associated Bidirectional LSP The document [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp] discusses the provisioning models and signaling procedures of associated bidirectional LSPs. Consider the example provided there, when LSP1 and LSP2 are bound together to be an associated bidirectional LSP which is across several administration domains, the global ID filled in the Extended Association objects with Association Type set to "Double Sided Associated Bidirectional LSP" or "Single Sided Associated Bidirectional LSP" is A-Global_ID or B-Global_ID. If it is A-Global_ID, node A still does know the global ID of node B in case that LSP1 and LSP2 are across several administration domains. Since multiple Association objects have always been supported in Path messages, an Extended Association object with Asssociation Type "LSP Identifiers" can be inserted in the Path messages of associated bidirectional LSPs to let the terminating nodes exchange each others LSP identifiers. If double sided provisioning model is used, the values of an Extended Association object in LSP1's Path message are set as below : Association Type set to "LSP Identifiers", Association ID set to A-Tunnel_Num, Association Source set to A-Node_ID, Global Association Source set to A-Global_ID, and the Extended Association ID field omitted; the object in LSP2's Path message are set similarly : Association Type is set to "LSP Identifiers", Association ID set to B-Tunnel_Num, Association Source set to B-Node_ID, Global Association Source set to B-Global_ID, and the Extended Association ID field omitted. While in case that single sided provisioning model is adopted, in the initialized LSP1's Path message, the values of an Extended Association object are set as following: Association Type set to "LSP Identifiers", Association ID set to A-Tunnel_Num, Association Source set to A-Node_ID, Global Association Source set to A-Global_ID, and the Extended Association ID field omitted. When node B receives this Path message, LSP2 is triggered to be established by the received Extended ASSOCIATION objects with the Association Type "Single Sided Associated Bidirectional LSPs" and "LSP Identifiers". The Extended Association Object with Association Type "LSP Identifiers" inserted in LSP2's Path message is like: Association ID set to B-Tunnel_Num, Association Source set to B-Node_ID, Global Association Source set to B-Global_ID, and the Zhang Expires September 8, 2012 [Page 4] Internet-Draft RSVP-TE Extensions for LSP Identifiers March 2012 Extended Association ID field omitted. 4. RSVP-TE Extensions 4.1. Association Type Within the current document, a new Association Type is defined in the Extended ASSOCIATION object. Value Type ----- ----- 6 (TBD) LSP Identifiers (L) See [I-D.ietf-ccamp-assoc-ext] for the definition of other fields and values. The rules associated with the processing of the Extended ASSOCIATION objects in RSVP message are discussed in [I-D.ietf-ccamp-assoc-ext]. It said that in the absence of Association Type-specific rules for identifying association, the included Extended ASSOCIATION objects MUST be identical. Since the Association Type "LSP Identifiers" used here is to carry LSP identifier, there is no need to associate Path state to Path state or Resv state to Resv state, one specific rule is added: when the Association Type is "LSP Identifiers", the Extended ASSOCIATION object can appear in Path or Resv message across sessions or in a single session, and the values can be different. 5. IANA Considerations IANA is requested to administer assignment of new values for namespace defined in this document and summarized in this section. One bit ("LSP Identifers") needs to be allocated in the Association Type Registry. 6. Security Considerations A new Association Type is defined in this document, and except this, there are no security issues about the Extended ASSOCIATION object are introduced here. For Association object related security issues, see the documents [RFC4872], [RFC4873], and [I-D.ietf-ccamp-assoc-ext]. Zhang Expires September 8, 2012 [Page 5] Internet-Draft RSVP-TE Extensions for LSP Identifiers March 2012 For a more comprehensive discussion on GMPLS security please see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 7. Acknowledgement This document was prepared based on the discussion with George Swallow, valuable comments and input were also received from Berger Lou, Venkatesan Mahalingam, Jaihari Kalijanakiraman, Muliu Tao and Wenjuan He. 8. References 8.1. Normative references [I-D.ietf-ccamp-assoc-ext] Berger, L., Faucheur, F., and A. Narayanan, "RSVP Association Object Extensions", draft-ietf-ccamp-assoc-ext-02 (work in progress), February 2012. [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp] Zhang, F. and R. Jing, "RSVP-TE Extensions for Associated Bidirectional LSPs", draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02 (work in progress), October 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [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. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Zhang Expires September 8, 2012 [Page 6] Internet-Draft RSVP-TE Extensions for LSP Identifiers March 2012 Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011. Author's Address Fei Zhang ZTE Corporation Email: zhang.fei3@zte.com.cn Xiao Bao ZTE Corporation Email: bao.xiao1@zte.com.cn Zhang Expires September 8, 2012 [Page 7]