draft-ietf-mpls-tp-itu-t-identifiers-08.txt   rfc6923.txt 
Network Working Group R. Winter Internet Engineering Task Force (IETF) R. Winter
Internet-Draft NEC Request for Comments: 6923 NEC
Intended status: Standards Track E. Gray Category: Standards Track E. Gray
Expires: August 29, 2013 Ericsson ISSN: 2070-1721 Ericsson
H. van Helvoort H. van Helvoort
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
M. Betts M. Betts
ZTE ZTE
February 25, 2013 May 2013
MPLS-TP Identifiers Following ITU-T Conventions MPLS Transport Profile (MPLS-TP) Identifiers
draft-ietf-mpls-tp-itu-t-identifiers-08 Following ITU-T Conventions
Abstract Abstract
This document specifies an extension to the identifiers to be used in This document specifies an extension to the identifiers to be used in
the Transport Profile of Multiprotocol Label Switching (MPLS-TP). the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
Identifiers that follow IP/MPLS conventions have already been Identifiers that follow IP/MPLS conventions have already been
defined. This memo augments that set of identifiers for MPLS-TP defined. This memo augments that set of identifiers for MPLS-TP
management and Operations, Administration, and Maintenance (OAM) management and Operations, Administration, and Maintenance (OAM)
functions to include identifier information in a format typically functions to include identifier information in a format typically
used by the International Telecommunication Union Telecommunication used by the International Telecommunication Union Telecommunication
Standardization Sector (ITU-T). Standardization Sector (ITU-T).
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 29, 2013. 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.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation ......................................4
1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.3. Notational Conventions .....................................4
2. Named Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Named Entities ..................................................4
3. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 5 3. Uniquely Identifying an Operator -- the ICC_Operator_ID .........5
3.1. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . 6 3.1. Use of the ICC_Operator_ID .................................6
4. Node and Interface Identifiers . . . . . . . . . . . . . . . . 6 4. Node and Interface Identifiers ..................................7
5. MPLS-TP Tunnel and LSP Identifiers . . . . . . . . . . . . . . 7 5. MPLS-TP Tunnel and LSP Identifiers ..............................7
5.1. MPLS-TP Point-to-Point Tunnel Identifiers . . . . . . . . 7 5.1. MPLS-TP Point-to-Point Tunnel Identifiers ..................7
5.2. MPLS-TP LSP Identifiers . . . . . . . . . . . . . . . . . 8 5.2. MPLS-TP LSP Identifiers ....................................8
5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers . . . 8 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers .....8
5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers . . 8 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers ....9
6. Pseudowire Path Identifiers . . . . . . . . . . . . . . . . . 9 6. Pseudowire Path Identifiers .....................................9
7. Maintenance Identifiers . . . . . . . . . . . . . . . . . . . 9 7. Maintenance Identifiers .........................................9
7.1. MEG Identifiers . . . . . . . . . . . . . . . . . . . . . 9 7.1. MEG Identifiers ...........................................10
7.2. MEP Identifiers . . . . . . . . . . . . . . . . . . . . . 10 7.2. MEP Identifiers ...........................................10
7.3. MIP Identifiers . . . . . . . . . . . . . . . . . . . . . 10 7.3. MIP Identifiers ...........................................10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations ........................................11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References .....................................................11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References ......................................11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References ....................................12
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document augments the initial set of identifiers to be used in This document augments the initial set of identifiers to be used in
the Transport Profile of Multiprotocol Label Switching (MPLS-TP) the Transport Profile of Multiprotocol Label Switching (MPLS-TP)
defined in [RFC6370] by adding new identifiers based on ITU-T defined in [RFC6370] by adding new identifiers based on ITU-T
conventions. It is not intended that both types of identifier will conventions. It is not intended that both types of identifiers will
be used at the same time in the same domain. be used at the same time in the same domain.
[RFC6370] defines a set of MPLS-TP transport and management entity [RFC6370] defines a set of MPLS-TP transport and management entity
identifiers to support bidirectional (co-routed and associated) identifiers to support bidirectional (co-routed and associated)
point-to-point MPLS-TP Label Switched Paths (LSPs), including point-to-point MPLS-TP Label Switched Paths (LSPs), including
Pseudowire (PWs) and Sections which follow the IP/MPLS conventions. Pseudowires (PWs) and Sections that follow the IP/MPLS conventions.
This document specifies an alternative way to generate unambiguous This document specifies an alternative way to generate unambiguous
identifiers for operators/service providers based on ITU-T identifiers for operators/service providers based on ITU-T
conventions and specifies how these operator/service provider conventions and specifies how these operator/service provider
identifiers can be used to generate unambiguous identifiers for the identifiers can be used to generate unambiguous identifiers for the
existing set of identifiable MPLS-TP entities described in existing set of identifiable MPLS-TP entities described in [RFC6370].
[RFC6370]."
This document solely defines those identifiers. Their use and This document solely defines those identifiers. Their use and
possible protocols extensions to carry them is out of scope in this possible protocol extensions to carry them are out of the scope of
document. this document.
In this document, we follow the notational convention laid out in In this document, we follow the notational convention laid out in
[RFC6370], which is included in this document for convenience in [RFC6370], which is included in this document for convenience in
Section 1.3. Section 1.3.
1.1. Terminology 1.1. Terminology
CC: Country Code CC: Country Code
ICC: ITU Carrier Code ICC: ITU Carrier Code
ISO: International Organization for Standardization ISO: International Organization for Standardization
ITU-T: International Telecommunication Union Telecommunication ITU: International Telecommunication Union
Standardization Sector
ITU-T: ITU Telecommunication Standardization Sector
LSP: Label Switched Path LSP: Label Switched Path
MEG: Maintenance Entity Group MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point MIP: Maintenance Entity Group Intermediate Point
MPLS: Multi-Protocol Label Switching MPLS: Multiprotocol Label Switching
PW: Pseudowire PW: Pseudowire
TSB: (ITU-T) Telecommunication Standardization Bureau TSB: (ITU-T) Telecommunication Standardization Bureau
UMC: Unique MEG ID Code UMC: Unique MEG ID Code
1.2. Requirements notation 1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Notational Conventions 1.3. Notational Conventions
All multiple-word atomic identifiers use underscores (_) between the This document uses the notational conventions laid out in [RFC6370]:
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 All multiple-word atomic identifiers use underscores (_) between
concatenation, they are qualified by a prefix joined to the the words to join the words. Many of the identifiers are composed
identifier by a dash (-). For example, A1-Node_ID is the Node_ID of of a set of other identifiers. These are expressed by listing the
a node referred to as A1. latter identifiers joined with double-colon "::" notation.
The notation defines a preferred ordering of the fields. Where the same identifier type is used multiple times in a
Specifically, the designation A1 is used to indicate the lower sort concatenation, they are qualified by a prefix joined to the
order of a field or set of fields and Z9 is used to indicate the identifier by a dash (-). For example, A1-Node_ID is the Node_ID
higher sort order of the same. The sort is either alphanumeric or of a node referred to as A1.
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 The notation defines a preferred ordering of the fields.
on the ordering, but rather, upon the uniqueness and scoping of the Specifically, the designation A1 is used to indicate the lower
fields that compose the identifier. Further, the preferred ordering sort order of a field or set of fields and Z9 is used to indicate
is not intended to constrain protocol designs by dictating a the higher sort order of the same. The sort is either
particular field sequence or even what fields appear in which alphanumeric or numeric depending on the field's definition.
objects. 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 2. Named Entities
This document makes modest changes to the set of identifiers defined This document provides additional identifiers supplementing those
in [RFC6370]. Most changes replace certain parts in the already defined in [RFC6370]. The identifiers in [RFC6370] are composed of a
defined identifiers that are themselves composed of a set of atomic set of atomic identifiers, and this document defines some new atomic
identifiers. The set of identifiers defined in [RFC6370] are: 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 Global_ID
o Node o Node
o Interface o Interface
o Tunnel o Tunnel
o LSP o LSP
o PW o PW
o MEG o MEG
skipping to change at page 5, line 27 skipping to change at page 5, line 22
o MEG o MEG
o MEP o MEP
o MIP o MIP
The following sections go through this list of identifiers one by The following sections go through this list of identifiers one by
one. The structure of this document is loosely aligned with the one. The structure of this document is loosely aligned with the
structure of [RFC6370]. structure of [RFC6370].
3. Uniquely Identifying an Operator - the ICC_Operator_ID 3. Uniquely Identifying an Operator -- the ICC_Operator_ID
In [RFC6370] an operator is uniquely identified by the Global_ID In [RFC6370], an operator is uniquely identified by the Global_ID,
which is based on the AS number of the operator. The ITU-T however which is based on the Autonomous System (AS) number of the operator.
traditionally identifies operators/service providers based on the ITU The ITU-T, however, traditionally identifies operators and service
Carrier Code (ICC) as specified in [M1400]. providers based on the ITU Carrier Code (ICC) as specified in
[M1400].
The ITU-T Telecommunication Standardization Bureau (TSB) maintains a The ITU-T Telecommunication Standardization Bureau (TSB) maintains a
list of assigned ICCs [ICC-list]. Note that ICCs can be assigned to list of assigned ICCs [ICC-list]. Note that ICCs, all of which are
both, ITU-T members as well as non-members, all of which are referenced at [ICC-list], can be assigned to ITU-T members as well as
referenced at [ICC-list]. The national regulatory authorities act as non-members. The national regulatory authorities act as an
an intermediary between the ITU/TSB and operators/service providers. intermediary between the ITU/TSB and operators/service providers.
Amongst the things that the national authorities are responsible for One of the things that the national authorities are responsible for
in the process of assigning an ICC is to ensure that the Carrier in the process of assigning an ICC is to ensure that the Carrier
Codes are unique within their country. This uniqueness assumption is Codes are unique within their country. This uniqueness assumption is
the basis for creating a globally unique ICC-based operator ID. the basis for creating a globally unique ICC-based operator ID.
The ICC itself is a string of one to six characters, each character 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). being either alphabetic (i.e., A-Z) or numeric (i.e., 0-9).
Alphabetic characters in the ICC SHOULD be represented with upper Alphabetic characters in the ICC SHOULD be represented with uppercase
case letters. letters.
Global uniqueness is assured by concatenating the ICC with a Country Global uniqueness is assured by concatenating the ICC with a Country
Code (CC). The Country Code (alpha-2) is a string of two alphabetic Code (CC). The Country Code (alpha-2) is a string of two alphabetic
characters represented with upper case letters (i.e., A-Z). characters represented with uppercase letters (i.e., A-Z).
The International Organization for Standardization (ISO) establishes The International Organization for Standardization (ISO) establishes
internationally recognised codes for the representation of names of internationally recognized codes for the representation of names of
countries, territories or areas of geographical interest, and their countries, territories or areas of geographical interest, and their
subdivisions, published as a list of CCs [CC-list] in standard ISO subdivisions, published as a list of CCs [CC-list] in ISO Standard
3166-1 [ISO3166-1]. 3166-1 [ISO3166-1].
The ICC and CC characters are coded according to ITU-T Recommendation The ICC and CC characters are coded according to ITU-T Recommendation
T.50 [T.50]. T.50 [T.50].
Together, the CC and the ICC form the ICC_Operator_ID as: Together, the CC and the ICC form the ICC_Operator_ID as:
CC::ICC CC::ICC
3.1. Use of the ICC_Operator_ID 3.1. Use of the ICC_Operator_ID
The ICC_Operator_ID is used as a replacement for the Global_ID as 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 specified in [RFC6370], i.e., its purpose is to provide a globally
unique context for other MPLS-TP identifiers. unique context for other MPLS-TP identifiers.
As an example, an Interface Identifier (IF_ID) in [RFC6370] is As an example, an Interface Identifier (IF_ID) in [RFC6370] is
specified as the concatenation of the Node_ID (a unique 32-bit value 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 assigned by the operator) and the Interface Number (IF_Num, a 32-bit
unsigned integer assigned by the operator that is unique within the unsigned integer assigned by the operator that is unique within the
scope of a Node_ID). To make this IF_ID globally unique 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 Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an
alternative format which, just like the Global_ID, is prefixed to the alternative format that, just like the Global_ID, is prefixed to the
IF_ID. Using the notation from RFC 6370 [RFC6370]: IF_ID. Using the notation from RFC 6370 [RFC6370]:
Global_ID::Node_ID::IF_Num Global_ID::Node_ID::IF_Num
is functionally equivalent to: is functionally equivalent to:
ICC_Operator_ID::Node_ID::IF_Num ICC_Operator_ID::Node_ID::IF_Num
The same substitution procedure applies to all identifiers specified The same substitution procedure applies to all identifiers specified
in [RFC6370] with the exception of the MEG ID, MEP ID and MIP ID. 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 MEG, MEP, and MIP Identifiers are redefined in this document (see
Section 7.1, Section 7.2 and Section 7.3 respectively). Sections 7.1, 7.2, and 7.3, respectively).
4. Node and Interface Identifiers 4. Node and Interface Identifiers
The format of the node and interface identifiers are not changed by The format of the Node and Interface Identifiers are not changed by
this memo except for the case when global uniqueness is required. this memo except for the case when global uniqueness is required.
[RFC6370] defines the node identifier (Node_ID) as a unique 32-bit [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 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 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 operator to choose an appropriate value. The value zero, however, is
reserved and MUST NOT be used. reserved and MUST NOT be used.
This draft does not change the above definition. However, in case This document does not change the above definition. However, in case
global uniqueness is required, the Node_ID is prefixed with the global uniqueness is required, the Node_ID is prefixed with the
ICC_Operator_ID as defined in Section 3. ICC_Operator_ID as defined in Section 3.
[RFC6370] further defines interface numbers (IF_Num) as 32-bit [RFC6370] further defines interface numbers (IF_Num) as 32-bit
unsigned integers which can be freely assigned by the operator and 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 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 value 0 has a special meaning, and therefore, it MUST NOT be used to
identify an MPLS-TP interface. identify an MPLS-TP interface.
An interface identifier (IF_ID) identifies an interface uniquely An Interface Identifier (IF_ID) identifies an interface uniquely
within the context of an ICC_Operator_ID. It is formed by 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 concatenating the Node_ID with the IF_Num to result in a 64-bit
identifier formed as Node_ID::IF_Num. identifier formed as Node_ID::IF_Num.
Global uniqueness of the IF_ID, if needed, can be assured by Global uniqueness of the IF_ID, if needed, can be assured by
prefixing the identifier with the ICC_Operator_ID. prefixing the identifier with the ICC_Operator_ID.
5. MPLS-TP Tunnel and LSP Identifiers 5. MPLS-TP Tunnel and LSP Identifiers
This document does not change the definition for local tunnel and LSP This document does not change the definition for local Tunnel and LSP
IDs. When global uniqueness is needed, the format of these IDs. When global uniqueness is needed, the format of these
identifiers is as described in Section 5.1 and Section 5.2 below. identifiers is as described in Sections 5.1 and 5.2.
5.1. MPLS-TP Point-to-Point Tunnel Identifiers 5.1. MPLS-TP Point-to-Point Tunnel Identifiers
Tunnel IDs (Tunnel_ID) are based on the end points' Node_IDs and Tunnel IDs (Tunnel_ID) are based on the end points' Node_IDs and
locally assigned tunnel numbers (Tunnel_Num) which identify the locally assigned tunnel numbers (Tunnel_Num), which identify the
tunnel at each end point. The tunnel number is a 16-bit unsigned 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 integer unique within the context of the Node_ID. A full Tunnel ID
is represented by the concatenation of these two end point-specific is represented by the concatenation of these two end-point-specific
identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID
is: is:
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}
Where global uniqueness is required, using ITU-T conventions, the Where global uniqueness is required, using ITU-T conventions, the
ICC_Operator_ID is prefixed to the Tunnel_IDs. Thus, a globally ICC_Operator_ID is prefixed to the Tunnel_ID. Thus, a globally
unique Tunnel_ID becomes: unique Tunnel_ID becomes:
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: Z9- A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
{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 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. assigned a unique IF_ID at each end point as defined in Section 4.
5.2. MPLS-TP LSP Identifiers 5.2. MPLS-TP LSP Identifiers
The following sub-sections define identifiers for MPLS-TP co-routed The following subsections define identifiers for MPLS-TP co-routed
bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub- bidirectional and associated bidirectional LSPs. Since MPLS-TP
Path Maintenance Entities (SPMEs) are also LSPs, they use the same Sub-Path Maintenance Entities (SPMEs) are also LSPs, they use the
form of IDs. same form of IDs.
5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers
The LSP identifier (LSP_ID) for a co-routed bidirectional LSP is 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 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 the Tunnel ID. Consequently, the format of an MPLS-TP co-routed
bidirectional LSP_ID is: bidirectional LSP_ID is:
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
[RFC6370] notes that, the "uniqueness of identifiers does not depend [RFC6370] notes that the "uniqueness of identifiers does not depend
on the A1/Z9 sort ordering". on the A1/Z9 sort ordering".
A co-routed bidirectional LSP is provisioned or signaled as a single A co-routed bidirectional LSP is provisioned or signaled as a single
entity and therefore a single LSP_Num is used for both unidirectional entity, and therefore, a single LSP_Num is used for both
LSPs. These can be referenced by the following identifiers: unidirectional LSPs. These can be referenced by the following
identifiers:
A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and
Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively. Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively.
Global uniqueness is accomplished by using globally unique Node_IDs. Global uniqueness is accomplished by using globally unique Node_IDs.
A globally unique LSP_ID consequently becomes: A globally unique LSP_ID consequently becomes:
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num
5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers
Associated bidirectional LSPs need an LSP_Num for each unidirectional An associated bidirectional LSP needs a separate LSP_Num for both of
LSP it consists of. The LSP number is again a 16-bit unsigned its unidirectional LSPs. The LSP number is again a 16-bit unsigned
integer which needs to be unique within the scope of the ingress' integer that needs to be unique within the scope of the ingress's
Tunnel_Num. Consequently, the format of an MPLS-TP associated Tunnel_Num. Consequently, the format of an MPLS-TP associated
bidirectional LSP_ID is: bidirectional LSP_ID is:
A1-{Node_ID::Tunnel_Num::LSP_Num}:: A1-{Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Node_ID::Tunnel_Num::LSP_Num} Z9-{Node_ID::Tunnel_Num::LSP_Num}
Each of the unidirectional LSPs of which the associated bidirectional Each of the unidirectional LSPs of which the associated bidirectional
LSP consists of may be referenced by one of the following LSP is composed may be referenced by one of the following
identifiers: identifiers:
A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and 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. Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID, respectively.
A globally unique LSP_ID is constructed using the globally unique A globally unique LSP_ID is constructed using the globally unique
Node_IDs as defined before. Consequently, a globally unique LSP_ID Node_IDs as defined before. Consequently, a globally unique LSP_ID
is formulated as: is formulated as:
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}:: A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num} Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}
6. Pseudowire Path Identifiers 6. Pseudowire Path Identifiers
The PW Path Identifier (PW_Path_ID) is structured in a similar manner 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 as the PW_Path_ID described in Section 6 of [RFC6370]. Instead of
the Global_ID used in [RFC6370] this document uses the the Global_ID used in [RFC6370], this document uses the
ICC_Operator_ID to make the PW-Path_ID globally unique. In this ICC_Operator_ID to make the PW_Path_ID globally unique. In this
document the Attachment Individual Identifier (AII) is composed of document, the Attachment Individual Identifier (AII) is composed of
three fields. These are the ICC_Operator_ID, the Node_ID and the 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 AC_ID. The AC_ID is as defined in [RFC5003]. The complete globally
unique PW_Path_ID is formulated as: unique PW_Path_ID is formulated as:
A1-{ICC_Operator_ID::Node_ID::AC_ID}:: A1-{ICC_Operator_ID::Node_ID::AC_ID}::
Z9-{ICC_Operator_ID::Node_ID::AC_ID} Z9-{ICC_Operator_ID::Node_ID::AC_ID}
7. Maintenance Identifiers 7. Maintenance Identifiers
The following sub-sections define the identifiers for the various The following subsections define the identifiers for the various
maintenance-related groups and entities as defined in [RFC6371]. In maintenance-related groups and entities as defined in [RFC6371]. In
contrast to the IDs defined in [RFC6370], this document does not contrast to the IDs defined in [RFC6370], this document does not
define separate maintenance identifiers for sections, PWs and LSPs. define separate maintenance identifiers for Sections, PWs, and LSPs.
7.1. MEG Identifiers 7.1. MEG Identifiers
MEG_IDs for MPLS-TP Sections, LSPs and Pseudowires following ITU-T MEG_IDs for MPLS-TP Sections, LSPs, and PWs following ITU-T
conventions are based on the globally unique ICC_Operator_ID. In 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 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), the of three subfields: the Country Code (as described in Section 3) and
ICC (as described in Section 3) which together form the 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 ICC_Operator_ID -- followed by a Unique MEG ID Code (UMC) as defined
[Y.1731_cor1]. in [Y.1731_cor1].
The resulting MEG_ID is: The resulting MEG_ID is:
CC::ICC::UMC CC::ICC::UMC
To avoid the potential for the concatenation of a short (i.e. less To avoid the potential for the concatenation of a short (i.e., less
than 6 Character) ICC with a UMC not being unique the UMC MUST start than 6 characters) ICC with a UMC not being unique, the UMC MUST
with the "/" character which is not allowed in the ICC itself. This start with the "/" character, which is not allowed in the ICC itself.
way, the MEG_ID can also be easily decomposed into its individual This way, the MEG_ID can also be easily decomposed into its
components by a receiver. individual components by a receiver.
The UMC MUST be unique within the organization identified by the The UMC MUST be unique within the organization identified by the
combination of CC and ICC. combination of CC and ICC.
The ICC_Operator_ID-based MEG_ID may be applied equally to a single The ICC_Operator_ID-based MEG_ID may be applied equally to a single
MPLS-TP Section, LSP or Pseudowire. MPLS-TP Section, LSP, or Pseudowire.
7.2. MEP Identifiers 7.2. MEP Identifiers
ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs and 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 Pseudowires are formed by appending a 16-bit index to the MEG_ID
defined in Section 7.1 above. Within the context of a particular defined in Section 7.1. Within the context of a particular MEG, we
MEG, we call the identifier associated with a MEP the MEP Index call the identifier associated with a MEP the MEP Index (MEP_Index).
(MEP_Index). The MEP_Index is administratively assigned. It is The MEP_Index is administratively assigned. It is encoded as a
encoded as a 16-bit unsigned integer and MUST be unique within the 16-bit unsigned integer and MUST be unique within the MEG. An
MEG. An ICC_Operator_ID-based MEP_ID is structured as: ICC_Operator_ID-based MEP_ID is structured as:
MEG_ID::MEP_Index MEG_ID::MEP_Index
An ICC_Operator_ID-based MEP ID is globally unique by construction An ICC_Operator_ID-based MEP ID is globally unique by construction
given the ICC_Operator_ID-based MEG_ID's global uniqueness. given the ICC_Operator_ID-based MEG_ID's global uniqueness.
7.3. MIP Identifiers 7.3. MIP Identifiers
ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs and ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs, and
Pseudowires are formed by a global IF_ID that is obtained by Pseudowires are formed by a global IF_ID that is obtained by
prefixing the identifier of the interface the MIP resides with the prefixing the identifier of the interface on which the MIP resides
ICC_Operator_ID as described in Section 3.1. This allows MIPs to be with the ICC_Operator_ID as described in Section 3.1. This allows
independently identified in nodes where a per-interface MIP model is MIPs to be independently identified in nodes where a per-interface
used. MIP model is used.
If only a per-node MIP model is used, one MIP is configured. In this 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. case, the MIP_ID is formed by using the Node_ID and an IF_Num of 0.
8. Security Considerations 8. Security Considerations
This document extends an existing naming scheme and does not This document extends an existing naming scheme and does not
introduce new security concerns. But, as mentioned in the security introduce new security concerns. However, as mentioned in the
considerations section of [RFC6370] protocol specifications that Security Considerations section of [RFC6370], protocol specifications
describe use of this naming scheme may introduce security risks and that describe the use of this naming scheme may introduce security
concerns about authentication of participants. For this reason, risks and concerns about authentication of participants. For this
these protocol specifications need to describe security and reason, these protocol specifications need to describe security and
authentication concerns that may be raised by the particular authentication concerns that may be raised by the particular
mechanisms defined and how those concerns may be addressed. mechanisms defined and how those concerns may be addressed.
9. IANA Considerations 9. References
There are no IANA actions resulting from this document.
10. References
10.1. Normative References 9.1. Normative References
[ISO3166-1] [ISO3166-1] "Codes for the representation of names of countries and
"Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO
their subdivisions -- Part 1: Country codes", ISO 3166-1. 3166-1, 2006.
[M1400] "Designations for interconnections among operators' [M1400] "Designations for interconnections among operators'
networks", ITU-T Recommendation M.1400, July 2006, networks", ITU-T Recommendation M.1400, July 2006.
<http://www.itu.int/rec/T-REC-M.1400-200607-I/en>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for "Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007. Aggregation", RFC 5003, September 2007.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. Profile (MPLS-TP) Identifiers", RFC 6370, September
2011.
[T.50] "International Reference Alphabet- 7-bit coded character [T.50] "International Reference Alphabet (IRA) (Formerly
set for information exchange", ITU-T Recommendation ITU-T International Alphabet No. 5 or IA5) - Information
T.50 (1992). technology - 7-bit coded character set for information
exchange", ITU-T Recommendation T.50, September 1992.
[Y.1731_cor1] [Y.1731_cor1] "OAM functions and mechanisms for Ethernet based
"OAM functions and mechanisms for Ethernet based networks networks - Corrigendum 1", ITU-T Recommendation
- Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731 G.8013/Y.1731 Corrigendum 1, October 2011.
(2011) Corrigendum 1.
10.2. Informative References 9.2. Informative References
[CC-list] "List of Country Codes - ISO 3166 (CCs)", [CC-list] "List of Country Codes - ISO 3166 (CCs)",
<http://www.iso.org/iso/country_codes.htm>. <http://www.iso.org/iso/country_codes.htm>.
[ICC-list] [ICC-list] "List of ITU Carrier Codes (ICCs)",
"List of ITU Carrier Codes (ICCs)", <http://www.itu.int/oth/T0201>.
<http://www.itu.int/oth/T0201>.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
Maintenance Framework for MPLS-Based Transport Networks", Administration, and Maintenance Framework for MPLS-
RFC 6371, September 2011. Based Transport Networks", RFC 6371, September 2011.
Authors' Addresses Authors' Addresses
Rolf Winter Rolf Winter
NEC NEC
Email: rolf.winter@neclab.eu EMail: rolf.winter@neclab.eu
Eric Gray Eric Gray
Ericsson Ericsson
Email: eric.gray@ericsson.com EMail: eric.gray@ericsson.com
Huub van Helvoort Huub van Helvoort
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: huub.van.helvoort@huawei.com EMail: huub.van.helvoort@huawei.com
Malcolm Betts Malcolm Betts
ZTE ZTE
Email: malcolm.betts@zte.com.cn EMail: malcolm.betts@zte.com.cn
 End of changes. 83 change blocks. 
205 lines changed or deleted 202 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/