Siva Sivabalan Francois Le Faucheur Cisco Systems, Inc. Raymond Zhang Infonet Services Corporation IETF Internet Draft Expires: September, 2003 Document: draft-sivabalan-diff-te-bundling-01.txt March, 2003 Link Bundling support for Diff-Serv aware Traffic Engineering 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. Abstract This document describes how bandwidth-related MPLS Traffic Engineering parameters need to be advertised for a bundled link in order to support Diff-Serv aware Traffic Engineering. Summary for Sub-IP related Internet Drafts RELATED DOCUMENTS: See references. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the TEWG. Link Bundling Support for DS-TE March 2003 WHY IS IT TARGETED AT THIS WG(s) TEWG is responsible for specifying protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering. JUSTIFICATION The TEWG charter states that "This will entail verification and review of the Diffserv requirements in the WG Framework document and initial specification of how these requirements can be met through use and potentially expansion of existing protocols." In line with this, the TEWG is progressing a Working Group document specifying protocol extensions for Diff-Serv-aware MPLS Traffic Engineering. This ID discusses how these protocol extensions need to be used in the particular case of bundled links, which are not currently covered by the Working Group document. 1. Introduction As defined in [BUNDLE], a Traffic Engineering (TE) link bundle is a logical entity that represents a group of physical and/or logical TE links connecting Label Switching Routers (LSRs). The TE links making up a TE bundle link are called component links. As with ordinary TE links, TE parameters associated with a bundled TE link are advertised (e.g., via OSPF) to allow Constraint Based Routing. However, TE parameters for individual component links are not flooded. As such, an LSR that is not directly attached to a bundled link views that bundled link as a single link for path computation purpose. As stated in [DSTE-REQ] and [DSTE-PROTO], Diff-Serv Traffic Engineering (DS-TE) provides the capability to engineer network traffic on a per "class" basis instead of on an aggregate basis. With DS-TE, CSPF and admission control are done on a per class basis instead of on an aggregate basis as with ordinary TE. Consequently, DS-TE requires that certain bandwidth parameters are advertised on a per class basis. [DSTE-PROTO] specifies how those TE parameters are advertised on a per class basis on non-bundled links. [BUNDLE] specifies how to derive TE parameters for a bundled link from those of its component links. Currently, [BUNDLE] assumes that traffic engineering is performed on an aggregate basis only. This document captures the relevant enhancements to [BUNDLE] so that the necessary TE parameters are advertised on a per-class basis for a TE link bundle. This allows DS-TE to be supported over bundled links. Sivabalan, Le Faucheur, Zhang 2 Link Bundling Support for DS-TE March 2003 2. Terminology For readability a number of definitions from [DSTE-REQ] are repeated here: Class-Type (CT): the set of Traffic Trunks crossing a link that is governed by a specific set of Bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constraint based routing and admission control. A given Traffic Trunk belongs to the same CT on all links. TE-Class: A pair of: i. a Class-Type ii. a preemption priority allowed for that Class-Type. This means that an LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the set-up priority, as the holding priority or both. 3. Bandwidth-related TE parameters In this section we refine the definitions provided in [BUNDLE] for bandwidth-related TE parameters that are advertised for bundled links, in order to support DS-TE on these bundled links. 3.1. Bandwidth Constraints DS-TE provides support for up to 8 Bandwidth Constraints. Those are referred to as BC0, BC1, ..., BC7. For a bundle link, the value of BCi (7 >= i >= 0) can be configured either separately for each of the component links or for the whole bundle link. In the former case, the value of BCi for the bundle equals to the sum of the BCi value for each of the component link. The set of Bandwidth Constraints applicable to a particular TE-Class depends on the Bandwidth Constraints Model in use on the link (see [DSTE-REQ] for definition and examples of Bandwidth Constraints Model) The existing "Maximum Reservable Bandwidth" parameter for the bundled link is retained but its semantic is generalized and interpreted as BC0. The values of BCi for the bundled link MAY be advertised. When advertised for a bundled link, they MUST be advertised as specified in [DSTE-PROTO]. In particular: - a DS-TE LSR which does advertise Bandwidth Constraints MUST use the new "Bandwidth Constraints" sub-TLV to do so. - a DS-TE LSR which does advertise Bandwidth Constraints, MAY also include the existing "Maximum Reservable Bandwidth" sub-TLV. Sivabalan, Le Faucheur, Zhang 3 Link Bundling Support for DS-TE March 2003 3.2. Unreserved Bandwidth for TE-class DS-TE requires that unreserved bandwidth be advertised on a per TE- class basis. Unreserved Bandwidth of a bundle link for a given TE-class i (where 7 >= i >= 0) is the sum of the Unreserved Bandwidth for that TE-class on all the associated component links. The Unreserved Bandwidth for every active TE-class MUST be advertised for a bundled link as specified in [DSTE-PROTO] using the Unreserved Bandwidth sub-TLV (with a generalized definition). 3.3. Maximum LSP Bandwidth Maximum LSP Bandwidth for priority p for unbundled link is defined in [GMPLS-ROUTE] as the smaller of Maximum Reservable Bandwidth and the unreserved bandwidth for priority p. [BUNDLE] defines Maximum LSP Bandwidth for a bundled link on a per priority basis. It is assumed that Maximum LSP Bandwidth value is available for each component link, and the Maximum LSP Bandwidth for a bundle is defined as the Maximum of Maximum LSP Bandwidth among all component links. For supporting DS-TE, Maximum LSP Bandwidth must be defined on a per TE-class basis. Extending the above definitions, we define Maximum LSP Bandwidth for TE class i (where 7 >= i >= 0) for a component link as the minimum of the Unreserved Bandwidth for TE class i and the BC applicable to the TE-class I over that component link. [Maximum Reservable Bandwidth is less than or equal to unreserved bandwidth for any priority p. Thus, we believe that Maximum LSP Bandwidth at priority p should be equal to Unreserved Bandwidth for priority p, in the absence of any other per-LSP limit. If there is a user specified per-LSP bandwidth limit L for priority p, then the Maximum LSP Bandwidth at priority p is the minimum of Unreserved Bandwidth at priority p and the specified limit L. This needs to be clarified with the authors of [GMPLS-ROUTE], and the above definition for Maximum LSP Bandwidth for component link for DS-TE will be modified, if needed.] The Maximum LSP Bandwidth for an active TE-class i (where 7 >=i >=0) on a bundled link is the maximum of the Maximum LSP Bandwidth for the TE-class i across all of the associated component links. [GMPLS-ISIS] and [GMPLS-OSPF] currently specify how the Maximum LSP Bandwidth for each of the 8 preemption priorities are advertised, respectively in ISIS and OSPF, inside the Interface Switching Capability Descriptor sub-TLV. For support of DS-TE, each of the "Maximum LSP bandwidth at preemption i" field (7 >= i >= 0) in that Sivabalan, Le Faucheur, Zhang 4 Link Bundling Support for DS-TE March 2003 sub-TLV has its semantic generalized into the "Maximum LSP Bandwidth for TE-class i". This generalization MAY be used for advertising the Maximum LSP Bandwidth for each TE-class both on simple (unbundled) links and on bundled links. Note that when DS-TE is not used, the 8 TE-classes revert to the 8 preemption priorities (of the single bandwidth constraint) so that the generalized definition above reverts to the one currently defined in [GMPLS-ISIS] and [GMPLS-OSPF]. 4. Bandwidth Accounting An LSP belonging to TE-class i (where 7 >= i >= 0) with a bandwidth requirement b fits in a bundled link if at least one component link has its Maximum LSP bandwidth for TE-class i >= b. 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 for each TE-class on each component link, the unreserved bandwidth for each TE-class must be tracked on each component link. 5. Security Considerations No new security considerations are raised by this document. Those are the same as the ones discussed in [DSTE-REQ] and in [BUNDLE]. 6. References [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in progress) [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-06.txt, September 2002. [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- proto-02.txt, October 2002. [GMPLS-ROUTE] Kompella et al, Routing Extensions in Support of Generalized MPLS, draft-ietf-ccamp-gmpls-routing-05.txt, August 2002. [GMPLS-ISIS] Kompella et al, IS-IS Extensions in Support of Generalized MPLS, draft-ietf-isis-gmpls-extensions-16.txt, August 2002. Sivabalan, Le Faucheur, Zhang 5 Link Bundling Support for DS-TE March 2003 [GMPLS-OSPF] Kompella et al, OSPF Extensions in Support of Generalized MPLS, draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, August 2002. Authors' Address: Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada msiva@cisco.com Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France Email: flefauch@cisco.com Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: raymond_zhang@infonet.com Sivabalan, Le Faucheur, Zhang 6