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

               Link Bundling in MPLS Traffic Engineering

                   draft-kompella-mpls-bundle-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

   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.  This
   document also defines corresponding signaling (RSVP-TE) support.









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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 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 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".

   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 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 [LSP-HIER]).

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

   Component links may be either numbered or unnumbered. If all the
   component links within a bundled link are unnumbered, then the
   bundled link is unnumbered 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).

   If a component link is numbered, this document assumes that the link
   has a dedicated control channel (which may be the link itself) that
   could be used to send RSVP/CR-LDP messages. If a component link is
   unnumbered, then the link may, but doesn't have to have a dedicated
   control channel.  In this case, the bundled link must have a control
   channel that is shared by all component links that do not have



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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


   dedicated control channels.

   If a bundled link is unnumbered, then it has to have its own
   interface identifier, just like any other unnumbered link [UNNUM].

   This document assumes that each unnumbered component link on a Label
   Switching Router (LSR) is given a 16-bit identifier by this LSR.  We
   refer to this identifier as the component interface identifier. The
   scope of this identifier is the bundled link that contains the
   component link.  Thus multiple component links on an LSR may share
   the same component interface identifier, as long as these component
   links belong to different bundled links. The component interface
   identifiers are not visible to the IS-IS and/or OSPF, but are visible
   to RSVP and/or CR-LDP.


3.3. Other Considerations

   If several component links are bundled, IS-IS/OSPF flooding can be
   restricted to just one of the component links [ZININ]. 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 mechanism (e.g., keep-alive) to ensure that a
   failure of the link is detected.

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








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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


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 interface IP address
   (OSPF) or IPv4 interface address (ISIS) is set to the Router ID of
   advertising LSR.  The first two octets of the remote interface IP
   address (OSPF) or IPv4 neighbor address (ISIS) are set to zero; the
   remaining two octets are set to the interface identifier assigned to
   the bundled link.


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 as the Maximum Link Bandwidth.


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.



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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


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












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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


5. Procedures


5.1. Bandwidth Accounting

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


5.2. Signaling

   Signaling must identify both the component link to use and the label
   to use.  For unidirectional LSPs the sender of the Resv message
   chooses the label (as before).  The sender of the Path message
   selects the component link to be used for the LSP and communicates
   the choice downstream.  For bidirectional LSPs [GMPLS-SIG], in
   addition to the above, the sender of the Path message selects the
   (upstream) label, and the component link to be used with the
   (upstream) label, and communicates the choice downstream.




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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


   There are two methods for communicating the selected component link.
   The first method communicates the selected component link via the
   COMPONENT_INTERFACE_ID object class defined below. Doing this assumes
   that an LSR connected to a component link knows the component
   interface identifier assigned to that link by the LSR at the other
   end of the link. Exchanging the identity of a component link between
   the LSRs connected by that link is accomplished either by
   configuration or by means of a protocol such as [LMP], or in the case
   where a component link is a Forwarding Adjacency by RSVP/CR-LDP
   [LSP-HIER].

   The second method is for the upstream node to indicate the selected
   link by sending the Path message over the control channel
   corresponding to the selected component link.  This method may only
   be used when LMP is not used or there are no configured component
   link values, and when there is a one-to-one correspondence between
   component links and control channels.  When this method is used on
   bidirectional LSPs, both upstream and downstream labels MUST be
   assigned on the same component link.

   When a component link is numbered, the first method is non-
   applicable, and only the second method is used.


5.2.1. COMPONENT_INTERFACE_ID Object Class

   A new object class, the COMPONENT_INTERFACE_ID object class, is
   defined.  The Length field is set to 8.  The Class Num is TBD of form
   0bbbbbbb.  The DOWNSTREAM_COMPONENT_INTERFACE_ID object, which has a
   C_Type of 1, is used to indicate the component interface to be used
   for traffic flowing in the downstream direction.  The
   UPSTREAM_COMPONENT_INTERFACE_ID object, which has a C_Type of 2, is
   used to indicate the component interface to be used for traffic
   flowing in the upstream direction.  Both objects have the same format
   and carry a 16-bit Component Interface Identifier.  The format of the
   objects are:

       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 (1|2) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Reserved               | Component Interface Identifier|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   We introduce a new error value for the error code "Routing problem",
   namely "Unknown Component Interface ID" with error value 11.




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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


   If the receiver doesn't recognize the COMPONENT_INTERFACE_ID object
   class, per [RSVP], it SHOULD send an error message with an "Unknown
   Object Class". If the class is recognize but the C-Type is not, per
   [RSVP], the receiver SHOULD send an "Unknown Object C-Type" error.  A
   node that recognizes either COMPONENT_INTERFACE_ID objects, but that
   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 Component Interface Identifier in
   either object, the receiver SHOULD send an error message with the
   error code "Routing problem" and the error value "Unknown Component
   Interface ID".


5.2.2. COMPONENT_INTERFACE_ID Object Class Usage

   The COMPONENT_INTERFACE_ID objects are carried in RSVP messages as
   part of the sender descriptor.  They are optional with respect to the
   protocol, and are only used when component links are being identified
   using the COMPONENT_INTERFACE_ID objects.  There are two formats for
   the sender descriptor, one for traditional LSPs and one for
   bidirectional LSPs.

   The format of the sender descriptor for unidirectional LSPs is:

           ::=   
                                   [  ]
                                   [  ]
                                   
                                   [  ]

   The format of the sender descriptor for bidirectional LSPs is:

           ::=   
                                   [  ]
                                   [  ]
                                   
                                   [  ]
                                   
                                   










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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


6. Security Considerations

   This document raises no new security issues for IS-IS, OSPF or RSVP.


7. References

   [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling
   Functional Description", draft-ashood-generalized-mpls-signalling-
   00.txt

   [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] Braden, Ed., et. al., "Resource ReSerVation Protocol (RSVP) --
   Version 1 Functional Specification", RFC2205, September 1997.

   [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)

   [LSP-HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE",
   draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress)

   [UNNUM] Kompella, K., Rekhter, Y., "Traffic Engineering with
   Unnumbered Links", draft-kompella-mpls-unnum-01.txt (work in
   progress)

   [ZININ] Zinin, A., Shand, M., "Flooding optimizations in link-state
   routing protocols", draft-zinin-flood-opt-00.txt (work in progress)















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





Internet Draft     draft-kompella-mpls-bundle-03.txt      September 2000


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

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
































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