--- 1/draft-ietf-mpls-tp-itu-t-identifiers-00.txt 2011-10-28 18:14:05.406754847 +0200 +++ 2/draft-ietf-mpls-tp-itu-t-identifiers-01.txt 2011-10-28 18:14:05.422755097 +0200 @@ -1,21 +1,23 @@ Network Working Group R. Winter, Ed. Internet-Draft NEC -Intended status: Standards Track H. van Helvoort -Expires: January 27, 2012 Huawei Technologies Co., Ltd. +Intended status: Standards Track E. Gray, Ed. +Expires: April 30, 2012 Ericsson + H. van Helvoort + Huawei Technologies Co., Ltd. M. Betts ZTE - July 26, 2011 + October 28, 2011 MPLS-TP Identifiers Following ITU-T Conventions - draft-ietf-mpls-tp-itu-t-identifiers-00 + draft-ietf-mpls-tp-itu-t-identifiers-01 Abstract This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. @@ -27,211 +29,249 @@ 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 January 27, 2012. + This Internet-Draft will expire on April 30, 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 - 3. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 5 - 4. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . . . 6 - 5. ICC_Operator_ID-based MEG Identifiers . . . . . . . . . . . . 7 - 6. ICC_Operator_ID-based MEP Identifiers . . . . . . . . . . . . 8 - 7. Identifier Usage Considerations . . . . . . . . . . . . . . . 9 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 4 + 2. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 4 + 3. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . . . 4 + 4. ICC_Operator_ID-based MEG Identifiers . . . . . . . . . . . . . 5 + 5. ICC_Operator_ID-based MEP Identifiers . . . . . . . . . . . . . 5 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document augments the initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP) - specified in [I-D.ietf-mpls-tp-identifiers]. + specified in RFC 6370 [RFC6370]. - [I-D.ietf-mpls-tp-identifiers] defines a set of MPLS-TP transport and - management entity identifiers to support bidirectional (co-routed and + RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management + entity identifiers to support bidirectional (co-routed and associated) point-to-point MPLS-TP LSPs, including PWs and Sections which follow the IP/MPLS conventions. This document specifies an alternative way to uniquely identify an operator/service provider based on ITU-T conventions and specifies how this operator/service provider identifier can be used to make the existing set of MPLS-TP transport and management entity identifiers, - defined by [I-D.ietf-mpls-tp-identifiers], globally unique. + defined by RFC 6370 [RFC6370], globally unique. - This document solely defines those identifiers. The use of them and - possible extensions to protocols to carry them is outside of scope of - this document. + This document solely defines those identifiers. Their use and + possible protocols extensions to carry them is out of scope in this + document. - In this document, we follow the notational convention laid out in - [I-D.ietf-mpls-tp-identifiers]. + In this document, we follow the notational convention laid out in RFC + 6370 [RFC6370]. -2. Requirements notation +1.1. Terminology + + CC: Country Code + + ICC: ITU-T Carrier Code + + ITU-T: International Telecommunication Union Telecommunication + Standardization Sector + + LSP: Label Switched Path + + MEG: Maintenance Entity Group + + MEP: Maintenance Entity Group End Point + + MPLS: Multi-Protocol Label Switching + + PW: Pseudowire + + TSB: (ITU-T) Telecommunication Standardization Bureau + + UMC: Unique MEG ID Code + +1.2. Requirements notation 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]. + document are to be interpreted as described in RFC 2119 [RFC2119]. -3. Uniquely Identifying an Operator - the ICC_Operator_ID +2. Uniquely Identifying an Operator - the ICC_Operator_ID - In [I-D.ietf-mpls-tp-identifiers] an operator is uniquely identified - by the Global_ID which is based on the AS number of the operator. - The ITU-T however traditionally identifies operators/service - providers based on the ITU-T Carrier Code (ICC) as specified in - [M1400]. + In RFC 6370 [RFC6370] an operator is uniquely identified by the + Global_ID which is based on the AS number of the operator. The ITU-T + however traditionally identifies operators/service providers based on + the ITU-T Carrier Code (ICC) as specified in [M1400]. The ITU-T Telecommunication Standardization Bureau (TSB) maintains a list of assigned ICCs [ICC-list]. Note that ICCs can be assigned to both, ITU-T members as well as non-members, all of which are referenced at [ICC-list]. The national regulatory authorities act as an intermediary between the ITU/TSB and operators/service providers. Amongst the things that the national authorities are responsible for in the process of assigning an ICC is to ensure that the Carrier Codes are unique within their country. The ICC itself is a string of one to six characters, each character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9). Alphabetic characters in the ICC SHOULD be represented with upper case letters. Global uniqueness is assured by concatenating the ICC with a Country Code (CC). The Country Code (alpha-2) is a string of two alphabetic characters represented with upper case letters (i.e., A-Z). The Country Code format is defined in ISO 3166-1 [ISO3166-1]. Together, - they form the ICC_Operator_ID. + the CC and the ICC form the ICC_Operator_ID as CC::ICC. -4. Use of the ICC_Operator_ID +3. Use of the ICC_Operator_ID The ICC_Operator_ID is used as a replacement for the Global_ID as - specified in [I-D.ietf-mpls-tp-identifiers], i.e. its purpose is to - provide a globally unique context for other MPLS-TP identifiers. + specified in RFC 6370 [RFC6370], i.e. its purpose is to provide a + globally unique context for other MPLS-TP identifiers. - As an example, an Interface Identifier (IF_ID) in - [I-D.ietf-mpls-tp-identifiers] is specified as the concatenation of - the Node_ID (a unique 32-bit value assigned by the operator) and the - Interface Number (IF_Num, a 32-bit unsigned integer assigned by the - operator that is unique within the scope of a Node_ID). To make this - IF_ID globally unique the Global_ID is prefixed. This memo specifies - the ICC_Operator_ID as an alternative format which, just like the - Global_ID, is prefixed to the IF_ID. Using the notation from - [I-D.ietf-mpls-tp-identifiers]: + As an example, an Interface Identifier (IF_ID) in RFC 6370 [RFC6370] + is specified as the concatenation of the Node_ID (a unique 32-bit + value assigned by the operator) and the Interface Number (IF_Num, a + 32-bit unsigned integer assigned by the operator that is unique + within the scope of a Node_ID). To make this IF_ID globally unique + the Global_ID is prefixed. This memo specifies the ICC_Operator_ID + as an alternative format which, just like the Global_ID, is prefixed + to the IF_ID. Using the notation from RFC 6370 [RFC6370]: Global_ID::Node_ID::IF_Num is functionally equivalent to: ICC_Operator_ID::Node_ID::IF_Num The same substitution procedure applies to all identifiers specified - in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives - mentioned in this document. + in RFC 6370 [RFC6370] except for the other alternatives mentioned in + this document. -5. ICC_Operator_ID-based MEG Identifiers +4. ICC_Operator_ID-based MEG Identifiers The ITU-T format of MEG_IDs for MPLS-TP Sections, LSPs and Pseudowires is based on the globally unique ICC_Operator_ID. In this - case, the MEG_ID is a string of up to thirteen characters. It - consists of three subfields: the ICC (as described in Section 3), - followed by a "/" (indicating the end of the ICC subfield), the - Country Code (as described in Section 3) followed by a unique MEG - code (UMC). The UMC MUST be unique within the organization - identified by the ICC. + case, the MEG_ID is a string of up to 15 characters. It consists of + three subfields: the Country Code (as described in Section 2), the + ICC (as described in Section 2) which together form the + ICC_Operator_ID, followed by a Unique MEG ID Code (UMC). + + The resulting MEG_ID therefore looks like the following: + + CC:ICC:UMC + + To avoid the potential for a short (i.e. less than 6 Character) ICC + code in combination with a UMC not being unique the UMC MUST start + with a special character that is not allowed in the ICC such as the + "/" character. A side effect of this is that the MEG_ID can be + decomposed into its individual components by a receiver. + + The UMC MUST be unique within the organization identified by the + combination of CC and ICC. The ICC_Operator_ID-based MEG_ID may be applied equally to a single - MPLS-TP Section, LSP or Pseudowires. + MPLS-TP Section, LSP or Pseudowire. -6. ICC_Operator_ID-based MEP Identifiers +5. ICC_Operator_ID-based MEP Identifiers ICC_Operator_ID-based MEP_IDs for MPLS-TP LSPs and Pseudowires are - formed by appending a unique number to the MEG_ID defined in - Section 5 above. Within the context of a particular MEG, we call the + formed by appending a 16-bit index to the MEG_ID defined in Section 4 + above. Within the context of a particular MEG, we call the identifier associated with a MEP the MEP Index (MEP_Index). The MEP_Index is administratively assigned. It is encoded as a 16-bit unsigned integer and MUST be unique within the MEG. An ICC_Operator_ID-based MEP_ID is structured as: MEG_ID::MEP_Index An ICC_Operator_ID-based MEP ID is globally unique by construction given the ICC_Operator_ID-based MEG_ID's global uniqueness. -7. Identifier Usage Considerations - - TBD. - -8. Security Considerations +6. Security Considerations This document extends an existing information model and, as such, does in itself not introduce new security concerns. But, as mentioned in the security considerations section of the document that is being augmented, protocol specifications that describe use of this information model may introduce security risks and concerns about - authentication of participants. For this reason, the writers of - protocol specifications for the purpose of describing implementations - of this information model need to describe security and - authentication concerns that may be raised by the particular - mechanisms defined and how those concerns may be addressed. + authentication of participants. For this reason, these protocol + specifications need to describe security and authentication concerns + that may be raised by the particular mechanisms defined and how those + concerns may be addressed. -9. IANA Considerations +7. IANA Considerations There are no IANA actions resulting from this document. -10. Normative References - - [I-D.ietf-mpls-tp-identifiers] - Bocci, M., Swallow, G., and E. Gray, "MPLS-TP - Identifiers", draft-ietf-mpls-tp-identifiers-06 (work in - progress), June 2011. +8. References - [ICC-list] - "www.itu.int/ITU-T/inr/icc/index.html". +8.1. Normative References [ISO3166-1] "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1. [M1400] "Designations for interconnections among operators' - networks", ITU-T Recommendation M.1400, July 2006. + networks", ITU-T Recommendation M.1400, July 2006, + . [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. + +8.2. Informative References + + [ICC-list] + "List of ITU Carrier Codes (ICCs)", + . + Authors' Addresses Rolf Winter (editor) NEC Email: rolf.winter@neclab.eu + Eric Gray (editor) + Ericsson + + Email: eric.gray@ericsson.com + Huub van Helvoort Huawei Technologies Co., Ltd. Email: huub.van.helvoort@huawei.com Malcolm Betts ZTE Email: malcolm.betts@zte.com.cn