draft-ietf-ccamp-oam-configuration-fwk-11.txt		draft-ietf-ccamp-oam-configuration-fwk-12.txt
	Network Working Group A. Takacs		Network Working Group A. Takacs
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track D. Fedyk		Intended status: Standards Track D. Fedyk
	Expires: June 5, 2014 Alcatel-Lucent		Expires: July 16, 2014 Alcatel-Lucent
	J. He		J. He
	Huawei		Huawei
	December 2, 2013		January 12, 2014
	GMPLS RSVP-TE extensions for OAM Configuration		GMPLS RSVP-TE extensions for OAM Configuration
	draft-ietf-ccamp-oam-configuration-fwk-11		draft-ietf-ccamp-oam-configuration-fwk-12
	Abstract		Abstract
	Operations, Administration and Maintenance is an integral part of		Operations, Administration and Maintenance is an integral part of
	transport connections, hence it is required that Operations,		transport connections, hence it is required that Operations,
	Administration and Maintenance functions are activated/deactivated in		Administration and Maintenance functions are activated/deactivated in
	sync with connection commissioning/decommissioning; avoiding spurious		sync with connection commissioning/decommissioning; avoiding spurious
	alarms and ensuring consistent operation. In certain technologies,		alarms and ensuring consistent operation. In certain technologies,
	Operations, Administration and Maintenance entities are inherently		Operations, Administration and Maintenance entities are inherently
	established once the connection is set up, while other technologies		established once the connection is set up, while other technologies
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	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 June 5, 2014.		This Internet-Draft will expire on July 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6		3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6
	3.1. Establishment of OAM Entities and Functions . . . . . . . 7		3.1. Establishment of OAM Entities and Functions . . . . . . . 8
	3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9		3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9
	3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9		3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10
	4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 10		4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 11
	4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 10		4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 11
	4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11		4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12
	4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 13		4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 14
	4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14		4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14
	4.3. Administrative Status Information . . . . . . . . . . . . 14		4.3. Administrative Status Information . . . . . . . . . . . . 15
	4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14		4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15
	4.5. Considerations on Point-to-Multipoint OAM Configuration . 15		4.5. Considerations on Point-to-Multipoint OAM Configuration . 16
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 16		5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 17
	5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 16		5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 17
	5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 17		5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 18
	5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 17		5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 18
	5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 18		5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 19
	5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 18		5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 19
	5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 18		5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 19
	5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 19		5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 20
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . 20		8.1. Normative References . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . 20		8.2. Informative References . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	GMPLS is designed as an out-of-band control plane supporting dynamic		GMPLS is designed as an out-of-band control plane supporting dynamic
	connection provisioning for any suitable data plane technology;		connection provisioning for any suitable data plane technology;
	including spatial switching (e.g., incoming port or fiber to outgoing		including spatial switching (e.g., incoming port or fiber to outgoing
	port or fiber), wavelength-division multiplexing (e.g., DWDM), time-		port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
	division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider		division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider
	Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most		Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most
	of these technologies, there are Operations, Administration and		of these technologies, there are Operations, Administration and
	skipping to change at page 5, line 28		skipping to change at page 5, line 28
	o From [RFC5654]: The MPLS-TP control plane MUST support the		o From [RFC5654]: The MPLS-TP control plane MUST support the
	configuration and modification of OAM maintenance points as well		configuration and modification of OAM maintenance points as well
	as the activation/ deactivation of OAM when the transport path or		as the activation/ deactivation of OAM when the transport path or
	transport service is established or modified.		transport service is established or modified.
	Ethernet Connectivity Fault Management (CFM) defines an adjunct		Ethernet Connectivity Fault Management (CFM) defines an adjunct
	connectivity monitoring OAM flow to check the liveliness of Ethernet		connectivity monitoring OAM flow to check the liveliness of Ethernet
	networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet		networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet
	networks support explicitly-routed Ethernet connections. CFM can be		networks support explicitly-routed Ethernet connections. CFM can be
	used to track the liveliness of PBB-TE connections and detect data		used to track the liveliness of PBB-TE connections and detect data
	plane failures. In IETF, the GMPLS controlled Ethernet Label		plane failures. In the IETF, the GMPLS controlled Ethernet Label
	Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the		Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the
	GMPLS control plane to support the establishment of PBB-TE data plane		GMPLS control plane to support the establishment of PBB-TE data plane
	connections. Without control plane support, separate management		connections. Without control plane support separate management
	commands would be needed to configure and start CFM.		commands would be needed to configure and start CFM.
	GMPLS based OAM configuration and control, needs to provide a general		GMPLS based OAM configuration and control needs to provide a general
	framework to be applicable to a wide range of data plane technologies		framework to be applicable to a wide range of data plane technologies
	and OAM solutions. There are three typical data plane technologies		and OAM solutions. There are three typical data plane technologies
	used for transport applications: wavelength based such as WSON, TDM		used for transport applications: wavelength based such as WSON, TDM
	based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921]		based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921]
	and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes,		and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes,
	the operator MUST be able to configure and control the following OAM		the operator MUST be able to configure and control the following OAM
	functions:		functions:
	o It MUST be possible to explicitly request the setup of OAM		o It MUST be possible to explicitly request the setup of OAM
	entities for the signaled LSP and provide specific information for		entities for the signaled LSP and provide specific information for
	skipping to change at page 7, line 28		skipping to change at page 7, line 22
	OAM identifiers, as well as the configuration of OAM functions, are		OAM identifiers, as well as the configuration of OAM functions, are
	technology specific (i.e., vary depending on the data plane		technology specific (i.e., vary depending on the data plane
	technology and the chosen OAM solution). In addition, for any given		technology and the chosen OAM solution). In addition, for any given
	data plane technology, a set of OAM solutions may be applicable.		data plane technology, a set of OAM solutions may be applicable.
	Therefore, the OAM configuration framework allows selecting a		Therefore, the OAM configuration framework allows selecting a
	specific OAM solution to be used for the signaled LSP and provides		specific OAM solution to be used for the signaled LSP and provides
	means to carry detailed OAM configuration information in technology		means to carry detailed OAM configuration information in technology
	specific TLVs.		specific TLVs.
			Administrative Status Information is carried in the ADMIN_STATUS
			Object. The Administrative Status Information is described in
			[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
			[RFC3473]. Two bits are allocated for the administrative control of
			OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled"
			(O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms
			MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled.
			When the "OAM Alarms Enabled" bit is set OAM triggered alarms are
			enabled and associated consequent actions MUST be executed including
			the notification to the management system. When this bit is cleared,
			alarms are suppressed and no action SHOULD be executed and the
			management system SHOULD NOT be notified.
			The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES objects are
			defined in [RFC5420] to provide means to signal LSP attributes and
			options in the form of TLVs. Options and attributes signaled in the
			LSP_ATTRIBUTES object can be passed transparently through LSRs not
			supporting a particular option or attribute, while the contents of
			the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by
			each LSR. One bit "OAM MEP entities desired" is allocated in the LSP
			Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. If the
			"OAM MEP entities desired" bit is set it is indicating that the
			establishment of OAM MEP entities are required at the endpoints of
			the signaled LSP. One bit "OAM MIP entities desired" is allocated in
			the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
			LSP_REQUIRED_ATTRIBUES objects. If the "OAM MIP entities desired"
			bit is set in the LSP_ATTRIBUTES Flags TLV in the
			LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
			establishment of OAM MIP entities is required at every transit node
			of the signaled LSP.
	3.1. Establishment of OAM Entities and Functions		3.1. Establishment of OAM Entities and Functions
	In order to avoid spurious alarms, OAM functions should be setup and		In order to avoid spurious alarms, OAM functions should be setup and
	enabled in the appropriate order. When using the GMPLS control plane		enabled in the appropriate order. When using the GMPLS control plane
	for both LSP establishment and to enable OAM functions on the LSPs,		for both LSP establishment and to enable OAM functions on the LSPs,
	the control of both processes is bound to RSVP-TE message exchanges.		the control of both processes is bound to RSVP-TE message exchanges.
	An LSP may be signaled and established without OAM configuration		An LSP may be signaled and established without OAM configuration
	first, and OAM entities may be added later with a subsequent re-		first, and OAM entities may be added later with a subsequent re-
	signaling of the LSP. Alternatively, the LSP may be setup with OAM		signaling of the LSP. Alternatively, the LSP may be setup with OAM
	skipping to change at page 10, line 35		skipping to change at page 11, line 9
	the downstream direction. In the case of a bidirectional connection,		the downstream direction. In the case of a bidirectional connection,
	it MUST leave in place the OAM sink functions associated to the		it MUST leave in place the OAM sink functions associated to the
	upstream direction. The remote end, after receiving the Path		upstream direction. The remote end, after receiving the Path
	message, MUST remove all associated OAM entities and functions and		message, MUST remove all associated OAM entities and functions and
	reply with a Resv message without an OAM Configuration TLV. The		reply with a Resv message without an OAM Configuration TLV. The
	initiator completely removes OAM entities and functions after the		initiator completely removes OAM entities and functions after the
	Resv message arrived.		Resv message arrived.
	4. RSVP-TE Extensions		4. RSVP-TE Extensions
			RFC Editor Note: remove/update "IANA" and "IANA to assign" notes in
			the document once the assignments have been made.
	4.1. LSP Attributes Flags		4.1. LSP Attributes Flags
	In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to		In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to
	indicate options and attributes of the LSP. The Flags field has 8		indicate options and attributes of the LSP. The Flags field has 8
	bits and hence is limited to differentiate only 8 options. [RFC5420]		bits and hence is limited to differentiate only 8 options. [RFC5420]
	defines new objects for RSVP-TE messages to allow the signaling of		defines new objects for RSVP-TE messages to allow the signaling of
	arbitrary attribute parameters making RSVP-TE easily extensible to		arbitrary attribute parameters making RSVP-TE easily extensible to
	support new applications. Furthermore, [RFC5420] allows options and		support new applications. Furthermore, [RFC5420] allows options and
	attributes that do not need to be acted on by all Label Switched		attributes that do not need to be acted on by all Label Switched
	Routers (LSRs) along the path of the LSP. In particular, these		Routers (LSRs) along the path of the LSP. In particular, these
	skipping to change at page 12, line 30		skipping to change at page 13, line 7
	OAM Type: specifies the technology specific OAM method. When carried		OAM Type: specifies the technology specific OAM method. When carried
	in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is		in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is
	not supported at any given node an error MUST be generated: "OAM		not supported at any given node an error MUST be generated: "OAM
	Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES		Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES
	Object, intermediate nodes not supporting the OAM Type pass the		Object, intermediate nodes not supporting the OAM Type pass the
	object forward unchanged as specified in [RFC5420]. Ingress and		object forward unchanged as specified in [RFC5420]. Ingress and
	egress nodes that support the OAM Configuration TLV but that do not		egress nodes that support the OAM Configuration TLV but that do not
	support a specific OAM Type MUST respond with an error indicating		support a specific OAM Type MUST respond with an error indicating
	"OAM Problem/Unsupported OAM Type".		"OAM Problem/Unsupported OAM Type".
	OAM Type Description		OAM Type Description
	------------ --------------------		------------ --------------------
	0-255 Reserved		0-255 Reserved
	This document defines no types. IANA is requested to maintain the		This document defines no types. IANA is requested to maintain the
	values in a new "RSVP-TE OAM Configuration Registry".		values in a new "RSVP-TE OAM Configuration Registry".
	Two groups of TLVs are defined: generic sub-TLVs and technology		Two groups of TLVs are defined: generic sub-TLVs and technology
	specific sub-TLVs. Generic sub-TLVs carry information that are		specific sub-TLVs. Generic sub-TLVs carry information that are
	applicable independent of the actual OAM technology, while technology		applicable independent of the actual OAM technology, while technology
	specific sub-TLVs are providing configuration parameters for specific		specific sub-TLVs are providing configuration parameters for specific
	OAM technologies. This document defines one generic sub-TLV, see		OAM technologies. This document defines one generic sub-TLV, see
	Section 4.2.1, while it is foreseen that technology specific sub-TLVs		Section 4.2.1, while it is foreseen that technology specific sub-TLVs
	will be defined by separate documents.		will be defined by separate documents.
	The receiving node, based on the OAM Type, will check if a		The receiving node, based on the OAM Type, will check if a
	corresponding technology specific OAM configuration sub-TLV is		corresponding technology specific OAM configuration sub-TLV is
	included in the OAM Configuration TLV. If the included technology		included in the OAM Configuration TLV. If the included technology
	specific OAM configuration sub-TLV is different from what is		specific OAM configuration sub-TLV is different from what is
	specified in the OAM Type an error MUST be generated: "OAM Problem/		specified in the OAM Type an error MUST be generated: "OAM Problem/
	OAM Type Mismatch". IANA is requested to maintain the sub-TLV space		OAM Type Mismatch". IANA is requested to maintain the sub-TLV space
	in the new "RSVP-TE OAM Configuration Registry".		in the new "RSVP-TE OAM Configuration Registry".
	Sub-TLV Type Description		Sub-TLV Type Description
	------------ ------------------------------------		------------ ------------------------------------
	0 Reserved		0 Reserved
	1 OAM Function Flags Sub-TLV		1 OAM Function Flags Sub-TLV
	2-31 Reserved for generic Sub-TLVs		2-31 Reserved for generic Sub-TLVs
	32- Reserved for technology specific Sub-TLVs		32- Reserved for technology specific Sub-TLVs
	Note that there is a hierarchical dependency between the OAM		Note that there is a hierarchical dependency between the OAM
	configuration elements. First, the "OAM MEP entities desired" flag		configuration elements. First, the "OAM MEP entities desired" flag
	needs to be set. Only when that flag is set MAY an "OAM		needs to be set. Only when that flag is set MAY an "OAM
	Configuration TLV" be included in the LSP_ATTRIBUTES or		Configuration TLV" be included in the LSP_ATTRIBUTES or
	LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on		LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on
	the "OAM Type" field, it MAY carry a technology specific OAM		the "OAM Type" field, it MAY carry a technology specific OAM
	configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP		configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP
	entities desired" flag is not set but an OAM Configuration TLV is		entities desired" flag is not set but an OAM Configuration TLV is
	present) an error MUST be generated: "OAM Problem/Configuration		present) an error MUST be generated: "OAM Problem/Configuration
	skipping to change at page 13, line 50		skipping to change at page 14, line 32
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	OAM Function Flags is bitmap with extensible length based on the		OAM Function Flags is bitmap with extensible length based on the
	Length field of the TLV. Bits are numbered from left to right. The		Length field of the TLV. Bits are numbered from left to right. The
	TLV is padded to 4-octet alignment. The Length field indicates the		TLV is padded to 4-octet alignment. The Length field indicates the
	size of the padded TLV in octets. IANA is requested to maintain the		size of the padded TLV in octets. IANA is requested to maintain the
	OAM Function Flags in the new "RSVP-TE OAM Configuration Registry".		OAM Function Flags in the new "RSVP-TE OAM Configuration Registry".
	This document defines the following flags.		This document defines the following flags.
	OAM Function Flag bit# Description		OAM Function Flag bit# Description
	--------------------- ---------------------------		--------------------- ---------------------------
	0 Continuity Check (CC)		0 Continuity Check (CC)
	1 Connectivity Verification (CV)		1 Connectivity Verification (CV)
	2 Fault Management Signal (FMS)		2 Fault Management Signal (FMS)
	3 Performance Monitoring/Loss (PM/Loss)		3 Performance Monitoring/Loss (PM/Loss)
	4 Performance Monitoring/Delay (PM/Delay)		4 Performance Monitoring/Delay (PM/Delay)
	5 Performance Monitoring/Throughput Measurement		5 Performance Monitoring/Throughput Measurement
	(PM/Throughput)		(PM/Throughput)
	4.2.2. Technology Specific Sub-TLVs		4.2.2. Technology Specific Sub-TLVs
	If technology-specific configuration information is needed for a		If technology-specific configuration information is needed for a
	specific "OAM Type", then this information is carried in a		specific "OAM Type", then this information is carried in a
	technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM		technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM
	Configuration TLV MUST NOT contain more than one technology- specific		Configuration TLV MUST NOT contain more than one technology- specific
	sub-TLV. IANA is requested to maintain the OAM technology specific		sub-TLV. IANA is requested to maintain the OAM technology specific
	sub-TLV space in the new "RSVP-TE OAM Configuration Registry".		sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
	skipping to change at page 15, line 36		skipping to change at page 16, line 25
	messages.		messages.
	P2MP OAM mechanisms are very specific to the data plane technology,		P2MP OAM mechanisms are very specific to the data plane technology,
	therefore in this document, we only highlight the basic principles of		therefore in this document, we only highlight the basic principles of
	P2MP OAM configuration. We consider only the root to leaf OAM flows,		P2MP OAM configuration. We consider only the root to leaf OAM flows,
	and as such, aspects of the configuration of return paths are outside		and as such, aspects of the configuration of return paths are outside
	the scope of our discussions. We also limit our consideration to the		the scope of our discussions. We also limit our consideration to the
	case where all leaves must successfully establish OAM entities with		case where all leaves must successfully establish OAM entities with
	identical configuration in order the P2MP OAM is successfully		identical configuration in order the P2MP OAM is successfully
	established. In any case, the discussion set forth below provides		established. In any case, the discussion set forth below provides
	only guidelines for P2MP OAM configuration, details will be specified		only guidelines for P2MP OAM configuration. However at minimum the
	in technology specific documents.		below procedures SHOULD be specified for P2MP OAM configuration in a
			technology specific document.
	The root node may use a single Path message or multiple Path messages		The root node may use a single Path message or multiple Path messages
	to setup the whole P2MP tree. In the case when multiple Path		to setup the whole P2MP tree. In the case when multiple Path
	messages are used, the root node is responsible to keep the OAM		messages are used, the root node is responsible to keep the OAM
	Configuration information consistent in each of the sent Path		Configuration information consistent in each of the sent Path
	messages, i.e., the same information MUST be included in all Path		messages, i.e., the same information MUST be included in all Path
	messages used to construct the multicast tree. Each branching node		messages used to construct the multicast tree. Each branching node
	will propagate the Path message downstream on each of the branches,		will propagate the Path message downstream on each of the branches,
	when constructing a Path message the OAM Configuration information		when constructing a Path message the OAM Configuration information
	MUST be copied unchanged from the received Path message, including		MUST be copied unchanged from the received Path message, including
	skipping to change at page 16, line 44		skipping to change at page 17, line 33
	5. IANA Considerations		5. IANA Considerations
	5.1. ADMIN_STATUS Object Bit Flags		5.1. ADMIN_STATUS Object Bit Flags
	IANA maintains a registry called "Generalized Multi-Protocol Label		IANA maintains a registry called "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Parameters" with a sub-registry called		Switching (GMPLS) Signaling Parameters" with a sub-registry called
	"Administrative Status Information Flags".		"Administrative Status Information Flags".
	IANA is requested to allocate two new flags as follows:		IANA is requested to allocate two new flags as follows:
	Bit Number | Hex Value | Name | Reference		Bit Number | Hex Value | Name | Reference
	-----------+------------+--------------------------+-----------		-----------+------------+--------------------------+-----------
	TBA | TBA | OAM Alarms Enabled (O) | [This.ID]		TBA | TBA | OAM Alarms Enabled (O) | [This.ID]
	TBA | TBA | OAM Flows Enabled (M) | [This.ID]		TBA | TBA | OAM Flows Enabled (M) | [This.ID]
	5.2. LSP Attributes Flags		5.2. LSP Attributes Flags
	IANA maintains a registry called "Resource Reservation Protocol-		IANA maintains a registry called "Resource Reservation Protocol-
	Traffic Engineering (RSVP-TE) Parameters" with a subregistry called		Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
	"Attribute Flags".		"Attribute Flags".
	IANA is requested to allocate two new flags as follows:		IANA is requested to allocate two new flags as follows:
	Bit | Name | Attribute | Attribute | RRO | Reference		Bit | Name | Attribute | Attribute | RRO | Reference
	No | | Flags Path | Flags Resv | |		No | | Flags Path | Flags Resv | |
	----+------------------+------------+------------+-----+----------		----+------------------+------------+------------+-----+----------
	TBA | OAM MEP | | | |		TBA | OAM MEP | | | |
	skipping to change at page 17, line 41		skipping to change at page 18, line 36
	TBA| OAM Configuration TLV| Yes | Yes |[This.ID]		TBA| OAM Configuration TLV| Yes | Yes |[This.ID]
	5.4. RSVP Error Code		5.4. RSVP Error Code
	IANA maintains a registry called "Resource Reservation Protocol		IANA maintains a registry called "Resource Reservation Protocol
	(RSVP) Parameters" with a subregistry called "Error Codes and		(RSVP) Parameters" with a subregistry called "Error Codes and
	Globally-Defined Error Value Sub-Codes".		Globally-Defined Error Value Sub-Codes".
	IANA is requested to allocate one new Error Code as follows:		IANA is requested to allocate one new Error Code as follows:
	Error Code | Meaning | Reference		Error Code | Meaning | Reference
	-----------+-------------+-------------		-----------+-------------+-------------
	TBA | OAM Problem | [This.ID]		TBA | OAM Problem | [This.ID]
	The value is to be selected from the range 0-239.		The value is to be selected from the range 0-239.
	The following Error Value sub-codes are defined for this new Error		The following Error Value sub-codes are defined for this new Error
	Code as follows:		Code as follows:
	Value | Description | Reference		Value | Description | Reference
	------+---------------------------------+--------------		------+---------------------------------+--------------
	1 | MEP establishment not supported | [This.ID]		1 | MEP establishment not supported | [This.ID]
	2 | MIP establishment not supported | [This.ID]		2 | MIP establishment not supported | [This.ID]
	3 | Unsupported OAM Type | [This.ID]		3 | Unsupported OAM Type | [This.ID]
	4 | Configuration Error | [This.ID]		4 | Configuration Error | [This.ID]
	5 | OAM Type Mismatch | [This.ID]		5 | OAM Type Mismatch | [This.ID]
	6 | Unsupported OAM Function | [This.ID]		6 | Unsupported OAM Function | [This.ID]
	5.5. RSVP-TE OAM Configuration Registry		5.5. RSVP-TE OAM Configuration Registry
	IANA is requested to create a new registry called "RSVP-TE OAM		IANA is requested to create a new registry called "RSVP-TE OAM
	Configuration Registry".		Configuration Registry".
	IANA is requested to create sub-registries as defined in the		IANA is requested to create sub-registries as defined in the
	following subsections:		following subsections:
	5.5.1. OAM Types Sub-Registry		5.5.1. OAM Types Sub-Registry
	IANA is requested to create the "OAM Types" sub-registry of the		IANA is requested to create the "OAM Types" sub-registry of the
	"RSVP-TE OAM Configuration Registry" as follows:		"RSVP-TE OAM Configuration Registry" as follows:
	Range | Registration Procedures		Range | Registration Procedures
	-------+-------------------------		-------+-------------------------
	0-255 | IETF Review		0-255 | IETF Review
	There are no initial values in this registry. IANA should show the		There are no initial values in this registry. IANA should show the
	registry as follows:		registry as follows:
	OAM Type Number | OAM Type Description | Reference		OAM Type Number | OAM Type Description | Reference
	----------------+----------------------+--------------		----------------+----------------------+--------------
	0-255 | Not allocated |		0-255 | Not allocated |
	5.5.2. OAM Sub-TLVs Sub-Registry		5.5.2. OAM Sub-TLVs Sub-Registry
	skipping to change at page 18, line 48		skipping to change at page 19, line 42
	"RSVP-TE OAM Configuration Registry" as follows:		"RSVP-TE OAM Configuration Registry" as follows:
	Range | Purpose | Registration Procedures		Range | Purpose | Registration Procedures
	------------+------------------------------|------------------------		------------+------------------------------|------------------------
	0-31 | Generic Sub-TLVs | IETF Review		0-31 | Generic Sub-TLVs | IETF Review
	32-65534 | Technology-specific Sub-TLVs | IETF Review		32-65534 | Technology-specific Sub-TLVs | IETF Review
	65535-65536 | Experimental Sub-TLVs | Experimental		65535-65536 | Experimental Sub-TLVs | Experimental
	IANA is requested to populate the registry as follows:		IANA is requested to populate the registry as follows:
	Sub-TLV Type | Description | Reference		Sub-TLV Type | Description | Reference
	-------------+----------------------------+-------		-------------+----------------------------+-------
	0 | Reserved | [This.ID]		0 | Reserved | [This.ID]
	1 | OAM Function Flags Sub-TLV | [This.ID]		1 | OAM Function Flags Sub-TLV | [This.ID]
	2-31 | Not allocated |		2-31 | Not allocated |
	32-65534 | Not allocated |		32-65534 | Not allocated |
	5.5.3. OAM Function Flags Sub-Registry		5.5.3. OAM Function Flags Sub-Registry
	IANA is requested to create the "OAM Function Flags Sub-Registry"		IANA is requested to create the "OAM Function Flags Sub-Registry"
	sub-registry of the "RSVP-TE OAM Configuration Registry".		sub-registry of the "RSVP-TE OAM Configuration Registry".
	New values in the registry are allocated by "IETF Review". There is		New values in the registry are allocated by "IETF Review". There is
	no top value to the range. Bits are counted from bit 0 as the first		no top value to the range. Bits are counted from bit 0 as the first
	bit transmitted.		bit transmitted.
	IANA is requested to populate the registry as follows.		IANA is requested to populate the registry as follows.
	OAM Function Flag | Description		OAM Function Flag | Description
	bit number |		bit number |
	------------------+---------------------------------------------		------------------+---------------------------------------------
	0 | Continuity Check (CC)		0 | Continuity Check (CC)
	1 | Connectivity Verification (CV)		1 | Connectivity Verification (CV)
	2 | Fault Management Signal (FMS)		2 | Fault Management Signal (FMS)
	3 | Performance Monitoring/Loss (PM/Loss)		3 | Performance Monitoring/Loss (PM/Loss)
	4 | Performance Monitoring/Delay (PM/Delay)		4 | Performance Monitoring/Delay (PM/Delay)
	5 | Performance Monitoring/Throughput Measurement		5 | Performance Monitoring/Throughput Measurement
	| (PM/Throughput)		| (PM/Throughput)
	6-... | Not allocated		6-... | Not allocated
	6. Security Considerations		6. Security Considerations
	The signaling of OAM related parameters and the automatic		The signaling of OAM related parameters and the automatic
	establishment of OAM entities based on RSVP-TE messages adds a new		establishment of OAM entities based on RSVP-TE messages adds a new
	aspect to the security considerations discussed in [RFC3473]. In		aspect to the security considerations discussed in [RFC3473]. In
	particular, a network element could be overloaded, if a remote		particular, a network element could be overloaded, if a remote
	attacker could request liveliness monitoring, with frequent periodic		attacker could request liveliness monitoring, with frequent periodic
	messages, for a high number of LSPs, targeting a single network		messages, for a high number of LSPs, targeting a single network
	element. Such an attack can efficiently be prevented when mechanisms		element. Such an attack can efficiently be prevented when mechanisms
	for message integrity and node authentication are deployed. Since		for message integrity and node authentication are deployed. Since
	the OAM configuration extensions rely on the hop-by-hop exchange of		the OAM configuration extensions rely on the hop-by-hop exchange of
	exiting RSVP-TE messages, procedures specified for RSVP message		exiting RSVP-TE messages, procedures specified for RSVP message
	security in [RFC2747] can be used to mitigate possible attacks.		security in [RFC2747] can be used to mitigate possible attacks.
	For a more comprehensive discussion on GMPLS security, please see the		For a more comprehensive discussion of GMPLS security, and attack
	Security Framework for MPLS and GMPLS Networks [RFC5920].		mitigation techniques, please see the Security Framework for MPLS and
	Cryptography can be used to protect against many attacks described in		GMPLS Networks [RFC5920].
	[RFC5920].
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Francesco Fondelli, Adrian Farrel,		The authors would like to thank Francesco Fondelli, Adrian Farrel,
	Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful		Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
	comments.		comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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.
	skipping to change at page 21, line 45		skipping to change at page 22, line 41
	Budapest 1097		Budapest 1097
	Hungary		Hungary
	Email: attila.takacs@ericsson.com		Email: attila.takacs@ericsson.com
	Don Fedyk		Don Fedyk
	Alcatel-Lucent		Alcatel-Lucent
	Groton, MA 01450		Groton, MA 01450
	USA		USA
	Email: donald.fedyk@alcatel-lucent.com		Email: don.fedyk@gmail.com
	Jia He		Jia He
	Huawei		Huawei
	Email: hejia@huawei.com		Email: hejia@huawei.com
End of changes. 27 change blocks.
	92 lines changed or deleted		128 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/