draft-ietf-ccamp-oam-configuration-fwk-02.txt		draft-ietf-ccamp-oam-configuration-fwk-03.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: April 29, 2010 Alcatel-Lucent		Expires: August 1, 2010 Alcatel-Lucent
	J. He		J. He
	Huawei		Huawei
	October 26, 2009		January 28, 2010
	OAM Configuration Framework and Requirements for GMPLS RSVP-TE		OAM Configuration Framework and Requirements for GMPLS RSVP-TE
	draft-ietf-ccamp-oam-configuration-fwk-02		draft-ietf-ccamp-oam-configuration-fwk-03
			Abstract
			OAM is an integral part of transport connections, hence it is
			required that OAM functions are activated/deactivated in sync with
			connection commissioning/decommissioning; avoiding spurious alarms
			and ensuring consistent operation. In certain technologies OAM
			entities are inherently established once the connection is set up,
			while other technologies require extra configuration to establish and
			configure OAM entities. This document specifies extensions to
			RSVP-TE to support the establishment and configuration of OAM
			entities along with LSP signaling.
			Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35		skipping to change at page 2, line 32
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 29, 2010.		This Internet-Draft will expire on August 1, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	OAM is an integral part of transport connections, hence it is		described in the BSD License.
	required that OAM functions are activated/deactivated in sync with
	connection commissioning/decommissioning; avoiding spurious alarms
	and ensuring consistent operation. In certain technologies OAM
	entities are inherently established once the connection is set up,
	while other technologies require extra configuration to establish and
	configure OAM entities. This document specifies extensions to
	RSVP-TE to support the establishment and configuration of OAM
	entities along with LSP signaling.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 9		3. GMPLS based OAM Configuration . . . . . . . . . . . . . . . . 8
	3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 9		3.1. Establishment of OAM Entities and Functions . . . . . . . 8
	3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 10		3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10
	3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11		3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10
	3.4. TCME Configuration TLV . . . . . . . . . . . . . . . . . . 13		4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12
	3.5. NIME Configuration TLV . . . . . . . . . . . . . . . . . . 14		4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12
	3.6. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 15		4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12
	3.7. OAM configuration errors . . . . . . . . . . . . . . . . . 15		4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 18		4.3. Administrative Status Information . . . . . . . . . . . . 14
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15
	Appendix A. Discussion on alternatives . . . . . . . . . . . . . 20		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
			Appendix A. Discussion on Alternatives . . . . . . . . . . . . . 19
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 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 lately Ethernet		division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet
	Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS		Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS
	Transport Profile (MPLS-TP). In most of these technologies there are		Transport Profile (MPLS-TP). In most of these technologies there are
	skipping to change at page 4, line 43		skipping to change at page 4, line 43
	selectively configurable.		selectively configurable.
	In general, it is required that the management plane and control		In general, it is required that the management plane and control
	plane connection establishment mechanisms are synchronized with OAM		plane connection establishment mechanisms are synchronized with OAM
	establishment and activation. In particular, if the GMPLS control		establishment and activation. In particular, if the GMPLS control
	plane is employed it is desirable to bind OAM setup and configuration		plane is employed it is desirable to bind OAM setup and configuration
	to connection establishment signaling to avoid two separate		to connection establishment signaling to avoid two separate
	management/configuration steps (connection setup followed by OAM		management/configuration steps (connection setup followed by OAM
	configuration) which increases delay, processing and more importantly		configuration) which increases delay, processing and more importantly
	may be prune to misconfiguration errors. Once OAM entities are setup		may be prune to misconfiguration errors. Once OAM entities are setup
	and configured pro-active as well as on-demand OAM functions can be		and configured, pro-active as well as on-demand OAM functions can be
	activated via the management plane. On the other hand, it should be		activated via the management plane. On the other hand, it should be
	possible to activate/deactivate pro-active OAM functions via the		possible to activate/deactivate pro-active OAM functions via the
	GMPLS control plane as well.		GMPLS control plane as well.
	This document describes requirements on OAM configuration and control		This document describes requirements on OAM configuration and control
	via RSVP-TE, and specifies extensions to the RSVP-TE protocol		via RSVP-TE, and specifies extensions to the RSVP-TE protocol
	providing a framework to configure and control OAM entities along		providing a framework to configure and control OAM entities along
	with capability to carry technology specific information. Extensions		with the capability to carry technology specific information.
	can be grouped into generic elements that are applicable to any OAM		Extensions can be grouped into generic elements that are applicable
	solution and technology specific elements that provide additional		to any OAM solution and technology specific elements that provide
	configuration parameters only needed for a specific OAM technology.		additional configuration parameters, only needed for a specific OAM
	This document specifies the technology agnostic elements which alone		technology. This document specifies the technology agnostic
	can be used to establish and control OAM entities in the case no		elements, which alone can be used to establish and control OAM
	technology specific information is needed, and specifies the way		entities in the case no technology specific information is needed,
	additional technology specific OAM parameters are provided.		and specifies the way additional technology specific OAM parameters
			are provided.
			This document addresses end-to-end OAM configuration, that is, the
			setup of OAM entities bound to an end-to-end LSP, and configuration
			and control of OAM functions running end-to-end in the LSP.
			Configuration of OAM entities for LSP segments and tandem connections
			are out of the scope of this document.
	The mechanisms described in this document provide an additional		The mechanisms described in this document provide an additional
	option for bootstrapping OAM that is not intended to replace or		option for bootstrapping OAM that is not intended to replace or
	deprecate the use of other technology specific OAM bootstrapping		deprecate the use of other technology specific OAM bootstrapping
	techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The		techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The
	procedures specified in this document are intended only for use in		procedures specified in this document are intended only for use in
	environments where RSVP-TE signaling is already in use to set up the		environments where RSVP-TE signaling is already in use to set up the
	LSPs that are to be monitored using OAM.		LSPs that are to be monitored using OAM.
	2. Requirements		2. Requirements
	MPLS OAM requirements are described in [RFC4377]. It provides		MPLS OAM requirements are described in [RFC4377], which provides
	requirements to create consistent OAM functionality for MPLS		requirements to create consistent OAM functionality for MPLS
	networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The		networks.
	GMPLS OAM requirements are based on the MPLS OAM requirements
	[RFC4377], in addition it also considers the existing OAM techniques
	in non-packet networks.
	The following list is an excerpt of MPLS OAM requirements documented		The following list is an excerpt of MPLS OAM requirements documented
	in [RFC4377]. Only a few requirements are discussed that bear a		in [RFC4377]. Only a few requirements are discussed that bear a
	direct relevance to the discussion set forth in this document.		direct relevance to the discussion set forth in this document.
	o It is desired to support the automation of LSP defect detection.		o It is desired to support the automation of LSP defect detection.
	It is especially important in cases where large numbers of LSPs		It is especially important in cases where large numbers of LSPs
	might be tested.		might be tested.
	o In particular some LSPs may require automated ingress-LSR to		o In particular some LSPs may require automated ingress-LSR to
	skipping to change at page 6, line 38		skipping to change at page 6, line 35
	synchronizing defect detection times by setting appropriately		synchronizing defect detection times by setting appropriately
	bounded detection timeframes.		bounded detection timeframes.
	MPLS-TP defines a profile of MPLS targeted at transport applications		MPLS-TP defines a profile of MPLS targeted at transport applications
	[MPLS-TP-FWK]. This profile specifies the specific MPLS		[MPLS-TP-FWK]. This profile specifies the specific MPLS
	characteristics and extensions required to meet transport		characteristics and extensions required to meet transport
	requirements, including providing additional OAM, survivability and		requirements, including providing additional OAM, survivability and
	other maintenance functions not currently supported by MPLS.		other maintenance functions not currently supported by MPLS.
	Specific OAM requirements for MPLS-TP are specified in		Specific OAM requirements for MPLS-TP are specified in
	[MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane		[MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane
	to configure and control OAM entities.		to configure and control OAM entities:
	o The use of OAM functions SHOULD be optional for the operator. A		o The use of OAM functions SHOULD be optional for the operator. A
	network operator SHOULD be able to choose which OAM functions to		network operator SHOULD be able to choose which OAM functions to
	use and which Maintenance Entity to apply them to.		use and which Maintenance Entity to apply them to.
	o The MPLS-TP control plane MUST support the configuration and		o The MPLS-TP control plane MUST support the configuration and
	modification of OAM maintenance points as well as the activation/		modification of OAM maintenance points as well as the activation/
	deactivation of OAM when the transport path is established or		deactivation of OAM when the transport path is established or
	modified. OAM functions SHOULD be configurable as part of		modified. OAM functions SHOULD be configurable as part of
	connectivity (LSP or PW) management.		connectivity (LSP or PW) management.
	Ethernet Connectivity Fault Management (CFM) defines an adjunct
	connectivity monitoring OAM flow to check the liveliness of Ethernet
	networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will
	support explicitly-routed Ethernet connections. CFM can be used to
	track the liveliness of PBB-TE connections and detect data plane
	failures. In IETF the GMPLS controlled Ethernet Label Switching
	(GELS) [GELS-Framework] work is extending the GMPLS control plane to
	support the establishment of point-to-point PBB-TE data plane
	connections. Without control plane support separate management
	commands would be needed to configure and start CFM.
	GMPLS based OAM configuration and control should be general to be		GMPLS based OAM configuration and control should be general to be
	applicable to a wide range of data plane technologies and OAM		applicable to a wide range of data plane technologies and OAM
	solution. There are three typical data plane technologies used for		solutions. There are three typical data plane technologies used for
	transport application, which are wavelength based such as WSON, TDM		transport application, which are wavelength based such as WSON, TDM
	based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK]		based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK]
	and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the		and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the
	operator MUST be able to configure and control the following OAM		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
	the setup if this is required by the technology.		the setup if this is required by the technology.
	skipping to change at page 7, line 48		skipping to change at page 7, line 34
	to be able to balance the trade-off in fast failure detection and		to be able to balance the trade-off in fast failure detection and
	overhead it is beneficial to configure the frequency of continuity		overhead it is beneficial to configure the frequency of continuity
	check messages on a per LSP basis.		check messages on a per LSP basis.
	o Pro-active Performance Monitoring (PM) functions are continuously		o Pro-active Performance Monitoring (PM) functions are continuously
	collecting information about specific characteristics of the		collecting information about specific characteristics of the
	connection. For consistent measurement of Service Level		connection. For consistent measurement of Service Level
	Agreements (SLAs) it may be required that measurement points agree		Agreements (SLAs) it may be required that measurement points agree
	on a common probing rate to avoid measurement problems.		on a common probing rate to avoid measurement problems.
	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 the data plane		of OAM configuration and control features if the data plane
	technology, the OAM solution or network management policy allows.		technology, the OAM solution or network management policy allows.
	The extensions must be reusable as much as reasonably possible.		The extensions must be reusable as much as reasonably possible.
	That is generic OAM parameters and data plane or OAM technology		That is generic OAM parameters and data plane or OAM technology
	specific parameters must be separated.		specific parameters must be separated.
	3. GMPLS RSVP-TE Extensions		3. GMPLS based OAM Configuration
	3.1. Operation overview
	In general, two types of Maintenance Poits (MPs) can be		In general, two types of Maintenance Poits (MPs) can be
	distinguished: Maintenance End Points (MEPs) and Maintenance		distinguished: Maintenance End Points (MEPs) and Maintenance
	Intermediate Points (MIPs). MEPs are capable of initiating and		Intermediate Points (MIPs). MEPs reside at the ends of an LSP and
	terminating OAM messages for Fault Management (FM) and Performance		are capable of initiating and terminating OAM messages for Fault
	Monitoring (PM). MIPs on the other hand are located at transit nodes		Management (FM) and Performance Monitoring (PM). MIPs on the other
	of an LSP and are capable of reacting to some OAM messages but		hand are located at transit nodes of an LSP and are capable of
	otherwise do not initiate messages. Maintenance Entity (ME) refers		reacting to some OAM messages but otherwise do not initiate messages.
	to an association of MEPs and MIPs that are provisioned to monitor an		Maintenance Entity (ME) refers to an association of MEPs and MIPs
	LSP. The ME association is achieved by configuring MPs of an ME with		that are provisioned to monitor an LSP. The ME association is
	the same unique ME Assocication ID (MA ID). Each MEP must have		achieved by configuring MPs to belong to the same ME.
	unique identification (MEP ID) within a Maintenance Entity.
	When an LSP is signaled forwarding association is established between
	endpoints and transit nodes via label bindings. This association
	creates a context for the OAM entities monitoring the LSP. On top of
	this association OAM entities may be configured with an MA ID and MEP
	IDs. The MA ID may be used to detect misconfiguration errors and
	leaking OAM traffic. While the MEP ID can be used to demultiplex and
	identify the originating MEP of OAM messages. Since MIPs do not
	originate OAM packets, on top of the configuration of Maintenance
	Entity associations, no specific configuration is required for them.
	Along the LSP several Tandem Connections may be provisioned and
	associated to the end-to-end connection. These Tandem Connections
	may implement their own OAM monitoring entities. The Tandem
	Connection Maintenance Entities (TCMEs) provide the same monitoring
	capabilities for a segment of a connection as what is possible on an
	end-to-end basis. As the endpoints of a TCME may be (and usually
	are) intermediate nodes of an end-to-end LSP, the placement of TCME
	ingress and egress endpoints must be explicitly identified.
	Altough provisioned together with the end-to-end connection, each
	TCME defines a new context for the OAM entities, which is independent
	from the end-to-end connection. The MA ID and MEP IDs for a TCME are
	within this new context.
	When an LSP is signaled Non-Intrusive Maintenance Elements (NIME) may		When an LSP is signaled, forwarding association is established
	be deployed along the path. These elements differ from the MIPs as		between endpoints and transit nodes via label bindings. This
	they implemetn egress MEP functions: they not only process OAM		association creates a context for the OAM entities monitoring the
	messages but they can also trigger consequent actions, for instance,		LSP. On top of this association OAM entities may be configured to
	initiate segment protection switching. The NIMEs belong to the OAM		unambigously identify MPs and MEs.
	entity context of the end-to-end LSP and, thus, the same MA ID is
	applied. As the NIMEs are placed at intermediate nodes, their
	placement must be explicitly indicated.
	In addition to the MA and MEP identification parameters pro-active		In addition to MP and ME identification parameters pro-active OAM
	OAM functions (e.g., Continuity Check (CC), Performance Monitoring)		functions (e.g., Continuity Check (CC), Performance Monitoring) may
	may have specific parameters requiring configuration as well. In		have specific parameters requiring configuration as well. In
	particular, the frequency of periodic CC packets and the measurement		particular, the frequency of periodic CC packets and the measurement
	interval for loss and delay measurements may need to be configured.		interval for loss and delay measurements may need to be configured.
	MEP
	+-------------+
	|OAM Functions|
	| FM | PM |
	+------+------+
	| MEP ID |
	+-------------+
	| MA ID |
	+-------------+
	+-------------+
	| connection |
	+-------------+
	In some cases all the above parameters may be either derived form		In some cases all the above parameters may be either derived form
	some exiting information or pre-configured default values can be		some exiting information or pre-configured default values can be
	used. In the simplest case the control plane needs to provide		used. In the simplest case the control plane needs to provide
	information whether or not a MA with MPs need to be setup for the		information whether or not OAM entities need to be setup for the
	signaled LSP. If OAM entities are created signaling must provide		signaled LSP. If OAM entities are created signaling must provide
	means to activate/deactivate OAM message flows and associated alarms.		means to activate/deactivate OAM message flows and associated alarms.
	MA and MEP IDs as well as 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. The		data plane technology a set of OAM solutions may be applicable. The
	OAM configuration framework allows selecting a specific OAM solution		OAM configuration framework allows selecting a specific OAM solution
	to be used for the signaled LSP and provides technology specific TLVs		to be used for the signaled LSP and provides technology specific TLVs
	to carry further detailed configuration information.		to carry further detailed configuration information.
	3.2. LSP Attributes flags		3.1. Establishment of OAM Entities and Functions
			In order to avoid spurious alarms OAM functions must be setup and
			enabled in the appropriate order. When using the GMPLS control
			plane, establishment and enabling of OAM functions must be bound to
			RSVP-TE message exchanges.
			An LSP may be signaled and established without OAM configuration
			first, and OAM entities may be added later with a subsequent re-
			signaling of the LSP. Alternatively, the LSP may be setup with OAM
			entities right with the first signaling of the LSP. The below
			procedures apply to both cases.
			Before the initiator first sends a Path messages with OAM
			Configuration information, it MUST establish and configure the
			corresponding OAM entities locally, however OAM source functions MUST
			NOT start sending any OAM messages. In the case of bidirectional
			connections, the initiator node MUST setup the OAM sink function to
			be prepared to receive OAM messages but MUST suppress any OAM alarms
			(e.g., due to missing or unidentified OAM messages). The Path
			message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag
			cleared, i.e, data plane OAM alarms are suppressed.
			When the Path message arrives at the receiver, the remote end MUST
			establish and configure OAM entities according to the OAM information
			provided in Path message. If this is not possible a PathErr SHOULD
			be sent and neither the OAM entities nor the LSP SHOULD be
			established. If OAM entities are established successfully, the OAM
			sink function MUST be prepared to receive OAM messages but MUST not
			generate any OAM alarms (e.g., due to missing or unidentified OAM
			messages). In the case of bidirectional connections, an OAM source
			function MUST be setup and, according to the requested configuration,
			it MUST start sending OAM messages. Then a Resv message is sent
			back, including the OAM Configuration TLV that corresponds to the
			actually established and configured OAM entities and functions.
			Depending on 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 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 accepted, the initiator will
			reconfigure its OAM functions according to the information received
			in the Resv message. If the alternate setting is not acceptable a
			ResvErr may be sent tearing down the LSP. Details of this operation
			are technology specific and should be described in accompanying
			technology specific documents.
			When the initiating side receives the Resv message it completes any
			pending OAM configuration and enables the OAM source function to send
			OAM messages.
			After this round, OAM entities are established and configured for the
			LSP and OAM messages MAY already be exchanged. OAM alarms can now be
			enabled. The initiator, while still keeping OAM alarms disabled
			sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set.
			The receiving node enables the OAM alarms after processing the Path
			message. The initiator enables OAM alarms after it receives the Resv
			message. Data plane OAM is now fully functional.
			3.2. Adjustment of OAM Parameters
			There may be a need to change the parameters of an already
			established and configured OAM function during the lifetime of the
			LSP. To do so the LSP needs to be re-signaled with the updated
			parameters. OAM parameters influence the content and timing of OAM
			messages and identify the way OAM defects and alarms are derived and
			generated. Hence, to avoid spurious alarms, it is important that
			both sides, OAM sink and source, are updated in a synchronized way.
			First, the alarms of the OAM sink function should be suppressed and
			only then should expected OAM parameters be adjusted. Subsequently,
			the parameters of the OAM source function can be updated. Finally,
			the alarms of the OAM sink side can be enabled again.
			In accordance with the above operation, the LSP MUST first be re-
			signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared and
			including the updated OAM Configuration TLV corresponding to the new
			parameter settings. The initiator MUST keep its OAM sink and source
			functions running unmodified, but it MUST suppress OAM alarms after
			the updated Path message is sent. The receiver MUST first disable
			all OAM alarms, then update the OAM paramaters according to the
			information in the Path message and reply with a Resv message
			acknowledging the changes by including the OAM Configuration TLV.
			Note that the receiving side has the possibility to adjust the
			requested OAM configuration parameters and reply with and updated OAM
			Configuration TLV in the Resv message, reflecting the actually
			configured values. However, in order to avoid an extensive
			negotiation phase, in the case of adjusting already configured OAM
			functions, the receiving side SHOULD NOT update the parameters
			requested in the Path message to an extent that would provide lower
			performance than what has been configured previously.
			The initiator MUST only update its OAM sink and source functions
			after it received the Resv message. After this Path/Resv message
			exchange (in both unidirectional and bidirectional LSP cases) the OAM
			parameters are updated and OAM is running according the new parameter
			settings. However OAM alarms are still disabled. A subsequent Path/
			Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set
			is needed to enable OAM alarms again.
			3.3. Deleting OAM Entities
			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.
			To avoid any spurious alarm, first the LSP SHOULD be re-signaled with
			"OAM Alarms" ADMIN_STATUS flag cleared but unchanged OAM
			configuration. Subsequently, the LSP is re-signaled with "OAM MEP
			Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
			cleared, and without the OAM Configuration TLV, this MUST result in
			the deletion of all OAM entities associated with the LSP. All
			control and data plane resources in use by the OAM entities and
			functions SHOULD be freed up. Alternatively, if only some OAM
			functions need to be removed, the LSP is re-signalled with the
			updated OAM Configuration TLV. Changes between the contents of the
			previously signalled OAM Configuration TLV and the currently received
			TLV represent which functions SHOULD be removed/added.
			First, OAM source functions SHOULD be deleted and only after that
			SHOULD the associated OAM sink functions be removed, this will ensure
			that OAM messages do not leak outside the LSP. To this end the
			initiator, before sending the Path message, SHOULD remove the OAM
			source, hence terminating the OAM message flow associated to the
			downstream direction. In the case of a bidirectional connection, it
			SHOULD leave in place the OAM sink functions associated to the
			upstream direction. The remote end, after receiving the Path
			message, SHOULD remove all associated OAM entities and functions and
			reply with a Resv message without an OAM Configuration TLV. The
			initiator completely removes OAM entities and functions after the
			Resv message arrived.
			4. RSVP-TE Extensions
			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. [RFC4420]		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, [RFC4420] 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
	options and attributes may apply only to key LSRs on the path such as		options and attributes may apply only to key LSRs on the path such as
	the ingress LSR and egress LSR. Options and attributes can be		the ingress LSR and egress LSR. Options and attributes can be
	signaled transparently, and only examined at those points that need		signaled transparently, and only examined at those points that need
	to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES		to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES
	objects are defined in [RFC4420] to provide means to signal LSP		objects are defined in [RFC5420] to provide means to signal LSP
	attributes and options in the form of TLVs. Options and attributes		attributes and options in the form of TLVs. Options and attributes
	signaled in the LSP_ATTRIBUTES object can be passed transparently		signaled in the LSP_ATTRIBUTES object can be passed transparently
	through LSRs not supporting a particular option or attribute, while		through LSRs not supporting a particular option or attribute, while
	the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined		the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined
	and processed by each LSR. One TLV is defined in [RFC4420]: the		and processed by each LSR. One TLV is defined in [RFC5420]: the
	Attributes Flags TLV.		Attributes Flags TLV.
	One bit (10 IANA to assign): "OAM MEP entities desired" is allocated		One bit (10 IANA to assign): "OAM MEP entities desired" is allocated
	in the LSP Attributes Flags TLV. If the "OAM MEP entities desired"		in the LSP Attributes Flags TLV. If the "OAM MEP entities desired"
	bit is set it is indicating that the establishment of OAM MEP		bit is set it is indicating that the establishment of OAM MEP
	entities are required at the endpoints of the signaled LSP. If the		entities are required at the endpoints of the signaled LSP. If the
	establishment of MEPs is not supported an error must be generated:		establishment of MEPs is not supported an error must be generated:
	"OAM Problem/MEP establishment not supported".		"OAM Problem/MEP establishment not supported".
	If the "OAM MEP entities desired" bit is set and additional		If the "OAM MEP entities desired" bit is set and additional
	parameters are needed to configure the OAM entities an OAM		parameters are needed to be configured the OAM entities an OAM
	Configuration TLV may be included in the LSP_ATTRIBUTES object.		Configuration TLV may be included in the LSP_ATTRIBUTES object.
	One bit (11 IANA to assign): "OAM MIP entities desired" is allocated		One bit (11 IANA to assign): "OAM MIP entities desired" is allocated
	in the LSP Attributes Flags TLV. If the "OAM MIP entities desired"		in the LSP Attributes Flags TLV. This bit can only be set if the
	bit is set it is indicating that the establishment of OAM MIP		"OAM MEP entities desired" bit is set. If the "OAM MIP entities
	entities are required at the transit nodes of the signaled LSP. This		desired" bit is set in the LSP_ATTRIBUTES Flags TLV, it is indicating
	bit can only be set if the "OAM MEP entities desired" bit is set. If		that the establishment of OAM MIP entities is required at every
	the establishment of MIPs is not supported an error must be		transit node of the signalled LSP. If the establishment of a MIP is
	generated: "OAM Problem/MIP establishment not supported".		not supported an error must be generated: "OAM Problem/MIP
			establishment not supported".
	One bit (12 IANA to assign): "Alarm indication desired" is allocated
	in the LSP Attributes Flags TLV. If the "Alarm indication desired"
	bit is set it is indicating that the OAM entities of the signaled LSP
	should be notified of lower layer failures. In the case of
	hierarchical LSPs this will create an association between the
	underlying (server) LSP's OAM entities and the currently signaled
	(client) LSP's OAM entities.
	3.3. OAM Configuration TLV		4.2. OAM Configuration TLV
	This TLV specifies which OAM technology/method should be used for the		This TLV provides information about which OAM technology/method
	LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES		should be used and carries sub-TLVs for any additional OAM
	object in Path messages.		configuration information. The OAM Configuration TLV may be carried
			in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
			Resv messages.
	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 (2) (IANA) | Length |		| Type (2) (IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OAM Type | Reserved | OAM Function |		| OAM Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ sub-TLVs ~		~ sub-TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: indicates a new type: the OAM Configuration TLV (2) (IANA to		Type: indicates a new type: the OAM Configuration TLV (2) (IANA to
	assign).		assign).
	OAM Type: specifies the technology specific OAM method. If the		OAM Type: specifies the technology specific OAM method. If the
	requested OAM method is not supported an error must be generated:		requested OAM method is not supported an error must be generated:
	"OAM Problem/Unsupported OAM Type".		"OAM Problem/Unsupported OAM Type".
	This document defines no types. The receiving node based on the OAM
	Type will check if a corresponding technology specific OAM
	configuration sub-TLV is included. If different technology specific
	OAM configuration sub-TLV is included than what was specified in the
	OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch".
	OAM Type Description		OAM Type Description
	------------ --------------------		------------ --------------------
	0-255 Reserved		0-255 Reserved
	There is a hierarchy in between the OAM configuration elements.		This document defines no types. IANA is requests to maintain the
	First, the "OAM MEP (and MIP) entities desired" flag needs to be set,		values in a new "RSVP-TE OAM Configuration Registry".
	if it is set an "OAM Configuration TLV" may be included in the
	LSP_ATTRIBUTES object, if this TLV is present based on the OAM Type a
	technology specific OAM configuration sub-TLV may be present. If
	this hierarchy is broken (e.g., "OAM MEP entities desired" flag is
	not set but an OAM Configuration TLV is present an error must be
	generated: "OAM Problem/Configuration Error".
	OAM Function Flags: specifies pro-active OAM functions (e.g.,
	connectivity monitoring, loss and delay measurement) that should be
	established and configured. If the selected OAM Function(s) is(are)
	not supported an error must be generated: "OAM Problem/Unsupported
	OAM Function".
	This document defines the following flags.
	OAM Function Flag Description
	--------------------- ---------------------------
	0 Connectivity Monitoring
	1 Performance Monitoring/Loss
	2 Performance Monitoring/Delay
	3.4. TCME Configuration TLV
	Two TCME Configuration TLVs together specify a Tandem Connection
	Monitoring entity: they designate the TCM ingress and TCM egress
	MEPs, respectively. TCME Configuration TLVs are carried in
	HOP_ATTRIBUTES subobjects [HOP_ATTR] in the ERO, the corresponding
	node in the ERO identifies where TCME MEP is placed. Both TCME
	Configuration TLVs of the same TCME must specify the same OAM
	technology and method.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (2) (IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OAM Type |H|M| Level | OAM Functions |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SUB TLVs |
	~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: indicates a new type: the TCME Configuration TLV (2) (IANA to
	assign).
	OAM Type: specifies the technology specific OAM method. The OAM Type
	values defined for OAM Configuration TLV are applied here. If the
	requested OAM method is not supported an error must be generated:
	"OAM Problem/Unsupported OAM Type".
	One bit (Flag H) is allocated to indicate which endpoint of a TCME is
	encoded by the TCME Configuration TLV. Setting this flag indicates
	the ingress endpoints while clearing it indicates the egress one.
	One bit (Flag M) "TCME MIP entities desired" is allocated. This flag
	indicates if OAM MIP entities monitoring the TCME are required. If
	this function is not supported an error must be generated: "OAM
	Problem/TCME MIP establishment not supported".
	Level provides a key for the ingress node to determine the egress of
	the same TCME. Therefore, the same Level values must be set to the
	ingress and egress endpoints of the same TCME. Overlapping
	(including nesting) TCM entities must use different Level values, but
	two entries not having common segments may use the same Level value.
	Value 0 is reserved and must not be used to identify a TCM entity.
	Futher technology specific constraints of the Level value may be
	defined by accompying documents.
	OAM Function Flags: specifies pro-active OAM functions (e.g.,
	connectivity monitoring, loss and delay measurement) that should be
	established and configured. Same flags are applied as for OAM
	Configuration TLV.
	Both TLVs may contain technology sub-TLVs and the encoded sub-TLVs
	are relevant to the referred monitoring endpoint. The TCM ingress
	may update the OAM configuration of the egress point by changing
	already defined sub-TLVs or by adding new sub-TLVs.
	If the node, where TCME endpoint is to be configured, does not
	support that feature, must generate an error: "OAM Problem/TCM not
	supported".
	Since a TCME Configuration TLV pair encodes a TCME, the ingress node		The receiving node based on the OAM Type will check if a
	must check if a proper TCME Configuration TLV encoding the egress MEP		corresponding technology specific OAM configuration sub-TLV is
	is included in the ERO. If no such TLV (i.e., the same Level value		included. If the included technology specific OAM configuration sub-
	is set and flag H is cleared) is found an error must be generated:		TLV is different than what is specified in the OAM Type an error must
	"OAM Problem/TCM Egress is not properly configured".		be generated: "OAM Problem/OAM Type Mismatch".
	The above check ensures that a TCM egress will not be configured		Note that there is a hierarchical dependency in between the OAM
	without peering TCM ingress. Therefore, there is no need TCME		configuration elements. First, the "OAM MEP (and MIP) entities
	ingress checking procedure at the TCME egress.		desired" flag needs to be set. When it is set an "OAM Configuration
			TLV" may be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
			Object. When this TLV is present, based on the "OAM Type" field, it
			may carry a technology specific OAM configuration sub-TLV. If this
			hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set
			but an OAM Configuration TLV is present) an error must be generated:
			"OAM Problem/Configuration Error".
	3.5. NIME Configuration TLV		4.2.1. OAM Function Flags Sub-TLV
	Inserting a NIME Configuration TLV into a HOP_ATTRIBUTES object		As the first sub-TLV one "OAM Function Flags sub-TLV" MUST be always
	[HOP_ATTR] indicates that a non-intrusive monitoring element is to be		included in the "OAM Configuration TLV". "OAM Function Flags"
	configured. Futhermore, it encodes what OAM technology and method		specifies which pro-active OAM functions (e.g., connectivity
	should be used at that entity.		monitoring, loss and delay measurement) and which fault management
			signals MUST be established and configured. If the selected OAM
			Function(s) is(are) not supported, an error must be 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 (3) (IANA) | Length |		| Type (1) (IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OAM Type |D|U| Level | OAM Functions |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SUB TLVs |		| |
	~ ~		~ OAM Function Flags ~
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: indicates a new type: the NIM OAM Configuration TLV (3) (IANA
	to assign).
	OAM Type: specifies the technology specify OAM method. If the		This document defines the following flags.
	requested OAM method is not supported an error must be generated:
	"OAM Problem/Unsupported OAM Type". The same OAM type values to be
	used as for OAM Configuration TLV.
	Level value indicates which OAM flow of the connection is monitored:		OAM Function Flag Description
	the end-to-end OAM flow (Level = 0) or TCM entity associated to the		--------------------- ---------------------------
	connection (Level > 0).		0 Continuity Check (CC)
			1 Connectivity Verification (CV)
			2 Performance Monitoring/Loss (PM/Loss)
			3 Performance Monitoring/Delay (PM/Delay)
	Two bits (Flags D,U) indicates the direction of the monitored entity.		4.2.2. Technology Specific sub-TLVs
	The downstream traffic is monitored if flag D is set, while setting
	flag U means monitoring the upstream direction. Both directions are
	monitored if both flags are set. When both flags are cleared or the
	flag U is set but the LSP is not bidirectional an error must be
	generated: "OAM Problem/Invalid NIM direction defined".
	OAM Function Flags: specifies pro-active OAM functions (e.g.,		One technology specific sub-TLV SHOULD be defined for each "OAM
	connectivity monitoring, loss and delay measurement) that should be		Type". This sub-TLV MUST contain any further OAM configuration
	established and configured. Same procedures and flags applied as for		information for that specific "OAM Type". The technology specific
	OAM Configuration TLV.		sub-TLV may be carried within the OAM Configuration TLV.
	3.6. Monitoring Disabled - Admin_Status bit		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].
	One bit is allocated for the administrative control of OAM		Two bits are allocated for the administrative control of OAM
	monitoring. In addition to the Reflect (R) bit, 7 bits are currently		monitoring. In addition to the Reflect (R) bit, 7 bits are currently
	occupied (assigned by IANA or temporarily blocked by work in progress		occupied (assigned by IANA or temporarily blocked by work in progress
	Internet drafts). As the 24th bit (IANA to assign) this draft		Internet drafts). As the 24th and 25th bits (IANA to assign) this
	introduces the Monitoring Disabled (M) bit. When this bit is set the		draft introduces the "OAM Flows Enabled" (M) and "OAM Alarms Enabled"
	monitoring and OAM triggered alarms of the LSP are disabled (e.g., no		(O) bits. When the "OAM Flows Enabled" bit is set, OAM packets are
	continuity check messages are sent, no AIS is generated).		sent if it is cleared no OAM packets are emitted. When the "OAM
			Alarms Enabled" bit is set OAM triggered alarms are enabled and
			associated consequent actions are executed including the notification
			of the management system. When this bit is cleared, alarms are
			suppressed and no action is executed and the management system is not
			notified.
	3.7. 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 is defined.		Error Values is defined.
	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 (IANA to assign): "MEP		entities it must use the error value (IANA to assign): "MEP
	establishment not supported" or "MIP establishment not supported"		establishment not supported" or "MIP establishment not supported"
	respectively in the PathErr message.		respectively in the PathErr message.
	If a node does not support a specific OAM technology/solution it must		If a node does not support a specific OAM technology/solution it must
	use the error value (IANA to assign): "Unsupported OAM Type" in the		use the error value (IANA to assign): "Unsupported OAM Type" in the
	PathErr message.		PathErr message.
	If a different technology specific OAM configuration TLV is included		If a different technology specific OAM configuration TLV is included
	than what was specified in the OAM Type an error must be generated		than what was specified in the OAM Type an error must be generated
	with error value:"OAM Type Mismatch" in the PathErr message.		with error value: "OAM Type Mismatch" in the PathErr message.
	There is a hierarchy in between the OAM configuration elements. If		There is a hierarchy in between the OAM configuration elements. If
	this hierarchy is broken an the error value: "OAM Problem/		this hierarchy is broken the error value: "Configuration Error" must
	Configuration Error" must be used in the PathErr message.		be used in the PathErr message.
	If a node does not support a specific OAM Function it must use the		If a node does not support a specific OAM Function it must use the
	error value (IANA to assign): "Unsupported OAM Function" in the		error value: "Unsupported OAM Function" in the PathErr message.
	PathErr message.
	If an intermediate node is configured as a TCM ingress node, but no
	egress node for the same TCM entity is encoded in the ERO it must use
	"OAM Problem/TCM Egress is not properly configured" error value in
	the PathErr message
	If the node, where TCME endpoint is to be configured, does not
	support that feature, must generate an error: "OAM Problem/TCM not
	supported".
	If the technology does not support deploying MIPs monitoring a TCME
	an error must be generated by the TCME ingress: "OAM Problem/TCME MIP
	establishment not supported".
	If an intermediate node is configured as a non-intrusive monitoring
	node, but direction flags encode an invalid direction (both flags are
	set to 0 or flag "U" is set in the case of an unidirectional LSP) the
	node must issue a PathErr message with "OAM Problem/invalid NIM
	direction defined".
	4. IANA Considerations		5. IANA Considerations
	One bit (Monitoring Disabled (M)) needs to be allocated in the		Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs
	ADMIN_STATUS Object.		to be allocated in the ADMIN_STATUS Object.
	One bit ("OAM entities desired") needs to be allocated in the LSP		Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")
	Attributes Flag Registry.		needs to be allocated in the LSP Attributes Flags Registry.
	This document specifies one new TLVs to be carried in the		This document specifies one new TLV to be carried in the
	LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages:		LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv
	OAM Configuration TLV.		messages: OAM Configuration TLV.
	One new Error Code: "OAM Problem" and three new values: "MEP		One new Error Code: "OAM Problem" and a set of new values: "MEP
	establishment not supported", "MIP establishment not supported",		establishment not supported", "MIP establishment not supported",
	"Unsupported OAM Type" and "Unsupported OAM Function" needs to be		"Unsupported OAM Type", "Configuration Error" and "Unsupported OAM
	assigned.		Function" needs to be assigned.
	5. Security Considerations		The IANA is requested to open a new registry: "RSVP-TE OAM
			Configuration Registry" that maintains the "OAM Type" code points and
			the allocations of "OAM Function Flags" within the OAM Configuration
			TLV.
			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 introduces additional security		establishment of OAM entities introduces additional security
	considerations to those discussed in [RFC3473]. In particular, a		considerations to those discussed in [RFC3473]. In particular, a
	network element could be overloaded, if an attacker would request		network element could be overloaded, if an attacker would request
	liveliness monitoring, with frequent periodic messages, for a high		liveliness monitoring, with frequent periodic messages, for a high
	number of LSPs, targeting a single network element.		number of LSPs, targeting a single network element.
	Security aspects will be covered in more detailed in subsequent		Security aspects will be covered in more detailed in subsequent
	versions of this document.		versions of this document.
	6. 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.
	Appendix A. Discussion on alternatives		Appendix A. Discussion on Alternatives
	This appendix summarizes the discussions after IETF-71 about the way		This appendix summarizes the discussions after IETF-71 about the way
	OAM configuration information should be carried in RSVP-TE.		OAM configuration information should be carried in RSVP-TE.
	The first question is how the requirement for OAM establishment is		The first question is how the requirement for OAM establishment is
	signaled and how the operation of OAM is controlled. There is a		signaled and how the operation of OAM is controlled. There is a
	straightforward way to achieve these using existing objects and		straightforward way to achieve these using existing objects and
	fields:		fields:
	o Use one or more OAM flags in the LSP Attributes Flag TLV within		o Use one or more OAM flags in the LSP Attributes Flag TLV within
	skipping to change at page 22, line 5		skipping to change at page 21, line 5
	carry configuration information of data plane entities, thus a new		carry configuration information of data plane entities, thus a new
	object like an "OAM_SPEC" may be a better fit to existing protocol		object like an "OAM_SPEC" may be a better fit to existing protocol
	elements.		elements.
	The authors of this document favor the first alternative (adding new		The authors of this document favor the first alternative (adding new
	TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which		TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which
	alternative to select for standardization is up for the working group		alternative to select for standardization is up for the working group
	to decide. In any case, the information to be carried would be the		to decide. In any case, the information to be carried would be the
	same or very similar for both alternatives.		same or very similar for both alternatives.
	7. References		8. References
	[GELS-Framework]		[GELS-Framework]
	"GMPLS Ethernet Label Switching Architecture and		"GMPLS Ethernet Label Switching Architecture and
	Framework", Internet Draft, work in progress.		Framework", Internet Draft, work in progress.
	[GMPLS-OAM]		[GMPLS-OAM]
	"OAM Requirements for Generalized Multi-Protocol Label		"OAM Requirements for Generalized Multi-Protocol Label
	Switching (GMPLS) Networks", Internet Draft, work in		Switching (GMPLS) Networks", Internet Draft, work in
	progress.		progress.
	[HOP_ATTR]
	Kern, A. and A. Takacs, "Encoding of Attributes of LSP
	hops using RSVP-TE", Internet-draft Work in progress,
	October 2009.
	[IEEE-CFM]		[IEEE-CFM]
	"IEEE 802.1ag, Draft Standard for Connectivity Fault		"IEEE 802.1ag, Draft Standard for Connectivity Fault
	Management", work in progress.		Management", work in progress.
	[IEEE-PBBTE]		[IEEE-PBBTE]
	"IEEE 802.1Qay Draft Standard for Provider Backbone		"IEEE 802.1Qay Draft Standard for Provider Backbone
	Bridging Traffic Engineering", work in progress.		Bridging Traffic Engineering", work in progress.
	[MPLS-TP-FWK]		[MPLS-TP-FWK]
	"A Framework for MPLS in Transport Networks", Internet		"A Framework for MPLS in Transport Networks", Internet
	skipping to change at page 22, line 51		skipping to change at page 21, line 46
	Signaling Functional Description", RFC 3471, January 2003.		Signaling Functional Description", RFC 3471, January 2003.
	[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)		[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
	Signaling Resource ReserVation Protocol-Traffic		Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
	[RFC4377] "Operations and Management (OAM) Requirements for Multi-		[RFC4377] "Operations and Management (OAM) Requirements for Multi-
	Protocol Label Switched (MPLS) Networks", RFC 4377,		Protocol Label Switched (MPLS) Networks", RFC 4377,
	February 2006.		February 2006.
	[RFC4420] "Encoding of Attributes for Multiprotocol Label Switching		[RFC5420] "Encoding of Attributes for Multiprotocol Label Switching
	(MPLS) Label Switched Path (LSP) Establishment Using		(MPLS) Label Switched Path (LSP) Establishment Using
	Resource ReserVation Protocol-Traffic Engineering		Resource ReserVation Protocol-Traffic Engineering
	(RSVP-TE)", RFC 4420, February 2006.		(RSVP-TE)", RFC 5420, February 2009.
	Authors' Addresses		Authors' Addresses
	Attila Takacs		Attila Takacs
	Ericsson		Ericsson
	Laborc u. 1.		Laborc u. 1.
	Budapest, 1037		Budapest, 1037
	Hungary		Hungary
	Email: attila.takacs@ericsson.com		Email: attila.takacs@ericsson.com
End of changes. 67 change blocks.
	337 lines changed or deleted		318 lines changed or added
This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/