Network Working Group R. Winter, Ed.
Internet-Draft NEC
Intended status: Standards Track E. Gray, Ed.
Expires: September 7, 2012 Ericsson
H. van Helvoort
Huawei Technologies Co., Ltd.
M. Betts
ZTE
March 6, 2012
MPLS-TP Identifiers Following ITU-T Conventions
draft-ietf-mpls-tp-itu-t-identifiers-03
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 OAM functions to include identifier information in a
format typically used by the ITU-T.
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
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
and may be updated, replaced, or obsoleted by other documents 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 September 7, 2012.
Copyright Notice
Copyright (c) 2012 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
Winter, et al. Expires September 7, 2012 [Page 1]
Internet-Draft MPLS-TP ITU-T IDs March 2012
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
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 . . . . . . . . . . . . . . . . 6
5. MPLS-TP Tunnel and LSP Identifiers . . . . . . . . . . . . . . 7
5.1. MPLS-TP Point-to-Point Tunnel Identifiers . . . . . . . . 7
5.2. MPLS-TP LSP Identifiers . . . . . . . . . . . . . . . . . 7
5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers . . . 7
5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers . . 8
6. Pseudowire Path Identifiers . . . . . . . . . . . . . . . . . 9
7. Maintenance Identifiers . . . . . . . . . . . . . . . . . . . 9
7.1. MEG Identifiers . . . . . . . . . . . . . . . . . . . . . 9
7.2. MEP Identifiers . . . . . . . . . . . . . . . . . . . . . 10
7.3. MIP Identifiers . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Winter, et al. Expires September 7, 2012 [Page 2]
Internet-Draft MPLS-TP ITU-T IDs March 2012
1. Introduction
This document augments the initial set of identifiers to be used in
the Transport Profile of Multiprotocol Label Switching (MPLS-TP)
specified in [RFC6370].
[RFC6370] defines a set of MPLS-TP transport and management entity
identifiers to support bidirectional (co-routed and associated)
point-to-point MPLS-TP LSPs, including PWs and Sections which follow
the IP/MPLS conventions.
This document specifies an alternative way to uniquely identify an
operator/service provider based on ITU-T conventions and specifies
how this operator/service provider identifier can be used to make the
existing set of MPLS-TP transport and management entity identifiers,
defined by [RFC6370], globally unique.
This document solely defines those identifiers. Their use and
possible protocols extensions to carry them is out of scope in 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
ITU-T: International Telecommunication Union 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 Label Switching
PW: Pseudowire
TSB: (ITU-T) Telecommunication Standardization Bureau
Winter, et al. Expires September 7, 2012 [Page 3]
Internet-Draft MPLS-TP ITU-T IDs March 2012
UMC: Unique MEG ID Code
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
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 identifiers defined
in [RFC6370]. Most changes replace certain parts in the already
defined identifiers that are themselves composed of a set of atomic
identifiers. The set of identifiers defined in [RFC6370] are:
o Global_ID
o Node
o Interface
Winter, et al. Expires September 7, 2012 [Page 4]
Internet-Draft MPLS-TP ITU-T IDs March 2012
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 AS number of the operator. The ITU-T however
traditionally identifies operators/service providers based on the
ITU-T 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 can be assigned to
both, ITU-T members as well as non-members, all of which are
referenced at [ICC-list]. The national regulatory authorities act as
an intermediary between the ITU/TSB and operators/service providers.
Amongst 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.
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 upper
case 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 letters (i.e., A-Z). The
Country Code format is defined in ISO 3166-1 [ISO3166-1]. Together,
the CC and the ICC form the ICC_Operator_ID as:
CC::ICC
Winter, et al. Expires September 7, 2012 [Page 5]
Internet-Draft MPLS-TP ITU-T IDs March 2012
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 which, 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
Section 7.1, Section 7.2 and Section 7.3 respectively).
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 draft 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 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.
Winter, et al. Expires September 7, 2012 [Page 6]
Internet-Draft MPLS-TP ITU-T IDs March 2012
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 Section 5.1 and Section 5.2 below.
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}
Where global uniqueness is required, using ITU-T conventions, the
ICC_Operator_ID is prefixed to the Tunnel_IDs. 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 sub-sections 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 unsigend integer LSP number (LSP_Num) to
Winter, et al. Expires September 7, 2012 [Page 7]
Internet-Draft MPLS-TP ITU-T IDs March 2012
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
5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers
Associated bidirectional LSPs need an LSP_Num for each unidirectional
LSP it consists of. The LSP number is again a 16-bit unsigned
integer which needs to be unique within the scope of the ingress'
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 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}
Winter, et al. Expires September 7, 2012 [Page 8]
Internet-Draft MPLS-TP ITU-T IDs March 2012
6. Pseudowire Path Identifiers
The PW Path Identifier (PW_Path_ID) is structured in a similar manner
as the LSP IDs described before. It uses the concept of a group ID
(Group_ID) as described in RFC 4447 together with a PW number
(PW_Num). Both are 16 bit quantaties. In a statically configure
environment, both the group ID and the PW number need to be equal on
both ends of the PW. Together with the node ID these values form the
PW_Path_ID as follows:
A1-{Node_ID::Group_ID::PW_Num}::Z9-{Node_ID::Group_ID::PW_Num}
A globally unique PW_Path_ID is constructed using the globally unique
Node_IDs as defined earlier in this document. A globally unique
PW_Path_ID is formulated as:
A1-{ICC_Operator_ID::Node_ID::Group_ID::PW_Num}::
Z9-{ICC_Operator_ID::Node_ID::Group_ID::PW_Num}
7. Maintenance Identifiers
A Maintenance Entity Group (MEG) as defined by [RFC6371] is a
collection of one or more maintenance enties that belong to the same
transport path. These maintenance entities can be e.g. Maintenance
Entity Group End Points (MEPs) or Maintenance Entity Group
Intermediate Points (MIPs). The following sub-sections define the
identifiers for the various maintenance-related groups and entities.
In contrast to the IDs defined in [RFC6370], this document does not
define separate maintenance identifiers for sections, PWs and LSPs.
7.1. MEG Identifiers
MEG_IDs for MPLS-TP Sections, LSPs and Pseudowires 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), 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 Character) ICC with a UMC not being unique the UMC MUST start
with the "/" character which is not allowed in the ICC itself. This
Winter, et al. Expires September 7, 2012 [Page 9]
Internet-Draft MPLS-TP ITU-T IDs March 2012
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 LSPs and Pseudowires are
formed by appending a 32-bit index to the MEG_ID defined in
Section 7.1 above. 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 32-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 are formed the same way MEP_IDs are
constructed, i.e. by appending a 32-bit MIP Index (MIP_Index) to the
MEG_ID. The MIP_Index is administratively assigned and encoded as a
32-bit unsigned integer. It MUST be unique within the MEG. An
ICC_Operator_ID-based MIP_ID is structured as:
MEG_ID::MIP_Index
An ICC_Operator_ID-based MIP ID is globally unique by construction
given the ICC_Operator_ID-based MEG_ID's global uniqueness.
8. Security Considerations
This document extends an existing information model and does not
introduce new security concerns. But, as mentioned in the security
considerations section of [RFC6370] protocol specifications that
describe use of this information model 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.
Winter, et al. Expires September 7, 2012 [Page 10]
Internet-Draft MPLS-TP ITU-T IDs March 2012
9. IANA Considerations
There are no IANA actions resulting from this document.
10. References
10.1. Normative References
[ISO3166-1]
"Codes for the representation of names of countries and
their subdivisions -- Part 1: Country codes", ISO 3166-1.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[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. Informative References
[ICC-list]
"List of ITU Carrier Codes (ICCs)",
<http://www.itu.int/oth/T0201>.
Authors' Addresses
Rolf Winter (editor)
NEC
Email: rolf.winter@neclab.eu
Winter, et al. Expires September 7, 2012 [Page 11]
Internet-Draft MPLS-TP ITU-T IDs March 2012
Eric Gray (editor)
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. Expires September 7, 2012 [Page 12]