Internet Draft
Network Working Group                              Kireeti Kompella
Internet Draft                                     Juniper Networks
Expiration Date:  December 2000                       Yakov Rekhter
                                                      Cisco Systems
                                                         Lou Berger
                                               LabN Consulting, LLC

               Link Bundling in MPLS Traffic Engineering

                   draft-kompella-mpls-bundle-01.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          June 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 either be unnumbered, or all components links
   must be numbered identically.  In the former case, the bundled link
   may be either unnumbered or numbered with IP addresses assigned to
   some "virtual" interfaces on an LSR (it is assumed that an LSR may
   have multiple virtual interfaces).  In the latter case, the bundled
   link is numbered the same as the component links.


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 bearer channels of a MPL(ambda)S link (see
   [RTG]), LSP setup signaling 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
   working links should be taken into account.



Kompella, K., Rekhter, Y., Berger, L.                           [Page 2]

Internet Draft      draft-kompella-mpls-bundle-02.txt          June 2000


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 component links of a bundled link are numbered, the Local and
   Remote Interface IP addresses of the bundled link are the same as for
   the component links.

   If the component links are unnumbered, the bundled link may also be
   unnumbered, in which case the Local Address is the Router ID of the
   advertising LSR, and the Remote Address is the Router ID of the
   neighboring LSR.  Or, the bundled link may be associated with the
   addresses of a virtual interface, in which case the Local and Remote
   Addresses are those of the virtual interface.


4.4. Traffic Engineering Metric

   The Traffic Engineering Metric for a bundled link is that of the
   component links.







Kompella, K., Rekhter, Y., Berger, L.                           [Page 3]

Internet Draft      draft-kompella-mpls-bundle-02.txt          June 2000


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.

   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



Kompella, K., Rekhter, Y., Berger, L.                           [Page 4]

Internet Draft      draft-kompella-mpls-bundle-02.txt          June 2000


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





Kompella, K., Rekhter, Y., Berger, L.                           [Page 5]

Internet Draft      draft-kompella-mpls-bundle-02.txt          June 2000


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 LABEL REQUEST object is modified
   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. LABEL_REQUEST with Link ID

   The Path message from [RSVP-TE] has a LABEL_REQUEST object with Class
   Num 19 (to be determined by IANA) and C_Types 1, 2 and 3.  Here, we
   define a new format for the LABEL_REQUEST object with the same Class
   Num, and C_Type 4 as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |             L3PID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Link Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The receiver of a LABEL_REQUEST with C_Type 4 treats it as if a
   LABEL_REQUEST of C_Type 1 was received over the link identified by
   the Link Identifier.

   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 LABEL_REQUEST object, or is
   incapable of providing a label binding, it SHOULD send a PathErr
   message with an "Unknown Object Class" or an "Unknown Object C-Type"
   error.  A node that recognizes the LABEL_REQUEST object, but that is
   unable to support it (possibly because of a failure to allocate
   labels) SHOULD send a PathErr with the error code "Routing problem"
   and the error value "MPLS label allocation failure."  If LMP or some



Kompella, K., Rekhter, Y., Berger, L.                           [Page 6]

Internet Draft      draft-kompella-mpls-bundle-02.txt          June 2000


   other link identification protocol is not running, or there is no
   component link with the Link Identifier in the LABEL_REQUEST object,
   the receiver SHOULD send a PathErr with the error code "Routing
   problem" and the error value "Unknown Link ID".  If the receiver
   cannot support the protocol L3PID, it SHOULD send a PathErr with the
   error code "Routing problem" and the error value "Unsupported L3PID."


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          June 2000


   Lou Berger
   LabN Consulting, LLC
   Voice: +1 301 468 9228
   Email: lberger@labn.net















































Kompella, K., Rekhter, Y., Berger, L.                           [Page 8]