From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6923.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6923.txt (limited to 'doc/rfc/rfc6923.txt') diff --git a/doc/rfc/rfc6923.txt b/doc/rfc/rfc6923.txt new file mode 100644 index 0000000..0c55a9d --- /dev/null +++ b/doc/rfc/rfc6923.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Winter +Request for Comments: 6923 NEC +Category: Standards Track E. Gray +ISSN: 2070-1721 Ericsson + H. van Helvoort + Huawei Technologies Co., Ltd. + M. Betts + ZTE + May 2013 + + + MPLS Transport Profile (MPLS-TP) Identifiers + Following ITU-T Conventions + +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 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 of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6923. + + + + + + + + + + + + + +Winter, et al. Standards Track [Page 1] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + +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 ....................................................2 + 1.1. Terminology ................................................3 + 1.2. Requirements Notation ......................................4 + 1.3. Notational Conventions .....................................4 + 2. Named Entities ..................................................4 + 3. Uniquely Identifying an Operator -- the ICC_Operator_ID .........5 + 3.1. Use of the ICC_Operator_ID .................................6 + 4. Node and Interface Identifiers ..................................7 + 5. MPLS-TP Tunnel and LSP Identifiers ..............................7 + 5.1. MPLS-TP Point-to-Point Tunnel Identifiers ..................7 + 5.2. MPLS-TP LSP Identifiers ....................................8 + 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers .....8 + 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers ....9 + 6. Pseudowire Path Identifiers .....................................9 + 7. Maintenance Identifiers .........................................9 + 7.1. MEG Identifiers ...........................................10 + 7.2. MEP Identifiers ...........................................10 + 7.3. MIP Identifiers ...........................................10 + 8. Security Considerations ........................................11 + 9. References .....................................................11 + 9.1. Normative References ......................................11 + 9.2. Informative References ....................................12 + +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 of identifiers will + be used at the same time in the same domain. + + + + +Winter, et al. Standards Track [Page 2] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + + [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), including + Pseudowires (PWs) and Sections that 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]. + + This document solely defines those identifiers. Their use and + possible protocol extensions to carry them are out of the scope of + 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 Standardization + + 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: Multiprotocol Label Switching + + PW: Pseudowire + + TSB: (ITU-T) Telecommunication Standardization Bureau + + UMC: Unique MEG ID Code + + + + + +Winter, et al. Standards Track [Page 3] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + +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]. + +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 document provides additional identifiers supplementing those + defined in [RFC6370]. The identifiers in [RFC6370] are composed 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] is: + + o Global_ID + + o Node + + + + +Winter, et al. Standards Track [Page 4] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + + 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], an operator is uniquely identified by the Global_ID, + which is based on the Autonomous System (AS) number of the operator. + The ITU-T, however, traditionally identifies operators 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 that ICCs, all of which are + referenced at [ICC-list], can be assigned to ITU-T members as well as + non-members. The national regulatory authorities act as an + intermediary between the ITU/TSB and operators/service providers. + One 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., A-Z) or numeric (i.e., 0-9). + Alphabetic characters in the ICC SHOULD be represented with uppercase + 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 uppercase letters (i.e., A-Z). + + + + + + + +Winter, et al. Standards Track [Page 5] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + + The International Organization for Standardization (ISO) establishes + internationally recognized 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] in ISO 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., 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 globally unique, the + Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an + alternative format 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, MEP ID, and MIP ID. + MEG, MEP, and MIP Identifiers are redefined in this document (see + Sections 7.1, 7.2, and 7.3, respectively). + + + + + + + + + + + + + +Winter, et al. Standards Track [Page 6] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + +4. Node and Interface Identifiers + + The format of the Node and Interface Identifiers are not changed by + this memo except for the case when global uniqueness is required. + + [RFC6370] defines the Node 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 value zero, however, is + reserved and MUST NOT be used. + + This document 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 integers that 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 special meaning, and therefore, it MUST NOT be used to + identify an MPLS-TP interface. + + An Interface 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 local Tunnel and LSP + IDs. When global uniqueness is needed, the format of these + identifiers is as described in Sections 5.1 and 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), 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 full Tunnel ID + is represented by the concatenation of these two end-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} + + + + + +Winter, et al. Standards Track [Page 7] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + + Where global uniqueness is required, using ITU-T conventions, the + ICC_Operator_ID is prefixed to the 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} + + As per [RFC6370], when an MPLS-TP tunnel 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 following subsections define identifiers for MPLS-TP co-routed + bidirectional and associated bidirectional LSPs. Since MPLS-TP + Sub-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 LSP Identifier (LSP_ID) for a co-routed bidirectional LSP is + formed by adding a 16-bit unsigned integer LSP number (LSP_Num) to + the Tunnel 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] notes 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 single + entity, and therefore, 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 + + + + + + + + +Winter, et al. Standards Track [Page 8] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + +5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers + + An associated bidirectional LSP needs a separate LSP_Num for both of + its unidirectional LSPs. The LSP number is again a 16-bit unsigned + integer that needs to be unique within the scope of the 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 + LSP is 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 in Section 6 of [RFC6370]. Instead of + the Global_ID used in [RFC6370], this document uses the + ICC_Operator_ID to make the PW_Path_ID globally unique. In this + document, the Attachment Individual Identifier (AII) is composed of + three fields. These are the ICC_Operator_ID, the Node_ID, and the + AC_ID. The AC_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 following subsections 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 for Sections, PWs, and LSPs. + + + + + +Winter, et al. Standards Track [Page 9] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + +7.1. MEG Identifiers + + MEG_IDs for MPLS-TP Sections, LSPs, and PWs 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 Section 3) and + the ICC (as described in Section 3) -- which together form the + 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., less + than 6 characters) ICC with a UMC not being unique, the UMC MUST + start with the "/" character, 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, LSP, or Pseudowire. + +7.2. MEP Identifiers + + ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs, and + Pseudowires are formed by appending a 16-bit index to the MEG_ID + defined in Section 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, LSPs, and + Pseudowires are formed by a global IF_ID that is obtained by + prefixing the identifier of the interface on which the MIP resides + + + + + +Winter, et al. Standards Track [Page 10] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + + 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. However, as mentioned in the + Security Considerations section of [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. References + +9.1. Normative References + + [ISO3166-1] "Codes for the representation of names of countries and + their subdivisions -- Part 1: Country codes", ISO + 3166-1, 2006. + + [M1400] "Designations for interconnections among operators' + 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. + + [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 Reference Alphabet (IRA) (Formerly + International Alphabet No. 5 or IA5) - Information + technology - 7-bit coded character set for information + exchange", ITU-T Recommendation T.50, September 1992. + + [Y.1731_cor1] "OAM functions and mechanisms for Ethernet based + networks - Corrigendum 1", ITU-T Recommendation + G.8013/Y.1731 Corrigendum 1, October 2011. + + + +Winter, et al. Standards Track [Page 11] + +RFC 6923 MPLS-TP ITU-T IDs May 2013 + + +9.2. Informative References + + [CC-list] "List of Country Codes - ISO 3166 (CCs)", + . + + [ICC-list] "List of ITU Carrier Codes (ICCs)", + . + + [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, + Administration, and Maintenance Framework for MPLS- + Based Transport Networks", RFC 6371, September 2011. + +Authors' Addresses + + Rolf Winter + NEC + + EMail: rolf.winter@neclab.eu + + + Eric Gray + 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 + + + + + + + + + + + + + + + +Winter, et al. Standards Track [Page 12] + -- cgit v1.2.3