draft-ietf-mpls-tp-itu-t-identifiers-06.txt		draft-ietf-mpls-tp-itu-t-identifiers-07.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: May 11, 2013 Ericsson		Expires: July 13, 2013 Ericsson
	H. van Helvoort		H. van Helvoort
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	M. Betts		M. Betts
	ZTE		ZTE
	November 7, 2012		January 9, 2013
	MPLS-TP Identifiers Following ITU-T Conventions		MPLS-TP Identifiers Following ITU-T Conventions
	draft-ietf-mpls-tp-itu-t-identifiers-06		draft-ietf-mpls-tp-itu-t-identifiers-07
	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 Operations, Administration, and Maintenance (OAM)
	format typically used by the ITU-T.		functions to include identifier information in a format typically
			used by the International Telecommunication Union Telecommunication
			Standardization Sector (ITU-T).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 11, 2013.		This Internet-Draft will expire on July 13, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	skipping to change at page 3, line 13		skipping to change at page 3, line 13
	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)
	defined 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 Label Switched Paths (LSPs), including
	the IP/MPLS conventions.		Pseudowire (PWs) and Sections 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 [RFC6370], globally unique.		defined by [RFC6370], globally unique.
	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 protocols extensions to carry them is out of scope in this
	document.		document.
	skipping to change at page 5, line 34		skipping to change at page 5, line 34
	traditionally identifies operators/service providers based on the		traditionally identifies operators/service providers based on the
	ITU-T Carrier Code (ICC) as specified in [M1400].		ITU-T 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 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. This uniqueness assumption is
			the basis for creating a globally unique ICC-based operator ID.
	The ICC itself is a string of one to six characters, each character		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,
	skipping to change at page 9, line 8		skipping to change at page 9, line 8
	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]. In stead 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
	A Maintenance Entity Group (MEG) as defined by [RFC6371] is a		The following sub-sections define the identifiers for the various
	collection of one or more maintenance enties that belong to the same		maintenance-related groups and entities as defined in [RFC6371]. In
	transport path. These maintenance entities can be e.g. Maintenance		contrast to the IDs defined in [RFC6370], this document does not
	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.		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 Pseudowires 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), the
	ICC (as described in Section 3) which together form 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 in
	[Y.1731_cor1].		[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 Character) ICC with a UMC not being unique the UMC MUST start
	with the "/" character which is not allowed in the ICC itself. This		with the "/" character which is not allowed in the ICC itself. This
	way, the MEG_ID can also be easily decomposed into its individual		way, the MEG_ID can also be easily decomposed into its individual
	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.
	skipping to change at page 10, line 37		skipping to change at page 10, line 34
	prefixing the identifier of the interface the MIP resides with the		prefixing the identifier of the interface the MIP resides with the
	ICC_Operator_ID as described in Section 3.1. This allows MIPs to be		ICC_Operator_ID as described in Section 3.1. This allows MIPs to be
	independently identified in nodes where a per-interface MIP model is		independently identified in nodes where a per-interface MIP model is
	used.		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 information model 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. 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 naming scheme may introduce security risks and
	and concerns about authentication of participants. For this reason,		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
	mechanisms defined and how those concerns may be addressed.		mechanisms defined and how those concerns may be addressed.
	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>.
End of changes. 14 change blocks.
	23 lines changed or deleted		21 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/