draft-ietf-mpls-lsp-ping-11.txt		draft-ietf-mpls-lsp-ping-12.txt
	Network Working Group Kireeti Kompella		Network Working Group Kireeti Kompella
	Internet Draft Juniper Networks, Inc.		Internet Draft Juniper Networks, Inc.
	Category: Standards Track		Category: Standards Track
	Expiration Date: May 2006		Expiration Date: June 2006
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	November 2005		December 2005
	Detecting MPLS Data Plane Failures		Detecting MPLS Data Plane Failures
	draft-ietf-mpls-lsp-ping-11.txt		draft-ietf-mpls-lsp-ping-12.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 7		skipping to change at page 2, line 7
	This document describes a simple and efficient mechanism that can be		This document describes a simple and efficient mechanism that can be
	used to detect data plane failures in Multi-Protocol Label Switching		used to detect data plane failures in Multi-Protocol Label Switching
	(MPLS) Label Switched Paths (LSPs). There are two parts to this		(MPLS) Label Switched Paths (LSPs). There are two parts to this
	document: information carried in an MPLS "echo request" and "echo		document: information carried in an MPLS "echo request" and "echo
	reply" for the purposes of fault detection and isolation; and		reply" for the purposes of fault detection and isolation; and
	mechanisms for reliably sending the echo reply.		mechanisms for reliably sending the echo reply.
	Contents		Contents
	1 Introduction .............................................. 3		1 Introduction .............................................. 4
	1.1 Conventions ............................................... 3		1.1 Conventions ............................................... 4
	1.2 Structure of this document ................................ 3		1.2 Structure of this document ................................ 4
	1.3 Contributors .............................................. 3		1.3 Contributors .............................................. 5
	2 Motivation ................................................ 4		2 Motivation ................................................ 5
	3 Packet Format ............................................. 5		2.1 Use of address range 127/8 ................................ 6
	3.1 Return Codes .............................................. 9		3 Packet Format ............................................. 7
	3.2 Target FEC Stack .......................................... 10		3.1 Return Codes .............................................. 12
	3.2.1 LDP IPv4 Prefix ........................................... 11		3.2 Target FEC Stack .......................................... 13
	3.2.2 LDP IPv6 Prefix ........................................... 11		3.2.1 LDP IPv4 Prefix ........................................... 14
	3.2.3 RSVP IPv4 LSP ............................................. 12		3.2.2 LDP IPv6 Prefix ........................................... 14
	3.2.4 RSVP IPv6 LSP ............................................. 12		3.2.3 RSVP IPv4 LSP ............................................. 15
	3.2.5 VPN IPv4 Prefix ........................................... 13		3.2.4 RSVP IPv6 LSP ............................................. 15
	3.2.6 VPN IPv6 Prefix ........................................... 14		3.2.5 VPN IPv4 Prefix ........................................... 16
	3.2.7 L2 VPN Endpoint ........................................... 14		3.2.6 VPN IPv6 Prefix ........................................... 17
	3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 15		3.2.7 L2 VPN Endpoint ........................................... 17
	3.2.9 FEC 128 Pseudowire (Current) .............................. 15		3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 18
	3.2.10 FEC 129 Pseudowire ........................................ 16		3.2.9 FEC 128 Pseudowire (Current) .............................. 18
	3.2.11 BGP Labeled IPv4 Prefix ................................... 16		3.2.10 FEC 129 Pseudowire ........................................ 19
	3.2.12 BGP Labeled IPv6 Prefix ................................... 17		3.2.11 BGP Labeled IPv4 Prefix ................................... 19
	3.2.13 Generic IPv4 Prefix ....................................... 17		3.2.12 BGP Labeled IPv6 Prefix ................................... 20
	3.2.14 Generic IPv6 Prefix ....................................... 18		3.2.13 Generic IPv4 Prefix ....................................... 20
	3.2.15 Nil FEC ................................................... 18		3.2.14 Generic IPv6 Prefix ....................................... 21
	3.3 Downstream Mapping ........................................ 19		3.2.15 Nil FEC ................................................... 21
	3.3.1 Multipath Information Encoding ............................ 23		3.3 Downstream Mapping ........................................ 22
	3.3.2 Downstream Router and Interface ........................... 25		3.3.1 Multipath Information Encoding ............................ 26
	3.4 Pad TLV ................................................... 25		3.3.2 Downstream Router and Interface ........................... 28
	3.5 Vendor Enterprise Code .................................... 26		3.4 Pad TLV ................................................... 28
	3.6 Interface and Label Stack ................................. 26		3.5 Vendor Enterprise Number .................................. 29
	3.7 Errored TLVs .............................................. 28		3.6 Interface and Label Stack ................................. 29
	3.8 Reply TOS Byte TLV ........................................ 28		3.7 Errored TLVs .............................................. 31
	4 Theory of Operation ....................................... 29		3.8 Reply TOS Byte TLV ........................................ 31
	4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 29		4 Theory of Operation ....................................... 32
	4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 30		4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 32
	4.3 Sending an MPLS Echo Request .............................. 30		4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 33
	4.4 Receiving an MPLS Echo Request ............................ 31		4.3 Sending an MPLS Echo Request .............................. 33
	4.5 Sending an MPLS Echo Reply ................................ 34		4.4 Receiving an MPLS Echo Request ............................ 34
	4.6 Receiving an MPLS Echo Reply .............................. 35		4.4.1 FEC Validation ............................................ 40
	4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36		4.5 Sending an MPLS Echo Reply ................................ 41
	4.8 Non-compliant Routers ..................................... 36		4.6 Receiving an MPLS Echo Reply .............................. 42
	5 References ................................................ 37		4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 42
	6 Security Considerations ................................... 38		4.8 Non-compliant Routers ..................................... 43
	7 IANA Considerations ....................................... 38		5 References ................................................ 43
	7.1 Message Types, Reply Modes, Return Codes .................. 39		6 Security Considerations ................................... 44
	7.2 TLVs ...................................................... 40		7 IANA Considerations ....................................... 45
	8 Acknowledgments ........................................... 41		7.1 Message Types, Reply Modes, Return Codes .................. 46
			7.2 TLVs ...................................................... 47
			8 Acknowledgments ........................................... 48
	1. Introduction		1. Introduction
	This document describes a simple and efficient mechanism that can be		This document describes a simple and efficient mechanism that can be
	used to detect data plane failures in MPLS LSPs. There are two parts		used to detect data plane failures in MPLS LSPs. There are two parts
	to this document: information carried in an MPLS "echo request" and		to this document: information carried in an MPLS "echo request" and
	"echo reply"; and mechanisms for transporting the echo reply. The		"echo reply"; and mechanisms for transporting the echo reply. The
	first part aims at providing enough information to check correct		first part aims at providing enough information to check correct
	operation of the data plane, as well as a mechanism to verify the		operation of the data plane, as well as a mechanism to verify the
	data plane against the control plane, and thereby localize faults.		data plane against the control plane, and thereby localize faults.
	The second part suggests two methods of reliable reply channels for		The second part suggests two methods of reliable reply channels for
	the echo request message, for more robust fault isolation.		the echo request message, for more robust fault isolation.
	An important consideration in this design is that MPLS echo requests		An important consideration in this design is that MPLS echo requests
	follow the same data path that normal MPLS packets would traverse.		follow the same data path that normal MPLS packets would traverse.
	MPLS echo requests are meant primarily to validate the data plane,		MPLS echo requests are meant primarily to validate the data plane,
	and secondarily to verify the data plane against the control plane.		and secondarily to verify the data plane against the control plane.
	Mechanisms to check the control plane are valuable, but are not cov-		Mechanisms to check the control plane are valuable, but are not cov-
	ered in this document.		ered in this document.
			This document makes special use of the address range 127/8. This is
			an exception to the behavior defined in RFC1122 [RFC1122] and updates
			that RFC. The motivation for this change and the details of this
			exceptional use are discussed in section 2.1 below.
	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 decriptions 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.
			Terminology pertaining to L2 and L3 VPNs is defined in [RFC4026].
	1.2. Structure of this document		1.2. Structure of this document
	The body of this memo contains four main parts: motivation, MPLS echo		The body of this memo contains four main parts: motivation, MPLS echo
	request/reply packet format, LSP ping operation, and a reliable		request/reply packet format, LSP ping operation, and a reliable
	return path. It is suggested that first-time readers skip the actual		return path. It is suggested that first-time readers skip the actual
	packet formats and read the Theory of Operation first; the document		packet formats and read the Theory of Operation first; the document
	is structured the way it is to avoid forward references.		is structured the way it is to avoid forward references.
	1.3. Contributors		1.3. Contributors
	skipping to change at page 5, line 5		skipping to change at page 6, line 9
	the control plane against the data plane, i.e., that forwarding		the control plane against the data plane, i.e., that forwarding
	matches what the routing protocols determined as the path.		matches what the routing protocols determined as the path.
	One way these tools can be used is to periodically ping a FEC to		One way these tools can be used is to periodically ping a FEC to
	ensure connectivity. If the ping fails, one can then initiate a		ensure connectivity. If the ping fails, one can then initiate a
	traceroute to determine where the fault lies. One can also periodi-		traceroute to determine where the fault lies. One can also periodi-
	cally traceroute FECs to verify that forwarding matches the control		cally traceroute FECs to verify that forwarding matches the control
	plane; however, this places a greater burden on transit LSRs and thus		plane; however, this places a greater burden on transit LSRs and thus
	should be used with caution.		should be used with caution.
			2.1. Use of address range 127/8
			As described above, LSP Ping is intended as a diagnostic tool. It is
			intended to enable providers of an MPLS based service to isolate net-
			work faults. In particular LSP Ping needs to diagnose situations
			where the control and data planes are out of sync. It performs this
			by routing an MPLS echo request packet based solely on its label
			stack. That is the IP destination address is never used in a for-
			warding decision. In fact, the sender of an MPLS echo request packet
			may not know, a priori, the address of the router at the end of the
			LSP.
			Providers of MPLS based services also need the ability to trace all
			of the possible paths that an LSP make take. Since most MPLS ser-
			vices are based on IP unicast forwarding, these paths are subject to
			equal cost multi-path load sharing (ECMP).
			This leads to the following requirements:
			1. Although the LSP in question may be broken in unknown ways, the
			likelihood of a diagnostic packet being delivered to a user of an
			MPLS service MUST be held to an absolute minimum.
			2. If an LSP is broken in such a way that it prematurely terminates,
			the diagnostic packet MUST NOT be IP forwarded.
			3. A means of varying the diagnostic packets such that they exercise
			all ECMP paths is thus REQUIRED.
			Clearly using general unicast addresses satisfies neither of the
			first two requirements. A number of other options for addresses were
			considered, including a portion of the private address space (as
			determined by the network operator) and the newly designated IPv4
			link local addresses. Use of the private address space was deemed
			ineffective since the leading MPLS based service is IPv4 Virtual Pri-
			vate Networks (VPN). VPNs often used private addresses.
			The IPv4 link local addresses are more attractive in that scope over
			which they can be forwarded is limited. However, if one were to use
			an address from this range, it would still be possible for the first
			recipient of a diagnostic packet that "escaped" from a broken LSP to
			have that addressed assigned to the interface on which it arrived and
			thus could mistakenly receive such a packet. Further, the IPv4 link
			local address range has only recently been allocated. Many deployed
			routers would forward a packet with an address from that range toward
			the default route.
			The 127/8 range for IPv4 and that same range embedded in an IPv6
			addresses for IPv6 was chosen for a number of reasons.
			RFC1122 allocates the 127/8 as "Internal host loopback address" and
			states that "Addresses of this form MUST NOT appear outside a host."
			Thus the default behavior of hosts is to discard such packets. This
			helps to ensure that if a diagnostic packet is mis-directed to a
			host, it will be silently discarded.
			RFC1812 [RFC1812] states that:
			A router SHOULD NOT forward, except over a loopback interface, any
			packet that has a destination address on network 127. A router
			MAY have a switch that allows the network manager to disable these
			checks. If such a switch is provided, it MUST default to perform-
			ing the checks.
			This helps to ensure that diagnostic packets are never IP forwarded.
			The 127/8 address range provides 16M addresses allowing wide flexi-
			bility in varying addresses to exercise ECMP paths. Finally, as an
			implementation optimization, the 127/8 provides an easy means of
			identifying possible LSP Packets.
	3. Packet Format		3. Packet Format
	An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet;		An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet;
	the contents of the UDP packet have the following format:		the contents of the UDP packet have the following 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 | Global Flags |		| Version Number | Global Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 39		skipping to change at page 9, line 34
	log gaps in the sequence numbers and/or maintain delay/jitter statis-		log gaps in the sequence numbers and/or maintain delay/jitter statis-
	tics. An MPLS echo request would normally have 2 (Reply via an		tics. An MPLS echo request would normally have 2 (Reply via an
	IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP		IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP
	return path is deemed unreliable, one may use 3 (Reply via an		return path is deemed unreliable, one may use 3 (Reply via an
	IPv4/IPv6 UDP packet with Router Alert). Note that this requires		IPv4/IPv6 UDP packet with Router Alert). Note that this requires
	that all intermediate routers understand and know how to forward MPLS		that all intermediate routers understand and know how to forward MPLS
	echo replies. The echo reply uses the same IP version number as the		echo replies. The echo reply uses the same IP version number as the
	received echo request, i.e., an IPv4 encapsulated echo reply is sent		received echo request, i.e., an IPv4 encapsulated echo reply is sent
	in response to an IPv4 encapsulated echo request.		in response to an IPv4 encapsulated echo request.
	Any application which supports an IP control channel between its con-		Some applications support an IP control channel. One such example is
	trol entities may set the Reply Mode to 4 (Reply via application		the associated control channel defined in Virtual Circuit Connectiv-
	level control channel) to ensure that replies use that same channel.		ity Verification [VCCV]. Any application which supports an IP con-
	Further definition of this codepoint is application specific and thus		trol channel between its control entities may set the Reply Mode to 4
	beyond the scope of this document.		(Reply via application level control channel) to ensure that replies
			use that same channel. Further definition of this codepoint is
			application specific and thus beyond the scope of this document.
	Return Codes and Subcodes are described in the next section.		Return Codes and Subcodes are described in the next section.
	the Sender's Handle is filled in by the sender, and returned		the Sender's Handle is filled in by the sender, and returned
	unchanged by the receiver in the echo reply (if any). There are no		unchanged by the receiver in the echo reply (if any). There are no
	semantics associated with this handle, although a sender may find		semantics associated with this handle, although a sender may find
	this useful for matching up requests with replies.		this useful for matching up requests with replies.
	The Sequence Number is assigned by the sender of the MPLS echo		The Sequence Number is assigned by the sender of the MPLS echo
	request, and can be (for example) used to detect missed replies.		request, and can be (for example) used to detect missed replies.
	The TimeStamp Sent is the time-of-day (in seconds and microseconds,		The TimeStamp Sent is the time-of-day (in seconds and microseconds,
	according to the sender's clock) when the MPLS echo request is sent.		according to the sender's clock) in NTP format [NTP] when the MPLS
	The TimeStamp Received in an echo reply is the time-of-day (according		echo request is sent. The TimeStamp Received in an echo reply is the
	to the receiver's clock) that the corresponding echo request was		time-of-day (according to the receiver's clock) in NTP format that
	received.		the corresponding echo request was received.
	TLVs (Type-Length-Value tuples) have the following format:		TLVs (Type-Length-Value tuples) have the following 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value |		| Value |
	. .		. .
	skipping to change at page 8, line 35		skipping to change at page 11, line 35
	A description of the Types and Values of the top level TLVs for LSP		A description of the Types and Values of the top level TLVs for LSP
	ping are given below:		ping are given below:
	Type # Value Field		Type # Value Field
	------ -----------		------ -----------
	1 Target FEC Stack		1 Target FEC Stack
	2 Downstream Mapping		2 Downstream Mapping
	3 Pad		3 Pad
	4 Not Assigned		4 Not Assigned
	5 Vendor Enterprise Code		5 Vendor Enterprise Number
	6 Not Assigned		6 Not Assigned
	7 Interface and Label Stack		7 Interface and Label Stack
	8 Not Assigned		8 Not Assigned
	9 Errored TLVs		9 Errored TLVs
	10 Reply TOS Byte		10 Reply TOS Byte
	Types less than 32768 (i.e., with the high order bit equal to 0) are		Types less than 32768 (i.e., with the high order bit equal to 0) are
	mandatory TLVs that MUST either be supported by an implementation or		mandatory TLVs that MUST either be supported by an implementation or
	result in the return code of 2 ("One or more of the TLVs was not		result in the return code of 2 ("One or more of the TLVs was not
	understood") being sent in the echo response.		understood") being sent in the echo response.
	skipping to change at page 14, line 34		skipping to change at page 17, line 34
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Prefix Length | Must Be Zero |		| Prefix Length | Must Be Zero |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.2.7. L2 VPN Endpoint		3.2.7. L2 VPN Endpoint
	VPLS BGP NLRI and VE ID are defined in [VPLS]. This document uses		VPLS BGP NLRI and VE ID are defined in [VPLS]. This document uses
	the simpler term L2 VPN endpoint when refering to a VPLS BGP NLRI.		the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI.
	When an L2 VPN endpoint is encoded in a label stack, the following		When an L2 VPN endpoint is encoded in a label stack, the following
	format is used. The value field consists of a Route Distinguisher (8		format is used. The value field consists of a Route Distinguisher (8
	octets), the sender (of the ping)'s VE ID (2 octets), the receiver's		octets), the sender (of the ping)'s VE ID (2 octets), the receiver's
	VE ID (2 octets), and an encapsulation type (2 octets), formatted as		VE ID (2 octets), and an encapsulation type (2 octets), formatted as
	follows:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Route Distinguisher |		| Route Distinguisher |
	skipping to change at page 16, line 26		skipping to change at page 19, line 26
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender's PE Address |		| Sender's PE Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Remote PE Address |		| Remote PE Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PW Type | AGI Type | AGI Length |		| PW Type | AGI Type | AGI Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ AGI Value ~		~ AGI Value ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AII Type | SAII Length | Value |		| AII Type | SAII Length | SAII Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SAII Value (contd.) ~		~ SAII Value (continued) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AII Type | TAII Length | Value |		| AII Type | TAII Length | TAII Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ TAII Value (contd.) ~		~ TAII Value (continued) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value (cont.)| 0-3 octets of zero padding |		| TAII (cont.) | 0-3 octets of zero padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.2.11. BGP Labeled IPv4 Prefix		3.2.11. BGP Labeled IPv4 Prefix
	BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP		BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP
	labeled IPv4 prefix is encoded in a label stack, the following format		labeled IPv4 prefix is encoded in a label stack, the following format
	is used. The value field consists the IPv4 prefix (with trailing 0		is used. The value field consists the IPv4 prefix (with trailing 0
	bits to make 32 bits in all), and the prefix length, as follows:		bits to make 32 bits in all), and the prefix length, as follows:
	0 1 2 3		0 1 2 3
	skipping to change at page 23, line 13		skipping to change at page 26, line 13
	the next section below for encoding details.		the next section below for encoding details.
	Downstream Label(s)		Downstream Label(s)
	The set of labels in the label stack as it would have appeared if		The set of labels in the label stack as it would have appeared if
	this router were forwarding the packet through this interface. Any		this router were forwarding the packet through this interface. Any
	Implicit Null labels are explicitly included. Labels are treated as		Implicit Null labels are explicitly included. Labels are treated as
	numbers, i.e. they are right justified in the field.		numbers, i.e. they are right justified in the field.
	A Downstream Label is 24 bits, in the same format as an MPLS label		A Downstream Label is 24 bits, in the same format as an MPLS label
	minus the TTL field, i.e., the MSBit of the label is bit 0, the LSbit		minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit
	is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The		is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The
	replying router SHOULD fill in the EXP and S bits; the LSR receiving		replying router SHOULD fill in the EXP and S bits; the LSR receiving
	the echo reply MAY choose to ignore these bits.		the echo reply MAY choose to ignore these bits.
	Protocol		Protocol
	The Protocol is taken from the following table:		The Protocol is taken from the following table:
	Protocol # Signaling Protocol		Protocol # Signaling Protocol
	---------- ------------------		---------- ------------------
	skipping to change at page 26, line 11		skipping to change at page 29, line 11
	the other octets (if any) are ignored. The receiver SHOULD verify		the other octets (if any) are ignored. The receiver SHOULD verify
	that the TLV is received in its entirety, but otherwise ignores the		that the TLV is received in its entirety, but otherwise ignores the
	contents of this TLV, apart from the first octet.		contents of this TLV, apart from the first octet.
	Value Meaning		Value Meaning
	----- -------		----- -------
	1 Drop Pad TLV from reply		1 Drop Pad TLV from reply
	2 Copy Pad TLV to reply		2 Copy Pad TLV to reply
	3-255 Reserved for future use		3-255 Reserved for future use
	3.5. Vendor Enterprise Code		3.5. Vendor Enterprise Number
	The Length is always 4; the value is the SMI Enterprise code, in net-		SMI Private Enterprise Numbers are maintained by IANA. The Length is
	work octet order, of the vendor with a Vendor Private extension to		always 4; the value is the SMI Private Enterprise code, in network
	any of the fields in the fixed part of the message, in which case		octet order, of the vendor with a Vendor Private extension to any of
	this TLV MUST be present. If none of the fields in the fixed part of		the fields in the fixed part of the message, in which case this TLV
	the message have vendor private extensions, inclusion of this this		MUST be present. If none of the fields in the fixed part of the mes-
	TLV in is OPTIONAL. Vendor private ranges for Message Types, Reply		sage have vendor private extensions, inclusion of this this TLV in is
	Modes, and Return Codes have been defined. When any of these are		OPTIONAL. Vendor private ranges for Message Types, Reply Modes, and
	used the Vendor Enterprise Code TLV MUST be included in the message.		Return Codes have been defined. When any of these are used the Ven-
			dor Enterprise Number TLV MUST be included in the message.
	3.6. Interface and Label Stack		3.6. Interface and Label Stack
	The Interface and Label Stack TLV MAY be included in a reply message		The Interface and Label Stack TLV MAY be included in a reply message
	to report the interface on which the request message was received and		to report the interface on which the request message was received and
	the label stack which was on the packet when it was received. Only		the label stack which was on the packet when it was received. Only
	one such object may appear. The purpose of the object is to allow		one such object may appear. The purpose of the object is to allow
	the upstream router to obtain the exact interface and label stack		the upstream router to obtain the exact interface and label stack
	information as it appears at the replying LSR.		information as it appears at the replying LSR.
	skipping to change at page 30, line 34		skipping to change at page 33, line 34
	the LSP ping may forward the MPLS echo request successfully over an		the LSP ping may forward the MPLS echo request successfully over an
	interface not configured to carry MPLS payloads because of the use of		interface not configured to carry MPLS payloads because of the use of
	penultimate hop popping. Since the receiving router has no means to		penultimate hop popping. Since the receiving router has no means to
	differentiate whether the IP packet was sent unlabeled or implicitly		differentiate whether the IP packet was sent unlabeled or implicitly
	labeled, the addition of labels shimmed above the MPLS echo request		labeled, the addition of labels shimmed above the MPLS echo request
	(using the Nil FEC) will prevent a router from forwarding such a		(using the Nil FEC) will prevent a router from forwarding such a
	packet out unlabeled interfaces.		packet out unlabeled interfaces.
	4.3. Sending an MPLS Echo Request		4.3. Sending an MPLS Echo Request
	An MPLS echo request is a (possibly) labeled UDP packet. The IP		An MPLS echo request is a UDP packet. The IP header is set as fol-
	header is set as follows: the source IP address is a routable address		lows: the source IP address is a routable address of the sender; the
	of the sender; the destination IP address is a (randomly chosen)		destination IP address is a (randomly chosen) address from 127/8; the
	address from 127/8; the IP TTL is set to 1. The source UDP port is		IP TTL is set to 1. The source UDP port is chosen by the sender; the
	chosen by the sender; the destination UDP port is set to 3503		destination UDP port is set to 3503 (assigned by IANA for MPLS echo
	(assigned by IANA for MPLS echo requests). The Router Alert option		requests). The Router Alert option MUST be set in the IP header.
	is set in the IP header.
	If the echo request is labeled, one may (depending on what is being		An MPlS Echo Request is sent with a label stack corresponding to the
			FEC stack being tested. Note that further labels could be applied
			if, for example, the normal route to the topmost FEC in the stack is
			via a Traffic Engineered Tunnel [RSVP-TE]. If all of the FECs in the
			stack correspond to Implicit Null Labels the MPLS echo request is
			considered unlabeled even if further labels will be applied in send-
			ing the packet.
			If the echo request is labeled, one MAY (depending on what is being
	pinged) set the TTL of the innermost label to 1, to prevent the ping		pinged) set the TTL of the innermost label to 1, to prevent the ping
	request going farther than it should. Examples of this include ping-		request going farther than it should. Examples of where this SHOULD
	ing a VPN IPv4 or IPv6 prefix, an L2 VPN end point or a pseudowire.		be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN end
	This can also be accomplished by inserting a router alert label above		point or a pseudowire. Preventing the ping request from going to far
	this label; however, this may lead to the undesired side effect that		can also be accomplished by inserting a router alert label above this
	MPLS echo requests take a different data path than actual data.		label; however, this may lead to the undesired side effect that MPLS
			echo requests take a different data path than actual data. For more
			information on how these mechanisms can be used for pseudowire con-
			nectivity verification, see [VCCV].
	In "ping" mode (end-to-end connectivity check), the TTL in the outer-		In "ping" mode (end-to-end connectivity check), the TTL in the outer-
	most label is set to 255. In "traceroute" mode (fault isolation		most label is set to 255. In "traceroute" mode (fault isolation
	mode), the TTL is set successively to 1, 2, ....		mode), the TTL is set successively to 1, 2, ....
	The sender chooses a Sender's Handle, and a Sequence Number. When		The sender chooses a Sender's Handle, and a Sequence Number. When
	sending subsequent MPLS echo requests, the sender SHOULD increment		sending subsequent MPLS echo requests, the sender SHOULD increment
	the sequence number by 1. However, a sender MAY choose to send a		the sequence number by 1. However, a sender MAY choose to send a
	group of echo requests with the same sequence number to improve the		group of echo requests with the same sequence number to improve the
	chance of arrival of at least one packet with that sequence number.		chance of arrival of at least one packet with that sequence number.
	skipping to change at page 31, line 26		skipping to change at page 34, line 35
	microseconds) that the echo request is sent. The TimeStamp Received		microseconds) that the echo request is sent. The TimeStamp Received
	is set to zero.		is set to zero.
	An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode		An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode
	must be set to the desired reply mode; the Return Code and Subcode		must be set to the desired reply mode; the Return Code and Subcode
	are set to zero. In the "traceroute" mode, the echo request SHOULD		are set to zero. In the "traceroute" mode, the echo request SHOULD
	include a Downstream Mapping TLV.		include a Downstream Mapping TLV.
	4.4. Receiving an MPLS Echo Request		4.4. Receiving an MPLS Echo Request
	An LSR X that receives an MPLS echo request first parses the packet		Sending An MPLS Echo Request to the control plane is triggered by
	to ensure that it is a well-formed packet, and that the TLVs that are		one of the following packet processing exceptions: Router Alert
	not marked "Ignore" are understood. If not, X SHOULD send an MPLS		Option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert
	echo reply with the Return Code set to "Malformed echo request		Label, or the destination address in the 127/8 address range. The
	received" or "TLV not understood" (as appropriate), and the Subcode		control plane further identifies it by UDP destination port 3503.
	set to zero. In the latter case, the misunderstood TLVs (only) are
	included in the reply.
	If the echo request is good, X notes the interface I over which the		For reporting purposes the bottom of stack is considered to be
	echo was received, and the label stack with which it came.		stack-depth of 1. This is to establish an absolute reference for
			the case where the actual stack may have more labels than there are
			FECs in the Target FEC Stack.
	For reporting purposes the bottom of stack is considered to be stack-		Further, in all the error codes listed in this document a
	depth of 1. This is to establish an absolute reference for the case		stack-depth of 0 means "no value specified". This allows
	where the stack may have more labels than are in the FEC stack. Fur-		compatibility with existing implementations which do not use the
	ther, in all the error codes listed in this document a stack-depth of		Return Subcode field.
	0 means "no value specified". This allows compatibility with exist-
	ing implementations which do not use the Return Subcode field.
	X employs two variables, called FEC-stack-depth and Label-stack-		An LSR X that receives an MPLS Echo Request then processes it as
	depth. X sets Label-stack-depth to the number of labels in the		follows.
	received label stack. If the label-stack-depth is 0, assume there is
	one implicit null label and set label-stack-depth to 1. FEC-stack-
	depth is used later and need not be initialized. Processing now con-
	tinues with the following steps:
	Label_Validation:		1. General packet sanity is verified. If the packet is not
			well-formed, LSR X SHOULD send an MPLS Echo Reply with the
			Return Code set to "Malformed echo request received" and the
			Subcode to zero. If there are any TLVs not marked as "Ignore"
			that LSR X does not understand, LSR X SHOULD send an MPLS "TLV
			not understood" (as appropriate), and the Subcode set to
			zero. In the latter case, the misunderstood TLVs (only) are
			included as sub-TLVs in an Errored TLVs TLV in the reply. The
			header fields Sender's Handle, Sequence Number, and Timestamp
			Sent are not examined, but are included in the MPLS Echo Reply
			message.
	If the label at Label-stack-depth is valid, goto Label_Operation.		The algorithm uses the following variables and identifiers:
	If not, set Best-return-code to 11, "No label entry at stack-depth"
	and Best-return-subcode to Label-stack-depth. Goto
	Send_Reply_Packet.
	Label_Operation:		Interface-I: the interface on which the MPLS Echo Request was
			received.
	Switch on label operation.		Stack-R: the label stack on the packet as it was
			received.
	Case: Pop and Continue Processing (Note: this includes		Stack-D: the label stack carried in the Downstream
	Explicit_Null and Router_Alert)		Mapping TLV (not always present)
	If Label-stack-depth is greater than 1, decrement Label-stack-		Label-L: the label from the actual stack currently being
	depth and goto Label_Validation. Otherwise, set FEC-stack-depth		examined. Requires no initialization.
	to 1, set Best-return-code to 3 "Replying router is an egress for
	the FEC at stack depth", set Best-return-subcode to 1 and goto
	Egress_Processing.
	Case: Swap or Pop and Switch based on Popped Label		Label-stack-depth: the depth of label being verified. Initialized
			to the number of labels in the received label
			stack S.
	If the label operation is either swap or pop and switch based on		FEC-stack-depth: depth of the FEC in the Target FEC Stack that
	the popped label, Best-return-code to 8, "Label switched at		should be used to verify the current actual
	stack-depth" and Best-return-subcode to Label-stack-depth.		label. Requires no initialization.
	If a Downstream Mapping TLV is present, a Downstream mapping TLVs		Best-return-code: contains the return code for the Echo Reply
	SHOULD be created for each multipath.		packet as currently best known. As algorithm
			progresses, this code may change depending on
			the results of further checks that it performs.
	Determine the output interface. If it is not valid to forward a		Best-rtn-subcode: similar to Best-return-code, but for the Echo
	labeled packet on this interface, set Best-return-code to Return		Reply Subcode.
	Code 9, "Label switched but no MPLS forwarding at stack-depth"
	and set Best-return-subcode to Label-stack-depth and goto
	Send_Reply_Packet. (Note: this return code is set even if Label-
	stack-depth is one.)
	If no Downstream Mapping TLV is present, or the Downstream IP		FEC-status: result value returned by the FEC Checking
	Address is set to the All-Routers multicast address goto		algorithm described in section 4.4.1.
	Send_Reply_Packet.
	Verify that the IP address, interface address and label stack		/* Save receive context information */
	match the received interface and label stack. If the IP address
	is either 127.0.0.1 or 0::1 bypass the interface check, and set
	Best-return-code to 6, "Upstream Interface Index Unknown". For
	any other error, set Best-return-code to 5, "Downstream Mapping
	Mis-match". For either error, an Interface and Label Stack TLV
	SHOULD be created. If Best-return-code equals 5, goto
	Send_Reply_Packet.
	If the "Validate FEC Stack" flag is not set, goto		2. If the echo request is good, LSR X stores the interface over
	Send_Reply_Packet.		which the echo was received in Interface-I, and the label stack
			with which it came in Stack-R.
	Locate the label at Label-stack-depth in the Downstream Labels by		/* The rest of the algorithm iterates over the labels in Stack-R,
	counting from the bottom of the stack, skipping over, but count-		verifies validity of label values, reports associated label
	ing Implicit Null labels and set FEC-stack-depth to that depth.		switching operations (for traceroute), verifies correspondence
	(Note: If the Downstream Labels contain one or more Implicit Null		between the Stack-R and the Target FEC Stack description in the
	labels, this may be at a depth greater than Label-stack-depth.)		body of the Echo Request, and reports any errors. */
	If the depth of the FEC stack is greater than or equal to FEC-		/* The algorithm iterates as follows. */
	stack-depth, Perform FEC Checking. If FEC-status is 2, set Best-
	return-code to 10, "Mapping for this FEC is not the given label
	at stack-depth".
	If the return code is 1 set Best-return-code to FEC-return-code		3. Label Validation:
	and Best-return-subcode to FEC-stack-depth.
	Goto Send_Reply_Packet.		If Label-stack-depth is 0 {
	Egress_Processing:		/* The LSR needs to report its being a tail-end for the LSP */
	If no Downstream Mapping TLV is present, goto Egress_FEC_Valida-		Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null).
	tion.		Set Best-return-code to 3 ("Replying router is an egress for
			the FEC at stack depth"), set Best-rtn-subcode to the
			value of FEC-stack-depth (1) and go to step 5 (Egress
			Processing).
			}
	Verify that the IP address, interface address and label stack match		/* This step assumes there's always an entry for well-known
	the received interface and label stack. If not, set Best-return-		label values */
	code to 5, "Downstream Mapping Mis-match". A Received Interface
	and Label Stack TLV SHOULD be created. Goto Send_Reply_Packet.
	Egress_FEC_Validation:		Set Label-L to the value extracted from Stack-R at depth
			Label-stack-depth. Lookup Label-L in the Incoming Label Map
			(ILM) to determine if the label has been allocated and an
			operation is associated with it.
	Perform FEC checking. If FEC-status is 1, set Best-return-code		If there is no entry for L {
	to FEC-code and Best-return-subcode to FEC-stack-depth. Goto
			/* Indicates a temporary or permanent label synchronization
			problem the LSR needs to report an error */
			Set Best-return-code to 11 ("No label entry at stack-depth")
			and Best-rtn-subcode to Label-stack-depth. Go to step 7
			(Send Reply Packet).
			}
			Else {
			Retrieve the associated label operation from the
			corresponding NLFE and proceed to step 4 (Label Operation).
			}
			4. Label Operation Check
			If the label operation is "Pop and Continue Processing" {
			/* Includes Explicit Null and Router Alert label cases */
			Iterate to the next label by decrementing Label-stack-depth
			and loop back to step 3 (Label Validation).
			}
			If the label operation is "Swap or Pop and Switch based on Popped
			Label" {
			Set Best-return-code to 8 ("Label switched at stack-depth")
			and Best-rtn-subcode to Label-stack-depth to report transit
			switching.
			If a Downstream Mapping TLV is present in the received Echo
			Request {
			If the IP address in the TLV is 127.0.0.1 or 0::1: {
			Set Best-return-code to 6 ("Upstream Interface Index
			Unknown"). An Interface and Label Stack TLV SHOULD be
			included in the reply and filled with Interface-I and
			Stack-R.
			}
			Else {
			Verify that the IP address, interface address and label
			stack in the Downstream Mapping TLV match Interface-I
			and Stack-R. If there is a mismatch, set
			Best-return-code to 5, "Downstream Mapping Mismatch".
			An Interface and Label Stack TLV SHOULD be included in
			the reply and filled in based on Interface-I and
			Stack-R. Go to step 7 (Send Reply Packet).
			}
			}
			For each available downstream ECMP path {
			Retrieve output interface from the NHLFE entry.
			/* Note: this return code is set even if Label-stack-depth
			is one */
			If the output interface is not MPLS-enabled {
			set Best-return-code to Return Code 9, "Label switched
			but no MPLS forwarding at stack-depth" and set
			Best-rtn-subcode to Label-stack-depth and goto
	Send_Reply_Packet.		Send_Reply_Packet.
			}
	Increment FEC-stack-depth. If FEC-stack-depth is greater than		If a Downstream Mapping TLV is present {
	the number of FECs in the FEC-stack, goto Send_Reply_Packet. If
	FEC-status is 0, increment Label-stack-depth. Goto
	Egress_FEC_Validation.
	Send_Reply_Packet:		A Downstream mapping TLV SHOULD be included in the Echo
			Reply (see section 3.3) filled in with information about
			the current ECMP path.
			}
			}
	Send an MPLS echo reply with a Return Code of Best-return-code,		If no Downstream Mapping TLV is present, or the Downstream IP
	and a Return Subcode of Best-return-subcode. Include any TLVs		Address is set to the ALLROUTERS multicast address,
	created during the above process. The procedures for sending the		Go to step 7 (Send Reply Packet).
	echo reply are found in the next subsection below.
	FEC_Checking:		If the "Validate FEC Stack" flag is not set and the LSR is not
			configured to perform FEC checking by default, go to step 7
			(Send Reply Packet).
	This routine accepts a FEC, Label, and Interface. It returns two		/* Validate the Target FEC Stack in the received Echo Request.
	values, FEC-status and FEC-return-code, both of which are		First determine FEC-stack-depth from the Downstream Mapping
	initialized to 0.		TLV. This is done by walking through Stack-D (the Downstream
			Labels) from the bottom, decrementing the number of labels
			for each non-Implicit Null label, while incrementing
			FEC-stack-depth for each label. If the Downstream Mapping TLV
			contains one or more Implicit Null labels, FEC-stack-depth
			may be greater than Label-stack-depth. To be consistent with
			the above stack-depths, the bottom is considered to entry 1.
			*/
	If the FEC is the Nil FEC, check that Label is either		Set FEC-stack-depth to 0. Set i to Label-stack-depth.
	Explicit_Null or Router_Alert. If so return. Else
	set FEC-return-code to 10, "Mapping for this FEC is not the given
	label at stack-depth". Set FEC-status to 1 and return.
	Check that the label mapping for FEC. If no mapping exists, set		While (i > 0 ) do {
	FEC-return-code to Return 4, "Replying router has no mapping for		++FEC-stack-depth.
	the FEC at stack-depth". Set FEC-status to 1. Return.		if Stack-D[FEC-stack-depth] != 3 (Implicit Null)
			--i.
			}
			If the number of labels in the FEC stack is greater
			than or equal to FEC-stack-depth {
	If the label mapping for FEC is Implicit Null, set FEC-status to		Perform the FEC Checking procedure (see subsection 4.4.1
	2. Goto Check_Protocol.		below).
	If the label mapping for FEC is Label, goto Check_Protocol. Else		If FEC-status is 2 set Best-return-code to 10 ("Mapping
	set FEC-return-code to 10, "Mapping for this FEC is not the given		for this FEC is not the given label at stack-depth").
	label at stack-depth". Set FEC-status to 1 and return.
	Check_Protocol:		If the return code is 1 set Best-return-code to
			FEC-return-code and Best-rtn-subcode to FEC-stack-depth.
			}
	Check what protocol would be used to advertise FEC. If it can be		Go to step 7 (Send Reply Packet).
	determined that no protocol associated with interface I would		}
	have advertised a FEC of that FEC-Type, set FEC-return-code to
	12, "Protocol not associated with interface at FEC stack-depth".		5. Egress Processing:
	Set FEC-status to 1. Return.
			/* These steps are performed by the LSR that identified itself
			as the tail-end LSR for an LSP. */
			If received Echo Request contains no Downstream Mapping TLV, or
			the Downstream IP Address is set to 127.0.0.1 or 0::1:
			Go t0 step 6 (Egress FEC Validation).
			Verify that the IP address, interface address and label stack in
			the Downstream mapping TLV match Interface-I and Stack-R. If
			not, set Best-return-code to 5, "Downstream Mapping
			Mis-match". A Received Interface and Label Stack TLV SHOULD be
			created for the Echo Response packet. Go to step 7 (Send Reply
			Packet).
			6. Egress FEC Validation:
			/* This is a loop for all entries in the Target FEC Stack
			starting with FEC-stack-depth. */
			Perform FEC checking by following the algorithm described in
			subsection 4.4.1 for Label-L and the FEC at FEC-stack-depth.
			Set Best-return-code to FEC-code and Best-rtn-subcode to the
			value in FEC-stack-depth.
			If FEC-status (the result of the check) is 1,
			Go to step 7 (Send Reply Packet).
			/* Iterate to the next FEC entry */
			++FEC-stack-depth.
			If FEC-stack-depth > the number of FECs in the FEC-stack,
			Go to step 7 (Send Reply Packet).
			If FEC-status is 0 {
			++Label-stack-depth.
			If Label-stack-depth > the number of labels in Stack-R,
			Go to step 7 (Send Reply Packet).
			Label-L = extracted label from Stack-R at depth
			Label-stack-depth.
			Loop back to step 6 (Egress FEC Validation).
			}
			7. Send Reply Packet:
			Send an MPLS Echo Reply with a Return Code of Best-return-code,
			and a Return Subcode of Best-rtn-subcode. Include any TLVs
			created during the above process. The procedures for sending
			the Echo Reply are found in subsection 4.4.1.
			4.4.1. FEC Validation
			/* This subsection describes validation of a FEC entry within the
			Target FEC Stack and accepts a FEC, Label-L and Interface-I.
			The algorithm performs the following steps. */
			1. Two return values, FEC-status and FEC-return-code, are initialized
			to 0.
			2. If the FEC is the Nil FEC {
			If Label-L is either Explicit_Null or Router_Alert, return.
			Else {
			Set FEC-return-code to 10 ("Mapping for this FEC is not
			the given label at stack-depth").
			Set FEC-status to 1
			Return.
			}
			}
			3. Check the FEC label mapping that describes how traffic received
			on the LSP is further switched or which application it is
			associated with. If no mapping exists, set FEC-return-code to
			Return 4, "Replying router has no mapping for the FEC at
			stack-depth". Set FEC-status to 1. Return.
			4. If the label mapping for FEC is Implicit Null, set FEC-status to
			2 and proceed to step 5. Otherwise, if the label mapping for FEC
			is Label-L, proceed to step 5. Otherwise, set FEC-return-code to
			10 ("Mapping for this FEC is not the given label at
			stack-depth"), set FEC-status to 1 and return.
			5. This is a protocol check. Check what protocol would be used to
			advertise FEC. If it can be determined that no protocol
			associated with Interface-I would have advertised a FEC of that
			FEC-Type, set FEC-return-code to 12 ("Protocol not associated
			with interface at FEC stack-depth"). Set FEC-status to 1.
			6. Return.
	4.5. Sending an MPLS Echo Reply		4.5. Sending an MPLS Echo Reply
	An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response		An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response
	to an MPLS echo request. The source IP address is a routable address		to an MPLS echo request. The source IP address is a routable address
	of the replier; the source port is the well-known UDP port for LSP		of the replier; the source port is the well-known UDP port for LSP
	ping. The destination IP address and UDP port are copied from the		ping. The destination IP address and UDP port are copied from the
	source IP address and UDP port of the echo request. The IP TTL is		source IP address and UDP port of the echo request. The IP TTL is
	set to 255. If the Reply Mode in the echo request is "Reply via an		set to 255. If the Reply Mode in the echo request is "Reply via an
	IPv4 UDP packet with Router Alert", then the IP header MUST contain		IPv4 UDP packet with Router Alert", then the IP header MUST contain
	skipping to change at page 35, line 36		skipping to change at page 42, line 14
	label, and add Downstream Mapping TLVs for each one to the echo reply		label, and add Downstream Mapping TLVs for each one to the echo reply
	it sends back.		it sends back.
	If the Downstream Mapping TLV contains multipath information requir-		If the Downstream Mapping TLV contains multipath information requir-
	ing more processing than the receiving router is willing to perform,		ing more processing than the receiving router is willing to perform,
	the responding router MAY choose to respond with only a subset of		the responding router MAY choose to respond with only a subset of
	multipaths contained in the echo request Downstream Map. (Note: The		multipaths contained in the echo request Downstream Map. (Note: The
	originator of the echo request MAY send another echo request with the		originator of the echo request MAY send another echo request with the
	multipath information that was not included in the reply.)		multipath information that was not included in the reply.)
			Except in the case of Reply Mode 4, "Reply via application level con-
			trol channel", Echo Replies are always sent in the context of the
			IP/MPLS network.
	4.6. Receiving an MPLS Echo Reply		4.6. Receiving an MPLS Echo Reply
	An LSR X should only receive an MPLS echo reply in response to an		An LSR X should only receive an MPLS echo reply in response to an
	MPLS echo request that it sent. Thus, on receipt of an MPLS echo		MPLS echo request that it sent. Thus, on receipt of an MPLS echo
	reply, X should parse the packet to assure that it is well-formed,		reply, X should parse the packet to assure that it is well-formed,
	then attempt to match up the echo reply with an echo request that it		then attempt to match up the echo reply with an echo request that it
	had previously sent, using the destination UDP port and the Sender's		had previously sent, using the destination UDP port and the Sender's
	Handle. If no match is found, then X jettisons the echo reply; oth-		Handle. If no match is found, then X jettisons the echo reply; oth-
	erwise, it checks the Sequence Number to see if it matches. Gaps in		erwise, it checks the Sequence Number to see if it matches.
	the Sequence Number MAY be logged and SHOULD be counted. Once an
	echo reply is received for a given Sequence Number (for a given UDP
	port and Handle), the Sequence Number for subsequent echo requests
	for that UDP port and Handle SHOULD be incremented.
	If the echo reply contains Downstream Mappings, and X wishes to		If the echo reply contains Downstream Mappings, and X wishes to
	traceroute further, it SHOULD copy the Downstream Mapping(s) into its		traceroute further, it SHOULD copy the Downstream Mapping(s) into its
	next echo request(s) (with TTL incremented by one).		next echo request(s) (with TTL incremented by one).
	4.7. Issue with VPN IPv4 and IPv6 Prefixes		4.7. Issue with VPN IPv4 and IPv6 Prefixes
	Typically, a LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is		Typically, a LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is
	sent with a label stack of depth greater than 1, with the innermost		sent with a label stack of depth greater than 1, with the innermost
	label having a TTL of 1. This is to terminate the ping at the egress		label having a TTL of 1. This is to terminate the ping at the egress
	skipping to change at page 37, line 21		skipping to change at page 43, line 37
	[IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA		[IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA
	Considerations", BCP 26, RFC 2434, October 1998.		Considerations", BCP 26, RFC 2434, October 1998.
	[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.
	[LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding",		[LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding",
	RFC 3032, January 2001.		RFC 3032, January 2001.
			[NTP] Mills, D., "Simple Network Time Protocol (SNTP)
			Version 4 for IPv4, IPv6 and OSI", RFC 2030, October
			1996.
			[RFC1122] Braden, R., "Requirements for Internet Hosts -
			Communication Layers", STD 3, RFC 1122, October 1989.
			[RFC1812] Almquist, P. and F. Kastenholz, "Towards Requirements
			for IP Routers", RFC 1716, November 1994.
			[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
			Virtual Private Network (VPN) Terminology", RFC 4026,
			March 2005.
	Informative References		Informative References
	[BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information		[BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information
	in BGP-4", RFC 3107, May 2001.		in BGP-4", RFC 3107, May 2001.
	[ICMP] Postel, J., "Internet Control Message Protocol",		[ICMP] Postel, J., "Internet Control Message Protocol",
	RFC 792.		RFC 792.
	[LDP] Andersson, L., et al, "LDP Specification", RFC 3036,		[LDP] Andersson, L., et al, "LDP Specification", RFC 3036,
	January 2001.		January 2001.
	skipping to change at page 37, line 43		skipping to change at page 44, line 27
	draft-ietf-l3vpn-rfc2547bis-03.txt, work-in-progress.		draft-ietf-l3vpn-rfc2547bis-03.txt, work-in-progress.
	[PW-CONTROL] Martini, L. et al., "Pseudowire Setup and Maintenance		[PW-CONTROL] Martini, L. et al., "Pseudowire Setup and Maintenance
	using the Label Distribution Protocol",		using the Label Distribution Protocol",
	draft-ietf-pwe3-control-protocol-17.txt,		draft-ietf-pwe3-control-protocol-17.txt,
	work-in-progress.		work-in-progress.
	[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for		[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for
	LSP Tunnels", RFC 3209, December 2001.		LSP Tunnels", RFC 3209, December 2001.
			[VCCV] Nadeau, T. & Aggarwal, R., "Pseudo Wire Virtual
			Circuit Connectivity Verification (VCCV),
			draft-ietf-pwe3-vccv-07.txt, August 2005,
			work-in-progress.
	[VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN		[VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN
	Service", draft-ietf-l2vpn-vpls-bgp-05,		Service", draft-ietf-l2vpn-vpls-bgp-05,
	work-in-progress.		work-in-progress.
	6. Security Considerations		6. Security Considerations
	Overall, the security needs for LSP Ping are are similar to those of		Overall, the security needs for LSP Ping are are similar to those of
	ICMP Ping.		ICMP Ping.
	There are at least two approaches to attacking LSRs using the mecha-		There are at least three approaches to attacking LSRs using the mech-
	nisms defined here. One is a Denial of Service attack, by sending		anisms defined here. One is a Denial of Service attack, by sending
	MPLS echo requests/replies to LSRs and thereby increasing their work-		MPLS echo requests/replies to LSRs and thereby increasing their work-
	load. The other is obfuscating the state of the MPLS data plane		load. The second is obfuscating the state of the MPLS data plane
	liveness by spoofing, hijacking, replaying or otherwise tampering		liveness by spoofing, hijacking, replaying or otherwise tampering
	with MPLS echo requests and replies.		with MPLS echo requests and replies. The third is an unauthorized
			source using an LSP Ping to obtain information about the network.
	To avoid potential Denial of Service attacks, it is RECOMMENDED that		To avoid potential Denial of Service attacks, it is RECOMMENDED that
	implementations regulate the LSP ping traffic going to the control		implementations regulate the LSP ping traffic going to the control
	plane. A rate limiter SHOULD be applied to the well-known UDP port		plane. A rate limiter SHOULD be applied to the well-known UDP port
	defined below.		defined below.
	Replay and spoofing attacks are unlikely to be effective given that		Unsophisticated replay and spoofing attacks involving faking or
	the Sender's Handle and Sequence Number need to be valid. Thus a		replaying MPLS Echo Reply Messages are unlikely to be effective.
	replay would be discarded as the sequence has moved on. A spoof has		These replies would have to match the the Sender's Handle and
	only a small window of opportunity, however an implementation MAY		Sequence Number of an outstanding MPLS Echo Request Message. A non-
	provide a validation on the TimeStamp Sent to limit the window to the		matching replay would be discarded as the sequence has moved on, thus
	resolution of the system clock.		a spoof has only a small window of opportunity. However to provide a
			stronger defence, an implementation MAY also validate the TimeStamp
			Sent by requiring and exact match on this field.
			To protect against unauthorized sources using MPLS Echo Request mes-
			sages to obtain network information, it is RECOMMENDED that implemen-
			tations provides a means of checking the source addresses of MPLS
			Echo Request messages against an access list before accepting the
			message.
	It is not clear how to prevent hijacking (non-delivery) of echo		It is not clear how to prevent hijacking (non-delivery) of echo
	requests or replies; however, if these messages are indeed hijacked,		requests or replies; however, if these messages are indeed hijacked,
	LSP ping will report that the data plane isn't working as it should.		LSP ping will report that the data plane isn't working as it should.
	It doesn't seem vital (at this point) to secure the data carried in		It doesn't seem vital (at this point) to secure the data carried in
	MPLS echo requests and replies, although knowledge of the state of		MPLS echo requests and replies, although knowledge of the state of
	the MPLS data plane may be considered confidential by some. Imple-		the MPLS data plane may be considered confidential by some. Imple-
	mentations SHOULD however provide a means of filtering the addresses		mentations SHOULD however provide a means of filtering the addresses
	to which Echo Reply messages may be sent.		to which Echo Reply messages may be sent.
			Although this document makes special use of 127/8 address, these are
			used only in conjunction with the UDP port 3503. Further these pack-
			ets are only processed by routers. All other hosts MUST treat all
			packets with a destination address in the range 127/8 in accordance
			to RFC1122. Any packet received by a router with a destination
			address in the range 127/8 without a destination UDP port of 3503
			MUST be treated in accordance to RFC1812.
	7. IANA Considerations		7. IANA Considerations
	The TCP and UDP port number 3503 has been allocated by IANA for LSP		The TCP and UDP port number 3503 has been allocated by IANA for LSP
	echo requests and replies.		echo requests and replies.
	The following sections detail the new name spaces to be managed by		The following sections detail the new name spaces to be managed by
	IANA. For each of these name spaces, the space is divided into		IANA. For each of these name spaces, the space is divided into
	assignment ranges; the following terms are used in describing the		assignment ranges; the following terms are used in describing the
	procedures by which IANA allocates values: "Standards Action" (as		procedures by which IANA allocates values: "Standards Action" (as
	defined in [IANA]); "Expert Review" and "Vendor Private Use".		defined in [IANA]); "Specification Required" and "Vendor Private
			Use".
	Values from "Expert Review" ranges MUST be registered with IANA. The		Values from "Specification Required" ranges MUST be registered with
	request MUST be made via an Experimental RFC that describes the		IANA. The request MUST be made via an Experimental RFC that
	format and procedures for using the code point; the actual assignment		describes the format and procedures for using the code point; the
	is made during the IANA actions for the RFC.		actual assignment is made during the IANA actions for the RFC.
	Values from "Vendor Private" ranges MUST NOT be registered with IANA;		Values from "Vendor Private" ranges MUST NOT be registered with IANA;
	however, the message MUST contain an enterprise code as registered		however, the message MUST contain an enterprise code as registered
	with the IANA SMI Network Management Private Enterprise Codes. For		with the IANA SMI Private Network Management Private Enterprise Num-
	each name space that has a Vendor Private range, it must be specified		bers. For each name space that has a Vendor Private range, it must
	where exactly the SMI Enterprise Code resides; see below for exam-		be specified where exactly the SMI Private Enterprise Number resides;
	ples. In this way, several enterprises (vendors) can use the same		see below for examples. In this way, several enterprises (vendors)
	code point without fear of collision.		can use the same code point without fear of collision.
	7.1. Message Types, Reply Modes, Return Codes		7.1. Message Types, Reply Modes, Return Codes
	It is requested that IANA maintain registries for Message Types,		It is requested that IANA maintain registries for Message Types,
	Reply Modes, and Return Codes. Each of these can take values in the		Reply Modes, and Return Codes. Each of these can take values in the
	range 0-255. Assignments in the range 0-191 are via Standards		range 0-255. Assignments in the range 0-191 are via Standards
	Action; assignments in the range 192-251 are made via Expert Review;		Action; assignments in the range 192-251 are made via "Specification
	values in the range 252-255 are for Vendor Private Use, and MUST NOT		Required"; values in the range 252-255 are for Vendor Private Use,
	be allocated.		and MUST NOT be allocated.
	If any of these fields fall in the Vendor Private range, a top-level		If any of these fields fall in the Vendor Private range, a top-level
	Vendor Enterprise Code TLV MUST be present in the message.		Vendor Enterprise Number TLV MUST be present in the message.
	Message Types defined in this document are:		Message Types defined in this document are:
	Value Meaning		Value Meaning
	----- -------		----- -------
	1 MPLS Echo Request		1 MPLS Echo Request
	2 MPLS Echo Reply		2 MPLS Echo Reply
	Reply Modes defined in this document are:		Reply Modes defined in this document are:
	skipping to change at page 40, line 15		skipping to change at page 47, line 15
	7.2. TLVs		7.2. TLVs
	It is requested that IANA maintain a registry for the Type field of		It is requested that IANA maintain a registry for the Type field of
	top-level TLVs as well as for any associated sub-TLVs. Note the		top-level TLVs as well as for any associated sub-TLVs. Note the
	meaning of a sub-TLV is scoped by the TLV. The number spaces for the		meaning of a sub-TLV is scoped by the TLV. The number spaces for the
	sub-TLVs of various TLVs are independent.		sub-TLVs of various TLVs are independent.
	The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the		The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the
	range 0-16383 and 32768-49161 are made via Standards Action as		range 0-16383 and 32768-49161 are made via Standards Action as
	defined in [IANA]; assignments in the range 16384-31743 and		defined in [IANA]; assignments in the range 16384-31743 and
	49162-64511 are made via Expert Review as defined above; values in		49162-64511 are made via "Specification Required" as defined above;
	the range 31744-32767 and 64512-65535 are for Vendor Private Use, and		values in the range 31744-32767 and 64512-65535 are for Vendor Pri-
	MUST NOT be allocated.		vate Use, and MUST NOT be allocated.
	If a TLV or sub-TLV has a Type that falls in the range for Vendor		If a TLV or sub-TLV has a Type that falls in the range for Vendor
	Private Use, the Length MUST be at least 4, and the first four octets		Private Use, the Length MUST be at least 4, and the first four octets
	MUST be that vendor's SMI Enterprise Code, in network octet order.		MUST be that vendor's SMI Private Enterprise Number, in network octet
	The rest of the Value field is private to the vendor.		order. The rest of the Value field is private to the vendor.
	TLVs and sub-TLVs defined in this document are:		TLVs and sub-TLVs defined in this document are:
	Type Sub-Type Value Field		Type Sub-Type Value Field
	---- -------- -----------		---- -------- -----------
	1 Target FEC Stack		1 Target FEC Stack
	1 LDP IPv4 prefix		1 LDP IPv4 prefix
	2 LDP IPv6 prefix		2 LDP IPv6 prefix
	3 RSVP IPv4 LSP		3 RSVP IPv4 LSP
	4 RSVP IPv6 LSP		4 RSVP IPv6 LSP
	skipping to change at page 40, line 48		skipping to change at page 47, line 48
	10 "FEC 128" Pseudowire		10 "FEC 128" Pseudowire
	11 "FEC 129" Pseudowire		11 "FEC 129" Pseudowire
	12 BGP labeled IPv4 prefix		12 BGP labeled IPv4 prefix
	13 BGP labeled IPv6 prefix		13 BGP labeled IPv6 prefix
	14 Generic IPv4 prefix		14 Generic IPv4 prefix
	15 Generic IPv6 prefix		15 Generic IPv6 prefix
	16 Nil FEC		16 Nil FEC
	2 Downstream Mapping		2 Downstream Mapping
	3 Pad		3 Pad
	4 Not Assigned		4 Not Assigned
	5 Vendor Enterprise Code		5 Vendor Enterprise Number
	6 Not Assigned		6 Not Assigned
	7 Interface and Label Stack		7 Interface and Label Stack
	8 Not Assigned		8 Not Assigned
	9 Errored TLVs		9 Errored TLVs
	Any value The TLV not understood		Any value The TLV not understood
	10 Reply TOS Byte		10 Reply TOS Byte
	8. Acknowledgments		8. Acknowledgments
	This document is the outcome of many discussions among many people,		This document is the outcome of many discussions among many people,
	skipping to change at page 42, line 28		skipping to change at page 49, line 28
	Email: swallow@cisco.com		Email: swallow@cisco.com
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Expiration Date		Expiration Date
	May 2006		June 2006
	Disclaimer of Validity		Disclaimer of Validity
	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 AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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. 79 change blocks.
	238 lines changed or deleted		527 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/