draft-ietf-mpls-rfc6374-udp-return-path-01.txt		draft-ietf-mpls-rfc6374-udp-return-path-02.txt
	MPLS S. Bryant		MPLS S. Bryant
	Internet-Draft S. Sivabalan		Internet-Draft S. Sivabalan
	Intended status: Standards Track S. Soni		Intended status: Standards Track S. Soni
	Expires: March 8, 2015 Cisco Systems		Expires: March 29, 2015 Cisco Systems
	September 4, 2014		September 25, 2014
	RFC6374 UDP Return Path		RFC6374 UDP Return Path
	draft-ietf-mpls-rfc6374-udp-return-path-01		draft-ietf-mpls-rfc6374-udp-return-path-02
	Abstract		Abstract
	This document specifies the proceedure to be used by the Packet Loss		This document specifies the proceedure to be used by the Packet Loss
	and Delay Measurement for MPLS Networks protocol defined in RFC6374		and Delay Measurement for MPLS Networks protocol defined in RFC6374
	when sending and processing MPLS performance management out-of-band		when sending and processing MPLS performance management out-of-band
	responses for delay and loss measurements over an IP/UDP return path.		responses for delay and loss measurements over an IP/UDP return path.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 March 8, 2015.		This Internet-Draft will expire on March 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 49		skipping to change at page 3, line 49
	~ 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. is
	the size of the address in bytes plus 2). When the address is IPv4		the size of the address in bytes plus 2). When the address is IPv4
	the length field is thus 6 and when the address is IPv6 the length		the length field is thus 6 and when the address is IPv6 the length
	field is thus 18. The length field therefore acts as both the TLV		field is thus 18. The length field therefore acts as both the TLV
	parsing parameter and the address family type indicator.		parsing parameter and the address family type indicator.
	The UDP Return Object Type (URO TLV Type) has a value of <TBD>.		The UDP Return Object Type (URO TLV 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].		[RFC0768].
	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.		The URO MUST NOT appear in a response.
	4. Theory of Operation		4. Theory of Operation
	skipping to change at page 5, line 26		skipping to change at page 5, line 26
	4.3. Sending an MPLS-PM Response		4.3. Sending an MPLS-PM Response
	As specified in [RFC6374] the MPLS-PLDM Response can be sent over		As specified in [RFC6374] the MPLS-PLDM Response can be sent over
	either the reverse MPLS LSP for a bidirectional LSP or over an IP		either the reverse MPLS LSP for a bidirectional LSP or over an IP
	path. It MUST NOT be sent other than in response to an MPLS-PLDM		path. It MUST NOT be sent other than in response to an MPLS-PLDM
	Query message.		Query 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 MUST be		method is in use, the destination IP address and UDP port MUST be
	copied from the URO. The source IP address and the source UDP port		copied from the URO. The source IP address and the source UDP Port
	of Response packet is left to discretion of the Responder subject to		of Response packet is left to discretion of the Responder subject to
	the normal management and security considerations. The packet format		the normal management and security considerations. The packet format
	for the MPLS-PLDM response after the UDP header is as specified in		for the MPLS-PLDM response after the UDP header is as specified in
	[RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH)		[RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH)
	[RFC5586] is not incuded. The information provided by the ACH is not		[RFC5586] is not incuded. The information provided by the ACH is not
	needed since the correct binding between the Querry and Response		needed since the correct binding between the Querry and Response
	messages is achieved though the UDP Port and the Session Indentifier		messages is achieved though the UDP Port and the Session Indentifier
	contained in the RFC6374 message.		contained in the RFC6374 message.
	+----------------------------------------------------------+		+----------------------------------------------------------+
	skipping to change at page 7, line 20		skipping to change at page 7, line 20
	Section 8 of [RFC6374] are applicable to this specification and the		Section 8 of [RFC6374] are applicable to this specification and the
	reader's attention is drawn to the last two paragraphs.		reader's attention is drawn 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.
	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.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to assign a new Optional TLV type from MPLS Loss/		IANA has made an early allocation of a new Optional TLV type from
	Delay Measurement TLV Object Registry contained within the g-ach-		MPLS Loss/Delay Measurement TLV Object Registry contained within the
	parameters registry set.		g-ach-parameters registry set. IANA is requested to modify the
			description text as shown below.
	Code Description Reference		Code Description Reference
	TBD Return UDP Port [This]		131 UDP Return [This]
	The TLV 131 is recommended.
	8. Acknowledgements		8. Acknowledgements
	We acknowledge the contribution of Joseph Chin and Rakesh Gandhi,		We acknowledge the contribution of Joseph Chin and Rakesh Gandhi,
	both with Cisco Systems. We thank Loa Andersson, Eric Osborne,		both with Cisco Systems. We thank Loa Andersson, Eric Osborne,
	Mustapha Aissaoui, and Jeffrey Zhang for their review comments.		Mustapha Aissaoui, and Jeffrey Zhang for their review comments.
	We thank all who have reviewed this text and provided feedback.		We thank all who have reviewed this text and provided feedback.
	9. Normative References		9. References
			9.1. Normative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching		[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
	(GMPLS) Architecture", RFC 3945, October 2004.		(GMPLS) Architecture", RFC 3945, October 2004.
	[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic		[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
	Associated Channel", RFC 5586, June 2009.		Associated Channel", RFC 5586, June 2009.
	[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,		[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
	and S. Ueno, "Requirements of an MPLS Transport Profile",		and S. Ueno, "Requirements of an MPLS Transport Profile",
	RFC 5654, September 2009.		RFC 5654, September 2009.
			[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
			Measurement for MPLS Networks", RFC 6374, September 2011.
			9.2. Informative References
	[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.		[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
	Berger, "A Framework for MPLS in Transport Networks", RFC		Berger, "A Framework for MPLS in Transport Networks", RFC
	5921, July 2010.		5921, July 2010.
	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374, September 2011.
	Authors' Addresses		Authors' Addresses
	Stewart Bryant		Stewart Bryant
	Cisco Systems		Cisco Systems
	Email: stbryant@cisco.com		Email: stbryant@cisco.com
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems		Cisco Systems
End of changes. 10 change blocks.
	16 lines changed or deleted		19 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/