Network Working Group Kireeti Kompella
Internet Draft Juniper Networks
Expiration Date: January 2001 Yakov Rekhter
Cisco Systems
Lou Berger
LabN Consulting, LLC
Link Bundling in MPLS Traffic Engineering
draft-kompella-mpls-bundle-02.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 how to accomplish this.
Kompella, K., Rekhter, Y., Berger, L. [Page 1]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
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 interfaces 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".
3.1. Restrictions on Bundling
All component links in a bundle must have the same Link Type (if
any), the same Traffic Engineering metric, the same set of resource
classes, and the same Link Multiplex Capability (see [RTG]).
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.
Component links may be unnumbered, or the various component links may
be numbered differently, or all components links may be numbered
identically. In the first two cases, the bundled link is unnumbered
by default; in the last case, the bundled link is numbered the same
as the component links by default. In all cases, the bundled link's
addresses may be overridden by configuration with IP addresses
assigned to some "virtual" interfaces on an LSR (it is assumed that
an LSR may have multiple virtual interfaces).
3.2. Other Considerations
If several component links are bundled, IS-IS/OSPF flooding can be
restricted to just one of the component links. Similarly, IS-IS/OSPF
hellos can be restricted to just one component link; however, it may
be useful to send hellos on all links that do not have a link layer
keep-alive mechanism to ensure that a failure of the link is
detected.
If the component links are not Packet Switch Capable, LSP setup
signalling needs to identify the component link to use. This
protocol is outside the scope of this document; however, see [LMP].
If a bundled link consists of "working" and "protect" component
links, then for the purposes of bandwidth computation, only the
Kompella, K., Rekhter, Y., Berger, L. [Page 2]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
working links should be taken into account.
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.
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] and [OSPF];
we use the terminology from [OSPF].
4.1. 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. 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 (see section 3.1), 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.
If the bundled link is unnumbered, the Local Address is the Router ID
of the advertising LSR, and the Remote Address is the Router ID of
the neighboring LSR.
Kompella, K., Rekhter, Y., Berger, L. [Page 3]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
4.4. Traffic Engineering Metric
The Traffic Engineering Metric for a bundled link is that of the
component links.
4.5. Maximum Link Bandwidth
This TLV is not used. The maximum LSP Bandwidth (as described below)
replaces the maximum link bandwidth for bundled links. For backward
compatibility, one MAY advertise the Maximum LSP Bandwidth at
priority 7 of the bundle.
4.6. Maximum Reservable Bandwidth
We assume that for a given bundled link either each of its component
links is configured with the maximum reservable bandwidth, or the
bundled link is configured with the maximum reservable bandwidth. In
the former case, the Maximum Reservable Bandwidth of the bundled link
is set to the sum of the maximum reservable bandwidths of all
component links associated with the bundled link.
4.7. 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.8. Resource Classes (Administrative Groups)
The Resource Classes for a bundled link are the same as those of the
component links.
4.9. Maximum LSP Bandwidth
The Maximum LSP Bandwidth takes the place of the Maximum Link
Bandwidth. However, while Maximum Link Bandwidth is a single fixed
value (usually simply the link capacity), Maximum LSP Bandwidth is
carried per priority, and may vary as LSPs are set up and torn down.
The Maximum LSP Bandwidth of a bundled link at priority p is defined
to be the maximum of the Maximum LSP Bandwidth at priority p of each
component link.
Kompella, K., Rekhter, Y., Berger, L. [Page 4]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
If a component link is a simple (unbundled) link, define its Maximum
LSP Bandwidth at priority p to be the smaller of its unreserved
bandwidth at priority p and its maximum link bandwidth.
Since bundling may be applied recursively, a component link may
itself be a bundled link. In this case, its Maximum LSP Bandwidth as
a component link is the same as its Maximum LSP Bandwidth as a
bundled link.
In IS-IS, the Maximum LSP Bandwidth TLV is a sub-TLV of the Extended
IS Reachability TLV with type 21. In OSPF, this TLV is a sub-TLV of
the Link TLV within the Traffic Engineering LSA, with type 11. The
length of the Maximum LSP Bandwidth TLV is 32 octets. The value is a
list of eight 4 octet fields in IEEE floating point format of the
Maximum LSP Bandwidth of the bundle, from priority 0 to priority 7.
5. Procedures
5.1. Bandwidth Accounting
The RSVP Traffic Control module 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 RSVP module must track the unreserved bandwidth
(per priority) for each component link. This is done as follows. If
an LSP with bandwidth b and holding priority p is set up through a
component link, that component link's unreserved bandwidth at
priority p and lower is reduced by b. If an LSP with bandwidth b and
holding priority p that is currently set up through a component link
is torn down, the unreserved bandwidth at priority p and lower for
that component link is increased by b.
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
Kompella, K., Rekhter, Y., Berger, L. [Page 5]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
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.
5.2. Signaling
Signaling must identify both the component link to use and the label
to use. The sender of the Path message identifies the component link
to be used for the LSP. The sender of the Resv message chooses the
label (as before). If the bundled link is composed of packet-switch
capable links and there is no designated control channel, then the
component link to be used is the link over which the Path message is
sent.
If, however, there is a protocol such as LMP that uniquely identifies
each component link and allocates a designated control channel, then
the sender of the Path message MUST send the Path message over the
control channel. In this case, the LINK_ID object is used to
identify the component link to use. This method of choosing the link
is required if the component links are not packet-switch capable.
5.2.1. LINK_ID object
A new object, the LINK_ID object, is defined. The Length field is
set to 8. The Class Num and C_Type of the LINK_ID object are to be
obtained from IANA. The format is given below; it consists simply of
a 32-bit Link Identifier that identifies the link to be used for the
LSP being set up.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class Num (TBD)| C_Type (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object is an optional subobject of the Path and Resv messages.
We introduce a new error value for the error code "Routing problem",
namely "Unknown Link ID" with error value 11.
If the receiver doesn't recognize the LINK_ID object, it SHOULD send
an error message with an "Unknown Object Class" or an "Unknown Object
C-Type" error. A node that recognizes the LINK_ID object, but that
Kompella, K., Rekhter, Y., Berger, L. [Page 6]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
is unable to support it (possibly because of a failure to allocate
labels) SHOULD send an error message with the error code "Routing
problem" and the error value "MPLS label allocation failure." If LMP
or some other link identification protocol is not running, or there
is no component link with the Link Identifier in the LINK_ID object,
the receiver SHOULD send an error message with the error code
"Routing problem" and the error value "Unknown Link ID".
6. Security Considerations
This document raises no new security issues for IS-IS, OSPF or RSVP.
7. References
[ISIS] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering",
draft-ietf-isis-traffic-01.txt (work in progress)
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
draft-lang-mpls-lmp-00.txt (work in progress)
[OSPF] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF",
draft-katz-yeung-ospf-traffic-01.txt (work in progress)
[RSVP-TE] Awduche, D., Berger, L., Gan, D., et al, "Extensions to
RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-05.txt (work
in progress)
[RTG] Kompella, K., Rekhter, Y., et al, "Extensions to IS-IS/OSPF and
RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical.txt
(work in progress) (new version forthcoming)
8. Author Information
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Yakov Rekhter
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: yakov@cisco.com
Kompella, K., Rekhter, Y., Berger, L. [Page 7]
Internet Draft draft-kompella-mpls-bundle-02.txt July 2000
Lou Berger
LabN Consulting, LLC
Voice: +1 301 468 9228
Email: lberger@labn.net
Kompella, K., Rekhter, Y., Berger, L. [Page 8]