Internet Draft Network Working Group Kireeti Kompella Internet Draft Juniper Networks Expiration Date: August 2000 Yakov Rekhter Cisco Systems Link Bundling in MPLS Traffic Engineering draft-kompella-mpls-bundle-00.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 LSRs may be connected by several (parallel) links. From the MPLS Traffic Engineering point of view for the purpose of scalability it may be desirable to treat all these links as a single IP link. This document describes how to accomplish this. Kompella, K., Rekhter, Y. [Page 1] Internet Draft draft-kompella-mpls-bundle-00.txt Februrary 2000 3. Unnumbered links as a bundle 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/ISIS. We refer to this process as "link bundling", or just "bundling". We refer to the link that is advertised into OSPF/ISIS as a "bundled link". We refer to the links associated with that bundled link as "component links". Component links are expected to be unnumbered. A bundled link could be either unnumbered or numbered with IP addresses assigned to some "virtual" interfaces on a router (it is assumed that a router may have multiple virtual interfaces). 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 over the the maximum reservable bandwidth for all the component links associated with the bundled link. The maximum LSP bandwidth (as described below) replaces the maximum link bandwidth for bundled links. We assume that for a given bundled link either each of its component links is configured with the maximum LSP bandwidth per priority, or the bundled link is configured with the maximum LSP bandwidth per priority. In the former case the maximum LSP bandwidth for a given priority of the bundled link is set to the maximum over maximum LSP bandwidth for that priority for all the component links associated with the bundled link. By default the unreserved bandwidth of a bundled link is set to the sum of all the unreserved bandwidths on all the component links associated with the bundled link. RSVP must track the unreserved bandwidth on each individual component link. If one of the component links goes down, that results in changing the unreserved bandwidth of the associated bundled link, provided that at least one other component link associated with the bundled link is up. When all the component links associated with a given bundled link are down, the bundled link should not be advertised into OSPF/ISIS. This document assumes that the label returned in the Label Object of Kompella, K., Rekhter, Y. [Page 2] Internet Draft draft-kompella-mpls-bundle-00.txt Februrary 2000 the Resv message is associated with the interface over which the corresponding Path message is received. Therefore, this document assumes that for a given bundled link connected to an LSR, the LSR should be able to send the Path message over any of the component links associated with the bundled link. Procedures that would allow the label returned in the Label Object of the Resv message to be associated with the interface different from the one over which the corresponding Path message is received are outside the scope of this document. That is, handling the case where an LSR may not be able to send the Path message over some of the component links, while still being able to place LSPs over these links is outside the scope of this document. 4. Maximum LSP bandwidth TLV The bandwidth allocated to a single LSP is limited (from above) by the physical capacity of the links traversed by the LSP, as well as other (already existing) LSPs that traverse the links. This value is determined based on the physical link bandwidth, ignoring any oversubscription factor. Maximum LSP bandwidth is carried on a per priority level. This allows to control the maximum amount of bandwidth that an LSP with a given priority could allocate. On a bundled link, the maximum LSP bandwidth for a given priority is set to the maximum of the maximum LSP bandwidth for that priority over all the component links associated with the bundled link. In ISIS, this 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, with type 11. The Maximum bandwidth LSP sub-TLV is a list of two-tuples, of which the first field is a 4 octet field, and the second is a one octet field. The first field in a tuple encodes the maximum bandwidth in units of bytes (not bits) per second as an IEEE floating point number. The second field in the tuple encodes the value of the lowest holding priority that an LSP has to have in order to reserve up to the maximum bandwidth specified in the first field. The difference between maximum LSP bandwidth and unreserved bandwidth is that the former is computed based on the actual link bandwidth, while the latter may reflect oversubscription. This sub-TLV is expected to supersede the maximum link bandwidth Kompella, K., Rekhter, Y. [Page 3] Internet Draft draft-kompella-mpls-bundle-00.txt Februrary 2000 sub-TLV. 5. Acknowledgements 6. References [Smit] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-01.txt [Katz] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-01.txt 7. Author Information Kireeti Kompella Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 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. [Page 4]