Francois Le Faucheur, Editor Thomas Nadeau Cisco Systems, Inc. Martin Tatham BT Angela Chiu Celion Networks William Townsend Tenor Networks Darek Skalecki Nortel Networks Pete Hicks Core Express IETF Internet Draft Expires: January, 2002 Document: draft-lefaucheur-diff-te-proto-00.txt July, 2001 Protocol extensions for support of Diff-Serv-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 describes a solution for addressing the requirements defined in "Requirements for support of Diff-Serv-aware MPLS Traffic Le Faucheur, et. al 1 Protocols for Diff-Serv-aware TE July 2001 Engineering" [DSTE-REQ] and the corresponding extensions to existing MPLS TE protocols (ISIS, OSPF, RSVP-TE, CR-LDP) and procedures. This document also discusses how the detailed requirements defined in [DSTE-REQ] are met and how the solution fares against the evaluation criteria also defined in [DSTE-REQ]. 1. I-D Summary Information This section contains the information submitted on the "idsummary@subip.ietf.org" list of the Sub-IP area. SUMMARY: This draft describes protocol extensions (RSVP-TE, CR-LDP, OSPF, ISIS) to address the requirements defined in http://www.ietf.org/internet-drafts/draft-ietf-TEWG-diff-te-reqts- 01.txt, "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering". RELATED DOCUMENTS: - Complements: http://www.ietf.org/internet-drafts/draft-ietf-TEWG-diff-te-reqts- 01.txt - Replaces: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext- 01.txt http://www.ietf.org/internet-drafts/draft-ietf-isis-diff-te-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ospf-diff-te-00.txt - Competes: None that I know of. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK: This fits into TE-WG. WHY IS IT TARGETED AT THIS WG This directly addresses a specific item of the TEWG charter: "For the time being, it also is covering the area of verification that diffserv is achievable in traffic engineered SP networks. This will entail verification and review of the Diffserv requirements in the the WG Framework document and initial specification of how these requirements can be met through use and potentially expansion of existing protocols. " JUSTIFICATION The draft directly addresses an item of the charter. 2. Introduction [DSTE-REQ] presents the Service Providers requirements for support of Diff-Serv-aware MPLS Traffic Engineering (DS-TE). For memory, Le Faucheur et. al 2 Protocols for Diff-Serv-aware TE July 2001 this includes the fundamental requirement to be able to enforce different bandwidth constraints for different Class-Types. This document describes: - a solution for addressing these requirements including in environments relying on distributed Constraint Based Routing (i.e. path computation involving Head-end LSRs) - the corresponding extensions to existing MPLS TE protocols (ISIS, OSPF, RSVP-TE, CR-LDP) and procedures. - how the detailed requirements defined in [DSTE-REQ] are met - how the solution fares against the evaluation criteria also defined in [DSTE-REQ]. 3. Solution Overview 3.1. Configurable Parameters In order to configure the multiple bandwidth constraints to be enforced by DS-TE, for every link, it is possible to configure, in addition to all the existing TE parameters, the following new parameters (or any subset of those): - Maximum Reservable bandwidth for CT(3) - Maximum Reservable bandwidth for CT(3)+CT(2) - Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1) The existing "Maximum Reservable link bandwidth" parameter is interpreted as the: - Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)+CT(0) For example, a network administrator using one Class-Type for Voice and one Class-Type for data might configure on a given link: - Maximum Reservable Bandwidth for Voice + Data = 2.5 Gb/s - Maximum Reservable Bandwidth for Voice = 1.5 Gb/s 3.2. Preemption Model The preemption attribute defined in [TE-REQ] is retained for all Class-Types. The preemption attributes of setup priority and holding priority retain existing semantics, and in particular the preemption operates independently of class-types. This means that if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher preemption priority regardless of LSP1's CT and LSP2's CT. In other words, the solution offers 8 preemption priority levels to be used by LSPs completely orthogonally to the LSP's Class-Type. Just for illustration purposes, a Service Provider using two Class- Types, may elect to configure: - all Voice LSPs to preemption priority 0 - all Data LSPs to preemption priority 1 Le Faucheur et. al 3 Protocols for Diff-Serv-aware TE July 2001 in order to make sureVoice LSPs are never driven away from their shortest path because ofData LSPs. Another Service Provider may elect to configure: - all large sizeVoice LSPs to preemption priority 0 - all large size Data LSPs to preemption priority 1 - all small size Voice LSPs to preemption priority 2 - all small size Data LSPs to preemption priority 3 in order to try to optimize global network resource utilization by favoring placement of large LSPs first. 3.3. IGP Advertisement This solution takes the straightforward approach of advertising for each active Class-Type the same bandwidth information as currently advertised for aggregate TE i.e. for each Class-Type advertise the "unreserved Bandwidth" at each preemption level. This "unreserved bandwidth" takes account of all the potential constraints that may apply to the considered Class-Type. Details on how to compute the "unreserved bandwidth for CT(N)" are provided in Appendix A. In order to minimize the size of IGP advertisement, a compression scheme is proposed below so that no bandwidth information is encoded for preemption levels which are not actually used within a Class- Type. Note that no information needs to be advertised for a Class-Type which is not actually used in a given network. 3.4. LSP Set-up This solution specifies that the TE-LSP signaling protocols (RSVP- TE, CR-LDP) signal the Class-Type of the LSP. This is used by LSRs so that the local CAC enforces the bandwidth constraints relevant to the LSP Class-Type and updates the corresponding counters for reserved/unreserved bandwidth for the LSP Class-Type. This also avoids the need for configuring on intermediate LSRs the mapping between preemption and Class-Types. 3.5. Constraint Based Routing Since the "unreserved bandwidth for CT(N)" advertised by the IGP factors in all the potential bandwidth constraints affecting that CT, the Constraint Based Routing algorithm is only required to perform path computation satisfying a single bandwidth constraint. Thus, no change is required on the existing TE Constraint Based Routing algorithm. Only, this algorithm now considers the "unreserved bandwidth" relevant to the particular CT and to the particular preemption priority of the LSP for which the route is computed. Le Faucheur et. al 4 Protocols for Diff-Serv-aware TE July 2001 3.6. Diff-Serv scheduling The Class-Type signaled by the TE-LSP signaling protocols can optionally be used by LSRs to dynamically adjust the resources allocated to a Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv information (e.g. PSC) signaled by the TE-LSP signaling protocols as specified in [DIFF-MPLS] can optionally be used by LSRs to dynamically adjust the resources allocated to a Class within a Class-Type by the Diff-Serv scheduler. 4. Protocol and Procedure Extensions Protocol and Procedure Extensions for the DS-TE solution are detailed in Appendix B. 5. Addressing DS-TE Detailed Requirements This section discusses how this solution addresses each of the detailed requirements for DS-TE identified in section 2 of [DSTE- REQ]. 5.1. DS-TE Compatibility Since all the DS-TE extensions are above and beyond the existing TE extensions, this solution raises no interoperability issues with existing deployed TE mechanisms. Networks which do not require DS-TE are not impacted in any way. Since all extensions are on a per Class-Type basis and only used for actually deployed Class-Types, the solution allows DS-TE deployment to the required level of granularity and scope (e.g. only in a subset of the topology, e.g. only for the number of Classes required in the considered network) 5.2. Separate Bandwidth Constraints The solutions allows configuration and enforcement of the specific bandwidth constraints defined in [DSTE-REQ] i.e.: - never route more than P(N-1)% of CT(N-1) on a given link - never route more than P(N-2)% of CT(N-1)+CT(N-2) on that link. - etc. - never route more than P(0)% of CT(N-1)+CT(N-2)+... + CT(0) on that link, where P(N-1), P(N-2), ..., P(0) are each configurable separately for every link. Le Faucheur et. al 5 Protocols for Diff-Serv-aware TE July 2001 More generally, the solution simultaneously supports the combination of objectives on bandwidth constraints identified in [DSTE-REQ]: " - if a high priority class does not use up all of its bandwidth, the next highest priority should be able to make use of this unused bandwidth. For instance, in the above example with 3 Class-Types, if CT2/EF is only using 30% (instead of its maximum 60%), then CT1/AF should be able to use up to 50%. However, if CT2/EF is using its 60%, it is obviously necessary to limit CT1/AF to much below 50% (i.e. to 20% in our example) in order to maintain CT2's performance levels. - If a lower priority class (e.g. AF) used some of the unused bandwidth of a higher priority class (e.g. EF), the high priority class should be able to reclaim this bandwidth where necessary (i.e. preempt lower priority class - see section 2.5) - lower priority class-Types (e.g Best Effort) should not be completely starved by higher priority classes. - Highest priority classes, should only be routed away from their shortest path when they would exceed their own bandwidth constraints. They should not be routed away from their shortest path because of lower priority classes. " For example, let's assume the network administrator configures: - Max Reservable bandwidth for CT2/EF= 60% - Max Reservable bandwidth for CT2/EF + CT1/AF= 80% - Max Reservable bandwidth for CT2/EF + CT1/AF + CT0/BE = 100% - Preemption Priority of CT2 LSPs is high - Preemption Priority of CT1 LSPs is medium - Preemption Priority of CT0 LSPs is low Then, - if CT2 LSPs do not use up all the 60%, whatever's left can be used by CT1 (or CT0 if not used by CT1) - If CT1+CT2 LSPs do not use up all the 80%, whatever's left can be used by CT0 - If CT1 or CT0 LSPs are using some of CT2's 60%, then new CT2 LSPs will be able to preempt some CT0 (and if necessary CT1) LSPs until CT2 LSPs use the full 60%, since the preemption priority operates across Class-Types - CT1 is never starved since it will always be able to use at least 80-60=20% - CT0 is never starved since it will always be able to use at least 100-80=20% - Since they are configured with higher preemption priority, CT2 LSPs will only be routed away from their shortest path if CT2 is using its 60%, never because of the amount of CT1 or CT0 LSPs established. 5.3. Number of Class-Types The DS-TE solution supports the required 4 Class-Types. Le Faucheur et. al 6 Protocols for Diff-Serv-aware TE July 2001 In a given network, the solution does not force the network administrator to support the maximum number of Class-Types. The network administrator may deploy DS-TE for only 2, for only 3 or for 4 Class-Types. The solution minimizes the scalability impact when low number of Class-Types are actually deployed because extensions are on a per-CT basis and are only used for CTs actually deployed. The solution can be extended to any arbitrary number of Class-Types simply by replicating the per-CT extensions. 5.4. Number of Classes The solution does not constrain the number of classes that can be grouped in a Class-Type. 5.5. Preemption 5.5.1. Preemption Within a Class-Type Since preemption is defined independently of Class-Types, the solution supports multiple preemption priorities within a given Class-Type. To allow preemption among two LSPs of the same CT, the network administrator only need to configure the two LSPs with different preemption priorities. The solution also allows preemption to be disabled within a Class- Type by simply configuring all LSPs of a given CT to the same preemption priority. 5.5.2. Preemption Across Class-Types Since preemption is defined independently of Class-Types, the solution supports multiple preemption priorities across Class-Types. To allow preemption among two LSPs of different CTs, the network administrator only need to configure the two LSPs with different preemption priorities. The solution also allows preemption to be disabled across Class- Types by simply configuring all LSPs of the considered CTs to the same preemption priority. 5.6. Resource Class Affinity The solution allows separate configuration of Resource Class Affinity attributes for each DS-TE tunnel. 5.7. Traffic Mapping The solution supports traffic mapping as defined in [DSTE-REQ]. Le Faucheur et. al 7 Protocols for Diff-Serv-aware TE July 2001 5.8. Dynamic Adjustment of Diff-Serv PHBs The solution allows optional adjustment of Diff-Serv PHBs parameters (e.g. queue bandwidth) based on the amount of TE-LSPs established for each Class/Class-Type. The Class-Type signaled in TE LSP signaling protocol can be used for that purposes. The solution allows for disabling dynamic adjutment via configuration (thus reverting to PHB treatment with static scheduler configuration independent of DS-TE operations). The solution allows dynamic adjustment to take account of the performance requirements of each class when computing required adjustments. 5.9. Multiple TE Metrics The solution can make immediate use of multiple TE metrics once those are available simply by allowing TE-LSPs for different Classes of Service to be routed based on a different TE Metric. 5.10. Conclusion The solution addresses every detailed requirements of [DSTE-REQ]. 6. Solution Evaluation This section discusses how this solution fares against each of the evaluation criteria identified in section 3 of [DSTE-REQ]. 6.1. Addressing Scenarios The solution addresses all the scenarios described in section 1. Examples of how the solution can be deployed to address each scenario are provided in Appendix C. 6.2. Flexibility The solution supports the number of Class Types identified in [DSTE- REQ]. The solution supports any arbitrary number of Classes within a Class-Type 6.3. Extendibility The solution can be easily extended to support any arbitrary number of Class-Types that may be required in the future. 6.4. Scalability Le Faucheur et. al 8 Protocols for Diff-Serv-aware TE July 2001 6.4.1. Path Computation Path computation is often the most taxing task on the router CPU and thus the most determinant in terms of IGP scalability, so we consider this aspect first. TE/DS-TE typically triggers Constraint Based Routing path computation on events such as: 1) activation of a TE-LSP 2) reoptimisation timers 3) notification (by TE-LSP signaling protocol or IGP) that a link on current path of a TE-LSP becomes invalid. However, TE/DS-TE does not trigger Constraint Based Routing path computation because of changes in "Unreserved Bandwidth" information advertised by the IGP. "Unreserved Bandwidth" information will be used in the future whenever a new path computation is performed but changes in these value do not directly trigger Constraint Based Routing path computation. Since the IGP extensions proposed in this solution only contain "unreserved Bandwidth" information, our first conclusion is that this solution does not affect how frequently Constraint Based Routing path computation is run compared to existing TE. Secondly, since path computation is performed with the same algorithm as aggregate TE (but simply considering a different value of "unreserved bandwidth"), the solution does not have any significant impact on the time it takes to execute a path computation. In short, this solution advertises more information that goes into the TE topology database but does not significantly affect how often path computation is run nor the time it takes to run the path computation. Consequently, when considering the predominant aspect of IGP scalability which is path computation, we feel that the proposed DS- TE solution has no significant scalability impact as compared to existing TE. 6.4.2. Processing of a received LSP/LSA Processing a received LSP/LSA and storing its content in the topology database involves a significant proportion of processing which is fairly independent of the actual LSP/LSA content (e.g. parsing, checks, database access). We expect that increasing the size of the TE TLV by (in worst case) 35 octets (new Sub-TLV comprises 1 octet for T, 1 octet for L, and 33 octets worst case for V) per Class-Type would result in no significant overhead in terms of pure LSP/LSA processing. Le Faucheur et. al 9 Protocols for Diff-Serv-aware TE July 2001 In normal IGP operations, increase in amount of information contained in an LSP/LSA potentially affects CPU load (and thus scalability) because this increases the likelihood of "significant changes" which can trigger SPF computation. However, as discussed above, this does not apply to "Unreserved Bandwidth" information which does not trigger TE/DS-TE path computation. Thus, the proposed IGP extensions are expected to result in no significant impact from the viewpoint of processing a received LSP/LSA. 6.4.3. Generating an LSP/LSA Similarly generating a LSP/LSA involves a significant proportion of processing which is fairly independent of the actual LSP/LSA content. Increasing the size of the TE TLV by 35 octets per Class- Type is expected to result in no significant overhead in terms of pure LSP/LSA generation. 6.4.4. Increased Flooding Frequency In addition to usual IGP flooding triggers, TE/DS-TE implementations usually also trigger IGP flooding updates via thresholds on local "Unreserved Bandwidth" values. Since DS-TE maintains more "Unreserved Bandwidth" values it is expected that this may result in more frequent generation/reception of LSPs/LSAs. However, as explained above, this would result in more frequent generation and processing of LSP/LSA but would not result in more frequent path computation which is the prime consideration. Also, we would expect the frequency increase factor to be typically much below the number of Class-Types since there are correlation between "unreserved Bandwidth" values changes across Class-Types. So this is not expected to result in a significant scalability impact. We also observe that in environments where a given preemption level is only used by a single Class-Type (as constrained by proposals such as [DSTE-NOP]), this frequency increase would be identical with proposals such as [DSTE-NOP] since the number of Unreserved Bandwidth values which effectively change over time would be identical with both approach and thus trigger exactly the same thresholds. 6.4.5. TLV size We have argued above that the proposed TLV size increase has marginal impact on CPU load. This section looks more precisely at the TLV size increase in order to relate this to the hard size limits of IGP advertisement. Activating Aggregate TE results in the advertisement of the extended IS reachability TLV which comprises (at least) 82 bytes (see [ISIS- Le Faucheur et. al 10 Protocols for Diff-Serv-aware TE July 2001 TE]: 1 octet of T, 1 octet of L, 11 octets of data structure, 7 x 1 octet of T for each sub-TLV, 7x1 octet of L for each sub-TLV, and 55 octets of V for all the sub-TLV Vs). Activating the DS-TE solution described in this document results in increasing the size of the extended IS reachability TLV of (P*4)+3 octets [1 octet of T, 1 octet of L and (P*4)+1 octets of V] per Class-Type beyond CT0 (where 1<=P<=8, depending on the number of preemption levels actually used by the Class-Type in addition to preemption level zero). Thus, in the worst case where all the 8 preemption levels are used by every Class-Type, this DS-TE solution increases the TLV size by 35 octets per Class-Type beyond the 82 octets with TE. In a situation where each Class-Type uses a single level of preemption (which is not preemption zero), this DS-TE solution increases the TLV size by 11 octets only per Class-Types beyond the 82 octets with TE. As a typical example, in DS-TE deployment with 3 Class-Types (ie 2 CTs beyond CT0) each with a single level of preemption, the DS-TE solution has increased TLV size from 82 to 104 octets. Thus, we do not expect this solution to result in an issue with respect to maximum TLV size since we are still well below the maximum sub-TLV size of 255 bytes. We also do not expect such size increase to result in issues regarding maximum LSP size (which are being worked on in IETF anyway). 6.4.6. Database Size As more information is advertised with the proposed solution compared to TE, the TE topology database size would increase compared to existing TE. If we take the worst case of all 4 Class-Types being deployed (i.e. 3 CTs beyond CT0) and all preemption levels being used by every Class-Type, then the solution would result in an extra 35x3=105bytes per TLV. Although this information is often encoded in a different format when stored in the topology database, it would be of the same order of magnitude. So increase in database size is O(100byte) per TLV. Thus, if we consider a network with 1,000 links, we expect the database size impact to be O(100 kbytes). In a network of 10,000 links, we expect the database size impact to be O(1Mbyte). Thus we expect the impact of the solution on database size to be acceptable even in worst case of 4 Class-Types and in large networks. 6.4.7. Tunnel Signaling Because accurate unreserved bandwidth information is advertised to all head-ends for each CT and for each preemption, the solution does Le Faucheur et. al 11 Protocols for Diff-Serv-aware TE July 2001 not result in any unnecessary tunnel establishment failure/retry (beyond the inevitable ones due to database de-synchronization in between floodings) and thus does not have any scalability impact in terms of tunnel signaling nor path (re)computation. 6.4.8. Link Bandwidth consumed by advertisement It is the belief of the authors that because of typical link speeds used in Service Provider networks, bandwidth consumed by IGP advertisements is not a significant scalability constraint per say. Increase in consumed link bandwidth as per this solution would not change this. 6.4.9. Scalability Conclusions Our assessment is that the DS-TE solution proposed above only has a marginal impact on IGP scalability compared to existing TE. Although not entirely intuitive at first glance, this conclusion can be primarily explained by the combination of those facts: - IGP scalability is predominantly constrained by CPU load - CPU load is predominantly due to path computation - IGP extensions proposed by this solution do not affect frequency nor affect significantly complexity of path computation. We also feel that the small delta in scalability impact between this approach and approaches which may attempt to minimize the amount of information advertised in the IGP such as [DSTE-NOP] is outweighted by (i) the resulting flexibility including: - any CT can use any subset of the 8 preemption priorities - preemption is possible within CTs and across CTs - distribution of preemption priorities used by each CT can be modified at any time by the Service Provider without any change on the IGP configuration (ii) the smooth handling of any migration scenario: - TE LSRs can be gradually upgraded to DS-TE LSRs and DS- TE will dynamically be able to operate on all upgraded LSRs as they get upgraded - LSRs can be gradually reconfigured to support a new CT and DS-TE will dynamically be able to establish Tunnels of the new CT on all upgraded LSRs as they get upgraded. (iii) its operational resiliency: - information on relationship between CT and preemption is encoded in IGP advertisement avoiding reliance on consistent configuration throughout the whole network. We are seeking other opinions on this trade-off between scalability delta Versus flexibility/easier operations. 6.5. Backward compatibility/Migration 6.5.1. Backward compatibility/Migration with existing TE Le Faucheur et. al 12 Protocols for Diff-Serv-aware TE July 2001 Because the solution only proposes extensions over the existing aggregate TE mechanisms which are left unchanged, it is fully compatible with existing TE mechanisms. DS-TE can be deployed in an environment supporting aggregate TE without any migration. In particular, the following is supported for smooth migration: - operations in heterogeneous environments where some LSRs are Diff-Serv-TE-capable while some other LSRs are not Diff-Serv- TE-capable (i.e. support aggregate TE only) - in such heterogeneous environments, the solution allows establishment of Class-Type 0 LSPs across paths combining Diff- Serv-TE-capable LSRs and non-Diff-Serv-TE-capable LSRs - in such heterogeneous environments, the solution ensures that a non-Diff-Serv-TE-capable LSR would reject establishment of a Class-Type N (N=1,2,3) LSP. 6.5.2. Backward Compatibility/Migration with Changing Number of CTs Because the solution proposes separate extensions for each Class- Type, a Class-Type can be added or removed from a given deployment without any migration/compatibility issue. In particular, the following is supported for smooth migration when increasing/deceasing number of CTs: - operations in heterogeneous environments where some Diff-Serv- TE-capable LSRs (as defined in this specification) support N Class-Types while other Diff-Serv-TE-capable LSRs support M Class-Types with M>N. - in such heterogeneous environments, the solution allows establishment of Class-Type 0,.., N-1 LSPs across paths combining both types of LSRs - in such heterogeneous environments, the solution ensures that a Diff-Serv-TE-capable LSR supporting only N Class-Types would reject establishment of a Class-Type X LSP if N<=X<=M-1. 6.5.3. Backward Compatibility/Migration with Changing Distribution of Preemption Across CTs Because the solution proposes extensions allowing all eight preemption priorities by each CT, a CT can start/stop using any preemption level priorities without any migration/compatibility issue and without any reconfiguration of IGP on LSRs. 7. Security Considerations The solution is not expected to add specific security requirements beyond those of Diff-Serv and existing TE. The security mechanisms currently used with Diff-Serv and existing TE can be used with this solution. Le Faucheur et. al 13 Protocols for Diff-Serv-aware TE July 2001 8. Acknowledgments This document has benefited from the expertise of Carol Iturralde, Stefano Previdi and Jean-Philippe Vasseur. References [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts- 01.txt, June 2001. [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-katz-yeung-ospf-traffic-05.txt, June 2001. [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- ietf-isis-traffic-03.txt, June 2001. [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-05.txt, February 2001 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- ietf-mpls-diff-ext-09.txt, April 2001 [DIFF-NEW] Grossman, "New Terminology for Diffserv", work in progress, draft-ietf-diffserv-new-terms-04.txt, March 2001. [DSTE-NOP] Boyle, "Accomplishing Diffserv TE needs with Current Specifications", draft-boyle-tewg-ds-nop-00.txt, July 2001. Authors' Address: Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France Phone: +33 4 97 23 26 19 Email: flefauch@cisco.com Martin Tatham BT Adastral Park, Martlesham Heath, Ipswich IP5 3RE UK Le Faucheur et. al 14 Protocols for Diff-Serv-aware TE July 2001 Phone: +44-1473-606349 Email: martin.tatham@bt.com Angela Chiu Celion Networks 1 Sheila Drive, Suite 2 Tinton Falls, NJ 07724 Phone: +1-732 747 9987 Email: angela.chiu@celion.com William Townsend Tenor Networks 100 Nagog Park Acton, MA 01720 Phone: +1-978-264-4900 Email: btownsend@tenornetworks.com Thomas D. Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9 Phone: +1-613-765-2252 Email: dareks@nortelnetworks.com Pete Hicks CoreExpress, Inc 12655 Olive Blvd, Suite 500 St. Louis, MO 63141 USA Phone: (314) 317-7504 Email: pete.hicks@coreexpress.net Le Faucheur et. al 15 Protocols for Diff-Serv-aware TE July 2001 Appendix A - Computing "Unreserved Bandwidth for CT-N" This Appendix defines how the "unreserved bandwidth for CT-N" is computed for IGP advertisment as well as for local admission control of DS-TE LSPs by LSRs. Imagine the Service Provider configured: - Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)= 100 Mb/s - Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)+CT(0)=155 Mb/s Say that, at the considered preemption priority, there is currently: - 0 Mb/s of CT(3) LSPs - 0 Mb/s of CT(2) LSPs - 90 Mb/s of CT(1) LSPs - 10 Mb/s of CT(0) LSPs then, the bandwidth "reservable" (aka. "unreserved") for new CT(1) LSPs is 100-90=10 Mb/s and is effectively constrained by the "Max Reservable bandwidth for CT(3)+CT(2)+CT(1)" Now say that, at the considered preemption priority, there is currently: - 0 Mb/s of CT(3) LSPs - 0 Mb/s of CT(2) LSPs - 10 Mb/s of CT(1) LSPs - 100 Mb/s of CT(0) LSPs then, the bandwidth "reservable" (aka. "unreserved") for new CT(1) LSPs is 155-10-100=45 Mb/s and, this time, is effectively constrained by the "Max Reservable bandwidth for CT(3)+CT(2)+CT(1)+CT(0)" More generally, the bandwidth "reservable" (aka. "unreserved") for new LSPs of CT(N), at a considered preemption priority, is computed as the smallest of: - the CT(3)+CT(2)+CT(1)+CT(0) bandwidth currently unreserved (i.e. the difference between the "Maximum Reservable Bandwidth for CT(3)+CT(2)+CT(1)+CT(0) and the bandwidth reserved by LSPs of CT(0) and CT(1) and CT(2) and CT(3)). - . . . - the CT(3)+ . . . +CT(1) bandwidth currently unreserved (i.e. the difference between the "Maximum Reservable Bandwidth for CT(3)+ . . . +CT(N) and the bandwidth reserved by LSPs of CT(N) and . . . and CT(3)). Le Faucheur et. al 16 Protocols for Diff-Serv-aware TE July 2001 Appendix B - Protocol and Procedure Extensions 9. ISIS Extensions In this section we describe the extensions to IS-IS for support of DS-TE. These extensions are in addition to the extensions required to support (aggregate) MPLS Traffic Engineering defined in [ISIS- TE]. 9.1. Existing TE sub-TLVs [ISIS-TE] defines new extended TLVs for support of (aggregate) Traffic Engineering. One of these extended TLV is referred to as the extended IS reachability TLV (TLV type 22). This TLV contains a number of new sub-TLVs. In this document we refer to the sub-TLV 10 (Maximum reservable link bandwidth) of the extended IS reachability TLV (as defined in [ISIS- TE]) as the "Maximum Reservable Bandwidth for CT(3)+CT(2)+CT(1)+CT(0)". We also refer to the sub-TLV 11 (unreserved bandwidth) of the extended IS reachability TLV (as defined in [ISIS-TE]) as the "Unreserved Bandwidth for Class-Type 0". 9.2. New Sub-TLVs The following additional sub-TLVs are defined for the extended IS reachability TLV (sub-TLV numbers to be allocated): TBD1 - Unreserved bandwidth for Class-Type 1 TBD2 - Unreserved bandwidth for Class-Type 2 TBD3 - Unreserved bandwidth for Class-Type 3 Each sub-TLV may occur only once. Unrecognized types are ignored. The additional sub-TLVs defined above are optional so that they may or may not be included in the extended IS reachability TLV. The extended IS reachability TLV may include the sub-TLVs for any subset of the three additional Class-Types. In other words, the IS reachability TLV may contain none of the three sub-TLVs defined above, any one of those, any two of those, or the three sub-TLVs. Where a Class-Type is not effectively used in a network, it is recommended that the corresponding sub-TLV is not included in the IS reachability TLV. Therefore, the Class-Types to be advertised in ISIS should be configurable. For instance, a Network Administrator may elect to use Diff-Serv Traffic Engineering in order to compute separate routes for data traffic and voice traffic. In that case, the IGP would be configured to only advertise the sub-TLV for one additional Class-Type (i.e. the extended IS reachability TLV would Le Faucheur et. al 17 Protocols for Diff-Serv-aware TE July 2001 contain sub-TLV 10 for the "Maximum Reservable Bandwidth for CT(3)+CT(2)+CT(1)+CT(0)", sub-TLV 11 for the "Unreserved Bandwidth for Class-Type 0" and sub-TLV TBD1 for "Unreserved Bandwidth for Class-Type 1"). An LSR which supports Class-Type N and receiving an extended IS reachability TLV without the sub-TLV corresponding to Class-Type N, must interpret this as meaning that the corresponding link does not support Class-Type N. For Constraint Based Routing purposes, the LSR may consider this equivalent to the case where the extended IS reachability TLV contains an Unreserved Bandwidth Class-Type N sub- TLV with bandwidth values set to zero. An LSR which does not support Class-Type N and which receives an extended IS reachability TLV containing the sub-TLV corresponding to Class-Type N, must ignore this sub-TLV. However, the IS reachability TLV must be flooded transparently, so that the sub-TLV for Class- Type N is kept in the IS reachability TLV when reflooded by this LSR. 9.3. Sub-TLV Details The Unreserved Bandwidth for Class-Type N (N= 1,2,3) sub-TLVs specifies the amount of bandwidth reservable by Class-Type N LSPs at each of the eight preemption priority levels. Details for computing the Unreserved Bandwitdh for CT(N) are provided in Appendix A. When the bandwidth value for preemption Z (Z > 0) is identical to the bandwidth value for preemption Z-1, the bandwidth value for preemption Z is not explicitly repeated in the sub-TLV. Rather, the fact that it is identical to the value of preemption Z-1, is encoded in a "repetition octet". Thus, the sub-TLV comprises: - P (1<=P<=8) bandwidth values. These values correspond to the bandwidth that can be reserved with a holding priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 towards the end of the sub-TLV, but omitting all repeated values. The units are bytes per second and the values are encoded in IEEE floating point format. - a "repetition octet" where each bit is referred to as bitZ , 0 <= Z < 8, and is defined to have the following meaning: * if bitZ = 0 then "Unreserved Bandwidth" for preemption level Z is explicitely included in the sub-TLV, * if bitZ = 1 then "Unreserved Bandwidth" for preemption level Z is not explicitely included in the sub-TLV but is defined to be equal to "Unreserved Bandwidth" for preemption level Z-1. Le Faucheur et. al 18 Protocols for Diff-Serv-aware TE July 2001 Note that the highest preemption level (level 0) is always advertised and the first bit (Bit0) in the "repetition octet" is always set to 0. [Editor's note: should the "repetition octet" be moved before the bandwidth values?] The Unreserved Bandwidth for Class-Type N sub-TLV is TLV type (TBDN). Its length is (P*4 +1), where 1<=P<=8 and where P is the number of non-equal bandwidth values across all preemption levels for that Class-Type. For example, when a link supports LSPs of preemption levels 2 and 4 only (for a particular Class-Type) with "Unreserved Bandwidth" (for the particular Class-Type) on that link for preemption levels 0, 2, and 4 currently of 10Mb/s, 5Mb/s and 3Mb/s, respectively, then "Unreserved Bandwidth" (for the particular Class-Type) for preemption levels 0, 2, and 4 of 10Mb/s, 5Mb/s and 3Mb/s, respectively, are explicitly advertised for that link as well as "repetition octet" of 01010111 in binary form. The sub-TLV length is 13. 10. OSPF Extensions In this section we describe the extensions to OSPF for support of DS-TE. These extensions are in addition to the extensions already defined for support of (aggregate) MPLS Traffic Engineering in [OSPF-TE]. 10.1. Existing TE Sub-TLVs [OSPF-TE] defines a new LSA for support of (aggregate) Traffic Engineering, which is referred to as the Traffic Engineering LSA. This LSA contains a Link TLV (Type 2) comprising a number of sub- TLVs. In this document we refer to the sub-TLV 7 (maximum reservable bandwidth) of the Link TLV (as defined in [OSPF-TE]) as the "Maximum Reservable Bandwidth for CT(3)+CT(2)+CT(1)+CT(0)". We also refer to the sub-TLV 8 (unreserved bandwidth) of the Link TLV (as defined in [OSPF-TE]) as the "Unreserved Bandwidth for Class-Type 0". 10.2. New Sub-TLVs The following additional sub-TLVs are defined for the Link TLV of the Traffic Engineering LSA (sub-TLV numbers to be allocated) TBD1' - Unreserved Bandwidth for Class-Type 1 (32 octets) TBD2' - Unreserved Bandwidth for Class-Type 2 (32 octets) Le Faucheur et. al 19 Protocols for Diff-Serv-aware TE July 2001 TBD3' - Unreserved Bandwidth for Class-Type 3 (32 octets) The rules relating to which of this new OSPF sub-TLV is present in the Link TLV are the same as the rules presented in section 3.1.2 relating to which new IS-IS sub-TLV is present in the extended IS reachability TLV. 10.3. Sub-TLV Details The encoding for the new OSPF Sub-TLV is identical to the one for IS-IS described above in section 3.1.3. 11. RSVP Extensions In this section we describe extensions to RSVP for support of DS-TE. These extensions are in addition to the extensions to RSVP defined in [RSVP-TE] for support of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 11.1. Diff-Serv related RSVP Messages Format One new RSVP Object is defined in this document: the CLASSTYPE Object. Detailed description of this Object is provided below. This new Object is applicable to Path messages. This specification only defines the use of the CLASSTYPE Object in Path messages used to establish LSP Tunnels in accordance with [RSVP-TE] and thus containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object. Restrictions defined in [RSVP-TE] for support of establishment of LSP Tunnels via RSVP are also applicable to the establishment of LSP Tunnels supporting Diff-Serv Traffic Engineering. For instance, only unicast LSPs are supported and Multicast LSPs are for further study. This new CLASSTYPE object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP set up do not have to support this object. An LSR supporting DS-TE in compliance with this specification MUST support the CLASSTYPE Object. It MUST support Class-Type value 1, and MAY support other Class-Type values. The format of the Path message is as follows: ::= [ ] [ ] [ ] Le Faucheur et. al 20 Protocols for Diff-Serv-aware TE July 2001 [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] 11.2. CLASSTYPE object class = TBD, C_Type = 1 (need to get an official class num from the IANA with the form 0bbbbbbb) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |CT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 30 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. CT : 2 bits Indicates the Class-Type. Values currently allowed are 1, 2 and 3. 11.3. Handling CLASSTYPE Object To establish an LSP tunnel with RSVP, the sender LSR creates a Path message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also include the DIFFSERV object as per [DIFF-MPLS]. If the LSP is associated with Class-Type 0, the sender LSR must not include the CLASSTYPE object in the Path message. If the LSP is associated with Class-Type N (N=1,2,3), the sender LSR must include the CLASSTYPE object in the Path message with the Class-Type (CT) field set to N. If a path message contains multiple CLASSTYPE objects, only the first one is meaningful; subsequent CLASSTYPE object(s) must be ignored and must not be forwarded. Each LSR along the path records the CLASSTYPE object, when present, in its path state block. Le Faucheur et. al 21 Protocols for Diff-Serv-aware TE July 2001 If the CLASSTYPE object is not present in the Path message, the LSR must associate the Class-Type 0 to the LSP. The destination LSR responds to the Path message by sending a Resv message without a CLASSTYPE object (whether the Path message contained a CLASSTYPE object or not). During establishment of an LSP corresponding to the Class-Type N, the LSR performs admission control over the "unreserved bandwidth" for that particular Class-Type, which is computed as defined in Appendix A. An LSR that recognizes the CLASSTYPE object and that receives a path message which contains the CLASSTYPE object but which does not contain a LABEL_REQUEST object or which does not have a session type of LSP_Tunnel_IPv4, must send a PathErr towards the sender with the error code 'Diff-Serv TE Error' and an error value of 'Unexpected CLASSTYPE object'. Those are defined below in section 4.5. An LSR receiving a Path message with the CLASSTYPE object, which recognizes the CLASSTYPE object but does not support the particular Class-Type, must send a PathErr towards the sender with the error code 'Diff-Serv TE Error' and an error value of 'Unsupported Class- Type'. Those are defined below in section 4.5. An LSR receiving a Path message with the CLASSTYPE object, which recognizes the CLASSTYPE object but determines that the Class-Type value is not valid (i.e. Class-Type value 0), must send a PathErr towards the sender with the error code 'Diff-Serv TE Error' and an error value of 'Invalid Class-Type value'. Those are defined below in section 4.5. An LSR MUST handle the situations where the LSP can not be accepted for other reasons than those already discussed in this section, in accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is rejected by admission control, a label can not be associated). 11.4. Non-support of the CLASSTYPE Object An LSR that does not recognize the CLASSTYPE object Class-Num must behave in accordance with the procedures specified in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a PathErr with the error code 'Unknown object class' toward the sender). An LSR that recognizes the CLASSTYPE object Class-Num but does not recognize the CLASSTYPE object C-Type, must behave in accordance with the procedures specified in [RSVP] for an unknown C-type (i.e. it must send a PathErr with the error code 'Unknown object C-Type' toward the sender). Le Faucheur et. al 22 Protocols for Diff-Serv-aware TE July 2001 In both situations, this causes the path set-up to fail. The sender should notify management that a LSP cannot be established and possibly might take action to retry reservation establishment without the CLASSTYPE object. 11.5. Error Codes For Diff-Serv TE In the procedures described above, certain errors must be reported as a 'Diff-Serv TE Error'. The value of the 'Diff-Serv TE Error' error code is (TBD). The following defines error values for the Diff-Serv TE Error: Value Error 1 Unexpected CLASSTYPE object 2 Unsupported Class-Type 3 Invalid Class-Type value 12. CR-LDP Extensions CR-LDP, defined in [CR-LDP], is an extension to LDP, defined in [LDP], for support of (aggregate) MPLS Traffic Engineering. In this section we describe extensions to CR-LDP for support of DS-TE. These extensions are in addition to the extensions to LDP defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. They closely resemble the extensions to RSVP defined in the previous section. Note that extensions of this section for support of Diff-Serv Traffic Engineering are not applicable to LDP due to the fact that LDP does not support MPLS Traffic Engineering and bandwidth reservation in particular. 12.1. Diff-Serv TE related CR-LDP Messages Encoding One new CR-LDP TLV is defined in this document: the Class Type TLV. Detailed description of this TLV is provided below. This new TLV is applicable to Label Request messages. Restrictions defined in [CR-LDP] for support of establishment of LSPs via CR-LDP are also applicable to the establishment of LSPs supporting Diff-Serv Traffic Engineering: for instance, only unicast LSPs are supported and multicast LSPs are for further study. This new Class Type TLV is optional with respect to CR-LDP so that general CR-LDP implementations not concerned with per-Class-Type Diff-Serv Traffic Engineering are not required to support this TLV. An LSR supporting DS-TE in compliance with this specification MUST support the Class Type TLV. It MUST support Class-Type value 1, and MAY support other Class-Type values. Le Faucheur et. al 23 Protocols for Diff-Serv-aware TE July 2001 The encoding for the CR-LDP Label Request message is extended as follows, to optionally include the Class Type TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class Type TLV (CR-LDP optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other CR-LDP TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The extension is based on a related LDP extension, defined in [DIFF- MPLS], for support of Diff-Serv TLV but further extended for CR-LDP with CR-LDP TLVs. 12.2. Class Type TLV The Class Type TLV has the following form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Class Type TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |CT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 30 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. CT : 2 bits Indicates the Class-Type. Values currently allowed are 1, 2 and 3. 12.3. Handling Class Type TLV To establish an LSP using CR-LDP, an ingress LSR generates a Label Request message as per [CR-LDP]. This Label Request may optionally include the Diff-Serv TLV as defined in [DIFF-MPLS] for LDP but extended to CR-LDP. If the LSP is associated with Class-Type 0, the ingress LSR must not include the Class Type TLV in the Label Request message. Le Faucheur et. al 24 Protocols for Diff-Serv-aware TE July 2001 If the LSP is associated with Class-Type N (N=1,2,3), the ingress LSR must include the Class Type TLV in the Label Request message with the Class-Type (CT) field set to N. If a Label Request message contains multiple Class Type TLVs, only the first one is meaningful; subsequent Class Type TLV(s) must be ignored and not forwarded. If the Class Type TLV is not present in the Label Request message, an LSR must associate the Class-Type 0 to the LSP. A downstream LSR sending a Label Mapping message in response to a Label Request message must not include the Class-Type TLV (whether the Class-Type TLV was included in the Label Request message or not). During establishment of an LSP corresponding to the Class-Type N, an LSR performs admission control over the "unreserved bandwidth" for that particular Class-Type, which is computed as defined in Appendix A. An LSR that recognizes the Class Type TLV and receives a Label Request message which contains the Class Type TLV but which does not contain any of the CR-LDP TLVs, must reject the label request by sending upstream a Notification message which includes the Status TLV with a Status Code of 'Unexpected Class-Type TLV'. This is defined below in section 5.4. This error can only occur when an LDP LSP as opposed to CR-LDP LSP is being established. As was already mentioned, Class Type TLV extension for Diff-Serv Traffic Engineering is not applicable to LDP. An LSR receiving a Label Request message with the Class Type TLV, which recognizes the Class Type TLV but does not support the particular Class-Type, must reject the label request by sending upstream a Notification message which includes the Status TLV with a Status Code of 'Unsupported Class-Type'. This is defined below in section 5.4. An LSR receiving a Label Request message with the Class Type TLV, which recognizes the Class Type TLV but determines that the Class- Type value is not valid (i.e. Class-Type value 0), must reject the label request by sending upstream a Notification message which includes the Status TLV with a Status Code of 'Invalid Class-Type value'. This is defined below in section 5.4. An LSR MUST handle the situations where the LSP can not be accepted for other reasons than those already discussed in this section, in accordance with [CR-LDP], [LDP] and [DIFF-MPLS] (e.g. reservation rejected by admission control, a label can not be associated). 12.4. Status Code Values for Diff-Serv TE Le Faucheur et. al 25 Protocols for Diff-Serv-aware TE July 2001 In the procedures described above, certain errors must be reported. The following values are defined for the Status Code field of the Status TLV: Status Code E Status Data Unexpected Class Type TLV 0 TBD Unsupported Class-Type 0 TBD Invalid Class-Type value 0 TBD Le Faucheur et. al 26 Protocols for Diff-Serv-aware TE July 2001 Appendix C - Addressing [DSTE-REQ] Scenarios This Appendix provides examples of how the DS-TE solution can be used to support each of the scenario described in [DSTE-REQ]. Scenario 1: High Proportion of Voice By configuring on every link: - Max Reservable Bandwidth for CT1/Voice = "certain percentage" of link capacity - Max Reservable Bandwidth for CT0+CT1(+CT2+CT3)= link capacity By configuring: - every CT1/Voice TE-LSP with preemption =0 - every CT0/Voice TE-LSP with preemption =1 The proposed solution will address all the requirements: - amount of Voice traffic limited to desired percentage on every link - data traffic capable of using all remaining link capacity - voice traffic capable of preempting other traffic Scenario 2: Rerouting on Lower Speed Facilities Using same configuration as for previous scenario, would ensure that the amount of Voice traffic remains limited below desired percentage on every link even after rerouting on lower speed facilities. This in turn ensures QoS performance is preserved even after reroute on lower speed facilities. Scenario 3: By configuring on every link: - Max Reservable Bandwidth for CT2 = e.g. 45% - Max Reservable Bandwidth for CT1+CT2 = e.g. 80% - Max Reservable Bandwidth for CT0+CT1+CT2(+CT3)= e.g.100% The proposed DS-TE solution will ensure that the amount of traffic of each Class-Type established on a link is within acceptable levels as compared to the resources allocated to the corresponding Diff- Serv PHBs regardless of which order the LSPs are routed in, regardless of which preemption priorities are used by which LSPs and regardless of failure situations. Optional automatic adjustment of Diff-Sev scheduling configuration could be used for maintaining very strict relationship between amount of established traffic of each Class-Type and corresponding Diff-Serv resources. Le Faucheur et. al 27 Protocols for Diff-Serv-aware TE July 2001 Scenario 4: Guaranteed Bandwidth Services By using a separate Class-Type (e.g. CT1) for the Guaranteed Bandwidth traffic and by configuring on every link: - Max Reservable Bandwidth for CT1/guaranteed = "given percentage" of link capacity - Max Reservable Bandwidth for CT0+CT1(+CT2+CT3)= link capacity The Proposed solution will address the requirements: - the amount of guaranteed traffic wil always be below the given percentage necessary to meet the QoS objectives of the Guaranteed Bandwidth Service - rest of the traffic/CT0 will be able to use all remaining link capacity Le Faucheur et. al 28