draft-ietf-mpls-rfc3036bis-02.txt		draft-ietf-mpls-rfc3036bis-03.txt
	Network Working Group Loa Andersson		Network Working Group Loa Andersson
	Internet Draft Ina Minei		Internet Draft Ina Minei
	Expiration Date: January 2006 Bob Thomas		Expiration Date: April 2006 Bob Thomas
	Editors		Editors
	July 2005		October 2005
	LDP Specification		LDP Specification
	draft-ietf-mpls-rfc3036bis-02.txt		draft-ietf-mpls-rfc3036bis-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 other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 2, line 8		skipping to change at page 2, line 8
	This document is produced as part of advancing the LDP specification		This document is produced as part of advancing the LDP specification
	to draft standard status. The LDP specification was originally		to draft standard status. The LDP specification was originally
	published as RFC 3036 in January 2001. It was produced by the MPLS		published as RFC 3036 in January 2001. It was produced by the MPLS
	working of the IETF and was jointly authored by Loa Andersson, Paul		working of the IETF and was jointly authored by Loa Andersson, Paul
	Doolan, Nancy Feldman, Andre Fredette and Bob Thomas.		Doolan, Nancy Feldman, Andre Fredette and Bob Thomas.
	Abstract		Abstract
	The architecture for Multi Protocol Label Switching (MPLS) is		The architecture for Multi Protocol Label Switching (MPLS) is
	described in RFC 3031. A fundamental concept in MPLS is that two		described in RFC 3031 [RFC3031]. A fundamental concept in MPLS is
	Label Switching Routers (LSRs) must agree on the meaning of the		that two Label Switching Routers (LSRs) must agree on the meaning of
	labels used to forward traffic between and through them. This common		the labels used to forward traffic between and through them. This
	understanding is achieved by using a set of procedures, called a		common understanding is achieved by using a set of procedures, called
	label distribution protocol, by which one LSR informs another of		a label distribution protocol, by which one LSR informs another of
	label bindings it has made. This document defines a set of such		label bindings it has made. This document defines a set of such
	procedures called LDP (for Label Distribution Protocol) by which LSRs		procedures called LDP (for Label Distribution Protocol) by which LSRs
	distribute labels to support MPLS forwarding along normally routed		distribute labels to support MPLS forwarding along normally routed
	paths.		paths.
	Table of Contents		Table of Contents
	Source of this document ............................... 1		Source of this document ............................... 1
	1 LDP Overview .......................................... 7		1 LDP Overview .......................................... 7
	1.1 LDP Peers ............................................. 8		1.1 LDP Peers ............................................. 8
	skipping to change at page 18, line 15		skipping to change at page 18, line 15
	c. If LSR1 receives a KeepAlive message, LSR2 has accepted its		c. If LSR1 receives a KeepAlive message, LSR2 has accepted its
	proposed session parameters.		proposed session parameters.
	d. When LSR1 has received both an acceptable Initialization		d. When LSR1 has received both an acceptable Initialization
	message and a KeepAlive message the session is operational		message and a KeepAlive message the session is operational
	from LSR1's point of view.		from LSR1's point of view.
	Until the LDP session is established, no other messages		Until the LDP session is established, no other messages
	except those listed in the procedures above may be		except those listed in the procedures above may be
	exchanged, and the rules for processing the U-bit in LDP		exchanged, and the rules for processing the U-bit in LDP
	messages are overridden.		messages are overridden. If a message other than those
			listed in the procedures above is received, a Shutdown msg
			MUST be tranmitted and the transport connection MUST be
			closed.
	It is possible for a pair of incompatibly configured LSRs that		It is possible for a pair of incompatibly configured LSRs that
	disagree on session parameters to engage in an endless sequence		disagree on session parameters to engage in an endless sequence
	of messages as each NAKs the other's Initialization messages with		of messages as each NAKs the other's Initialization messages with
	Error Notification messages.		Error Notification messages.
	An LSR must throttle its session setup retry attempts with an		An LSR MUST throttle its session setup retry attempts with an
	exponential backoff in situations where Initialization messages		exponential backoff in situations where Initialization messages
	are being NAK'd. It is also recommended that an LSR detecting		are being NAK'd. It is also recommended that an LSR detecting
	such a situation take action to notify an operator.		such a situation take action to notify an operator.
	The session establishment setup attempt following a NAK'd Ini-		The session establishment setup attempt following a NAK'd Ini-
	tialization message must be delayed no less than 15 seconds, and		tialization message must be delayed no less than 15 seconds, and
	subsequent delays must grow to a maximum delay of no less than 2		subsequent delays must grow to a maximum delay of no less than 2
	minutes. The specific session establishment action that must be		minutes. The specific session establishment action that must be
	delayed is the attempt to open the session transport connection		delayed is the attempt to open the session transport connection
	by the LSR playing the active role.		by the LSR playing the active role.
	skipping to change at page 34, line 30		skipping to change at page 34, line 30
	| |		| |
	| Value |		| Value |
	~ ~		~ ~
	| |		| |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	U bit		U bit
	Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear		Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
	(=0), a notification must be returned to the message originator		(=0), a notification MUST be returned to the message originator
	and the entire message must be ignored; if U is set (=1), the		and the entire message MUST be ignored; if U is set (=1), the
	unknown TLV is silently ignored and the rest of the message is		unknown TLV MUST be silently ignored and the rest of the message
	processed as if the unknown TLV did not exist. The sections fol-		processed as if the unknown TLV did not exist. The sections fol-
	lowing that define TLVs specify a value for the U-bit.		lowing that define TLVs specify a value for the U-bit.
	F bit		F bit
	Forward unknown TLV bit. This bit applies only when the U bit is		Forward unknown TLV bit. This bit applies only when the U bit is
	set and the LDP message containing the unknown TLV is to be for-		set and the LDP message containing the unknown TLV is to be for-
	warded. If F is clear (=0), the unknown TLV is not forwarded with		warded. If F is clear (=0), the unknown TLV is not forwarded with
	the containing message; if F is set (=1), the unknown TLV is for-		the containing message; if F is set (=1), the unknown TLV is for-
	warded with the containing message. The sections following that		warded with the containing message. The sections following that
	define TLVs specify a value for the F-bit. By setting both the U		define TLVs specify a value for the F-bit. By setting both the U
	skipping to change at page 37, line 37		skipping to change at page 37, line 37
	this case the Prefix itself is zero octets).		this case the Prefix itself is zero octets).
	Prefix		Prefix
	An address prefix encoded according to the Address Family		An address prefix encoded according to the Address Family
	field, whose length, in bits, was specified in the PreLen		field, whose length, in bits, was specified in the PreLen
	field, padded to a byte boundary.		field, padded to a byte boundary.
	3.4.1.1. FEC Procedures		3.4.1.1. FEC Procedures
	If in decoding a FEC TLV an LSR encounters a FEC Element with an		If in decoding a FEC TLV an LSR encounters a FEC Element with an
	Address Family it does not support, it should stop decoding the FEC		Address Family it does not support, it SHOULD stop decoding the FEC
	TLV, abort processing the message containing the TLV, and send an		TLV, abort processing the message containing the TLV, and send an
	"Unsupported Address Family" Notification message to its LDP peer		"Unsupported Address Family" Notification message to its LDP peer
	signaling an error.		signaling an error.
	If it encounters a FEC Element type it cannot decode, it should stop		If it encounters a FEC Element type it cannot decode, it SHOULD stop
	decoding the FEC TLV, abort processing the message containing the		decoding the FEC TLV, abort processing the message containing the
	TLV, and send an "Unknown FEC" Notification message to its LDP peer		TLV, and send an "Unknown FEC" Notification message to its LDP peer
	signaling an error.		signaling an error.
	3.4.2. Label TLVs		3.4.2. Label TLVs
	Label TLVs encode labels. Label TLVs are carried by the messages		Label TLVs encode labels. Label TLVs are carried by the messages
	used to advertise, request, release and withdraw label mappings.		used to advertise, request, release and withdraw label mappings.
	There are several different kinds of Label TLVs which can appear in		There are several different kinds of Label TLVs which can appear in
	skipping to change at page 38, line 44		skipping to change at page 38, line 44
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| ATM Label (0x0201) | Length |		|0|0| ATM Label (0x0201) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Res| V | VPI | VCI |		|Res| V | VPI | VCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Res		Res
	This field is reserved. It must be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and must be ignored on receipt.		and MUST be ignored on receipt.
	V-bits		V-bits
	Two-bit switching indicator. If V-bits is 00, both the VPI and		Two-bit switching indicator. If V-bits is 00, both the VPI and
	VCI are significant. If V-bits is 01, only the VPI field is sig-		VCI are significant. If V-bits is 01, only the VPI field is sig-
	nificant. If V-bit is 10, only the VCI is significant.		nificant. If V-bit is 10, only the VCI is significant.
	VPI		VPI
	Virtual Path Identifier. If VPI is less than 12-bits it should be		Virtual Path Identifier. If VPI is less than 12-bits it SHOULD be
	right justified in this field and preceding bits should be set to		right justified in this field and preceding bits SHOULD be set to
	0.		0.
	VCI		VCI
	Virtual Channel Identifier. If the VCI is less than 16- bits, it		Virtual Channel Identifier. If the VCI is less than 16- bits, it
	should be right justified in the field and the preceding bits must		SHOULD be right justified in the field and the preceding bits MUST
	be set to 0. If Virtual Path switching is indicated in the V-bits		be set to 0. If Virtual Path switching is indicated in the V-bits
	field, then this field must be ignored by the receiver and set to		field, then this field MUST be ignored by the receiver and set to
	0 by the sender.		0 by the sender.
	3.4.2.3. Frame Relay Label TLV		3.4.2.3. Frame Relay Label TLV
	An LSR uses Frame Relay Label TLVs to encode labels for use on Frame		An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
	Relay links.		Relay links.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Frame Relay Label (0x0202)| Length |		|0|0| Frame Relay Label (0x0202)| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |Len| DLCI |		| Reserved |Len| DLCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Res		Res
	This field is reserved. It must be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and must be ignored on receipt.		and MUST be ignored on receipt.
	Len		Len
	This field specifies the number of bits of the DLCI. The follow-		This field specifies the number of bits of the DLCI. The follow-
	ing values are supported:		ing values are supported:
	0 = 10 bits DLCI		0 = 10 bits DLCI
	2 = 23 bits DLCI		2 = 23 bits DLCI
	Len values 1 and 3 are reserved.		Len values 1 and 3 are reserved.
	skipping to change at page 41, line 20		skipping to change at page 41, line 20
	| HC Value |		| HC Value |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	HC Value		HC Value
	1 octet unsigned integer hop count value.		1 octet unsigned integer hop count value.
	3.4.4.1. Hop Count Procedures		3.4.4.1. Hop Count Procedures
	During setup of an LSP an LSR R may receive a Label Mapping or Label		During setup of an LSP an LSR R may receive a Label Mapping or Label
	Request message for the LSP that contains the Hop Count TLV. If it		Request message for the LSP that contains the Hop Count TLV. If it
	does, it should record the hop count value.		does, it SHOULD record the hop count value.
	If LSR R then propagates the Label Mapping message for the LSP to an		If LSR R then propagates the Label Mapping message for the LSP to an
	upstream peer or the Label Request message to a downstream peer to		upstream peer or the Label Request message to a downstream peer to
	continue the LSP setup, it must must determine a hop count to include		continue the LSP setup, it must determine a hop count to include in
	in the propagated message as follows:		the propagated message as follows:
	- If the message is a Label Request message, R must increment the		- If the message is a Label Request message, R MUST increment the
	received hop count;		received hop count;
	- If the message is a Label Mapping message, R determines the hop		- If the message is a Label Mapping message, R determines the hop
	count as follows:		count as follows:
	o If R is a member of the edge set of an LSR domain whose LSRs do		o If R is a member of the edge set of an LSR domain whose LSRs do
	not perform 'TTL-decrement' and the upstream peer is within		not perform 'TTL-decrement' and the upstream peer is within
	that domain, R must reset the hop count to 1 before propagating		that domain, R MUST reset the hop count to 1 before propagating
	the message.		the message.
	o Otherwise, R must increment the received hop count.		o Otherwise, R MUST increment the received hop count.
	The first LSR in the LSP (ingress for a Label Request message, egress		The first LSR in the LSP (ingress for a Label Request message, egress
	for a Label Mapping message) should set the hop count value to 1.		for a Label Mapping message) SHOULD set the hop count value to 1.
	By convention a value of 0 indicates an unknown hop count. The		By convention a value of 0 indicates an unknown hop count. The
	result of incrementing an unknown hop count is itself an unknown hop		result of incrementing an unknown hop count is itself an unknown hop
	count (0).		count (0).
	Use of the unknown hop count value greatly reduces the signaling		Use of the unknown hop count value greatly reduces the signaling
	overhead when independent control is used. When a new LSP is estab-		overhead when independent control is used. When a new LSP is estab-
	lished, each LSR starts with unknown hop count. Addition of a new		lished, each LSR starts with unknown hop count. Addition of a new
	LSR whose hop count is also unknown does not cause a hop count update		LSR whose hop count is also unknown does not cause a hop count update
	to be propagated upstream since the hop count remains unknown. When		to be propagated upstream since the hop count remains unknown. When
	skipping to change at page 42, line 20		skipping to change at page 42, line 20
	These updates are useless overhead since they don't reflect the hop		These updates are useless overhead since they don't reflect the hop
	count to the egress.		count to the egress.
	>From the perspective of the ingress node, the fact that the hop		>From the perspective of the ingress node, the fact that the hop
	count is unknown implies nothing about whether a packet sent on the		count is unknown implies nothing about whether a packet sent on the
	LSP will actually make it to the egress. All it implies is that the		LSP will actually make it to the egress. All it implies is that the
	hop count update from the egress has not yet reached the ingress.		hop count update from the egress has not yet reached the ingress.
	If an LSR receives a message containing a Hop Count TLV, it must		If an LSR receives a message containing a Hop Count TLV, it must
	check the hop count value to determine whether the hop count has		check the hop count value to determine whether the hop count has
	exceeded its configured maximum allowable value. If so, it must		exceeded its configured maximum allowable value. If so, it MUST
	behave as if the containing message has traversed a loop by sending a		behave as if the containing message has traversed a loop by sending a
	Notification message signaling Loop Detected in reply to the sender		Notification message signaling Loop Detected in reply to the sender
	of the message.		of the message.
	If Loop Detection is configured, the LSR must follow the procedures		If Loop Detection is configured, the LSR MUST follow the procedures
	specified in Section "Loop Detection".		specified in Section "Loop Detection".
	3.4.5. Path Vector TLV		3.4.5. Path Vector TLV
	The Path Vector TLV is used with the Hop Count TLV in Label Request		The Path Vector TLV is used with the Hop Count TLV in Label Request
	and Label Mapping messages to implement the optional LDP loop detec-		and Label Mapping messages to implement the optional LDP loop detec-
	tion mechanism. See Section "Loop Detection". Its use in the Label		tion mechanism. See Section "Loop Detection". Its use in the Label
	Request message records the path of LSRs the request has traversed.		Request message records the path of LSRs the request has traversed.
	Its use in the Label Mapping message records the path of LSRs a label		Its use in the Label Mapping message records the path of LSRs a label
	advertisement has traversed to setup an LSP. Its encoding is:		advertisement has traversed to setup an LSP. Its encoding is:
	skipping to change at page 43, line 21		skipping to change at page 43, line 21
	3.4.5.1. Path Vector Procedures		3.4.5.1. Path Vector Procedures
	The Path Vector TLV is carried in Label Mapping and Label Request		The Path Vector TLV is carried in Label Mapping and Label Request
	messages when loop detection is configured.		messages when loop detection is configured.
	3.4.5.1.1. Label Request Path Vector		3.4.5.1.1. Label Request Path Vector
	Section "Loop Detection" specifies situations when an LSR must		Section "Loop Detection" specifies situations when an LSR must
	include a Path Vector TLV in a Label Request message.		include a Path Vector TLV in a Label Request message.
	An LSR that receives a Path Vector in a Label Request message must		An LSR that receives a Path Vector in a Label Request message MUST
	perform the procedures described in Section "Loop Detection".		perform the procedures described in Section "Loop Detection".
	If the LSR detects a loop, it must reject the Label Request message.		If the LSR detects a loop, it MUST reject the Label Request message.
	The LSR must:		The LSR MUST:
	1. Transmit a Notification message to the sending LSR signaling		1. Transmit a Notification message to the sending LSR signaling
	"Loop Detected".		"Loop Detected".
	2. Not propagate the Label Request message further.		2. Not propagate the Label Request message further.
	Note that a Label Request message with Path Vector TLV is forwarded		Note that a Label Request message with Path Vector TLV is forwarded
	until:		until:
	1. A loop is found,		1. A loop is found,
	skipping to change at page 43, line 48		skipping to change at page 43, line 48
	2. The LSP egress is reached,		2. The LSP egress is reached,
	3. The maximum Path Vector limit or maximum Hop Count limit is		3. The maximum Path Vector limit or maximum Hop Count limit is
	reached. This is treated as if a loop had been detected.		reached. This is treated as if a loop had been detected.
	3.4.5.1.2. Label Mapping Path Vector		3.4.5.1.2. Label Mapping Path Vector
	Section "Loop Detection" specifies the situations when an LSR must		Section "Loop Detection" specifies the situations when an LSR must
	include a Path Vector TLV in a Label Mapping message.		include a Path Vector TLV in a Label Mapping message.
	An LSR that receives a Path Vector in a Label Mapping message must		An LSR that receives a Path Vector in a Label Mapping message MUST
	perform the procedures described in Section "Loop Detection".		perform the procedures described in Section "Loop Detection".
	If the LSR detects a loop, it must reject the Label Mapping message		If the LSR detects a loop, it MUST reject the Label Mapping message
	in order to prevent a forwarding loop. The LSR must:		in order to prevent a forwarding loop. The LSR MUST:
	1. Transmit a Label Release message carrying a Status TLV to the		1. Transmit a Label Release message carrying a Status TLV to the
	sending LSR to signal "Loop Detected".		sending LSR to signal "Loop Detected".
	2. Not propagate the message further.		2. Not propagate the message further.
	3. Check whether the Label Mapping message is for an existing LSP.		3. Check whether the Label Mapping message is for an existing LSP.
	If so, the LSR must unsplice any upstream labels which are		If so, the LSR must unsplice any upstream labels which are
	spliced to the downstream label for the FEC.		spliced to the downstream label for the FEC.
	skipping to change at page 44, line 48		skipping to change at page 44, line 48
	|U|F| Status (0x0300) | Length |		|U|F| Status (0x0300) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Status Code |		| Status Code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message ID |		| Message ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Type |		| Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	U bit		U bit
	Should be 0 when the Status TLV is sent in a Notification message.		SHOULD be 0 when the Status TLV is sent in a Notification message.
	Should be 1 when the Status TLV is sent in some other message.		SHOULD be 1 when the Status TLV is sent in some other message.
	F bit		F bit
	Should be the same as the setting of the F-bit in the Status Code		SHOULD be the same as the setting of the F-bit in the Status Code
	field.		field.
	Status Code		Status Code
	32-bit unsigned integer encoding the event being signaled. The		32-bit unsigned integer encoding the event being signaled. The
	structure of a Status Code is:		structure of a Status Code is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|E|F| Status Data |		|E|F| Status Data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E bit		E bit
	Fatal error bit. If set (=1), this is a fatal error notifica-		Fatal error bit. If set (=1), this is a fatal error notifica-
	tion. If clear (=0), this is an advisory notification.		tion. If clear (=0), this is an advisory notification.
	F bit		F bit
	Forward bit. If set (=1), the notification should be forwarded		Forward bit. If set (=1), the notification SHOULD be forwarded
	to the LSR for the next-hop or previous-hop for the LSP, if		to the LSR for the next-hop or previous-hop for the LSP, if
	any, associated with the event being signaled. If clear (=0),		any, associated with the event being signaled. If clear (=0),
	the notification should not be forwarded.		the notification SHOULD NOT be forwarded.
	Status Data		Status Data
	30-bit unsigned integer which specifies the status information.		30-bit unsigned integer which specifies the status information.
	This specification defines Status Codes (32-bit unsigned integers		This specification defines Status Codes (32-bit unsigned integers
	with the above encoding).		with the above encoding).
	A Status Code of 0 signals success.		A Status Code of 0 signals success.
	Message ID		Message ID
	skipping to change at page 45, line 50		skipping to change at page 45, line 50
	being identified.		being identified.
	Message Type		Message Type
	If non-zero, the type of the peer message to which the Status TLV		If non-zero, the type of the peer message to which the Status TLV
	refers. If zero, the Status TLV does not refer to any specific		refers. If zero, the Status TLV does not refer to any specific
	message type.		message type.
	Note that use of the Status TLV is not limited to Notification mes-		Note that use of the Status TLV is not limited to Notification mes-
	sages. A message other than a Notification message may carry a Sta-		sages. A message other than a Notification message may carry a Sta-
	tus TLV as an Optional Parameter. When a message other than a Noti-		tus TLV as an Optional Parameter. When a message other than a Noti-
	fication carries a Status TLV the U-bit of the Status TLV should be		fication carries a Status TLV the U-bit of the Status TLV SHOULD be
	set to 1 to indicate that the receiver should silently discard the		set to 1 to indicate that the receiver SHOULD silently discard the
	TLV if unprepared to handle it.		TLV if unprepared to handle it.
	3.5. LDP Messages		3.5. LDP Messages
	All LDP messages have the following format:		All LDP messages 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U| Message Type | Message Length |		|U| Message Type | Message Length |
	skipping to change at page 46, line 47		skipping to change at page 46, line 47
	Identifies the type of message		Identifies the type of message
	Message Length		Message Length
	Specifies the cumulative length in octets of the Message ID,		Specifies the cumulative length in octets of the Message ID,
	Mandatory Parameters, and Optional Parameters.		Mandatory Parameters, and Optional Parameters.
	Message ID		Message ID
	32-bit value used to identify this message. Used by the sending		32-bit value used to identify this message. Used by the sending
	LSR to facilitate identifying notification messages that may apply		LSR to facilitate identifying notification messages that may apply
	to this message. An LSR sending a notification message in		to this message. An LSR sending a notification message in
	response to this message should include this Message Id in the		response to this message SHOULD include this Message Id in the
	Status TLV carried by the notification message; see Section "Noti-		Status TLV carried by the notification message; see Section "Noti-
	fication Message".		fication Message".
	Mandatory Parameters		Mandatory Parameters
	Variable length set of required message parameters. Some messages		Variable length set of required message parameters. Some messages
	have no required parameters.		have no required parameters.
	For messages that have required parameters, the required parame-		For messages that have required parameters, the required parame-
	ters MUST appear in the order specified by the individual message		ters MUST appear in the order specified by the individual message
	specifications in the sections that follow.		specifications in the sections that follow.
	skipping to change at page 49, line 28		skipping to change at page 49, line 28
	3.5.1.1. Notification Message Procedures		3.5.1.1. Notification Message Procedures
	If an LSR encounters a condition requiring it to notify its peer with		If an LSR encounters a condition requiring it to notify its peer with
	advisory or error information it sends the peer a Notification mes-		advisory or error information it sends the peer a Notification mes-
	sage containing a Status TLV that encodes the information and option-		sage containing a Status TLV that encodes the information and option-
	ally additional TLVs that provide more information about the condi-		ally additional TLVs that provide more information about the condi-
	tion.		tion.
	If the condition is one that is a fatal error the Status Code carried		If the condition is one that is a fatal error the Status Code carried
	in the notification will indicate that. In this case, after sending		in the notification will indicate that. In this case, after sending
	the Notification message the LSR should terminate the LDP session by		the Notification message the LSR SHOULD terminate the LDP session by
	closing the session TCP connection and discard all state associated		closing the session TCP connection and discard all state associated
	with the session, including all label-FEC bindings learned via the		with the session, including all label-FEC bindings learned via the
	session.		session.
	When an LSR receives a Notification message that carries a Status		When an LSR receives a Notification message that carries a Status
	Code that indicates a fatal error, it should terminate the LDP ses-		Code that indicates a fatal error, it SHOULD terminate the LDP ses-
	sion immediately by closing the session TCP connection and discard		sion immediately by closing the session TCP connection and discard
	all state associated with the session, including all label-FEC bind-		all state associated with the session, including all label-FEC bind-
	ings learned via the session.		ings learned via the session.
	The above statement does not apply to the processing of the shutdown		The above statement does not apply to the processing of the Shutdown
	message in the session initialization procedure. When an LSR receives		message in the session initialization procedure. When an LSR receives
	a shutdown message during session initialization, it should transmit		a Shutdown message during session initialization, it SHOULD transmit
	a shutdown message and then close the transport connection.		a Shutdown message and then close the transport connection.
	3.5.1.2. Events Signaled by Notification Messages		3.5.1.2. Events Signaled by Notification Messages
	It is useful for descriptive purpose to classify events signaled by		It is useful for descriptive purpose to classify events signaled by
	Notification Messages into the following categories.		Notification Messages into the following categories.
	3.5.1.2.1. Malformed PDU or Message		3.5.1.2.1. Malformed PDU or Message
	Malformed LDP PDUs or Messages that are part of the LDP Discovery		Malformed LDP PDUs or Messages that are part of the LDP Discovery
	mechanism are handled by silently discarding them.		mechanism are handled by silently discarding them.
	skipping to change at page 53, line 49		skipping to change at page 53, line 49
	request.		request.
	An LSR initiating Extended Discovery sets R to 1. If R is 1,		An LSR initiating Extended Discovery sets R to 1. If R is 1,
	the receiving LSR checks whether it has been configured to send		the receiving LSR checks whether it has been configured to send
	Targeted Hellos to the Hello source in response to Hellos with		Targeted Hellos to the Hello source in response to Hellos with
	this request. If not, it ignores the request. If so, it ini-		this request. If not, it ignores the request. If so, it ini-
	tiates periodic transmission of Targeted Hellos to the Hello		tiates periodic transmission of Targeted Hellos to the Hello
	source.		source.
	Reserved		Reserved
	This field is reserved. It must be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and ignored on receipt.		and ignored on receipt.
	Optional Parameters		Optional Parameters
	This variable length field contains 0 or more parameters, each		This variable length field contains 0 or more parameters, each
	encoded as a TLV. The optional parameters defined by this ver-		encoded as a TLV. The optional parameters defined by this ver-
	sion of the protocol are		sion of the protocol are
	Optional Parameter Type Length Value		Optional Parameter Type Length Value
	IPv4 Transport Address 0x0401 4 See below		IPv4 Transport Address 0x0401 4 See below
	Configuration 0x0402 4 See below		Configuration 0x0402 4 See below
	Sequence Number		Sequence Number
	IPv6 Transport Address 0x0403 16 See below		IPv6 Transport Address 0x0403 16 See below
	IPv4 Transport Address		IPv4 Transport Address
	Specifies the IPv4 address to be used for the sending LSR when		Specifies the IPv4 address to be used for the sending LSR when
	opening the LDP session TCP connection. If this optional TLV		opening the LDP session TCP connection. If this optional TLV
	is not present the IPv4 source address for the UDP packet car-		is not present the IPv4 source address for the UDP packet car-
	rying the Hello should be used.		rying the Hello SHOULD be used.
	Configuration Sequence Number		Configuration Sequence Number
	Specifies a 4 octet unsigned configuration sequence number that		Specifies a 4 octet unsigned configuration sequence number that
	identifies the configuration state of the sending LSR. Used by		identifies the configuration state of the sending LSR. Used by
	the receiving LSR to detect configuration changes on the send-		the receiving LSR to detect configuration changes on the send-
	ing LSR.		ing LSR.
	IPv6 Transport Address		IPv6 Transport Address
	Specifies the IPv6 address to be used for the sending LSR when		Specifies the IPv6 address to be used for the sending LSR when
	opening the LDP session TCP connection. If this optional TLV		opening the LDP session TCP connection. If this optional TLV
	is not present the IPv6 source address for the UDP packet car-		is not present the IPv6 source address for the UDP packet car-
	rying the Hello should be used.		rying the Hello SHOULD be used.
	3.5.2.1. Hello Message Procedures		3.5.2.1. Hello Message Procedures
	An LSR receiving Hellos from another LSR maintains a Hello adjacency		An LSR receiving Hellos from another LSR maintains a Hello adjacency
	corresponding to the Hellos. The LSR maintains a hold timer with the		corresponding to the Hellos. The LSR maintains a hold timer with the
	Hello adjacency which it restarts whenever it receives a Hello that		Hello adjacency which it restarts whenever it receives a Hello that
	matches the Hello adjacency. If the hold timer for a Hello adjacency		matches the Hello adjacency. If the hold timer for a Hello adjacency
	expires the LSR discards the Hello adjacency: see sections "Maintain-		expires the LSR discards the Hello adjacency: see sections "Maintain-
	ing Hello Adjacencies" and "Maintaining LDP Sessions".		ing Hello Adjacencies" and "Maintaining LDP Sessions".
	skipping to change at page 57, line 27		skipping to change at page 57, line 27
	Indicates the type of Label advertisement. A value of 0 means		Indicates the type of Label advertisement. A value of 0 means
	Downstream Unsolicited advertisement; a value of 1 means Down-		Downstream Unsolicited advertisement; a value of 1 means Down-
	stream On Demand.		stream On Demand.
	If one LSR proposes Downstream Unsolicited and the other pro-		If one LSR proposes Downstream Unsolicited and the other pro-
	poses Downstream on Demand, the rules for resolving this dif-		poses Downstream on Demand, the rules for resolving this dif-
	ference is:		ference is:
	- If the session is for a label-controlled ATM link or a		- If the session is for a label-controlled ATM link or a
	label-controlled Frame Relay link, then Downstream on Demand		label-controlled Frame Relay link, then Downstream on Demand
	must be used.		MUST be used.
	- Otherwise, Downstream Unsolicited must be used.		- Otherwise, Downstream Unsolicited MUST be used.
	If the label advertisement discipline determined in this way is		If the label advertisement discipline determined in this way is
	unacceptable to an LSR, it must send a Session Rejected/Parame-		unacceptable to an LSR, it MUST send a Session Rejected/Parame-
	ters Advertisement Mode Notification message in response to the		ters Advertisement Mode Notification message in response to the
	Initialization message and not establish the session.		Initialization message and not establish the session.
	D, Loop Detection		D, Loop Detection
	Indicates whether loop detection based on path vectors is		Indicates whether loop detection based on path vectors is
	enabled. A value of 0 means loop detection is disabled; a		enabled. A value of 0 means loop detection is disabled; a
	value of 1 means that loop detection is enabled.		value of 1 means that loop detection is enabled.
	PVLim, Path Vector Limit		PVLim, Path Vector Limit
	The configured maximum path vector length. Must be 0 if loop		The configured maximum path vector length. MUST be 0 if loop
	detection is disabled (D = 0). If the loop detection proce-		detection is disabled (D = 0). If the loop detection proce-
	dures would require the LSR to send a path vector that exceeds		dures would require the LSR to send a path vector that exceeds
	this limit, the LSR will behave as if a loop had been detected		this limit, the LSR will behave as if a loop had been detected
	for the FEC in question.		for the FEC in question.
	When Loop Detection is enabled in a portion of a network, it is		When Loop Detection is enabled in a portion of a network, it is
	recommended that all LSRs in that portion of the network be		recommended that all LSRs in that portion of the network be
	configured with the same path vector limit. Although knowledge		configured with the same path vector limit. Although knowledge
	of a peer's path vector limit will not change an LSR's behav-		of a peer's path vector limit will not change an LSR's behav-
	ior, it does enable the LSR to alert an operator to a possible		ior, it does enable the LSR to alert an operator to a possible
	misconfiguration.		misconfiguration.
	Reserved		Reserved
	This field is reserved. It must be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and ignored on receipt.		and ignored on receipt.
	Max PDU Length		Max PDU Length
	Two octet unsigned integer that proposes the maximum allowable		Two octet unsigned integer that proposes the maximum allowable
	length for LDP PDUs for the session. A value of 255 or less		length for LDP PDUs for the session. A value of 255 or less
	specifies the default maximum length of 4096 octets.		specifies the default maximum length of 4096 octets.
	The receiving LSR MUST calculate the maximum PDU length for the		The receiving LSR MUST calculate the maximum PDU length for the
	session by using the smaller of its and its peer's proposals		session by using the smaller of its and its peer's proposals
	for Max PDU Length. The default maximum PDU length applies		for Max PDU Length. The default maximum PDU length applies
	before session initialization completes.		before session initialization completes.
	If the maximum PDU length determined this way is unacceptable		If the maximum PDU length determined this way is unacceptable
	to an LSR, it must send a Session Rejected/Parameters Max PDU		to an LSR, it MUST send a Session Rejected/Parameters Max PDU
	Length Notification message in response to the Initialization		Length Notification message in response to the Initialization
	message and not establish the session.		message and not establish the session.
	Receiver LDP Identifier		Receiver LDP Identifier
	Identifies the receiver's label space. This LDP Identifier,		Identifies the receiver's label space. This LDP Identifier,
	together with the sender's LDP Identifier in the PDU header		together with the sender's LDP Identifier in the PDU header
	enables the receiver to match the Initialization message with		enables the receiver to match the Initialization message with
	one of its Hello adjacencies; see Section "Hello Message Proce-		one of its Hello adjacencies; see Section "Hello Message Proce-
	dures".		dures".
	If there is no matching Hello adjacency, the LSR must send a		If there is no matching Hello adjacency, the LSR MUST send a
	Session Rejected/No Hello Notification message in response to		Session Rejected/No Hello Notification message in response to
	the Initialization message and not establish the session.		the Initialization message and not establish the session.
	Optional Parameters		Optional Parameters
	This variable length field contains 0 or more parameters, each		This variable length field contains 0 or more parameters, each
	encoded as a TLV. The optional parameters are:		encoded as a TLV. The optional parameters are:
	Optional Parameter Type Length Value		Optional Parameter Type Length Value
	ATM Session Parameters 0x0501 var See below		ATM Session Parameters 0x0501 var See below
	skipping to change at page 60, line 17		skipping to change at page 60, line 17
	tion on the link only. When either or both of the peers speci-		tion on the link only. When either or both of the peers speci-
	fies unidirectional VC capability, both LSRs use unidirectional		fies unidirectional VC capability, both LSRs use unidirectional
	VC label assignment for the link as follows. The LSRs compare		VC label assignment for the link as follows. The LSRs compare
	their LDP Identifiers as unsigned integers. The LSR with the		their LDP Identifiers as unsigned integers. The LSR with the
	larger LDP Identifier may assign only odd-numbered VCIs in the		larger LDP Identifier may assign only odd-numbered VCIs in the
	VPI/VCI range as labels. The system with the smaller LDP Iden-		VPI/VCI range as labels. The system with the smaller LDP Iden-
	tifier may assign only even-numbered VCIs in the VPI/VCI range		tifier may assign only even-numbered VCIs in the VPI/VCI range
	as labels.		as labels.
	Reserved		Reserved
	This field is reserved. It must be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and ignored on receipt.		and ignored on receipt.
	One or more ATM Label Range Components		One or more ATM Label Range Components
	A list of ATM Label Range Components which together specify the		A list of ATM Label Range Components which together specify the
	Label range supported by the transmitting LSR.		Label range supported by the transmitting LSR.
	A receiving LSR MUST calculate the intersection between the		A receiving LSR MUST calculate the intersection between the
	received range and its own supported label range. The inter-		received range and its own supported label range. The inter-
	section is the range in which the LSR may allocate and accept		section is the range in which the LSR may allocate and accept
	labels. LSRs MUST NOT establish a session with neighbors for		labels. LSRs MUST NOT establish a session with neighbors for
	which the intersection of ranges is NULL. In this case, the		which the intersection of ranges is NULL. In this case, the
	LSR must send a Session Rejected/Parameters Label Range Notifi-		LSR MUST send a Session Rejected/Parameters Label Range Notifi-
	cation message in response to the Initialization message and		cation message in response to the Initialization message and
	not establish the session.		not establish the session.
	The encoding for an ATM Label Range Component is:		The encoding for an ATM Label Range Component is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res | Minimum VPI | Minimum VCI |		| Res | Minimum VPI | Minimum VCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res | Maximum VPI | Maximum VCI |		| Res | Maximum VPI | Maximum VCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Res		Res
	This field is reserved. It must be set to zero on transmis-		This field is reserved. It MUST be set to zero on transmis-
	sion and must be ignored on receipt.		sion and MUST be ignored on receipt.
	Minimum VPI (12 bits)		Minimum VPI (12 bits)
	This 12 bit field specifies the lower bound of a block of		This 12 bit field specifies the lower bound of a block of
	Virtual Path Identifiers that is supported on the originat-		Virtual Path Identifiers that is supported on the originat-
	ing switch. If the VPI is less than 12-bits it should be		ing switch. If the VPI is less than 12-bits it SHOULD be
	right justified in this field and preceding bits should be		right justified in this field and preceding bits SHOULD be
	set to 0.		set to 0.
	Minimum VCI (16 bits)		Minimum VCI (16 bits)
	This 16 bit field specifies the lower bound of a block of		This 16 bit field specifies the lower bound of a block of
	Virtual Connection Identifiers that is supported on the		Virtual Connection Identifiers that is supported on the
	originating switch. If the VCI is less than 16-bits it		originating switch. If the VCI is less than 16-bits it
	should be right justified in this field and preceding bits		SHOULD be right justified in this field and preceding bits
	should be set to 0.		SHOULD be set to 0.
	Maximum VPI (12 bits)		Maximum VPI (12 bits)
	This 12 bit field specifies the upper bound of a block of		This 12 bit field specifies the upper bound of a block of
	Virtual Path Identifiers that is supported on the originat-		Virtual Path Identifiers that is supported on the originat-
	ing switch. If the VPI is less than 12-bits it should be		ing switch. If the VPI is less than 12-bits it SHOULD be
	right justified in this field and preceding bits should be		right justified in this field and preceding bits SHOULD be
	set to 0.		set to 0.
	Maximum VCI (16 bits)		Maximum VCI (16 bits)
	This 16 bit field specifies the upper bound of a block of		This 16 bit field specifies the upper bound of a block of
	Virtual Connection Identifiers that is supported on the		Virtual Connection Identifiers that is supported on the
	originating switch. If the VCI is less than 16-bits it		originating switch. If the VCI is less than 16-bits it
	should be right justified in this field and preceding bits		SHOULD be right justified in this field and preceding bits
	should be set to 0.		SHOULD be set to 0.
	When peer LSRs are connected indirectly by means of an ATM VP, the		When peer LSRs are connected indirectly by means of an ATM VP, the
	sending LSR should set the Minimum and Maximum VPI fields to 0,		sending LSR SHOULD set the Minimum and Maximum VPI fields to 0,
	and the receiving LSR must ignore the Minimum and Maximum VPI		and the receiving LSR MUST ignore the Minimum and Maximum VPI
	fields.		fields.
	See [ATM-VP] for specification of the fields for ATM Label Range		See [ATM-VP] for specification of the fields for ATM Label Range
	Components to be used with VP merge LSRs.		Components to be used with VP merge LSRs.
	Frame Relay Session Parameters		Frame Relay Session Parameters
	Used when an LDP session manages label exchange for a Frame		Used when an LDP session manages label exchange for a Frame
	Relay link to specify Frame Relay-specific session parameters.		Relay link to specify Frame Relay-specific session parameters.
	0 1 2 3		0 1 2 3
	skipping to change at page 62, line 51		skipping to change at page 62, line 51
	label mapping for one direction on the link only. Wheneither		label mapping for one direction on the link only. Wheneither
	or both of the peers specifies unidirectional VC capability,		or both of the peers specifies unidirectional VC capability,
	both LSRs use unidirectional VC label assignment for the link		both LSRs use unidirectional VC label assignment for the link
	as follows. The LSRs compare their LDP Identifiers as unsigned		as follows. The LSRs compare their LDP Identifiers as unsigned
	integers. The LSR with the larger LDP Identifier may assign		integers. The LSR with the larger LDP Identifier may assign
	only odd-numbered DLCIs in the range as labels. The system		only odd-numbered DLCIs in the range as labels. The system
	with the smaller LDP Identifier may assign only even-numbered		with the smaller LDP Identifier may assign only even-numbered
	DLCIs in the range as labels.		DLCIs in the range as labels.
	Reserved		Reserved
	This field is reserved. It must be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and ignored on receipt.		and ignored on receipt.
	One or more Frame Relay Label Range Components		One or more Frame Relay Label Range Components
	A list of Frame Relay Label Range Components which together		A list of Frame Relay Label Range Components which together
	specify the Label range supported by the transmitting LSR.		specify the Label range supported by the transmitting LSR.
	A receiving LSR MUST calculate the intersection between the		A receiving LSR MUST calculate the intersection between the
	received range and its own supported label range. The inter-		received range and its own supported label range. The inter-
	section is the range in which the LSR may allocate and accept		section is the range in which the LSR may allocate and accept
	labels. LSRs MUST NOT establish a session with neighbors for		labels. LSRs MUST NOT establish a session with neighbors for
	which the intersection of ranges is NULL. In this case, the		which the intersection of ranges is NULL. In this case, the
	LSR must send a Session Rejected/Parameters Label Range Notifi-		LSR MUST send a Session Rejected/Parameters Label Range Notifi-
	cation message in response to the Initialization message and		cation message in response to the Initialization message and
	not establish the session.		not establish the session.
	The encoding for a Frame Relay Label Range Component is:		The encoding for a Frame Relay Label Range Component is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |Len| Minimum DLCI |		| Reserved |Len| Minimum DLCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Maximum DLCI |		| Reserved | Maximum DLCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Reserved		Reserved
	This field is reserved. It must be set to zero on transmis-		This field is reserved. It MUST be set to zero on transmis-
	sion and ignored on receipt.		sion and ignored on receipt.
	Len		Len
	This field specifies the number of bits of the DLCI. The		This field specifies the number of bits of the DLCI. The
	following values are supported:		following values are supported:
	Len DLCI bits		Len DLCI bits
	0 10		0 10
	2 23		2 23
	Len values 1 and 3 are reserved.		Len values 1 and 3 are reserved.
	Minimum DLCI		Minimum DLCI
	This 23-bit field specifies the lower bound of a block of		This 23-bit field specifies the lower bound of a block of
	Data Link Connection Identifiers (DLCIs) that is supported		Data Link Connection Identifiers (DLCIs) that is supported
	on the originating switch. The DLCI should be right justi-		on the originating switch. The DLCI SHOULD be right justi-
	fied in this field and unused bits should be set to 0.		fied in this field and unused bits SHOULD be set to 0.
	Maximum DLCI		Maximum DLCI
	This 23-bit field specifies the upper bound of a block of		This 23-bit field specifies the upper bound of a block of
	Data Link Connection Identifiers (DLCIs) that is supported		Data Link Connection Identifiers (DLCIs) that is supported
	on the originating switch. The DLCI should be right		on the originating switch. The DLCI SHOULD be right
	justified in this field and unused bits should be set to 0.		justified in this field and unused bits SHOULD be set to 0.
	Note that there is no Generic Session Parameters TLV for sessions		Note that there is no Generic Session Parameters TLV for sessions
	which advertise Generic Labels.		which advertise Generic Labels.
	3.5.3.1. Initialization Message Procedures		3.5.3.1. Initialization Message Procedures
	See Section "LDP Session Establishment" and particularly Section		See Section "LDP Session Establishment" and particularly Section
	"Session Initialization" for general procedures for handling the Ini-		"Session Initialization" for general procedures for handling the Ini-
	tialization Message.		tialization Message.
	skipping to change at page 65, line 4		skipping to change at page 65, line 4
	The KeepAlive Timer mechanism described in Section "Maintaining LDP		The KeepAlive Timer mechanism described in Section "Maintaining LDP
	Sessions" resets a session KeepAlive timer every time an LDP PDU is		Sessions" resets a session KeepAlive timer every time an LDP PDU is
	received on the session TCP connection. The KeepAlive Message is		received on the session TCP connection. The KeepAlive Message is
	provided to allow reset of the KeepAlive Timer in circumstances where		provided to allow reset of the KeepAlive Timer in circumstances where
	an LSR has no other information to communicate to an LDP peer.		an LSR has no other information to communicate to an LDP peer.
	An LSR must arrange that its peer receive an LDP Message from it at		An LSR must arrange that its peer receive an LDP Message from it at
	least every KeepAlive Time period. Any LDP protocol message will do		least every KeepAlive Time period. Any LDP protocol message will do
	but, in circumstances where no other LDP protocol messages have been		but, in circumstances where no other LDP protocol messages have been
	sent within the period, a KeepAlive message must be sent.		sent within the period, a KeepAlive message MUST be sent.
	3.5.5. Address Message		3.5.5. Address Message
	An LSR sends the Address Message to an LDP peer to advertise its		An LSR sends the Address Message to an LDP peer to advertise its
	interface addresses.		interface addresses.
	The encoding for the Address Message is:		The encoding for the Address Message is:
	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
	skipping to change at page 65, line 46		skipping to change at page 65, line 46
	No optional parameters are defined for the Address message.		No optional parameters are defined for the Address message.
	3.5.5.1. Address Message Procedures		3.5.5.1. Address Message Procedures
	An LSR that receives an Address Message message uses the addresses it		An LSR that receives an Address Message message uses the addresses it
	learns to maintain a database for mapping between peer LDP Identi-		learns to maintain a database for mapping between peer LDP Identi-
	fiers and next hop addresses; see Section "LDP Identifiers and Next		fiers and next hop addresses; see Section "LDP Identifiers and Next
	Hop Addresses".		Hop Addresses".
	When a new LDP session is initialized and before sending Label Map-		When a new LDP session is initialized and before sending Label Map-
	ping or Label Request messages an LSR should advertise its interface		ping or Label Request messages an LSR SHOULD advertise its interface
	addresses with one or more Address messages.		addresses with one or more Address messages.
	Whenever an LSR "activates" a new interface address, it should		Whenever an LSR "activates" a new interface address, it SHOULD
	advertise the new address with an Address message.		advertise the new address with an Address message.
	Whenever an LSR "de-activates" a previously advertised address, it		Whenever an LSR "de-activates" a previously advertised address, it
	should withdraw the address with an Address Withdraw message; see		SHOULD withdraw the address with an Address Withdraw message; see
	Section "Address Withdraw Message".		Section "Address Withdraw Message".
	If an LSR does not support the Address Family specified in the		If an LSR does not support the Address Family specified in the
	Address List TLV, it should send an "Unsupported Address Family"		Address List TLV, it SHOULD send an "Unsupported Address Family"
	Notification to its LDP signalling an error and abort processing the		Notification to its LDP signalling an error and abort processing the
	message.		message.
	An LSR may re-advertise an address (A) that it has previously adver-		An LSR may re-advertise an address (A) that it has previously adver-
	tised without explicitly withdrawing the address. If the receiver		tised without explicitly withdrawing the address. If the receiver
	already has address binding (LSR, A) it should take no further		already has address binding (LSR, A) it SHOULD take no further
	action.		action.
	An LSR may withdraw an address (A) without having previously adver-		An LSR may withdraw an address (A) without having previously adver-
	tised it. If the receiver has no address binding (LSR, A), it should		tised it. If the receiver has no address binding (LSR, A), it SHOULD
	take no further action.		take no further action.
	3.5.6. Address Withdraw Message		3.5.6. Address Withdraw Message
	An LSR sends the Address Withdraw Message to an LDP peer to withdraw		An LSR sends the Address Withdraw Message to an LDP peer to withdraw
	previously advertised interface addresses.		previously advertised interface addresses.
	The encoding for the Address Withdraw Message is:		The encoding for the Address Withdraw Message is:
	0 1 2 3		0 1 2 3
	skipping to change at page 68, line 17		skipping to change at page 68, line 17
	Label Request 4 See below		Label Request 4 See below
	Message ID TLV		Message ID TLV
	Hop Count TLV 1 See below		Hop Count TLV 1 See below
	Path Vector TLV variable See below		Path Vector TLV variable See below
	The encodings for the Hop Count, and Path Vector TLVs can be found		The encodings for the Hop Count, and Path Vector TLVs can be found
	in Section "TLV Encodings for Commonly Used Parameters".		in Section "TLV Encodings for Commonly Used Parameters".
	Label Request Message ID		Label Request Message ID
	If this Label Mapping message is a response to a Label Request		If this Label Mapping message is a response to a Label Request
	message it must include the Request Message Id optional parame-		message it MUST include the Request Message Id optional parame-
	ter. The value of this optional parameter is the Message Id of		ter. The value of this optional parameter is the Message Id of
	the corresponding Label Request Message.		the corresponding Label Request Message.
	Hop Count		Hop Count
	Specifies the running total of the number of LSR hops along the		Specifies the running total of the number of LSR hops along the
	LSP being setup by the Label Message. Section "Hop Count Pro-		LSP being setup by the Label Message. Section "Hop Count Pro-
	cedures" describes how to handle this TLV.		cedures" describes how to handle this TLV.
	Path Vector		Path Vector
	Specifies the LSRs along the LSP being setup by the Label Mes-		Specifies the LSRs along the LSP being setup by the Label Mes-
	skipping to change at page 68, line 43		skipping to change at page 68, line 43
	The Mapping message is used by an LSR to distribute a label mapping		The Mapping message is used by an LSR to distribute a label mapping
	for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC		for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC
	to multiple LDP peers, it is a local matter whether it maps a single		to multiple LDP peers, it is a local matter whether it maps a single
	label to the FEC, and distributes that mapping to all its peers, or		label to the FEC, and distributes that mapping to all its peers, or
	whether it uses a different mapping for each of its peers.		whether it uses a different mapping for each of its peers.
	An LSR is responsible for the consistency of the label mappings it		An LSR is responsible for the consistency of the label mappings it
	has distributed, and that its peers have these mappings.		has distributed, and that its peers have these mappings.
	An LSR receiving a Label Mapping message from a downstream LSR for a		An LSR receiving a Label Mapping message from a downstream LSR for a
	Prefix should not use the label for forwarding unless its routing ta-		Prefix SHOULD NOT use the label for forwarding unless its routing ta-
	ble contains an entry that exactly matches the FEC Element.		ble contains an entry that exactly matches the FEC Element.
	See Appendix A "LDP Label Distribution Procedures" for more details.		See Appendix A "LDP Label Distribution Procedures" for more details.
	3.5.7.1.1. Independent Control Mapping		3.5.7.1.1. Independent Control Mapping
	If an LSR is configured for independent control, a mapping message is		If an LSR is configured for independent control, a mapping message is
	transmitted by the LSR upon any of the following conditions:		transmitted by the LSR upon any of the following conditions:
	1. The LSR recognizes a new FEC via the forwarding table, and the		1. The LSR recognizes a new FEC via the forwarding table, and the
	skipping to change at page 70, line 21		skipping to change at page 70, line 21
	everything is functioning properly, but no labels are distributed.		everything is functioning properly, but no labels are distributed.
	For example, consider two LSRs Ru and Rd where Ru is the upstream LSR		For example, consider two LSRs Ru and Rd where Ru is the upstream LSR
	and Rd is the downstream LSR for a particular FEC. In this example,		and Rd is the downstream LSR for a particular FEC. In this example,
	Ru is using Downstream Unsolicited advertisement mode and Rd is using		Ru is using Downstream Unsolicited advertisement mode and Rd is using
	Downstream on Demand mode. In this case, Rd may assume that Ru will		Downstream on Demand mode. In this case, Rd may assume that Ru will
	request a label mapping when it wants one and Ru may assume that Rd		request a label mapping when it wants one and Ru may assume that Rd
	will advertise a label if it wants Ru to use one. If Rd and Ru oper-		will advertise a label if it wants Ru to use one. If Rd and Ru oper-
	ate as suggested, no labels will be distributed from Rd to Ru.		ate as suggested, no labels will be distributed from Rd to Ru.
	This livelock situation can be avoided if the following rule is		This livelock situation can be avoided if the following rule is
	observed: an LSR operating in Downstream on Demand mode should not be		observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
	expected to send unsolicited mapping advertisements. Therefore, if		expected to send unsolicited mapping advertisements. Therefore, if
	the downstream LSR is operating in Downstream on Demand mode, the		the downstream LSR is operating in Downstream on Demand mode, the
	upstream LSR is responsible for requesting label mappings as needed.		upstream LSR is responsible for requesting label mappings as needed.
	3.5.7.1.4. Downstream Unsolicited Label Advertisement		3.5.7.1.4. Downstream Unsolicited Label Advertisement
	In general, the downstream LSR is responsible for advertising a label		In general, the downstream LSR is responsible for advertising a label
	mapping when it wants an upstream LSR to use the label. An upstream		mapping when it wants an upstream LSR to use the label. An upstream
	LSR may issue a mapping request if it so desires.		LSR may issue a mapping request if it so desires.
	skipping to change at page 72, line 26		skipping to change at page 72, line 26
	ditions:		ditions:
	1. The LSR recognizes a new FEC via the forwarding table, and the		1. The LSR recognizes a new FEC via the forwarding table, and the
	next hop is an LDP peer, and the LSR doesn't already have a		next hop is an LDP peer, and the LSR doesn't already have a
	mapping from the next hop for the given FEC.		mapping from the next hop for the given FEC.
	2. The next hop to the FEC changes, and the LSR doesn't already		2. The next hop to the FEC changes, and the LSR doesn't already
	have a mapping from that next hop for the given FEC.		have a mapping from that next hop for the given FEC.
	Note that if the LSR already has a pending Label Request mes-		Note that if the LSR already has a pending Label Request mes-
	sage for the new next hop it should not issue an additional		sage for the new next hop it SHOULD NOT issue an additional
	Label Request in response to the next hop change.		Label Request in response to the next hop change.
	3. The LSR receives a Label Request for a FEC from an upstream LDP		3. The LSR receives a Label Request for a FEC from an upstream LDP
	peer, the FEC next hop is an LDP peer, and the LSR doesn't		peer, the FEC next hop is an LDP peer, and the LSR doesn't
	already have a mapping from the next hop.		already have a mapping from the next hop.
	Note that since a non-merge LSR must setup a separate LSP for		Note that since a non-merge LSR must setup a separate LSP for
	each upstream peer requesting a label, it must send a separate		each upstream peer requesting a label, it must send a separate
	Label Request for each such peer. A consequence of this is		Label Request for each such peer. A consequence of this is
	that a non-merge LSR may have multiple Label Request messages		that a non-merge LSR may have multiple Label Request messages
	for a given FEC outstanding at the same time.		for a given FEC outstanding at the same time.
	The receiving LSR should respond to a Label Request message with a		The receiving LSR SHOULD respond to a Label Request message with a
	Label Mapping for the requested label or with a Notification message		Label Mapping for the requested label or with a Notification message
	indicating why it cannot satisfy the request.		indicating why it cannot satisfy the request.
	When the FEC for which a label is requested is a Prefix FEC Element,		When the FEC for which a label is requested is a Prefix FEC Element,
	the receiving LSR uses its routing table to determine its response.		the receiving LSR uses its routing table to determine its response.
	Unless its routing table includes an entry that exactly matches the		Unless its routing table includes an entry that exactly matches the
	requested Prefix, the LSR must respond with a No Route Notification		requested Prefix, the LSR MUST respond with a No Route Notification
	message.		message.
	The message ID of the Label Request message serves as an identifier		The message ID of the Label Request message serves as an identifier
	for the Label Request transaction. When the receiving LSR responds		for the Label Request transaction. When the receiving LSR responds
	with a Label Mapping message, the mapping message must include a		with a Label Mapping message, the mapping message MUST include a
	Label Request/Returned Message ID TLV optional parameter which		Label Request/Returned Message ID TLV optional parameter which
	includes the message ID of the Label Request message. Note that		includes the message ID of the Label Request message. Note that
	since LSRs use Label Request message IDs as transaction identifiers		since LSRs use Label Request message IDs as transaction identifiers
	an LSR should not reuse the message ID of a Label Request message		an LSR SHOULD NOT reuse the message ID of a Label Request message
	until the corresponding transaction completes.		until the corresponding transaction completes.
	This version of the protocol defines the following Status Codes for		This version of the protocol defines the following Status Codes for
	the Notification message that signals a request cannot be satisfied:		the Notification message that signals a request cannot be satisfied:
	No Route		No Route
	The FEC for which a label was requested includes a FEC Element		The FEC for which a label was requested includes a FEC Element
	for which the LSR does not have a route.		for which the LSR does not have a route.
	No Label Resources		No Label Resources
	The LSR cannot provide a label because of resource limitations.		The LSR cannot provide a label because of resource limitations.
	When resources become available the LSR must notify the		When resources become available the LSR MUST notify the
	requesting LSR by sending a Notification message with the Label		requesting LSR by sending a Notification message with the Label
	Resources Available Status Code.		Resources Available Status Code.
	An LSR that receives a No Label Resources response to a Label		An LSR that receives a No Label Resources response to a Label
	Request message must not issue further Label Request messages		Request message MUST NOT issue further Label Request messages
	until it receives a Notification message with the Label		until it receives a Notification message with the Label
	Resources Available Status code.		Resources Available Status code.
	Loop Detected		Loop Detected
	The LSR has detected a looping Label Request message.		The LSR has detected a looping Label Request message.
	See Appendix A "LDP Label Distribution Procedures" for more details.		See Appendix A "LDP Label Distribution Procedures" for more details.
	3.5.9. Label Abort Request Message		3.5.9. Label Abort Request Message
	skipping to change at page 75, line 7		skipping to change at page 75, line 7
	Request for FEC from an upstream peer Y and Y is the only		Request for FEC from an upstream peer Y and Y is the only
	(last) upstream LSR requesting a label for FEC.		(last) upstream LSR requesting a label for FEC.
	There may be other situations where an LSR may choose to abort an		There may be other situations where an LSR may choose to abort an
	outstanding Label Request message in order to reclaim resource asso-		outstanding Label Request message in order to reclaim resource asso-
	ciated with the pending LSP. However, specification of general		ciated with the pending LSP. However, specification of general
	strategies for using the abort mechanism is beyond the scope of LDP.		strategies for using the abort mechanism is beyond the scope of LDP.
	When an LSR receives a Label Abort Request message, if it has not		When an LSR receives a Label Abort Request message, if it has not
	previously responded to the Label Request being aborted with a Label		previously responded to the Label Request being aborted with a Label
	Mapping message or some other Notification message, it must acknowl-		Mapping message or some other Notification message, it MUST acknowl-
	edge the abort by responding with a Label Request Aborted Notifica-		edge the abort by responding with a Label Request Aborted Notifica-
	tion message. The Notification must include a Label Request Message		tion message. The Notification MUST include a Label Request Message
	ID TLV that carries the message ID of the aborted Label Request mes-		ID TLV that carries the message ID of the aborted Label Request mes-
	sage.		sage.
	If an LSR receives a Label Abort Request Message after it has		If an LSR receives a Label Abort Request Message after it has
	responded to the Label Request in question with a Label Mapping mes-		responded to the Label Request in question with a Label Mapping mes-
	sage or a Notification message, it ignores the abort request.		sage or a Notification message, it ignores the abort request.
	If an LSR receives a Label Mapping message in response to a Label		If an LSR receives a Label Mapping message in response to a Label
	Request message after it has sent a Label Abort Request message to		Request message after it has sent a Label Abort Request message to
	abort the Label Request, the label in the Label Mapping message is		abort the Label Request, the label in the Label Mapping message is
	skipping to change at page 75, line 47		skipping to change at page 75, line 47
	an LSR may choose to time out receipt of the above. The time out		an LSR may choose to time out receipt of the above. The time out
	period should be relatively long (several minutes). If the time out		period should be relatively long (several minutes). If the time out
	period elapses with no reply from the peer the LSR may reuse the Mes-		period elapses with no reply from the peer the LSR may reuse the Mes-
	sage Id of the Label Request message; if it does so, it should also		sage Id of the Label Request message; if it does so, it should also
	discard any record of the outstanding Label Request and Label Abort		discard any record of the outstanding Label Request and Label Abort
	messages.		messages.
	Note that the response to a Label Abort Request message is never		Note that the response to a Label Abort Request message is never
	"ordered". That is, the response does not depend on the downstream		"ordered". That is, the response does not depend on the downstream
	state of the LSP setup being aborted. An LSR receiving a Label Abort		state of the LSP setup being aborted. An LSR receiving a Label Abort
	Request message must process it immediately, regardless of the down-		Request message MUST process it immediately, regardless of the down-
	stream state of the LSP, responding with a Label Request Aborted		stream state of the LSP, responding with a Label Request Aborted
	Notification or ignoring it, as appropriate.		Notification or ignoring it, as appropriate.
	3.5.10. Label Withdraw Message		3.5.10. Label Withdraw Message
	An LSR sends a Label Withdraw Message to an LDP peer to signal the		An LSR sends a Label Withdraw Message to an LDP peer to signal the
	peer that the peer may not continue to use specific FEC-label map-		peer that the peer may not continue to use specific FEC-label map-
	pings the LSR had previously advertised. This breaks the mapping		pings the LSR had previously advertised. This breaks the mapping
	between the FECs and the labels.		between the FECs and the labels.
	skipping to change at page 77, line 30		skipping to change at page 77, line 30
	optional Label TLV is to be withdrawn.		optional Label TLV is to be withdrawn.
	The FEC TLV may contain the Wildcard FEC Element; if so, it may con-		The FEC TLV may contain the Wildcard FEC Element; if so, it may con-
	tain no other FEC Elements. In this case, if the Label Withdraw mes-		tain no other FEC Elements. In this case, if the Label Withdraw mes-
	sage contains an optional Label TLV, then the label is to be with-		sage contains an optional Label TLV, then the label is to be with-
	drawn from all FECs to which it is bound. If there is not an		drawn from all FECs to which it is bound. If there is not an
	optional Label TLV in the Label Withdraw message, then the sending		optional Label TLV in the Label Withdraw message, then the sending
	LSR is withdrawing all label mappings previously advertised to the		LSR is withdrawing all label mappings previously advertised to the
	receiving LSR.		receiving LSR.
	An LSR that receives a Label Withdraw message must respond with a		An LSR that receives a Label Withdraw message MUST respond with a
	Label Release message.		Label Release message.
	See Appendix A "LDP Label Distribution Procedures" for more details.		See Appendix A "LDP Label Distribution Procedures" for more details.
	3.5.11. Label Release Message		3.5.11. Label Release Message
	An LSR sends a Label Release message to an LDP peer to signal the		An LSR sends a Label Release message to an LDP peer to signal the
	peer that the LSR no longer needs specific FEC-label mappings previ-		peer that the LSR no longer needs specific FEC-label mappings previ-
	ously requested of and/or advertised by the peer.		ously requested of and/or advertised by the peer.
	skipping to change at page 78, line 45		skipping to change at page 78, line 45
	Label		Label
	If present, the label being released (see procedures below).		If present, the label being released (see procedures below).
	3.5.11.1. Label Release Message Procedures		3.5.11.1. Label Release Message Procedures
	An LSR transmits a Label Release message to a peer when it is no		An LSR transmits a Label Release message to a peer when it is no
	longer needs a label previously received from or requested of that		longer needs a label previously received from or requested of that
	peer.		peer.
	An LSR must transmit a Label Release message under any of the follow-		An LSR MUST transmit a Label Release message under any of the follow-
	ing conditions:		ing conditions:
	1. The LSR which sent the label mapping is no longer the next hop		1. The LSR which sent the label mapping is no longer the next hop
	for the mapped FEC, and the LSR is configured for conservative		for the mapped FEC, and the LSR is configured for conservative
	operation.		operation.
	2. The LSR receives a label mapping from an LSR which is not the		2. The LSR receives a label mapping from an LSR which is not the
	next hop for the FEC, and the LSR is configured for conserva-		next hop for the FEC, and the LSR is configured for conserva-
	tive operation.		tive operation.
	skipping to change at page 80, line 24		skipping to change at page 80, line 24
	| |		| |
	| Data.... |		| Data.... |
	~ ~		~ ~
	| |		| |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	U bit		U bit
	Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear		Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
	(=0), a notification must be returned to the message originator		(=0), a notification MUST be returned to the message originator
	and the entire message must be ignored; if U is set (=1), the		and the entire message MUST be ignored; if U is set (=1), the
	unknown TLV is silently ignored and the rest of the message is		unknown TLV is silently ignored and the rest of the message is
	processed as if the unknown TLV did not exist.		processed as if the unknown TLV did not exist.
	The determination as to whether a vendor-private message is under-		The determination as to whether a vendor-private message is under-
	stood is based on the Type and the mandatory Vendor ID field.		stood is based on the Type and the mandatory Vendor ID field.
	F bit		F bit
	Forward unknown TLV bit. This bit only applies when the U bit is		Forward unknown TLV bit. This bit only applies when the U bit is
	set and the LDP message containing the unknown TLV is is to be		set and the LDP message containing the unknown TLV is is to be
	forwarded. If F is clear (=0), the unknown TLV is not forwarded		forwarded. If F is clear (=0), the unknown TLV is not forwarded
	skipping to change at page 93, line 23		skipping to change at page 93, line 23
	sources. We would like to thank Rick Boivie, Ross Callon, Alex		sources. We would like to thank Rick Boivie, Ross Callon, Alex
	Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov		Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
	Rekhter, and Arun Viswanathan for their input for RFC3036.		Rekhter, and Arun Viswanathan for their input for RFC3036.
	The editors would like to thank Eric Gray for his insight and input		The editors would like to thank Eric Gray for his insight and input
	to the current document.		to the current document.
	In addition, the editors would like to thank the members of the mpls		In addition, the editors would like to thank the members of the mpls
	working group for their ideas and the support they have given to this		working group for their ideas and the support they have given to this
	document, and in particular to Eric Rosen, Luca Martini, Markus Jork,		document, and in particular to Eric Rosen, Luca Martini, Markus Jork,
	Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan		Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan,
	and Nick Weeds.		Nick Weeds and Adrian Farrel.
	9. References		9. References
	9.1. Normative references		9.1. Normative references
	[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
	skipping to change at page 97, line 21		skipping to change at page 97, line 21
	. Downstream On Demand Independent Control, called		. Downstream On Demand Independent Control, called
	PulledUnconditional in [RFC3031].		PulledUnconditional in [RFC3031].
	. Downstream On Demand Ordered Control, called		. Downstream On Demand Ordered Control, called
	PulledConditional in [RFC3031].		PulledConditional in [RFC3031].
	- Label Withdrawal procedure, which is performed by a downstream		- Label Withdrawal procedure, which is performed by a downstream
	LSR to determine when to withdraw a FEC label mapping previ-		LSR to determine when to withdraw a FEC label mapping previ-
	ously distributed to LDP peers. The architecture defines a		ously distributed to LDP peers. The architecture defines a
	single Label Withdrawal procedure. Whenever an LSR breaks the		single Label Withdrawal procedure. Whenever an LSR breaks the
	binding between a label and a FEC, it must withdraw the FEC		binding between a label and a FEC, it MUST withdraw the FEC
	label mapping from all LDP peers to which it has previously		label mapping from all LDP peers to which it has previously
	sent the mapping.		sent the mapping.
	- Label Request procedure, which is performed by an upstream LSR		- Label Request procedure, which is performed by an upstream LSR
	to determine when to explicitly request that a downstream LSR		to determine when to explicitly request that a downstream LSR
	bind a label to a FEC and send it the corresponding label map-		bind a label to a FEC and send it the corresponding label map-
	ping. The architecture defines three Label Request procedures:		ping. The architecture defines three Label Request procedures:
	. Request Never. The LSR never requests a label.		. Request Never. The LSR never requests a label.
	skipping to change at page 102, line 25		skipping to change at page 102, line 25
	distinguish such requests from a non-label merging MsgSource		distinguish such requests from a non-label merging MsgSource
	from duplicate label requests.		from duplicate label requests.
	The LSR uses the message ID of received Label Request messages		The LSR uses the message ID of received Label Request messages
	to detect duplicate requests. This means that an LSR (the		to detect duplicate requests. This means that an LSR (the
	upstream peer) may not reuse the message ID used for a Label		upstream peer) may not reuse the message ID used for a Label
	Request until the Label Request transaction has completed.		Request until the Label Request transaction has completed.
	2. When an LSR sends a label request to a peer it records that the		2. When an LSR sends a label request to a peer it records that the
	request has been sent and marks it as outstanding. As long as		request has been sent and marks it as outstanding. As long as
	the request is marked outstanding the LSR should not send		the request is marked outstanding the LSR SHOULD NOT send
	another request for the same label to the peer. Such a second		another request for the same label to the peer. Such a second
	request would be a duplicate. The Send_Label_Request procedure		request would be a duplicate. The Send_Label_Request procedure
	described below obeys this rule.		described below obeys this rule.
	A duplicate label request is considered a protocol error and		A duplicate label request is considered a protocol error and
	should be dropped by the receiving LSR (perhaps with a suitable		SHOULD be dropped by the receiving LSR (perhaps with a suitable
	notification returned to MsgSource).		notification returned to MsgSource).
	3. If LSR is not merge-capable, this test will fail.		3. If LSR is not merge-capable, this test will fail.
	4. The Send_Label procedure may fail due to lack of label		4. The Send_Label procedure may fail due to lack of label
	resources, in which case the LSR should not perform the Label		resources, in which case the LSR SHOULD NOT perform the Label
	Use procedure.		Use procedure.
	A.1.2. Receive Label Mapping		A.1.2. Receive Label Mapping
	Summary:		Summary:
	The response by an LSR to receipt of a FEC label mapping from an		The response by an LSR to receipt of a FEC label mapping from an
	LDP peer may involve one or more of the following actions:		LDP peer may involve one or more of the following actions:
	- Transmission of a label release message for the FEC label to		- Transmission of a label release message for the FEC label to
	skipping to change at page 108, line 26		skipping to change at page 108, line 26
	gate the Path Vector.		gate the Path Vector.
	10. LMp.22 through LMp.27 deal with a situation that can arise		10. LMp.22 through LMp.27 deal with a situation that can arise
	when the LSR is using independent control and it receives a		when the LSR is using independent control and it receives a
	mapping from the downstream peer after it has sent a mapping		mapping from the downstream peer after it has sent a mapping
	to an upstream peer. In this situation the LSR needs to prop-		to an upstream peer. In this situation the LSR needs to prop-
	agate any changed attributes, such as Hop Count, upstream. If		agate any changed attributes, such as Hop Count, upstream. If
	Loop Detection is configured on, the propagated attributes		Loop Detection is configured on, the propagated attributes
	must include the Path Vector		must include the Path Vector
	11. An LSR operating in Downstream Unsolicited mode must process		11. An LSR operating in Downstream Unsolicited mode MUST process
	any Label Request messages it receives. If there are pending		any Label Request messages it receives. If there are pending
	label requests, fall through into the Downstream on Demand		label requests, fall through into the Downstream on Demand
	procedures in order to satisfy the pending requests.		procedures in order to satisfy the pending requests.
	12. As determined by step LMp.1.		12. As determined by step LMp.1.
	13. An LSR operating in ordered control mode may choose to skip at		13. An LSR operating in ordered control mode may choose to skip at
	this stage the peer from which it received the advertisement		this stage the peer from which it received the advertisement
	that caused it to generate the label-map message. Doing so		that caused it to generate the label-map message. Doing so
	will in effect provide a form of split-horizon.		will in effect provide a form of split-horizon.
	skipping to change at page 111, line 38		skipping to change at page 111, line 38
	LRl.12 Do any peers still hold Label for FEC?		LRl.12 Do any peers still hold Label for FEC?
	If so, goto LRl.14.		If so, goto LRl.14.
	LRl.13 Free the Label.		LRl.13 Free the Label.
	LRl.14 DONE.		LRl.14 DONE.
	Notes:		Notes:
	1. If LSR is using Downstream Unsolicited label distribution, it		1. If LSR is using Downstream Unsolicited label distribution, it
	should not re-advertise a label mapping for FEC to MsgSource		SHOULD NOT re-advertise a label mapping for FEC to MsgSource
	until MsgSource requests it.		until MsgSource requests it.
	2. LRl.5 through LRl.9 deal with determining whether where the LSR		2. LRl.5 through LRl.9 deal with determining whether where the LSR
	should propagate the label release to a downstream peer		should propagate the label release to a downstream peer
	(LRl.9).		(LRl.9).
	3. If LRl.9 is reached, no upstream LSR holds a label for the FEC,		3. If LRl.9 is reached, no upstream LSR holds a label for the FEC,
	and the LSR holds a label for the FEC from the FEC Next Hop.		and the LSR holds a label for the FEC from the FEC Next Hop.
	The LSR could propagate the Label Release to the Next Hop. By		The LSR could propagate the Label Release to the Next Hop. By
	propagating the Label Release the LSR releases a potentially		propagating the Label Release the LSR releases a potentially
	skipping to change at page 118, line 50		skipping to change at page 118, line 50
	Next Hop.		Next Hop.
	3. The purpose of the check on label retention mode is to avoid a		3. The purpose of the check on label retention mode is to avoid a
	race with steps LMp.12-LMp.13 of the procedure for handling a		race with steps LMp.12-LMp.13 of the procedure for handling a
	Label Mapping message where the LSR operating in Conservative		Label Mapping message where the LSR operating in Conservative
	Label retention mode may have released a label mapping received		Label retention mode may have released a label mapping received
	from the New Next Hop before it detected the FEC next hop had		from the New Next Hop before it detected the FEC next hop had
	changed.		changed.
	4. Regardless of the Label Request procedure in use by the LSR, it		4. Regardless of the Label Request procedure in use by the LSR, it
	must send a label request if the conditions in		MUST send a label request if the conditions in
	NH.13 hold.		NH.13 hold.
	Therefore it executes the Send_Label_Request procedure directly		Therefore it executes the Send_Label_Request procedure directly
	rather than perform LSR Label Request procedure.		rather than perform LSR Label Request procedure.
	A.1.8. Receive Notification / Label Request Aborted		A.1.8. Receive Notification / Label Request Aborted
	Summary:		Summary:
	When an LSR receives a Label Request Aborted notification from an		When an LSR receives a Label Request Aborted notification from an
	skipping to change at page 123, line 32		skipping to change at page 123, line 32
	1. Iteration ResA.5 through ResA.8 handles the situation where the		1. Iteration ResA.5 through ResA.8 handles the situation where the
	LSR is using Downstream Unsolicited label distribution and was		LSR is using Downstream Unsolicited label distribution and was
	previously unable to allocate a label for a FEC.		previously unable to allocate a label for a FEC.
	A.1.14. LSR decides to no longer label switch a FEC		A.1.14. LSR decides to no longer label switch a FEC
	Summary:		Summary:
	An LSR may unilaterally decide to no longer label switch a FEC for		An LSR may unilaterally decide to no longer label switch a FEC for
	an LDP peer. An LSR that does so must send a label withdraw message		an LDP peer. An LSR that does so MUST send a label withdraw message
	for the FEC to the peer.		for the FEC to the peer.
	Context:		Context:
	- Peer. The peer.		- Peer. The peer.
	- FEC. The FEC.		- FEC. The FEC.
	- PrevAdvLabel. The label for FEC previously advertised to Peer.		- PrevAdvLabel. The label for FEC previously advertised to Peer.
	skipping to change at page 124, line 11		skipping to change at page 124, line 11
	PrevAdvLabel). (See Note 1.)		PrevAdvLabel). (See Note 1.)
	NoLS.2 DONE.		NoLS.2 DONE.
	Notes:		Notes:
	1. The LSR may remove the label from forwarding/switching use as		1. The LSR may remove the label from forwarding/switching use as
	part of this event or as part of processing the label release		part of this event or as part of processing the label release
	from the peer in response to the label withdraw. If the LSR		from the peer in response to the label withdraw. If the LSR
	doesn't wait for the label reelase message from the peer it		doesn't wait for the label reelase message from the peer it
	should not reuse the label until it receives the label release.		SHOULD NOT reuse the label until it receives the label release.
	A.1.15. Timeout of deferred label request		A.1.15. Timeout of deferred label request
	Summary:		Summary:
	Label requests are deferred in response to No Route and Loop		Label requests are deferred in response to No Route and Loop
	Detected notifications. When a deferred FEC label request for a		Detected notifications. When a deferred FEC label request for a
	peer times out, the LSR sends the label request.		peer times out, the LSR sends the label request.
	Context:		Context:
End of changes. 93 change blocks.
	117 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/