Internet Draft Kireeti Kompella Updates: 3471 Juniper Networks Category: Standards Track Yakov Rekhter Expiration Date: April 2005 Juniper Networks Lou Berger Movaz Networks October 2004 Link Bundling in MPLS Traffic Engineering draft-ietf-mpls-bundle-05.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 Kompella, K., Rekhter, Y., Berger, L. [Page 1] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 2. Abstract For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling in certain cases a combination of 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 [RFC3471]. 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 is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, a combination of 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 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 have node scope. On a bundled link a combination of is sufficient to unambiguously identify the appropriate resources used by an LSP. Kompella, K., Rekhter, Y., Berger, L. [Page 2] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 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 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 have node wide scope and MUST be unique across both TE and component link identifiers. 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. Kompella, K., Rekhter, Y., Berger, L. [Page 3] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 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. 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. With RSVP the choice of the component link is indicated by the sender of the Path message by including the IF_ID RSVP_HOP object in the Path message, as described in section 8 of [RFC3473]. With CR-LDP the choice of the component link is indicated by the sender of the REQUEST message by including the IF_ID TLV in the REQUEST message, as described in section 8 of [RFC3472]. With RSVP the choice of the component link is indicated by the sender of the Path message by including the IF_ID RSVP_HOP object in the Path message, as described in section 8 of [RFC3473]. With CR-LDP the choice of the component link is indicated by the sender of the REQUEST message by including the IF_ID TLV in the REQUEST message, as Kompella, K., Rekhter, Y., Berger, L. [Page 4] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 described in section 8 of [RFC3472]. 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 links identifier. Type 3 TLVs are used for unnumbered component link identifiers. The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used. 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 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 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. Kompella, K., Rekhter, Y., Berger, L. [Page 5] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 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]. 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. Kompella, K., Rekhter, Y., Berger, L. [Page 6] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 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. 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 link s. Kompella, K., Rekhter, Y., Berger, L. [Page 7] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 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]. 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. Kompella, K., Rekhter, Y., Berger, L. [Page 8] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 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. References 8.1. Normative References [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-ibis-gmpls- extensions-11.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-04.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. in progress) Kompella, K., Rekhter, Y., Berger, L. [Page 9] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 [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 [RFC3212] Jamoussi, B., editor, "Constraint-Based LSP Setup using LDP", RFC3212, December 2001 8.2. Non-normative References [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", draft-ietf-ccamp-lmp-10.txt (work in progress) 9. 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 Kompella, K., Rekhter, Y., Berger, L. [Page 10] Internet Draft draft-ietf-mpls-bundle-05.txt October 2004 10. 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. 11. 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 11]