MPLS Working Group F. Zhang Internet-Draft ZTE Corporation Intended status: Standards Track November 13, 2011 Expires: May 16, 2012 RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 Abstract The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] specifies a 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) [I-D.ietf-mpls-tp-cc-cv-rdi], 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 May 16, 2012. 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 Zhang Expires May 16, 2012 [Page 1] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 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. LSP Attribute Flags . . . . . . . . . . . . . . . . . . . . 5 4.2. Connection TLV . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Global_ID TLV . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative references . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Zhang Expires May 16, 2012 [Page 2] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 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) [I-D.ietf-mpls-tp-cc-cv-rdi], 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. The specification of setting up co-routed bidirectional LSP is described in the document [RFC3473], which does not specify the Global_ID and locally configured Z9-Tunnel_Num. Similary, for associated bidirectional LSP [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp], the Global_ID may also be useful. This document defines the signaling extensions to exchange the LSP identifiers. 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 MPLS-TP co-routed bidirectional LSPs can be deployed across one or more administration domains, and NMS may exist in some administration domains, which knows the tunnel spaces of every node in it's responsible domain. Consider that LSP1 is initialized at A1 node, and the "L" bit of the Attributes Flags TLV [RFC5420] may be set in Zhang Expires May 16, 2012 [Page 3] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 the outgoing Path message. If the "L" bit is set, the Connection TLV MUST be carried and Global_ID TLV is optional in the LSP_ATTRIBUTES object. A "L" bit is defined in the Connection TLV. When it is set, the Z9- Tunnel_Num is designated in the "Destination Tunnel Num" field. If the Z9 node finds that this tunnel number is occupied, or it can not be used because of some local policies, an error MUST be generated "Notify error/ unavailable tunnel number". Otherwise, the designated tunnel number must be adopted, and the Connection TLV may be inserted in the Resv message without any change. In case the "L" bit is not set, a recommended Z9-Tunnel_Num may be filled in the "Destination Tunnel Num" field. If the Z9 node finds that the recommended value can be used, the Connection TLV must be inserted in the Resv message without any change; else the recommended value can not be used or the "Destination Tunnel Num" field is empty, a new tunnel number will be allocated and filled into the Connection TLV that must be inserted in the Resv message. While, that the "L" bit is set or not depends on the operators' preference. For example, for the operators who are used to operate traditional transport network and familiar with the Transport-Centric operational model may prefer "L" bit set. That the "L" bit is not set is more suitable for the operators who are familiar with the operation and maintenance of IP/MPLS network, or the MPLS-TP LSPs cross multiple administration domains. The Global_ID TLV is needed to be carried if the LSP is across different administrative domains, which can be inserted in the outgoing Path message at A1 node or added by the transit Autonomous System Border Router (ASBR) node that is in the same domain as A1 node, and the value is A1's Global_ID. Z9's Global_ID should be inserted in the Resv message at Z9 node or any other Label Swithed Routers (LSRs) that in the same domain as Z9, and the value is Z9's Global_ID. 3.2. Associated Bidirectional LSP MPLS-TP associated bidirectional LSPs may also be deployed across one or more administration domains, and the Global_ID is needed to keep the MEP_ID globally unique. Consider that the forward LSP is initialized at A1 node and the backward LSP is initialized at Z9 node, the "L" bit of the Attributes Flags TLV may be set in each other's outgoing Path messages. When the "L" bit is set, the Global_ID TLV with the value set to A1/Z9's Global_ID is optional in the LSP_ATTRIBUTES object and can be inserted in the outgoing Path message at A1/Z9 node or added by the transit Autonomous System Border Router (ASBR) node that is in the same domain as A1/Z9 node. If this TLV is present in Resv message, it can be ignored. Zhang Expires May 16, 2012 [Page 4] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 4. RSVP-TE Extensions 4.1. LSP Attribute Flags The LSP Attribute Flags TLV is defined in [RFC5420], and this document introduces a new flag: One bit ("L", IANA to assign): "LSP identifier indication" is allocated in the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. If the "L" bit is set, it is indicating that A1/Z9 node needs to know each other's LSP identifer. 4.2. Connection TLV The Connection TLV is carried in the LSP_ATTRIBUTES object with the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved | Destination Tunnel Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connection TLV Zhang Expires May 16, 2012 [Page 5] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 L The L bit is set if the initiating node enforces the peer endpoint to configure the value carried in the field of "Destination Tunnle Num". If the bit is not set, the peer endpoint firstly tries to use the recommended tunnel number; it can use any other unoccupied tunnnel numbers when the recommended tunnel number is unavailable. Reserverd Must be set to 0 on transmit and ignored on receive. Destination Tunnel Num If the L bit is set, it indicates that the peer endpoint must configure the value carried in this field. Else the L bit is not set, this field can be empty or filled by the recommended value. The Connection TLV may appear in Path or Resv message of co-routed bidirectional LSP. 4.3. Global_ID TLV The Global_ID TLV is carried in the LSP_ATTRIBUTES object with the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Global_ID TLV This TLV can be used for co-routed or associated bidirectional LSP. For co-routed bidirectional LSP, it can appear in Path or Resv message. As to associated bidirectional LSP, it can only appear in the Path message, and will be ignored in the Resv message. Zhang Expires May 16, 2012 [Page 6] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 5. IANA Considerations One bit ("LSP identifier indication") needs to be allocated in the LSP Attributes Flags Registry. This document specifies two new TLVs to be carried in the LSP_ATTRIBUTES objects in Path and Resv messages: the Connection TLV and Global_ID TLV. For the existing error code "Notify error" (value 25), one new Error value: "Unavailable tunnel number" needs to be assigned. 6. Security Considerations This document adds a new flag to the Attributes Flags TLV and introduce two new TLVs in the LSP_ATTRIBUTES objects. It does not introduce any new direct security issues, and the reader is referred to the security considerations expressed in [RFC2205] and [RFC5420]. 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 and Muliu Tao. 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. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Zhang Expires May 16, 2012 [Page 7] Internet-Draft RSVP-TE Extentions for LSP Identifiers November 2011 Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. 8.2. Informative References [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. [I-D.ietf-mpls-tp-cc-cv-rdi] Allan, D., Swallow, G., and J. Drake, "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress), August 2011. [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 Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 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 May 16, 2012 [Page 8]