summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6923.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6923.txt')
-rw-r--r--doc/rfc/rfc6923.txt675
1 files changed, 675 insertions, 0 deletions
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)",
+ <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]
+