Network Working Group Kireeti Kompella
Internet Draft Juniper Networks
Expiration Date: November 2001 Yakov Rekhter
Juniper Networks
LSP Hierarchy with MPLS TE
draft-ietf-mpls-lsp-hierarchy-03.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
To improve scalability of MPLS TE it may be useful to aggregate TE
LSPs. The aggregation is accomplished by (a) an LSR creating a TE
LSP, (b) the LSR forming a forwarding adjacency out of that LSP
(advertising this LSP as a link into ISIS/OSPF), (c) allowing other
LSRs to use forwarding adjacencies for their path computation, and
(d) nesting of LSPs originated by other LSRs into that LSP (by using
the label stack construct).
This document describes the mechanisms to accomplish this.
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 1]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
3. Overview
An LSR uses MPLS TE procedures to create and maintain an LSP. The
LSR then may (under local configuration control) announce this LSP as
a Traffic Engineering (TE) link into ISIS/OSPF. We call such a link
a "forwarding adjacency". We refer to the LSP as the "forwarding
adjacency LSP", or just FA-LSP.
In general, the creation/termination of a forwarding adjacency and
its FA-LSP could be driven either by mechanisms outside of MPLS
(e.g., via configuration control on the LSR at the head-end of the
adjacency), or by mechanisms within MPLS (e.g., as a result of the
LSR at the head-end of the adjacency receiving LSP setup requests
originated by some other LSRs).
ISIS/OSPF floods the information about forwarding adjacencies just as
it floods the information about any other links. As a result of this
flooding, an LSR has in its TE link state database the information
about not just conventional links, but forwarding adjacencies as
well.
An LSR, when performing path computation, uses not just conventional
links, but forwarding adjacencies as well. Once a path is computed,
the LSR uses RSVP/CR-LDP [RSVP-TE, CR-LDP] for establishing label
binding along the path.
In this document we define mechanisms/procedures to accomplish the
above. These mechanisms/procedures cover both the routing
(ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects.
Note that an LSP may be advertised as a point-to-point link into ISIS
or OSPF, to be used in normal SPF by nodes other than the head end.
While this is similar in spirit to a Forwarding Adjacency, this is
beyond the scope of this document.
4. Routing aspects
In this section we describe procedures for constructing forwarding
adjacencies out of LSPs, and handling of forwarding adjacencies by
ISIS/OSPF. Specifically, this section describes how to construct the
information needed to advertise LSPs as links into ISIS/OSPF.
Procedures for creation/termination of such LSPs are defined in
Section 6.
Forwarding adjacencies may be represented as either unnumbered or
numbered links. If FAs are numbered, the local and remote IPv4
addresses come out of a /31; the local address is the one specified
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 2]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
as the IPv4 tunnel sender address; the remote address can then be
inferred. If the LSP is bidirectional, the tail-end can thus know
the addresses to assign to the reverse FA.
If there are multiple LSPs that all originate on one LSR and all
terminate on another LSR, then at one end of the spectrum all these
LSPs could be merged (under control of the head-end LSR) into a
single forwarding adjacency using the concept of Link Bundling (see
[BUNDLE]), while at the other end of the spectrum each such LSP could
be advertised as its own adjacency.
When a forwarding adjacency is created under administrative control
(static provisioning), the attributes of the FA-LSP have to be
provided via configuration. Specifically, the following attributes
may be configured for the FA-LSP: the head-end address (if left
unconfigured, this defaults to the head-end LSR's Router ID); the
tail-end address; bandwidth and resource colors constraints. The
path taken by the FA-LSP may be either computed by the LSR at the
head-end of the FA-LSP, or specified by explicit configuration; this
choice is determined by configuration.
When a forwarding adjacency is created dynamically, the attributes of
its FA-LSP are inherited from the LSP which induced its creation.
Note that the bandwidth of the FA-LSP must be at least as big as the
LSP that induced it, but may be bigger if only discrete bandwidths
are available for the FA-LSP. In general, for dynamically
provisioned forwarding adjacencies, a policy-based mechanism may be
needed to associate attributes to the FA-LSPs.
4.1. Traffic Engineering parameters
In this section, the Traffic Engineering parameters (see [OSPF-TE]
and [ISIS-TE]) for forwarding adjacencies are described.
4.1.1. Link type (OSPF only)
The Link Type of a forwarding adjacency is set to "point-to-point".
4.1.2. Link ID (OSPF only)
The Link ID is set to the Router ID of the tail end of FA-LSP.
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 3]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
4.1.3. Local and remote interface IP address
If the FA is to be numbered, the local interface IP address (OSPF) or
IPv4 interface address (ISIS) is set to the head-end address of the
FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor
address (ISIS) is set to the tail-end address of the FA-LSP.
4.1.4. Outgoing and Incoming Interface Identifiers
For an unnumbered FA the assignment and handling of the local and
remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP].
4.1.5. Traffic Engineering metric
By default the TE metric on the forwarding adjacency is set to max(1,
(the TE metric of the FA-LSP path) - 1) so that it attracts traffic
in preference to setting up a new LSP. This may be overridden via
configuration at the head-end of the forwarding adjacency.
4.1.6. Maximum bandwidth
By default the maximum reservable bandwidth and the initial maximum
LSP bandwidth for all priorities of the forwarding adjacency is set
to the bandwidth of the FA-LSP. These may be overridden via
configuration at the head-end of the forwarding adjacency (note that
the maximum LSP bandwidth at any one priority should be no more than
the bandwidth of the FA-LSP).
4.1.7. Unreserved bandwidth
The initial unreserved bandwidth for all priority levels of the
forwarding adjacency is set to the bandwidth of the FA-LSP.
4.1.8. Resource class/color
By default, a forwarding adjacency does not have resource colors
(administrative groups). This may be overridden by configuration at
the head-end of the forwarding adjacency.
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 4]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
4.1.9. Interface Switching Capability
The Interface Switching Capability associated with the forwarding
adjacency is the Interface Switching Capability of the last link in
the FA-LSP.
4.1.10. Path information
A forwarding adjacency advertisement could contain the information
about the path taken by the FA-LSP associated with that forwarding
adjacency. This information may be used for path calculation by
other LSRs. This information is carried in the Path TLV. In both
IS-IS and OSPF, this TLV is encoded as follows: the type is TBD, the
length is 4 times the path length, and the value is a list of 4 octet
IPv4 addresses identifying the links in the order that they form the
path of the forwarding adjacency.
It is possible that the underlying Path information might change over
time, via configuration updates, or dynamic route modifications,
resulting in the change of the Path TLV.
If forwarding adjacencies are bundled (via link bundling), and if the
resulting bundled link carries a Path TLV, it MUST be the case that
the underlying path followed by each of the FA-LSPs that form the
component links is the same.
5. Other considerations
It is expected that forwarding adjacencies will not be used for
establishing ISIS/OSPF peering relation between the routers at the
ends of the adjacency.
It may be desired in some cases that forwarding adjacencies only be
used in Traffic Engineering path computations. In IS-IS, this can be
accomplished by setting the default metric of the extended IS
reachability TLV for the FA to the maximum link metric (2^24 - 1).
In OSPF, this can be accomplished by not advertising the link as a
regular LSA, but only as a TE opaque LSA.
Since LSPs are in general unidirectional, it follows that forwarding
adjacencies are (by definition) unidirectional links. Therefore, the
TE path computation procedures should not perform two-way
connectivity check on the links used by the procedures.
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 5]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
6. Controlling FA-LSPs boundaries
To facilitate controlling the boundaries of FA-LSPs this document
introduces two new mechanisms: Interface Switching Capability (see
[GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region").
6.1. LSP regions
The information carried in the Interface Switching Capabilities is
used to construct LSP regions, and determine regions' boundaries as
follows.
Define an ordering among interface switching capabilities as follows:
PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two links
link-1 and link-2 with interface switching capabilities lmc-1 and
lmc-2 respectively, say that link-1 < link-2 iff lmc-1 < lmc-2 or
lmc-1 == lmc-2 == TDM, and link-1's bandwidth is less than link-2's
switching speed.
Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
node-2, ..., link-n, node-n. If link-i < link-(i+1), we say that the
LSP has crossed a region boundary at node-i; with respect to that LSP
path, the LSR at node-i is an edge LSR. The 'other edge' of the
region with respect to the LSP path is node-k, where k is the
smallest number greater than i+1 such that link-k <= link-i.
Path computation may take into account region boundaries when
computing a path for an LSP. For example, path computation may
restrict the path taken by an LSP to only the links whose Interface
Switching Capability is PSC-1.
Note that a link may have multiple Interface Switching Capabilities.
In such a case, the test whether link-i < link-(i+1) depends on the
Interface Switching Capabilities chosen for link-i and link-(i+1),
which in turn determines whether or not there is a region boundary at
node-i. Furthermore, if a particular Interface Switching Capability
is chosen at a given link, it needs to be matched with a
corresponding Interface Switching Capability at the end of the
region; this may limit the feasible choices. Path computation must
take both of these into account.
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 6]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
7. Signalling aspects
In this section we describe procedures that an LSR at the head-end of
a forwarding adjacency uses for handling LSP setup originated by
other LSR.
As we mentioned before, establishment/termination of FA-LSPs may
triggered either by mechanisms outside of MPLS (e.g., via
administrative control), or by mechanisms within MPLS (e.g., as a
result of the LSR at the edge of an aggregate LSP receiving LSP setup
requests originated by some other LSRs beyond LSP aggregate and its
edges). Procedures described in Section 7.1 applied to both cases.
Procedures described in Section 7.2 apply only to the latter case.
7.1. Common procedures
For the purpose of processing the ERO in a Path/Request message of an
LSP that is to be tunneled over a forwarding adjacency, an LSR at the
head-end of the FA-LSP views the LSR at the tail of that FA-LSP as
adjacent (one IP hop away).
How this is to be achieved for RSVP-TE and CR-LDP is described in the
following subsections.
In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through
an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's
bandwidth from the unreserved bandwidth of the forwarding adjacency.
In the presence of link bundling (when link bundling is applied to
forwarding adjacencies), when an LSP is tunneled through an FA-LSP,
the LSR at the head-end of the FA-LSP also need to adjust Max LSP
bandwidth of the forwarding adjacency.
7.1.1. RSVP-TE
If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP,
then the Path message MUST contain an IF_ID RSVP_HOP object [GRSVP-
TE, GSIG] instead of an RSVP_HOP object; and the data interface
identification MUST identify the FA-LSP.
The preferred method is to set the destination IP address of the Path
message to the computed NHOP for that Path message. This NHOP
address must be a routable address; in the case of separate control
and data planes, this must be a control plane address.
Furthermore, the IP header for the Path message MUST NOT have the
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 7]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
Router Alert option. The Path message is intended to be IP-routed to
the tail end of the FA-LSP without being intercepted and processed as
an RSVP message by any of the intermediate nodes.
Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general,
if the IF_ID RSVP_HOP object is used, this check must be disabled, as
the number of hops over the control plane may be greater than one.
Instead, the following check is done by the receiver Y of the IF_ID
RSVP_HOP object:
1. Make sure that the data interface identified in the IF_ID
RSVP_HOP object actually terminates on Y.
2. Find the "other end" of the above data interface, say X.
Make sure that the PHOP in the IF_ID RSVP_HOP object is a
control channel address that belongs to X.
How check #2 is carried out is beyond the scope of this document;
suffice it to say that it may require a Traffic Engineering Database,
or the use of LMP [LMP] or yet other means.
An alternative method is to encapsulate the Path message in an IP
tunnel (or, in the case that the Interface Switching Capability of
the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the
message to the tail end of the FA-LSP, without the Router Alert
option. This option may be needed if intermediate nodes process RSVP
messages regardless of whether the Router Alert option is present.
The Resv message back to the head-end of the FA-LSP (PHOP) is IP-
routed to the PHOP in the Path message. If necessary, Resv Messages
MAY be encapsulated in another IP header whose destination IP address
is the PHOP of the received Path message.
7.1.2. CR-LDP
If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP,
then the Request message MUST contain an IF_ID TLV [GCR-LDP] object;
and the data interface identification MUST identify the FA-LSP.
Furthermore, the head end LSR must create a targetted LDP session
with the tail end LSR. The Request (Mapping) message is unicast from
the head end (tail end) to the tail end (head end).
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 8]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
7.2. Specific procedures
When an LSR receives a Path/Request message, the LSR determines
whether it is at the edge of a region with respect to the ERO carried
in the message. The LSR does this by looking up the interface
switching capabilities of the previous hop and the next hop in its
IGP database, and comparing them using the relation defined in
Section 7.2. If the LSR is not at the edge of a region, the
procedures in this section do not apply.
If the LSR is at the edge of a region, it must then determine the
other edge of the region with respect to the ERO, again using the IGP
database. The LSR then extracts the strict hop subsequence from
itself to the other end of the region.
The LSR then compares the strict hop subsequence with all existing
FA-LSPs originated by the LSR; if a match is found, that FA-LSP has
enough unreserved bandwidth for the LSP being signaled, and the L3PID
of the FA-LSP is compatible with the L3PID of the LSP being signaled,
the LSR uses that FA-LSP as follows. The Path/Request message for
the original LSP is sent to the egress of the FA-LSP, not to the next
hop along the FA- LSP's path. The PHOP in the message is the address
of the LSR at the head-end of the FA-LSP. Before sending the
Path/Request message, the ERO in that message is adjusted by removing
the subsequence of the ERO that lies in the FA-LSP, and replacing it
with just the end point of the FA-LSP.
Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA-
LSP. That is, it initiates a new LSP setup just for the FA-LSP.
After the LSR establishes the new FA-LSP, the LSR announces this LSP
into IS-IS/OSPF as a forwarding adjacency.
The unreserved bandwidth of the forwarding adjacency is computed by
subtracting the bandwidth of sessions pending the establishment of
the FA-LSP associated from the bandwidth of the FA-LSP.
An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP
as a matter of policy local to the LSR. It is expected that the FA-
LSP would be torn down once there are no more LSPs carried by the FA-
LSP. When the FA-LSP is torn down, the forwarding adjacency
associated with the FA-LSP is no longer advertised into IS-IS/OSPF.
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 9]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
7.3. FA-LSP Holding Priority
The value of the holding priority of an FA-LSP must be the minimum of
the configured holding priority of the FA-LSP and the holding
priorities of the LSPs tunneling through the FA-LSP (note that
smaller priority values denote higher priority). Thus, if an LSP of
higher priority than the FA-LSP tunnels through the FA-LSP, the FA-
LSP is itself promoted to the higher priority. However, if the
tunneled LSP is torn down, the FA-LSP need not drop its priority to
its old value right away; it may be advisable to apply hysteresis in
this case.
If the holding priority of an FA-LSP is configured, this document
restricts it to 0.
8. Security Considerations
Security issues are not discussed in this document.
9. Acknowledgements
Many thanks to Alan Hannan, whose early discussions with Yakov
Rekhter contributed greatly to the notion of Forwarding Adjacencies.
We would also like to thank George Swallow, Quaizar Vohra and Ayan
Banerjee.
10. References
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in
progress)
[GCR-LDP] Ashwood-Smith, Berger et al, "Generalized MPLS - CR-LDP
Extensions" (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-01.txt (work in progress)
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-kompella-ospf-
gmpls-extensions-01.txt (work in progress)
[GRSVP-TE] Ashwood-Smith, Berger et al, "Generalized MPLS - RSVP-TE
Extensions" (work in progress).
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 10]
Internet Draft draft-ietf-mpls-lsp-hierarchy-03.txt May 2001
[GSIG] Ashwood-Smith, Berger et al, "Generalized MPLS - Signaling
Functional Description" (work in progress).
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-02.txt (work in progress)
[OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to
OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress)
[UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work
in progress)
[UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress)
11. Author Information
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
e-mail: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
e-mail: yakov@juniper.net
draft-ietf-mpls-lsp-hierarchy-03.txt [Page 11]