Network Working Group                              Kireeti Kompella
Internet Draft                                     Juniper Networks
Expiration Date:  August 2000                         Yakov Rekhter
                                                      Cisco Systems


               Link Bundling in MPLS Traffic Engineering

                   draft-kompella-mpls-bundle-00.txt


. 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.


. Abstract

   In some cases a pair of LSRs may be connected by several (parallel)
   links. From the MPLS Traffic Engineering point of view for the
   purpose of scalability it may be desirable to treat all these links
   as a single IP link. This document describes how to accomplish this.












Kompella, K., Rekhter, Y.                                       [Page 1]

Internet Draft     draft-kompella-mpls-bundle-00.txt      Februrary 2000


. Unnumbered links as a bundle

   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/ISIS.
   We refer to this process as "link bundling", or just "bundling". We
   refer to the link that is advertised into OSPF/ISIS as a "bundled
   link". We refer to the links associated with that bundled link as
   "component links".

   Component links are expected to be unnumbered. A bundled link could
   be either unnumbered or numbered with IP addresses assigned to some
   "virtual" interfaces on a router (it is assumed that a router may
   have multiple virtual interfaces).

   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 over the the maximum reservable bandwidth for all
   the component links associated with the bundled link.

   The maximum LSP bandwidth (as described below) replaces the maximum
   link bandwidth for bundled links.

   We assume that for a given bundled link either each of its component
   links is configured with the maximum LSP bandwidth per priority, or
   the bundled link is configured with the maximum LSP bandwidth per
   priority.  In the former case the maximum LSP bandwidth for a given
   priority of the bundled link is set to the maximum over maximum LSP
   bandwidth for that priority for all the component links associated
   with the bundled link.

   By default the unreserved bandwidth of a bundled link is set to the
   sum of all the unreserved bandwidths on all the component links
   associated with the bundled link.

   RSVP must track the unreserved bandwidth on each individual component
   link.

   If one of the component links goes down, that results in changing the
   unreserved bandwidth of the associated bundled link, provided that at
   least one other component link associated with the bundled link is
   up.  When all the component links associated with a given bundled
   link are down, the bundled link should not be advertised into
   OSPF/ISIS.

   This document assumes that the label returned in the Label Object of



Kompella, K., Rekhter, Y.                                       [Page 2]

Internet Draft     draft-kompella-mpls-bundle-00.txt      Februrary 2000


   the Resv message is associated with the interface over which the
   corresponding Path message is received. Therefore, this document
   assumes that for a given bundled link connected to an LSR, the LSR
   should be able to send the Path message over any of the component
   links associated with the bundled link.

   Procedures that would allow the label returned in the Label Object of
   the Resv message to be associated with the interface different from
   the one over which the corresponding Path message is received are
   outside the scope of this document. That is, handling the case where
   an LSR may not be able to send the Path message over some of the
   component links, while still being able to place LSPs over these
   links is outside the scope of this document.


. Maximum LSP bandwidth TLV

   The bandwidth allocated to a single LSP is limited (from above) by
   the physical capacity of the links traversed by the LSP, as well as
   other (already existing) LSPs that traverse the links. This value is
   determined based on the physical link bandwidth, ignoring any
   oversubscription factor.

   Maximum LSP bandwidth is carried on a per priority level. This allows
   to control the maximum amount of bandwidth that an LSP with a given
   priority could allocate.

   On a bundled link, the maximum LSP bandwidth for a given priority is
   set to the maximum of the maximum LSP bandwidth for that priority
   over all the component links associated with the bundled link.

   In ISIS, this 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, with
   type 11.

   The Maximum bandwidth LSP sub-TLV is a list of two-tuples, of which
   the first field is a 4 octet field, and the second is a one octet
   field. The first field in a tuple encodes the maximum bandwidth in
   units of bytes (not bits) per second as an IEEE floating point
   number. The second field in the tuple encodes the value of the lowest
   holding priority that an LSP has to have in order to reserve up to
   the maximum bandwidth specified in the first field.

   The difference between maximum LSP bandwidth and unreserved bandwidth
   is that the former is computed based on the actual link bandwidth,
   while the latter may reflect oversubscription.

   This sub-TLV is expected to supersede the maximum link bandwidth



Kompella, K., Rekhter, Y.                                       [Page 3]

Internet Draft     draft-kompella-mpls-bundle-00.txt      Februrary 2000


   sub-TLV.


. Acknowledgements


. References

   [Smit] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering",
   draft-ietf-isis-traffic-01.txt

   [Katz] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF",
   draft-katz-yeung-ospf-traffic-01.txt


. Author Information


   Kireeti Kompella
   Juniper Networks, Inc.
   385 Ravendale Drive
   Mountain View, CA 94043
   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.                                       [Page 4]