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/