Network Working Group
Internet Engineering Task Force (IETF)                         R. Winter
Internet-Draft
Request for Comments: 6923                                           NEC
Intended status:
Category: Standards Track                                        E. Gray
Expires: August 29, 2013
ISSN: 2070-1721                                                 Ericsson
                                                         H. van Helvoort
                                           Huawei Technologies Co., Ltd.
                                                                M. Betts
                                                                     ZTE
                                                       February 25,
                                                              April 2013

            MPLS-TP

              MPLS Transport Profile (MPLS-TP) Identifiers
                      Following ITU-T Conventions
                draft-ietf-mpls-tp-itu-t-identifiers-08

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 This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an 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 list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   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. Requirements notation  . . . . . . . . . . . . . . . . . .  4 Notation ......................................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 of identifier identifiers 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), including
   Pseudowire
   Pseudowires (PWs) and Sections which 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]." [RFC6370].

   This document solely defines those identifiers.  Their use and
   possible protocols protocol extensions to carry them is are out of the scope in 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-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-Protocol Multiprotocol Label Switching

   PW: Pseudowire

   TSB: (ITU-T) Telecommunication Standardization Bureau

   UMC: Unique MEG ID Code

1.2.  Requirements notation 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 makes modest changes to the set of provides additional identifiers supplementing those
   defined in [RFC6370].  Most changes replace certain parts in the already
   defined The identifiers that in [RFC6370] are themselves 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] 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 the Global_ID Global_ID,
   which is based on the AS Autonomous System (AS) number of the operator.
   The ITU-T however ITU-T, however, traditionally identifies operators/service 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 ICCs, all of which are
   referenced at [ICC-list], can be assigned to
   both, ITU-T members as well as non-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.
   Amongst
   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. (i.e., A-Z) or numeric (i.e. (i.e., 0-9).
   Alphabetic characters in the ICC SHOULD be represented with upper
   case 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 upper case uppercase letters (i.e., A-Z).

   The International Organization for Standardization (ISO) establishes
   internationally recognised 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 standard 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. 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 unique, the
   Global_ID is prefixed.  This memo specifies the ICC_Operator_ID as an
   alternative format which, 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 ID, and MIP ID.
   MEG, MEP MEP, and MIP identifiers Identifiers are redefined in this document (see
   Section
   Sections 7.1, Section 7.2 7.2, and Section 7.3 7.3, respectively).

4.  Node and Interface Identifiers

   The format of the node Node and interface identifiers Interface Identifiers are not changed by
   this memo except for the case when global uniqueness is required.

   [RFC6370] defines the node identifier 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 zero, however, is
   reserved and MUST NOT be used.

   This draft 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 which 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 meaning, and therefore therefore, it MUST NOT be used to
   identify an MPLS-TP interface.

   An interface identifier 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 Tunnel and LSP
   IDs.  When global uniqueness is needed, the format of these
   identifiers is as described in Section Sections 5.1 and Section 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 full tunnel Tunnel ID
   is represented by the concatenation of these two end point-specific 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_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-TP Tunnel 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 sub-sections subsections define identifiers for MPLS-TP co-routed
   bidirectional and associated bidirectional LSPs.  Since MPLS-TP Sub-
   Path
   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 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 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, 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
   entity, and therefore 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

5.2.2.  MPLS-TP Associated Bidirectional LSP Identifiers

   Associated

   An associated bidirectional LSPs need an LSP needs a separate LSP_Num for each both of
   its unidirectional
   LSP it consists of. LSPs.  The LSP number is again a 16-bit unsigned
   integer which that needs to be unique within the scope of the ingress' 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 consists of 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 Section 6 of [RFC6370].  Instead of
   the Global_ID used in [RFC6370] [RFC6370], this document uses the
   ICC_Operator_ID to make the PW-Path_ID PW_Path_ID globally unique.  In this
   document
   document, the Attachment Individual Identifier (AII) is composed of
   three fields.  These are the ICC_Operator_ID, the Node_ID Node_ID, and the
   AC_ID.  The AC-ID 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 sub-sections 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 Sections, PWs, and LSPs.

7.1.  MEG Identifiers

   MEG_IDs for MPLS-TP Sections, LSPs LSPs, and Pseudowires 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), 3) and
   the ICC (as described in Section 3) -- which together form the
   ICC_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 6 Character) characters) ICC with a UMC not being unique unique, the UMC MUST
   start with the "/" character 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 LSP, or Pseudowire.

7.2.  MEP Identifiers

   ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs LSPs, and
   Pseudowires are formed by appending a 16-bit index to the MEG_ID
   defined in Section 7.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, LSPs 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
   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 the security
   considerations
   Security 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.  References

10.1.

9.1.  Normative References

   [ISO3166-1]   "Codes for the representation of names of countries and
                 their subdivisions -- Part 1: Country codes", ISO 3166-1.
                 3166-1, 2006.

   [M1400]       "Designations for interconnections among operators'
                 networks", ITU-T Recommendation M.1400, July 2006,
              <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 Reference Alphabet- Alphabet (IRA) (Formerly
                 International Alphabet No. 5 or IA5) - Information
                 technology - 7-bit coded character set for information
                 exchange", ITU-T Recommendation ITU-T
              T.50 (1992). T.50, September 1992.

   [Y.1731_cor1] "OAM functions and mechanisms for Ethernet based
                 networks - Corrigendum 1", ITU-T Recommendation ITU-T
                 G.8013/Y.1731
              (2011) Corrigendum 1.

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 for MPLS-Based MPLS-
                 Based Transport Networks", RFC 6371, September 2011.

Authors' Addresses

   Rolf Winter
   NEC

   Email:

   EMail: rolf.winter@neclab.eu

   Eric Gray
   Ericsson

   Email:

   EMail: eric.gray@ericsson.com

   Huub van Helvoort
   Huawei Technologies Co., Ltd.

   Email:

   EMail: huub.van.helvoort@huawei.com

   Malcolm Betts
   ZTE

   Email:

   EMail: malcolm.betts@zte.com.cn