draft-ietf-mpls-rsvp-unnum-01.txt   draft-ietf-mpls-rsvp-unnum-02.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: February 2002 Yakov Rekhter
Juniper Networks Juniper Networks
Signalling Unnumbered Links in RSVP-TE Signalling Unnumbered Links in RSVP-TE
draft-ietf-mpls-rsvp-unnum-01.txt draft-ietf-mpls-rsvp-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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
skipping to change at page 2, line 11 skipping to change at page 2, line 11
unnumbered links. This document defines procedures and extensions to unnumbered links. This document defines procedures and extensions to
RSVP-TE, one of the MPLS TE signalling protocols, that are needed in RSVP-TE, one of the MPLS TE signalling protocols, that are needed in
order to support unnumbered links. order to support unnumbered links.
3. Overview 3. Overview
Supporting MPLS TE over unnumbered links (i.e., links that do not Supporting MPLS TE over unnumbered links (i.e., links that do not
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 [ISIS-TE, OSPF-TE]. The focus signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The
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 Objects. This document proposes simple procedures and extensions that
that allow RSVP-TE signalling [RSVP-TE] to be used with unnumbered allow RSVP-TE signalling [RSVP-TE] to be used with unnumbered links.
links.
4. Interface Identifiers 4. Interface Identifiers
Since unnumbered links are not identified by an IP address, then for Since unnumbered links are not identified by an IP address, then for
the purpose of MPLS TE they need some other identifier. We assume the purpose of MPLS TE they need some other identifier. We assume
that each unnumbered link on a Label Switched Router (LSR) is given a that each unnumbered link on a Label Switched Router (LSR) is given a
unique 32-bit identifier. The scope of this identifier is the LSR to unique 32-bit identifier. The scope of this identifier is the LSR to
which the link belongs; moreover, 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 interface identifiers. modules on an LSR must agree on interface identifiers.
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
Path message MUST contain an LSP_TUNNEL_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 Path message used
the LSP is part of a bundled link (see [BUNDLE]), the Interface ID is for establishing the LSP that forms the Forwarding Adjacency MUST
set to the component interface ID of the LSP. 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 Resv message for the the reverse Forwarding Adjacency. Furthermore, the Resv message for
LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the LSR's the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the
Router ID set to the tail end's router ID, and the Interface ID set LSR's Router ID set to the tail-end's Router ID, and the Interface ID
to the reverse LSP's interface ID. If the LSP is part of a bundled set to the interface identifier allocated by the tail-end LSR.
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 25 skipping to change at page 4, line 25
|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 This subobject MUST be strict (i.e., the L bit MUST be 0). The Type
is 4 (Unnumbered Interface ID). The Length is 12. is 4 (Unnumbered Interface ID). The Length is 12.
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. The PHOP object in the message MUST contain X. If not, the
receiving node MUST return a PathErr.
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
Path message correctly. If the first subobject in the ERO is an Path 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 [RSVP-TE] 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 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 The PHOP or IF_ID RSVP_HOP object in the message MUST contain the
Router ID, Forward Interface ID> of any of the LSPs for which the same Router ID (IP Address) as the Router ID carried in the
node is a tail-end. If a match is found, the match identifies the subobject. If not, the receiving LSR MUST return a PathErr. If
Forwarding Adjacency for which the node has to perform label IF_ID RSVP_HOP object is present, and it carries the IF_INDEX TLV,
allocation. 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.
Otherwise, the node MUST check whether the tuple <X, ID> matches the If the above checks are passes, the LSR checks whether the tuple
tuple <LSR's Router ID, Reverse Interface ID> of any of the <Router ID, Interface ID> from the Unnumbered Interface subobject
bidirectional LSPs for which the node is the head-end. If a match is matches the tuple <Router ID, Forward Interface ID> of any of the
found, the match identifies the Forwarding Adjacency for which the LSPs for which the LSR is a tail-end. If a match is found, the match
node has to perform label allocation, namely, the reverse Forwarding identifies the Forwarding Adjacency for which the LSR has to perform
Adjacency for the LSP identified by the match. label allocation.
Otherwise, R must have information about Interface IDs and Component Otherwise, the LSR MUST check whether the tuple <Router ID, Interface
Interface IDs assigned by its neighbors for the unnumbered links ID> from the Unnumbered Interface subobject matches the tuple <Router
between R and its neighbors (i.e., incoming interface identifiers ID, Reverse Interface ID> of any of the bidirectional LSPs for which
from R's point of view). the LSR is the head-end. If a match is found, the match identifies
the Forwarding Adjacency for which the LSR has to perform label
allocation, namely, the reverse Forwarding Adjacency for the LSP
identified by the match.
If the Path message does not contain a COMPONENT_INTERFACE_ID, R Otherwise, the LSR must have information about the identifiers
determines the link by looking up <X, I> in the Traffic Engineering assigned by its neighbors to the unnumbered links (i.e., incoming
database. If the Path message contains a COMPONENT_INTERFACE_ID, R interface identifiers from LSR's point of view). The LSR uses this
determines the link as described in [BUNDLE]. 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, it is assumed that the node has to perform label Otherwise, the LSR SHOULD return a "Bad initial subobject" error.
allocation for the link over which the Path message was received.
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
subobject is computed as follows. The Interface ID in the subobject
MUST refer to an outgoing interface identifier that this node MUST refer to an outgoing interface identifier that this node
allocated; if not, the node SHOULD return a "Bad EXPLICIT_ROUTE allocated; if not, the LSR 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 LSR at the other end of the link
that the Interface ID refers to. If this node is R itself, the that the Interface ID refers to. If this is the LSR itself, the
subobject is removed, and the process repeated. If the next node is subobject is removed, and the process repeated. If the next hop is
not R, say N, this is the next hop to which a Path message must be some other LSR, then this is the next hop to which a Path message
sent. must be sent.
Furthermore, when sending a Path message to N, the ERO to be used is When sending a Path message to the next hop, if the Path message
the remaining ERO (i.e., starting with the subobject that refers to a carries the PHOP object, then this object MUST contain the LSR's
node different from the receiving node); the PHOP object is R's Router ID. If the Path message carries the IF_ID object, then this
router ID. object MUST contain the IF_INDEX TLV, with IP Address in that TLV set
to the LSR's Router ID, and Interface ID set to the Interface ID
carried in the first subobject of the ERO.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Reserved (MBZ)| | Type | Length | Flags | Reserved (MBZ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 4 (Unnumbered Interface ID); the Length is 8. Flags are The Type is 4 (Unnumbered Interface ID); the Length is 12. Flags are
defined below. defined below.
0x01 Local protection available 0x01 Local protection available
Indicates that the link downstream of this node is protected Indicates that the link downstream of this node is protected
via a local repair mechanism. This flag can only be set if via a local repair mechanism. This flag can only be set if
the Local protection flag was set in the SESSION_ATTRIBUITE the Local protection flag was set in the SESSION_ATTRIBUITE
object of the cooresponding Path message. object of the cooresponding Path message.
0x02 Local protection in use 0x02 Local protection in use
 End of changes. 

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