Traffic Engineering Working Group Jerry Ash Internet Draft Wai Sum Lai Document: AT&T Labs Category: Experimental June 2003 Use of Overbooking in Diffserv-aware MPLS 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 presents a precise formulation and a functional description of overbooking methods used in DS-TE from the operational perspective of service providers. To minimize operational complexity, an integrated approach to overbooking is recommended. Conventions used in this document 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. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................2 2. Terminology.....................................................2 3. Overbooking in Aggregate TE.....................................3 4. Overbooking in DS-TE............................................4 Ash, Lai Category - Expiration [Page 1] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 5. Components-Based Approach.......................................4 6. An Integrated Approach..........................................6 7. Functional Equivalence..........................................6 APPENDIX I: Example Use of Per-Link Per-CT Overbooking.............7 APPENDIX II: Example 1.............................................8 APPENDIX III: Example 2...........................................10 8. Security Considerations........................................11 9. References.....................................................11 10. Contributing Authors..........................................12 11. Author's Address..............................................12 Full Copyright Statement..........................................12 1. Introduction Requirements for DS-TE and the associated protocol extensions are specified in references [1, 2], respectively. A requirement is the application of overbooking on LSPs for constraint-based routing and admission control. Use of overbooking is an integral part of current practice for aggregate TE in live deployments. However, overbooking methods have not been described in any details in existing TE documents. In DS- TE, with the use of bandwidth constraints for different Class-Types (CT), overbooking must be specified explicitly and consistently in the context of multiple CTs, for purposes of per-CT constraint-based routing and per-CT admission control. This document complements [1] by presenting a precise formulation and a functional description of overbooking methods in DS-TE from the *operational perspective* of service providers. As stated in [1], DS-TE is used "where fine-grained optimization of transmission resources is sought." In conjunction with bandwidth constraints models [3, 4, 5, 6], overbooking is a TE mechanism employed to support this requirement. In this document, based on operational complexity, we compare and analyze two approaches to overbooking: components-based and integrated. They are shown to be functionally equivalent. It is recommended that the integrated approach be used because of its simplicity. 2. Terminology For a given Class-Type CTc (0 <= c <= MaxCT-1): Requested(LSPc): service bandwidth requested before any adjustment for overbooking, for an LSPc belonging to CTc Tspec(LSPc): RSVP-TE Tspec bandwidth specified in TLV, for an LSPc belonging to CTc Ash, Lai Category - Expiration [Page 2] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 Reserved(LSPc): bandwidth reserved for an LSPc belonging to CTc For aggregate TE as in current operation, there are no Class-Types. In this case, the above terms become Requested(LSP), Tspec(LSP), and Reserved(LSP), respectively. Reserved(CTc): the sum of the bandwidth reserved by all established LSPs that belong to CTc. Notes: (1) It is assumed that, in current operation, Reserved(LSP) = Tspec(LSP). (2) Generally, Reserved(LSPc) <= Requested(LSPc). This is so that LSPs of a class that can be overbooked reserve less than what their corresponding service specifications explicitly call for. Therefore, enough LSPs of that class can be admitted until the capacity held for the expected carried load is reached. 3. Overbooking in Aggregate TE Two methods are in common use in existing TE: 1. Link Size Overbooking (per-link) method: apply overbooking by adjusting the Maximum Reservable Bandwidth of an individual link (this parameter may be set by default to the Maximum Link Bandwidth or may be configured by operator to some other value). 2. LSP Size Overbooking (per-LSP) method: apply overbooking by adjusting the size of an individual LSP. Let us define: LSOM = Link Size Overbooking multiplier LSPOM = LSP Size Overbooking multiplier Then, we have the following three application scenarios: 1. Link Size Overbooking only: Reserved(LSP) = Tspec(LSP) = Requested(LSP) Maximum Reservable Bandwidth = Maximum Link Bandwidth * LSOM 2. LSP Size Overbooking only: Reserved(LSP) = Tspec(LSP) = Requested(LSP) / LSPOM Maximum Reservable Bandwidth = Maximum Link Bandwidth 3. Both Link Size Overbooking and LSP Size Overbooking simultaneously: Reserved(LSP) = Tspec(LSP) = Requested(LSP) / LSPOM Maximum Reservable Bandwidth = Maximum Link Bandwidth * LSOM Since use of the above two overbooking methods does not result in any specific protocol extensions, the parameters LSOM and LSPOM are not signaled. That is, they are conceptual parameters that do not Ash, Lai Category - Expiration [Page 3] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 need to be defined in any standards or carried in any signaling protocols. However, since they (or their equivalent parameters) need to be configured, they are defined here for assessing the *operational complexity* of the methods. Also, they should be documented explicitly to avoid possible misinterpretation that may lead to operational errors. 4. Overbooking in DS-TE Since DS-TE is used if and only if the number of Class-Types is at least 2, the germane overbooking method in DS-TE should be on a per- CT basis. That is, to allow a different level of overbooking for different CTs. For example, service providers would typically use high overbooking on best-effort traffic, and low overbooking on premium data. There are two cases: @ Per-domain per-CT overbooking (i.e., applied on a network-wide basis) @ Per-link per-CT overbooking Per-domain per-CT overbooking can be achieved by extending the LSP size overbooking method of existing TE, i.e., by extending the granularity of per-LSP overbooking to per-CT for scalability. In conjunction with Link Size Overbooking, it is possible to adjust the per-CT overbooking on different links by the *same* proportion. This is because Link Size Overbooking effectively applies a single per-link overbooking that is common to all CTs. Per-link per-CT overbooking is a new capability in DS-TE. An example of its use is when a network has a mixture of links with different speeds. In this case, depending on the relative traffic size, per-CT overbooking may need to be *proportionally different*. This is because different CTs may see different scaling effects when link speeds change. (See Appendix I for an example.) As described above, DS-TE includes also the Link/LSP Size Overbooking methods. As these methods are directly inherited from existing TE, minimal modification should be made to them to maintain backward compatibility. However, where they are not used by a service provider, they should have *minimal impact* on the operational complexity of the per-CT overbooking methods in DS-TE. 5. Components-Based Approach One approach is to simply provide each of the above methods as an option and package them together, as commonly used in product development. This is the approach that was proposed during the initial development of the DS-TE protocol extensions document [2]. The result is: two mandatory components Ash, Lai Category - Expiration [Page 4] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 . Link Size Overbooking . LSP Size Overbooking one optional component . Local Overbooking Multiplier (LOM) A new set of quantities is also introduced to factor in both the Link/LSP Size Overbooking and the optional LOM method: Normalised(LSPc) = Reserved(LSPc)/LOM(CTc), Normalised(CTc) = Reserved(CTc)/LOM(CTc), where LOM(CTc) is the Local Overbooking Multiplier for an LSPc belonging to CTc. By structuring the LOM method as an optional component over existing components, as well as the use of the new "Normalized" quantities, two sets of formulas are needed: with and without LOM. As in the case of aggregate TE, let us define: LSOM = Link Size Overbooking multiplier (unsignaled) LSPOM(CTc) = LSP Size Overbooking multiplier (unsignaled) LOM(CTc) = local overbooking multiplier (signaled) Here again, LSOM and LSPOM(CTc) are defined only for assessing the operational complexity of the components-based approach. Then, we have the following four application scenarios: 1. Link Size Overbooking only: Reserved(LSPc) = Tspec(LSPc) = Requested(LSPc) Maximum Reservable Bandwidth = Maximum Link Bandwidth * LSOM (Note that Link Size Overbooking does not enforce different overbooking ratios for different CTs.) 2. LSP Size Overbooking only: Reserved(LSPc) = Tspec(LSPc) = Requested(LSPc) / LSPOM(CTc) Maximum Reservable Bandwidth = Maximum Link Bandwidth 3. Both Link Size Overbooking and LSP Size Overbooking simultaneously: Reserved(LSPc) = Tspec(LSPc) = Requested(LSPc) / LSPOM(CTc) Maximum Reservable Bandwidth = Maximum Link Bandwidth * LSOM 4. LOM in conjunction with any of the above: Normalized(LSPc) = Reserved(LSPc) / LOM(CTc) = Tspec(LSPc) / LOM(CTc) where Reserved(CTc) = Tspec(LSPc) is as defined in cases 1 to 3 above. *Note that in case 4, the Reserved(LSPc) still equals Tspec(LSPc), but Normalized(LSPc) is not a physical quantity corresponding to reserved bandwidth, requested bandwidth, or Tspec bandwidth.* Ash, Lai Category - Expiration [Page 5] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 Because of the use of Normalized(LSPc), the aggregate constraints are also different, depending on whether LOM is used or not. The use of Maximum Reservable Bandwidth as an aggregate constraint tacitly assumes the use of Link Size Overbooking, which may or may not be the case. 6. An Integrated Approach From the operational perspective of service providers, an integrated approach is more desirable. To minimize operational complexity, a single set of formulas should be used in all application scenarios. This objective can be achieved by defining a single parameter: OB(CTc) = the overbooking factor for an LSPc belonging to CTc. Then, for either per-domain per-CT overbooking or per-link per-CT overbooking, we have Tspec(LSPc) = Requested(LSPc) Reserved(LSPc) = Tspec(LSPc) / OB(CTc) Maximum Reservable Bandwidth = Maximum Link Bandwidth *Note that the above reduction in Reserved(LSPc), i.e., by dividing the Tspec(LSPc) bandwidth by the OB(CTc) overbooking, is a change from current operation as assumed in Section 2.* OB(CTc) is signaled when per-link per-CT overbooking is used, otherwise it does not need to be signaled. The above integrated formulation results in the use of a single aggregate constraint: SUM (Reserved(CTc)) <= Maximum Reservable Bandwidth = Maximum Link Bandwidth for all "c" in the range 0 <= c <= (MaxCT-1) Observe that the per-link per-CT overbooking method basically applies a different level of overbooking to each CT on different links (e.g., higher overbooking on higher-speed links). Thus, the method itself already encompasses the capability of Link/LSP Size Overbooking, and there is no need to account for them separately. This leads to the feasibility of using only a single set of formulas in the integrated approach. Also note that Maximum Reservable Bandwidth is not really needed, but may be retained for backward compatibility. 7. Functional Equivalence To see how the integrated approach meets all the needs of the different scenarios, let us define Ash, Lai Category - Expiration [Page 6] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 OB(CTc) = LSOM * LSPOM(CTc) * LOM(CTc) We want to emphasize that we do not need this formula in operational context. It is solely used here to demonstrate that the integrated approach is functionally equivalent to the components-based approach. Referring to the four application scenarios in the components-based approach: 1. Link Size Overbooking only: LSPOM(CTc) = 1, LOM(CTc) = 1, for all c Reserved(LSPc) = Tspec(LSPc) / OB(CTc) = Requested(LSPc) / LSOM 2. LSP Size Overbooking only: LSOM = 1, LOM(CTc) = 1, for all c Reserved(LSPc) = Tspec(LSPc) / OB(CTc) = Requested(LSPc) / LSPOM(CTc) 3. Both Link Size Overbooking and LSP Size Overbooking simultaneously: LOM(CTc) = 1, for all c Reserved(LSPc) = Tspec(LSPc) / OB(CTc) = Requested(LSPc) / ( LSOM * LSPOM(CTc) ) 4. LOM in conjunction with any of the above: LSOM = 1, LSPOM(CTc) = 1, for all c Reserved(LSPc) = Tspec(LSPc) / OB(CTc) = Requested(LSPc) / LOM(CTc) Note that we no longer need the quantities Normalized(LSPc) and Normalized(CTc). Thus, with a more coherent and seamless integration, it is possible to provide an overall simplification of the rather complicated 3-way overbooking complexity in the components-based approach, while retaining full backward compatible with existing TE. By avoiding the use of different options, parameters [3 parameters (LSOM, LSPOM, LOM) versus 1 parameter (OB)], and formulas for different situations, operational complexity is reduced. This will also help to reduce operational errors such as misconfigurations. Also, note that since Link/LSP Size Overbooking is not needed in per-link per-CT overbooking, the requirement that existing TE overbooking should have minimal impact on DS-TE overbooking is fulfilled. APPENDIX I: Example Use of Per-Link Per-CT Overbooking Suppose link0 has 100 units (e.g., Mbps of link bandwidth), of which say 30 is allocated to CT0, and 70 to CT1. Similarly, link1 has 500 units, of which 150 is to CT0, and 350 to CT1. That is, with 30%/70% allocation for both links, the bandwidth constraints are in Ash, Lai Category - Expiration [Page 7] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 the same proportion for both. Then, in going from link0 to link1, CT0 sees an increase from 30 to 150, while CT1 sees an increase from 70 to 350. To get a feel for the change in per-CT overbooking needed for the two links, we do a back-of-the-envelope calculation at a very high level by using the simple Erlang formula, assuming 1% LSP blocking for both CT0 and CT1. (Obviously, this is very crude, without any consideration for sharing - but the idea is to see the scaling effect of link speeds, to be explained below.) 30 units support an offered load of 20.3 units (68% utilization) 150 units support an offered load of 131.6 units (88% utilization) 70 units support an offered load of 56.1 units (80% utilization) 350 units support an offered load of 326.2 units (93% utilization) With only 30 units in link0, CT0 has a much smaller overbooking to start with. Thus, CT0 should see a proportionally bigger increase in overbooking in link1, as the utilization increases by 20% from 68% to 88%. On the other hand, CT1 has 70 units in link0 and can work with a higher overbooking. Thus, CT1 should see a proportionally smaller increase in overbooking in link1, as the utilization increase is much smaller, by 13% from 80% to 93%. In summary, depending on the relative traffic size, per-CT overbooking may need to be proportionally different. This is because different CTs may see different scaling effects when link speeds change. To support application scenarios like this, the use of per-link per-CT is needed. APPENDIX II: Example 1 The proposed OB(CTc) would be configured by link, by CT, just as in the current proposal for LOM(CTc). However, OB(CTc) is meant to combine, functionally: LSPOMc = LSP overbooking multiplier for CTc LSOM = link size overbooking multiplier for a given link LOMc = local overbooking multiplier, per-link, per-CT adjustment factor in the components-based approach In the integrated approach, we define: OBc = LSPOMc * LSOM * LOMc Here is an example that compares today's method of overbooking (Case A) and the proposed method of overbooking (Case B): Take a link with: Ash, Lai Category - Expiration [Page 8] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 Max link bandwidth = 100 Max reservable bandwidth = 200 (That is, in today's parlance, LSOM = 200/100 = 2, the link bandwidth is overbooked by a factor of 2) BC0 = 50 BC1 = 150 LSPOB0 = 1 LSPOB1 = 4 (That is, in today's parlance, CT0 is not overbooked, CT1 is overbooked by a factor of 4) LOM0 = 1 LOM1 = 1 (That is, in today's parlance, no per-link/per-CT overbooking adjustment is made for either CT0 or CT1 using LOM) Suppose we have 2 LSPs set up over this link: LSP0 requested bandwidth = 30 LSP1 requested bandwidth = 80 Case A: today's way of applying overbooking factors: ---------------------------------------------------- Tspec(LSP0) = LSP0 requested bandwidth/LSPOB0 = 30/1 = 30 Tspec(LSP1) = LSP1 requested bandwidth/LSPOB1 = 80/4 = 20 Reserved(LSP0) = Tspec(LSP0) = 30 Reserved(LSP1) = Tspec(LSP1) = 20 Then Unreserved(CT0) = BC0 - Reserved(CT0) = 50 - 30 = 20 Unreserved(CT1) = BC1 - Reserved(CT1) = 150 - 20 = 130 These quantities are advertised. Case B: the proposed modified way of applying overbooking factors: ------------------------------------------------------------------ First we adjust the BC0 and BC1 by the LSOM for this link: BC0 = 50/2 = 25 BC1 = 150/2 = 75 (Note that the proposed method uses Max link bandwidth as the aggregate constraint) Then we determine the OB0 and OB1 factors: Ash, Lai Category - Expiration [Page 9] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 OB0 = LSPOB0 * LSOM * LOM0 = 1 * 2 * 1 = 2 OB1 = LSPOB1 * LSOM * LOM1 = 4 * 2 * 1 = 8 Tspec(LSP0) = LSP0 requested bandwidth = 30 Tspec(LSP1) = LSP1 requested bandwidth = 80 Reserved(LSP0) = Tspec(LSP0)/OB0 = 30/2 = 15 Reserved(LSP1) = Tspec(LSP1)/OB1 = 80/8 = 10 Then Unreserved(CT0) = BC0 - Reserved(CT0) = 25 - 15 = 10 Unreserved(CT1) = BC1 - Reserved(CT1) = 75 - 10 = 65 These quantities are advertised. APPENDIX III: Example 2 Example to compare LSPOM/LSOM/LOM method of overbooking (Case A) and the proposed integrated method of overbooking (Case B): Take a link with: Max link bandwidth = 100 Max reservable bandwidth = 200 (That is, in today's parlance, LSOM = 200/100 = 2, the link bandwidth is overbooked by a factor of 2) BC0 = 50 BC1 = 150 LOM0 = 1 LOM1 = 4 (That is, in today's parlance, CT0 is not overbooked, CT1 is overbooked by a factor of 4) LSPOB0 = 1 LSPOB1 = 4 (That is, in today's parlance, no LSP overbooking factor is used, instead the per-link/per-CT overbooking adjustment is made using LOM) Suppose we have 2 LSPs set up over this link: LSP0 requested bandwidth = 30 LSP1 requested bandwidth = 80 Case A: today's way of applying overbooking factors: ---------------------------------------------------- Tspec(LSP0) = LSP0 requested bandwidth = 30 Tspec(LSP1) = LSP1 requested bandwidth = 80 Reserved(LSP0) = Tspec(LSP0) = 30 Reserved(LSP1) = Tspec(LSP1) = 80 Ash, Lai Category - Expiration [Page 10] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 Normalized(LSP0) = Reserved(LSP0)/LOM0 = 30/1 = 30 Normalized(LSP1) = Reserved(LSP1)/LOM1 = 80/4 = 20 Then Unreserved(CT0) = BC0 - Normalized(CT0) = 50 - 30 = 20 Unreserved(CT1) = BC1 - Normalized(CT1) = 150 - 20 = 130 These quantities are advertised. Case B: the proposed modified way of applying overbooking factors: ------------------------------------------------------------------ First we adjust the BC0 and BC1 by the LSOM for this link: BC0 = 50/2 = 25 BC1 = 150/2 = 75 (note that the proposed method uses Max link bandwidth as the aggregate constraint) Then we determine the OB0 and OB1 factors: OB0 = LSPOB0 * LSOM * LOM0 = 1 * 2 * 1 = 2 OB1 = LSPOB1 * LSOM * LOM1 = 1 * 2 * 4 = 8 Tspec(LSP0) = LSP0 requested bandwidth = 30 Tspec(LSP1) = LSP1 requested bandwidth = 80 Reserved(LSP0) = Tspec(LSP0)/OB0 = 30/2 = 15 Reserved(LSP1) = Tspec(LSP1)/OB1 = 80/8 = 10 Then Unreserved(CT0) = BC0 - Reserved(CT0) = 25 - 15 = 10 Unreserved(CT1) = BC1 - Reserved(CT1) = 75 - 10 = 65 These quantities are advertised. 8. Security Considerations No new security considerations are raised by the overbooking methods presented in this document; they are the same as in the DS-TE Requirements document [1]. 9. References Normative References Ash, Lai Category - Expiration [Page 11] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 1 F. Le Faucheur (Editor), W.S. Lai (Co-editor), "Requirements for Support of Diff-Serv-aware MPLS Traffic Engineering," Approved for RFC publication, March 2003. 2 F. Le Faucheur (Editor), "Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering," Internet-Draft, Work in Progress. Informative References 3 F. Le Faucheur and W.S. Lai, "Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering," Internet-Draft, Work in Progress. 4 F. Le Faucheur (Editor), "Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering," Internet- Draft, Work in Progress. 5 J. Ash, "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons," Internet- Draft, Work in Progress. 6 W.S. Lai, "Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation," Internet-Draft, Work in Progress. 10. Contributing Authors Francois Le Faucheur, Sanjaya Choudhury, Dimitry Haskin, Sandy Goldfless, plus others (?). 11. Author's Address Jerry Ash AT&T Labs Room D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-4578 Email: gash@att.com Wai Sum Lai AT&T Labs Room D5-3D18 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-3712 Email: wlai@att.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to Ash, Lai Category - Expiration [Page 12] Internet-Draft Overbooking in Diffserv-aware MPLS TE Jun 2003 others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Ash, Lai Category - Expiration [Page 13]