Skip to main content

Link Bundling in MPLS Traffic Engineering (TE)
draft-ietf-mpls-bundle-06

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4201.
Authors Yakov Rekhter , Lou Berger , Kireeti Kompella
Last updated 2015-10-14 (Latest revision 2004-12-27)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 4201 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Alex D. Zinin
Send notices to (None)
draft-ietf-mpls-bundle-06
Internet Draft                                          Kireeti Kompella
Updates: 3471, 3472, 3473                               Juniper Networks
Category: Standards Track                                  Yakov Rekhter
Expiration Date: June 2005                              Juniper Networks
                                                              Lou Berger
                                                          Movaz Networks

                                                           December 2004

               Link Bundling in MPLS Traffic Engineering

                     draft-ietf-mpls-bundle-06.txt

1. Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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 a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

2. Abstract

   For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
   signaling in certain cases a combination of <link identifier, label>
   is not sufficient to unambiguously identify the appropriate resource
   used by a Label Switched Path (LSP).  Such cases are handled by using
   the link bundling construct which is described in this document.
   This document updates the interface identification TLVs defined in
   GMPLS Signaling Functional Description, [RFC3471].

Kompella, K., Rekhter, Y., Berger, L.                           [Page 1]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

Contents

 1      Status of this Memo  .......................................   1
 2      Abstract  ..................................................   1
 3      Specification of Requirements  .............................   3
 4      Link Bundling  .............................................   3
 4.1    Restrictions on Bundling  ..................................   4
 4.2    Routing Considerations  ....................................   4
 4.3    Signaling Considerations  ..................................   5
 4.3.1  Interface Identification TLV Format  .......................   6
 4.3.2  Errored Component Identification  ..........................   6
 5      Traffic Engineering Parameters for Bundled Links  ..........   7
 5.1    OSPF Link Type  ............................................   7
 5.2    OSPF Link ID  ..............................................   7
 5.3    Local and Remote Interface IP Address  .....................   7
 5.4    Local and Remote Identifiers  ..............................   7
 5.5    Traffic Engineering Metric  ................................   8
 5.6    Maximum Bandwidth  .........................................   8
 5.7    Maximum Reservable Bandwidth  ..............................   8
 5.8    Unreserved Bandwidth  ......................................   8
 5.9    Resource Classes (Administrative Groups)  ..................   8
 5.10   Maximum LSP Bandwidth  .....................................   8
 6      Bandwidth Accounting  ......................................   9
 7      Security Considerations  ...................................   9
 8      IANA Considerations  .......................................   9
 9      References  ................................................  10
 9.1    Normative References  ......................................  10
 9.2    Non-normative References  ..................................  11
10      Author Information  ........................................  11
11      Full Copyright Statement  ..................................  11
12      Intellectual Property  .....................................  12

Kompella, K., Rekhter, Y., Berger, L.                           [Page 2]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

3. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

4. Link Bundling

   As defined in [GMPLS-ROUTING], a TE link is a logical construct that
   represents a way to group/map the information about certain physical
   resources (and their properties) that interconnect LSRs into the
   information that is used by Constrained SPF for the purpose of path
   computation, and by GMPLS signaling.

   As further stated in [GMPLS-ROUTING], depending on the nature of
   resources that form a particular TE link, for the purpose of GMPLS
   signaling in some cases a combination of <TE link identifier, label>
   is sufficient to unambiguously identify the appropriate resource used
   by an LSP. In other cases, a combination of <TE link identifier,
   label> is not sufficient.  Such cases are handled by using the link
   bundling construct which is described in this document.

   Consider a TE link such that for the purpose of GMPLS signaling a
   combination of <TE link identifier, label> is not sufficient to
   unambiguously identify the appropriate resources used by an LSP.  In
   this situation the link bundling construct assumes that the set of
   resources that form the TE link could be partitioned into disjoint
   subsets, such that (a) the partition is minimal, and (b) within each
   subset a label is sufficient to unambiguously identify the
   appropriate resources used by an LSP. We refer to such subsets as
   "component links", and to the whole TE link as a "bundled link".
   Furthermore we restrict the identifiers that can be used to identify
   component links such that they are unique for a given node.  On a
   bundled link a combination of <component link identifier, label> is
   sufficient to unambiguously identify the appropriate resources used
   by an LSP.

   The partition of resources that form a bundled link into component
   links has to be done consistently at both ends of the bundled link.
   Both ends of the bundled link also have to understand each others
   component link identifiers.

   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

Kompella, K., Rekhter, Y., Berger, L.                           [Page 3]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

   information. To limit the amount of losses one need to restrict the
   type of the information that can be aggregated/abstracted.

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

   Component link identifiers MUST be unique across both TE and
   component link identifiers on a particular node.  This means that
   unnumbered identifiers have node wide scope, and that numbered
   identifiers have the same scope as IP addresses.

4.2. Routing Considerations

   A component link may be either numbered or unnumbered. A bundled link
   may itself be numbered or unnumbered independent of whether the
   component links of that bundled link are numbered or not.

   Handling identifiers for unnumbered component links, including the
   case where a link is formed by a Forwarding Adjacency, follows the
   same rules as for an unnumbered TE link (see Section "Link
   Identifiers" of [RFC3477]/[RFC3480]). Furthermore, link local
   identifiers for all unnumbered links of a given LSR (whether
   component links, Forwarding Adjacencies or bundled links) MUST be
   unique in the context of that LSR.

   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 (see [LMP]), or from layer 1 or layer 2
   indications.

Kompella, K., Rekhter, Y., Berger, L.                           [Page 4]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

   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. Procedures for doing
   this are outside the scope of this document.

   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.3. Signaling Considerations

   Typically, an LSP's ERO will identify the bundled link to be used for
   the LSP, but not the component link, since information about the
   bundled link is flooded, but information about the component links is
   not.  The identification of a component link in an ERO is outside the
   scope of this document.  When the bundled link is identified in an
   ERO or is dynamically identified, the choice of the component link
   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
   [RFC3471], the sender chooses a component link in each direction).
   The handling of labels is not modified by this document.

   Component link identifiers are carried in RSVP messages as described
   in section 8 of [RFC3473]. Component link identifiers are carried in
   CR-LDP messages as described in section 8 of [RFC3473].  Additional
   processing related to unnumbered links is described in the
   "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" and
   "Unnumbered Forwarding Adjacencies" sections of [RFC3477]/[RFC3480].

   [RFC3471] defines the Interface Identification TLV types. This
   document specifies that the TLV types 1, 2 and 3 SHOULD be used to
   indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs.
   Type 1 TLVs are used for IPv4 numbered component link identifiers.
   Type 2 TLVs are used for IPv6 numbered component link identifiers.
   Type 3 TLVs are used for unnumbered component link identifiers.  The
   Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
   Note, in Path and REQUEST messages, link identifiers MUST be
   specified from the sender's perspective.

   Except in the special case noted below, for a unidirectional LSP,
   only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
   TLV.  This TLV indicates the component link identifier of the

Kompella, K., Rekhter, Y., Berger, L.                           [Page 5]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

   downstream data channel on which label allocation must be done.

   Except in the special case noted below, for a bidirectional LSP, only
   one or two TLVs SHOULD used in an IF_ID RSVP_HOP object or IF_ID TLV.
   The first TLV always indicates the component link identifier of the
   downstream data channel on which label allocation must be done.  When
   present, the second TLV always indicates the component link
   identifier of the upstream data channel on which label allocation
   must be done.  When only one TLV is present, it indicates the
   component link identifier for both downstream and upstream data
   channels.

   In the special case where the same label is to be valid across all
   component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or
   IF_ID TLV.  The first TLV indicates the TE link identifier of the
   bundle on which label allocation must be done.  The second TLV
   indicates a bundle scope label.  For TLV types 1 and 2 this is done
   by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for
   a type 1 TLV.  Per [RFC3471], for TLV types 3, 4 and 5, this is done
   by setting the Interface ID field to the special value 0xFFFFFFFF.
   Note that this special case applies to both unidirectional and
   bidirectional LSPs.

   Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
   the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.

4.3.1. Interface Identification TLV Format

   This section modifies section 9.1.1. of [RFC3471].  The definition of
   the IP Address field of the TLV types 3, 4 and 5 is clarified.

      For types 3, 4 and 5 the Value field has the identical format as
      the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object
      defined in [RFC3477].  Note this results in the renaming of the IP
      Address field defined in [RFC3471].

4.3.2. Errored Component Identification

   When Interface Identification TLVs are used, the TLVs are also used
   to indicate the specific components associated with an error.  For
   RSVP, this means that any received TLVs SHOULD be copied into the
   IF_ID ERROR_SPEC object, see Section 8.2 in [RFC3473].  The Error
   Node Address field of the object SHOULD indicate the TE Link
   associated with the error.  For CR-LDP, this means that any received
   TLVs SHOULD be copied into the IF_ID Status TLV, see Section 8.2 in
   [RFC3472].  The HOP Address field of the TLV SHOULD indicate the TE

Kompella, K., Rekhter, Y., Berger, L.                           [Page 6]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

   Link associated with the error.

5. 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 [RFC3784] and
   [RFC3630]; we use the terminology from [RFC3630].

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

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

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

5.4. Local and Remote Identifiers

   If the bundled link is unnumbered, the link local identifier is set
   to the identifier chosen for the bundle by the advertising LSR.  The
   link remote identifier is set to the 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 7]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

5.5. Traffic Engineering Metric

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

5.6. Maximum Bandwidth

   This parameter is not used. The maximum LSP Bandwidth (as described
   below) replaces the Maximum Bandwidth for bundled links.

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

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

5.9. Resource Classes (Administrative Groups)

   The Resource Classes for a bundled link are the same as those of the
   component links.

5.10. Maximum LSP Bandwidth

   The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
   For an unbundled link the Maximum Bandwidth is defined in
   [GMPLS-ROUTING]. 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 all of its component links.

   The details of how Maximum LSP 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].

Kompella, K., Rekhter, Y., Berger, L.                           [Page 8]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

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

7. Security Considerations

   This document defines ways of utilizing procedures defined in other
   documents referenced herein.  Any security issues related to those
   procedures are addressed in the referenced drafts.  This document
   thus raises no new security issues for RSVP-TE [RFC3209] or CR-LDP
   [RFC3212].

8. IANA Considerations

   This document changes the recommended usage of two of the
   Interface_ID Types defined in [RFC3471].  For this reason, the IANA
   registry of GMPLS Signaling Parameters should be updated for those
   types to read:

   4      12  See below   COMPONENT_IF_DOWNSTREAM - Deprecated  [BUNDLE]
   5      12  See below   COMPONENT_IF_UPSTREAM   - Deprecated  [BUNDLE]

Kompella, K., Rekhter, Y., Berger, L.                           [Page 9]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

9. References

9.1. Normative References

   [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
   Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
   extensions-19.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-12.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-09.txt (work in progress)

   [RFC3471] Berger, L., et al., "Generalized Multi-Protocol Label
   Switching (GMPLS) Signaling Functional Description",  RFC 3471,
   January 2003.

   [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
   Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
   Engineering (RSVP-TE) Extensions.", RFC 3473, January 2003.

   [RFC3472] Ashwood, P., Berger, L., et al., "Generalized Multi-
   Protocol Label Switching (GMPLS) Signaling Constraint-based Routed
   Label Distribution Protocol (CR-LDP) Extensions.", RFC 3472,January
   2003.

   [RFC3784] Smit, H., Li, T., "Intermediate System to Intermediate
   System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
   June 2004.

   [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Engineering
   (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

   [RFC3480] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
   Unnumbered Links in CR-LDP", RFC 3480, February 2003.

   [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in
   RSVP-TE", RFC 3477, January 2003.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3209] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
   V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
   RFC3209, December 2001

Kompella, K., Rekhter, Y., Berger, L.                          [Page 10]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

   [RFC3212] Jamoussi, B., editor, "Constraint-Based LSP Setup using
   LDP", RFC3212, December 2001

9.2. Non-normative References

   [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
   draft-ietf-ccamp-lmp-10.txt (work in progress)

10. 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 703-847-1801
   Email: lberger@movaz.com

11. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Kompella, K., Rekhter, Y., Berger, L.                          [Page 11]
Internet Draft        draft-ietf-mpls-bundle-06.txt        December 2004

12. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Kompella, K., Rekhter, Y., Berger, L.                          [Page 12]
Generated on: Mon Dec 20 11:40:16 2004