RFC 6923

MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions

📅 published May 2013, from ietf

RFC 6923: MPLS-TP Identifiers Following ITU-T Conventions 💖

Okay bestie, here's the vibe check. This is RFC 6923, published in May 2013 on the Standards Track (ISSN 2070-1721). The authors are R. Winter (NEC), E. Gray (Ericsson), H. van Helvoort (Huawei Technologies Co., Ltd.), and M. Betts (ZTE). The title block doesn't list any obsoletes or updates, so it doesn't replace or amend anything else. 🎀

Abstract

okay so this doc adds new identifiers to MPLS-TP (the Transport Profile of Multiprotocol Label Switching) 🦋 IP/MPLS-style identifiers were already defined, so this one adds a set that follows the format the ITU-T usually uses. Those extra identifiers are for MPLS-TP management and OAM (Operations, Administration, and Maintenance) functions.

Status of This Memo

This is an Internet Standards Track document. 🌸

It's a product of the IETF (Internet Engineering Task Force), it represents the consensus of the IETF community, it got public review, and the IESG (Internet Engineering Steering Group) approved it for publication. For more on Internet Standards, check Section 2 of RFC 5741.

For the current status, errata, and feedback info, go to http://www.rfc-editor.org/info/rfc6923. 🔥

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 doc adds to the starter set of identifiers for MPLS-TP that's defined in [RFC6370] 🧚 It does this by adding new identifiers based on ITU-T conventions. The two types are not meant to be used at the same time in the same domain, so pick one lane. 🛣️

[RFC6370] defines a set of MPLS-TP transport and management entity identifiers for bidirectional (co-routed and associated) point-to-point MPLS-TP Label Switched Paths (LSPs), including Pseudowires (PWs) and Sections, all following the IP/MPLS conventions. 💜

This document gives an alternative way to make unambiguous identifiers for operators and service providers using ITU-T conventions. It also shows how those operator and service provider identifiers can make unambiguous identifiers for the existing set of identifiable MPLS-TP entities from [RFC6370]. 🍓

This document only defines the identifiers. How they get used, and any protocol extensions that might carry them, are out of scope here. 🙈

We follow the notational convention from [RFC6370], which is copied into 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

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 from [RFC6370]. Here's the lowdown:

All multiple-word atomic identifiers use underscores (_) to join the words. A lot of identifiers are made of other identifiers, and those get written by listing them with double-colon :: notation.

If the same identifier type shows up more than once in a concatenation, a prefix joined with a dash (-) qualifies each one. For example, A1-Node_ID is the Node_ID of a node called A1. 🧩

The notation sets a preferred field order. A1 marks the lower sort order of a field (or group of fields), and Z9 marks the higher sort order. The sort is alphanumeric or numeric, depending on how the field is defined. When the sort applies to a group of fields, that group is wrapped in {...}.

Heads up though: uniqueness doesn't depend on the order. It depends on the uniqueness and scoping of the fields that make up the identifier. The preferred order also isn't meant to box in protocol designs by forcing one field sequence, or even which fields show up in which objects. You do you, within limits! 🌈

2. Named Entities 🎀

This document adds more identifiers on top of the ones defined in [RFC6370]. The identifiers in [RFC6370] are built from a set of atomic identifiers, and this document defines some new atomic identifiers that can swap in for some of the existing ones to make new identifiers. The identifier set defined in [RFC6370] is:

  • Global_ID
  • Node
  • Interface
  • Tunnel
  • LSP
  • PW
  • MEG
  • MEP
  • MIP

The next sections go through this list one by one. The structure of this document loosely follows [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 operator's Autonomous System (AS) number. The ITU-T, on the other hand, has traditionally identified operators and service providers with the ITU Carrier Code (ICC), specified in [M1400]. 🌍

The ITU-T Telecommunication Standardization Bureau (TSB) keeps a list of assigned ICCs [ICC-list]. ICCs, all of which are referenced at [ICC-list], can go to ITU-T members and non-members alike. National regulatory authorities sit in the middle between the ITU/TSB and the operators/service providers. One of their jobs when assigning an ICC is making sure the Carrier Codes are unique within their country. That uniqueness is what makes a globally unique ICC-based operator ID possible. ✨

An ICC is a string of one to six characters. Each character is either alphabetic (A-Z) or numeric (0-9). Alphabetic characters in the ICC SHOULD be written as uppercase letters. 🔠

Global uniqueness comes from putting the ICC together with a Country Code (CC). The Country Code (alpha-2) is a string of two alphabetic characters, written in uppercase (A-Z). 🗺️

The International Organization for Standardization (ISO) sets internationally recognized codes for the names of countries, territories, areas of geographical interest, and their subdivisions. These are 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 like this:

CC::ICC

3.1. Use of the ICC_Operator_ID 🦋

The ICC_Operator_ID is used as a replacement for the Global_ID specified in [RFC6370]. In other words, its job is to give a globally unique context for other MPLS-TP identifiers. 🔑

Here's an example. In [RFC6370], an Interface Identifier (IF_ID) is 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 that IF_ID globally unique, the Global_ID gets prefixed. This memo specifies the ICC_Operator_ID as an alternative format that gets prefixed onto the IF_ID, just like the Global_ID does. 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 one exception: the MEG ID, MEP ID, and MIP ID. Those get redefined in this document (see Sections 7.1, 7.2, and 7.3, respectively). 🌸

part 1 ends here, and part 2 is coming up with the rest of the identifiers, the security stuff, and the references! stay tuned 💖🧚

4. Node and Interface Identifiers ✨

okay so the Node and Interface Identifiers keep their format in this memo 💖 the only time anything changes is when global uniqueness is needed 🫶

[RFC6370] defines the Node Identifier (Node_ID) as a unique 32-bit value that the operator assigns within the scope of a Global_ID 🦋 The structure of the Node_ID isn't defined because the operator gets to pick an appropriate value 💅 The value zero is reserved, though, so it MUST NOT be used 🙈

This document doesn't change that definition. But if global uniqueness is required, the Node_ID gets prefixed with the ICC_Operator_ID as defined in Section 3 ✨

[RFC6370] also defines interface numbers (IF_Num) as 32-bit unsigned integers that the operator can freely assign. They must be unique within the scope of the respective Node_ID 🌸 The IF_Num value 0 is special, so 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. You make it by concatenating the Node_ID with the IF_Num, which gives you a 64-bit identifier written as Node_ID::IF_Num 🎀

If global uniqueness of the IF_ID is needed, it can be assured by prefixing the identifier with the ICC_Operator_ID 🧚

5. MPLS-TP Tunnel and LSP Identifiers 🌈

This document doesn't change the definition for local Tunnel and LSP IDs 💜 When global uniqueness is needed, the format of these identifiers is 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 that's unique within the context of the Node_ID. A full Tunnel ID is 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}

Where global uniqueness is required, using ITU-T conventions, the ICC_Operator_ID is prefixed to the Tunnel_ID. So 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. So 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, so 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 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. So 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 that the associated bidirectional LSP is made of 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. So 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 way to 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 ✨ Here, the Attachment Individual Identifier (AII) is made of three fields: 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]. Unlike the IDs defined in [RFC6370], this document does not define separate maintenance identifiers for Sections, PWs, and LSPs 🌸

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 with 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 starting with "/" is the whole trick here, bestie. no shortcuts 💀

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, the identifier associated with a MEP is called the MEP Index (MEP_Index). The MEP_Index is administratively assigned. It's 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 global uniqueness of the ICC_Operator_ID-based MEG_ID ✨

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's obtained by prefixing the identifier of the interface where the MIP resides with the ICC_Operator_ID, as described in Section 3.1 🎀 This lets MIPs 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 the security and authentication concerns that may be raised by the particular mechanisms defined, and how those concerns may be addressed 😭

ngl this is the part where the protocol writers have to do their homework. the naming scheme itself isn't the problem, but whatever gets built on top of it needs to deal with auth and security head-on 💀

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.

9.2. Informative References

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

📦 where this page comes from