RFC 4201

Link Bundling in MPLS Traffic Engineering (TE)

📅 published October 2005, from ietf

Part 1 of 3 🧚

Network Working Group, Request for Comments 4201, October 2005. Okay so the authors are K. Kompella and Y. Rekhter from Juniper Networks, plus L. Berger from Movaz Networks 🫶. It's a Standards Track doc, and it updates RFCs 3471, 3472 and 3473 🔥.

Status of This Memo ✨

This is an Internet standards track protocol spec for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2005).

Abstract 🌸

Okay so for Generalized Multi-Protocol Label Switching (GMPLS) signaling, sometimes a <link identifier, label> combo just isn't enough to pin down the exact resource an LSP is using 😭. That's where link bundling comes in, and this doc explains how it works 🧠. This doc also updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description 💖.

Table of Contents 🧾

1.  Introduction .................................................  2
    1.1.  Specification of Requirements ..........................  2
2.  Link Bundling ................................................  3
    2.1.  Restrictions on Bundling ...............................  4
    2.2.  Routing Considerations .................................  4
    2.3.  Signaling Considerations ...............................  5
          2.3.1.  Interface Identification TLV Format ............  6
          2.3.2.  Errored Component Identification ...............  7
3.  Traffic Engineering Parameters for Bundled Links .............  7
    3.1.  OSPF Link Type .........................................  7
    3.2.  OSPF Link ID ...........................................  7
    3.3.  Local and Remote Interface IP Address ..................  7
    3.4.  Local and Remote Identifiers ...........................  8
    3.5.  Traffic Engineering Metric .............................  8
    3.6.  Maximum Bandwidth ......................................  8
    3.7.  Maximum Reservable Bandwidth ...........................  8
    3.8.  Unreserved Bandwidth ...................................  8
    3.9.  Resource Classes (Administrative Groups) ...............  8
    3.10.  Maximum LSP Bandwidth .................................  8
4.  Bandwidth Accounting .........................................  9
5.  Security Considerations ......................................  9
6.  IANA Considerations ..........................................  9
7.  References ................................................... 10
    7.1.  Normative References ................................... 10
    7.2.  Informative References ................................. 11

1. Introduction ✨

Okay bestie, this is the intro, and it's giving the same vibe as the abstract 💜. For GMPLS signaling, a <link identifier, label> combo isn't always enough to unambiguously identify the right resource an LSP uses 👀. Link bundling is the construct that handles those cases, and it's described in this document 🎀. This doc updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description 🦋.

1.1. 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] 💅.

As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a logical construct 🧩. It's a way to group and map info about certain physical resources (and their properties) that interconnect LSRs with info used by Constrained SPF (for path computation) and by GMPLS signaling 🌈.

Now here's the tea 🍵. As stated in [GMPLS-ROUTING], depending on what resources make up a particular TE link for GMPLS signaling, a <TE link identifier, label> combo is sometimes enough to pinpoint the resource an LSP uses. Other times it isn't 😭. Picture a TE link between a pair of SONET/SDH cross-connects, where the TE link is made of several fibers. The label is a TDM time slot, and that time slot only means something inside one specific fiber 🤯. So when you signal an LSP over that kind of TE link, you need more than just the link's identity. You also need the specific fiber inside that TE link, plus the specific label (time slot) inside that fiber 🍓. That's the situation link bundling is built for, and this document describes how it works 🔥.

Let's say you've got a TE link where <TE link identifier, label> isn't enough to unambiguously identify the resources an LSP uses 🙈. Link bundling assumes the resources in that TE link can be split into disjoint subsets. Those subsets have to follow two rules: (a) the split is minimal, and (b) inside each subset, a label is enough to unambiguously identify the resources an LSP uses ✨. We call those subsets "component links," and we call the whole TE link a "bundled link" 🎀. We also restrict the identifiers used for component links so they're unique for a given node 💖. On a bundled link, a <component link identifier, label> combo is enough to unambiguously identify the resources an LSP uses 👑.

The split of resources into component links has to be done consistently at both ends of the bundled link 🫶. Both ends also have to understand each other's component link identifiers 🧚.

The whole point of link bundling is to improve routing scalability by cutting down the amount of info that OSPF and/or IS-IS have to handle 📉. It does this with information aggregation/abstraction 🧠. But like any aggregation/abstraction, you lose some info along the way 😭. To keep those losses small, you have to limit what kind of info can be aggregated/abstracted 💅.

2.1. Restrictions on Bundling 🚧

All component links in a bundle 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. They must also begin and end on the same pair of LSRs 💕.

A Forwarding Adjacency may be a component link 🦋. In fact, a bundle can be a mix of point-to-point links and FAs 🌸.

If the component links are all multi-access links, then the set of IS-IS or OSPF routers connected to each component link must be the same. The Designated Router for each component link must also be the same 🧠. If these conditions can't 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 🔥. In other words, unnumbered identifiers have a node-wide scope, and numbered identifiers have the same scope as IP addresses 🌈.

2.2. Routing Considerations 🛣️

A component link can be numbered or unnumbered 🎀. A bundled link can be numbered or unnumbered too, and that's independent of whether its component links are numbered 🫶.

Handling identifiers for unnumbered component links follows the same rules as for an unnumbered TE link. That includes the case where a link is formed by a Forwarding Adjacency. See Section "Link Identifiers" of [RFC3477]/[RFC3480] 📖. On top of that, 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 a bundled link comes from the liveness of its component links 💖. A bundled link is alive when at least one of its component links is determined to be alive 🌟. A component link's liveness can be determined by several means: IS-IS or OSPF hellos over the component link, RSVP Hello, LMP hellos (see [LMP]), or layer 1 or layer 2 indications 🧚.

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 run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links 🤫. The 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 of how they can be bundled, plus any possible restrictions on bundling 🔮.

2.3. Signaling Considerations 💅

okay so, the info about the bundled link gets flooded around, but the info about the component links doesn't. So usually an LSP's ERO will name the bundled link it's using, but not the component link 🦋 Figuring out which component link identities go in an ERO is outside the scope of this doc, but it's envisioned that the info could come from configuration or from future RRO extensions ✨ When the bundled link is in an ERO or gets identified dynamically, picking 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 and the label to use 👑 The sender of the Path/REQUEST message is always the one who picks the component link 💖 If an LSP is bidirectional [RFC3471], the sender picks 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 type-length-value (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 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 be 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 be 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. 🙈

2.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 an identical format to the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. Note that this results in the renaming of the IP Address field defined in [RFC3471].

2.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 Link associated with the error 💀

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] 📚

The Link Type of a bundled link is the (unique) Link Type of the component links. Note that this parameter is not present in IS-IS.

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 that this parameter is not present in IS-IS.

3.3. Local and Remote Interface IP Address

Note that in IS-IS, the Local Interface IP Address is known as the IPv4 Interface Address and the Remote Interface IP Address is known as the IPv4 Neighbor Address 🫶

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.

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

3.5. Traffic Engineering Metric

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

3.6. Maximum Bandwidth

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

3.7. Maximum Reservable Bandwidth

For a given bundled link, we assume that 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 🌸

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

3.9. Resource Classes (Administrative Groups)

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

3.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] 🧚

4. 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 a maximum LSP bandwidth >= b at priority p. If there are several such links, the implementation will choose which link to use for the LSP 💖

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 😭

5. 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 documents. Thus, this document raises no new security issues for RSVP-TE [RFC3209] or CR-LDP [RFC3212] 🛡️

6. 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 has been updated to read:

4      12      COMPONENT_IF_DOWNSTREAM - DEPRECATED
5      12      COMPONENT_IF_UPSTREAM   - DEPRECATED

7. References 📖

7.1. Normative References 📚

okay so these are the docs the spec literally can't function without, bestie 🫶

  • [GMPLS-ISIS] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
  • [GMPLS-OSPF] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
  • [GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
  • [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
  • [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
  • [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
  • [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
  • [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
  • [RFC3480] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
  • [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (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., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
  • [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.

7.2. Informative References 🦋

just one extra read if you're curious 👀

  • [LMP] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.

Authors' Addresses 🎀

meet the squad who wrote this 💜

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.

Phone: +1 703-847-1801
EMail: lberger@movaz.com

the legal bit, but make it cute 🙈

Copyright (C) The Internet Society (2005).

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.

Intellectual Property 🔥

okay so the IETF is not picking a side on who owns what 💅 It takes no position on whether any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document are valid or in scope, or whether any license under those rights might be available. It also doesn't claim to have independently searched for any such rights.

Info on how RFC rights work is in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, or the outcome of an attempt to get a general license or permission for implementers or users to use the proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org 🫶

Acknowledgement 🌈

shoutout to whoever keeps the lights on 🧚 Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from