draft-ietf-mpls-rfc6374-udp-return-path-05.txt		rfc7876.txt
	MPLS S. Bryant		Internet Engineering Task Force (IETF) S. Bryant
	Internet-Draft Independent		Request for Comments: 7876 Independent
	Intended status: Standards Track S. Sivabalan		Category: Standards Track S. Sivabalan
	Expires: October 9, 2016 S. Soni		ISSN: 2070-1721 S. Soni
	Cisco Systems		Cisco Systems
	April 7, 2016		July 2016
	RFC6374 UDP Return Path		UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks
	draft-ietf-mpls-rfc6374-udp-return-path-05
	Abstract		Abstract
	RFC6374 defines a protocol for Packet Loss and Delay Measurement for		RFC 6374 defines a protocol for Packet Loss and Delay Measurement for
	MPLS networks (MPLS-PLDM). This document specifies the procedures to		MPLS networks (MPLS-PLDM). This document specifies the procedures to
	be used when sending and processing out-of-band MPLS performance		be used when sending and processing out-of-band MPLS performance
	management responses over an IP/UDP return path.		management Responses over an UDP/IP return path.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on October 9, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7876.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
			1. Introduction ....................................................3
			2. Requirements Language ...........................................3
			3. Solution Overview ...............................................3
			3.1. UDP Return Object ..........................................4
			4. Theory of Operation .............................................5
			4.1. Sending an MPLS-PLDM Query .................................5
			4.2. Receiving an MPLS-PLDM Query Request .......................5
			4.3. Sending an MPLS-PLDM Response ..............................6
			4.4. Receiving an MPLS-PLDM Response ............................7
			5. Congestion Considerations .......................................7
			6. Manageability Considerations ....................................8
			7. Security Considerations .........................................8
			8. IANA Considerations .............................................8
			9. References ......................................................9
			9.1. Normative References .......................................9
			9.2. Informative References .....................................9
			Acknowledgements ..................................................10
			Authors' Addresses ................................................10
	1. Introduction		1. Introduction
	This document describes how Packet Loss and Delay Measurement for		This document describes how MPLS-PLDM [RFC6374] out-of-band Responses
	MPLS Networks protocol (MPLS-PLDM) [RFC6374] out-of-band responses
	can be delivered to the querier using UDP/IP.		can be delivered to the querier using UDP/IP.
	The use of UDP may be required to support data path management such		The use of UDP may be required to support data-path management such
	as passage through firewalls, or to provide the necessary		as passage through firewalls or to provide the necessary multiplexing
	multiplexing needed in bistatic operation where the querier and the		needed in bistatic operation where the querier and the collector are
	collector are not co-located and the collector is gathering the		not co-located and the collector is gathering the Response
	response information for a number of responders. In a highly scaled		information for a number of responders. In a highly scaled system,
	system some MPLS-PLDM sessions may be off-loaded to a specific node		some MPLS-PLDM sessions may be off-loaded to a specific node within
	within the distributed system that comprises the Label Switching		the distributed system that comprises the Label Switching Router
	Router (LSR) as a whole. In such systems the response may arrive via		(LSR) as a whole. In such systems, the Response may arrive via any
	any interface in the LSR and need to be forwarded internally to the		interface in the LSR and needs to be forwarded internally to the
	processor tasked with handling the particular MPLS-PLDM measurement.		processor tasked with handling the particular MPLS-PLDM measurement.
	Currently the MPLS-PLDM protocol does not have any mechanism to		Currently, the MPLS-PLDM protocol does not have any mechanism to
	deliver the PLDM Response message to a particular node within a		deliver the PLDM Response message to a particular node within a
	multi-CPU LSR.		multi-CPU LSR.
	The procedure described in this specification describes how the		The procedure described in this specification describes how the
	querier requests delivery of the MPLS-PLDM response over IP to a		querier requests delivery of the MPLS-PLDM Response over IP to a
	dynamic UDP port. It makes no other changes to the protocol and thus		dynamic UDP port. It makes no other changes to the protocol and thus
	does not affect the case where the response is delivered over a MPLS		does not affect the case where the Response is delivered over an MPLS
	Associated Channel [RFC5586].		Associated Channel [RFC5586].
	2. Requirements Language		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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Solution Overview		3. Solution Overview
	This document specifies that, unless configured otherwise, if a UDP		This document specifies that, unless configured otherwise, if a UDP
	Return Object (URO) is present in a MPLS-PLDM Query, the responder		Return Object (URO) is present in an MPLS-PLDM Query, the responder
	SHOULD use the IP address and UDP port in the URO to reply back to		SHOULD use the IP address and UDP port in the URO to reply back to
	the querier. The querier MAY include multiple UROs in a MPLS-PLDM		the querier. The querier MAY include multiple UROs in an MPLS-PLDM
	Query indicating to the responder that an identical responses SHOULD		Query indicating to the responder that an identical Response SHOULD
	be sent to each address-port pair. A responder MAY be designed or		be sent to each address-port pair. A responder MAY be designed or
	configured to only transmit a single response, in which case the		configured to only transmit a single Response, in which case the
	response MUST be sent using the parameters specified in the first URO		Response MUST be sent using the parameters specified in the first URO
	in the query packet that it is able to use (see Section 4.3).		in the Query packet that it is able to use (see Section 4.3).
	The procedures defined in this document may be applied to both		The procedures defined in this document may be applied to both
	unidirectional and bidirectional LSPs. In this document, the term		unidirectional and bidirectional Label Switched Paths (LSPs). In
	bidirectional LSP includes the co-routed bidirectional LSP defined in		this document, the term "bidirectional LSP" includes the co-routed
	[RFC3945] and the associated bidirectional LSP that is constructed		bidirectional LSP defined in [RFC3945] and the associated
	from a pair of unidirectional LSPs (one for each direction) that are		bidirectional LSP that is constructed from a pair of unidirectional
	associated with one another at the LSP's ingress/egress points		LSPs (one for each direction) that are associated with one another at
	[RFC5654]. The mechanisms defined in this document can apply to both		the LSP's ingress/egress points [RFC5654]. The mechanisms defined in
	IP/MPLS and to the MPLS Transport Profile (MPLS-TP)[RFC5654],		this document can apply to both IP/MPLS and to the MPLS Transport
	[RFC5921]		Profile (MPLS-TP) [RFC5654] [RFC5921].
	3.1. UDP Return Object		3.1. UDP Return Object
	NOTE TO RFC Editor please delete the following paragraph before
	publication.
	START DELETE
	Note to reviewers - We considered a number of approaches to the
	design. The first was to use the existing address object and a
	separate UDP object, but concern was expressed in the WG that there
	may be more than one collector that required this information, and
	the combined size of the two objects was large. The next approach
	considered by the authors was to create a new object by appending a
	UDP port to the existing generalized address object. However, noting
	that UDP is only likely to be sent over IP and that it will be a long
	time before we design a third major version of IP we can compress the
	object either by having separate IPv4 and IPv6 objects, or using the
	address length as the discriminator. The object design below uses
	the latter approach. The resultant combined UDP port + address
	object is thus the same size as the original address object.
	END DELETE
	The format of the UDP Return Object (URO) is as follows:		The format of the UDP Return Object (URO) is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| URO TLV Type | Length={6,18} | UDP-Destination-Port |		| URO Type | Length={6,18} | UDP-Destination-Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Address ~		~ Address ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Type and Length fields are each 8 bits long. The Length field		The Type and Length fields are each 8 bits long. The Length field
	indicates the size in bytes of the remainder of the object (i.e. is		indicates the size in bytes of the remainder of the object (i.e., it
	the size of the address in bytes plus 2). When the address is IPv4		is the size of the address in bytes plus 2). When the address is
	the length field is thus 6 and when the address is IPv6 the length		IPv4, the Length field is thus 6; when the address is IPv6, the
	field is thus 18. The length field therefore acts as both the TLV		Length field is thus 18. The Length field therefore acts as both the
	parsing parameter and the address family type indicator.		TLV parsing parameter and the address family type indicator.
	The UDP Return Object Type (URO TLV Type) has a value of 131.		The UDP Return Object Type (URO Type) has a value of 131.
	The UDP Destination Port is a UDP Destination port as specified in		The UDP-Destination-Port is a UDP destination port as specified in
	[RFC0768].		[RFC768].
	The Address is either an IPv4 or an IPv6 address.		The Address is either an IPv4 or an IPv6 address.
	The URO MUST NOT appear in a response and MUST be ignored if it is		The URO MUST NOT appear in a Response and MUST be ignored if it is
	found to be present.		found to be present.
	To prevent any ambiguity as to which address the responder needs to		To prevent any ambiguity as to which address the responder needs to
	reply to, an MPLS-PLDM Query message containing a URO MUST NOT		reply to, an MPLS-PLDM Query message containing a URO MUST NOT
	include an RFC6374 Return Address TLV (TLV 1). Additionally, the		include an RFC 6374 Return Address TLV (TLV 1). Additionally, the
	method of constructing the return address from the Source Address TLV		method of constructing the return address from the Source Address TLV
	(TLV 130) described in Section 3.5.2 of RFC6374 MUST NOT be used to		(TLV 130) described in Section 3.5.2 of [RFC6374] MUST NOT be used to
	construct a Response to a Query message that contains a URO.		construct a Response to a Query message that contains a URO.
	4. Theory of Operation		4. Theory of Operation
	This document defines the UDP Return Object to enable the MPLS-PLDM		This document defines the UDP Return Object to enable the MPLS-PLDM
	querier to specify the return path for the MPLS-PLDM reply using UDP/		querier to specify the return path for the MPLS-PLDM reply using UDP/
	IP encapsulation.		IP encapsulation.
	When the MPLS-PLDM Response is requested out-of-band by setting the		When the MPLS-PLDM Response is requested out-of-band by setting the
	Control Code of the MPLS-PLDM query to "Out-of-band Response		Control Code of the MPLS-PLDM Query to "Out-of-band Response
	Requested", and the URO is present, the responder SHOULD send the		Requested", and the URO is present, the responder SHOULD send the
	response back to querier on the specified destination UDP port at the		Response back to querier on the specified destination UDP port at the
	specified destination IP address contained in the URO.		specified destination IP address contained in the URO.
	If the URO is expected but is not present in a query message and an		If the URO is expected but is not present in a Query message and an
	MPLS-PLDM Response is requested out-of-band, the query message MUST		MPLS-PLDM Response is requested out-of-band, the Query message MUST
	NOT be processed further, and if possible an "Error - Invalid		NOT be processed further, and if possible, an "Error - Invalid
	Message" ([RFC6374] Section 3.1) SHOULD be send to the querier and		Message" ([RFC6374], Section 3.1) SHOULD be sent to the querier and
	the operator notified via the management system (see Section 4.2 for		the operator notified via the management system (see Section 4.2 for
	further details.		further details).
	4.1. Sending an MPLS-PLDM Query		4.1. Sending an MPLS-PLDM Query
	When sending an MPLS-PLDM query message, in addition to the rules and		When sending an MPLS-PLDM Query message, in addition to the rules and
	procedures defined in [RFC6374]; the Control Code of the MPLS-PLDM		procedures defined in [RFC6374], the Control Code of the MPLS-PLDM
	query MUST be set to "Out-of-band Response Requested", and a URO MUST		Query MUST be set to "Out-of-band Response Requested", and a URO MUST
	be carried in the MPLS-PLDM query message.		be carried in the MPLS-PLDM Query message.
	If the querier uses the UDP port to de-multiplex the response for		If the querier uses the UDP port to de-multiplex the Response for a
	different measurement type, there MUST be a different UDP port for		different measurement type, there MUST be a different UDP port for
	each measurement type (Delay, loss and delay-loss combined).		each measurement type (delay, loss, and delay-loss combined).
	An implementation MAY use multiple UDP ports for same measurement		An implementation MAY use multiple UDP ports for the same measurement
	type to direct the response to the correct management process in the		type to direct the Response to the correct management process in the
	LSR.		LSR.
	4.2. Receiving an MPLS PLDM Query Request		4.2. Receiving an MPLS-PLDM Query Request
	The processing of MPLS-PLDM query messages as defined in [RFC6374]		The processing of MPLS-PLDM Query messages as defined in [RFC6374]
	applies in this document. In addition, when an MPLS-PLDM query		applies in this document. In addition, when an MPLS-PLDM Query
	message is received, with the control code of the MPLS-PLDM query set		message is received, with the Control Code of the MPLS-PLDM Query set
	to "Out-of-band Response Requested" with a URO present, then the		to "Out-of-band Response Requested" with a URO present, then the
	responder SHOULD use that IP address and UDP port to send MPLS-PLDM		responder SHOULD use that IP address and UDP port to send an MPLS-
	response back to querier.		PLDM Response back to the querier.
	If an Out-of-band response is requested and the URO is missing, the		If an out-of-band Response is requested and the URO is missing, the
	query SHOULD be dropped in the case of a unidirectional LSP. If the		Query SHOULD be dropped in the case of a unidirectional LSP. If the
	TLV is missing on a bidirectional LSP, the control code of the		TLV is missing on a bidirectional LSP, the Control Code of the
	Response message SHOULD set to 0x1C indicating "Error - Invalid		Response message SHOULD set to 0x1C indicating "Error - Invalid
	Message" ([RFC6374] Section 3.1) and the response SHOULD be sent over		Message" ([RFC6374], Section 3.1), and the Response SHOULD be sent
	the reverse LSP. The receipt of such a mal-formed request SHOULD be		over the reverse LSP. The receipt of such a malformed request SHOULD
	notified to the operator through the management system, taking the		be reported to the operator through the management system, with
	normal precautions with respect to the prevention of overload of the		normal precautions taken in respect to the prevention of overload of
	error reporting system.		the error-reporting system.
	4.3. Sending an MPLS-PLDM Response		4.3. Sending an MPLS-PLDM Response
	As specified in [RFC6374] the MPLS-PLDM Response can be sent over		As specified in [RFC6374], the MPLS-PLDM Response can be sent either
	either the reverse MPLS LSP for a bidirectional LSP or over an IP		over the reverse MPLS LSP for a bidirectional LSP or over an IP path.
	path. It MUST NOT be sent other than in response to an MPLS-PLDM		It MUST NOT be sent other than in Response to an MPLS-PLDM Query
	query message.		message.
	When the requested return path is an IP forwarding path and this		When the requested return path is an IP forwarding path and this
	method is in use, the destination IP address and UDP port is copied		method is in use, the destination IP address and UDP port are copied
	from the URO. The source IP address and the source UDP Port of the		from the URO. The source IP address and the source UDP port of the
	Response packet is left to discretion of the responder subject to the		Response packet are left to the discretion of the responder, subject
	normal management and security considerations. If the querier has		to the normal management and security considerations. If the querier
	included URO(s) for only one IP address family and a return path of		has included URO(s) for only one IP address family and a return path
	that type is not available, then the query message MUST be discarded,		of that type is not available, then the Query message MUST be
	and the operator SHOULD be informed of the error through the		discarded, and the operator SHOULD be informed of the error through
	management system using the normal rate limited approach. If the		the management system using the normal rate-limited approach. If the
	responder is configured to only respond with a single response, and a		responder is configured to only respond with a single Response, and a
	path using the IP address family in the first URO is not available,		path using the IP address family in the first URO is not available,
	the responder MAY search the UROs for the first URO specifying a		the responder MAY search the UROs for the first URO specifying a
	return address family for which it does have a path and use the		return address family for which it does have a path and use the
	parameters in that URO to respond. If the responder is designed or		parameters in that URO to respond. If the responder is designed or
	configured not to search for a URO that it can respond to, then the		configured not to search for a URO that it can respond to, then the
	operator SHOULD be informed of the error through the management		operator SHOULD be informed of the error through the management
	system using the normal rate limited approach.		system using the normal rate-limited approach.
	The packet format for the MPLS-PLDM response after the UDP header is		The packet format for the MPLS-PLDM Response after the UDP header is
	as specified in [RFC6374]. As shown in Figure 1 the Associate		as specified in [RFC6374]. As shown in Figure 1, the Associated
	Channel Header (ACH) [RFC5586] is not included. The information		Channel Header (ACH) [RFC5586] is not included. The information
	provided by the ACH is not needed since the correct binding between		provided by the ACH is not needed since the correct binding between
	the query and response messages is achieved though the UDP Port and		the Query and Response messages is achieved through the UDP port and
	the session indentifier contained in the RFC6374 message.		the session identifier contained in the RFC 6374 message.
	+----------------------------------------------------------+		+----------------------------------------------------------+
	| IP Header |		| IP Header |
	. Source Address = Responders IP Address |		. Source Address = Responders IP Address |
	. Destination Address = URO.Address |		. Destination Address = URO.Address |
	. Protocol = UDP .		. Protocol = UDP .
	. .		. .
	+----------------------------------------------------------+		+----------------------------------------------------------+
	| UDP Header |		| UDP Header |
	. Source Port = As chosen by Responder .		. Source Port = As chosen by Responder .
	. Destination Port = URO.UDP-Destination-Port .		. Destination Port = URO.UDP-Destination-Port .
	. .		. .
	+----------------------------------------------------------+		+----------------------------------------------------------+
	| Message as specified in RFC6374 |		| Message as specified in RFC 6374 |
	. .		. .
	+----------------------------------------------------------+		+----------------------------------------------------------+
	Figure 1: Response packet Format		Figure 1: Response Packet Format
	If the return path is an IP path, only one-way delay or one-way loss		If the return path is an IP path, only one-way delay or one-way loss
	measurement can be carried out. In this case timestamps 3 and 4 MUST		measurement can be carried out. In this case, timestamps 3 and 4
	be zero as specified in [RFC6374].		MUST be zero as specified in [RFC6374].
	4.4. Receiving an MPLS-PLDM Response		4.4. Receiving an MPLS-PLDM Response
	If the response was received over UDP/IP and an out-of-band response		If the Response was received over UDP/IP and an out-of-band Response
	was expected, the Response message SHOULD be directed to the		was expected, the Response message SHOULD be directed to the
	appropriate measurement process as determined by the destination UDP		appropriate measurement process as determined by the destination UDP
	Port, and processed using the corresponding measurement type		port and processed using the corresponding measurement type procedure
	procedure specified in F [RFC6374].		specified in [RFC6374].
	If the Response was received over UDP/IP and an out-of-band response		If the Response was received over UDP/IP and an out-of-band Response
	was not requested, that response SHOULD be dropped and the event		was not requested, that Response SHOULD be dropped, and the event
	SHOULD be notified to the operator through the management system,		SHOULD be reported to the operator through the management system,
	taking the normal precautions with respect to the prevention of		with normal precautions taken in respect to the prevention of
	overload of the error reporting system.		overload of the error-reporting system.
	5. Congestion Considerations		5. Congestion Considerations
	This protocol MUST be run in accordance the guidance provided in		This protocol MUST be run in accordance with the guidance provided in
	[RFC5405]. As advised in section 3.2.1 of RFC5405, operators that		[RFC5405]. As advised in Section 3.1.2 of RFC 5405, operators that
	wish to run this protocol at rates in excess of one packet per three		wish to run this protocol at rates in excess of one packet per three
	seconds need to ensure that the MPLS path being monitored and any IP		seconds need to ensure that the MPLS path being monitored and any IP
	path that may be used to carry the response are provisioned such that		path that may be used to carry the Response are provisioned such that
	there is a negligible chance of this protocol causing congestion.		there is a negligible chance of this protocol causing congestion.
	Additionally, if a significant number of response packets are lost,		Additionally, if a significant number of Response packets are lost,
	the querier MUST reduce the sending rate to a point where there is a		the querier MUST reduce the sending rate to a point where there is a
	negligible chance that this protocol is contributing to network		negligible chance that this protocol is contributing to network
	congestion. The operator should also take precautions that response		congestion. The operator should also take precautions that Response
	packets do not leak out of the network domain being used and cause		packets do not leak out of the network domain being used and cause
	congestion elsewhere. If a default IP address is configured by the		congestion elsewhere. If a default IP address is configured by the
	equipment vendor, this MUST be an address known to contain the		equipment vendor, this MUST be an address known to contain the
	response packet within the responder, such as the IPv4 localhost		Response packet within the responder. A responder receiving a Query
	address [RFC6890] or the IPv6 loopback address [RFC4291]. A		specifying this as a return address, and not being configured to
	responder receiving a query specifying this as a return address, and		expect such a return address, SHOULD notify the operator in a
	not being configured to expect such a return address*, SHOULD notify		suitably rate-limited manner.
	the operator in a suitably rate limited manner.
	6. Manageability Considerations		6. Manageability Considerations
	The manageability considerations described in Section 7 of [RFC6374]		The manageability considerations described in Section 7 of [RFC6374]
	are applicable to this specification. Additional manageability		are applicable to this specification. Additional manageability
	considerations are noted within the elements of procedure of this		considerations are noted within the elements of procedure in this
	document.		document.
	Nothing in this document precludes the use of a configured UDP/IP		Nothing in this document precludes the use of a configured UDP/IP
	return path in a deployment in which configuration is preferred to		return path in a deployment in which configuration is preferred to
	signalling. In these circumstances the URO MAY be omitted from the		signaling. In these circumstances, the URO MAY be omitted from the
	MPLS-PLDM messages.		MPLS-PLDM messages.
	7. Security Considerations		7. Security Considerations
	The MPLS-PLDM system is not intended to be deployed on the public		The MPLS-PLDM system is not intended to be deployed on the public
	Internet. It is intended for deployment in well managed private and		Internet. It is intended for deployment in well-managed private and
	service provider networks. The security considerations described in		service provider networks. The security considerations described in
	Section 8 of [RFC6374] are applicable to this specification and the		Section 8 of [RFC6374] are applicable to this specification, and
	reader's attention is drawn to the last two paragraphs.		particular attention should be paid to the last two paragraphs.
	Cryptographic measures may be enhanced by the correct configuration		Cryptographic measures may be enhanced by the correct configuration
	of access control lists and firewalls.		of access-control lists and firewalls.
	To prevent the use of this protocol as a reflection attack vector,		To prevent the use of this protocol as a reflection attack vector,
	the operator should ensure that the IP address in the URO addresses a		the operator should ensure that the IP address in the URO addresses a
	system that is expecting to act as a receiver of PLDM responses.		system that is expecting to act as a receiver of PLDM Responses.
	There is no additional exposure of information to pervasive		There is no additional exposure of information to pervasive
	monitoring systems observing LSPs that are being monitored.		monitoring systems observing LSPs that are being monitored.
	8. IANA Considerations		8. IANA Considerations
	IANA has made an early allocation of a new Optional TLV type from		IANA has assigned a new optional TLV type from the "MPLS Loss/Delay
	MPLS Loss/Delay Measurement TLV Object Registry contained within the		Measurement TLV Object" registry contained within the "Generic
	Generic Associated Channel (G-ACh) Parameters registry set. IANA is		Associated Channel (G-ACh) Parameters" registry set:
	requested to modify the description text as shown below.
	Code Description Reference
	131 UDP Return [This]
	9. Acknowledgements
	We acknowledge the contribution of Joseph Chin and Rakesh Gandhi,
	both with Cisco Systems. We thank Loa Andersson, Eric Osborne,
	Mustapha Aissaoui, Jeffrey Zhang and Ross Callon for their review
	comments.
	We thank all who have reviewed this text and provided feedback.		Code Description Reference
			131 UDP Return [RFC7876]
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<http://www.rfc-editor.org/info/rfc768>.		<http://www.rfc-editor.org/info/rfc768>.
	[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>.
	[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label		[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Architecture", RFC 3945,		Switching (GMPLS) Architecture", RFC 3945,
	DOI 10.17487/RFC3945, October 2004,		DOI 10.17487/RFC3945, October 2004,
	<http://www.rfc-editor.org/info/rfc3945>.		<http://www.rfc-editor.org/info/rfc3945>.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <http://www.rfc-editor.org/info/rfc4291>.
	[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines		[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
	for Application Designers", BCP 145, RFC 5405,		for Application Designers", BCP 145, RFC 5405,
	DOI 10.17487/RFC5405, November 2008,		DOI 10.17487/RFC5405, November 2008,
	<http://www.rfc-editor.org/info/rfc5405>.		<http://www.rfc-editor.org/info/rfc5405>.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,		[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,		"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,		DOI 10.17487/RFC5586, June 2009,
	<http://www.rfc-editor.org/info/rfc5586>.		<http://www.rfc-editor.org/info/rfc5586>.
	[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>.
	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay		[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374,		Measurement for MPLS Networks", RFC 6374,
	DOI 10.17487/RFC6374, September 2011,		DOI 10.17487/RFC6374, September 2011,
	<http://www.rfc-editor.org/info/rfc6374>.		<http://www.rfc-editor.org/info/rfc6374>.
	[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,		9.2. Informative References
	"Special-Purpose IP Address Registries", BCP 153,
	RFC 6890, DOI 10.17487/RFC6890, April 2013,
	<http://www.rfc-editor.org/info/rfc6890>.
	10.2. Informative References
	[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,		[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
	L., and L. Berger, "A Framework for MPLS in Transport		L., and L. Berger, "A Framework for MPLS in Transport
	Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,		Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
	<http://www.rfc-editor.org/info/rfc5921>.		<http://www.rfc-editor.org/info/rfc5921>.
			Acknowledgements
			We acknowledge the contributions of Joseph Chin and Rakesh Gandhi,
			both with Cisco Systems. We thank Loa Andersson, Eric Osborne,
			Mustapha Aissaoui, Jeffrey Zhang, and Ross Callon for their review
			comments.
			We thank all who have reviewed this text and provided feedback.
	Authors' Addresses		Authors' Addresses
	Stewart Bryant		Stewart Bryant
	Independent		Independent
	Email: stewart.bryant@gmail.com		Email: stewart.bryant@gmail.com
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems		Cisco Systems
End of changes. 69 change blocks.
	186 lines changed or deleted		170 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/