Siva Sivabalan Francois Le Faucheur Cisco Systems, Inc. Raymond Zhang Infonet Services Corporation IETF Internet Draft Expires: December, 2003 Document: draft-sivabalan-diff-te-bundling-02.txt June, 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 June 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, and Zhang 2 Link Bundling Support for DS-TE June 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 [DSTE-PROTO] specifies that the existing Maximum Reservable Bandwidth parameter for a link is retained but its semantic is generalized and interpreted as the aggregate bandwidth constraints across all Class Types, independently of the Bandwidth Constraint Model in use (see [DSTE-REQ] for definition and examples of Bandwidth Constraints Model). Thus, for DS-TE over bundle link, the Maximum Reservable Bandwidth for the bundled link in [BUNDLE] is also retained and its semantic is also generalized and interpreted as the aggregate bandwidth constraints across all Class Types over bundled link, independently of the bandwidth constraint model in use. 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. Sivabalan, Le Faucheur, and Zhang 3 Link Bundling Support for DS-TE June 2003 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 (in addition to the "Maximum Reservable Bandwidth" sub-TLV). 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 For a simple (unbundled) link its Maximum LSP Bandwidth at priority p is defined to be the smaller of its unreserved bandwidth at priority p and a locally configured parameter which we call "Maximum LSP Size". The default value of Maximum LSP Size is equal to the Max Link Bandwidth. Maximum LSP Size is not advertised separately because it is factored into the advertised Maximum LSP Bandwidth. This parameter may exist merely to enforce an upper bound on the amount of bandwidth available to a single LSP over a link. [Editor's notes: we are in discussion with the [GMPLS-ROUTE] authors in order to update the current Maximum LSP Bandwidth definition in [GMPLS-ROUTE]in alignment with the text of the previous paragraph. We hope to get a resolution at the upcoming IETF meeting]. [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 computable 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 smaller of the Unreserved Bandwidth for TE class i and the Maximum LSP Size applicable to TE-class i on that component link. The method of enforcing Maximum LSP Size for a component link for a given TE-class is a matter of local policy. Sivabalan, Le Faucheur, and Zhang 4 Link Bundling Support for DS-TE June 2003 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 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. Normative 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-07.txt, work in progress. [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- proto-04.txt, June 2003. Sivabalan, Le Faucheur, and Zhang 5 Link Bundling Support for DS-TE June 2003 [GMPLS-ROUTE] Kompella et al, Routing Extensions in Support of Generalized MPLS, draft-ietf-ccamp-gmpls-routing-05.txt, work in progress. [GMPLS-ISIS] Kompella et al, IS-IS Extensions in Support of Generalized MPLS, draft-ietf-isis-gmpls-extensions-16.txt, work in progress. [GMPLS-OSPF] Kompella et al, OSPF Extensions in Support of Generalized MPLS, draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, work in progress. 7. Informative References [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraint Model for DS-TE, draft-ietf-tewg-diff-te-russian-03.txt, June 2003. [DSTE-MAM] Le Faucheur et al, Maximum Allocation Bandwidth Constraint Model for DS-TE, draft-ietf-tewg-diff-te-mam-01.txt, June 2003. 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, and Zhang 6