draft-ietf-mpls-crldp-unnum-01.txt		draft-ietf-mpls-crldp-unnum-02.txt
	Network Working Group Kireeti Kompella		Network Working Group Kireeti Kompella
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Expiration Date: August 2001 Yakov Rekhter		Expiration Date: March 2002 Yakov Rekhter
	Juniper Networks		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-01.txt		draft-ietf-mpls-crldp-unnum-02.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 8		skipping to change at page 3, line 8
	from LSR B to LSR A (for example, a point-to-point SONET interface		from LSR B to LSR A (for example, a point-to-point SONET interface
	connecting LSRs A and B would be represented as two links, one from A		connecting LSRs A and B would be represented as two links, one from A
	to B, and another from B to A), B chooses the outgoing interface		to B, and another from B to A), B chooses the outgoing interface
	identifier for the reverse link; we call this the link's "incoming		identifier for the reverse link; we call this the link's "incoming
	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 (see [LSP-HIER]), or the LSR
	allocate an interface ID to that Forwarding Adjacency. Moreover, the		uses the Forwarding Adjacency formed by this LSP as an unnumbered
	REQUEST message for the LSP MUST contain an INTERFACE ID object		component link of a bundled link (see [BUNDLE]), the LSR MUST
	(described below), with the LSR's Router ID set to the head end's		allocate an interface identifier to that Forwarding Adjacency (just
	router ID, and the Interface ID set to the LSP's interface ID. If		like for any other unnumbered link). Moreover, the Request message
	the LSP is part of a bundled link (see [BUNDLE]), the Interface ID is		used for establishing the LSP that forms the Forwarding Adjacency
	set to the component interface ID of the LSP.		MUST contain an LSP_TUNNEL_INTERFACE_ID object (described below),
			with the LSR's Router ID set to the head end's Router ID, and the
			Interface ID set to the interface identifier that the LSR allocated
			to the Forwarding Adjacency.
	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 identifier to
	reverse Forwarding Adjacency. Furthermore, the MAPPING message for		the reverse Forwarding Adjacency. Furthermore, the MAPPING message
	the LSP MUST contain an INTERFACE ID object, with the LSR's Router ID		for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the
	set to the tail end's router ID, and the Interface ID set to the		LSR's Router ID set to the tail end's router ID, and the Interface ID
	reverse LSP's interface ID. If the LSP is part of a bundled link		set to the interface identifier allocated by the tail-end LSR.
	(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. LSP_TUNNEL_INTERFACE_ID Object
	The INTERFACE ID object has Type to be determined by IETF consensus		The LSP_TUNNEL_INTERFACE ID object has Type to be determined by IETF
	and length 8. The format is given below.		consensus 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Type | Length |		|0|0| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSR's Router ID |		| LSR's Router ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 4, line 25		skipping to change at page 4, line 25
	|0|0| Type | Length |		|0|0| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router ID |		| 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 8.		ID) and the Length is 8.
	6.1. Interpreting the Unnumbered Interface ID Subobject		The Interface ID is the outgoing interface identifier with respect to
			the LSR specified by the router ID.
	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.
	6.2. Validating the Unnumbered Interface ID Subobject		6.1. Processing the Unnumbered Interface ID Subobject
	First of all, the receiving node R must validate that it received the		First of all, the receiving LSR must validate that it received the
	Request message correctly. If the first subobject in the ERO is an		Request message correctly. If the first subobject in the ERO is an
	Unnumbered Interface subobject, the check is done as follows. R		Unnumbered Interface subobject, the check is done as follows (for
	looks up in its Traffic Engineering database the node P corresponding		other types of ERO subobjects, the rules in [CR-LDP] apply).
	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.
	For other types of ERO subobjects, the rules in [CR-LDP] apply.
	6.3. Determining the Link Identified by the ERO
	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.
	First, R checks whether the tuple <X, ID> matches the tuple <LSR's
	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
	Forwarding Adjacency for which the node has to perform label
	allocation.
	Otherwise, the node MUST check whether the tuple <X, ID> matches the		The IF_ID TLV ([GMPLS-SIG], [GMPLS-CRLDP]), if present in the
	tuple <LSR's Router ID, Reverse Interface ID> of any of the		message, MUST contain the same Router ID (IP Address) as the Router
	bidirectional LSPs for which the node is the head-end. If a match is		ID carried in the Unnumbered Interface ID subobject. If not, the
	found, the match identifies the Forwarding Adjacency for which the		receiving LSR MUST return a "Bad Initial ER-Hop" error. If IF_ID TLV
	node has to perform label allocation, namely, the reverse Forwarding		is present, and it carries the IF_INDEX TLV, the receiving LSR SHOULD
	Adjacency for the LSP identified by the match.		check that the value carried in this TLV is the same as carried in
			the Interface ID field of the Unnumbered Interface ID subobject. If
			the value is different, the receiving LSR MUST return a "Bad Initial
			ER-Hop" error.
	Otherwise, R must have information about Interface IDs and Component		If the above checks are passes, the LSR checks whether the tuple
	Interface IDs assigned by its neighbors for the unnumbered links		<Router ID, Interface ID> from the Unnumbered Interface subobject
	between R and its neighbors (i.e., incoming interface identifiers		matches the tuple <Router ID, Forward Interface ID> of any of the
	from R's point of view).		LSPs for which the LSR is a tail-end. If a match is found, the match
			identifies the Forwarding Adjacency for which the LSR has to perform
			label allocation.
	If the Request message does not contain a Component Interface		Otherwise, the LSR MUST check whether the tuple <Router ID, Interface
	Identifier object, R determines the link by looking up <X, I> in the		ID> from the Unnumbered Interface subobject matches the tuple <Router
	Traffic Engineering database. If the Request message contains a		ID, Reverse Interface ID> of any of the bidirectional LSPs for which
	Component Interface Identifier object, R determines the link as		the LSR is the head-end. If a match is found, the match identifies
	described in [BUNDLE].		the Forwarding Adjacency for which the LSR has to perform label
			allocation, namely, the reverse Forwarding Adjacency for the LSP
			identified by the match.
	Otherwise, it is assumed that the node has to perform label		Otherwise, the LSR must have information about the identifiers
	allocation for the link over which the Request message was received.		assigned by its neighbors to the unnumbered links (i.e., incoming
			interface identifiers from LSR's point of view). The LSR uses this
			information to find a link with tuple <Router ID, incoming interface
			identifier> matching the tuple <Router ID, Interface ID> from the
			Unnumbered Interface subobject. If the matching tuple is found, and
			the link is not a bundled link, the match identifies the link for
			which the LSR has to perform label allocation. If the matching tuple
			is found, and the link is a bundled link, the LSR follows the
			procedures for label allocation as described in [LINK-BUNDLE].
	6.4. Selecting the Next Hop		6.2. Selecting the Next Hop
	Once the link has been determined, the initial subobject is removed,		Once an LSR determines the link for which the LSR has to perform
	and the next hop should be computed. The next hop for an Unnumbered		label allocation, the LSR removes the initial subobject in the ERO,
	Interface ID subobject is determined as follows. The Interface ID		and computes the next hop. The next hop for an Unnumbered Interface
	MUST refer to an outgoing interface identifier that this node		ID subobject is determined as follows. The Interface ID MUST refer
	allocated; if not, the node SHOULD return a "Bad Strict Node" error.		to an outgoing interface identifier that this node allocated; if not,
	The next hop is the node at the other end of the link that the		the node SHOULD return a "Bad Strict Node" error. The next hop is
	Interface ID refers to. If this node is R itself, the subobject is		the LSR at the other end of the link that the Interface ID refers to.
	removed, and the process repeated. If the next node is not R, say N,		If this is the LSR itself, the subobject is removed, and the process
	this is the next hop to which a Request message must be sent.		repeated. If the next node is some other LSR, this is the next hop
			to which a Request message must be sent.
	Furthermore, when sending a Request message to N, the ERO to be used		When sending a Request message to the next hop, if the message
	is the remaining ERO (i.e., starting with the subobject that refers		carries the IF_ID object, then this object MUST contain the IF_INDEX
	to a node different from the receiving node); the PHOP object is R's		TLV, with IP Address in that TLV set to the LSR's Router ID, and
	router ID.		Interface ID set to the Interface ID carried in the first subobject
			of the ERO.
	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 too to		Thanks to Rahul Aggarwal for his comments on the text. Thanks too to
	Bora Akyol and Vach Kompella.		Bora Akyol and Vach Kompella.
	9. References		9. References
			[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in
			MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in
			progress)
	[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)
			[GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling
			Functional Description", draft-ietf-generalized-mpls-
			signalling-05.txt
			[GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR-
			LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-04.txt
	[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
	TE", draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress)		TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress)
	[OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to		[OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to
	OSPF", draft-katz-yeung-ospf-traffic-02.txt (work in progress)		OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress)
	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
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	e-mail: yakov@juniper.net		e-mail: yakov@juniper.net
	Alan Kullberg		Alan Kullberg
	NetPlane Systems, Inc.		NetPlane Systems, Inc.
	888 Washington St.		Westwood Executive Center
	Dedham, MA 02026		200 Lowder Brook Drive
			Westwood, MA 02090
	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/