draft-ietf-mpls-crldp-unnum-00.txt		draft-ietf-mpls-crldp-unnum-01.txt
	Network Working Group Kireeti Kompella		Network Working Group Kireeti Kompella
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Expiration Date: May 2001 Yakov Rekhter		Expiration Date: August 2001 Yakov Rekhter
	Cisco Systems		Juniper Networks
	Alan Kullberg		Alan Kullberg
	NetPlane Systems		NetPlane Systems
	Signalling Unnumbered Links in CR-LDP		Signalling Unnumbered Links in CR-LDP
	draft-ietf-mpls-crldp-unnum-00.txt		draft-ietf-mpls-crldp-unnum-01.txt
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 12		skipping to change at page 3, line 12
	interface identifier from A's point of view". There is no a priori		interface identifier from A's point of view". There is no a priori
	relationship between the two interface identifiers.		relationship between the two interface identifiers.
	5. Unnumbered Forwarding Adjacencies		5. Unnumbered Forwarding Adjacencies
	If an LSR that originates an LSP advertises this LSP as an unnumbered		If an LSR that originates an LSP advertises this LSP as an unnumbered
	Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST		Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST
	allocate an interface ID to that Forwarding Adjacency. Moreover, the		allocate an interface ID to that Forwarding Adjacency. Moreover, the
	REQUEST message for the LSP MUST contain an INTERFACE ID object		REQUEST message for the LSP MUST contain an INTERFACE ID object
	(described below), with the LSR's Router ID set to the head end's		(described below), with the LSR's Router ID set to the head end's
	router ID, and the Interface ID set to the LSP's interface ID.		router ID, and the Interface ID set to the LSP's interface ID. If
			the LSP is part of a bundled link (see [BUNDLE]), the Interface ID is
			set to the component interface ID of the LSP.
	If the LSP is bidirectional, and the tail-end LSR (of the forward		If the LSP is bidirectional, and the tail-end LSR (of the forward
	LSP) advertises the reverse LSP as an unnumbered Forwarding		LSP) advertises the reverse LSP as an unnumbered Forwarding
	Adjacency, the tail-end LSR MUST allocate an interface ID to the		Adjacency, the tail-end LSR MUST allocate an interface ID to the
	reverse Forwarding Adjacency. Furthermore, the MAPPING message for		reverse Forwarding Adjacency. Furthermore, the MAPPING message for
	the LSP MUST contain an INTERFACE ID object, with the LSR's Router ID		the LSP MUST contain an INTERFACE ID object, with the LSR's Router ID
	set to the tail end's router ID, and the Interface ID set to the		set to the tail end's router ID, and the Interface ID set to the
	reverse LSP's interface ID.		reverse LSP's interface ID. If the LSP is part of a bundled link
			(see [BUNDLE]), the Component Interface ID is set to the component
			interface ID of the LSP; otherwise, it is set to zero.
	5.1. INTERFACE ID Object		5.1. INTERFACE ID Object
	The INTERFACE ID object has Type to be determined by IETF consensus		The INTERFACE ID object has Type to be determined by IETF consensus
	and length 8. The format is given below.		and length 8. The format is given below.
	Figure 1: Interface ID TLV		Figure 1: Interface ID TLV
	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 4, line 17		skipping to change at page 4, line 17
	A new subobject of the Explicit Route Object (ERO) is used to specify		A new subobject of the Explicit Route Object (ERO) is used to specify
	unnumbered links. This subobject has the following format:		unnumbered links. This subobject has the following format:
	Figure 2: Unnumbered Interface ID Subobject		Figure 2: Unnumbered Interface ID Subobject
	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| Type | Length |		|0|0| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Router ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface ID (32 bits) |		| Interface ID (32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	This subobject is strict. The Type is 0x0805 (Unnumbered Interface		This subobject is strict. The Type is 0x0805 (Unnumbered Interface
	ID) and the Length is 4.		ID) and the Length is 8.
	An LSR sending a Request message that includes an Unnumbered		6.1. Interpreting the Unnumbered Interface ID Subobject
	Interface ID subobject as the first subobject in the ERO MUST also
	include a PHOP TLV, specifying the Router ID of the sending LSR.
	This TLV is depicted in Figure 3.
	Figure 3: PHOP TLV		The Router ID (say X) is the router ID of the LSR P at the upstream
			end of the unnumbered link. The Interface ID (say I) is the outgoing
			interface identifier with respect to the LSR specified by the router
			ID. If not, the receiving node MUST return an error message.
	0 1 2 3		6.2. Validating the Unnumbered Interface ID Subobject
	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| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSR's Router ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Type (PHOP TLV) is to be determined by IETF consensus and the		First of all, the receiving node R must validate that it received the
	Length is 4.		Request message correctly. If the first subobject in the ERO is an
			Unnumbered Interface subobject, the check is done as follows. R
			looks up in its Traffic Engineering database the node P corresponding
			to the router ID X in the ERO subobject. It then checks that there
			is a link from P to R that carries the same Interface ID as the one
			in the ERO subobject (I). If this is not the case, R has received
			the message in error and SHOULD return a "Bad Initial ER-Hop" error.
	6.1. Interpreting the Unnumbered Interface ID Subobject		For other types of ERO subobjects, the rules in [CR-LDP] apply.
	The Interface ID is the outgoing interface identifier with respect to		6.3. Determining the Link Identified by the ERO
	the previous node in the path (i.e., the PHOP). If the Request
	message contains an Unnumbered Interface ID subobject as the first
	subobject in the ERO, then the PHOP object in the message must
	contain the router ID of the previous node.
	6.2. Processing the Unnumbered Interface ID Subobject		Determining the link for which label allocation must be done depends
			on whether a Component Interface Identifier object [BUNDLE] is
			present in the Request message or not. If so, set ID to the
			Component Interface ID; otherwise, set ID to I (the Interface ID in
			the ERO subobject). X is (as above) the router ID in the Unnumbered
			ERO subobject.
	A node that receives a Request message with an Unnumbered Interface		First, R checks whether the tuple <X, ID> matches the tuple <LSR's
	ID as the first subobject in the ERO carried by the message MUST
	check whether the tuple <PHOP, Interface ID> matches the tuple <LSR's
	Router ID, Forward Interface ID> of any of the LSPs for which the		Router ID, Forward Interface ID> of any of the LSPs for which the
	node is a tail-end. If a match is found, the match identifies the		node is a tail-end. If a match is found, the match identifies the
	Forwarding Adjacency for which the node has to perform label		Forwarding Adjacency for which the node has to perform label
	allocation.		allocation.
	Otherwise, the node MUST check whether the tuple <PHOP, Interface ID>		Otherwise, the node MUST check whether the tuple <X, ID> matches the
	matches the tuple <LSR's Router ID, Reverse Interface ID> of any of		tuple <LSR's Router ID, Reverse Interface ID> of any of the
	the bidirectional LSPs for which the node is the head-end. If a		bidirectional LSPs for which the node is the head-end. If a match is
	match is found, the match identifies the Forwarding Adjacency for		found, the match identifies the Forwarding Adjacency for which the
	which the node has to perform label allocation, namely, the reverse		node has to perform label allocation, namely, the reverse Forwarding
	Forwarding Adjacency for the LSP identified by the match.		Adjacency for the LSP identified by the match.
	Otherwise, if the node maintains information about Interface IDs		Otherwise, R must have information about Interface IDs and Component
	assigned by its neighbors for the unnumbered links between the node		Interface IDs assigned by its neighbors for the unnumbered links
	and the neighbors (i.e., incoming interface identifiers from the		between R and its neighbors (i.e., incoming interface identifiers
	node's point of view), the node SHOULD check whether the tuple <PHOP,		from R's point of view).
	Interface ID> matches <neighbor's Router ID, Incoming Interface ID>
	for any link. If a match is found, the match identifies the link for		If the Request message does not contain a Component Interface
	which the node has to perform label allocation.		Identifier object, R determines the link by looking up <X, I> in the
			Traffic Engineering database. If the Request message contains a
			Component Interface Identifier object, R determines the link as
			described in [BUNDLE].
	Otherwise, it is assumed that the node has to perform label		Otherwise, it is assumed that the node has to perform label
	allocation for the link over which the Request message was received.		allocation for the link over which the Request message was received.
	In this case the receiving node MAY validate that it received the
	Request Message correctly. To do so, the node must maintain a
	database of Traffic Engineering information distributed by IS-IS
	and/or OSPF.
	To validate that it received the Request message correctly, the node
	looks up in its Traffic Engineering database for the node
	corresponding to the router ID of the sender of the Request message.
	It then checks that there is a link from the previous node to itself
	that carries the same Interface ID as the one in the ERO subobject.
	If this is not the case, the receiving node has received the message
	in error and SHOULD return a "Bad Initial ER-Hop" error. Otherwise,
	the receiving node removes the first subobject, and continues
	processing the ERO.
	6.3. Selecting the Next Hop		6.4. Selecting the Next Hop
	If, after processing and removing all initial subobjects in the ERO		Once the link has been determined, the initial subobject is removed,
	that refer to itself, the receiving node finds a subobject of type		and the next hop should be computed. The next hop for an Unnumbered
	Unnumbered Interface ID, it determines the next hop as follows. The		Interface ID subobject is determined as follows. The Interface ID
	Interface ID MUST refer to an outgoing interface identifier that this		MUST refer to an outgoing interface identifier that this node
	node allocated; if not, the node SHOULD return a "Bad Strict Node"		allocated; if not, the node SHOULD return a "Bad Strict Node" error.
	error. The next hop is the node at the other end of the link that		The next hop is the node at the other end of the link that the
	the Interface ID refers to.		Interface ID refers to. If this node is R itself, the subobject is
			removed, and the process repeated. If the next node is not R, say N,
			this is the next hop to which a Request message must be sent.
	Furthermore, when sending a Request message to the next hop, the ERO		Furthermore, when sending a Request message to N, the ERO to be used
	to be used is the current ERO (starting with the Unnumbered Interface		is the remaining ERO (i.e., starting with the subobject that refers
	ID subobject).		to a node different from the receiving node); the PHOP object is R's
			router ID.
	7. Security Considerations		7. Security Considerations
	This document raises no new security concerns for CR-LDP.		This document raises no new security concerns for CR-LDP.
	8. Acknowledgments		8. Acknowledgments
	Thanks to Rahul Aggarwal for his comments on the text.		Thanks to Rahul Aggarwal for his comments on the text. Thanks too to
			Bora Akyol and Vach Kompella.
	9. References		9. References
	[CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using		[CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using
	LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress)		LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress)
	[ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic		[ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic
	Engineering", draft-ietf-isis-traffic-02.txt (work in progress)		Engineering", draft-ietf-isis-traffic-02.txt (work in progress)
	[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS		[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS
	skipping to change at page 7, line 14		skipping to change at page 7, line 12
	10. Author Information		10. Author Information
	Kireeti Kompella		Kireeti Kompella
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	e-mail: kireeti@juniper.net		e-mail: kireeti@juniper.net
	Yakov Rekhter		Yakov Rekhter
	Cisco Systems, Inc.		Juniper Networks, Inc.
	170 West Tasman Drive		1194 N. Mathilda Ave.
	San Jose, CA 95134		Sunnyvale, CA 94089
	e-mail: yakov@cisco.com		e-mail: yakov@juniper.net
	Alan Kullberg		Alan Kullberg
	NetPlane Systems, Inc.		NetPlane Systems, Inc.
	888 Washington St.		888 Washington St.
	Dedham, MA 02026		Dedham, MA 02026
	e-mail: akullber@netplane.com		e-mail: akullber@netplane.com
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/