< draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10.txt		draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-11.txt >
	MPLS Working Group E. Bellagamba		MPLS Working Group E. Bellagamba
	Internet-Draft		Internet-Draft
	Intended status: Standards Track G. Mirsky		Intended status: Standards Track G. Mirsky
	Expires: February 1, 2016 Ericsson		Expires: February 22, 2016 Ericsson
	L. Andersson		L. Andersson
	Huawei Technologies		Huawei Technologies
	P. Skoldstrom		P. Skoldstrom
	Acreo AB		Acreo AB
	D. Ward		D. Ward
	Cisco		Cisco
	J. Drake		J. Drake
	Juniper		Juniper
	July 31, 2015		August 21, 2015
	Configuration of Proactive Operations, Administration, and Maintenance		Configuration of Proactive Operations, Administration, and Maintenance
	(OAM) Functions for MPLS-based Transport Networks using LSP Ping		(OAM) Functions for MPLS-based Transport Networks using LSP Ping
	draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10		draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-11
	Abstract		Abstract
	This specification describes the configuration of proactive MPLS-TP		This specification describes the configuration of proactive MPLS-TP
	Operations, Administration, and Maintenance (OAM) Functions for a		Operations, Administration, and Maintenance (OAM) Functions for a
	given LSP using a set of TLVs that are carried by the LSP-Ping		given Label Switched Path (LSP) using a set of TLVs that are carried
	protocol.		by the LSP-Ping protocol.
	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 February 1, 2016.		This Internet-Draft will expire on February 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions used in this document . . . . . . . . . . . . 4		1.1. Conventions used in this document . . . . . . . . . . . . 4
	1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4		1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 5
	2. Theory of Operations . . . . . . . . . . . . . . . . . . . . 4		2. Theory of Operations . . . . . . . . . . . . . . . . . . . . 5
	2.1. MPLS OAM Configuration Operation Overview . . . . . . . . 4		2.1. MPLS OAM Configuration Operation Overview . . . . . . . . 5
	2.1.1. Configuration of BFD Sessions . . . . . . . . . . . . 5		2.1.1. Configuration of BFD Sessions . . . . . . . . . . . . 5
	2.1.2. Configuration of Performance Monitoring . . . . . . . 6		2.1.2. Configuration of Performance Monitoring . . . . . . . 6
	2.1.3. Configuration of Fault Management Signals . . . . . . 6		2.1.3. Configuration of Fault Management Signals . . . . . . 6
	2.2. MPLS OAM Functions TLV . . . . . . . . . . . . . . . . . 6		2.2. MPLS OAM Functions TLV . . . . . . . . . . . . . . . . . 7
	2.2.1. BFD Configuration Sub-TLV . . . . . . . . . . . . . . 8		2.2.1. BFD Configuration Sub-TLV . . . . . . . . . . . . . . 9
	2.2.2. Local Discriminator Sub-TLV . . . . . . . . . . . . . 10		2.2.2. Local Discriminator Sub-TLV . . . . . . . . . . . . . 11
	2.2.3. Negotiation Timer Parameters Sub-TLV . . . . . . . . 10		2.2.3. Negotiation Timer Parameters Sub-TLV . . . . . . . . 11
	2.2.4. BFD Authentication Sub-TLV . . . . . . . . . . . . . 12		2.2.4. BFD Authentication Sub-TLV . . . . . . . . . . . . . 12
	2.2.5. Traffic Class Sub-TLV . . . . . . . . . . . . . . . . 13		2.2.5. Traffic Class Sub-TLV . . . . . . . . . . . . . . . . 13
	2.2.6. Performance Measurement Sub-TLV . . . . . . . . . . . 13		2.2.6. Performance Measurement Sub-TLV . . . . . . . . . . . 14
	2.2.7. PM Loss Measurement Sub-TLV . . . . . . . . . . . . . 15		2.2.7. PM Loss Measurement Sub-TLV . . . . . . . . . . . . . 16
	2.2.8. PM Delay Measurement Sub-TLV . . . . . . . . . . . . 16		2.2.8. PM Delay Measurement Sub-TLV . . . . . . . . . . . . 17
	2.2.9. Fault Management Signal Sub-TLV . . . . . . . . . . . 17		2.2.9. Fault Management Signal Sub-TLV . . . . . . . . . . . 18
	2.2.10. Source MEP-ID Sub-TLV . . . . . . . . . . . . . . . . 18		2.2.10. Source MEP-ID Sub-TLV . . . . . . . . . . . . . . . . 20
	3. Summary of MPLS OAM Configuration Errors . . . . . . . . . . 19		3. Summary of MPLS OAM Configuration Errors . . . . . . . . . . 20
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	4.1. TLV and Sub-TLV Allocation . . . . . . . . . . . . . . . 20		4.1. TLV and Sub-TLV Allocation . . . . . . . . . . . . . . . 22
	4.2. OAM Configuration Errors . . . . . . . . . . . . . . . . 21		4.2. MPLS OAM Function Flags Allocation . . . . . . . . . . . 22
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		4.3. OAM Configuration Errors . . . . . . . . . . . . . . . . 23
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 22		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	7.1. Normative References . . . . . . . . . . . . . . . . . . 23		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.2. Informative References . . . . . . . . . . . . . . . . . 24		7.1. Normative References . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		7.2. Informative References . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	This document describes the configuration of proactive MPLS-TP		MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
	Operations, Administration, and Maintenance (OAM) Functions for a		enables operational models typical in transport networks, while
	given LSP using TLVs carried in LSP-Ping [RFC4379]. In particular it		providing additional Operations, Administration, and Maintenance
	specifies the mechanisms necessary to establish MPLS-TP OAM entities		(OAM), survivability and other maintenance functions not currently
	at the maintenance points for monitoring and performing measurements		supported by MPLS. 860] defines the requirements for the OAM
	on an LSP, as well as defining information elements and procedures to		functionality of MPLS-TP.
	configure proactive MPLS-TP OAM functions running between LERs.
	Initialization and control of on-demand MPLS-TP OAM functions are		This document describes the configuration of proactive MPLS-TP OAM
	expected to be carried out by directly accessing network nodes via a		Functions for a given Label Switched Path (LSP) using TLVs carried in
	management interface; hence configuration and control of on-demand		LSP Ping [RFC4379]. In particular it specifies the mechanisms
	OAM functions are out-of-scope for this document.		necessary to establish MPLS-TP OAM entities at the maintenance points
			for monitoring and performing measurements on an LSP, as well as
			defining information elements and procedures to configure proactive
			MPLS-TP OAM functions running between LERs. Initialization and
			control of on-demand MPLS-TP OAM functions are expected to be carried
			out by directly accessing network nodes via a management interface;
			hence configuration and control of on-demand OAM functions are out-
			of-scope for this document.
	The Transport Profile of MPLS must, by definition [RFC5654], be		The Transport Profile of MPLS must, by definition [RFC5654], be
	capable of operating without a control plane. Therefore there are		capable of operating without a control plane. Therefore there are
	several options for configuring MPLS-TP OAM, without a control plane		several options for configuring MPLS-TP OAM, without a control plane
	by either using an NMS or LSP Ping, or with a control plane using		by either using an NMS or LSP Ping, or with a control plane using
	signaling protocols RSVP-TE [RFC3209] and/or T-LDP [RFC5036].		signaling protocols RSVP Traffic engineering (RSVP-TE) [RFC3209] and/
			or Targeted LDP [RFC5036].
	MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
	enables operational models typical in transport networks, while
	providing additional OAM, survivability and other maintenance
	functions not currently supported by MPLS. [RFC5860] defines the
	requirements for the OAM functionality of MPLS-TP.
	Proactive MPLS-TP OAM is performed by set of protocols, Bi-		Proactive MPLS-TP OAM is performed by set of protocols, Bi-
	directional Forwarding Detection (BFD) [RFC6428] for Continuity		directional Forwarding Detection (BFD) [RFC6428] for Continuity
	Check/Connectivity Verification, the delay measurement protocol (DM)		Check/Connectivity Verification, the delay measurement protocol (DM)
	[RFC6374], [RFC6375] for delay and delay variation (jitter)		[RFC6374], [RFC6375] for delay and delay variation (jitter)
	measurements, and the loss measurement (LM) protocol [RFC6374],		measurements, and the loss measurement (LM) protocol [RFC6374],
	[RFC6375] for packet loss and throughput measurements. Additionally,		[RFC6375] for packet loss and throughput measurements. Additionally,
	there is a number of Fault Management Signals that can be configured		there is a number of Fault Management Signals that can be configured
	[RFC6427].		[RFC6427].
	skipping to change at page 3, line 45		skipping to change at page 4, line 4
	failures in the path between two forwarding engines, including the		failures in the path between two forwarding engines, including the
	interfaces, data link(s), and, to the extent possible, the forwarding		interfaces, data link(s), and, to the extent possible, the forwarding
	engines themselves. BFD can be used to detect the continuity and		engines themselves. BFD can be used to detect the continuity and
	mis-connection defects of MPLS-TP point-to-point and might also be		mis-connection defects of MPLS-TP point-to-point and might also be
	extended to support point-to-multipoint label switched paths (LSPs).		extended to support point-to-multipoint label switched paths (LSPs).
	The delay and loss measurements protocols [RFC6374], [RFC6375] use a		The delay and loss measurements protocols [RFC6374], [RFC6375] use a
	simple query/response model for performing both uni- and bi-		simple query/response model for performing both uni- and bi-
	directional measurements that allow the originating node to measure		directional measurements that allow the originating node to measure
	packet loss and delay in forward or forward and reverse directions.		packet loss and delay in forward or forward and reverse directions.
	By timestamping and/or writing current packet counters to the		By timestamping and/or writing current packet counters to the
	measurement packets at four times (Tx and Rx in both directions)		measurement packets at four times (Transmit and Receive in both
	current delays and packet losses can be calculated. By performing		directions) current delays and packet losses can be calculated. By
	successive delay measurements the delay and/or inter-packet delay		performing successive delay measurements the delay and/or inter-
	variation (jitter) can be calculated. Current throughput can be		packet delay variation (jitter) can be calculated. Current
	calculated from the packet loss measurements by dividing the number		throughput can be calculated from the packet loss measurements by
	of packets sent/received with the time it took to perform the		dividing the number of packets sent/received with the time it took to
	measurement, given by the timestamp in LM header. Combined with a		perform the measurement, given by the timestamp in LM header.
	packet generator the throughput measurement can be used to measure		Combined with a packet generator the throughput measurement can be
	the maximum capacity of a particular LSP. It should be noted that		used to measure the maximum capacity of a particular LSP. It should
	here we are not configuring on-demand throughput estimates based on		be noted that here we are not configuring on-demand throughput
	saturating the connection as defined in [RFC6371]. Rather, we only		estimates based on saturating the connection as defined in [RFC6371].
	enable the estimation of the current throughput based on loss		Rather, we only enable the estimation of the current throughput based
	measurements.		on loss measurements.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	1.1.1. Terminology		1.1.1. Terminology
	BFD - Bidirectional Forwarding Detection		BFD - Bidirectional Forwarding Detection
	DM - Delay Measurement		DM - Delay Measurement
	FMS - Fault Management Signal		FMS - Fault Management Signal
	skipping to change at page 4, line 34		skipping to change at page 4, line 42
	LSP - Label Switched Path		LSP - Label Switched Path
	LM - Loss Measurement		LM - Loss Measurement
	MEP - Maintenance Entity Group End Point		MEP - Maintenance Entity Group End Point
	MPLS - Multi-Protocol Label Switching		MPLS - Multi-Protocol Label Switching
	MPLS-TP - MPLS Transport Profile		MPLS-TP - MPLS Transport Profile
			NMS - Network management System
	PM - Performance Measurement		PM - Performance Measurement
			RSVP-TE - RSVP Traffic Engineering
	TC - Traffic Class		TC - Traffic Class
	1.1.2. Requirements Language		1.1.2. 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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Theory of Operations		2. Theory of Operations
	2.1. MPLS OAM Configuration Operation Overview		2.1. MPLS OAM Configuration Operation Overview
	The MPLS-TP OAM tool set is described in the [RFC6669].		The MPLS-TP OAM tool set is described in the [RFC6669].
	LSP Ping, or alternatively RSVP-TE [RSVP-TE-CONF], can be used to		LSP Ping, or alternatively RSVP-TE [RFC7487], can be used to simply
	simply enable the different OAM functions, by setting the		enable the different OAM functions, by setting the corresponding
	corresponding flags in the MPLS OAM Functions TLV, Section 2.2. For		flags in the MPLS OAM Functions TLV, Section 2.2. For a more
	a more detailed configuration one may include sub-TLVs for the		detailed configuration one may include sub-TLVs for the different OAM
	different OAM functions in order to specify various parameters in		functions in order to specify various parameters in detail.
	detail.
	Typically intermediate nodes simply forward OAM configuration TLVs to		Typically intermediate nodes simply forward OAM configuration TLVs to
	the end-node without any processing or modification At least one		the end-node without any processing or modification At least one
	exception to this is if the FMS sub-TLV Section 2.2.9 is present.		exception to this is if the FMS sub-TLV Section 2.2.9 is present.
	This sub-TLV MUST be examined even by intermediate nodes that support		This sub-TLV MUST be examined even by intermediate nodes that support
	this extension. The sub-TLV MAY be present if a flag is set in the		this extension. The sub-TLV MAY be present if a flag is set in the
	MPLS OAM Functions TLV.		MPLS OAM Functions TLV.
	2.1.1. Configuration of BFD Sessions		2.1.1. Configuration of BFD Sessions
	For this specification, BFD MUST run in either one of the two modes:		For this specification, BFD MUST run in either one of the two modes:
	- Asynchronous mode, where both sides should be in active mode		- Asynchronous mode, where both sides should be in active mode
	- Unidirectional mode		- Unidirectional mode
	In the simplest scenario LSP Ping [RFC5884], or alternatively RSVP-TE		In the simplest scenario LSP Ping [RFC5884], or alternatively RSVP-TE
	[RSVP-TE-CONF], is used only to bootstrap a BFD session for an LSP,		[RFC7487], is used only to bootstrap a BFD session for an LSP,
	without any timer negotiation.		without any timer negotiation.
	Timer negotiation can be performed either in subsequent BFD control		Timer negotiation can be performed either in subsequent BFD control
	messages (in this case the operation is similar to LSP Ping based		messages (in this case the operation is similar to LSP Ping based
	bootstrapping described in [RFC5884]) or directly in the LSP-Ping		bootstrapping described in [RFC5884]) or directly in the LSP-Ping
	configuration messages.		configuration messages.
	When BFD Control packets are transported in the ACH encapsulation		When BFD Control packets are transported in the ACH encapsulation
	they are not protected by any end-to-end checksum, only lower-layers		they are not protected by any end-to-end checksum, only lower-layers
	are providing error detection/correction. A single bit error, e.g. a		are providing error detection/correction. A single bit error, e.g. a
	skipping to change at page 6, line 11		skipping to change at page 6, line 24
	pre-shared key/ password that should be used for this particular		pre-shared key/ password that should be used for this particular
	session. How the key exchange is performed is out of scope of this		session. How the key exchange is performed is out of scope of this
	document.		document.
	2.1.2. Configuration of Performance Monitoring		2.1.2. Configuration of Performance Monitoring
	It is possible to configure Performance Monitoring functionalities		It is possible to configure Performance Monitoring functionalities
	such as Loss, Delay, Delay/Interpacket Delay variation (jitter), and		such as Loss, Delay, Delay/Interpacket Delay variation (jitter), and
	Throughput as described in [RFC6374].		Throughput as described in [RFC6374].
	When configuring Performance monitoring functionalities it is		When configuring Performance Monitoring functionalities it is
	possible to choose either the default configuration, by only setting		possible to choose either the default configuration, by only setting
	the respective flags in the MPLS OAM functions TLV, or a customized		the respective flags in the MPLS OAM functions TLV, or a customized
	configuration. To customize the configuration one would set the		configuration. To customize the configuration one would set the
	respective flags in the including the respective Loss and/or Delay		respective flags in the MPLS OAM functions TLV and including the
	sub-TLVs).		respective Loss and/or Delay sub-TLVs.
	By setting the PM Loss flag in the MPLS OAM Functions TLV and		By setting the PM Loss flag in the MPLS OAM Functions TLV and
	including the PM Loss sub-TLV, Section 2.2.7, one can configure the		including the PM Loss sub-TLV, Section 2.2.7, one can configure the
	measurement interval and loss threshold values for triggering		measurement interval and loss threshold values for triggering
	protection.		protection.
	Delay measurements are configured by setting PM Delay flag in the		Delay measurements are configured by setting PM Delay flag in the
	MPLS OAM Functions TLV and including the PM Delay sub-TLV,		MPLS OAM Functions TLV and including the PM Delay sub-TLV,
	Section 2.2.8, one can configure the measurement interval and the		Section 2.2.8, one can configure the measurement interval and the
	delay threshold values for triggering protection.		delay threshold values for triggering protection.
	skipping to change at page 6, line 43		skipping to change at page 7, line 8
	can enable the default configuration by setting the FMS flag in the		can enable the default configuration by setting the FMS flag in the
	OAM Function Flags sub-TLV. In order to modify the default		OAM Function Flags sub-TLV. In order to modify the default
	configuration the MPLS OAM FMS sub-TLV MUST be included.		configuration the MPLS OAM FMS sub-TLV MUST be included.
	If an intermediate point is meant to originate fault management		If an intermediate point is meant to originate fault management
	signal messages this means that such an intermediate point is		signal messages this means that such an intermediate point is
	associated with a Server MEP through a co-located MPLS-TP client/		associated with a Server MEP through a co-located MPLS-TP client/
	server adaptation function and the Fault Management subscription flag		server adaptation function and the Fault Management subscription flag
	in the MPLS OAM FMS sub-TLV been set as indication of the request to		in the MPLS OAM FMS sub-TLV been set as indication of the request to
	create the association at each intermediate node of the client LSP.		create the association at each intermediate node of the client LSP.
	Corresponding Server MEP needs to be configured by its own LSP-ping		The corresponding Server MEP needs to be configured by its own LSP-
	session or, alternatively, via an NMS or RSVP-TE.		ping session or, alternatively, via a Network Management system (NMS)
			or RSVP-TE.
	2.2. MPLS OAM Functions TLV		2.2. MPLS OAM Functions TLV
	The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV		The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV
	of the MPLS Echo Request/Reply messages [RFC4379].		of the MPLS Echo Request/Reply messages [RFC4379].
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS OAM Func. Type (TBA1) | Length |		| MPLS OAM Func. Type (TBA1) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|C|V|F|L|D|T| Reserved (MBZ) |		| MPLS OAM Function Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ sub-TLVs ~		~ sub-TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: MPLS OAM Functions TLV format		Figure 1: MPLS OAM Functions TLV format
	The MPLS OAM Functions TLV contains a number of flags indicating		The MPLS OAM Functions TLV contains MPLS OAM Function Flags field.
	which OAM functions should be activated as well as OAM function		The MPLS OAM Function Flags indicates which OAM functions should be
	specific sub-TLVs with configuration parameters for the particular		activated as well as OAM function specific sub-TLVs with
	function.		configuration parameters for the particular function.
	Type: indicates the MPLS OAM Functions TLV Section 4.		Type: indicates the MPLS OAM Functions TLV Section 4.
	Length: the length of the MPLS OAM Function Flags field including the		Length: the length of the MPLS OAM Function Flags field including the
	total length of the sub-TLVs in octets.		total length of the sub-TLVs in octets.
	MPLS OAM Function Flags: a bitmap numbered from left to right as		MPLS OAM Function Flags: a bitmap numbered from left to right as
	shown in the figure.		shown in the Figure 2.These flags are managed by IANA Section 4.2.
			Flags defined in this document are presented in Table 2. Undefined
	These flags are defined in this document as presented in Table 1:		flags MUST be set to zero and unknown flags MUST be ignored. The
			flags indicate what OAM is being configured and direct the presence
			of optional sub-TLVs as set out below.
	+------------+--------------------+---------------------------------+		0 1 2 3
	| Bit | MPLS OAM Function | Description |		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
	| Position | Flag | |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+------------+--------------------+---------------------------------+		|C|V|F|L|D|T| Reserved (MBZ) |
	| 0 | C | Continuity Check (CC) |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | V | Connectivity Verification (CV) |
	| 2 | F | Fault Management Signal (FMS) |
	| 3 | L | Performance Measurement/Loss |
	| | | (PM/Loss) |
	| 4 | D | Performance Measurement/Delay |
	| | | (PM/Delay) |
	| 5 | T | Throughput Measurement) |
	| 6-31 | | Reserved |
	+------------+--------------------+---------------------------------+
	Table 1: MPLS OAM Functions Flags		Figure 2: MPLS OAM Function Flags format
	Sub-TLVs corresponding to the different flags are as follows:		Sub-TLVs corresponding to the different flags are as follows:
			- If a flag in the MPLS OAM Function Flags is set and the
			corresponding sub-TLVs listed below is absent, then this MPLS OAM
			function MUST be initialized according to its default settings.
			Default settings of MPLS OAM functions are outside the scope of
			this document.
			- If any sub-TLV is present without the corresponding flag being
			set, the sub-TLV SHOULD be ignored.
	- BFD Configuration sub-TLV, which MUST be included if either the		- BFD Configuration sub-TLV, which MUST be included if either the
	CC, the CV or both MPLS OAM Function flags being set in the MPLS		CC, the CV or both MPLS OAM Function flags being set in the MPLS
	OAM Functions TLV .		OAM Functions TLV .
	- PM Loss sub-TLV within the "Performance Monitoring sub-TLV",		- Performance Monitoring sub-TLV MUST be used to carry PM Loss
	which MAY be included if the PM/Loss OAM Function flag is set. If		sub-TLV and/or PM Delay sub-TLV. If neither one of these sub-TLVs
	the "PM Loss sub-TLV" is not included, default configuration		is present then Performance Monitoring sub-TLV SHOULD NOT be
	values are used. Such sub-TLV MAY also be included in case the		included. Empty, i.e. no enclosed sub-TLVs, Performance
	Throughput function flag is set and there is the need to specify		Monitoring sub-TLV SHOULD be ignored.
	measurement interval different from the default ones. In fact the
	throughput measurement make use of the same tool as the loss
	measurement, hence the same TLV is used.
	- PM Delay sub-TLV within the "Performance Monitoring sub-TLV",		- PM Loss sub-TLV MAY be included if the PM/Loss OAM Function flag
	which MAY be included if the PM/Delay OAM Function flag is set.		is set. If the "PM Loss sub-TLV" is not included, default
	If the "PM Delay sub-TLV" is not included, default configuration		configuration values are used. Such sub-TLV MAY also be included
	values are used.		in case the Throughput function flag is set and there is the need
			to specify measurement interval different from the default ones.
			In fact the throughput measurement make use of the same tool as
			the loss measurement, hence the same TLV is used.
			- PM Delay sub-TLV MAY be included if the PM/Delay OAM Function
			flag is set. If the "PM Delay sub-TLV" is not included, default
			configuration values are used.
	- FMS sub-TLV, which MAY be included if the FMS OAM Function flag		- FMS sub-TLV, which MAY be included if the FMS OAM Function flag
	is set. If the "FMS sub-TLV" is not included, default		is set. If the "FMS sub-TLV" is not included, default
	configuration values are used.		configuration values are used.
			If all flags in the MPLS OAM Function Flags filed have the same value
			of zero, that MUST be interpreted as the MPLS OAM Functions TLV not
			present in the MPLS Echo Request. If more than one MPLS OAM
			Functions TLV is present in the MPLS Echo request packet, then the
			first TLV SHOULD be processed and the rest be ignored. Any parsing
			error within nested sub-TLVs that is not specified in Section 3
			SHOULD be treated as described in [RFC4379].
	2.2.1. BFD Configuration Sub-TLV		2.2.1. BFD Configuration Sub-TLV
	The BFD Configuration sub-TLV, depicted Figure 2, is defined for BFD		The BFD Configuration sub-TLV, depicted Figure 3, is defined for BFD
	OAM specific configuration parameters. The "BFD Configuration sub-		OAM specific configuration parameters. The "BFD Configuration sub-
	TLV" is carried as a sub-TLV of the "OAM Functions TLV".		TLV" is carried as a sub-TLV of the "OAM Functions TLV".
	This TLV accommodates generic BFD OAM information and carries sub-		This TLV accommodates generic BFD OAM information and carries sub-
	TLVs.		TLVs.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BFD Conf. sub-Type (100) | Length |		| BFD Conf. sub-Type (100) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Vers.|N|S|I|G|U|B| Reserved (set to all 0s) |		|Vers.|N|S|I|G|U|B| Reserved (set to all 0s) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ sub-TLVs ~		~ sub-TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: BFD Configuration sub-TLV format		Figure 3: BFD Configuration sub-TLV format
	Sub-type: indicates a new sub-type, the BFD Configuration sub-TLV		Sub-type: indicates a new sub-type, the BFD Configuration sub-TLV
	(value 100).		(value 100).
	Length: indicates the length of the Value field in octets (4).		Length: indicates the length of the Value field in octets.
	Version: identifies the BFD protocol version. If a node does not		Version: identifies the BFD protocol version. If a node does not
	support a specific BFD version an error must be generated: "OAM		support a specific BFD version an error must be generated: "OAM
	Problem/Unsupported OAM Version".		Problem/Unsupported OAM Version".
	BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD		BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD
	Control Messages is enabled, when cleared it is disabled.		Control Messages is enabled, when cleared it is disabled and timer
			configuration is achieved using Negotiation Timer Parameters sub-TLV
			as described in Section 2.2.3.
	Symmetric session (S): If set the BFD session MUST use symmetric		Symmetric session (S): If set the BFD session MUST use symmetric
	timing values.		timing values. If cleared the BFD session MAY use any timing values
			either negotiated or explicitly configured.
	Integrity (I): If set BFD Authentication MUST be enabled. If the BFD		Integrity (I): If set BFD Authentication MUST be enabled. If the BFD
	Configuration sub-TLV does not include a BFD Authentication sub-TLV		Configuration sub-TLV does not include a BFD Authentication sub-TLV
	the authentication MUST use Keyed SHA1 with an empty pre-shared key		the authentication MUST use Keyed SHA1 with an empty pre-shared key
	(all 0s). If the egress LSR does not support BFD Authentication an		(all 0s). If the egress LSR does not support BFD Authentication an
	error MUST be generated: "OAM Problem/BFD Authentication		error MUST be generated: "OAM Problem/BFD Authentication
	unsupported".		unsupported". If the Integrity flag is clear, then Authentication
			MUST NOT be used.
	Encapsulation Capability (G): if set, it shows the capability of		Encapsulation Capability (G): if set, it shows the capability of
	encapsulating BFD messages into G-ACh channel. If both the G bit and		encapsulating BFD messages into G-ACh channel. If both the G bit and
	U bit are set, configuration gives precedence to the G bit.		U bit are set, configuration gives precedence to the G bit.
	Encapsulation Capability (U): if set, it shows the capability of		Encapsulation Capability (U): if set, it shows the capability of
	encapsulating BFD messages into IP/UDP packets. If both the G bit		encapsulating BFD messages into IP/UDP packets. If both the G bit
	and U bit are set, configuration gives precedence to the G bit.		and U bit are set, configuration gives precedence to the G bit.
	If the egress LSR does not support any of the ingress LSR		If the egress LSR does not support any of the ingress LSR
	skipping to change at page 10, line 24		skipping to change at page 11, line 10
	- the N flag is cleared and the S flag is set, and the		- the N flag is cleared and the S flag is set, and the
	Negotiation Timer Parameters sub-TLV received by the egress		Negotiation Timer Parameters sub-TLV received by the egress
	contains unsupported values. In this case an updated		contains unsupported values. In this case an updated
	Negotiation Timer Parameters sub-TLV, containing values		Negotiation Timer Parameters sub-TLV, containing values
	supported by the egress node [RFC7419], is returned to the		supported by the egress node [RFC7419], is returned to the
	ingress.		ingress.
	2.2.2. Local Discriminator Sub-TLV		2.2.2. Local Discriminator Sub-TLV
	The Local Discriminator sub-TLV is carried as a sub-TLV of the "BFD		The Local Discriminator sub-TLV is carried as a sub-TLV of the "BFD
	Configuration sub-TLV" and is depicted in Figure 3.		Configuration sub-TLV" and is depicted in Figure 4.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Lcl. Discr. sub-Type (101) | Length |		| Locl. Discr. sub-Type (101) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Discriminator |		| Local Discriminator |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Local Discriminator sub-TLV format		Figure 4: Local Discriminator sub-TLV format
	Type: indicates a new type, the "Local Discriminator sub-TLV" (value		Type: indicates a new type, the "Local Discriminator sub-TLV" (value
	101).		101).
	Length: indicates the length of the Value field in octets . (4)		Length: indicates the length of the Value field in octets . (4)
	Local Discriminator: A unique, nonzero discriminator value generated		Local Discriminator: A nonzero discriminator value that is unique in
	by the transmitting system and referring to itself, used to		the context of the transmitting system that generates it. It is used
	demultiplex multiple BFD sessions between the same pair of systems.		to demultiplex multiple BFD sessions between the same pair of
			systems.
	2.2.3. Negotiation Timer Parameters Sub-TLV		2.2.3. Negotiation Timer Parameters Sub-TLV
	The Negotiation Timer Parameters sub-TLV is carried as a sub-TLV of		The Negotiation Timer Parameters sub-TLV is carried as a sub-TLV of
	the BFD Configuration sub-TLV and is depicted in Figure 4.		the BFD Configuration sub-TLV and is depicted in Figure 5.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nego. Timer sub-type (102) | Length |		| Nego. Timer sub-type (102) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acceptable Min. Asynchronous TX interval |		| Acceptable Min. Asynchronous TX interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acceptable Min. Asynchronous RX interval |		| Acceptable Min. Asynchronous RX interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Required Echo TX Interval |		| Required Echo TX Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Negotiation Timer Parameters sub-TLV format		Figure 5: Negotiation Timer Parameters sub-TLV format
	Sub-type: indicates a new sub-type, the Negotiation Timer Parameters		Sub-type: indicates a new sub-type, the Negotiation Timer Parameters
	sub-TLV (value 102).		sub-TLV (value 102).
	Length: indicates the length of the Value field in octets (12).		Length: indicates the length of the Value field in octets (12).
	Acceptable Min. Asynchronous TX interval: in case of S (symmetric)		Acceptable Min. Asynchronous TX interval: in case of S (symmetric)
	flag set in the BFD Configuration sub-TLV, defined in Section 2.2.1,		flag set in the BFD Configuration sub-TLV, defined in Section 2.2.1,
	it expresses the desired time interval (in microseconds) at which the		it expresses the desired time interval (in microseconds) at which the
	ingress LER intends to both transmit and receive BFD periodic control		ingress LER intends to both transmit and receive BFD periodic control
	packets. If the receiving edge LSR cannot support such value, it		packets. If the receiving edge LSR cannot support such value, it
	SHOULD reply with an interval greater than the one proposed.		SHOULD reply with an interval greater than the one proposed.
	In case of S (symmetric) flag cleared in the BFD Configuration sub-		In case of S (symmetric) flag cleared in the BFD Configuration sub-
	TLV, this field expresses the desired time interval (in microseconds)		TLV, this field expresses the desired time interval (in microseconds)
	at which a edge LSR intends to transmit BFD periodic control packets		at which a edge LSR intends to transmit BFD periodic control packets
	in its transmitting direction.		in its transmitting direction.
	Acceptable Min. Asynchronous RX interval: in case of S (symmetric)		Acceptable Min. Asynchronous RX interval: in case of S (symmetric)
	flag set in the BFD Configuration sub-TLV, Figure 2, this field MUST		flag set in the BFD Configuration sub-TLV, Figure 3, this field MUST
	be equal to Acceptable Min. Asynchronous TX interval and has no		be equal to Acceptable Min. Asynchronous TX interval and has no
	additional meaning respect to the one described for "Acceptable Min.		additional meaning respect to the one described for "Acceptable Min.
	Asynchronous TX interval".		Asynchronous TX interval".
	In case of S (symmetric) flag cleared in the BFD Configuration sub-		In case of S (symmetric) flag cleared in the BFD Configuration sub-
	TLV, it expresses the minimum time interval (in microseconds) at		TLV, it expresses the minimum time interval (in microseconds) at
	which edge LSRs can receive BFD periodic control packets. In case		which edge LSRs can receive BFD periodic control packets. In case
	this value is greater than the value of Acceptable Min. Asynchronous		this value is greater than the value of Acceptable Min. Asynchronous
	TX interval received from the other edge LSR, such edge LSR MUST		TX interval received from the other edge LSR, such edge LSR MUST
	adopt the interval expressed in this Acceptable Min. Asynchronous RX		adopt the interval expressed in this Acceptable Min. Asynchronous RX
	skipping to change at page 12, line 15		skipping to change at page 12, line 49
	[RFC5880] sect. 6.8.9. This value is also an indication for the		[RFC5880] sect. 6.8.9. This value is also an indication for the
	receiving system of the minimum interval between transmitted BFD Echo		receiving system of the minimum interval between transmitted BFD Echo
	packets. If this value is zero, the transmitting system does not		packets. If this value is zero, the transmitting system does not
	support the receipt of BFD Echo packets. If the receiving system		support the receipt of BFD Echo packets. If the receiving system
	cannot support this value the "Unsupported BFD TX Echo rate interval"		cannot support this value the "Unsupported BFD TX Echo rate interval"
	error MUST be generated. By default the value is set to 0.		error MUST be generated. By default the value is set to 0.
	2.2.4. BFD Authentication Sub-TLV		2.2.4. BFD Authentication Sub-TLV
	The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD		The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD
	Configuration sub-TLV" and is depicted in Figure 5.		Configuration sub-TLV" and is depicted in Figure 6.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BFD Auth. sub-type (103) | Length |		| BFD Auth. sub-type (103) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Auth Type | Auth Key ID | Reserved (0s) |		| Auth Type | Auth Key ID | Reserved (0s) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: BFD Authentication sub-TLV format		Figure 6: BFD Authentication sub-TLV format
	Sub-type: indicates a new type, the BFD Authentication sub-TLV (value		Sub-type: indicates a new type, the BFD Authentication sub-TLV (value
	103).		103).
	Length: indicates the length of the Value field in octets (4).		Length: indicates the length of the Value field in octets (4).
	Auth Type: indicates which type of authentication to use. The same		Auth Type: indicates which type of authentication to use. The same
	values as are defined in section 4.1 of [RFC5880] are used.		values as are defined in section 4.1 of [RFC5880] are used.
	Auth Key ID: indicates which authentication key or password		Auth Key ID: indicates which authentication key or password
	skipping to change at page 13, line 8		skipping to change at page 13, line 41
	If BFD Authentication sub-TLV used for a BFD session in Up state then		If BFD Authentication sub-TLV used for a BFD session in Up state then
	the Sender of the MPLS LSP Echo Request SHOULD ensure that old and		the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
	new modes of authentication, i.e. combination of Auth.Type and Auth.		new modes of authentication, i.e. combination of Auth.Type and Auth.
	Key ID, used to send and receive BFD control packets until the Sender		Key ID, used to send and receive BFD control packets until the Sender
	can confirm that its peer had switched to the new authentication.		can confirm that its peer had switched to the new authentication.
	2.2.5. Traffic Class Sub-TLV		2.2.5. Traffic Class Sub-TLV
	The Traffic Class sub-TLV is carried as a sub-TLV of the "BFD		The Traffic Class sub-TLV is carried as a sub-TLV of the "BFD
	Configuration sub-TLV" or "Fault Management Signal sub-TLV"		Configuration sub-TLV" and "Fault Management Signal sub-TLV"
	Section 2.2.9 and is depicted in Figure 6.		Section 2.2.9 and is depicted in Figure 7.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Traffic Class sub-Type (104) | Length |		| Traffic Class sub-Type (104) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TC | Reserved (set to all 0s) |		| TC | Reserved (set to all 0s) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: Traffic Class sub-TLV format		Figure 7: Traffic Class sub-TLV format
	Type: indicates a new type, the "Traffic Class sub-TLV" (value 104).		Type: indicates a new type, the "Traffic Class sub-TLV" (value 104).
	Length: indicates the length of the Value field in octets . (4)		Length: indicates the length of the Value field in octets . (4)
	TC: Identifies the Traffic Class (TC) [RFC5462] for periodic		TC: Identifies the Traffic Class (TC) [RFC5462] for periodic
	continuity monitoring messages or packets with fault management		continuity monitoring messages or packets with fault management
	information.		information.
	If TC sub-TLV is present, then the value of the TC field MUST be used		If TC sub-TLV is present, then the value of the TC field MUST be used
	as the value of the TC field of an MPLS label stack entry. If the TC		as the value of the TC field of the MPLS label stack that corresponds
	sub-TLV is absent from "BFD Configuration sub-TLV" or "Fault		to the FEC for which fault detection is being performed. If the TC
			sub-TLV is absent from either "BFD Configuration sub-TLV" or "Fault
	Management Signal sub-TLV", then selection of the TC value is local		Management Signal sub-TLV", then selection of the TC value is local
	decision.		decision.
	2.2.6. Performance Measurement Sub-TLV		2.2.6. Performance Measurement Sub-TLV
	If the MPLS OAM Functions TLV has either the L (Loss), D (Delay) or T		If the MPLS OAM Functions TLV has any of the L (Loss), D (Delay) and
	(Throughput) flag set, the Performance Measurement sub-TLV MUST be		T (Throughput) flag set, the Performance Measurement sub-TLV MUST be
	present. Failure to include the correct sub-TLVs MUST result in an		present. Failure to include the correct sub-TLVs MUST result in an
	"OAM Problem/ Configuration Error" error being generated.		"OAM Problem/ Configuration Error" error being generated.
	The Performance Measurement sub-TLV provides the configuration		The Performance Measurement sub-TLV provides the configuration
	information mentioned in Section 7 of [RFC6374]. It includes support		information mentioned in Section 7 of [RFC6374]. It includes support
	for the configuration of quality thresholds and, as described in		for the configuration of quality thresholds and, as described in
	[RFC6374], "the crossing of which will trigger warnings or alarms,		[RFC6374], "the crossing of which will trigger warnings or alarms,
	and result reporting and exception notification will be integrated		and result reporting and exception notification will be integrated
	into the system-wide network management and reporting framework."		into the system-wide network management and reporting framework."
	In case the values need to be different than the default ones the		In case the values need to be different than the default ones the
	Performance Measurement sub-TLV MAY include the following sub-TLVs:		Performance Measurement sub-TLV MAY include the following sub-TLVs:
	- PM Loss sub-TLV if the L flag is set in the MPLS OAM Functions		- PM Loss sub-TLV if the L flag is set in the MPLS OAM Functions
	TLV;		TLV;
	- PM Delay sub-TLV if the D flag is set in the MPLS OAM Functions		- PM Delay sub-TLV if the D flag is set in the MPLS OAM Functions
	TLV.		TLV.
	The Performance Measurement sub-TLV depicted in Figure 7 is carried		The Performance Measurement sub-TLV depicted in Figure 8 is carried
	as a sub-TLV of the MPLS OAM Functions TLV.		as a sub-TLV of the MPLS OAM Functions TLV.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Perf Monitoring Type (200) | Length |		| Perf Monitoring Type (200) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|L|J|Y|K|C| Reserved (set to all 0s) |		| PM Configuration Flags |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ sub-TLVs ~
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: Performance Measurement sub-TLV format		Figure 8: Performance Measurement sub-TLV format
	Sub-type: indicates a new sub-type, the Performance Management sub-		Sub-type: indicates a new sub-type, the Performance Management sub-
	TLV" (value 200).		TLV" (value 200).
	Length: indicates the length of the Value field in octets (4).		Length: indicates the length of the Value field in octets, including
			PM Configuration Flags and optional sub-TLVs.
	Configuration Flags, for the specific function description please		0 1 2 3
	refer to [RFC6374]:		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|D|L|J|Y|K|C| Reserved (set to all 0s) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 9: Performance Measurement sub-TLV format
			PM Configuration Flags, format is presented in Figure 9, for the
			specific function description please refer to [RFC6374]:
	- D: Delay inferred/direct (0=INFERRED, 1=DIRECT). If the egress		- D: Delay inferred/direct (0=INFERRED, 1=DIRECT). If the egress
	LSR does not support specified mode an "OAM Problem/Unsupported		LSR does not support specified mode an "OAM Problem/Unsupported
	Delay Mode" error MUST be generated.		Delay Mode" error MUST be generated.
	- L: Loss inferred/direct (0=INFERRED, 1=DIRECT). If the egress		- L: Loss inferred/direct (0=INFERRED, 1=DIRECT). If the egress
	LSR does not support specified mode an "OAM Problem/Unsupported		LSR does not support specified mode an "OAM Problem/Unsupported
	Loss Mode" error MUST be generated.		Loss Mode" error MUST be generated.
	- J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). If the		- J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). If the
	skipping to change at page 15, line 14		skipping to change at page 16, line 18
	- C: Combined (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does		- C: Combined (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does
	not support Combined mode and the C flag is set, an "OAM Problem/		not support Combined mode and the C flag is set, an "OAM Problem/
	Combined mode unsupported" error MUST be generated.		Combined mode unsupported" error MUST be generated.
	Reserved: Reserved for future specification and set to 0 on		Reserved: Reserved for future specification and set to 0 on
	transmission and ignored when received.		transmission and ignored when received.
	2.2.7. PM Loss Measurement Sub-TLV		2.2.7. PM Loss Measurement Sub-TLV
	The PM Loss Measurement sub-TLV depicted in Figure 8 is carried as a		The PM Loss Measurement sub-TLV depicted in Figure 10 is carried as a
	sub-TLV of the Performance Measurement sub-TLV.		sub-TLV of the Performance Measurement sub-TLV.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PM Loss sub-type (201) | Length |		| PM Loss sub-type (201) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OTF |T|B| Reserved (set to all 0s) |		| OTF |T|B| Reserved (set to all 0s) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Measurement Interval |		| Measurement Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Test Interval |		| Test Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Loss Threshold |		| Loss Threshold |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: PM Loss Measurement sub-TLV format		Figure 10: PM Loss Measurement sub-TLV format
	Sub-type: indicates a new sub-type, the PM Loss Measurement sub-TLV		Sub-type: indicates a new sub-type, the PM Loss Measurement sub-TLV
	(value 201).		(value 201).
	Length: indicates the length of the Value field in octets (16).		Length: indicates the length of the Value field in octets (16).
	OTF: Origin Timestamp Format of the Origin Timestamp field described		OTF: Origin Timestamp Format of the Origin Timestamp field described
	in [RFC6374]. By default it is set to IEEE 1588 version 1. If the		in [RFC6374]. By default it is set to IEEE 1588 version 1. If the
	egress LSR cannot support this value an "OAM Problem/Unsupported		egress LSR cannot support this value an "OAM Problem/Unsupported
	Timestamp Format" error MUST be generated.		Timestamp Format" error MUST be generated.
	skipping to change at page 16, line 24		skipping to change at page 17, line 29
	as per [RFC6375].		as per [RFC6375].
	Test Interval: test messages interval in milliseconds as described in		Test Interval: test messages interval in milliseconds as described in
	[RFC6374]. By default it is set to (10) as per [RFC6375].		[RFC6374]. By default it is set to (10) as per [RFC6375].
	Loss Threshold: the threshold value of measured lost packets per		Loss Threshold: the threshold value of measured lost packets per
	measurement over which action(s) SHOULD be triggered.		measurement over which action(s) SHOULD be triggered.
	2.2.8. PM Delay Measurement Sub-TLV		2.2.8. PM Delay Measurement Sub-TLV
	The PM Delay Measurement sub-TLV" depicted in Figure 9 is carried as		The PM Delay Measurement sub-TLV" depicted in Figure 11 is carried as
	a sub-TLV of the Performance Monitoring sub-TLV.		a sub-TLV of the Performance Monitoring sub-TLV.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PM Delay Type (202) | Length |		| PM Delay Type (202) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OTF |T|B| Reserved (set to all 0s) |		| OTF |T|B| Reserved (set to all 0s) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Measurement Interval |		| Measurement Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Test Interval |		| Test Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Delay Threshold |		| Delay Threshold |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 9: PM Delay Measurement sub-TLV format		Figure 11: PM Delay Measurement sub-TLV format
	Sub-type: indicates a new sub-type, the PM Delay Measurement sub-TLV"		Sub-type: indicates a new sub-type, the PM Delay Measurement sub-TLV"
	(value 202).		(value 202).
	Length: indicates the length of the Value field in octets (16).		Length: indicates the length of the Value field in octets (16).
	OTF: Origin Timestamp Format of the Origin Timestamp field described		OTF: Origin Timestamp Format of the Origin Timestamp field described
	in [RFC6374]. By default it is set to IEEE 1588 version 1. If the		in [RFC6374]. By default it is set to IEEE 1588 version 1. If the
	egress LSR cannot support this value an "OAM Problem/Unsupported		egress LSR cannot support this value an "OAM Problem/Unsupported
	Timestamp Format" error MUST be generated.		Timestamp Format" error MUST be generated.
	skipping to change at page 17, line 35		skipping to change at page 18, line 40
	per [RFC6375].		per [RFC6375].
	Test Interval: test messages interval (in milliseconds) as described		Test Interval: test messages interval (in milliseconds) as described
	in [RFC6374]. By default it is set to (10) as per [RFC6375].		in [RFC6374]. By default it is set to (10) as per [RFC6375].
	Delay Threshold: the threshold value of measured two-way delay (in		Delay Threshold: the threshold value of measured two-way delay (in
	milliseconds) over which action(s) SHOULD be triggered.		milliseconds) over which action(s) SHOULD be triggered.
	2.2.9. Fault Management Signal Sub-TLV		2.2.9. Fault Management Signal Sub-TLV
	The FMS sub-TLV depicted in Figure 10 is carried as a sub-TLV of the		The FMS sub-TLV depicted in Figure 12 is carried as a sub-TLV of the
	MPLS OAM Configuration sub-TLV. When both working and protection		MPLS OAM Configuration sub-TLV. When both working and protection
	paths are configured, both LSPs SHOULD be configured with identical		paths are configured, both LSPs SHOULD be configured with identical
	settings of the E flag, T flag, and the refresh timer.		settings of the E flag, T flag, and the refresh timer.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FMS sub-type (300) | Length |		| FMS sub-type (300) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|E|S|T| Reserved | Refresh Timer |		|E|S|T| Reserved | Refresh Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ sub-TLVs ~		~ sub-TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Fault Management Signal sub-TLV format		Figure 12: Fault Management Signal sub-TLV format
	Sub-type: indicates a new sub-type, the FMS sub-TLV (value 300).		Sub-type: indicates a new sub-type, the FMS sub-TLV (value 300).
	Length: indicates the length of the Value field in octets (4).		Length: indicates the length of the Value field in octets.
	FMS Signal Flags are used to enable the FMS signals at end point MEPs		FMS Signal Flags are used to enable the FMS signals at end point MEPs
	and the Server MEPs of the links over which the LSP is forwarded. In		and the Server MEPs of the links over which the LSP is forwarded. In
	this document only the S flag pertains to Server MEPs.		this document only the S flag pertains to Server MEPs.
	The following flags are defined:		The following flags are defined:
	- E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR)		- E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR)
	signaling as described in [RFC6427]. Default value is 1		signaling as described in [RFC6427]. Default value is 1
	(enabled). If the egress MEP does not support FMS signal		(enabled). If the egress MEP does not support FMS signal
	skipping to change at page 18, line 47		skipping to change at page 20, line 13
	with a higher timer value.		with a higher timer value.
	FMS sub-TLV MAY include Traffic Class sub-TLV Section 2.2.5. If TC		FMS sub-TLV MAY include Traffic Class sub-TLV Section 2.2.5. If TC
	sub-TLV is present, the value of the TC field MUST be used as the		sub-TLV is present, the value of the TC field MUST be used as the
	value of the TC field of an MPLS label stack entry for FMS messages.		value of the TC field of an MPLS label stack entry for FMS messages.
	If the TC sub-TLV is absent, then selection of the TC value is local		If the TC sub-TLV is absent, then selection of the TC value is local
	decision.		decision.
	2.2.10. Source MEP-ID Sub-TLV		2.2.10. Source MEP-ID Sub-TLV
	The Source MEP-ID sub-TLV depicted in Figure 11 is carried as a sub-		The Source MEP-ID sub-TLV depicted in Figure 13 is carried as a sub-
	TLV of the MPLS OAM Functions TLV.		TLV of the MPLS OAM Functions TLV.
	Note that support of ITU IDs is out-of-scope.		Note that support of ITU IDs is out-of-scope.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source MEP-ID sub-type (400) | Length |		| Source MEP-ID sub-type (400) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Node ID |		| Source Node ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tunnel ID | LSP ID |		| Tunnel ID | LSP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Source MEP-ID sub-TLV format		Figure 13: Source MEP-ID sub-TLV format
	Sub-type: indicates a new sub-type, the Source MEP-ID sub-TLV (value		Sub-type: indicates a new sub-type, the Source MEP-ID sub-TLV (value
	400).		400).
	Length: indicates the length of the Value field in octets (8).		Length: indicates the length of the Value field in octets (8).
	Source Node ID: 32-bit node identifier as defined in [RFC6370].		Source Node ID: 32-bit node identifier as defined in [RFC6370].
	Tunnel ID: a 16-bit unsigned integer unique to the node as defined in		Tunnel ID: a 16-bit unsigned integer unique to the node as defined in
	[RFC6370].		[RFC6370].
	skipping to change at page 20, line 40		skipping to change at page 22, line 7
	- If an egress LSR does not support Fault Monitoring Signals, and		- If an egress LSR does not support Fault Monitoring Signals, and
	it is requested, an "OAM Problem/Fault management signaling		it is requested, an "OAM Problem/Fault management signaling
	unsupported" error MUST be generated.		unsupported" error MUST be generated.
	- If an intermediate server MEP supports Fault Monitoring Signals		- If an intermediate server MEP supports Fault Monitoring Signals
	but is unable to create an association, when requested to do so,		but is unable to create an association, when requested to do so,
	an "OAM Problem/Unable to create fault management association"		an "OAM Problem/Unable to create fault management association"
	error MUST be generated.		error MUST be generated.
			Ingress LSR MAY combine multiple MPLS OAM configuration TLVs and sub-
			TLVs into single MPLS echo request. In case an egress LSR doesn't
			support any of the requested modes it MUST set the return code to
			report the first unsupported mode in the list of TLVs and sub-TLVs.
			And if any of the requested OAM configuration is not supported the
			egress LSR SHOULD NOT process OAM Configuration TLVs and sub-TLVs
			listed in the MPLS echo request.
	4. IANA Considerations		4. IANA Considerations
	4.1. TLV and Sub-TLV Allocation		4.1. TLV and Sub-TLV Allocation
	IANA maintains the Multi-Protocol Label Switching (MPLS) Label		IANA maintains the Multi-Protocol Label Switching (MPLS) Label
	Switched Paths (LSPs) Ping Parameters registry, and within that		Switched Paths (LSPs) Ping Parameters registry, and within that
	registry a sub-registry for TLVs and sub-TLVs.		registry a sub-registry for TLVs and sub-TLVs.
	IANA is requested a new TLV from the standards action range (0-16383)		IANA is requested a new TLV from the standards action range (0-16383)
	and sub-TLVs as follows from this sub-registry.		and sub-TLVs as follows from this sub-registry.
	skipping to change at page 21, line 18		skipping to change at page 22, line 39
	| TBA1 | | MPLS OAM Functions | This document |		| TBA1 | | MPLS OAM Functions | This document |
	| | 100 | BFD Configuration | This document |		| | 100 | BFD Configuration | This document |
	| | 101 | BFD Local Discriminator | This document |		| | 101 | BFD Local Discriminator | This document |
	| | 102 | BFD Negotiation Timer | This document |		| | 102 | BFD Negotiation Timer | This document |
	| | | Parameters | |		| | | Parameters | |
	| | 103 | BFD Authentication | This document |		| | 103 | BFD Authentication | This document |
	| | 104 | Traffic Class | This document |		| | 104 | Traffic Class | This document |
	| | 200 | Performance Measurement | This document |		| | 200 | Performance Measurement | This document |
	| | 201 | PM Loss Measurement | This document |		| | 201 | PM Loss Measurement | This document |
	| | 202 | PM Delay Measurement | This document |		| | 202 | PM Delay Measurement | This document |
	| | 203 | Fault Management Signal | This document |		| | 300 | Fault Management Signal | This document |
	| | 204 | Source MEP-ID | This document |		| | 400 | Source MEP-ID | This document |
	+------+----------+---------------------------------+---------------+		+------+----------+---------------------------------+---------------+
	Table 2: IANA TLV Type Allocation		Table 1: IANA TLV Type Allocation
	4.2. OAM Configuration Errors		4.2. MPLS OAM Function Flags Allocation
			IANA is requested to create a new registry called the "MPLS OAM
			Function Flags" registry and to populate it as follows.
			+------------+--------------------+---------------------------------+
			| Bit | MPLS OAM Function | Description |
			| Position | Flag | |
			+------------+--------------------+---------------------------------+
			| 0 | C | Continuity Check (CC) |
			| 1 | V | Connectivity Verification (CV) |
			| 2 | F | Fault Management Signal (FMS) |
			| 3 | L | Performance Measurement/Loss |
			| | | (PM/Loss) |
			| 4 | D | Performance Measurement/Delay |
			| | | (PM/Delay) |
			| 5 | T | Throughput Measurement) |
			| 6-31 | | Unassigned (Must be zero) |
			+------------+--------------------+---------------------------------+
			Table 2: MPLS OAM Function Flags
			4.3. OAM Configuration Errors
	IANA maintains a registry "Multi-Protocol Label Switching (MPLS)		IANA maintains a registry "Multi-Protocol Label Switching (MPLS)
	Label Switched Paths (LSPs) Ping Parameters" registry, and within		Label Switched Paths (LSPs) Ping Parameters" registry, and within
	that registry a sub-registry "Return Codes".		that registry a sub-registry "Return Codes".
	IANA is requested to assign new Return Codes from the Standards		IANA is requested to assign new Return Codes from the Standards
	Action range (0-191) as follows:		Action range (0-191) as follows:
	+---------------+-----------------------------------+---------------+		+---------------+-----------------------------------+---------------+
	| Error Value | Description | Reference |		| Error Value | Description | Reference |
	skipping to change at page 22, line 40		skipping to change at page 24, line 40
	| TBA14 | OAM Problem/Fault management | This document |		| TBA14 | OAM Problem/Fault management | This document |
	| | signaling unsupported | |		| | signaling unsupported | |
	| TBA15 | OAM Problem/Unable to create | This document |		| TBA15 | OAM Problem/Unable to create | This document |
	| | fault management association | |		| | fault management association | |
	+---------------+-----------------------------------+---------------+		+---------------+-----------------------------------+---------------+
	Table 3: IANA Return Codes Allocation		Table 3: IANA Return Codes Allocation
	5. Acknowledgements		5. Acknowledgements
	The authors would like to thank Nobo Akiya for his useful comments.		The authors would like to thank Nobo Akiya, David Allan and Adrian
			Farrel for their thorough reviews and insightful comments.
	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 introduces additional security		establishment of OAM entities introduces additional security
	considerations to those discussed in [RFC3473]. In particular, a		considerations to those discussed in [RFC4379]. In particular, a
	network element could be overloaded if an attacker were to request		network element could be overloaded if an attacker were to request
	high frequency liveliness monitoring of a large number of LSPs,		high frequency liveliness monitoring of a large number of LSPs,
	targeting a single network element.		targeting a single network element. Implementations must be made
			cognizant of available OAM resources and MAY refuse new OAM
			configurations that would overload a node. Additional policies to
			manage OAM resources may be used to provide some fairness in OAM
			resource distribution among monitored LSPs.
			Security of OAM protocols configured with extenssions to LSP Ping
			described in this document are discussed in [RFC5880], [RFC5884],
			[RFC6374], [RFC6427], and [RFC6428].
	Additional discussion of security for MPLS protocols can be found in		Additional discussion of security for MPLS protocols can be found in
	[RFC5920].		[RFC5920].
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
	DOI 10.17487/RFC3473, January 2003,
	<http://www.rfc-editor.org/info/rfc3473>.
	[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,
	DOI 10.17487/RFC4379, February 2006,		DOI 10.17487/RFC4379, February 2006,
	<http://www.rfc-editor.org/info/rfc4379>.		<http://www.rfc-editor.org/info/rfc4379>.
	[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,		[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
	Sprecher, N., and S. Ueno, "Requirements of an MPLS		Sprecher, N., and S. Ueno, "Requirements of an MPLS
	Transport Profile", RFC 5654, DOI 10.17487/RFC5654,		Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
	September 2009, <http://www.rfc-editor.org/info/rfc5654>.		September 2009, <http://www.rfc-editor.org/info/rfc5654>.
	[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
	"Requirements for Operations, Administration, and
	Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
	DOI 10.17487/RFC5860, May 2010,
	<http://www.rfc-editor.org/info/rfc5860>.
	[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,		(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
	<http://www.rfc-editor.org/info/rfc5880>.		<http://www.rfc-editor.org/info/rfc5880>.
	[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,		[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
	"Bidirectional Forwarding Detection (BFD) for MPLS Label		"Bidirectional Forwarding Detection (BFD) for MPLS Label
	Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,		Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
	June 2010, <http://www.rfc-editor.org/info/rfc5884>.		June 2010, <http://www.rfc-editor.org/info/rfc5884>.
	[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport		[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
	skipping to change at page 25, line 15		skipping to change at page 27, line 10
	[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,		[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
	Administration, and Maintenance (OAM) Toolset for MPLS-		Administration, and Maintenance (OAM) Toolset for MPLS-
	Based Transport Networks", RFC 6669, DOI 10.17487/RFC6669,		Based Transport Networks", RFC 6669, DOI 10.17487/RFC6669,
	July 2012, <http://www.rfc-editor.org/info/rfc6669>.		July 2012, <http://www.rfc-editor.org/info/rfc6669>.
	[RFC7419] Akiya, N., Binderberger, M., and G. Mirsky, "Common		[RFC7419] Akiya, N., Binderberger, M., and G. Mirsky, "Common
	Interval Support in Bidirectional Forwarding Detection",		Interval Support in Bidirectional Forwarding Detection",
	RFC 7419, DOI 10.17487/RFC7419, December 2014,		RFC 7419, DOI 10.17487/RFC7419, December 2014,
	<http://www.rfc-editor.org/info/rfc7419>.		<http://www.rfc-editor.org/info/rfc7419>.
	[RSVP-TE-CONF]		[RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
	Bellagamba, E., Andersson, L., Ward, D., and P.		Skoldstrom, P., and D. Ward, "Configuration of Proactive
	Skoldstrom, "Configuration of proactive MPLS-TP
	Operations, Administration, and Maintenance (OAM)		Operations, Administration, and Maintenance (OAM)
	Functions Using RSVP-TE", 2012, <draft-ietf-ccamp-rsvp-te-		Functions for MPLS-Based Transport Networks Using RSVP-
	mpls-tp-oam-ext>.		TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
			<http://www.rfc-editor.org/info/rfc7487>.
	Authors' Addresses		Authors' Addresses
	Elisa Bellagamba		Elisa Bellagamba
	Email: elisa.bellagamba@gmail.com		Email: elisa.bellagamba@gmail.com
	Gregory Mirsky		Gregory Mirsky
	Ericsson		Ericsson
End of changes. 73 change blocks.
	170 lines changed or deleted		238 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/