    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)",
                     <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., 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]