Network Working GroupInternet Engineering Task Force (IETF) R. WinterInternet-DraftRequest for Comments: 6923 NECIntended status:Category: Standards Track E. GrayExpires: August 29, 2013ISSN: 2070-1721 Ericsson H. van Helvoort Huawei Technologies Co., Ltd. M. Betts ZTEFebruary 25,April 2013MPLS-TPMPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventionsdraft-ietf-mpls-tp-itu-t-identifiers-08Abstract 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 Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T). Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 August 29, 2013.http://www.rfc-editor.org/info/rfc6923. Copyright Notice Copyright (c) 2013 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 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3................................................3 1.2. Requirementsnotation . . . . . . . . . . . . . . . . . . 4Notation ......................................4 1.3. Notational Conventions. . . . . . . . . . . . . . . . . . 4.....................................4 2. Named Entities. . . . . . . . . . . . . . . . . . . . . . . . 4..................................................4 3. Uniquely Identifying an Operator--- the ICC_Operator_ID. . . . 5.........5 3.1. Use of the ICC_Operator_ID. . . . . . . . . . . . . . . . 6.................................6 4. Node and Interface Identifiers. . . . . . . . . . . . . . . . 6..................................6 5. MPLS-TP Tunnel and LSP Identifiers. . . . . . . . . . . . . . 7..............................7 5.1. MPLS-TP Point-to-Point Tunnel Identifiers. . . . . . . . 7..................7 5.2. MPLS-TP LSP Identifiers. . . . . . . . . . . . . . . . . 8....................................7 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers. . . 8.....8 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers. . 8....8 6. Pseudowire Path Identifiers. . . . . . . . . . . . . . . . . 9.....................................9 7. Maintenance Identifiers. . . . . . . . . . . . . . . . . . . 9.........................................9 7.1. MEG Identifiers. . . . . . . . . . . . . . . . . . . . . 9............................................9 7.2. MEP Identifiers. . . . . . . . . . . . . . . . . . . . . 10...........................................10 7.3. MIP Identifiers. . . . . . . . . . . . . . . . . . . . . 10...........................................10 8. Security Considerations. . . . . . . . . . . . . . . . . . . 10........................................10 9.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10.References. . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1......................................................11 9.1. Normative References. . . . . . . . . . . . . . . . . . . 11 10.2.......................................11 9.2. Informative References. . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12....................................11 1. Introduction This document augments the initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP) defined in [RFC6370] by adding new identifiers based on ITU-T conventions. It is not intended that both types ofidentifieridentifiers will be used at the same time in the same domain. [RFC6370] defines a set of MPLS-TP transport and management entity identifiers to support bidirectional (co-routed and associated) point-to-point MPLS-TP Label Switched Paths (LSPs), includingPseudowirePseudowires (PWs) and Sectionswhichthat follow the IP/MPLS conventions. This document specifies an alternative way to generate unambiguous identifiers for operators/service providers based on ITU-T conventions and specifies how these operator/service provider identifiers can be used to generate unambiguous identifiers for the existing set of identifiable MPLS-TP entities described in[RFC6370]."[RFC6370]. This document solely defines those identifiers. Their use and possibleprotocolsprotocol extensions to carry themisare out of the scopeinof this document. In this document, we follow the notational convention laid out in [RFC6370], which is included in this document for convenience in Section 1.3. 1.1. Terminology CC: Country Code ICC: ITU Carrier Code ISO: International Organization for StandardizationITU-T:ITU: International Telecommunication Union ITU-T: ITU Telecommunication Standardization Sector LSP: Label Switched Path MEG: Maintenance Entity Group MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point MPLS:Multi-ProtocolMultiprotocol Label Switching PW: Pseudowire TSB: (ITU-T) Telecommunication Standardization Bureau UMC: Unique MEG ID Code 1.2. RequirementsnotationNotation 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]. 1.3. Notational Conventions This document uses the notational conventions laid out in [RFC6370]: All multiple-word atomic identifiers use underscores (_) between the words to join the words. Many of the identifiers are composed of a set of other identifiers. These are expressed by listing the latter identifiers joined with double-colon "::" notation. Where the same identifier type is used multiple times in a concatenation, they are qualified by a prefix joined to the identifier by a dash (-). For example, A1-Node_ID is the Node_ID of a node referred to as A1. The notation defines a preferred ordering of the fields. Specifically, the designation A1 is used to indicate the lower sort order of a field or set of fields and Z9 is used to indicate the higher sort order of the same. The sort is either alphanumeric or numeric depending on the field's definition. Where the sort applies to a group of fields, those fields are grouped with {...}. Note, however, that the uniqueness of an identifier does not depend on the ordering, but rather, upon the uniqueness and scoping of the fields that compose the identifier. Further, the preferred ordering is not intended to constrain protocol designs by dictating a particular field sequence ... or even what fields appear in which objects. 2. Named Entities This documentmakes modest changes to the set ofprovides additional identifiers supplementing those defined in [RFC6370].Most changes replace certain parts in the already definedThe identifiersthatin [RFC6370] arethemselvescomposed of a set of atomic identifiers, and this document defines some new atomic identifiers that can be substituted for some of those that have already been defined, to create new identifiers. The set of identifiers defined in [RFC6370] are: o Global_ID o Node o Interface o Tunnel o LSP o PW o MEG o MEP o MIP The following sections go through this list of identifiers one by one. The structure of this document is loosely aligned with the structure of [RFC6370]. 3. Uniquely Identifying an Operator--- the ICC_Operator_ID In[RFC6370][RFC6370], an operator is uniquely identified by theGlobal_IDGlobal_ID, which is based on theASAutonomous System (AS) number of the operator. TheITU-T howeverITU-T, however, traditionally identifiesoperators/serviceoperators and service providers based on the ITU Carrier Code (ICC) as specified in [M1400]. The ITU-T Telecommunication Standardization Bureau (TSB) maintains a list of assigned ICCs [ICC-list]. Note thatICCsICCs, all of which are referenced at [ICC-list], can be assigned toboth,ITU-T members as well asnon-members, all of which are referenced at [ICC-list].non-members. The national regulatory authorities act as an intermediary between the ITU/TSB and operators/service providers.AmongstOne of 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. This uniqueness assumption is the basis for creating a globally unique ICC-based operator ID. The ICC itself is a string of one to six characters, each character being either alphabetic(i.e.(i.e., A-Z) or numeric(i.e.(i.e., 0-9). Alphabetic characters in the ICC SHOULD be represented withupper caseuppercase 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 withupper caseuppercase letters (i.e., A-Z). The International Organization for Standardization (ISO) establishes internationallyrecognisedrecognized codes for the representation of names of countries, territories or areas of geographical interest, and their subdivisions, published as a list of CCs [CC-list] instandardISO Standard 3166-1 [ISO3166-1]. The ICC and CC characters are coded according to ITU-T Recommendation T.50 [T.50]. Together, the CC and the ICC form the ICC_Operator_ID as: CC::ICC 3.1. Use of the ICC_Operator_ID The ICC_Operator_ID is used as a replacement for the Global_ID as specified in [RFC6370],i.e.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 [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 globallyuniqueunique, the Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an alternative formatwhich,that, 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 [RFC6370] with the exception of the MEG ID, MEPIDID, and MIP ID. MEG,MEPMEP, and MIPidentifiersIdentifiers are redefined in this document (seeSectionSections 7.1,Section 7.27.2, andSection 7.37.3, respectively). 4. Node and Interface Identifiers The format of thenodeNode andinterface identifiersInterface Identifiers are not changed by this memo except for the case when global uniqueness is required. [RFC6370] defines thenode identifierNode Identifier (Node_ID) as a unique 32-bit value assigned by the operator within the scope of a Global_ID. The structure of the Node_ID itself is not defined as it is left to the operator to choose an appropriate value. The valuezero howeverzero, however, is reserved and MUST NOT be used. Thisdraftdocument does not change the above definition. However, in case global uniqueness is required, the Node_ID is prefixed with the ICC_Operator_ID as defined in Section 3. [RFC6370] further defines interface numbers (IF_Num) as 32-bit unsigned integerswhichthat can be freely assigned by the operator and must be unique in the scope of the respective Node_ID. The IF_Num value 0 has a specialmeaningmeaning, andthereforetherefore, it MUST NOT be used to identify an MPLS-TP interface. Aninterface identifierInterface Identifier (IF_ID) identifies an interface uniquely within the context of an ICC_Operator_ID. It is formed by concatenating the Node_ID with the IF_Num to result in a 64-bit identifier formed as Node_ID::IF_Num. Global uniqueness of the IF_ID, if needed, can be assured by prefixing the identifier with the ICC_Operator_ID. 5. MPLS-TP Tunnel and LSP Identifiers This document does not change the definition for localtunnelTunnel and LSP IDs. When global uniqueness is needed, the format of these identifiers is as described inSectionSections 5.1 andSection 5.2 below.5.2. 5.1. MPLS-TP Point-to-Point Tunnel Identifiers Tunnel IDs (Tunnel_ID) are based on the end points' Node_IDs and locally assigned tunnel numbers(Tunnel_Num)(Tunnel_Num), which identify the tunnel at each end point. The tunnel number is a 16-bit unsigned integer unique within the context of the Node_ID. A fulltunnelTunnel ID is represented by the concatenation of these twoend point-specificend-point-specific identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID is: A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} Where global uniqueness is required, using ITU-T conventions, the ICC_Operator_ID is prefixed to theTunnel_IDs.Tunnel_ID. Thus, a globally unique Tunnel_ID becomes: A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::Z9- {ICC_Operator_ID::Node_ID::Tunnel_Num}Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num} As per [RFC6370], when an MPLS-TPTunneltunnel is configured, it MUST be assigned a unique IF_ID at each end point as defined in Section 4. 5.2. MPLS-TP LSP Identifiers The followingsub-sectionssubsections define identifiers for MPLS-TP co-routed bidirectional and associated bidirectional LSPs. Since MPLS-TPSub- PathSub-Path Maintenance Entities (SPMEs) are also LSPs, they use the same form of IDs. 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers The LSPidentifierIdentifier (LSP_ID) for a co-routed bidirectional LSP is formed by adding a 16-bit unsigned integer LSP number (LSP_Num) to thetunnelTunnel ID. Consequently, the format of an MPLS-TP co-routed bidirectional LSP_ID is: A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num [RFC6370] notesthat,that the "uniqueness of identifiers does not depend on the A1/Z9 sort ordering". A co-routed bidirectional LSP is provisioned or signaled as a singleentityentity, andthereforetherefore, a single LSP_Num is used for both unidirectional LSPs. These can be referenced by the following identifiers: A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively. Global uniqueness is accomplished by using globally unique Node_IDs. A globally unique LSP_ID consequently becomes: A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num 5.2.2. MPLS-TP Associated Bidirectional LSP IdentifiersAssociatedAn associated bidirectionalLSPs need anLSP needs a separate LSP_Num foreachboth of its unidirectionalLSP it consists of.LSPs. The LSP number is again a 16-bit unsigned integerwhichthat needs to be unique within the scope of theingress'ingress's Tunnel_Num. Consequently, the format of an MPLS-TP associated bidirectional LSP_ID is: A1-{Node_ID::Tunnel_Num::LSP_Num}:: Z9-{Node_ID::Tunnel_Num::LSP_Num} Each of the unidirectional LSPs of which the associated bidirectional LSPconsists ofis composed may be referenced by one of the following identifiers: A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID, respectively. A globally unique LSP_ID is constructed using the globally unique Node_IDs as defined before. Consequently, a globally unique LSP_ID is formulated as: A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}:: Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num} 6. Pseudowire Path Identifiers The PW Path Identifier (PW_Path_ID) is structured in a similar manner as the PW_Path_ID described insectionSection 6 of [RFC6370]. Instead of the Global_ID used in[RFC6370][RFC6370], this document uses the ICC_Operator_ID to make thePW-Path_IDPW_Path_ID globally unique. In thisdocumentdocument, the Attachment Individual Identifier (AII) is composed of three fields. These are the ICC_Operator_ID, theNode_IDNode_ID, and the AC_ID. TheAC-IDAC_ID is as defined in [RFC5003]. The complete globally unique PW_Path_ID is formulated as: A1-{ICC_Operator_ID::Node_ID::AC_ID}:: Z9-{ICC_Operator_ID::Node_ID::AC_ID} 7. Maintenance Identifiers The followingsub-sectionssubsections define the identifiers for the various maintenance-related groups and entities as defined in [RFC6371]. In contrast to the IDs defined in [RFC6370], this document does not define separate maintenance identifiers forsections, PWsSections, PWs, and LSPs. 7.1. MEG Identifiers MEG_IDs for MPLS-TP Sections,LSPsLSPs, andPseudowiresPWs following ITU-T conventions are based on the globally unique ICC_Operator_ID. In this case, the MEG_ID is a string of up to 15 characters and consists of three subfields: the Country Code (as described in Section3),3) and the ICC (as described in Section 3) -- which together form theICC_Operator_ID,ICC_Operator_ID -- followed by a Unique MEG ID Code (UMC) as defined in [Y.1731_cor1]. The resulting MEG_ID is: CC::ICC::UMC To avoid the potential for the concatenation of a short(i.e.(i.e., less than 6Character)characters) ICC with a UMC not beinguniqueunique, the UMC MUST start with the "/"charactercharacter, which is not allowed in the ICC itself. This way, the MEG_ID can also be easily 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,LSPLSP, or Pseudowire. 7.2. MEP Identifiers ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections,LSPsLSPs, and Pseudowires are formed by appending a 16-bit index to the MEG_ID defined in Section7.1 above.7.1. 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.3. MIP Identifiers ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections,LSPsLSPs, and Pseudowires are formed by a global IF_ID that is obtained by prefixing the identifier of the interface on which the MIP resides with the ICC_Operator_ID as described in Section 3.1. This allows MIPs to be independently identified in nodes where a per-interface MIP model is used. If only a per-node MIP model is used, one MIP is configured. In this case, the MIP_ID is formed by using the Node_ID and an IF_Num of 0. 8. Security Considerations This document extends an existing naming scheme and does not introduce new security concerns.But,However, as mentioned in thesecurity considerationsSecurity Considerations section of[RFC6370][RFC6370], protocol specifications that describe the use of this naming scheme may introduce security risks and concerns about 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 There are no IANA actions resulting from this document. 10.References10.1.9.1. Normative References [ISO3166-1] "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO3166-1.3166-1, 2006. [M1400] "Designations for interconnections among operators' networks", ITU-T Recommendation M.1400, July2006, <http://www.itu.int/rec/T-REC-M.1400-200607-I/en>.2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [T.50] "International ReferenceAlphabet-Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information exchange", ITU-T RecommendationITU-T T.50 (1992).T.50, September 1992. [Y.1731_cor1] "OAM functions and mechanisms for Ethernet based networks - Corrigendum 1", ITU-T RecommendationITU-TG.8013/Y.1731(2011)Corrigendum1. 10.2.1, October 2011. 9.2. Informative References [CC-list] "List of Country Codes - ISO 3166 (CCs)", <http://www.iso.org/iso/country_codes.htm>. [ICC-list] "List of ITU Carrier Codes (ICCs)", <http://www.itu.int/oth/T0201>. [RFC6371] Busi,I.I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework forMPLS-BasedMPLS- Based Transport Networks", RFC 6371, September 2011. Authors' Addresses Rolf Winter NECEmail:EMail: rolf.winter@neclab.eu Eric Gray EricssonEmail:EMail: eric.gray@ericsson.com Huub van Helvoort Huawei Technologies Co., Ltd.Email:EMail: huub.van.helvoort@huawei.com Malcolm Betts ZTEEmail:EMail: malcolm.betts@zte.com.cn