draft-ietf-mpls-fr-02.txt		draft-ietf-mpls-fr-03.txt
	MPLS Working Group A. Conta (Lucent)		MPLS Working Group A. Conta (Lucent)
	INTERNET-DRAFT P. Doolan (Ennovate)		INTERNET-DRAFT P. Doolan (Ennovate)
	A. Malis (Ascend)		A. Malis (Ascend)
	22 October 1998		16 November 1998
	Use of Label Switching on Frame Relay Networks		Use of Label Switching on Frame Relay Networks
	Specification		Specification
	draft-ietf-mpls-fr-02.txt		draft-ietf-mpls-fr-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute		and its Working Groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months. Internet-Drafts may be updated, replaced, or obsoleted by		months. Internet-Drafts may be updated, replaced, or obsoleted by
	skipping to change at line 38		skipping to change at line 38
	Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern		Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific		Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
	Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).		Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
	Abstract		Abstract
	This document defines the model and generic mechanisms for		This document defines the model and generic mechanisms for
	Multiprotocol Label Switching on Frame Relay networks. Furthermore,		Multiprotocol Label Switching on Frame Relay networks. Furthermore,
	it extends and clarifies portions of the Multiprotocol Label		it extends and clarifies portions of the Multiprotocol Label
	Switching Architecture described in [ARCH] and the Label Distribution		Switching Architecture described in [ARCH] and the Label Distribution
	Protocol described in [LDP] relative to Frame Relay Networks. MPLS		Protocol (LDP) described in [LDP] relative to Frame Relay Networks.
	enables the use of Frame Relay Switches as Label Switching Routers		MPLS enables the use of Frame Relay Switches as Label Switching
	(LSRs).		Routers (LSRs).
	(Conta & Doolan & Malis) Draft expires in six months [Page 1]		(Conta & Doolan & Malis) Draft expires in six months [Page 1]
	Table of Contents		Table of Contents
	Status of this Memo.........................................1		Status of this Memo.........................................1
	Table of Contents...........................................2		Table of Contents...........................................2
	1. Introduction................................................3		1. Introduction................................................3
	2. Terminology.................................................3		2. Terminology.................................................3
	3. Special Characteristics of Frame Relay Switches.............4		3. Special Characteristics of Frame Relay Switches.............5
	4. Label Encapsulation.........................................5		4. Label Encapsulation.........................................5
	5. Frame Relay Label Switching Processing......................6		5. Frame Relay Label Switching Processing......................7
	5.1 Use of DLCIs..............................................6		5.1 Use of DLCIs..............................................7
	5.2 Homogeneous LSPs..........................................7		5.2 Homogeneous LSPs..........................................8
	5.3 Heterogeneous LSPs........................................7		5.3 Heterogeneous LSPs........................................8
	5.4 Frame Relay Label Switching Loop Prevention and Control...8		5.4 Frame Relay Label Switching Loop Prevention and Control...8
	5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............8		5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............9
	5.4.2 Performing MPLS TTL calculations.......................9		5.4.2 Performing MPLS TTL calculations......................10
	5.5 Label Processing by Ingress FR-LSRs......................11		5.5 Label Processing by Ingress FR-LSRs......................13
	5.6 Label Processing by Core FR-LSRs.........................12		5.6 Label Processing by Core FR-LSRs.........................14
	5.7 Label Processing by Egress FR-LSRs.......................12		5.7 Label Processing by Egress FR-LSRs.......................14
	6 Label Switching Control Component for Frame Relay..........13		6 Label Switching Control Component for Frame Relay..........15
	6.1 Hybrid Switches (Ships in the Night) ...................14		6.1 Hybrid Switches (Ships in the Night) ...................16
	7 Label Allocation and Maintenance Procedures ...............14		7 Label Allocation and Maintenance Procedures ...............16
	7.1 Edge LSR Behavior........................................14		7.1 Edge LSR Behavior........................................16
	7.2 Efficient use of label space-Merging FR-LSRs.............17		7.2 Efficient use of label space-Merging FR-LSRs.............19
	7.3 LDP message fields specific to Frame Relay...............17		7.3 LDP message fields specific to Frame Relay...............20
	8 Security Considerations ..................................19		8 Security Considerations ..................................22
	9 Acknowledgments ..........................................20		9 Acknowledgments ..........................................23
	10 References ...............................................20		10 References ...............................................23
	11 Authors' Addresses .......................................21		11 Authors' Addresses .......................................24
			Appendix A - changes since previous versions..................25
	(Conta & Doolan & Malis) Draft expires in six months [Page 2]		(Conta & Doolan & Malis) Draft expires in six months [Page 2]
	1. Introduction		1. Introduction
	The Multiprotocol Label Switching Architecture is described in		The Multiprotocol Label Switching Architecture is described in
	[ARCH]. It is possible to use Frame Relay switches as Label Switching		[ARCH]. It is possible to use Frame Relay switches as Label Switching
	Routers. Such Frame Relay switches run network layer routing		Routers. Such Frame Relay switches run network layer routing
	algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based		algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based
	on the results of these routing algorithms. No specific Frame Relay		on the results of these routing algorithms. No specific Frame Relay
	routing is needed.		routing is needed.
	When a Frame Relay switch is used for label switching, the current		When a Frame Relay switch is used for label switching, the top
	label, on which forwarding decisions are based, is carried in the		(current) label, on which forwarding decisions are based, is carried
	DLCI field of the Frame Relay data link layer header of a frame.		in the DLCI field of the Frame Relay data link layer header of a
	Additional information carried along with the current label, but not		frame. Additional information carried along with the top (current)
	processed by Frame Relay switching, along with other labels, if the		label, but not processed by Frame Relay switching, along with other
	packet is multiply labeled, are carried in the generic MPLS		labels, if the packet is multiply labeled, are carried in the generic
	encapsulation defined in [STACK].		MPLS encapsulation defined in [STACK].
	Frame Relay permanent virtual circuits (PVCs) could be configured to		Frame Relay permanent virtual circuits (PVCs) could be configured to
	carry label switching based traffic. The DLCIs would be used as MPLS		carry label switching based traffic. The DLCIs would be used as MPLS
	Labels and the Frame Relay switches would become MPLS switches while		Labels and the Frame Relay switches would become Frame Relay Label
	the MPLS traffic would be encapsulated according to this		Switching Routers, while the MPLS traffic would be encapsulated
	specification, and would be forwarded based on network layer routing		according to this specification, and would be forwarded based on
	information.		network layer routing information.
	The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,		The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
	SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as		SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
	defined in RFC 2119.		defined in RFC 2119.
			This document is a companion document to [STACK] and [ATM].
	2. Terminology		2. Terminology
	LSR		LSR
	A Label Switching Router (LSR) is a device which implements the		A Label Switching Router (LSR) is a device which implements the
	label switching control and forwarding components described in		label switching control and forwarding components described in
	[ARCH].		[ARCH].
	LC-FR		LC-FR
	A label switching controlled Frame Relay (LC-FR) interface is a		A label switching controlled Frame Relay (LC-FR) interface is a
	Frame Relay interface controlled by the label switching control		Frame Relay interface controlled by the label switching control
	component. Packets traversing such an interface carry labels in		component. Packets traversing such an interface carry labels in
	the DLCI field.		the DLCI field.
	FR-LSR		FR-LSR
	A FR-LSR is an LSR with one or more LC-FR interfaces which
	(Conta & Doolan & Malis) Draft expires in six months [Page 3]		(Conta & Doolan & Malis) Draft expires in six months [Page 3]
	forwards frames onto these interfaces using labels carried in		A FR-LSR is an LSR with one or more LC-FR interfaces which
	the DLCI field.		forwards frames between two such interfaces using labels carried
			in the DLCI field.
	FR-LSR cloud		FR-LSR domain
	A FR-LSR cloud is a set of FR-LSRs, which are mutually		A FR-LSR domain is a set of FR-LSRs, which are mutually
	interconnected by LC-FR interfaces.		interconnected by LC-FR interfaces.
	Edge Set		Edge Set
	The Edge Set of an FR-LSR cloud is the set of LSRs, which are		The Edge Set of an FR-LSR domain is the set of LSRs, which are
	connected to the cloud by LC-FR interfaces.		connected to the domain by LC-FR interfaces.
			Forwarding Encapsulation
			The Forwarding Encapsulation is the type of MPLS encapsulation
			(Frame Relay, ATM, Generic) of a packet that determines the
			packet's MPLS forwarding, or the network layer encapsulation if
			that packet is forwarded based on the network layer (IP,
			etc...)header.
			Input Encapsulation
			The Input Encapsulation is the type of MPLS encapsulation (Frame
			Relay, ATM, Generic) of a packet when that packet is received on
			an LSR's interface, or the network layer (IP,
			etc...)encapsulation if that packet has no MPLS encapsulation.
			Output Encapsulation
			The Output Encapsulation is the type of MPLS encapsulation
			(Frame Relay, ATM, Generic) of a packet when that packet is
			transmitted on an LSR's interface, or the network layer (IP,
			etc...)encapsulation if that packet has no MPLS encapsulation.
			Input TTL
			The Input TTL is the MPLS TTL of the top of the stack when a
			labeled packet is received on an LSR interface, or the network
			layer (IP) TTL if the packet is not labeled.
			Output TTL
			The Output TTL is the MPLS TTL of the top of the stack when a
			labeled packet is transmitted on an LSR interface, or the
			network layer (IP) TTL if the packet is not labeled.
			(Conta & Doolan & Malis) Draft expires in six months [Page 4]
	Additionally, this document uses terminology from [ARCH].		Additionally, this document uses terminology from [ARCH].
	3. Special characteristics of Frame Relay Switches		3. Special characteristics of Frame Relay Switches
	While the label switching architecture permits considerable		While the label switching architecture permits considerable
	flexibility in LSR implementation, a FR-LSR is constrained by the		flexibility in LSR implementation, a FR-LSR is constrained by the
	capabilities of the (possibly pre-existing) hardware and the		capabilities of the (possibly pre-existing) hardware and the
	restrictions on such matters as frame format imposed by the		restrictions on such matters as frame format imposed by the
	Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay		Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay
	skipping to change at line 170		skipping to change at line 208
	- congestion control is performed by each node based on parameters		- congestion control is performed by each node based on parameters
	that are passed at circuit creation. Flags in the frame headers		that are passed at circuit creation. Flags in the frame headers
	may be set as a consequence of congestion, or exceeding the		may be set as a consequence of congestion, or exceeding the
	contractual parameters of the circuit.		contractual parameters of the circuit.
	- although in a standard switch it may be possible to configure		- although in a standard switch it may be possible to configure
	multiple input DLCIs to one output DLCI resulting in a		multiple input DLCIs to one output DLCI resulting in a
	multipoint-to-point circuit, multipoint-to-multipoint VCs are		multipoint-to-point circuit, multipoint-to-multipoint VCs are
	generally not fully supported.		generally not fully supported.
	(Conta & Doolan & Malis) Draft expires in six months [Page 4]
	This document describes ways of applying label switching to Frame		This document describes ways of applying label switching to Frame
	Relay switches, which work within these constraints.		Relay switches, which work within these constraints.
	4. Label Encapsulation		4. Label Encapsulation
	By default, all labeled packets should be transmitted with the		By default, all labeled packets should be transmitted with the
	generic label encapsulation as defined in [STACK], using the frame		generic label encapsulation as defined in [STACK], using the frame
	relay null encapsulation mechanism. The labels implicitly encode the		relay null encapsulation mechanism:
	network protocol type, consequently those particular labels cannot be
	used with other network protocols. Rules regarding the construction
	of the label stack, and error messages returned to the frame source
	are also described in [STACK].
			(Conta & Doolan & Malis) Draft expires in six months [Page 5]
	0 1 (Octets)		0 1 (Octets)
	+-----------------------+-----------------------+		+-----------------------+-----------------------+
	(Octets)0 | |		(Octets)0 | |
	/ Q.922 Address /		/ Q.922 Address /
	/ (length 'n' equals 2 or 4) /		/ (length 'n' equals 2 or 4) /
	| |		| |
	+-----------------------+-----------------------+		+-----------------------+-----------------------+
	n | . |		n | . |
	/ . /		/ . /
	/ MPLS packet /		/ MPLS packet /
	skipping to change at line 213		skipping to change at line 247
	7 6 5 4 3 2 1 0 (bit order)		7 6 5 4 3 2 1 0 (bit order)
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	(octet) 0 | DLCI(high order) | 0 | 0 |		(octet) 0 | DLCI(high order) | 0 | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	1 | DLCI(low order) | 0 | 0 | 0 | 1 |		1 | DLCI(low order) | 0 | 0 | 0 | 1 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	10 bits DLCI		10 bits DLCI
	(Conta & Doolan & Malis) Draft expires in six months [Page 5]
	7 6 5 4 3 2 1 0 (bit order)		7 6 5 4 3 2 1 0 (bit order)
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	(octet) 0 | DLCI(high order) | 0 | 0 |		(octet) 0 | DLCI(high order) | 0 | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	1 | DLCI | 0 | 0 | 0 | 0 |		1 | DLCI | 0 | 0 | 0 | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	2 | DLCI(low order) | 0 |		2 | DLCI(low order) | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	3 | unused (set to 0) | 1 | 1 |		3 | unused (set to 0) | 1 | 1 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	17 bits DLCI		17 bits DLCI
			(Conta & Doolan & Malis) Draft expires in six months [Page 6]
	7 6 5 4 3 2 1 0 (bit order)		7 6 5 4 3 2 1 0 (bit order)
	+-----+-----+-----+-----+-----+-----+-----+-----00		+-----+-----+-----+-----+-----+-----+-----+-----00
	(octet) 0 | DLCI(high order) | 0 | 0 |		(octet) 0 | DLCI(high order) | 0 | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----		+-----+-----+-----+-----+-----+-----+-----+-----
	1 | DLCI | 0 | 0 | 0 | 0 |		1 | DLCI | 0 | 0 | 0 | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	2 | DLCI | 0 |		2 | DLCI | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	3 | DLCI (low order) | 0 | 1 |		3 | DLCI (low order) | 0 | 1 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	23 bits DLCI		23 bits DLCI
	The generic encapsulation contains "n" labels for a label stack of depth		The use of the frame relay null encapsulation implies that labels
	"n" [STACK], where the top stack entry carries significant values for		implicitly encode the network protocol type.
	the EXP, S , and TTL fields [STACK] but not for the label, which is
	rather carried in the DLCI field of the Frame Relay data link header		Rules regarding the construction of the label stack, and error
	encoded in Q.922 [ITU] address format.		messages returned to the frame source are also described in [STACK].
			The generic encapsulation contains "n" labels for a label stack of
			depth "n" [STACK], where the top stack entry carries significant
			values for the EXP, S , and TTL fields [STACK] but not for the label,
			which is rather carried in the DLCI field of the Frame Relay data
			link header encoded in Q.922 [ITU] address format.
	5. Frame Relay Label Switching Processing		5. Frame Relay Label Switching Processing
	5.1 Use of DLCIs		5.1 Use of DLCIs
	Label switching is accomplished by associating labels with routes and		Label switching is accomplished by associating labels with routes and
	using the label value to forward packets, including determining the		using the label value to forward packets, including determining the
	value of any replacement label. See [ARCH] for further details. In a		value of any replacement label. See [ARCH] for further details. In a
	FR-LSR, the current (top) MPLS label is carried in the DLCI field of		FR-LSR, the top (current) MPLS label is carried in the DLCI field of
	the Frame Relay data link layer header of the frame. The top label		the Frame Relay data link layer header of the frame. The top label
	carries implicitly information about the network protocol type.		carries implicitly information about the network protocol type.
	For two connected FR-LSRs, a full-duplex connection must be available		For two connected FR-LSRs, a full-duplex connection must be available
	for LDP. The DLCI for the LDP VC is assigned a value by way of		for LDP. The DLCI for the LDP VC is assigned a value by way of
	configuration, similar to configuring the DLCI used to run IP routing		configuration, similar to configuring the DLCI used to run IP routing
	(Conta & Doolan & Malis) Draft expires in six months [Page 6]
	protocols between the switches.		protocols between the switches.
	With the exception of this configured value, the DLCI values used for		With the exception of this configured value, the DLCI values used for
	MPLS in the two directions of the link may be treated as belonging to		MPLS in the two directions of the link may be treated as belonging to
	two independent spaces, i.e. VCs may be half-duplex, each direction		two independent spaces, i.e. VCs may be half-duplex, each direction
	with its own DLCI. In case of DLCI aggregation (DLCI space		with its own DLCI.
	conservation), half-duplex (unidirectional) VCs are desired, since a
	"many to few" aggregation is possible in one direction but not in
	reverse.
	The allowable ranges of DLCIs are always communicated through LDP.		(Conta & Doolan & Malis) Draft expires in six months [Page 7]
	Note that the range of DLCIs used for labels depends on the size of		The allowable ranges of DLCIs, the size of DLCIs, and the support for
	the DLCI field.		VC merging MUST be communicated through LDP messages. Note that the
			range of DLCIs used for labels depends on the size of the DLCI field.
	5.2 Homogeneous LSPs		5.2 Homogeneous LSPs
	If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1, LSR2, and		If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1, LSR2, and
	LSR3 will use the same encoding of the label stack when transmitting		LSR3 will use the same encoding of the label stack when transmitting
	packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is		packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is
	homogeneous.		homogeneous.
	5.3 Heterogeneous LSPs		5.3 Heterogeneous LSPs
	skipping to change at line 298		skipping to change at line 334
	to LSR3. In general, the MPLS architecture supports LSPs with		to LSR3. In general, the MPLS architecture supports LSPs with
	different label stack encodings on different hops. When a labeled		different label stack encodings on different hops. When a labeled
	packet is received, the LSR must decode it to determine the current		packet is received, the LSR must decode it to determine the current
	value of the label stack, then must operate on the label stack to		value of the label stack, then must operate on the label stack to
	determine the new label value of the stack, and then encode the new		determine the new label value of the stack, and then encode the new
	value appropriately before transmitting the labeled packet to its		value appropriately before transmitting the labeled packet to its
	next hop.		next hop.
	Naturally there will be MPLS networks which contain a combination of		Naturally there will be MPLS networks which contain a combination of
	Frame Relay switches operating as LSRs, and other LSRs, which operate		Frame Relay switches operating as LSRs, and other LSRs, which operate
	using other MPLS encapsulations, such as the MPLS shim header, or ATM		using other MPLS encapsulations, such as the Generic (MPLS shim
	encapsulation. In such networks there may be some LSRs, which have		header), or ATM encapsulation. In such networks there may be some
	Frame Relay interfaces as well as "MPLS Shim" interfaces. This is one		LSRs, which have Frame Relay interfaces as well as MPLS Generic
	example of an LSR with different label stack encodings on different		("MPLS Shim") interfaces. This is one example of an LSR with
	hops of the same LSP. Such an LSR may swap off a Frame Relay encoded		different label stack encodings on different hops of the same LSP.
	label on an incoming interface and replace it with a label encoded		Such an LSR may swap off a Frame Relay encoded label on an incoming
	into an MPLS shim header on the outgoing interface.		interface and replace it with a label encoded into a Generic MPLS
			(MPLS shim) header on the outgoing interface.
	(Conta & Doolan & Malis) Draft expires in six months [Page 7]
	5.4 Frame Relay Label Switching Loop Prevention and Control		5.4 Frame Relay Label Switching Loop Prevention and Control
	FR-LSRs MUST use a mechanism that insures loop free FR- LSPs or LSP		FR-LSRs SHOULD operate on loop free FR-LSPs or LSP Frame Relay
	FR segments. Such mechanisms are described in [ARCH], and [LDP].		segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use
			loop prevention mechanisms as described in [ARCH], and [LDP].
			(Conta & Doolan & Malis) Draft expires in six months [Page 8]
	5.4.1 FR-LSRs Loop Control - MPLS TTL processing		5.4.1 FR-LSRs Loop Control - MPLS TTL processing
	The MPLS TTL encoded in the MPLS label stack is a mechanism used to:		The MPLS TTL encoded in the MPLS label stack is a mechanism used to:
	(a) suppress loops;		(a) suppress loops;
	(b) limit the scope of a packet.		(b) limit the scope of a packet.
	When a packet travels along an LSP, it should emerge with the same		When a packet travels along an LSP, it should emerge with the same
	skipping to change at line 339		skipping to change at line 377
	stack entry from the previous TTL value, whether that is from the		stack entry from the previous TTL value, whether that is from the
	network layer header when no previous label stack existed, or from a		network layer header when no previous label stack existed, or from a
	pre-existent lower level label stack entry.		pre-existent lower level label stack entry.
	A FR-LSR switching same level labeled packets does not decrement the		A FR-LSR switching same level labeled packets does not decrement the
	MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment".		MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment".
	When a packet emerges from a "non-TTL LSP segment", it should however		When a packet emerges from a "non-TTL LSP segment", it should however
	reflect in the TTL the number of LSR-hops it traversed. In the		reflect in the TTL the number of LSR-hops it traversed. In the
	unicast case, this can be achieved by propagating a meaningful LSP		unicast case, this can be achieved by propagating a meaningful LSP
	length or LSP segment length to the FR-LSR ingress nodes, enabling		length or LSP Frame Relay segment length to the FR-LSR ingress nodes,
	the ingress to decrement the TTL value before forwarding packets into		enabling the ingress to decrement the TTL value before forwarding
	a non-TTL LSP segment [ARCH].		packets into a non-TTL LSP segment [ARCH].
	When an ingress FR-LSR determines upon decrementing the MPLS TTL that		When an ingress FR-LSR determines upon decrementing the MPLS TTL that
	a particular packet's TTL will expire before the packet reaches the		a particular packet's TTL will expire before the packet reaches the
	egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch		egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch
	the packet, but rather follow the specifications in [STACK] in an		the packet, but rather follow the specifications in [STACK] in an
	attempt to return an error message to the packet's source.		attempt to return an error message to the packet's source:
			- it treats the packet as an expired packet and return an ICMP
			message to its source.
			- it forwards the packet, as an unlabeled packet, with a TTL
			that reflects the IP (network layer) forwarding.
			If the incoming TTL is 1, only the first option applies.
	In the multicast case, a meaningful LSP length or LSP segment length		In the multicast case, a meaningful LSP length or LSP segment length
	is propagated to the FR-LSR egress node, enabling the egress to		is propagated to the FR-LSR egress node, enabling the egress to
			(Conta & Doolan & Malis) Draft expires in six months [Page 9]
	decrement the TTL value before forwarding packets out of the non-TTL		decrement the TTL value before forwarding packets out of the non-TTL
	LSP segment.		LSP segment.
	(Conta & Doolan & Malis) Draft expires in six months [Page 8]
	5.4.2 Performing MPLS TTL calculations		5.4.2 Performing MPLS TTL calculations
	Considering the "incoming TTL" the MPLS TTL of the top of the stack		The calculation applied to the "input TTL" that yields the "output
	when a labeled packet is received, and the "output TTL" the MPLS TTL		TTL" depends on (i)the "input encapsulation", (ii)the "forwarding
	of the top of the stack when a packet leaves a node, the relationship		encapsulation", and (iii)the "output encapsulation". The
	between the two is defined as a function of the type of the output		relationship among (i),(ii), and (iii), can be defined as a function
	interface, and the type of transmit operation done on the output		"D" of "input encapsulation" (ie), "forwarding encapsulation" (fe),
	interface (unicast or multicast):		and "output encapsulation" (oe). Subsequently the calculation applied
			to the "input TTL" to yield the "output TTL" can be described as:
	output TTL = function (input TTL, output interface type, type of transmit)=
	= input TTL - funct (output interface type, type of transmit)		output TTL = input TTL - D(ie, fe, oe)
	Considering the symbol "I" for an IP interface, the symbol "G" for a		or in a brief notation:
	generic MPLS encapsulating interface, the symbol "A" for a MPLS ATM
	encapsulating
	interface, the symbol "F" for a MPLS FR encapsulating interface, and
	"G_G", "F_G", etc... LSRs with specific input and output interfaces,
	and also the symbols "O.TTL" and "I.TTL" for the "output" and "input"
	TTL, the following describes the possible combinations:
	input,output Unicast		output TTL = input TTL - d
	->G_G-> O.TTL = I.TTL - 1		where "d" has three possible values: "0","1", or "the number of hops
			of the LSP segment":
	->F_G-> O.TTL = I.TTL - nr. of hops of starting segment (ingress F)		For unicast transmission:
	->G_F-> O.TTL = I.TTL - 1 (egress F)
	->A_F-> O.TTL = I.TTL - nr. of hops of starting segment (ingress F)		+================+=================+=================+=================+
	->F_A-> O.TTL = I.TTL - 1 (egress F)		| | Type of | Type of | Type of |
			| d | Input | Forwarding | Output |
			| | Encapsulation | Encapsulation | Encapsulation |
			+================+=================+=================+=================+
			| 0 | Frame Relay | Frame Relay | Frame Relay |
			+----------------+-----------------+-----------------+-----------------+
			| 1 | any | Generic MPLS | Generic MPLS |
			+----------------+-----------------+-----------------+-----------------+
			| number of hops | | Generic MPLS | |
			| of | any | or | Frame Relay |
			| LSP segment | |IP(network layer)| |
			+================+=================+=================+=================+
	->F_F-> similar to ->A A-> no TTL processing		The "number of hops of the LSP segment" is the value of the "hop
			count" that is attached with the label used when the packet is
			forwarded, if LDP [LDP] has provided such a "hop count" value when it
			distributed the label for the LSP, that is the LDP message had a "hop
			count object". If LDP didn't provide a "hop count", or it provided an
			"unknown" value, the default value of the "number of hops of the
			segment" is 1.
	input,output Multicast		When sending a label binding upstream, the "hop count" associated
	->G_G-> O.TTL = I.TTL - 1		(Conta & Doolan & Malis) Draft expires in six months [Page 10]
			with the corresponding binding from downstream, if different than the
			"unknown" value, MUST be incremented by 1, and the result transmitted
			upstream as the hop count associated with the new binding (the
			"unknown" value is transmitted unchanged). If the new "hop count"
			value exceeds the "maximum" value, the FR-LSR MUST NOT pass the
			binding upstream, but instead MUST send an error upstream
			[LDP][ARCH].
	->G_F-> O.TTL = I.TTL - 1 (ingress F)		For multicast transmission:
	->F_G-> O.TTL = I.TTL - nr. of hops of ending segment (egress F)
	->A_F-> O.TTL = I.TTL - 1 (ingress F)		+================+=================+=================+=================+
	->F_A-> O.TTL = I.TTL - nr. of hops of ending segment (egress F)		| | Type of | Type of | Type of |
			| d | Input | Forwarding | Output |
			| | Encapsulation | Encapsulation | Encapsulation |
			+================+=================+=================+=================+
			| 0 | Frame Relay | Frame Relay | Frame Relay |
			+----------------+-----------------+-----------------+-----------------+
			| | | Generic MPLS | |
			| 1 | any | or | Frame Relay |
			| | |IP(network layer)| |
			+----------------+-----------------+-----------------+-----------------+
			| number of hops | | Generic MPLS | |
			| of | Frame Relay | or | any |
			| LSP segment | |IP(network layer)| |
			+================+=================+=================+=================+
	->F_F-> similar to ->A A-> no TTL processing		Referring to the "forwarding encapsulation" with the abbreviation "I"
			for IP (network layer), "G" for Generic MPLS, and "F" for Frame
			Relay MPLS, referring to an LSR interface with the abbreviation "i"
			if the input or output encapsulation is IP and no MPLS encapsulation,
			"g" when the input or output MPLS encapsulation is Generic MPLS, "f"
			when it is Frame Relay, "a" when it is ATM, and furthermore
			considering the symbols "iIf", "gGf", "fFf", etc... as LSRs with
			input, forwarding and output encapsulations as referred above, the
			following describes examples of TTL calculations for the Homogeneous
			and Heterogeneous LSPs discussed in previous sections:
	(Conta & Doolan & Malis) Draft expires in six months [Page 9]
	Homogeneous LSP		Homogeneous LSP
			---------------
			IP_ttl = n IP_ttl=mpls_ttl-1 = n-6
			--------->iIf fIi--------->
			| mpls_ttl = n-5 ^
			| |
			number of hops 1| Frame Relay |5
			| |
			V 2 3 4 |
			fFf--->fFf--->fFf--->fFf
	--->I_F Frame Relay F_I--->		(Conta & Doolan & Malis) Draft expires in six months [Page 11]
	hops = 5 | |		"iIf" is "ingress LSR" in Frame Relay LSP and
	F_F--->F_F--->F_F--->F_F		calculates: mpls_ttl = IP_TTL - number of hops = n-5
	loop free		"fIi" is "egress LSR" from Frame Relay LSP, and
	ip_ttl = n ip_ttl=n-6		calculates: IP_ttl = mpls_ttl-1 = n-6
	mpls_ttl = n-5 n-5
	Heterogeneous LSP		Heterogeneous LSP
			-----------------
			ingress LSR egress LSR
			IP_ttl = n IP_ttl = n - 15
			links LAN PPP FR ATM PPP FR LAN
			--->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi--->
			hops 1 2 | 6 | | 9 | 10 | 13 ^ 14 15
			|1 4| |1 3| |1 3|
			V 2 3 | V 2 | V 2 |
			fFf-->fFf-->fFf aAa-->aAa fFf-->fFf
			mpls_ttl
			n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14
	LSP LSP		"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
	ingress egress		"gGf" is "egress LSR" from Generic MPLS segment, and
			"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6
	LAN PPP FR ATM PPP FR LAN		"fGa" "egress LSR" from Frame Relay segment, and
			"ingress LSR" in ATM segment and calculates: mpls_ttl=n-9
	--->I_G-->G_G-->G_F F_A A_G-->G_F F_G-->G_I--->		"gGf" is "egress LSR" from Generic MPLS segment, and
	| / | | | |		"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13
	hops 1 1 | 4 / | 3 | 1 | 3 | 1 1		"fGg" is "egress LSR" from Frame Relay segment, and
	F_F--F_F--F_F A_A--A_A F_F--F_F		ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14
			"gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15
	loop free loop free loop free		And further examples:
	ip_ttl
	n n-15
	mpls_ttl
	n-1 n-2 n-6 n-9 n-10 n-13 n-14
	Unicast -- TTL calculated at ingress		Frame Relay Unicast -- TTL calculated at ingress
	1 2 3 4		(ingress LSR) 1 2 3 4
	o-------o-------o-------o-------o		x--->---+--->---+--->>--+-->>---x (egress LSR)
	ttl=n-4 / 2 3		o.ttl=i.ttl-4 | 2 3
	/		^
	hops 1/		hops 1|
	/		|
	o ttl=n-3		x (ingress LSR)
			o.ttl=i.ttl-3
	(Conta & Doolan & Malis) Draft expires in six months [Page 10]		(Conta & Doolan & Malis) Draft expires in six months [Page 12]
	Multicast -- TTL calculated at egress		Frame Relay Multicast -- TTL calculated at egress
	o ttl=n-3		(egress LSR)x o.ttl=i.ttl-3
	hops /		hops |
	3/		^3
	/ ttl=n-4		(ingress LSR) | o.ttl=i.ttl-4
	o-------o-------o-------o-------o		x--->---+--->---+--->---+--->---x (egress LSR)
	1 2 3 4		1 2 3 4
	5.5 Label Processing by Ingress FR-LSRs		5.5 Label Processing by Ingress FR-LSRs
	When a packet first enters an MPLS domain, the packet is forwarded by		When a packet first enters an MPLS domain, the packet is forwarded by
	normal network layer forwarding operations with the exception that		normal network layer forwarding operations with the exception that
	the outgoing encapsulation will include an MPLS label stack [STACK]		the outgoing encapsulation will include an MPLS label stack [STACK]
	with at least one entry. The frame relay null encapsulation will		with at least one entry. The frame relay null encapsulation will
	carry information about the network layer protocol implicitly in the		carry information about the network layer protocol implicitly in the
	label, which MUST be associated only with that network protocol. The		label, which MUST be associated only with that network protocol. The
	skipping to change at line 485		skipping to change at line 585
	For multicast packets, the MPLS TTL SHOULD be decremented by 1. An		For multicast packets, the MPLS TTL SHOULD be decremented by 1. An
	LDP constructing the LSP SHOULD pass meaningful information to the		LDP constructing the LSP SHOULD pass meaningful information to the
	egress FR-LSR regarding the number of hops of the "non-TTL segment".		egress FR-LSR regarding the number of hops of the "non-TTL segment".
	Next, the MPLS encapsulated packet is passed down to the Frame Relay		Next, the MPLS encapsulated packet is passed down to the Frame Relay
	data link driver with the top label as output DLCI. The Frame Relay		data link driver with the top label as output DLCI. The Frame Relay
	frame carrying the MPLS encapsulated packet is forwarded onto the		frame carrying the MPLS encapsulated packet is forwarded onto the
	Frame Relay VC to the next LSR.		Frame Relay VC to the next LSR.
	(Conta & Doolan & Malis) Draft expires in six months [Page 11]		(Conta & Doolan & Malis) Draft expires in six months [Page 13]
	5.6 Label Processing by Core FR-LSRs		5.6 Label Processing by Core FR-LSRs
	In a FR-LSR, the current (top) MPLS label is carried in the DLCI		In a FR-LSR, the current (top) MPLS label is carried in the DLCI
	field of the Frame Relay data link layer header of the frame. Just as		field of the Frame Relay data link layer header of the frame. Just as
	in conventional Frame Relay, for a frame arriving at an interface,		in conventional Frame Relay, for a frame arriving at an interface,
	the DLCI carried by the Frame Relay data link header is looked up in		the DLCI carried by the Frame Relay data link header is looked up in
	the DLCI Information Base, replaced with the correspondent output		the DLCI Information Base, replaced with the correspondent output
	DLCI, and transmitted on the outgoing interface (forwarded to the		DLCI, and transmitted on the outgoing interface (forwarded to the
	next hop node).		next hop node).
	skipping to change at line 535		skipping to change at line 635
	For unicast packets, the MPLS TTL SHOULD be decremented by one if the		For unicast packets, the MPLS TTL SHOULD be decremented by one if the
	output interface is a generic one, or with the number of hops of the		output interface is a generic one, or with the number of hops of the
	next ATM segment of the LSP (heterogeneous), if the output interface		next ATM segment of the LSP (heterogeneous), if the output interface
	is an ATM (non-TTL) interface.		is an ATM (non-TTL) interface.
	For multicast packets, the MPLS TTL SHOULD be decremented by the		For multicast packets, the MPLS TTL SHOULD be decremented by the
	number of hops of the FR segment being exited. An LDP constructing		number of hops of the FR segment being exited. An LDP constructing
	the LSP SHOULD pass meaningful information to the egress FR-LSR		the LSP SHOULD pass meaningful information to the egress FR-LSR
	regarding the number of hops of the FR "non-TTL segment".		regarding the number of hops of the FR "non-TTL segment".
	(Conta & Doolan & Malis) Draft expires in six months [Page 12]		(Conta & Doolan & Malis) Draft expires in six months [Page 14]
	6. Label Switching Control Component for Frame Relay		6. Label Switching Control Component for Frame Relay
	To support label switching a Frame Relay Switch MUST implement the		To support label switching a Frame Relay Switch MUST implement the
	control component of label switching, which consists primarily of		control component of label switching, which consists primarily of
	label allocation and maintenance procedures. Label binding		label allocation and maintenance procedures. Label binding
	information MAY be communicated by several mechanisms, one of which		information MAY be communicated by several mechanisms, one of which
	is the Label Distribution Protocol (LDP) [LDP].		is the Label Distribution Protocol (LDP) [LDP].
	Since the label switching control component uses information learned		Since the label switching control component uses information learned
	skipping to change at line 582		skipping to change at line 682
	communicated through LDP.		communicated through LDP.
	Support of label switching on a Frame Relay switch requires		Support of label switching on a Frame Relay switch requires
	conformance only to [FRF] (framing, bit-stuffing, headers, FCS)		conformance only to [FRF] (framing, bit-stuffing, headers, FCS)
	except for section 2.3 (PVC control signaling procedures, aka LMI).		except for section 2.3 (PVC control signaling procedures, aka LMI).
	Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC		Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC
	signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or		signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or
	SVCs when both are running on the same interface as MPLS, as		SVCs when both are running on the same interface as MPLS, as
	discussed in the next section.		discussed in the next section.
	(Conta & Doolan & Malis) Draft expires in six months [Page 13]		(Conta & Doolan & Malis) Draft expires in six months [Page 15]
	6.1 Hybrid Switches (Ships in the Night)		6.1 Hybrid Switches (Ships in the Night)
	The existence of the label switching control component on a Frame		The existence of the label switching control component on a Frame
	Relay switch does not preclude the ability to support the Frame Relay		Relay switch does not preclude the ability to support the Frame Relay
	control component defined by the ITU and Frame Relay Forum on the		control component defined by the ITU and Frame Relay Forum on the
	same switch and the same interfaces (NICs). The two control		same switch and the same interfaces (NICs). The two control
	components, label switching and those defined by ITU/Frame Relay		components, label switching and those defined by ITU/Frame Relay
	Forum, would operate independently.		Forum, would operate independently.
	Definition of how such a device operates is beyond the scope of this		Definition of how such a device operates is beyond the scope of this
	document. However, only a small amount of information needs to be		document. However, only a small amount of information needs to be
	consistent between the two control components, such as the portions		consistent between the two control components, such as the portions
	of the DLCI space which are available to each component.		of the DLCI space which are available to each component.
	7. Label Allocation and Maintenance Procedures		7. Label Allocation and Maintenance Procedures
	The mechanisms and message formats of a Label Distribution Protocol		The mechanisms and message formats of a Label Distribution Protocol
	are documented in [ARCH] and [LDP]. A possible scenario for the		are documented in [ARCH] and [LDP]. The "downstream-on-demand" label
	label allocation and maintenance for FR-LSRs is "downstream-on-		allocation and maintenance mechanism discussed in this section MUST
	demand" as it follows (note that this applies to hop-by-hop routed		be used by FR-LSRs that do not support VC merging, and it MAY also be
	traffic):		used by FR-LSRs that do support VC merging (note that this mechanism
			applies to hop-by-hop routed traffic):
	7.1 Edge LSR Behavior		7.1 Edge LSR Behavior
	Consider a member of the Edge Set of a FR-LSR cloud. Assume that, as		Consider a member of the Edge Set of a FR-LSR domain. Assume that, as
	a result of its routing calculations, it selects a FR-LSR as the next		a result of its routing calculations, it selects a FR-LSR as the next
	hop of a certain route (FEC), and that the next hop is reachable via		hop of a certain route (FEC), and that the next hop is reachable via
	a LC-Frame Relay interface. Assume that the next-hop FR-LSR is an		a LC-Frame Relay interface. Assume that the next-hop FR-LSR is an
	"LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP "request" message		"LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP "request" message
	for a label binding from the next hop, downstream LSR. When the Edge		for a label binding from the next hop, downstream LSR. When the Edge
	LSR receives in response from the downstream LSR the label binding		LSR receives in response from the downstream LSR the label binding
	information in an LDP "mapping" message, the label is stored in the		information in an LDP "mapping" message, the label is stored in the
	Label Information Base (LIB) as an outgoing label for that FEC. The		Label Information Base (LIB) as an outgoing label for that FEC. The
	"mapping" message may contain the "hop count" object, which		"mapping" message may contain the "hop count" object, which
	represents the number of hops a packet will take to cross the FR-LSR		represents the number of hops a packet will take to cross the FR-LSR
	cloud to the Egress FR-LSR when using this label. This information		domain to the Egress FR-LSR when using this label. This information
	may be stored for TTL calculation. Once this is done, the LSR may use		may be stored for TTL calculation. Once this is done, the LSR may use
	MPLS forwarding to transmit packets in that FEC.		MPLS forwarding to transmit packets in that FEC.
	When a member of the Edge Set of the FR-LSR cloud receives an LDP		When a member of the Edge Set of the FR-LSR domain receives an LDP
	"request" message from a FR-LSR for a FEC, it means it is the		"request" message from a FR-LSR for a FEC, it means it is the
	Egress-FR-LSR. It allocates a label, creates a new entry in its Label		Egress-FR-LSR. It allocates a label, creates a new entry in its Label
	Information Base (LIB), places that label in the incoming label		Information Base (LIB), places that label in the incoming label
	component of the entry, and returns (via LDP) a "mapping" message
	(Conta & Doolan & Malis) Draft expires in six months [Page 14]		(Conta & Doolan & Malis) Draft expires in six months [Page 16]
			component of the entry, and returns (via LDP) a "mapping" message
	containing the allocated label back upstream to the LDP peer that		containing the allocated label back upstream to the LDP peer that
	originated the request. The "mapping" message contains the "hop		originated the request. The "mapping" message contains the "hop
	count" object value set to 1.		count" object value set to 1.
	When a routing calculation causes an Edge LSR to change the next hop		When a routing calculation causes an Edge LSR to change the next hop
	for a route, and the former next hop was in the FR-LSR cloud, the		for a route, and the former next hop was in the FR-LSR domain, the
	Edge LSR should notify the former next hop (via an LDP "release"		Edge LSR should notify the former next hop (via an LDP "release"
	message) that the label binding associated with the route is no		message) that the label binding associated with the route is no
	longer needed.		longer needed.
	When a Frame Relay-LSR receives an LDP "request" message for a		When a Frame Relay-LSR receives an LDP "request" message for a
	certain route (FEC) from an LDP peer connected to the FR-LSR over a		certain route (FEC) from an LDP peer connected to the FR-LSR over a
	LC-FR interface, the FR-LSR takes the following actions:		LC-FR interface, the FR-LSR takes the following actions:
	- it allocates a label, creates a new entry in its Label		- it allocates a label, creates a new entry in its Label
	Information Base (LIB), and places that label in the incoming		Information Base (LIB), and places that label in the incoming
	skipping to change at line 672		skipping to change at line 773
	count will be returned later, as described below.		count will be returned later, as described below.
	Since both the "ordered" and "independent" control has advantages and		Since both the "ordered" and "independent" control has advantages and
	disadvantages, this is left as an implementation, or configuration		disadvantages, this is left as an implementation, or configuration
	choice.		choice.
	Once the FR-LSR receives in response the label binding in an LDP		Once the FR-LSR receives in response the label binding in an LDP
	"mapping" message from the next hop, it places the label into the		"mapping" message from the next hop, it places the label into the
	outgoing label component of the LIB entry.		outgoing label component of the LIB entry.
	Note that a FR-LSR, or a member of the edge set of a FR-LSR cloud,		Note that a FR-LSR, or a member of the edge set of a FR-LSR domain,
	may receive multiple binding requests for the same route (FEC) from		may receive multiple binding requests for the same route (FEC) from
	the same FR-LSR. It must generate a new "mapping" for each "request"		the same FR-LSR. It must generate a new "mapping" for each "request"
	(assuming adequate resources to do so), and retain any existing		(assuming adequate resources to do so), and retain any existing
	mapping(s). For each "request" received, a FR-LSR should also
	(Conta & Doolan & Malis) Draft expires in six months [Page 15]		(Conta & Doolan & Malis) Draft expires in six months [Page 17]
			mapping(s). For each "request" received, a FR-LSR should also
	generate a new binding "request" toward the next hop for the route		generate a new binding "request" toward the next hop for the route
	(FEC).		(FEC).
	When a routing calculation causes a FR-LSR to change the next hop for		When a routing calculation causes a FR-LSR to change the next hop for
	a route (FEC), the FR-LSR should notify the former next hop (via an		a route (FEC), the FR-LSR should notify the former next hop (via an
	LDP "release" message) that the label binding associated with the		LDP "release" message) that the label binding associated with the
	route is no longer needed.		route is no longer needed.
	When a LSR receives a notification that a particular label binding is		When a LSR receives a notification that a particular label binding is
	no longer needed, the LSR may deallocate the label associated with		no longer needed, the LSR may deallocate the label associated with
	skipping to change at line 727		skipping to change at line 828
	neighbor of the change. Each FR-LSR in turn increments the hop count		neighbor of the change. Each FR-LSR in turn increments the hop count
	and passes it upstream until it reaches the ingress Edge LSR.		and passes it upstream until it reaches the ingress Edge LSR.
	Whenever a FR-LSR originates a label binding request to its next hop		Whenever a FR-LSR originates a label binding request to its next hop
	LSR as a result of receiving a label binding request from another		LSR as a result of receiving a label binding request from another
	(upstream) LSR, and the request to the next hop LSR is not satisfied,		(upstream) LSR, and the request to the next hop LSR is not satisfied,
	the FR-LSR should destroy the binding created in response to the		the FR-LSR should destroy the binding created in response to the
	received request, and notify the requester (via an LDP "withdraw"		received request, and notify the requester (via an LDP "withdraw"
	message).		message).
	(Conta & Doolan & Malis) Draft expires in six months [Page 16]		(Conta & Doolan & Malis) Draft expires in six months [Page 18]
	When an LSR determines that it has lost its LDP session with another		When an LSR determines that it has lost its LDP session with another
	LSR, the following actions are taken:		LSR, the following actions are taken:
	- MUST discard any binding information learned via this		- MUST discard any binding information learned via this
	connection;		connection;
	- For any label bindings that were created as a result of		- For any label bindings that were created as a result of
	receiving label binding requests from the peer, the LSR may		receiving label binding requests from the peer, the LSR may
	destroy these bindings (and deallocate labels associated		destroy these bindings (and deallocate labels associated
	with these binding).		with these binding).
	7.2 Efficient use of label space - Merging FR-LSRs		7.2 Efficient use of label space - Merging FR-LSRs
	The above discussion assumes that an edge LSR will request one label		The above discussion assumes that an edge LSR will request one label
	for each prefix in its routing table that has a next hop in the FR-		for each prefix in its routing table that has a next hop in the FR-
	LSR cloud. In fact, it is possible to significantly reduce the number		LSR domain. In fact, it is possible to significantly reduce the
	of labels needed by having the edge LSR request instead one label for		number of labels needed by having the edge LSR request instead one
	several routes. Use of many-to-one mappings between routes (address		label for several routes. Use of many-to-one mappings between routes
	prefixes) and labels using the notion of Forwarding Equivalence		(address prefixes) and labels using the notion of Forwarding
	Classes (as described in [ARCH]) provides a mechanism to conserve the		Equivalence Classes (as described in [ARCH]) provides a mechanism to
	number of labels.		conserve the number of labels.
	Note that conserving label space may be restricted in case the frame		Note that conserving label space (VC merging) may be restricted in
	traffic requires Frame Relay fragmentation. The issue is that Frame		case the frame traffic requires Frame Relay fragmentation. The issue
	Relay fragments must be transmitted in sequence, i.e. fragments of		is that Frame Relay fragments must be transmitted in sequence, i.e.
	distinct frames must not be interleaved. If the fragmenting FR-LSR		fragments of distinct frames must not be interleaved. If the
	ensures the transmission in sequence of all fragments of a frame,		fragmenting FR-LSR ensures the transmission in sequence of all
	without interleaving with fragments of other frames, then label		fragments of a frame, without interleaving with fragments of other
	conservation (aggregation) can be performed.		frames, then label conservation (VC merging) can be performed.
	In the case where the label space is to be conserved, it is desirable		When label conservation is used, when a FR-LSR receives a binding
	to use half-duplex (unidirectional) VCs, since a "many to few"		request from an upstream LSR for a certain FEC, and it does already
	aggregation is possible in one direction but not in reverse.		have an outgoing label binding for that FEC, it does not need to
			issue a downstream binding request. Instead, it may allocate an
			incoming label, and return that label in a binding to the upstream
			requester. Packets received from the requester, with that label as
			top label, will be forwarded after replacing the label with the
			existing outgoing label for that FEC. If the FR-LSR does not have an
			outgoing label binding for that FEC, but does have an outstanding
			request for one, it need not issue another request. This means that
			in a label conservation case, a FR-LSR must respond with a new
			binding for every upstream request, but it may need to send one
			binding request downstream.
			In case of label conservation, if a change in the routing table
			causes a FR-LSR to select a new next hop for one of its FECs, it MAY
			(Conta & Doolan & Malis) Draft expires in six months [Page 19]
			release the binding for that route from the former next hop. If it
			doesn't already have a corresponding binding for the new next hop, it
			must request one (note that the choice depends on the label retention
			mode [ARCH]).
			If a new binding is obtained, which contain a hop count that differs
			from that of the old binding, the FR-LSR must process the new hop
			count: increment by 1, if different than "unknown", and notify the
			upstream neighbors who have label bindings for this FEC of the new
			value. To ensure that loops will be detected, if the new hop count
			exceeds the "maximum" value, the label values for this FEC must be
			withdrawn from all upstream neighbors to whom a binding was
			previously sent.
	7.3 LDP messages specific to Frame Relay		7.3 LDP messages specific to Frame Relay
	The Label Distribution Protocol [LDP] messages exchanged between two		The Label Distribution Protocol [LDP] messages exchanged between two
	Frame Relay "LDP-peer" LSRs may contain Frame Relay specific		Frame Relay "LDP-peer" LSRs may contain Frame Relay specific
	information such as:		information such as:
	(Conta & Doolan & Malis) Draft expires in six months [Page 17]
	"Frame Relay Label Range":		"Frame Relay Label Range":
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 795		skipping to change at line 923
	Len		Len
	This field specifies the number of bits of the DLCI. The following		This field specifies the number of bits of the DLCI. The following
	values are supported:		values are supported:
	Len DLCI bits		Len DLCI bits
	0 10		0 10
	1 17		1 17
	2 23		2 23
			(Conta & Doolan & Malis) Draft expires in six months [Page 20]
	Minimum DLCI		Minimum DLCI
	This 23 bit field is the binary value of the lower bound of a block		This 23 bit field is the binary value of the lower bound of a block
	of Data Link Connection Identifiers (DLCIs) that is supported by		of Data Link Connection Identifiers (DLCIs) that is supported by
	the originating FR-LSR. The Minimum DLCI should be right justified		the originating FR-LSR. The Minimum DLCI should be right justified
	in this field and the preceding bits should be set to 0.		in this field and the preceding bits should be set to 0.
	Maximum DLCI		Maximum DLCI
	This 23 bit field is the binary value of the upper bound of a block		This 23 bit field is the binary value of the upper bound of a block
	of Data Link Connection Identifiers (DLCIs) that is supported by		of Data Link Connection Identifiers (DLCIs) that is supported by
	the originating FR-LSR. The Maximum DLCI should be right justified		the originating FR-LSR. The Maximum DLCI should be right justified
	in this field and the preceding bits should be set to 0.		in this field and the preceding bits should be set to 0.
			"Frame Relay Merge":
			0 1 2 3 4 5 6 7
			+-+-+-+-+-+-+-+-+
			| Reserved |M|
			+-+-+-+-+-+-+-+-+
			with the following fields:
			Merge
			One bit field that specifies the merge capabilities of the FR-LSR:
			Value Meaning
			0 Merge NOT supported
			1 Merge supported
			A FR-LSR that supports VC merging MUST ensure that fragmented
			frames from distinct incoming DLCIs are not interleaved on the
			outgoing DLCI.
			Reserved
			This field is reserved. It must be set to zero on transmission and
			must be ignored on receipt.
	and "Frame Relay Label":		and "Frame Relay Label":
	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| DLCI |		| Reserved |Len| DLCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	with the following fields:		with the following fields:
	(Conta & Doolan & Malis) Draft expires in six months [Page 18]		(Conta & Doolan & Malis) Draft expires in six months [Page 21]
	Reserved		Reserved
	This field is reserved. It must be set to zero on transmission and		This field is reserved. It must be set to zero on transmission and
	must be ignored on receipt.		must be ignored on receipt.
	Len		Len
	This field specifies the number of bits of the DLCI. The following		This field specifies the number of bits of the DLCI. The following
	values are supported:		values are supported:
	Len DLCI bits		Len DLCI bits
	skipping to change at line 842		skipping to change at line 996
	DLCI		DLCI
	The binary value of the Frame Relay Label. The significant number		The binary value of the Frame Relay Label. The significant number
	of bits (10, 17, or 23) of the label value are to be encoded into		of bits (10, 17, or 23) of the label value are to be encoded into
	the Data Link Connection Identifier (DLCI) field when part of the		the Data Link Connection Identifier (DLCI) field when part of the
	Frame Relay data link header (see Section 4.).		Frame Relay data link header (see Section 4.).
	8. Security Considerations		8. Security Considerations
	This section looks at the security aspects of:		This section looks at the security aspects of:
	(a) frame traffic		(a) frame traffic,
	(b) label distribution.		(b) label distribution.
	MPLS encapsulation has no effect on authenticated or encrypted		MPLS encapsulation has no effect on authenticated or encrypted
	network layer packets, that is IP packets that are authenticated or		network layer packets, that is IP packets that are authenticated or
	encrypted will incur no change.		encrypted will incur no change.
	The MPLS protocol has no mechanisms of its own to protect against		The MPLS protocol has no mechanisms of its own to protect against
	misdirection of packets or the impersonation of an LSR by accident or		misdirection of packets or the impersonation of an LSR by accident or
	malicious intent.		malicious intent.
	Altering by accident or forgery an existent label in the DLCI field		Altering by accident or forgery an existent label in the DLCI field
	of the Frame Relay data link layer header of a frame or one or more		of the Frame Relay data link layer header of a frame or one or more
	fields in a potentially following label stack affects the forwarding		fields in a potentially following label stack affects the forwarding
	of that frame.		of that frame.
	The label distribution mechanism can be secured by applying the		The label distribution mechanism can be secured by applying the
	appropriate level of security to the underlying protocol carrying		appropriate level of security to the underlying protocol carrying
	label information - authentication or encryption - see [LDP].		label information - authentication or encryption - see [LDP].
	(Conta & Doolan & Malis) Draft expires in six months [Page 19]		(Conta & Doolan & Malis) Draft expires in six months [Page 22]
	9. Acknowledgments		9. Acknowledgments
	The initial version of this document was derived from the Label		The initial version of this document was derived from the Label
	Switching over ATM document [ATM].		Switching over ATM document [ATM].
	Thanks for the extensive reviewing and constructive comments from (in		Thanks for the extensive reviewing and constructive comments from (in
	alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller.		alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller,
	Also thanks to George Swallow for the suggestion to use null		Eric Rosen. Also thanks to George Swallow for the suggestion to use
	encapsulation, and to Eric Gray for his reviewing.		null encapsulation, and to Eric Gray for his reviewing.
	Also thanks to Nancy Feldman and Bob Thomas for their collaboration		Also thanks to Nancy Feldman and Bob Thomas for their collaboration
	in including the LDP messages specific to Frame Relay LSRs		in including the LDP messages specific to Frame Relay LSRs.
	10. References		10. References
	[MIFR] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect		[MIFR] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect
	over Frame Relay" RFC 2427, September 1998.		over Frame Relay" RFC 2427, September 1998.
	[ARCH] E. Rosen, R. Callon, A. Vishwanathan, "Multi-Protocol Label		[ARCH] E. Rosen, R. Callon, A. Vishwanathan, "Multi-Protocol Label
	Switching Architecture", Work in Progress, July 1998.		Switching Architecture", Work in Progress, July 1998.
	[LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R. Thomas,		[LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R. Thomas,
	skipping to change at line 902		skipping to change at line 1056
	[ATM] B. Davie et al. "Use of Label Switching with ATM", Work in		[ATM] B. Davie et al. "Use of Label Switching with ATM", Work in
	Progress, July 1998.		Progress, July 1998.
	[ITU] International Telecommunications Union, "ISDN Data Link Layer		[ITU] International Telecommunications Union, "ISDN Data Link Layer
	Specification for Frame Mode Bearer Services", ITU-T Recommendation		Specification for Frame Mode Bearer Services", ITU-T Recommendation
	Q.922, 1992.		Q.922, 1992.
	[FRF] Frame Relay Forum, User-to-Network Implementation Agreement		[FRF] Frame Relay Forum, User-to-Network Implementation Agreement
	(UNI), FRF 1.1, January 19, 1996		(UNI), FRF 1.1, January 19, 1996
	(Conta & Doolan & Malis) Draft expires in six months [Page 20]		(Conta & Doolan & Malis) Draft expires in six months [Page 23]
	11.Authors' Addresses		11.Authors' Addresses
	Alex Conta		Alex Conta
	Lucent Technologies Inc.		Lucent Technologies Inc.
	300 Baker Ave, Suite 100		300 Baker Ave, Suite 100
	Concord, MA 01742		Concord, MA 01742
	+1-978-287-2842		+1-978-287-2842
	E-mail: aconta@lucent.com		E-mail: aconta@lucent.com
	skipping to change at line 927		skipping to change at line 1081
	+1-978-263-2002		+1-978-263-2002
	E-mail: pdoolan@ennovatenetworks.com		E-mail: pdoolan@ennovatenetworks.com
	Andrew Malis		Andrew Malis
	Ascend Communications, Inc		Ascend Communications, Inc
	1 Robbins Rd		1 Robbins Rd
	Westford, MA 01886		Westford, MA 01886
	+1-978-952-7414		+1-978-952-7414
	E-mail: malis@ascend.com		E-mail: malis@ascend.com
	(Conta & Doolan & Malis) Draft expires in six months [Page 21]		(Conta & Doolan & Malis) Draft expires in six months [Page 24]
			Appendix A - Changes since previous versions
			From "version 02 to 03"
			- Replace "cloud" with "domain",
			- Update references to other documents,
			- Change definitions in "Terminology" section,
			- Add more definitions to "Terminology" section,
			- Make editorial changes to text and figures,
			- Change "Performing TTL calculations" section,
			- Add more reviewers in "Acknowledgments" section,
			- Add Appendix A - changes.
			(Conta & Doolan & Malis) Draft expires in six months [Page 25]
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/