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/