Network Working Group M. Chen Internet-Draft L. Zheng Intended status: Standards Track Huawei Technologies Co., Ltd Expires: May 3, 2012 October 31, 2011 Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operator Identifier Object draft-chen-ccamp-mpls-tp-oio-01.txt Abstract Two formats of operator identifier are specified in Multi-Protocol Label Switching Transport Profile (MPLS-TP) networks, to uniquely identify an operator. One is Global_ID, the other is ICC_Operator_ID. In MPLS-TP networks, operator identifier as part of the global identifier of an MPLS-TP LSP may be required to be carried in the Path/Resv message when setting up the LSP. This document defines a new RSVP-TE Object: Operator Identifier object (OIO). It has two types, the Global_ID object and the ICC_Operator_ID object. Similar as Session and Sender Template object, OIO could be carried in the Path or Resv message to communicate the Operator ID that the two ends of an LSP in use. At the same time, it makes sure all the nodes that the LSP traverses to use the same format of Operator ID. 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]. 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." Chen & Zheng Expires May 3, 2012 [Page 1] Internet-Draft Operator Identifier Object October 2011 This Internet-Draft will expire on May 3, 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 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. Chen & Zheng Expires May 3, 2012 [Page 2] Internet-Draft Operator Identifier Object October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Operator Identifier Object . . . . . . . . . . . . . . . . . . 4 2.1. Global_ID Object . . . . . . . . . . . . . . . . . . . . . 5 2.2. ICC_Operator_ID Object . . . . . . . . . . . . . . . . . . 5 2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Chen & Zheng Expires May 3, 2012 [Page 3] Internet-Draft Operator Identifier Object October 2011 1. Introduction RFC6370 [RFC6370] specifies an initial set of identifiers to be used in the Multiprotocol Label Switching Transport Profile (MPLS-TP). The Global_ID is defined in RFC6370 [RFC6370] to uniquely identify an operator. [I.D.draft-ietf-mpls-tp-itu-t-identifiers] [I-D.ietf-mpls-tp-itu-t-identifiers] specifies the ICC_Operator_ID, an alternative way to uniquely identify an operator based on ITU-T conventions. We call both Global_ID and ICC_Operator_ID as Operator ID in this document. The Operator ID is used to provide a globally unique context for other MPLS-TP identifiers. Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling [RFC3209][RFC3471] does not exchange Operator ID when setup an LSP. It is because in the traditional MPLS network the use of Operator ID is not necessary. When the IP addresses is globally unique, a Traffic Engineering (TE) LSP could be uniquely identified by the source IP address, destination IP address, Tunnel ID and Label Switching Path (LSP) ID of the LSP, which are carried in the Session and Sender Template/Filter Spec object. But in MPLS-TP networks, the Node Identifier (Node_ID) is unique within the scope of the Operator ID. In situations where a Node_ID needs to be globally unique, this is accomplished by prefixing the identifier with the Operator ID. This means the Operator ID as part of the global identifier of an MPLS-TP LSP may be required to be carried in the Path/Resv message when setting up the LSP. In addition, since two formats of Operator ID are defined, i.e.Global_ID and ICC_Operator_ID, two things need to be determined when setting up a LSP in terms of Operator ID. One is that which format should be used, the other is that how to make sure both ends of the LSP using the same format. The former could be achieved by the configuration of the operators. The later may need some signaling exchange. This document defines a new RSVP-TE object: Operator Identifier object (OIO). It has two types, the Global_ID object and ICC_Operator_ID object. Similar as the Session and Sender Template/ Filter Spec object, OIO could be carried in the Path/Resv message to communicate the Operator ID that the two ends of an LSP in use. At the same time, it makes sure all the nodes that the LSP traverses to use the same format of Operator ID. 2. Operator Identifier Object Two types of Operator Identifier object (OIO) are defined in this document for two formats of Operator ID respectively: Global_ID Chen & Zheng Expires May 3, 2012 [Page 4] Internet-Draft Operator Identifier Object October 2011 object and ICC_Operator_ID object. Both Global_ID and ICC_Operator_ID object are OPTIONAL. When setting up an MPLS-TP LSP, one and only one type of the OIO MUST be included in the Path/Resv message if the Operator ID is required. 2.1. Global_ID Object The encoding of the Global_ID object including the common object header is as follows: 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 (TBA)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Global_ID Object Class-Num: To be allocated by IANA. C-Type: To be allocated by IANA (0x01 is recommended). Global_ID: Global_ID of the sender node. As defined in RFC6370 [RFC6370], a Global_ID is an unsigned 32-bit value and MUST be derived from a 4-octet AS number assigned to the operator. Note that 2-octet AS numbers have been incorporated in the 4-octet by placing the 2-octet AS number in the low-order octets and setting the two high-order octets to zero. 2.2. ICC_Operator_ID Object The encoding of the ICC_Operator_ID object including the common object header is as follows: 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 (TBA)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICC_Operator_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICC_Operator_ID(contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. ICC_Operator_ID Object Class-Num: To be allocated by IANA. C-Type: To be allocated by IANA (0x02 is recommended). Chen & Zheng Expires May 3, 2012 [Page 5] Internet-Draft Operator Identifier Object October 2011 ICC_Operator_ID: ICC_Operator_ID of the sender node. As defined in [I-D.ietf-mpls-tp-itu-t-identifiers], the ICC_Operator_ID is formed by Country Code (CC) and ICC(ITU-T Carrier Code ) as CC::ICC. The ICC itself is a string of one to six characters, global uniqueness is assured by concatenating the ICC with a CC. The Country Code (alpha-2) is a string of two alphabetic characters represented with upper case letters (i.e., A-Z). When the length of a ICC_Operator_ID string is less than 8 octets, the higher-order unused octets of the ICC_Operator_ID field MUST be set to zero. 2.3. Procedures When signaling an MPLS-TP LSP, if the Operator ID is needed, e.g. LSRs on the LSP belong to different operators, the Operator Identifier object MUST be carried in the Path message, either the Global_ID or ICC_Operator_ID C-Type is used based on its local configuration. The Global_ID or ICC_Operator_ID field is filled by the sender node's Global_ID or ICC_Operator_ID. When receiving such a Path message with OIO object, the node MUST check it's C-Type to see whether it agree to use that format of Operator ID. If the node agrees, it MUST use the same format of Operator ID. The same C-Type of OIO MUST be carried in the Resv message, and the Global_ID or ICC_Operator_ID field is filled by its own Global_ID or ICC_Operator_ID. If the receiving node does not recognize the Operator Identifier object, it sends a PathErr message with the error code "Unknown object class" towards the sender. If the receiving node recognizes the Operator Identifier object but does not recognize or support the C-Type, it sends a PathErr message with the error code "Unknown object C-Type" towards the sender. If the receiving node, for any reason, is not able to use the same C-Type as sender, e.g. due to fault configuration or requested C-Type not enabled, it MUST send a PathErr message with the error code "Wrong Operator Identifier C-Type" to notify the sender (Error Code to be allocated by IANA), and the LSP is not set up. 3. IANA Considerations This document request IANA to assign new Class-Num, C-Types as follows: Class-Num Class Name Class Types or C-Types: --------- ------------------- ------------------------ TBD Operator Identifier 0x01(TBD) Global_ID 0x02(TBD) ICC_Operator_ID Chen & Zheng Expires May 3, 2012 [Page 6] Internet-Draft Operator Identifier Object October 2011 This document also request IANA to assign new Error-Code as follows: Error Code Meaning ---------- ------------------------------- TBD Wrong Operator Identifier C-Type 4. Security Considerations When Operator Identifier Object is in use, a form of source- validation checking may be enabled to ensure that the Global_ID or ICC_Operator_ID originated from a legitimate source, especially in the inter-provider case. 5. Acknowledgements 6. References 6.1. Normative References [I-D.ietf-mpls-tp-itu-t-identifiers] Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", draft-ietf-mpls-tp-itu-t-identifiers-01 (work in progress), October 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 6.2. Informative References [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. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Chen & Zheng Expires May 3, 2012 [Page 7] Internet-Draft Operator Identifier Object October 2011 Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China Email: mach@huawei.com Lianshu Zheng Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China Email: vero.zheng@huawei.com Chen & Zheng Expires May 3, 2012 [Page 8]