draft-ietf-ccamp-oam-configuration-fwk-10.txt		draft-ietf-ccamp-oam-configuration-fwk-11.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: December 17, 2013 Alcatel-Lucent		Expires: June 5, 2014 Alcatel-Lucent
	J. He		J. He
	Huawei		Huawei
	June 15, 2013		December 2, 2013
	GMPLS RSVP-TE extensions for OAM Configuration		GMPLS RSVP-TE extensions for OAM Configuration
	draft-ietf-ccamp-oam-configuration-fwk-10		draft-ietf-ccamp-oam-configuration-fwk-11
	Abstract		Abstract
	OAM is an integral part of transport connections, hence it is		Operations, Administration and Maintenance is an integral part of
	required that OAM functions are activated/deactivated in sync with		transport connections, hence it is required that Operations,
	connection commissioning/decommissioning; avoiding spurious alarms		Administration and Maintenance functions are activated/deactivated in
	and ensuring consistent operation. In certain technologies, OAM		sync with connection commissioning/decommissioning; avoiding spurious
	entities are inherently established once the connection is set up,		alarms and ensuring consistent operation. In certain technologies,
	while other technologies require extra configuration to establish and		Operations, Administration and Maintenance entities are inherently
	configure OAM entities. This document specifies extensions to		established once the connection is set up, while other technologies
	RSVP-TE to support the establishment and configuration of OAM		require extra configuration to establish and configure Operations,
	entities along with LSP signaling.		Administration and Maintenance entities. This document specifies
			extensions to RSVP-TE to support the establishment and configuration
			of Operations, Administration and Maintenance entities along with
			Label Switched Path signaling.
	Requirements Language		Requirements Language
	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].
	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 June 5, 2014.
	This Internet-Draft will expire on December 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	skipping to change at page 2, line 19		skipping to change at page 2, line 23
	(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 . . . . . . . 7
	3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8		3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9
	3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9		3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9
	4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10		4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 10
	4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10		4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 10
	4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11		4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
	4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12		4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 13
	4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . . 13		4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14
	4.3. Administrative Status Information . . . . . . . . . . . . 13		4.3. Administrative Status Information . . . . . . . . . . . . 14
	4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14		4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14
	4.5. Considerations on Point-to-Multipoint OAM Configuration . 14		4.5. Considerations on Point-to-Multipoint OAM Configuration . 15
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 18
			5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 18
			5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 19
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
			8.1. Normative References . . . . . . . . . . . . . . . . . . 20
			8.2. Informative References . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	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 6, line 31		skipping to change at page 6, line 36
	parameters for the LSP.		parameters for the LSP.
	o The extensions MUST allow the operator to use only a minimal set		o The extensions MUST allow the operator to use only a minimal set
	of OAM configuration and control features if supported by the OAM		of OAM configuration and control features if supported by the OAM
	solution or network management policy. Generic OAM parameters and		solution or network management policy. Generic OAM parameters and
	data plane or OAM technology specific parameters MUST be		data plane or OAM technology specific parameters MUST be
	supported.		supported.
	3. RSVP-TE based OAM Configuration		3. RSVP-TE based OAM Configuration
	In general, two types of Maintenance Points (MPs) can be		In general, two types of maintenance points can be distinguished:
	distinguished: Maintenance End Points (MEPs) and Maintenance		Maintenance Entity Group End Points (MEPs) and Maintenance Entity
	Intermediate Points (MIPs). MEPs reside at the ends of an LSP and		Group Intermediate Points (MIPs). MEPs reside at the ends of an LSP
	are capable of initiating and terminating OAM messages for Fault		and are capable of initiating and terminating OAM messages for Fault
	Management (FM) and Performance Monitoring (PM). MIPs on the other		Management (FM) and Performance Monitoring (PM). MIPs on the other
	hand, are located at transit nodes of an LSP and are capable of		hand, are located at transit nodes of an LSP and are capable of
	reacting to some OAM messages but otherwise do not initiate messages.		reacting to some OAM messages but otherwise do not initiate messages.
	Maintenance Entity (ME) refers to an association of MEPs and MIPs		Maintenance Entity (ME) refers to an association of MEPs and MIPs
	that are provisioned to monitor an LSP. The ME association is		that are provisioned to monitor an LSP.
	achieved by configuring MPs to belong to the same ME.
	When an LSP is signaled, a forwarding association is established		When an LSP is signaled, a forwarding association is established
	between endpoints and transit nodes via label bindings. This		between endpoints and transit nodes via label bindings. This
	association creates a context for the OAM entities monitoring the		association creates a context for the OAM entities monitoring the
	LSP. On top of this association, OAM entities may be configured to		LSP. On top of this association, OAM entities may be configured to
	unambiguously identify MPs and MEs.		unambiguously identify MEs.
	In addition to MP and ME identification parameters, pro-active OAM		In addition to ME identification parameters, pro-active OAM functions
	functions (e.g., Continuity Check (CC) and Performance Monitoring		(e.g., Continuity Check (CC) and Performance Monitoring (PM)) may
	(PM)) may have additional parameters that require configuration as		have additional parameters that require configuration as well. In
	well. In particular, the frequency of periodic CC packets and the		particular, the frequency of periodic CC packets and the measurement
	measurement interval for loss and delay measurements may need to be		interval for loss and delay measurements may need to be configured.
	configured.
	The above parameters may be either derived from LSP provisioning		The above parameters may be either derived from LSP provisioning
	information, or alternatively, pre-configured default values can be		information, or alternatively, pre-configured default values can be
	used. In the simplest case, the control plane MAY provide		used. In the simplest case, the control plane MAY provide
	information on whether or not OAM entities need to be setup for the		information on whether or not OAM entities need to be setup for the
	signaled LSP. If OAM entities are created, control plane signaling		signaled LSP. If OAM entities are created, control plane signaling
	MUST also provide a means to activate/deactivate OAM message flows		MUST also provide a means to activate/deactivate OAM message flows
	and associated alarms.		and associated alarms.
	OAM identifiers, as well as the configuration of OAM functions, are		OAM identifiers, as well as the configuration of OAM functions, are
	skipping to change at page 7, line 28		skipping to change at page 7, line 31
	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.
	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		enabled in the appropriate order. When using the GMPLS control plane
	plane, establishment and enabling of OAM functions MUST be bound to		for both LSP establishment and to enable OAM functions on the LSPs,
	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
	entities with the first signaling of the LSP. The below procedures		entities with the first signaling of the LSP. The below procedures
	apply to both cases.		apply to both cases.
	Before initiating a Path message with OAM Configuration information,		Before initiating a Path message with OAM Configuration information,
	an initiating node MUST establish and configure the corresponding OAM		an initiating node MUST establish and configure the corresponding OAM
	entities locally. But until the LSP is established, OAM source		entities locally. But until the LSP is established, OAM source
	skipping to change at page 8, line 11		skipping to change at page 8, line 15
	When the Path message arrives at the receiver, the remote end MUST		When the Path message arrives at the receiver, the remote end MUST
	establish and configure OAM entities according to the OAM information		establish and configure OAM entities according to the OAM information
	provided in the Path message. If this is not possible, a PathErr		provided in the Path message. If this is not possible, a PathErr
	SHOULD be sent and neither the OAM entities nor the LSP SHOULD be		SHOULD be sent and neither the OAM entities nor the LSP SHOULD be
	established. If OAM entities are established successfully, the OAM		established. If OAM entities are established successfully, the OAM
	sink function MUST be prepared to receive OAM messages, but MUST NOT		sink function MUST be prepared to receive OAM messages, but MUST NOT
	generate any OAM alarms (e.g., due to missing or unidentified OAM		generate any OAM alarms (e.g., due to missing or unidentified OAM
	messages). In the case of bidirectional connections, in addition to		messages). In the case of bidirectional connections, in addition to
	the OAM sink function, an OAM source function MUST be set up and,		the OAM sink function, an OAM source function MUST be set up and,
	according to the requested configuration, the OAM source function		according to the requested configuration, the OAM source function
	MUST start sending OAM messages. Then a Resv message is sent back,		MUST start sending OAM messages. Then a Resv message MUST be sent
	including the OAM Configuration TLV that corresponds to the		back, including the LSP_Attributes Flags TLV, with the appropriate
			setting of the "OAM MEP entities desired" and "OAM MIP entities
			desired" flags, and the OAM Configuration TLV that corresponds to the
	established and configured OAM entities and functions. Depending on		established and configured OAM entities and functions. Depending on
	the OAM technology, some elements of the OAM Configuration TLV MAY be		the OAM technology, some elements of the OAM Configuration TLV MAY be
	updated/changed; i.e., if the remote end is not supporting a certain		updated/changed; i.e., if the remote end is not supporting a certain
	OAM configuration it may suggest an alternative setting, which may or		OAM configuration it may suggest an alternative setting, which may or
	may not be accepted by the initiator of the Path message. If it is		may not be accepted by the initiator of the Path message. If it is
	accepted, the initiator will reconfigure its OAM functions according		accepted, the initiator will reconfigure its OAM functions according
	to the information received in the Resv message. If the alternate		to the information received in the Resv message. If the alternate
	setting is not acceptable a ResvErr may be sent tearing down the LSP.		setting is not acceptable a ResvErr may be sent tearing down the LSP.
	Details of this operation are technology specific and should be		Details of this operation are technology specific and should be
	described in accompanying technology specific documents.		described in accompanying technology specific documents.
	skipping to change at page 8, line 36		skipping to change at page 8, line 42
	OAM messages.		OAM messages.
	After this exchange, OAM entities are established and configured for		After this exchange, OAM entities are established and configured for
	the LSP and OAM messages are exchanged. OAM alarms can now be		the LSP and OAM messages are exchanged. OAM alarms can now be
	enabled. The initiator, during the period when OAM alarms are		enabled. The initiator, during the period when OAM alarms are
	disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS		disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS
	flag set. The receiving node enables the OAM alarms after processing		flag set. The receiving node enables the OAM alarms after processing
	the Path message. The initiator enables OAM alarms after it receives		the Path message. The initiator enables OAM alarms after it receives
	the Resv message. Data plane OAM is now fully functional.		the Resv message. Data plane OAM is now fully functional.
			In case an egress LSR does not support the extensions defined in this
			document, according to [RFC5420], it will silently ignore the new LSP
			Attributes Flags as well as the TLVs carrying additional OAM
			configuration information, and therefore no error will be raised that
			would notify the ingress LSR about the missing OAM configuration
			actions on the egress side. However, as described above, an egress
			LSR conformant to the specification of this document will set the LSP
			Attributes Flags and include the OAM Configuration TLV in the Resv
			message indicating the configuration of the OAM mechanisms, therefore
			an ingress LSR by detecting the missing information in the Resv
			message will be able to recognize that the remote end does not
			support the OAM configuration functionality and therefore it SHOULD
			tear down the LSP, and if appropriate, signal the LSP without any OAM
			configuration information.
	3.2. Adjustment of OAM Parameters		3.2. Adjustment of OAM Parameters
	There may be a need to change the parameters of an already		There may be a need to change the parameters of an already
	established and configured OAM function during the lifetime of the		established and configured OAM function during the lifetime of the
	LSP. To do so the LSP needs to be re-signaled with the updated		LSP. To do so the LSP needs to be re-signaled with the updated
	parameters. OAM parameters influence the content and timing of OAM		parameters. OAM parameters influence the content and timing of OAM
	messages and identify the way OAM defects and alarms are derived and		messages and identify the way OAM defects and alarms are derived and
	generated. Hence, to avoid spurious alarms, it is important that		generated. Hence, to avoid spurious alarms, it is important that
	both sides, OAM sink and source, are updated in a synchronized way.		both sides, OAM sink and source, are updated in a synchronized way.
	First, the alarms of the OAM sink function should be suppressed and		First, the alarms of the OAM sink function should be suppressed and
	skipping to change at page 9, line 25		skipping to change at page 9, line 45
	negotiation phase, in the case of adjusting already configured OAM		negotiation phase, in the case of adjusting already configured OAM
	functions, the receiving side SHOULD NOT update the parameters		functions, the receiving side SHOULD NOT update the parameters
	requested in the Path message to an extent that would provide lower		requested in the Path message to an extent that would provide lower
	performance (e.g., lower frequency of monitoring packets) than what		performance (e.g., lower frequency of monitoring packets) than what
	has been in operation previously.		has been in operation previously.
	The initiator MUST only update its OAM sink and source functions		The initiator MUST only update its OAM sink and source functions
	after it received the Resv message. After this Path/Resv message		after it received the Resv message. After this Path/Resv message
	exchange (in both unidirectional and bidirectional LSP cases) the OAM		exchange (in both unidirectional and bidirectional LSP cases) the OAM
	parameters are updated and OAM is running according the new parameter		parameters are updated and OAM is running according the new parameter
	settings. However, OAM alarms are still disabled. A subsequent		settings. However, OAM alarms are still disabled. A subsequent Path
	Path/Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS		/Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag
	flag set is needed to enable OAM alarms again.		set is needed to enable OAM alarms again.
	3.3. Deleting OAM Entities		3.3. Deleting OAM Entities
	In some cases it may be useful to remove some or all OAM entities and		In some cases it may be useful to remove some or all OAM entities and
	functions from an LSP without actually tearing down the connection.		functions from an LSP without actually tearing down the connection.
	To avoid any spurious alarms, first the LSP MUST be re-signaled with		To avoid any spurious alarms, first the LSP MUST be re-signaled with
	"OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM		"OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM
	configuration. Subsequently, the LSP is re-signaled with "OAM MEP		configuration. Subsequently, the LSP is re-signaled with "OAM MEP
	Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags		Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
	cleared, and without the OAM Configuration TLV, this MUST result in		cleared, and without the OAM Configuration TLV, this MUST result in
	the deletion of all OAM entities associated with the LSP. All		the deletion of all OAM entities associated with the LSP. All
	control and data plane resources in use by the OAM entities and		control and data plane resources in use by the OAM entities and
	skipping to change at page 10, line 50		skipping to change at page 11, line 23
	of the signaled LSP. If the establishment of MEPs is not supported		of the signaled LSP. If the establishment of MEPs is not supported
	an error MUST be generated: "OAM Problem/MEP establishment not		an error MUST be generated: "OAM Problem/MEP establishment not
	supported".		supported".
	If the "OAM MEP entities desired" bit is set and additional		If the "OAM MEP entities desired" bit is set and additional
	parameters need to be configured, an OAM Configuration TLV MAY be		parameters need to be configured, an OAM Configuration TLV MAY be
	included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.		included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
	One bit (IANA to assign): "OAM MIP entities desired" is allocated in		One bit (IANA to assign): "OAM MIP entities desired" is allocated in
	the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or		the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
	LSP_REQUIRED_ATTRIBUES objects. This bit MUST only be set if the		LSP_REQUIRED_ATTRIBUES objects. If the "OAM MEP entities desired"
	"OAM MEP entities desired" bit is set. If the "OAM MIP entities		bit is not set then this bit MUST NOT be set. If the "OAM MIP
	desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the		entities desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the
	LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the		LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
	establishment of OAM MIP entities is required at every transit node		establishment of OAM MIP entities is required at every transit node
	of the signaled LSP. If the establishment of a MIP is not supported		of the signaled LSP. If the establishment of a MIP is not supported
	an error MUST be generated: "OAM Problem/MIP establishment not		an error MUST be generated: "OAM Problem/MIP establishment not
	supported".		supported". If an intermediate LSR does not support the extensions
			defined in this document it will not recognize the "OAM MIP entities
			desired" flag and although the LSP_REQUIRED_ATTRIBUTES object was
			used it will not configure MIP entities and will not raise any
			errors. If LSRs that are not supporting this document are to be
			assumed in the network, the ingress LSR SHOULD collect per-hop
			information about the LSP Attributes utilizing the LSP Attributes
			sub-object of the Record Route Object as defined in [RFC5420]. When
			the Record Route object is received the ingress SHOULD check whether
			all intermediate LSRs set the "OAM MIP entities desired" flag
			indicating support of the function, if not, depending on operator
			policy the LSP MAY need to be torn down.
	4.2. OAM Configuration TLV		4.2. OAM Configuration TLV
	This TLV provides information about which OAM technology/method		This TLV provides information about which OAM technology/method
	should be used and carries sub-TLVs for any additional OAM		should be used and carries sub-TLVs for any additional OAM
	configuration information. The OAM Configuration TLV MAY be carried		configuration information. One OAM Configuration TLV MAY be carried
	in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and		in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
	Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object,		Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object,
	it is indicating that intermediate nodes MUST recognize and react on		it is indicating that intermediate nodes MUST recognize and react on
	the OAM configuration information.		the OAM configuration information.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (IANA) | Length |		| Type (IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OAM Type | Reserved |		| OAM Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ sub-TLVs ~		~ sub-TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: indicates a new type: the OAM Configuration TLV (3) (IANA to		Type: indicates a new type: the OAM Configuration TLV (IANA to
	assign).		assign).
	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], and only Label		object forward unchanged as specified in [RFC5420]. Ingress and
	Edge Nodes MUST generate an error if the OAM Type is not supported at		egress nodes that support the OAM Configuration TLV but that do not
	the LSP end-point.		support a specific OAM Type MUST respond with an error indicating
			"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
			specific sub-TLVs. Generic sub-TLVs carry information that are
			applicable independent of the actual OAM technology, while technology
			specific sub-TLVs are providing configuration parameters for specific
			OAM technologies. This document defines one generic sub-TLV, see
			Section 4.2.1, while it is foreseen that technology specific sub-TLVs
			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
	Error".		Error".
	4.2.1. OAM Function Flags Sub-TLV		4.2.1. OAM Function Flags Sub-TLV
	As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be		The "OAM Configuration TLV" MUST always include a single instance of
	included in the "OAM Configuration TLV". "OAM Function Flags"		the "OAM Function Flags Sub-TLV" and it MUST always be the first sub-
	specifies which pro-active OAM functions (e.g., connectivity		TLV. "OAM Function Flags" specifies which pro-active OAM functions
	monitoring, loss and delay measurement) and which fault management		(e.g., connectivity monitoring, loss and delay measurement) and which
	signals MUST be established and configured. If the selected OAM		fault management signals MUST be established and configured. If the
	Function(s) is(are) not supported, an error MUST be generated: "OAM		selected OAM Function(s) is(are) not supported, an error MUST be
	Problem/Unsupported OAM Function".		generated: "OAM Problem/Unsupported OAM Function".
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (1) (IANA) | Length |		| Type (1) (IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ OAM Function Flags ~		~ OAM Function Flags ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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. IANA		Length field of the TLV. Bits are numbered from left to right. The
	is requested to maintain the OAM Function Flags in the new "RSVP-TE		TLV is padded to 4-octet alignment. The Length field indicates the
	OAM Configuration Registry". This document defines the following		size of the padded TLV in octets. IANA is requested to maintain the
	flags.		OAM Function Flags in the new "RSVP-TE OAM Configuration Registry".
			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
	One technology specific sub-TLV MAY be defined for each "OAM Type".		If technology-specific configuration information is needed for a
	This sub-TLV MUST contain any further OAM configuration information		specific "OAM Type", then this information is carried in a
	for that specific "OAM Type". The technology specific sub-TLV, when		technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM
	used, MUST be carried within the OAM Configuration TLV. IANA is		Configuration TLV MUST NOT contain more than one technology- specific
	requested to maintain the OAM technology specific sub-TLV space in		sub-TLV. IANA is requested to maintain the OAM technology specific
	the new "RSVP-TE OAM Configuration Registry".		sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
	4.3. Administrative Status Information		4.3. Administrative Status Information
	Administrative Status Information is carried in the ADMIN_STATUS		Administrative Status Information is carried in the ADMIN_STATUS
	Object. The Administrative Status Information is described in		Object. The Administrative Status Information is described in
	[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in		[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
	[RFC3473].		[RFC3473].
	Two bits are allocated for the administrative control of OAM		Two bits are allocated for the administrative control of OAM
	monitoring. Two bits (IANA to assign) are allocated by this draft:		monitoring. Two bits (IANA to assign) are allocated by this
	the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When		document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O)
	the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is		bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST
	cleared, no OAM packets are emitted. When the "OAM Alarms Enabled"		be enabled; if it is cleared, OAM mechanisms MUST be disabled. When
	bit is set OAM triggered alarms are enabled and associated consequent		the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled
	actions are executed including the notification to the management		and associated consequent actions MUST be executed including the
	system. When this bit is cleared, alarms are suppressed and no		notification to the management system. When this bit is cleared,
	action is executed and the management system is not notified.		alarms are suppressed and no action SHOULD be executed and the
			management system SHOULD NOT be notified. For a detailed description
			of the use of these flags see Section 3.
	4.4. Handling OAM Configuration Errors		4.4. Handling OAM Configuration Errors
	To handle OAM configuration errors, a new Error Code (IANA to assign)		To handle OAM configuration errors, a new Error Code (IANA to assign)
	"OAM Problem" is introduced. To refer to specific problems, a set of		"OAM Problem" is introduced. To refer to specific problems, a set of
	Error Values are defined under the "OAM Problem" error code.		Error Values are defined under the "OAM Problem" error code.
	If a node does not support the establishment of OAM MEP or MIP		If a node does not support the establishment of OAM MEP or MIP
	entities it MUST use the error value: "MEP establishment not		entities it MUST use the error value: "MEP establishment not
	supported" or "MIP establishment not supported" respectively in the		supported" or "MIP establishment not supported" respectively in the
	skipping to change at page 16, line 7		skipping to change at page 16, line 36
	message flow can be enabled. Such action could be to setup two		message flow can be enabled. Such action could be to setup two
	independent P2MP LSPs. One LSP with OAM Configuration information		independent P2MP LSPs. One LSP with OAM Configuration information
	towards leaves which could successfully setup the OAM function. This		towards leaves which could successfully setup the OAM function. This
	can be done by pruning the leaves which failed to setup OAM of the		can be done by pruning the leaves which failed to setup OAM of the
	previously signaled P2MP LSP. The other P2MP LSP could be		previously signaled P2MP LSP. The other P2MP LSP could be
	constructed for leaves without OAM entities. The exact procedures		constructed for leaves without OAM entities. The exact procedures
	will be described in technology specific documents.		will be described in technology specific documents.
	5. IANA Considerations		5. IANA Considerations
	Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs		5.1. ADMIN_STATUS Object Bit Flags
	to be allocated in the ADMIN_STATUS Object.
	Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")		IANA maintains a registry called "Generalized Multi-Protocol Label
	needs to be allocated in the LSP Attributes Flags Registry.		Switching (GMPLS) Signaling Parameters" with a sub-registry called
			"Administrative Status Information Flags".
	This document specifies one new TLV to be carried in the		IANA is requested to allocate two new flags as follows:
	LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv
	messages: OAM Configuration TLV.
	One new Error Code: "OAM Problem" and a set of new values: "MEP		Bit Number | Hex Value | Name | Reference
	establishment not supported", "MIP establishment not supported",		-----------+------------+--------------------------+-----------
	"Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch"		TBA | TBA | OAM Alarms Enabled (O) | [This.ID]
	and "Unsupported OAM Function" needs to be assigned.		TBA | TBA | OAM Flows Enabled (M) | [This.ID]
	IANA is requested to open a new registry: "RSVP-TE OAM Configuration		5.2. LSP Attributes Flags
	Registry" that maintains the "OAM Type" code points, an associated		IANA maintains a registry called "Resource Reservation Protocol-
	sub-TLV space, and the allocations of "OAM Function Flags" within the		Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
	OAM Configuration TLV.		"Attribute Flags".
	RSVP-TE OAM Configuration Registry		IANA is requested to allocate two new flags as follows:
	OAM Type Description		Bit | Name | Attribute | Attribute | RRO | Reference
	------------ ------------------		No | | Flags Path | Flags Resv | |
	0-255 Reserved		----+------------------+------------+------------+-----+----------
			TBA | OAM MEP | | | |
			| entities desired | Yes | Yes | Yes | [This.ID]
			| | | | |
			TBA | OAM MIP | | | |
			| entities desired | Yes | Yes | Yes | [This.ID]
	Sub-TLV Type Description		5.3. New LSP Attributes
	------------ ------------------------------------
	0 Reserved
	1 OAM Function Flags Sub-TLV
	2-31 Reserved for generic Sub-TLVs
	32- Reserved for technology specific Sub-TLVs
	OAM Function Flag bit# Description		IANA maintains a registry called "Resource Reservation Protocol-
	---------------------- -------------------------------		Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
	0 Continuity Check (CC)		"Attributes TLV Space"
	1 Connectivity Verification (CV)
	2 Fault Management Signal (FMS)		IANA is requested to allocate one new TLV type as follows:
	3 Performance Monitoring/Loss (PM/Loss)
	4 Performance Monitoring/Delay (PM/Delay)		Type| Name |Allowed on |Allowed on |Reference
	5 Performance Monitoring/Throughput Measurement		| |LSP_ATTRIBUTES|LSP_REQUIRED_|
	(PM/Throughput)		| | |ATTRIBUTES |
	6- Reserved		----+----------------------+--------------+-------------+---------
			TBA| OAM Configuration TLV| Yes | Yes |[This.ID]
			5.4. RSVP Error Code
			IANA maintains a registry called "Resource Reservation Protocol
			(RSVP) Parameters" with a subregistry called "Error Codes and
			Globally-Defined Error Value Sub-Codes".
			IANA is requested to allocate one new Error Code as follows:
			Error Code | Meaning | Reference
			-----------+-------------+-------------
			TBA | OAM Problem | [This.ID]
			The value is to be selected from the range 0-239.
			The following Error Value sub-codes are defined for this new Error
			Code as follows:
			Value | Description | Reference
			------+---------------------------------+--------------
			1 | MEP establishment not supported | [This.ID]
			2 | MIP establishment not supported | [This.ID]
			3 | Unsupported OAM Type | [This.ID]
			4 | Configuration Error | [This.ID]
			5 | OAM Type Mismatch | [This.ID]
			6 | Unsupported OAM Function | [This.ID]
			5.5. RSVP-TE OAM Configuration Registry
			IANA is requested to create a new registry called "RSVP-TE OAM
			Configuration Registry".
			IANA is requested to create sub-registries as defined in the
			following subsections:
			5.5.1. OAM Types Sub-Registry
			IANA is requested to create the "OAM Types" sub-registry of the
			"RSVP-TE OAM Configuration Registry" as follows:
			Range | Registration Procedures
			-------+-------------------------
			0-255 | IETF Review
			There are no initial values in this registry. IANA should show the
			registry as follows:
			OAM Type Number | OAM Type Description | Reference
			----------------+----------------------+--------------
			0-255 | Not allocated |
			5.5.2. OAM Sub-TLVs Sub-Registry
			IANA is requested to create the "OAM Sub-TLVs" sub-registry of the
			"RSVP-TE OAM Configuration Registry" as follows:
			Range | Purpose | Registration Procedures
			------------+------------------------------|------------------------
			0-31 | Generic Sub-TLVs | IETF Review
			32-65534 | Technology-specific Sub-TLVs | IETF Review
			65535-65536 | Experimental Sub-TLVs | Experimental
			IANA is requested to populate the registry as follows:
			Sub-TLV Type | Description | Reference
			-------------+----------------------------+-------
			0 | Reserved | [This.ID]
			1 | OAM Function Flags Sub-TLV | [This.ID]
			2-31 | Not allocated |
			32-65534 | Not allocated |
			5.5.3. 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".
			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
			bit transmitted.
			IANA is requested to populate the registry as follows.
			OAM Function Flag | Description
			bit number |
			------------------+---------------------------------------------
			0 | Continuity Check (CC)
			1 | Connectivity Verification (CV)
			2 | Fault Management Signal (FMS)
			3 | Performance Monitoring/Loss (PM/Loss)
			4 | Performance Monitoring/Delay (PM/Delay)
			5 | Performance Monitoring/Throughput Measurement
			| (PM/Throughput)
			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
	skipping to change at page 18, line 17		skipping to change at page 20, line 40
	[IEEE.802.1Q-2011]		[IEEE.802.1Q-2011]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks -- Media Access Control (MAC) Bridges and Virtual		networks -- Media Access Control (MAC) Bridges and Virtual
	Bridged Local Area Networks", IEEE Std 802.1Q, 2011.		Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
	[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic		[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
	Authentication", RFC 2747, January 2000.		Authentication", RFC 2747, January 2000.
	[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.		[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
	Matsushima, "Operations and Management (OAM) Requirements		Matsushima, "Operations and Management (OAM) Requirements
	for Multi-Protocol Label Switched (MPLS) Networks",		for Multi-Protocol Label Switched (MPLS) Networks", RFC
	RFC 4377, February 2006.		4377, February 2006.
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,		Label Switched (MPLS) Data Plane Failures", RFC 4379,
	February 2006.		February 2006.
	[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,		[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
	"Extensions to Resource Reservation Protocol - Traffic		"Extensions to Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		Engineering (RSVP-TE) for Point-to-Multipoint TE Label
	Switched Paths (LSPs)", RFC 4875, May 2007.		Switched Paths (LSPs)", RFC 4875, May 2007.
	[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,		[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
	and S. Ueno, "Requirements of an MPLS Transport Profile",		and S. Ueno, "Requirements of an MPLS Transport Profile",
	RFC 5654, September 2009.		RFC 5654, September 2009.
	[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized		[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized
	Multiprotocol Label Switching (GMPLS) Ethernet Label		Multiprotocol Label Switching (GMPLS) Ethernet Label
	Switching Architecture and Framework", RFC 5828,		Switching Architecture and Framework", RFC 5828, March
	March 2010.		2010.
	[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for		[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
	Operations, Administration, and Maintenance (OAM) in MPLS		Operations, Administration, and Maintenance (OAM) in MPLS
	Transport Networks", RFC 5860, May 2010.		Transport Networks", RFC 5860, May 2010.
	[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.		Networks", RFC 5920, July 2010.
	[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.		[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
	Berger, "A Framework for MPLS in Transport Networks",		Berger, "A Framework for MPLS in Transport Networks", RFC
	RFC 5921, July 2010.		5921, July 2010.
	[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,		[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
	"Generalized Multiprotocol Label Switching (GMPLS) Control		"Generalized Multiprotocol Label Switching (GMPLS) Control
	of Ethernet Provider Backbone Traffic Engineering		of Ethernet Provider Backbone Traffic Engineering (PBB-
	(PBB-TE)", RFC 6060, March 2011.		TE)", RFC 6060, March 2011.
	Authors' Addresses		Authors' Addresses
	Attila Takacs		Attila Takacs
	Ericsson		Ericsson
	Konyves Kalman krt. 11.		Konyves Kalman krt. 11.
	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: donald.fedyk@alcatel-lucent.com
End of changes. 44 change blocks.
	154 lines changed or deleted		294 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/