draft-ietf-mpls-tp-itu-t-identifiers-00.txt   draft-ietf-mpls-tp-itu-t-identifiers-01.txt 
Network Working Group R. Winter, Ed. Network Working Group R. Winter, Ed.
Internet-Draft NEC Internet-Draft NEC
Intended status: Standards Track H. van Helvoort Intended status: Standards Track E. Gray, Ed.
Expires: January 27, 2012 Huawei Technologies Co., Ltd. Expires: April 30, 2012 Ericsson
H. van Helvoort
Huawei Technologies Co., Ltd.
M. Betts M. Betts
ZTE ZTE
July 26, 2011 October 28, 2011
MPLS-TP Identifiers Following ITU-T Conventions MPLS-TP Identifiers Following ITU-T Conventions
draft-ietf-mpls-tp-itu-t-identifiers-00 draft-ietf-mpls-tp-itu-t-identifiers-01
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 OAM functions to include identifier information in a management and OAM functions to include identifier information in a
format typically used by the ITU-T. format typically used by the ITU-T.
skipping to change at page 1, line 38 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2012. This Internet-Draft will expire on April 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 5 1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 4
4. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . . . 6 2. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 4
5. ICC_Operator_ID-based MEG Identifiers . . . . . . . . . . . . 7 3. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . . . 4
6. ICC_Operator_ID-based MEP Identifiers . . . . . . . . . . . . 8 4. ICC_Operator_ID-based MEG Identifiers . . . . . . . . . . . . . 5
7. Identifier Usage Considerations . . . . . . . . . . . . . . . 9 5. ICC_Operator_ID-based MEP Identifiers . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
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)
specified in [I-D.ietf-mpls-tp-identifiers]. specified in RFC 6370 [RFC6370].
[I-D.ietf-mpls-tp-identifiers] defines a set of MPLS-TP transport and RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management
management entity identifiers to support bidirectional (co-routed and entity identifiers to support bidirectional (co-routed and
associated) point-to-point MPLS-TP LSPs, including PWs and Sections associated) point-to-point MPLS-TP LSPs, including PWs and Sections
which follow the IP/MPLS conventions. which follow the IP/MPLS conventions.
This document specifies an alternative way to uniquely identify an This document specifies an alternative way to uniquely identify an
operator/service provider based on ITU-T conventions and specifies operator/service provider based on ITU-T conventions and specifies
how this operator/service provider identifier can be used to make the how this operator/service provider identifier can be used to make the
existing set of MPLS-TP transport and management entity identifiers, existing set of MPLS-TP transport and management entity identifiers,
defined by [I-D.ietf-mpls-tp-identifiers], globally unique. defined by RFC 6370 [RFC6370], globally unique.
This document solely defines those identifiers. The use of them and This document solely defines those identifiers. Their use and
possible extensions to protocols to carry them is outside of scope of possible protocols extensions to carry them is out of scope in this
this document. document.
In this document, we follow the notational convention laid out in In this document, we follow the notational convention laid out in RFC
[I-D.ietf-mpls-tp-identifiers]. 6370 [RFC6370].
2. Requirements notation 1.1. Terminology
CC: Country Code
ICC: ITU-T Carrier Code
ITU-T: International Telecommunication Union Telecommunication
Standardization Sector
LSP: Label Switched Path
MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point
MPLS: Multi-Protocol Label Switching
PW: Pseudowire
TSB: (ITU-T) Telecommunication Standardization Bureau
UMC: Unique MEG ID Code
1.2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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 RFC 2119 [RFC2119].
3. Uniquely Identifying an Operator - the ICC_Operator_ID 2. Uniquely Identifying an Operator - the ICC_Operator_ID
In [I-D.ietf-mpls-tp-identifiers] an operator is uniquely identified In RFC 6370 [RFC6370] an operator is uniquely identified by the
by the Global_ID which is based on the AS number of the operator. Global_ID which is based on the AS number of the operator. The ITU-T
The ITU-T however traditionally identifies operators/service however traditionally identifies operators/service providers based on
providers based on the ITU-T Carrier Code (ICC) as specified in the ITU-T Carrier Code (ICC) as specified in [M1400].
[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 can be assigned to
both, ITU-T members as well as non-members, all of which are both, ITU-T members as well as non-members, all of which are
referenced at [ICC-list]. The national regulatory authorities act as referenced at [ICC-list]. The national regulatory authorities act as
an intermediary between the ITU/TSB and operators/service providers. an intermediary between the ITU/TSB and operators/service providers.
Amongst the things that the national authorities are responsible for Amongst 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. Codes are unique within their country.
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 upper
case letters. case 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). The characters represented with upper case letters (i.e., A-Z). The
Country Code format is defined in ISO 3166-1 [ISO3166-1]. Together, Country Code format is defined in ISO 3166-1 [ISO3166-1]. Together,
they form the ICC_Operator_ID. the CC and the ICC form the ICC_Operator_ID as CC::ICC.
4. Use of the ICC_Operator_ID 3. 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 [I-D.ietf-mpls-tp-identifiers], i.e. its purpose is to specified in RFC 6370 [RFC6370], i.e. its purpose is to provide a
provide a globally unique context for other MPLS-TP identifiers. globally unique context for other MPLS-TP identifiers.
As an example, an Interface Identifier (IF_ID) in As an example, an Interface Identifier (IF_ID) in RFC 6370 [RFC6370]
[I-D.ietf-mpls-tp-identifiers] is specified as the concatenation of is specified as the concatenation of the Node_ID (a unique 32-bit
the Node_ID (a unique 32-bit value assigned by the operator) and the value assigned by the operator) and the Interface Number (IF_Num, a
Interface Number (IF_Num, a 32-bit unsigned integer assigned by the 32-bit unsigned integer assigned by the operator that is unique
operator that is unique within the scope of a Node_ID). To make this within the scope of a Node_ID). To make this IF_ID globally unique
IF_ID globally unique the Global_ID is prefixed. This memo specifies the Global_ID is prefixed. This memo specifies the ICC_Operator_ID
the ICC_Operator_ID as an alternative format which, just like the as an alternative format which, just like the Global_ID, is prefixed
Global_ID, is prefixed to the IF_ID. Using the notation from to the IF_ID. Using the notation from RFC 6370 [RFC6370]:
[I-D.ietf-mpls-tp-identifiers]:
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 [I-D.ietf-mpls-tp-identifiers] except for the other alternatives in RFC 6370 [RFC6370] except for the other alternatives mentioned in
mentioned in this document. this document.
5. ICC_Operator_ID-based MEG Identifiers 4. ICC_Operator_ID-based MEG Identifiers
The ITU-T format of MEG_IDs for MPLS-TP Sections, LSPs and The ITU-T format of MEG_IDs for MPLS-TP Sections, LSPs and
Pseudowires is based on the globally unique ICC_Operator_ID. In this Pseudowires is based on the globally unique ICC_Operator_ID. In this
case, the MEG_ID is a string of up to thirteen characters. It case, the MEG_ID is a string of up to 15 characters. It consists of
consists of three subfields: the ICC (as described in Section 3), three subfields: the Country Code (as described in Section 2), the
followed by a "/" (indicating the end of the ICC subfield), the ICC (as described in Section 2) which together form the
Country Code (as described in Section 3) followed by a unique MEG ICC_Operator_ID, followed by a Unique MEG ID Code (UMC).
code (UMC). The UMC MUST be unique within the organization
identified by the ICC. The resulting MEG_ID therefore looks like the following:
CC:ICC:UMC
To avoid the potential for a short (i.e. less than 6 Character) ICC
code in combination with a UMC not being unique the UMC MUST start
with a special character that is not allowed in the ICC such as the
"/" character. A side effect of this is that the MEG_ID can be
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 The ICC_Operator_ID-based MEG_ID may be applied equally to a single
MPLS-TP Section, LSP or Pseudowires. MPLS-TP Section, LSP or Pseudowire.
6. ICC_Operator_ID-based MEP Identifiers 5. ICC_Operator_ID-based MEP Identifiers
ICC_Operator_ID-based MEP_IDs for MPLS-TP LSPs and Pseudowires are ICC_Operator_ID-based MEP_IDs for MPLS-TP LSPs and Pseudowires are
formed by appending a unique number to the MEG_ID defined in formed by appending a 16-bit index to the MEG_ID defined in Section 4
Section 5 above. Within the context of a particular MEG, we call the above. Within the context of a particular MEG, we call the
identifier associated with a MEP the MEP Index (MEP_Index). The identifier associated with a MEP the MEP Index (MEP_Index). The
MEP_Index is administratively assigned. It is encoded as a 16-bit MEP_Index is administratively assigned. It is encoded as a 16-bit
unsigned integer and MUST be unique within the MEG. An unsigned integer and MUST be unique within the 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. Identifier Usage Considerations 6. Security Considerations
TBD.
8. Security Considerations
This document extends an existing information model and, as such, This document extends an existing information model and, as such,
does in itself not introduce new security concerns. But, as does in itself not introduce new security concerns. But, as
mentioned in the security considerations section of the document that mentioned in the security considerations section of the document that
is being augmented, protocol specifications that describe use of this is being augmented, protocol specifications that describe use of this
information model may introduce security risks and concerns about information model may introduce security risks and concerns about
authentication of participants. For this reason, the writers of authentication of participants. For this reason, these protocol
protocol specifications for the purpose of describing implementations specifications need to describe security and authentication concerns
of this information model need to describe security and that may be raised by the particular mechanisms defined and how those
authentication concerns that may be raised by the particular concerns may be addressed.
mechanisms defined and how those concerns may be addressed.
9. IANA Considerations 7. IANA Considerations
There are no IANA actions resulting from this document. There are no IANA actions resulting from this document.
10. Normative References 8. References
[I-D.ietf-mpls-tp-identifiers]
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
Identifiers", draft-ietf-mpls-tp-identifiers-06 (work in
progress), June 2011.
[ICC-list] 8.1. Normative References
"www.itu.int/ITU-T/inr/icc/index.html".
[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 3166-1. their subdivisions -- Part 1: Country codes", ISO 3166-1.
[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.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
8.2. Informative References
[ICC-list]
"List of ITU Carrier Codes (ICCs)",
<http://www.itu.int/oth/T0201>.
Authors' Addresses Authors' Addresses
Rolf Winter (editor) Rolf Winter (editor)
NEC NEC
Email: rolf.winter@neclab.eu Email: rolf.winter@neclab.eu
Eric Gray (editor)
Ericsson
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. 32 change blocks. 
79 lines changed or deleted 119 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/