Network Working Group Kireeti Kompella
Internet Draft Juniper Networks
Expiration Date: March 2002 Yakov Rekhter
Juniper Networks
Lou Berger
Movaz Networks
Link Bundling in MPLS Traffic Engineering
draft-ietf-mpls-bundle-00.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
In some cases a pair of Label Switching Routers (LSRs) may be
connected by several (parallel) links. From the MPLS Traffic
Engineering point of view for reasons of scalability it may be
desirable to advertise all these links as a single link into OSPF
and/or IS-IS. This document describes a mechanism to accomplish this.
Kompella, K., Rekhter, Y., Berger, L. [Page 1]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
3. Link Bundling
When a pair of LSRs are connected by multiple links, then for the
purpose of MPLS Traffic Engineering it is possible to advertise
several (or all) of these links as a single link into OSPF and/or IS-
IS. We refer to this process as "link bundling", or just "bundling".
We refer to the link that is advertised into OSPF/IS-IS as a "bundled
link". We refer to the links associated with that bundled link as
"component links".
Link bundling can be applied recursively. That is, a bundled link
that consists of multiple component links may itself be a component
link of some other bundled link.
The purpose of link bundling is to improve routing scalability by
reducing the amount of information that has to be handled by OSPF
and/or IS-IS. This reduction is accomplished by performing
information aggregation/abstraction. As with any other information
aggregation/abstraction, this results in losing some of the
information. To limit the amount of losses one need to restrict the
type of the information that can be aggregated/abstracted.
3.1. Restrictions on Bundling
All component links in a bundle must begin and end on the same pair
of LSRs, have the same Link Type (i.e., point-to-point or multi-
access), the same Traffic Engineering metric, and the same set of
resource classes at each end of the links. A Forwarding Adjacency may
be a component link; in fact, a bundle can consist of a mix of point-
to-point links and FAs.
If the component links are all multi-access links, the set of IS-IS
or OSPF routers connected to each component link must be the same,
and the Designated Router for each component link must be the same.
If these conditions cannot be enforced, multi-access links must not
be bundled.
3.2. Routing Considerations
A bundled link is just another kind of Traffic Engineering (TE) link
(see [GMPLS-ROUTING]). The "liveness" of the bundled link is
determined by the liveness of each of the component links within the
bundled link - a bundled link is alive when at least one its
component links is determined to be alive. The liveness of a
component link can be determined by any of several means: IS-IS or
OSPF hellos over the component link, or RSVP Hello, or LMP hellos
Kompella, K., Rekhter, Y., Berger, L. [Page 2]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
(see [LMP]), or from layer 1 or layer 2 indications.
Once a bundled link is determined to be alive, it can be advertised
as a TE link and the TE information can be flooded. If IS-IS/OSPF
hellos are run over the component links, IS-IS/OSPF flooding can be
restricted to just one of the component links [ZININ] [MOY].
Note that advertising a (bundled) TE link between a pair of LSRs
doesn't imply that there is an IGP adjacency between these LSRs that
is associated with just that link. In fact, in certain cases a TE
link between a pair of LSRs could be advertised even if there is no
IGP adjacency at all between the LSRs (e.g., when the TE link is an
FA).
A component link may be either numbered or unnumbered. A bundled link
may itself be numbered or unnumbered independent of whether the
component links are numbered or not. This affects how the bundled
link is advertised in IS-IS/OSPF, and the format of LSP EROs that
traverse the bundled link. Furthermore, unnumbered Interface
Identifiers for all unnumbered outgoing links of a given LSR (whether
component links, Forwarding Adjacencies or bundled links) MUST be
unique in the context of that LSR.
In the future, as new Traffic Engineering parameters are added to IS-
IS and OSPF, they should be accompanied by descriptions as to how
they can be bundled, and possible restrictions on bundling.
3.3. Signaling Considerations
Typically, an LSP's ERO will choose the bundled link to be used for
the LSP, but not the component link(s), since information about the
bundled link is flooded, but information about the component links is
not. If the ERO chooses the component links by means outside the
scope of this document, this section does not apply. Otherwise, the
choice of the component link(s) for the LSP is a local matter between
the two LSRs at each end of the bundled link.
Signaling must identify both the component link to use and the label
to use. The choice of the component link to use is always made by the
sender of the Path/REQUEST message (if an LSP is bidirectional
[GMPLS-SIG], the sender chooses a component link in each direction).
For unidirectional LSPs, and the forward direction of bidirectional
LSPs, the sender of a Resv/MAPPING message chooses the label. For the
reverse direction of a bidirectional LSP, the sender of the
Path/REQUEST message selects the upstream label.
Two mechanisms for identifying the component link to the receiver of
Kompella, K., Rekhter, Y., Berger, L. [Page 3]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
the Path/REQUEST message are described below; which of these
mechanisms is used SHOULD be configurable by the user, preferably on
a per-bundle basis. Both mechanisms work with either numbered or
unnumbered component links.
3.3.1. Mechanism 1: Implicit Indication
This mechanism requires that each component link has a dedicated
signaling channel (for example, the link is packet-switch capable; or
the link is a SONET link with an in-band channel for signaling). The
sender of the Path/REQUEST message tells the receiver which component
link to use by sending the message over the chosen component link's
dedicated signaling channel.
3.3.2. Mechanism 2: Explicit Indication by Interface ID
With RSVP the choice of the component link is indicated by the sender
of the Path message by including the IF_ID RSVP_HOP object in the
Path message, as described in section 8 of [GMPLS-RSVP]. With CR-LDP
the choice of the component link is indicated by the sender of the
REQUEST message by including the IF_ID TLV in the REQUEST message, as
described in section 8 of [GMPLS-CRLDP].
If the component link is numbered, the IF_ID RSVP_HOP object, or
IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
address) TLVs (see [GMPLS-SIG]). If the component link is unnumbered,
the IF_ID RSVP_HOP object, or IF_ID TLV carries Type 4
(COMPONENT_IF_DOWNSTREAM) TLV, and in the case of a bidirectional LSP
also Type 5 (COMPONENT_IF_UPSTREAM) TLV (see [GMPLS-SIG]). The value
carried in Type 4 and Type 5 TLVs contains the outgoing interface
identifier (from the point of view of the sender of the Path/REQUEST
message) of the selected component link.
When the IF_ID RSVP_HOP or IF_ID TLV carries the IPv4 or IPv6 address
(component link is numbered), this address identifies the link for
which label allocation must be done.
When a component link is unnumbered, this mechanism requires that
each component link is assigned a unique Interface Identifier per
[UNNUM-RSVP] or [UNNUM-CRLDP], and that the assigned identifiers be
exchanged by the two LSRs at each end of the bundled link.
Exchanging the identifiers may be accomplished by configuration, by
means of a protocol such as LMP ([LMP]), by means of RSVP/CR-LDP
(especially in the case where a component link is a Forwarding
Adjacency), or by means of IS-IS or OSPF extensions ([ISIS-GMPLS],
Kompella, K., Rekhter, Y., Berger, L. [Page 4]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
[OSPF-GMPLS]).
When the IF_ID RSVP_HOP or IF_ID TLV carries the
COMPONENT_IF_DOWNSTREAM TLV (component link is unnumbered), the LSR
that receives the Path/REQUEST message determines the component link
for which label allocation must be done as follows. First the LSR
checks whether the tuple <IP Address, Interface ID> carried in
COMPONENT_IF_DOWNSTREAM matches the tuple <Router ID, Forwarding
Interface ID> (see [RSVP-UNNUM], [CRLDP-UNNUM]) of any LSPs for which
the LSR is a tail-end. If the 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 <IP Address,
Interface ID> carried in COMPONENT_IF_DOWNSTREAM matches the tuple
<Router ID, Reverse Interface ID> (see [RSVP-UNNUM], [CRLDP-UNNUM])
of any of the bidirectional LSPs for which 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.
Otherwise, the LSR must have information about the identifiers
assigned by its neighbors to the component links (i.e., incoming
interface identifiers from LSR's point of view). The LSR uses this
information to find a (component) link with tuple <Router ID,
incoming interface identifier> matching the tuple <IP Address,
Interface ID> carried in COMPONENT_IF_DOWNSTREAM. If the matching
tuple is found, the match identifies the (component) link for which
the LSR has to perform label allocation.
In both RSVP and CR-LDP, if the Interface ID field of
COMPONENT_IF_DOWNSTREAM has the special value of 0xffffffff, this
means that the same label is to be valid across all component links
in the downstream direction. Likewise, if the Interface ID field of
COMPONENT_IF_UPSTREAM has the special value of 0xffffffff, this means
that the same label is to be valid across all component links in the
upstream direction.
Kompella, K., Rekhter, Y., Berger, L. [Page 5]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
4. Traffic Engineering Parameters for Bundled Links
In this section, we define the Traffic Engineering parameters to be
advertised for a bundled link, based on the configuration of the
component links and of the bundled link. The definition of these
parameters for component links was undertaken in [ISIS-TE] and [OSPF-
TE]; we use the terminology from [OSPF-TE].
4.1. OSPF Link Type
The Link Type of a bundled link is the (unique) Link Type of the
component links. (Note: this parameter is not present in IS-IS.)
4.2. OSPF Link ID
For point-to-point links, the Link ID of a bundled link is the
(unique) Router ID of the neighbor. For multi-access links, this is
the interface address of the (unique) Designated Router. (Note: this
parameter is not present in IS-IS.)
4.3. Local and Remote Interface IP Address
(Note: in IS-IS, these are known as IPv4 Interface Address and IPv4
Neighbor Address, respectively.)
If the bundled link is numbered, the Local Interface IP Address is
the local address of the bundled link; similarly, the Remote
Interface IP Address is the remote address of the bundled link.
4.4. Outgoing and Incoming Interface Identifiers
If the bundled link is unnumbered, the Outgoing Interface Identifier
is set to the outgoing interface identifier chosen for the bundle by
the advertising LSR. The Incoming Interface Identifier is set to the
outgoing interface identifier chosen by the neighboring LSR for the
reverse link corresponding to this bundle, if known; otherwise, this
is set to 0.
Kompella, K., Rekhter, Y., Berger, L. [Page 6]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
4.5. Traffic Engineering Metric
The Traffic Engineering Metric for a bundled link is that of the
component links.
4.6. Maximum Link Bandwidth
This TLV is not used. The maximum LSP Bandwidth (as described below)
replaces the maximum link bandwidth for bundled links.
4.7. Total Reservable Bandwidth
We assume that for a given bundled link either each of its component
links is configured with the Total Reservable Bandwidth, or the
bundled link is configured with the Total Reservable Bandwidth. In
the former case, the Total Reservable Bandwidth of the bundled link
is set to the sum of the Total Reservable Bandwidths of all component
links associated with the bundled link.
4.8. Unreserved Bandwidth
The unreserved bandwidth of a bundled link at priority p is the sum
of the unreserved bandwidths at priority p of all the component links
associated with the bundled link.
4.9. Resource Classes (Administrative Groups)
The Resource Classes for a bundled link are the same as those of the
component links.
4.10. Maximum LSP Bandwidth
The Maximum LSP Bandwidth takes the place of the Maximum Link
Bandwidth. It is defined in [GMPLS-ROUTING]. The details of how
Maximum LPS Bandwidth is carried in IS-IS is given in [GMPLS-ISIS].
The details of how Maximum LSP Bandwidth is carried in OSPF is given
in [GMPLS-OSPF].
Maximum LSP Bandwidth of a bundled link is equal to the maximum of
Maximum LSP Bandwidth of all of its component links.
Since bundling may be applied recursively, a component link may
itself be a bundled link. In this case, its Maximum LSP Bandwidth as
Kompella, K., Rekhter, Y., Berger, L. [Page 7]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
a component link is the same as its Maximum LSP Bandwidth as a
bundled link.
5. Bandwidth Accounting
The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
LSR with bundled links must apply admission control on a per-
component link basis. An LSP with a bandwidth requirement b and setup
priority p fits in a bundled link if at least one component link has
maximum LSP bandwidth >= b at priority p. If there are several such
links, the choice of which link is used for the LSP is up to the
implementation.
In order to know the maximum LSP bandwidth (per priority) of each
component link, the Traffic Control module must track the unreserved
bandwidth (per priority) for each component link.
A change in the unreserved bandwidth of a component link results in a
change in the unreserved bandwidth of the bundled link. It also
potentially results in a change in the maximum LSP bandwidth of the
bundle; thus, the maximum LSP bandwidth should be recomputed.
If one of the component links goes down, the associated bundled link
remains up and continues to be advertised, provided that at least one
component link associated with the bundled link is up. The
unreserved bandwidth of the component link that is down is set to
zero, and the unreserved bandwidth and maximum LSP bandwidth of the
bundle must be recomputed. If all the component links associated with
a given bundled link are down, the bundled link MUST not be
advertised into OSPF/IS-IS.
6. Security Considerations
This document raises no new security issues for RSVP or CR-LDP.
Kompella, K., Rekhter, Y., Berger, L. [Page 8]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
7. References
[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-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al,
"Routing Extensions in Support of Generalized MPLS", draft-ietf-
ccamp-gmpls-routing-00.txt
[GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling
Functional Description", draft-ietf-generalized-mpls-
signalling-05.txt
[GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP-
TE Extensions", draft-ietf-mpls-generalized-rsvp-te-04.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., Li, T., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-02.txt (work in progress)
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-00.txt (work in progress)
[MOY] Moy, J., draft-ietf-ospf-ppp-flood-00.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-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress)
[ZININ] Zinin, A., Shand, M., "Flooding optimizations in link-state
routing protocols", draft-ietf-ospf-isis-flood-opt-00.txt (work in
progress)
Kompella, K., Rekhter, Y., Berger, L. [Page 9]
Internet Draft draft-ietf-mpls-bundle-00.txt September 2001
8. Author Information
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
Email: yakov@juniper.net
Lou Berger
Movaz Networks, Inc.
Voice: +1 301 468 9228
Email: lberger@movaz.com
Kompella, K., Rekhter, Y., Berger, L. [Page 10]
