draft-ietf-mpls-rsvp-unnum-02.txt   draft-ietf-mpls-rsvp-unnum-03.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: February 2002 Yakov Rekhter Expiration Date: May 2002 Yakov Rekhter
Juniper Networks Juniper Networks
Signalling Unnumbered Links in RSVP-TE Signalling Unnumbered Links in RSVP-TE
draft-ietf-mpls-rsvp-unnum-02.txt draft-ietf-mpls-rsvp-unnum-03.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
have IP addresses) involves two components: (a) the ability to carry have IP addresses) involves two components: (a) the ability to carry
(TE) information about unnumbered links in IGP TE extensions (ISIS or (TE) information about unnumbered links in IGP TE extensions (ISIS or
OSPF), and (b) the ability to specify unnumbered links in MPLS TE OSPF), and (b) the ability to specify unnumbered links in MPLS TE
signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The
focus of this document is on the latter. focus of this document is on the latter.
Current signalling used by MPLS TE doesn't provide support for Current signalling used by MPLS TE doesn't provide support for
unnumbered links because the current signalling doesn't provide a way unnumbered links because the current signalling doesn't provide a way
to indicate an unnumbered link in its Explicit Route and Record Route to indicate an unnumbered link in its Explicit Route and Record Route
Objects. This document proposes simple procedures and extensions that Objects. This document proposes simple procedures and extensions that
allow RSVP-TE signalling [RSVP-TE] to be used with unnumbered links. allow RSVP-TE signalling [GMPLS-RSVP] to be used with unnumbered
links.
4. Interface Identifiers 4. Link Identifiers
Since unnumbered links are not identified by an IP address, then for An unnumbered link has to be a point-to-point link. An LSR at each
the purpose of MPLS TE they need some other identifier. We assume end of an unnumbered link assigns an identifier to that link. This
that each unnumbered link on a Label Switched Router (LSR) is given a identifier is a non-zero 32-bit number that is unique within the
unique 32-bit identifier. The scope of this identifier is the LSR to scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP
which the link belongs; moreover, the IS-IS and/or OSPF and RSVP modules on an LSR must agree on the identifiers.
modules on an LSR must agree on interface identifiers.
Note that links are directed, i.e., a link l is from some LSR A to There is no a priori relationship between the identifiers assigned to
some other LSR B. LSR A chooses the interface identifier for link l. a link by the LSRs at each end of that link.
To be completely clear, we call this the "outgoing interface
identifier from LSR A's point of view". If there is a reverse link LSRs at the two end points of an unnumbered link exchange with each
from LSR B to LSR A (for example, a point-to-point SONET interface other the identifiers they assign to the link. Exchanging the
connecting LSRs A and B would be represented as two links, one from A identifiers may be accomplished by configuration, by means of a
to B, and another from B to A), B chooses the outgoing interface protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in
identifier for the reverse link; we call this the link's "incoming the case where a link is a Forwarding Adjacency, see below), or by
interface identifier from A's point of view". There is no a priori means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]).
relationship between the two interface identifiers.
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an
idenfitier for that link. So is LSR B. From A's perspective we refer
to the identifier that A assigned to the link as the "link local
identifier" (or just "local identifier"), and to the identifier that
B assigned to the link as the "link remote identifier" (or just
"remote identifier"). Likewise, from B's perspective the identifier
that B assigned to the link is the local identifier, and the
identifier that A assigned to the link is the remote identifier.
This section is equally applicable to the case of unnumbered
component links (see [LINK-BUNDLE]).
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 (see [LSP-HIER]), or the LSR Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR
uses the Forwarding Adjacency formed by this LSP as an unnumbered uses the Forwarding Adjacency formed by this LSP as an unnumbered
component link of a bundled link (see [BUNDLE]), the LSR MUST component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST
allocate an interface identifier to that Forwarding Adjacency (just allocate an identifier to that Forwarding Adjacency (just like for
like for any other unnumbered link). Moreover, the Path message used any other unnumbered link). Moreover, the Path message used for
for establishing the LSP that forms the Forwarding Adjacency MUST establishing the LSP that forms the Forwarding Adjacency MUST contain
contain an LSP_TUNNEL_INTERFACE_ID object (described below), with the the LSP_TUNNEL_INTERFACE_ID object (described below), with the LSR's
LSR's Router ID set to the head end's Router ID, and the Interface ID Router ID set to the head end's Router ID, and the Interface ID set
set to the interface identifier that the LSR allocated to the to the identifier that the LSR allocated to the Forwarding Adjacency.
Forwarding Adjacency.
If the LSP is bidirectional, and the tail-end LSR (of the forward If the Path message contains the LSP_TUNNEL_INTERFACE_ID object, then
LSP) advertises the reverse LSP as an unnumbered Forwarding the tail-end LSR MUST allocate an identifier to that Forwarding
Adjacency, the tail-end LSR MUST allocate an interface identifier to Adjacency (just like for any other unnumbered link). Furthermore,
the reverse Forwarding Adjacency. Furthermore, the Resv message for the Resv message for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID
the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the object, with the LSR's Router ID set to the tail-end's Router ID, and
LSR's Router ID set to the tail-end's Router ID, and the Interface ID the Interface ID set to the identifier allocated by the tail-end LSR.
set to the interface identifier allocated by the tail-end LSR.
For the purpose of processing the ERO and the IF_ID RSVP_HOP objects,
an unnumbered Forwarding Adjacency is treated as an unnumbered (TE)
link or an unnumbered component link as follows. The LSR that
originates the Adjacency sets the link local identifier for that link
to the value that the LSR allocates to that Forwarding Adjacency, and
the link remote identifier to the value carried in the Interface ID
field of the Reverse Interface ID object. The LSR that is a tail-end
of that Forwarding Adjacency sets the link local identifier for that
link to the value that the LSR allocates to that Forwarding
Adjacency, and the link remote identifier to the value carried in the
Interface ID field of the Forward Interface ID object.
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.
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface ID"
for that LSP; in the latter case, we call it the "Reverse Interface
ID" for the LSP.
Figure 1: LSP_TUNNEL_INTERFACE_ID Object Figure 1: LSP_TUNNEL_INTERFACE_ID Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID | | LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface ID"
for that LSP; in the latter case, we call it the "Reverse Interface
ID" for the LSP.
6. Signalling Unnumbered Links in EROs 6. Signalling Unnumbered Links in EROs
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 | | 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 The Type is 4 (Unnumbered Interface ID). The Length is 12.
is 4 (Unnumbered Interface ID). The Length is 12.
The Interface ID is the outgoing interface identifier with respect to
the LSR specified by the router ID.
6.1. Processing the Unnumbered Interface ID Subobject
First of all, the receiving LSR must validate that it received the
Path message correctly. If the first subobject in the ERO is an
Unnumbered Interface subobject, the check is done as follows (for
other types of ERO subobjects, the rules in [RSVP-TE] apply).
The PHOP or IF_ID RSVP_HOP object in the message MUST contain the The Interface ID is the identifier assigned to the link by the LSR
same Router ID (IP Address) as the Router ID carried in the specified by the router ID.
subobject. If not, the receiving LSR MUST return a PathErr. If
IF_ID RSVP_HOP object is present, and it carries the IF_INDEX TLV,
the receiving LSR SHOULD check that the value carried in this TLV is
the same as carried in the subobject. If the value is different, the
receiving LSR MUST return a PathErr.
If the above checks are passes, the LSR checks whether the tuple 6.1. Processing the IF_ID RSVP_HOP object
<Router ID, Interface ID> from the Unnumbered Interface subobject
matches the tuple <Router ID, Forward Interface ID> of any of the
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.
Otherwise, the LSR MUST check whether the tuple <Router ID, Interface When an LSR receives a Path message containing the IF_ID RSVP_HOP
ID> from the Unnumbered Interface subobject matches the tuple <Router object with the IF_INDEX TLV, the LSR processes this TLV as follows.
ID, Reverse Interface ID> of any of the bidirectional LSPs for which The LSR must have information about the identifiers assigned by its
the LSR is the head-end. If a match is found, the match identifies neighbors to the unnumbered links between the neighbors and the LSR.
the Forwarding Adjacency for which the LSR has to perform label The LSR uses this information to find a link with tuple <Router ID,
allocation, namely, the reverse Forwarding Adjacency for the LSP local identifier> matching the tuple <IP Address, Interface ID>
identified by the match. carried in the IF_INDEX TLV. If the matching tuple is found, the
match identifies the link for which the LSR has to perform label
allocation.
Otherwise, the LSR must have information about the identifiers Otherwise, the LSR SHOULD return an error.
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].
Otherwise, the LSR SHOULD return a "Bad initial subobject" error. 6.2. Processing the ERO object
6.2. Selecting the Next Hop The Unnumbered Interface ID subobject is defined to be a part of a
particular abstract node if that node has the Router ID that is equal
to the Router ID field in the subobject, and if the node has an
(unnumbered) link or an (unnumbered) Forwarding Adjacency whose local
identifier (from that node's point of view) is equal to the value
carried in the Interface ID field of the subobject.
Once an LSR determines the link for which the LSR has to perform With this in mind, the ERO processing in the presence of the
label allocation, the LSR removes the initial subobject in the ERO, Unnumbered Interface ID subobject follows the rules specified in
and computes the next hop. The next hop for an Unnumbered Interface section 4.3.4.1 of [RSVP-TE].
subobject is computed as follows. The Interface ID in the subobject
MUST refer to an outgoing interface identifier that this node
allocated; if not, the LSR SHOULD return a "Bad EXPLICIT_ROUTE
object" error. The next hop is the LSR at the other end of the link
that the Interface ID refers to. If this is the LSR itself, the
subobject is removed, and the process repeated. If the next hop is
some other LSR, then this is the next hop to which a Path message
must be sent.
When sending a Path message to the next hop, if the Path message As part of the ERO processing, or to be more precise, as part of the
carries the PHOP object, then this object MUST contain the LSR's next hop selection, if the outgoing link is unnumbered, the Path
Router ID. If the Path message carries the IF_ID object, then this message that the node sends to the next hop MUST include the IF_ID
object MUST contain the IF_INDEX TLV, with IP Address in that TLV set RSVP_HOP object, with the IP address field of that object set to the
to the LSR's Router ID, and Interface ID set to the Interface ID Router ID of the node, and the Interface ID field of that object set
carried in the first subobject of the ERO. to the identifier assigned to the link by the node.
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 34 skipping to change at page 7, line 14
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. Finally, Aggarwal and Alan Kullberg for their comments on the text. Finally,
thanks to Bora Akyol and Vach Kompella. thanks to Bora Akyol and Vach Kompella.
11. References 11. References
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in Bundling in MPLS Traffic Engineering", draft-kompella-mpls-
progress) bundle-05.txt (work in progress)
[ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic
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-02.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", 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-08.txt (work in progress) draft-ietf-mpls-rsvp-lsp-tunnel-08.txt (work in progress)
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
extensions-02.txt (work in progress)
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-
gmpls-extensions-00.txt (work in progress)
[GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP-
TE Extensions", draft-ietf-mpls-generalized-rsvp-te-04.txt
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
 End of changes. 

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