draft-ietf-mpls-remote-lsp-ping-02.txt		draft-ietf-mpls-remote-lsp-ping-03.txt
	Network Working Group George Swallow		Network Working Group George Swallow
	Internet Draft Cisco Systems, Inc.		Internet Draft Cisco Systems, Inc.
	Category: Standards Track		Category: Standards Track
	Expiration Date: January 2009
	Vanson Lim		Vanson Lim
	Cisco Systems, Inc.		Cisco Systems, Inc.
	July 14, 2008		November 3, 2008
	Proxy LSP Ping		Proxy LSP Ping
	draft-ietf-mpls-remote-lsp-ping-02.txt		draft-ietf-mpls-remote-lsp-ping-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 8		skipping to change at page 2, line 8
	Label Switched Protocol Pings on Label Switched Paths. A proxy		Label Switched Protocol Pings on Label Switched Paths. A proxy
	ping request is sent to any Label Switching Routers along a Label		ping request is sent to any Label Switching Routers along a Label
	Switched Path. The primary motivations for this facility are		Switched Path. The primary motivations for this facility are
	first to limit the number of messages and related processing when		first to limit the number of messages and related processing when
	using LSP Ping in large Point-to-Multipoint LSPs, and second to		using LSP Ping in large Point-to-Multipoint LSPs, and second to
	enable leaf to root tracing.		enable leaf to root tracing.
	Contents		Contents
	1 Introduction .............................................. 3		1 Introduction .............................................. 3
	1.1 Conventions ............................................... 3		1.1 Conventions ............................................... 4
	2 Proxy Ping Overview ....................................... 4		2 Proxy Ping Overview ....................................... 4
	3 Proxy MPLS Echo Request / Reply Pprocedures ............... 5		3 Proxy MPLS Echo Request / Reply Pprocedures ............... 5
	3.1 Procedures for the initiator .............................. 5		3.1 Procedures for the initiator .............................. 5
	3.2 Procedures for the proxy LSR .............................. 6		3.2 Procedures for the proxy LSR .............................. 6
	3.2.1 Sending an MPLS proxy ping reply .......................... 7		3.2.1 Sending an MPLS proxy ping reply .......................... 7
	3.2.2 Sending the MPLS echo requests ............................ 7		3.2.2 Sending the MPLS echo requests ............................ 8
	4 Proxy Ping Request / Reply Messages ....................... 9		4 Proxy Ping Request / Reply Messages ....................... 9
	4.1 Proxy Ping Request / Reply Message formats ................ 9		4.1 Proxy Ping Request / Reply Message formats ................ 9
	4.2 Proxy Ping Request Message contents ....................... 10		4.2 Proxy Ping Request Message contents ....................... 11
	4.3 Proxy Ping Reply Message Contents ......................... 11		4.3 Proxy Ping Reply Message Contents ......................... 11
	5 Object formats ............................................ 11		5 Object formats ............................................ 12
	5.1 Proxy Echo Parameters Object .............................. 11		5.1 Proxy Echo Parameters Object .............................. 12
	5.1.1 Next Hop sub-Object ....................................... 13		5.1.1 Next Hop sub-Object ....................................... 14
	5.2 Reply-to Address Object ................................... 14		5.2 Reply-to Address Object ................................... 15
	5.3 Previous Hop Address Object ............................... 15		5.3 Previous Hop Address Object ............................... 15
	6 Security Considerations ................................... 16		6 Security Considerations ................................... 16
	7 IANA Considerations ....................................... 16		7 IANA Considerations ....................................... 17
	7.1 Message and Object Type Assignments ....................... 16		8 References ................................................ 18
	7.2 Return Code Assignments ................................... 17		8.1 Normative References ...................................... 18
	8 References ................................................ 17		8.2 Informative References .................................... 18
	8.1 Normative References ...................................... 17
	8.2 Informative References .................................... 17
	9 Authors' Addresses ........................................ 18		9 Authors' Addresses ........................................ 18
	1. Introduction		1. Introduction
	It is anticipated that very large Point-to-Multipoint (P2MP) Label		It is anticipated that very large Point-to-Multipoint (P2MP) Label
	Switched Paths (LSPs) will exist. Further it is anticipated that		Switched Paths (LSPs) will exist. Further it is anticipated that
	many of the applications for P2MP tunnels will require OAM that is		many of the applications for P2MP tunnels will require OAM that is
	both rigorous and scalable.		both rigorous and scalable.
	Suppose one wishes to trace a P2MP LSP to localize a fault which is		Suppose one wishes to trace a P2MP LSP to localize a fault which is
	affecting one egress or a set of egresses. Suppose one follows the		affecting one egress or a set of egresses. Suppose one follows the
	normal procedure for tracing - namely repeatedly pinging from the		normal procedure for tracing - namely repeatedly pinging from the
	root, incrementing the TTL by one after each three or so pings. Such		root, incrementing the TTL by one after each three or so pings. Such
	a procedure has the potential for producing a large amount of pro-		a procedure has the potential for producing a large amount of pro-
	cessing at the P2MP-LSP midpoints and egresses. It also could pro-		cessing at the P2MP-LSP midpoints and egresses. It also could pro-
	duce an unwieldy number of replies back to the root.		duce an unwieldy number of replies back to the root.
	One alternative would be to begin sending pings from points at or		One alternative would be to begin sending pings from points at or
	near the affected egress(es) and working backwards toward the root.		near the affected egress(es) and working backwards toward the root.
	The TTL could be held constant as say two, limiting the the number of		The TTL could be held constant as say two, limiting the the number of
	responses to the number of next-next-hops of the point where the ping		responses to the number of next-next-hops of the point where a ping
	was initiated.		is initiated.
	The above procedure does require that the root know the previous-hop		This document defines protocol extensions to MPLS ping [RFC4379] to
	node to the one which was pinged on the prior iteration. This infor-		allow a third party to remotely cause an MPLS echo request message to
	mation is readily available in [P2MP-TE]. This document provides a		be sent down a Label Switched Path (LSP) or part of an LSP. The pro-
	means for obtaining this information for [mLDP] as well as defining a		cedure described in the paragraphs above does require that the ini-
	means for remotely causing an MPLS echo request message to be sent		tiator know the previous-hop node to the one which was pinged on the
	down a Label Switched Path (LSP) or part of an LSP.		prior iteration. This information is readily available in [P2MP-TE].
			This also document provides a means for obtaining this information
			for [mLDP].
	While the motivaton for this document came from multicast scaling		While the motivaton for this document came from multicast scaling
	concerns, its applicability may be wider. However other uses of this		concerns, its applicability may be wider. However other uses of this
	facility are beyond the scope of this document. Further the discus-		facility are beyond the scope of this document. In particular, the
	sion is cauched in terms of multipoint LSPs.		procedures defined in this document only allow testing of a FEC stack
			consisting of a single FEC. It also does not allow the initiator to
			specify the label assigned to that FEC, nor does it allow the initia-
			tor to cause any additional labels to be added to the label stack of
			the actual MPLS echo request message. Further the discussion is
			cauched in terms of multipoint LSPs.
	1.1. Conventions		1.1. Conventions
	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 [KeyWords].		document are to be interpreted as described in RFC 2119 [KeyWords].
	The term "Must Be Zero" (MBZ) is used in object descriptions for		The term "Must Be Zero" (MBZ) is used in object descriptions for
	reserved fields. These fields MUST be set to zero when sent and		reserved fields. These fields MUST be set to zero when sent and
	ignored on receipt.		ignored on receipt.
	Based on context the terms leaf and egress are used interchangeably.		Based on context the terms leaf and egress are used interchangeably.
	Egress is used where consistency with [RFC4379] was deemed appropri-		Egress is used where consistency with [RFC4379] was deemed appropri-
	ate. Receiver is used in the context of receiving protocol messages.		ate. Receiver is used in the context of receiving protocol messages.
	[Note (to be removed after assignments occur): <tba> = to be assigned		[Note (to be removed after assignments occur): <tba> = to be assigned
	by IANA]		by IANA]
	2. Proxy Ping Overview		2. Proxy Ping Overview
	Two new LSP Ping messages are defined for remote pinging, the MPLS		This document defines a protocol interaction between a first node and
	proxy ping request and the MPLS proxy ping reply.		a node which is part of an LSP to allow the first node to remotely
			initiate a an LSP ping for the LSP. Two new LSP Ping messages are
			defined for remote pinging, the MPLS proxy ping request and the MPLS
			proxy ping reply.
	A remote ping operation on a P2MP LSP involves at least three LSRs;		A remote ping operation on a P2MP LSP involves at least three LSRs;
	in some scenarios none of these are the ingress (root) or an egress		in some scenarios none of these are the ingress (root) or an egress
	(leaf) of the LSP.		(leaf) of the LSP.
	We refer to these nodes with the following terms:		We refer to these nodes with the following terms:
	Initiator - the node which initiates the ping operation by sending		Initiator - the node which initiates the ping operation by sending
	an MPLS proxy ping request message		an MPLS proxy ping request message
	skipping to change at page 4, line 43		skipping to change at page 5, line 13
	previous hop, i.e. the LSR upstream of it on this LSP.		previous hop, i.e. the LSR upstream of it on this LSP.
	The proxy LSR validates that it has a label mapping for the specified		The proxy LSR validates that it has a label mapping for the specified
	FEC and that it is authorized to send the specified MPLS echo request		FEC and that it is authorized to send the specified MPLS echo request
	on behalf of the initiator. Depending on the Reply Mode carried in		on behalf of the initiator. Depending on the Reply Mode carried in
	the header of the proxy ping request message and the above results an		the header of the proxy ping request message and the above results an
	MPLS remote echo reply message might be sent back to the initiator.		MPLS remote echo reply message might be sent back to the initiator.
	This message may also communicate the address of the previous hop.		This message may also communicate the address of the previous hop.
	If the proxy LSR has a label mapping for the FEC and and all autho-		If the proxy LSR has a label mapping for the FEC and and all autho-
	rization check have passed, the proxy LSR formats an MPLS echo		rization checks have passed, the proxy LSR formats an MPLS echo
	request. If the source address of the IP packet is not the initia-		request. If the source address of the IP packet is not the initia-
	tor, it includes a Reply-to Address object containing the initiator's		tor, it includes a Reply-to Address object containing the initiator's
	address. It then sends it inband of the LSP.		address. It then sends it inband of the LSP.
	The receivers process the MPLS echo request as normal, sending their		The receivers process the MPLS echo request as normal, sending their
	MPLS echo replies back to the initiator.		MPLS echo replies back to the initiator.
	3. Proxy MPLS Echo Request / Reply Pprocedures		3. Proxy MPLS Echo Request / Reply Pprocedures
	3.1. Procedures for the initiator		3.1. Procedures for the initiator
	The initiator creates an MPLS proxy ping request message.		The initiator creates an MPLS proxy ping request message.
	The message MUST contain a Target FEC Stack that describes the FEC		The message MUST contain a Target FEC Stack that describes the FEC
	being tested.		being tested.
	[Note for the current version of the ID, the FEC stack is limited to		The message MUST contain a Proxy Echo Parameters object. In that
	a single FEC as we have not yet fully considered the operational and		object, the address type is set to either IPv4 or IPv6. The Destina-
	security impacts of permitting more FECs]		tion IP Address is set to the value to be used in the MPLS echo
			request packet. If the Address Type is IPv4, an address from the
	The message MUST contain a Proxy Echo Parameters object. The address		range 127/8. If the Address Type is IPv6, an address from the range
	type is set to either IPv4 or IPv6. The Destination IP Address is		0:0:0:0:0:FFFF:7F00:0/104.
	set to the value to be used in the MPLS echo request packet. If the
	Address Type is IPv4, an address from the range 127/8. If the
	Address Type is IPv6, an address from the range
	0:0:0:0:0:FFFF:127/104. By default the source address will be set to
	an address of the proxy LSR.
	The Reply mode and Global Flags of the Proxy Echo Parameters object		The Reply mode and Global Flags of the Proxy Echo Parameters object
	are set to the values to be used in the MPLS echo request message		are set to the values to be used in the MPLS echo request message
	header. The Source UDP Port is set to the value to be used in the		header. The Source UDP Port is set to the value to be used in the
	MPLS echo request packet. The TTL is set to the value to be used in		MPLS echo request packet. The TTL is set to the value to be used in
	the outgoing MPLS label stack. See section 5.2.2.2 for further		the outgoing MPLS label stack. See section 5.2.2.2 for further
	details.		details.
	Flags MAY be set to request the previous hop address and/or a down-		If the previous hop address and/or a downstream mapping object from
	stream mapping object from the proxy LSR.		the proxy LSR is needed the corresponding flag in the Flags field of
			the Proxy Echo Parameters object is set.
	A list of Next Hop IP Addresses MAY be included to limit the next		A list of Next Hop IP Addresses MAY be included to limit the next
	hops towards which the MPLS echo request message will be sent.		hops towards which the MPLS echo request message will be sent. These
			are encoded as Next Hop sub-objects and included in the Proxy Echo
			Parameters object.
	Any of following objects MAY be included; these objects will be		Any of following objects MAY be included; these objects will be
	copied into the MPLS echo request messages:		copied into the MPLS echo request messages:
	Pad		Pad
	Vendor Enterprise Number		Vendor Enterprise Number
	Reply TOS Byte		Reply TOS Byte
	P2MP Egress Identifier [McstPing]		P2MP Egress Identifier [McstPing]
	Echo Jitter TLV [McstPing]		Echo Jitter TLV [McstPing]
	Vendor Private TLVs		Vendor Private TLVs
	skipping to change at page 6, line 37		skipping to change at page 7, line 5
	The proxy LSR validates that it has a label mapping for the specified		The proxy LSR validates that it has a label mapping for the specified
	FEC, it then determines if it is an egress, transit or bud node and		FEC, it then determines if it is an egress, transit or bud node and
	sets the Return Code as appropriate.		sets the Return Code as appropriate.
	The proxy LSR then determines if it is authorized to send the speci-		The proxy LSR then determines if it is authorized to send the speci-
	fied MPLS echo request on behalf of the initiator. An LSR MUST be		fied MPLS echo request on behalf of the initiator. An LSR MUST be
	capable of filtering addresses to validate initiators. Other filters		capable of filtering addresses to validate initiators. Other filters
	on FECs or MPLS echo request contents MAY be applied. If a filter		on FECs or MPLS echo request contents MAY be applied. If a filter
	has been invoked (i.e. configured) and an address does not pass the		has been invoked (i.e. configured) and an address does not pass the
	filter, then an MPLS echo request message MUST NOT be sent, and the		filter, then an MPLS echo request message MUST NOT be sent, and the
	event SHOULD be logged. An MPLS proxy ping reply message may be sent		event SHOULD be logged. An MPLS proxy ping reply message MAY be sent
	with a Return Code of <tba>, "Remote Ping not authorized".		with a Return Code of <tba>, "Remote Ping not authorized".
			The destination address specified in the Proxy Echo Parameters object
			is checked to ensure that it conforms to the address allowed IPv4 or
			IPv6 address range. If not, it sets the Return Code set to "Mal-
			formed echo request received" and the Subcode set to zero. If the
			Reply Mode of the message header is not 1, an MPLS proxy ping reply
			message SHOULD be sent as described below.
	If the "Request for Previous Hop" flag is set, a Previous Hop Address		If the "Request for Previous Hop" flag is set, a Previous Hop Address
	Object is formatted for inclusion in the MPLS proxy ping reply. If		Object is formatted for inclusion in the MPLS proxy ping reply. If
	the previous HOP is unknown or ambiguous the Address Type is set to		the previous HOP is unknown or ambiguous the Address Type is set to
	"No Address Supplied".		"No Address Supplied".
	If there is a list of Next Hop addresses in the Proxy Echo Parameters		If there are Next Hop sub-objexts in the Proxy Echo Parameters
	object, each address is examined to determine if it is a next hop for		object, each address is examined to determine if it is a next hop for
	this FEC. If any are not, those addresses are deleted from the list.		this FEC. If any are not, those sub-objects are from the Proxy Echo
	The updated Proxy Echo Parameters object is included in the MPLS		Parameters object. The updated object is included in the MPLS proxy
	proxy ping reply.		ping reply.
	If the "Request for Downstream Mapping" flag is set the LSR formats a		If the "Request for Downstream Mapping" flag is set the LSR formats a
	Downstream Mapping object for each interface that the MPLS echo		Downstream Mapping object for each interface over which the MPLS echo
	request will be sent out.		request will be sent.
	If the Reply Mode of the message header is not 1 or 5, an MPLS remote		If the Reply Mode of the message header is 1 or is 5 and no errors or
	echo reply message SHOULD be sent as described below.		modificatons have occurred no MPLS proxy ping reply is sent. Other-
			wise an MPLS proxy ping reply message SHOULD be sent as described
			below.
	3.2.1. Sending an MPLS proxy ping reply		3.2.1. Sending an MPLS proxy ping reply
	The Reply mode, Sender's Handle and Sequence Number fields are copied		The Reply mode, Sender's Handle and Sequence Number fields are copied
	from the proxy ping request message. Various objects are included as		from the proxy ping request message. The objects specified above are
	specified above. The message is encapsulated in a UDP packet. The		included. The message is encapsulated in a UDP packet. The source
	source IP address is a routable address of the proxy LSR; the source		IP address is a routable address of the proxy LSR; the source port is
	port is the well-known UDP port for LSP ping. The destination IP		the well-known UDP port for LSP ping. The destination IP address and
	address and UDP port are copied from the source IP address and UDP		UDP port are copied from the source IP address and UDP port of the
	port of the echo request. The IP TTL is set to 255.		echo request. The IP TTL is set to 255.
	3.2.2. Sending the MPLS echo requests		3.2.2. Sending the MPLS echo requests
	A base MPLS echo request is formed as decribed in the next section.		A base MPLS echo request is formed as decribed in the next section.
	The section below that describes how the base MPLS echo request is		The section below that describes how the base MPLS echo request is
	sent on each interface.		sent on each interface.
	3.2.2.1. Forming the base MPLS echo request		3.2.2.1. Forming the base MPLS echo request
	A Next_Hop_List is created as follows. If Next Hop addresses were		A Next_Hop_List is created as follows. If Next Hop sub-objects were
	included in the received Proxy Parameters object, the Next_Hop_List		included in the received Proxy Parameters object, the Next_Hop_List
	is copied from the Proxy Echo Parameters object as adjusted above.		created from the address in those sub-ojects as adjusted above. Oth-
	Otherwise, the list is set to all the next hops to which the FEC		erwise, the list is set to all the next hops to which the FEC would
	would be forwarded.		be forwarded.
	The proxy LSR then formats an MPLS echo request message. The Global		The proxy LSR then formats an MPLS echo request message. The Global
	Flags and Reply Mode are copied from the Proxy Echo Parameters		Flags and Reply Mode are copied from the Proxy Echo Parameters
	object. The Return Code and Return Subcode are set to zero.		object. The Return Code and Return Subcode are set to zero.
	The Sender's Handle and Sequence Number are copied from the remote		The Sender's Handle and Sequence Number are copied from the remote
	echo request message.		echo request message.
	The TimeStamp Sent is set to the time-of-day (in seconds and		The TimeStamp Sent is set to the time-of-day (in seconds and
	microseconds) that the echo request is sent. The TimeStamp Received		microseconds) that the echo request is sent. The TimeStamp Received
	skipping to change at page 8, line 16		skipping to change at page 8, line 46
	Target FEC Stack		Target FEC Stack
	Pad		Pad
	Vendor Enterprise Number		Vendor Enterprise Number
	Reply TOS Byte		Reply TOS Byte
	P2MP Egress Identifier [McstPing]		P2MP Egress Identifier [McstPing]
	Echo Jitter TLV [McstPing]		Echo Jitter TLV [McstPing]
	Vendor Private TLVs		Vendor Private TLVs
	The message is then encapsulated in a UDP packet. The source UDP		The message is then encapsulated in a UDP packet. The source UDP
	port is copied from the Proxy Echo Parameters object. destination		port is copied from the Proxy Echo Parameters object. The destina-
	ports are copied from the proxy ping request message.		tion port copied from the proxy ping request message.
	The source IP address is set to a routable address of the proxy LSR.		The source IP address is set to a routable address of the proxy LSR.
	Per usual the TTL of the IP packet is set to 1.		Per usual the TTL of the IP packet is set to 1.
	If the Explicit DSCP flag is set, the Requested DSCP byte is exam-		If the Explicit DSCP flag is set, the Requested DSCP byte is exam-
	ined. If the setting is permitted then the DSCP byte of the IP		ined. If the setting is permitted then the DSCP byte of the IP
	header of the MPLS Echo Request message is set to that value. Other-		header of the MPLS Echo Request message is set to that value. Other-
	wise the DSCP byte is set to a default value. In this case the MPLS		wise the DSCP byte is set to a default value. In this case the MPLS
	Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be		Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be
	included in any MPLS proxy ping reply message. The return code MUST		included in any MPLS proxy ping reply message. The return code MUST
	skipping to change at page 8, line 39		skipping to change at page 9, line 22
	the MPLS Proxy Echo Parameters SHOULD be set to the actual value		the MPLS Proxy Echo Parameters SHOULD be set to the actual value
	used.		used.
	3.2.2.2. Per interface sending procedures		3.2.2.2. Per interface sending procedures
	The proxy LSR now iterates through the Next_Hop_List modifying the		The proxy LSR now iterates through the Next_Hop_List modifying the
	base MPLS echo request to form the MPLS echo request packet which is		base MPLS echo request to form the MPLS echo request packet which is
	then sent on that particular interface.		then sent on that particular interface.
	For each next hop address, the outgoing label stack is determained.		For each next hop address, the outgoing label stack is determained.
	The TTL for the label corresponding to the topmost FEC in the FEC		The TTL for the label corresponding to the FEC specified in the FEC
	stack is set such that the TTL on the wire will be one less than the		stack is set such that the TTL on the wire will be one less than the
	TTL specified in the Proxy Echo Parameters. If any additional labels		TTL specified in the Proxy Echo Parameters. If any additional labels
	are pushed onto the stack, their TTLs are set to 255.		are pushed onto the stack, their TTLs are set to 255.
	If the MPLS proxy ping request message contained Downstream Mapping		If the MPLS proxy ping request message contained Downstream Mapping
	objects, they are examined. If the Downstream IP Address matches the		objects, they are examined. If the Downstream IP Address matches the
	next hop address that Downstream Mapping object is included in the		next hop address that Downstream Mapping object is included in the
	MPLS echo request.		MPLS echo request.
	The packet is then transmitted on this interface.		The packet is then transmitted on this interface.
	4. Proxy Ping Request / Reply Messages		4. Proxy Ping Request / Reply Messages
	Two new LSP Ping messages are defined for remote pinging, the MPLS		This document defines two new LSP Ping messages, the MPLS proxy ping
	proxy ping request message and the MPLS proxy ping reply.		request and the MPLS proxy ping reply.
	4.1. Proxy Ping Request / Reply Message formats		4.1. Proxy Ping Request / Reply Message formats
	Except where noted, the definitions of all fields in the messages are		Except where noted, the definitions of all fields in the messages are
	identical to those found in [LSP-PING]. The messages have the fol-		identical to those found in [RFC4379]. The messages have the follow-
	lowing format:		ing format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version Number | MUST Be Zero |		| Version Number | MUST Be Zero |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Type | Reply mode | Return Code | Return Subcode|		| Message Type | Reply mode | Return Code | Return Subcode|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender's Handle |		| Sender's Handle |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 36		skipping to change at page 10, line 28
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLVs ... |		| TLVs ... |
	. .		. .
	. .		. .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Version Number		Version Number
	The Version Number is currently 1. (Note: the Version Number is		The Version Number is currently 1. (Note: the Version Number
	to be incremented whenever a change is made that affects the		is to be incremented whenever a change is made that affects the
	ability of an implementation to correctly parse or process an		ability of an implementation to correctly parse or process an
	MPLS echo request/reply. These changes include any syntactic or		MPLS echo request/reply. These changes include any syntactic
	semantic changes made to any of the fixed fields, or to any TLV		or semantic changes made to any of the fixed fields, or to any
	or sub-TLV assignment or format that is defined at a certain		TLV or sub-TLV assignment or format that is defined at a
	version number. The Version Number may not need to be changed		certain version number. The Version Number may not need to be
	if an optional TLV or sub-TLV is added.)		changed if an optional TLV or sub-TLV is added.)
	Message Type		Message Type
	Type Message		Type Message
	---- -------		---- -------
	5 MPLS proxy ping request		5 MPLS proxy ping request
	6 MPLS proxy ping reply		6 MPLS proxy ping reply
	Reply mode		Reply mode
	The reply modes are the same as [LSP-PING] with the addtion of		The reply modes are the same as [RFC4379] with the addtion of
	value 5. For completeness, the full list of reply modes		value 5. For completeness, the full list of reply modes
	follows:		follows:
	Value Meaning		Value Meaning
	----- -------		----- -------
	1 Do not reply		1 Do not reply
	2 Reply via an IPv4/IPv6 UDP packet		2 Reply via an IPv4/IPv6 UDP packet
	3 Reply via an IPv4/IPv6 UDP packet with Router Alert		3 Reply via an IPv4/IPv6 UDP packet with Router Alert
	4 Reply via application level control channel		4 Reply via application level control channel
	5 Reply via an IPv4/IPv6 UDP packet only if the proxy		5 Reply via an IPv4/IPv6 UDP packet only if the proxy
	request is not fulfilled or modified		request is not fulfilled or is modified
	4.2. Proxy Ping Request Message contents		4.2. Proxy Ping Request Message contents
	The MPLS proxy ping request message MAY contain the following		The MPLS proxy ping request message MAY contain the following
	objects:		objects:
	Type Object		Type Object
	---- -----------		---- -----------
	1 Target FEC Stack		1 Target FEC Stack
	2 Downstream Mapping		2 Downstream Mapping
	skipping to change at page 13, line 18		skipping to change at page 14, line 4
	receipt. When the flag is set this field contains the DSCP		receipt. When the flag is set this field contains the DSCP
	value to be used in the MPLS echo request packet IP header.		value to be used in the MPLS echo request packet IP header.
	Source UDP Port		Source UDP Port
	The source UDP port to be sent in the MPLS Echo Request packet		The source UDP port to be sent in the MPLS Echo Request packet
	Global Flags		Global Flags
	The Global Flags to be sent in the MPLS Echo Request messge		The Global Flags to be sent in the MPLS Echo Request messge
	Destination IP Address		Destination IP Address
	If the Address Type is IPv4, an address from the range 127/8;		If the Address Type is IPv4, an address from the range 127/8;
	If the Address Type is IPv6, an address from the range		If the Address Type is IPv6, an address from the range
	0:0:0:0:0:FFFF:127/104		0:0:0:0:0:FFFF:7F00:0/104
	Sub-Objects		Sub-Objects
	A TLV encoded list of sub-objects. Currently one is defined.		A TLV encoded list of sub-objects. Currently one is defined.
	Sub-Type Length Value Field		Sub-Type Length Value Field
	-------- ------ -----------		-------- ------ -----------
	1 8+ Next Hop		1 8+ Next Hop
	5.1.1. Next Hop sub-Object		5.1.1. Next Hop sub-Object
	skipping to change at page 16, line 30		skipping to change at page 16, line 30
	the label for this FEC was exchanged, this address MUST be the		the label for this FEC was exchanged, this address MUST be the
	address used in that protocol exchange.		address used in that protocol exchange.
	Local Address		Local Address
	The local address used in the protocol adjacency exists by		The local address used in the protocol adjacency exists by
	which the label for this FEC was exchanged.		which the label for this FEC was exchanged.
	6. Security Considerations		6. Security Considerations
	[To be written]		The mechanisms described in this document are intended to be used
			within a Service Provider network and to be initiated only under the
			authority of that administration.
	7. IANA Considerations		If such a network also carries internet traffic, or permits IP access
			from other administrations, MPLS proxy ping message SHOULD be dis-
			carded at those points. This can be accomplished by filtering on
			source address or by filtering all MPLS ping messages on UDP port.
	[Not complete]		Any node which acts as a proxy node SHOULD validate requests against
			a set of valid source addresses. An implementation MUST provide such
			filtering capabilities.
	7.1. Message and Object Type Assignments		MPLS proxy ping request messages are IP addressed directly to the
			Proxy node. If a node which receives an MPLS proxy ping message via
			TTL expiration, it MUST NOT be acted upon.
	This document makes the following codepoint assigments (pending IANA		MPLS proxy ping requests are limited to making their request via the
	action):		specification of a FEC. This ensures that only valid MPLS echo
			request messages can be created. No label spoofing attacks are
			possible.
	Registry Codepoint Purpose		7. IANA Considerations
	LSP Ping Message Type tba MPLS proxy ping request message		This document makes the following assigments (pending IANA action):
			LSP Ping Message Types
			Type Value Field
			---- -----------
			tba MPLS proxy ping request message
	tba MPLS proxy ping reply		tba MPLS proxy ping reply
	LSP Ping Object Type tba Proxy Echo Parameters		Objects and Sub-Objects
			Type Sub-Type Value Field
			---- -------- -----------
			tba Proxy Echo Parameters
			1 Next Hop
	tba Reply-to Address		tba Reply-to Address
	tba Previous Hop Address		tba Previous Hop Address
	7.2. Return Code Assignments		Return Codes
	Value Meaning		Value Meaning
			----- -------
	tba Proxy ping request not authorized		tba Remote ping not authorized
	tba Proxy ping parameters modified		tba Proxy ping parameters modified
			Reply Modes [pending IANA assignment]
			Value Meaning
			----- -------
			5 Reply via an IPv4/IPv6 UDP packet only if the
			proxy request is not fulfilled or is modified
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,		Label Switched (MPLS) Data Plane Failures", RFC 4379,
	February 2006.		February 2006.
	[KeyWords] Bradner, S., "Key words for use in RFCs to Indicate		[KeyWords] 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.
	[McstPing] Farrel, A. et al, "Detecting Data Plane Failures in		[McstPing] Farrel, A. et al, "Detecting Data Plane Failures in
	Point-to-Multipoint MPLS Traffic Engineering -		Point-to-Multipoint MPLS Traffic Engineering -
	Extensions to LSP Ping",		Extensions to LSP Ping",
	draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008.		draft-ietf-mpls-p2mp-lsp-ping-07.txt, September 2008.
	8.2. Informative References		8.2. Informative References
	[P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for		[P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for
	Point-to-Multipoint TE LSPs", RFC 4875, May 2007.		Point-to-Multipoint TE LSPs", RFC 4875, May 2007.
	[mLDP] Minei, I., et. al., "Label Distribution Protocol		[mLDP] Minei, I., et. al., "Label Distribution Protocol
	Extensions for Point-to-Multipoint and		Extensions for Point-to-Multipoint and
	Multipoint-to-Multipoint Label Switched Paths"		Multipoint-to-Multipoint Label Switched Paths"
	draft-ietf-mpls-ldp-p2mp-05.txt, May 2008.		draft-ietf-mpls-ldp-p2mp-05.txt, May 2008.
	skipping to change at page 18, line 42		skipping to change at page 19, line 26
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at
	ipr@ietf.org.		ietf-ipr@ietf.org.
	Full Copyright Notice		Full Copyright Notice
	Copyright (C) The IETF Trust (2008). This document is subject		Copyright (C) The IETF Trust (2008). This document is subject to the
	to the rights, licenses and restrictions contained in BCP 78, and		rights, licenses and restrictions contained in BCP 78, and except as
	except as set forth therein, the authors retain all their rights.		set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 51 change blocks.
	100 lines changed or deleted		141 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/