draft-ietf-mpls-rsvp-unnum-00.txt   draft-ietf-mpls-rsvp-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: May 2001 Yakov Rekhter
Cisco Systems Juniper Networks
Signalling Unnumbered Links in RSVP-TE Signalling Unnumbered Links in RSVP-TE
draft-ietf-mpls-rsvp-unnum-00.txt draft-ietf-mpls-rsvp-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
Path message MUST contain an LSP_TUNNEL_INTERFACE_ID object Path message MUST contain an LSP_TUNNEL_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 Resv message for the reverse Forwarding Adjacency. Furthermore, the Resv message for the
LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the LSR's LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the LSR's
Router ID set to the tail end's router ID, and the Interface ID set Router ID set to the tail end's router ID, and the Interface ID set
to the reverse LSP's interface ID. to the 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. LSP_TUNNEL_INTERFACE_ID Object 5.1. LSP_TUNNEL_INTERFACE_ID Object
The LSP_TUNNEL_INTERFACE_ID object has a class number of type The LSP_TUNNEL_INTERFACE_ID object has a class number of type
11bbbbbb (to be assigned by IANA), C-Type of 1 and length of 12. The 11bbbbbb (to be assigned by IANA), C-Type of 1 and length of 12. The
format is given below. format is given below.
Figure 1: LSP_TUNNEL_INTERFACE_ID Object Figure 1: LSP_TUNNEL_INTERFACE_ID Object
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved (MUST be zero) | |L| Type | Length | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This subobject MUST be strict (i.e., the L bit MUST be 0). The Type This subobject MUST be strict (i.e., the L bit MUST be 0). The Type
is 4 (Unnumbered Interface ID). The Length is 8. is 4 (Unnumbered Interface ID). The Length is 12.
6.1. Interpreting the Unnumbered Interface ID Subobject 6.1. Interpreting the Unnumbered Interface ID Subobject
The Interface ID is the outgoing interface identifier with respect to The Router ID (say X) is the router ID of the LSR P at the upstream
the previous node in the path (i.e., the PHOP). If the Path message end of the unnumbered link. The Interface ID (say I) is the outgoing
contains an Unnumbered Interface ID subobject as the first subobject interface identifier with respect to the LSR specified by the router
in the ERO, then the PHOP object in the message must contain the ID. The PHOP object in the message MUST contain X. If not, the
router ID of the previous node. receiving node MUST return a PathErr.
6.2. Processing the Unnumbered Interface ID Subobject 6.2. Validating the Unnumbered Interface ID Subobject
A node that receives a Path message with an Unnumbered Interface ID First of all, the receiving node R must validate that it received the
as the first subobject in the ERO carried by the message MUST check Path message correctly. If the first subobject in the ERO is an
whether the tuple <PHOP, Interface ID> matches the tuple <LSR's 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 subobject"
error.
For other types of ERO subobjects, the rules in [RSVP-TE] 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_ID [BUNDLE] is present in the Path
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 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
which the node has to perform label allocation.
Otherwise, it is assumed that the node has to perform label If the Path message does not contain a COMPONENT_INTERFACE_ID, R
allocation for the link over which the Path message was received. In determines the link by looking up <X, I> in the Traffic Engineering
this case the receiving node MAY validate that it received the Path database. If the Path message contains a COMPONENT_INTERFACE_ID, R
message correctly. To do so, the node must maintain a database of determines the link as described in [BUNDLE].
Traffic Engineering information distributed by IS-IS and/or OSPF.
To validate that it received the Path message correctly, the node Otherwise, it is assumed that the node has to perform label
looks up in its Traffic Engineering database for the node allocation for the link over which the Path message was received.
corresponding to the router ID in the PHOP object in the Path. 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 subobject" 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 EXPLICIT_ROUTE allocated; if not, the node SHOULD return a "Bad EXPLICIT_ROUTE
object" error. The next hop is the node at the other end of the link object" error. The next hop is the node at the other end of the link
that the Interface ID refers to. that the 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 Path message must be
sent.
Furthermore, when sending a Path message to the next hop, the ERO to Furthermore, when sending a Path message to N, the ERO to be used is
be used is the current ERO (starting with the Unnumbered Interface ID the remaining ERO (i.e., starting with the subobject that refers to a
subobject); the PHOP object is the sending node's router ID. node different from the receiving node); the PHOP object is R's
router ID.
7. Record Route Object 7. Record Route Object
A new subobject of the Record Route Object (RRO) is used to record A new subobject of the Record Route Object (RRO) is used to record
that the LSP path traversed an unnumbered link. This subobject has that the LSP path traversed an unnumbered link. This subobject has
the following format: the following format:
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 7, line 29 skipping to change at page 7, line 30
Furthermore, the same Internet authority needs to assign a class Furthermore, the same Internet authority needs to assign a class
number to the LSP_TUNNEL_INTERFACE_ID object. This must be of the number to the LSP_TUNNEL_INTERFACE_ID object. This must be of the
form 11bbbbbb (i.e., this is an 8-bit number whose two most form 11bbbbbb (i.e., this is an 8-bit number whose two most
significant bits are 1). significant bits are 1).
10. Acknowledgments 10. Acknowledgments
Thanks to Lou Berger and Markus Jork for pointing out that the RRO Thanks to Lou Berger and Markus Jork for pointing out that the RRO
should be extended in like fashion to the ERO. Thanks also to Rahul should be extended in like fashion to the ERO. Thanks also to Rahul
Aggarwal and Alan Kullberg for their comments on the text. Aggarwal and Alan Kullberg for their comments on the text. Finally,
thanks to Bora Akyol and Vach Kompella.
11. References 11. References
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in
MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.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
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)
[RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-07.txt (work in progress) draft-ietf-mpls-rsvp-lsp-tunnel-08.txt (work in progress)
12. Author Information 12. 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/