idnits 2.17.1 draft-ietf-mpls-tp-itu-t-identifiers-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'M1400' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Winter 3 Internet-Draft NEC 4 Intended status: Standards Track E. Gray 5 Expires: August 29, 2013 Ericsson 6 H. van Helvoort 7 Huawei Technologies Co., Ltd. 8 M. Betts 9 ZTE 10 February 25, 2013 12 MPLS-TP Identifiers Following ITU-T Conventions 13 draft-ietf-mpls-tp-itu-t-identifiers-08 15 Abstract 17 This document specifies an extension to the identifiers to be used in 18 the Transport Profile of Multiprotocol Label Switching (MPLS-TP). 19 Identifiers that follow IP/MPLS conventions have already been 20 defined. This memo augments that set of identifiers for MPLS-TP 21 management and Operations, Administration, and Maintenance (OAM) 22 functions to include identifier information in a format typically 23 used by the International Telecommunication Union Telecommunication 24 Standardization Sector (ITU-T). 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 29, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 63 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 4 64 2. Named Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 5 66 3.1. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . 6 67 4. Node and Interface Identifiers . . . . . . . . . . . . . . . . 6 68 5. MPLS-TP Tunnel and LSP Identifiers . . . . . . . . . . . . . . 7 69 5.1. MPLS-TP Point-to-Point Tunnel Identifiers . . . . . . . . 7 70 5.2. MPLS-TP LSP Identifiers . . . . . . . . . . . . . . . . . 8 71 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers . . . 8 72 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers . . 8 73 6. Pseudowire Path Identifiers . . . . . . . . . . . . . . . . . 9 74 7. Maintenance Identifiers . . . . . . . . . . . . . . . . . . . 9 75 7.1. MEG Identifiers . . . . . . . . . . . . . . . . . . . . . 9 76 7.2. MEP Identifiers . . . . . . . . . . . . . . . . . . . . . 10 77 7.3. MIP Identifiers . . . . . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 This document augments the initial set of identifiers to be used in 88 the Transport Profile of Multiprotocol Label Switching (MPLS-TP) 89 defined in [RFC6370] by adding new identifiers based on ITU-T 90 conventions. It is not intended that both types of identifier will 91 be used at the same time in the same domain. 93 [RFC6370] defines a set of MPLS-TP transport and management entity 94 identifiers to support bidirectional (co-routed and associated) 95 point-to-point MPLS-TP Label Switched Paths (LSPs), including 96 Pseudowire (PWs) and Sections which follow the IP/MPLS conventions. 98 This document specifies an alternative way to generate unambiguous 99 identifiers for operators/service providers based on ITU-T 100 conventions and specifies how these operator/service provider 101 identifiers can be used to generate unambiguous identifiers for the 102 existing set of identifiable MPLS-TP entities described in 103 [RFC6370]." 105 This document solely defines those identifiers. Their use and 106 possible protocols extensions to carry them is out of scope in this 107 document. 109 In this document, we follow the notational convention laid out in 110 [RFC6370], which is included in this document for convenience in 111 Section 1.3. 113 1.1. Terminology 115 CC: Country Code 117 ICC: ITU Carrier Code 119 ISO: International Organization for Standardization 121 ITU-T: International Telecommunication Union Telecommunication 122 Standardization Sector 124 LSP: Label Switched Path 126 MEG: Maintenance Entity Group 128 MEP: Maintenance Entity Group End Point 130 MIP: Maintenance Entity Group Intermediate Point 132 MPLS: Multi-Protocol Label Switching 133 PW: Pseudowire 135 TSB: (ITU-T) Telecommunication Standardization Bureau 137 UMC: Unique MEG ID Code 139 1.2. Requirements notation 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 1.3. Notational Conventions 147 All multiple-word atomic identifiers use underscores (_) between the 148 words to join the words. Many of the identifiers are composed of a 149 set of other identifiers. These are expressed by listing the latter 150 identifiers joined with double-colon "::" notation. 152 Where the same identifier type is used multiple times in a 153 concatenation, they are qualified by a prefix joined to the 154 identifier by a dash (-). For example, A1-Node_ID is the Node_ID of 155 a node referred to as A1. 157 The notation defines a preferred ordering of the fields. 158 Specifically, the designation A1 is used to indicate the lower sort 159 order of a field or set of fields and Z9 is used to indicate the 160 higher sort order of the same. The sort is either alphanumeric or 161 numeric depending on the field's definition. Where the sort applies 162 to a group of fields, those fields are grouped with {...}. 164 Note, however, that the uniqueness of an identifier does not depend 165 on the ordering, but rather, upon the uniqueness and scoping of the 166 fields that compose the identifier. Further, the preferred ordering 167 is not intended to constrain protocol designs by dictating a 168 particular field sequence or even what fields appear in which 169 objects. 171 2. Named Entities 173 This document makes modest changes to the set of identifiers defined 174 in [RFC6370]. Most changes replace certain parts in the already 175 defined identifiers that are themselves composed of a set of atomic 176 identifiers. The set of identifiers defined in [RFC6370] are: 178 o Global_ID 180 o Node 182 o Interface 184 o Tunnel 186 o LSP 188 o PW 190 o MEG 192 o MEP 194 o MIP 196 The following sections go through this list of identifiers one by 197 one. The structure of this document is loosely aligned with the 198 structure of [RFC6370]. 200 3. Uniquely Identifying an Operator - the ICC_Operator_ID 202 In [RFC6370] an operator is uniquely identified by the Global_ID 203 which is based on the AS number of the operator. The ITU-T however 204 traditionally identifies operators/service providers based on the ITU 205 Carrier Code (ICC) as specified in [M1400]. 207 The ITU-T Telecommunication Standardization Bureau (TSB) maintains a 208 list of assigned ICCs [ICC-list]. Note that ICCs can be assigned to 209 both, ITU-T members as well as non-members, all of which are 210 referenced at [ICC-list]. The national regulatory authorities act as 211 an intermediary between the ITU/TSB and operators/service providers. 212 Amongst the things that the national authorities are responsible for 213 in the process of assigning an ICC is to ensure that the Carrier 214 Codes are unique within their country. This uniqueness assumption is 215 the basis for creating a globally unique ICC-based operator ID. 217 The ICC itself is a string of one to six characters, each character 218 being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9). 219 Alphabetic characters in the ICC SHOULD be represented with upper 220 case letters. 222 Global uniqueness is assured by concatenating the ICC with a Country 223 Code (CC). The Country Code (alpha-2) is a string of two alphabetic 224 characters represented with upper case letters (i.e., A-Z). 226 The International Organization for Standardization (ISO) establishes 227 internationally recognised codes for the representation of names of 228 countries, territories or areas of geographical interest, and their 229 subdivisions, published as a list of CCs [CC-list] in standard ISO 230 3166-1 [ISO3166-1]. 232 The ICC and CC characters are coded according to ITU-T Recommendation 233 T.50 [T.50]. 235 Together, the CC and the ICC form the ICC_Operator_ID as: 237 CC::ICC 239 3.1. Use of the ICC_Operator_ID 241 The ICC_Operator_ID is used as a replacement for the Global_ID as 242 specified in [RFC6370], i.e. its purpose is to provide a globally 243 unique context for other MPLS-TP identifiers. 245 As an example, an Interface Identifier (IF_ID) in [RFC6370] is 246 specified as the concatenation of the Node_ID (a unique 32-bit value 247 assigned by the operator) and the Interface Number (IF_Num, a 32-bit 248 unsigned integer assigned by the operator that is unique within the 249 scope of a Node_ID). To make this IF_ID globally unique the 250 Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an 251 alternative format which, just like the Global_ID, is prefixed to the 252 IF_ID. Using the notation from RFC 6370 [RFC6370]: 254 Global_ID::Node_ID::IF_Num 256 is functionally equivalent to: 258 ICC_Operator_ID::Node_ID::IF_Num 260 The same substitution procedure applies to all identifiers specified 261 in [RFC6370] with the exception of the MEG ID, MEP ID and MIP ID. 262 MEG, MEP and MIP identifiers are redefined in this document (see 263 Section 7.1, Section 7.2 and Section 7.3 respectively). 265 4. Node and Interface Identifiers 267 The format of the node and interface identifiers are not changed by 268 this memo except for the case when global uniqueness is required. 270 [RFC6370] defines the node identifier (Node_ID) as a unique 32-bit 271 value assigned by the operator within the scope of a Global_ID. The 272 structure of the Node_ID itself is not defined as it is left to the 273 operator to choose an appropriate value. The value zero however is 274 reserved and MUST NOT be used. 276 This draft does not change the above definition. However, in case 277 global uniqueness is required, the Node_ID is prefixed with the 278 ICC_Operator_ID as defined in Section 3. 280 [RFC6370] further defines interface numbers (IF_Num) as 32-bit 281 unsigned integers which can be freely assigned by the operator and 282 must be unique in the scope of the respective Node_ID. The IF_Num 283 value 0 has a special meaning and therefore it MUST NOT be used to 284 identify an MPLS-TP interface. 286 An interface identifier (IF_ID) identifies an interface uniquely 287 within the context of an ICC_Operator_ID. It is formed by 288 concatenating the Node_ID with the IF_Num to result in a 64-bit 289 identifier formed as Node_ID::IF_Num. 291 Global uniqueness of the IF_ID, if needed, can be assured by 292 prefixing the identifier with the ICC_Operator_ID. 294 5. MPLS-TP Tunnel and LSP Identifiers 296 This document does not change the definition for local tunnel and LSP 297 IDs. When global uniqueness is needed, the format of these 298 identifiers is as described in Section 5.1 and Section 5.2 below. 300 5.1. MPLS-TP Point-to-Point Tunnel Identifiers 302 Tunnel IDs (Tunnel_ID) are based on the end points' Node_IDs and 303 locally assigned tunnel numbers (Tunnel_Num) which identify the 304 tunnel at each end point. The tunnel number is a 16-bit unsigned 305 integer unique within the context of the Node_ID. A full tunnel ID 306 is represented by the concatenation of these two end point-specific 307 identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID 308 is: 310 A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} 312 Where global uniqueness is required, using ITU-T conventions, the 313 ICC_Operator_ID is prefixed to the Tunnel_IDs. Thus, a globally 314 unique Tunnel_ID becomes: 316 A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: Z9- 317 {ICC_Operator_ID::Node_ID::Tunnel_Num} 319 As per [RFC6370], when an MPLS-TP Tunnel is configured, it MUST be 320 assigned a unique IF_ID at each end point as defined in Section 4. 322 5.2. MPLS-TP LSP Identifiers 324 The following sub-sections define identifiers for MPLS-TP co-routed 325 bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub- 326 Path Maintenance Entities (SPMEs) are also LSPs, they use the same 327 form of IDs. 329 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers 331 The LSP identifier (LSP_ID) for a co-routed bidirectional LSP is 332 formed by adding a 16-bit unsigned integer LSP number (LSP_Num) to 333 the tunnel ID. Consequently, the format of an MPLS-TP co-routed 334 bidirectional LSP_ID is: 336 A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num 338 [RFC6370] notes that, the "uniqueness of identifiers does not depend 339 on the A1/Z9 sort ordering". 341 A co-routed bidirectional LSP is provisioned or signaled as a single 342 entity and therefore a single LSP_Num is used for both unidirectional 343 LSPs. These can be referenced by the following identifiers: 345 A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and 347 Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively. 349 Global uniqueness is accomplished by using globally unique Node_IDs. 350 A globally unique LSP_ID consequently becomes: 352 A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: 353 Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num 355 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers 357 Associated bidirectional LSPs need an LSP_Num for each unidirectional 358 LSP it consists of. The LSP number is again a 16-bit unsigned 359 integer which needs to be unique within the scope of the ingress' 360 Tunnel_Num. Consequently, the format of an MPLS-TP associated 361 bidirectional LSP_ID is: 363 A1-{Node_ID::Tunnel_Num::LSP_Num}:: 364 Z9-{Node_ID::Tunnel_Num::LSP_Num} 366 Each of the unidirectional LSPs of which the associated bidirectional 367 LSP consists of may be referenced by one of the following 368 identifiers: 370 A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and 372 Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID, respectively. 374 A globally unique LSP_ID is constructed using the globally unique 375 Node_IDs as defined before. Consequently, a globally unique LSP_ID 376 is formulated as: 378 A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}:: 379 Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num} 381 6. Pseudowire Path Identifiers 383 The PW Path Identifier (PW_Path_ID) is structured in a similar manner 384 as the PW_Path_ID described in section 6 of [RFC6370]. Instead of 385 the Global_ID used in [RFC6370] this document uses the 386 ICC_Operator_ID to make the PW-Path_ID globally unique. In this 387 document the Attachment Individual Identifier (AII) is composed of 388 three fields. These are the ICC_Operator_ID, the Node_ID and the 389 AC_ID. The AC-ID is as defined in [RFC5003]. The complete globally 390 unique PW_Path_ID is formulated as: 392 A1-{ICC_Operator_ID::Node_ID::AC_ID}:: 393 Z9-{ICC_Operator_ID::Node_ID::AC_ID} 395 7. Maintenance Identifiers 397 The following sub-sections define the identifiers for the various 398 maintenance-related groups and entities as defined in [RFC6371]. In 399 contrast to the IDs defined in [RFC6370], this document does not 400 define separate maintenance identifiers for sections, PWs and LSPs. 402 7.1. MEG Identifiers 404 MEG_IDs for MPLS-TP Sections, LSPs and Pseudowires following ITU-T 405 conventions are based on the globally unique ICC_Operator_ID. In 406 this case, the MEG_ID is a string of up to 15 characters and consists 407 of three subfields: the Country Code (as described in Section 3), the 408 ICC (as described in Section 3) which together form the 409 ICC_Operator_ID, followed by a Unique MEG ID Code (UMC) as defined in 410 [Y.1731_cor1]. 412 The resulting MEG_ID is: 414 CC::ICC::UMC 416 To avoid the potential for the concatenation of a short (i.e. less 417 than 6 Character) ICC with a UMC not being unique the UMC MUST start 418 with the "/" character which is not allowed in the ICC itself. This 419 way, the MEG_ID can also be easily decomposed into its individual 420 components by a receiver. 422 The UMC MUST be unique within the organization identified by the 423 combination of CC and ICC. 425 The ICC_Operator_ID-based MEG_ID may be applied equally to a single 426 MPLS-TP Section, LSP or Pseudowire. 428 7.2. MEP Identifiers 430 ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs and 431 Pseudowires are formed by appending a 16-bit index to the MEG_ID 432 defined in Section 7.1 above. Within the context of a particular 433 MEG, we call the identifier associated with a MEP the MEP Index 434 (MEP_Index). The MEP_Index is administratively assigned. It is 435 encoded as a 16-bit unsigned integer and MUST be unique within the 436 MEG. An ICC_Operator_ID-based MEP_ID is structured as: 438 MEG_ID::MEP_Index 440 An ICC_Operator_ID-based MEP ID is globally unique by construction 441 given the ICC_Operator_ID-based MEG_ID's global uniqueness. 443 7.3. MIP Identifiers 445 ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs and 446 Pseudowires are formed by a global IF_ID that is obtained by 447 prefixing the identifier of the interface the MIP resides with the 448 ICC_Operator_ID as described in Section 3.1. This allows MIPs to be 449 independently identified in nodes where a per-interface MIP model is 450 used. 452 If only a per-node MIP model is used, one MIP is configured. In this 453 case, the MIP_ID is formed by using the Node_ID and an IF_Num of 0. 455 8. Security Considerations 457 This document extends an existing naming scheme and does not 458 introduce new security concerns. But, as mentioned in the security 459 considerations section of [RFC6370] protocol specifications that 460 describe use of this naming scheme may introduce security risks and 461 concerns about authentication of participants. For this reason, 462 these protocol specifications need to describe security and 463 authentication concerns that may be raised by the particular 464 mechanisms defined and how those concerns may be addressed. 466 9. IANA Considerations 468 There are no IANA actions resulting from this document. 470 10. References 472 10.1. Normative References 474 [ISO3166-1] 475 "Codes for the representation of names of countries and 476 their subdivisions -- Part 1: Country codes", ISO 3166-1. 478 [M1400] "Designations for interconnections among operators' 479 networks", ITU-T Recommendation M.1400, July 2006, 480 . 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 486 "Attachment Individual Identifier (AII) Types for 487 Aggregation", RFC 5003, September 2007. 489 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 490 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 492 [T.50] "International Reference Alphabet- 7-bit coded character 493 set for information exchange", ITU-T Recommendation ITU-T 494 T.50 (1992). 496 [Y.1731_cor1] 497 "OAM functions and mechanisms for Ethernet based networks 498 - Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731 499 (2011) Corrigendum 1. 501 10.2. Informative References 503 [CC-list] "List of Country Codes - ISO 3166 (CCs)", 504 . 506 [ICC-list] 507 "List of ITU Carrier Codes (ICCs)", 508 . 510 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 511 Maintenance Framework for MPLS-Based Transport Networks", 512 RFC 6371, September 2011. 514 Authors' Addresses 516 Rolf Winter 517 NEC 519 Email: rolf.winter@neclab.eu 521 Eric Gray 522 Ericsson 524 Email: eric.gray@ericsson.com 526 Huub van Helvoort 527 Huawei Technologies Co., Ltd. 529 Email: huub.van.helvoort@huawei.com 531 Malcolm Betts 532 ZTE 534 Email: malcolm.betts@zte.com.cn