draft-ietf-mpls-tp-itu-t-identifiers-04.txt   draft-ietf-mpls-tp-itu-t-identifiers-05.txt 
Network Working Group R. Winter, Ed. Network Working Group R. Winter, Ed.
Internet-Draft NEC Internet-Draft NEC
Intended status: Standards Track E. Gray, Ed. Intended status: Standards Track E. Gray, Ed.
Expires: March 2, 2013 Ericsson Expires: April 20, 2013 Ericsson
H. van Helvoort H. van Helvoort
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
M. Betts M. Betts
ZTE ZTE
August 29, 2012 October 17, 2012
MPLS-TP Identifiers Following ITU-T Conventions MPLS-TP Identifiers Following ITU-T Conventions
draft-ietf-mpls-tp-itu-t-identifiers-04 draft-ietf-mpls-tp-itu-t-identifiers-05
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 40 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 March 2, 2013. This Internet-Draft will expire on April 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 [RFC6370]. defined in [RFC6370].
[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 LSPs, including PWs and Sections which follow point-to-point MPLS-TP LSPs, including PWs and Sections which follow
the IP/MPLS conventions. 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,
skipping to change at page 4, line 9 skipping to change at page 4, line 9
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol 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 All multiple-word atomic identifiers use underscores (_) between the
words to join the words. Many of the identifiers are composed of a words to join the words. Many of the identifiers are composed of a
set of other identifiers. These are expressed by listing the latter set of other identifiers. These are expressed by listing the latter
identifiers joined with double-colon "::" notation. identifiers joined with double-colon "::" notation.
Where the same identifier type is used multiple times in a Where the same identifier type is used multiple times in a
skipping to change at page 7, line 51 skipping to change at page 7, line 51
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 sub-sections define identifiers for MPLS-TP co-routed
bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub- bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub-
Path Maintenance Entities (SPMEs) are also LSPs, they use the same Path Maintenance Entities (SPMEs) are also LSPs, they use the same
form of IDs. 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 unsigend 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 unidirectional
skipping to change at page 10, line 15 skipping to change at page 10, line 15
components by a receiver. 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 LSPs and Pseudowires are ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs and
formed by appending a 32-bit index to the MEG_ID defined in Pseudowires are formed by appending a 16-bit index to the MEG_ID
Section 7.1 above. Within the context of a particular MEG, we call defined in Section 7.1 above. Within the context of a particular
the identifier associated with a MEP the MEP Index (MEP_Index). The MEG, we call the identifier associated with a MEP the MEP Index
MEP_Index is administratively assigned. It is encoded as a 32-bit (MEP_Index). The MEP_Index is administratively assigned. It is
unsigned integer and MUST be unique within the MEG. An encoded as a 16-bit unsigned integer and MUST be unique within the
ICC_Operator_ID-based MEP_ID is structured as: MEG. An 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 are formed the same way MEP_IDs are ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs and
constructed, i.e. by appending a 32-bit MIP Index (MIP_Index) to the Pseudowires are formed by a global IF_ID that is obtained by
MEG_ID. The MIP_Index is administratively assigned and encoded as a prefixing the identifier of the interface the MIP resides with the
32-bit unsigned integer. It MUST be unique within the MEG. An ICC_Operator_ID as described in Section 3.1. This allows MIPs to be
ICC_Operator_ID-based MIP_ID is structured as: independently identified in nodes where a per-interface MIP model is
used.
MEG_ID::MIP_Index
An ICC_Operator_ID-based MIP ID is globally unique by construction If only a per-node MIP model is used, one MIP is configured. In this
given the ICC_Operator_ID-based MEG_ID's global uniqueness. 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 information model and does not This document extends an existing information model and does not
introduce new security concerns. But, as mentioned in the security introduce new security concerns. But, as mentioned in the security
considerations section of [RFC6370] protocol specifications that considerations section of [RFC6370] protocol specifications that
describe use of this information model may introduce security risks describe use of this information model may introduce security risks
and concerns about authentication of participants. For this reason, and concerns about authentication of participants. For this reason,
these protocol specifications need to describe security and 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
skipping to change at page 11, line 15 skipping to change at page 11, line 15
9. IANA Considerations 9. IANA Considerations
There are no IANA actions resulting from this document. There are no IANA actions resulting from this document.
10. References 10. References
10.1. Normative References 10.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 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>. <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 [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.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[Y.1731_cor1] [Y.1731_cor1]
"OAM functions and mechanisms for Ethernet based networks "OAM functions and mechanisms for Ethernet based networks
- Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731 - Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731
(2011) Corrigendum 1. (2011) Corrigendum 1.
10.2. Informative References 10.2. Informative References
[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
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
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) Eric Gray (editor)
Ericsson Ericsson
Email: eric.gray@ericsson.com Email: eric.gray@ericsson.com
 End of changes. 13 change blocks. 
28 lines changed or deleted 27 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/