Francois Le Faucheur, Editor Thomas Nadeau Cisco Systems, Inc. Jim Boyle PDNets Kireeti Kompella Juniper Networks William Townsend Tenor Networks Darek Skalecki Nortel Networks IETF Internet Draft Expires: May, 2002 Document: draft-lefaucheur-diff-te-proto-01.txt November, 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 Engineering" including the corresponding IGP and signaling Le Faucheur, et. al 1 Protocols for Diff-Serv-aware TE November 2001 extensions and procedures beyond those already specified for existing MPLS Traffic Engineering. This solution pulls together concepts from several earlier proposals ([PROTO],[NOP],[BW-ACCT]) into a single enhanced approach. 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. Introduction [DSTE-REQ] presents the Service Providers requirements for support of Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the fundamental requirement to be able to enforce different bandwidth constraints for different classes of traffic. This document describes: - a solution for addressing these requirements in environments relying on distributed Constraint Based Routing (i.e. path computation involving Head-end LSRs). This solution pulls together concepts from several earlier proposals ([PROTO],[NOP],[BW-ACCT]) into a single enhanced approach. - the corresponding IGP and procedures extensions beyond those already specified for existing MPLS Traffic Engineering [OSPF-TE][ISIS-TE]. - how the detailed requirements defined in [DSTE-REQ] are met - how the solution fares against the evaluation criteria also defined in [DSTE-REQ]. 2. Solution Overview 2.1. Traffic Trunks and Bandwidth Constraints For memory, [DSTE-REQ] allows each Head-end LSR to separate traffic to a given Tail-end into multiple Traffic Trunks. Each Traffic Trunk comprises traffic from one Diff-Serv Ordered Aggregate and is transported over a separate LSP. [DSTE-REQ] also defines a Class Type (CT) as "the set of Traffic Trunks which share the exact same Bandwidth Constraint, or set of Bandwidth Constraints, on all links, for the purpose of Constraint Based Routing and Admission Control". 2.2. Configurable Parameters 2.2.1. Preemption Priority In line with [DSTE-REQ], the preemption attribute defined in [TE- REQ] is retained for any DS-TE LSP. It is applicable across all Le Faucheur et. al 2 Protocols for Diff-Serv-aware TE November 2001 Class Types. The preemption attributes of setup priority and holding priority retain existing semantics, and in particular the preemption operates independently of Ordered Aggregates or Class Types. This means that: if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher preemption priority (i.e. lower numerical priority value) regardless of LSP1's OA/CT and LSP2's OA/CT. In other words, the solution offers a total of eight(8) preemption priority levels to be used by an LSP that are completely orthogonal to that LSP's Ordered Aggregate and Class Type. What is new with this proposal (compared to existing TE) is that the LSPs with higher priorities may be limited in the amount of link resources they utilize through the different Bandwidth Constraints applied to the Class-Types. This may be to meet QoS objectives of the corresponding Traffic Trunks or to prevent starvation of Traffic Trunks at lower priorities. As per existing TE, this DS-TE solution assumes that every DS-TE LSP be configured with a setup and holding priority, each with a value between 0 and 7. For illustrative purposes, we now present three examples. First, a Service Provider using two Class Types (one for Voice and one for Data), may elect to configure the following to ensure that Voice LSPs are never driven away from their shortest path because of Data LSPs: - all Voice LSPs to preemption priority 0 - all Data LSPs to preemption priority 1. As an example, a new Voice LSP would then be able to preempt an existing Data LSP in case they contend for resources. Another Service Provider may elect to configure the following in order to optimize global network resource utilization by favoring placement of large LSPs first: - all large size Voice 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. As an example, a new large size Data LSP would then be able to preempt a small size Data LSP or a small size Voice LSP in case they contend for resources, but it would not be able to preempt a large size Voice LSP. Yet another Service Provider may elect to configure the following in order to ensure that Voice LSPs are never driven away from their shortest path because of Data LSPs while also achieving some optimization of global network resource utilization by favoring placement of large LSPs first: - all large size Voice LSPs to preemption priority 0 Le Faucheur et. al 3 Protocols for Diff-Serv-aware TE November 2001 - all small size Voice LSPs to preemption priority 1 - all large size Data LSPs to preemption priority 2 - all small size Data LSPs to preemption priority 3. As an example, a new large size Data LSP would then be able to preempt a small size Data LSP in case they contend for resources, but it would not be able to preempt any Voice LSP. 2.2.2. Preemption/CT Mapping This DS-TE solution supports, on every LSR, a configurable Preemption/CT Mapping where every setup preemption priority is allocated for use by one CT. A CT may use one or more preemption priorities. Each preemption priority is only used by a single CT, however. The Preemption/CT Mapping must be configured consistently on all the LSRs within the DS-TE domain. This mapping is referred to as CT[i] = CTj where: - i identifies the preemption priority level, 0 <= i <= 7 - j identifies the CT, 0 <= j <= 7 As an example of preemption/CT mapping consider the following. A Service Provider using 3 CTs (CT0, CT1 and CT2) may configure: - CT[0]=CT2 (preemption priority 0 will be used by CT2) - CT[2]=CT1 (preemption priority 2 will be used by CT1) - CT[3]=CT2 (preemption priority 3 will be used by CT2) - CT[6]=CT0 (preemption priority 6 will be used by CT0) Preemption priorities 1, 4, 5 and 7 would then be currently unused. Note that since every DS-TE LSP is configured with a preemption priority and since a preemption/CT mapping is configured on the LSR, every DS-TE LSP is thus unambiguously associated with a CT, which determines which Bandwidth Constraint(s) are applicable to that LSP's Traffic Trunk. For example a network administrator may configure : - CT[0]=CT1 (preemption priority 0 will be used by CT1) - CT[1]=CT0 (preemption priority 1 will be used by CT0) - CT[2]=CT0 (preemption priority 2 will be used by CT0) - all the TE tunnels used for EF are granted preemption priority 0 - all the TE Tunnels used for AF1 are granted preemption priority 1 - all the TE Tunnels used for AF2 are granted preemption priority 2 Le Faucheur et. al 4 Protocols for Diff-Serv-aware TE November 2001 Then, all the EF TE Tunnels would be associated with CT1 while all the AF1 TE Tunnels and AF2 TE Tunnels would be associated with CT0. 2.2.3. Bandwidth Constraints [DSTE-REQ] introduces the concept of Bandwidth Constraint Model to characterize the Bandwidth Constraints associated with CTs, but it does not actually specify one particular Model. Although, the DS-TE solution defined in this document could be made to work with several Bandwidth Constraint Models, we specify its detailed operations assuming the "Russian Dolls" Bandwidth Constraints model. This will allow multiple implementations to achieve complete functional interoperability and ensure support of a consistent Bandwidth Constraint Model. The "Russian Doll" model of Bandwidth Constraints is defined in the following manner: - MaxBC= MaxCT - All LSPs supporting Traffic Trunks from CTc (with b<=c<=7) use no more than BCb. [Note: the above definition inverts the numbering order of CTs as compared to the one of [DSTE-REQ]. This is simply so that when less CTs are used than the possible maximum number, the active Bandwidth Constraints are naturally numbered starting from 0 rather than 7.] While we recognize that multiple Bandwidth Constraints models are conceivable and more flexible/sophisticated models can be conceived, the Russian Dolls model appear to us as an attractive trade-off and thus a useful base to start with, for the following reasons: - network administrators generally find it superior to the most simple model of a single BC per CT (which, in typical deployment scenario, results in either capacity wastage, low priority Traffic Trunk starvation and/or degradation of QoS objectives) - network administrators generally find it sufficient for their anticipated real life deployments (e.g. it addresses all the scenarios described in [DSTE-REQ]) - it remains simple and only requires very minor IGP extensions, while more sophisticated Bandwidth Constraints model may require additional IGP extensions and/or more complex procedures on LSRs. Operations of this DS-TE solution with other Bandwidth Constraints Model may be specified later if additional requirements emerge from Service Providers' real life deployment which cannot be addressed by the Russian Dolls model. With the solution described in this document, the existing "Maximum Reservable link bandwidth" parameter is retained but its semantic is generalized and interpreted as BC0. Additionally, on every link, this solution provides for configuration of up to 7 additional link parameters which are the Le Faucheur et. al 5 Protocols for Diff-Serv-aware TE November 2001 seven other potential Bandwidth Constraints i.e. BC1, BC2 , ... BC7. The LSR must ensure that BCi is configured smaller or equal to BCj, where i is greater than j. As an example of the "Russian Doll" Bandwidth Constraints Model, a network administrator using one CT for Voice and one CT for data might configure on a given link: - Existing Maximum Reservable Link Bandwidth (aka BC0) = 2.5 Gb/s (i.e. Voice + Data is limited to 2.5 Gb/s) - Bandwidth Constraint 1 (aka BC1)= 1.5 Gb/s (i.e. Voice is limited to 1.5 Gb/s). 2.2.4. per-CT Local Overbooking Multiplier This DS-TE solution enables a network administrator to apply different overbooking ratios for different CTs. The principal method to achieve this is the same as historically used in existing TE deployment which is to take into account the over-booking ratio appropriate for the OA/CT associated with the considered LSP at the time of establishing the bandwidth size of a given LSP. We refer to this as the "LSP size overbooking" method. Since the overbooking ratio is factored into the LSP bandwidth (which is invariable across all the links spanned by the LSP), using the "LSP size overbooking" method alone effectively has the following characteristics: - the overbooking ratio is the same on all links for a given OA/CT - the overbooking ratios could be fine-tuned on a per-LSP basis. The "LSP size overbooking" method is expected to be often sufficient in many DS-TE environments. However, in DS-TE environments where, for a given CT, the overbooking ratio needs to be tweaked differently on different links, the "LSP size overbooking" method can be complemented by the use of the "Local Overbooking" method. The "Local Overbooking" method relies on optional "per-CT Local Overbooking Multipliers" which are configurable, on every link, for every CT. The per-CT Local Overbooking Multiplier effectively allows the network operator to increase/decrease", on some links, the overbooking ratio already enforced by the "LSP size overbooking" method. This is achieved by applying the per-CT Local Overbooking Multiplier on all local bandwidth accounting computations for the purposes of admission control and IGP advertisement of Unreserved bandwidths. The optional per-CT Local Overbooking Multiplier are referred to as: LOM[i] Le Faucheur et. al 6 Protocols for Diff-Serv-aware TE November 2001 where i identifies the CT and where 0 <= i <= 3. 2.3. IGP Advertisement Existing IGP extensions for TE ([OSPF-TE], [ISIS-TE]) include the following sub-TLVs: - Maximum Reservable Bandwidth - Unreserved Bandwidth (at each of 8 preemption levels) 2.3.1. Bandwidth Constraints As detailed above in section 2.2.2, up to 8 Bandwidth Constraints ( BCb, 0 <= b <= 7) are configurable on any given link,: This solution proposes that the existing "Maximum Reservable Bw" sub-TLV be retained with a generalized semantic so that it is now interpreted as Bandwidth Constraint 0 (BC0). This solution also proposes that the following optional sub-TLV be defined to advertise the other seven potential Bandwidth Constraints: "Bandwidth Constraints" TBD - Bandwidth Constraints 0 (Nx4 octets) where N is the number of Bandwidth Constraints actually advertised in addition to BC0. For example, where a Service Provider only deploys DS-TE with two CTs, the "Bandwidth Constraints" sub-TLV may contain only one Bandwidth Constraints (BC1) in order to minimize the impact on IGP scalability. The use of this sub-TLV is optional. Its use may assist in head-end prediction of network response to LSP establishment or as a tie- breaker. 2.3.2. Unreserved Bandwidth This solution proposes that the existing "Unreserved Bandwidth" sub- TLV be retained as the only vehicle to advertise bandwidth information necessary for Constraint Based Routing on Head-ends, except that it be used with a generalized semantic. The Unreserved Bandwidth sub-TLV still carries one bandwidth value for each of the 8 preemption priorities. However, since the entries are now associated with different CT with different bandwidth constraints, no ordered relationship among these bandwidth values should be assumed. With existing TE, since all preemption priorities reflect the same (and only) bandwidth constraints, the following relationship is always true, and is often assumed by TE implementations: If p < q , then "Unreserved Bw [p]" >= "Unreserved Bw [q]" Le Faucheur et. al 7 Protocols for Diff-Serv-aware TE November 2001 With the DS-TE solution proposed, this is no longer to be assumed. The value to be advertised by the IGP in "Unreserved Bw [p]" must reflect all of the Bandwidth Constraints relevant to the CT associated with the preemption priority p. For instance, assuming 4 CTs are used, if preemption priority p has been associated with CT2, "Unreserved Bw [p]" will reflect the following constraints: - CT2+CT3 must be less or equal to BC2 - CT1+CT2+CT3 must be less or equal to BC1 - CT0+CT1+CT2+CT3 must be less or equal to BC0. If preemption priority p has been associated with CT0, "Unreserved Bw [p]" will reflect the single following constraint: - CT0+CT1+CT2+CT3 must be less or equal to BC0 Appendix A discusses how the "Unreserved Bw [p]" may be computed. 2.3.3. Local Overbooking Multiplier This solution proposes that the following optional sub-TLV be defined: "Local Overbooking Multiplier" TBD - per-CT Local Overbooking Multipliers (N x 1 octet) where N is the number of per-CT Local Overbooking Multipliers actually advertised. For example, where a Service Provider only deploys DS-TE with two CTs, the "Local Overbooking Multiplier" sub- TLV may contain only LOM[0] and LOM[1] in order to minimize the impact on IGP scalability. The use of this sub-TLV is optional even when the optional LOMs are actually used. Its use may assist in head-end prediction of network response to LSP establishment. 2.4. LSP Signaling The setup preemption priority of an LSP is explicitly signaled in RSVP-TE [RSVP-TE] and CR-LDP [CR-LDP]. Thus, using the configured Preemption/CT Mapping defined above, an LSR can determine unambiguously the CT associated with an LSP in order to enforce the appropriate bandwidth constraint(s) for admission control. Consequently, no modification or extension is required on the Information Elements of RSVP-TE or CR-LDP. Changes are only required in the admission control procedures in order to enforce the appropriate bandwidth constraint(s) relevant to the LSP's CT. Admission control is discussed further in Appendix A. 2.5. Constraint Based Routing Le Faucheur et. al 8 Protocols for Diff-Serv-aware TE November 2001 Since the "Unreserved Bw [p]" advertised by the IGP factors in all the potential bandwidth constraints affecting the CT associated with preemption p, the Constraint Based Routing algorithm is only required to perform path computation satisfying a single bandwidth constraint. Thus, no changes are required to the existing TE Constraint Based Routing algorithm itself. The Constraint Based Routing algorithm may also optionally take into account, when used, the optional information advertised in IGP such as the Bandwidth Constraints affecting the CT using the considered preemption. As an example, this might be used as a tie-breaker criteria when multiple paths with equal metric are possible. 2.6. Diff-Serv scheduling The Class Type determined from the preemption priority signaled at LSP establishment can optionally be used by LSRs to dynamically adjust the resources allocated to the Class Type by the Diff-Serv scheduler. In addition, the Diff-Serv information (i.e. the PSC) signaled by the TE-LSP signaling protocols as specified in [DIFF- MPLS], if used, can optionally be used by LSRs to dynamically adjust the resources allocated to a PSC/OA within a Class Type by the Diff- Serv scheduler 3. Addressing DS-TE Detailed Requirements This DS-TE solution satisfy all of the DS-TE detailed requirements presented in [DSTE-REQ]. 4. Solution Evaluation 4.1. Satisfying Detailed Requirements This DS-TE Solution address all the scenarios presented in [DSTE- REQ] as explained in Appendix C. It also satisfy all the detailed requirements presented in [DSTE-REQ]. 4.2. Flexibility This DS-TE solution supports 8 CTs. It is entirely flexible as to how Traffic Trunks are grouped together into a CT. 4.3. Extendibility A maximum of 8 CTs is considered by the authors of this document as more than comfortable. However, this solution could be extended to support more CTs if deemed necessary in the future. However, this would necessitate additional IGP extensions beyond those specified in this document. Le Faucheur et. al 9 Protocols for Diff-Serv-aware TE November 2001 4.4. Scalability This DS-TE solution is expected to have a very small scalability impact compared to existing TE. From an IGP viewpoint, the only additional mandatory information to be advertised in IGP are the Bandwidth Constraints (beyond BC0). We expect no noticeable impact on LSP Path computation since, as with existing TE, this solution only require CSPF to consider a single unreserved bandwidth value for any given LSP. From a signaling viewpoint we expect no significant impact due to this solution since it requires no extensions on the signaling protocol nor does it significantly increase the likelihood of CAC rejection. Note that DS-TE has some inherent impact on LSP signaling in the sense that it assumes that different classes of traffic are split over different LSPs so that more LSPs need to be signaled; but this is due to the DS-TE concept itself and not to the actual DS-TE solution discussed here. 4.5. Backward Compatibility/Migration This solution is expected to allow smooth migration from existing TE to DS-TE as well as when increasing the number of CTs actually deployed. Migration scenarios and associated operational procedures will be detailed in subsequent versions of this document. 5. 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. 6. Acknowledgments This document borrows concepts from an earlier solution proposal into which Martin Tatham, Angela Chiu and Pete Hicks had significant contributions. References [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts- 02.txt, November 2001. Le Faucheur et. al 10 Protocols for Diff-Serv-aware TE November 2001 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-katz-yeung-ospf-traffic-06.txt, October 2001. [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- ietf-isis-traffic-04.txt, October 2001. [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-09.txt, August 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 [DSTE-NOP] Boyle, "Accomplishing Diffserv TE needs with Current Specifications", draft-boyle-tewg-ds-nop-00.txt, July 2001. [BW-ACCT] Kompella, Bandwidth Accounting for Traffic Engineering, 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 Jim Boyle Protocol Driven Networks 1381 Kildaire Farm Road #288 Cary, NC 27511 Phone: +1 919 852-5160 Email: jboyle@pdnets.com Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94099 Email: kireeti@juniper.net William Townsend Tenor Networks 100 Nagog Park Acton, MA 01720 Phone: +1-978-264-4900 Email: btownsend@tenornetworks.com Le Faucheur et. al 11 Protocols for Diff-Serv-aware TE November 2001 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 Le Faucheur et. al 12 Protocols for Diff-Serv-aware TE November 2001 Appendix A - Computing "Unreserved Bw [p]" This Appendix discusses how the "unreserved bandwidth for [p]" may be computed for IGP advertisment as well as for local admission control of DS-TE LSPs by LSRs. We first observe that details on admission control algorithms for TE LSPs are outside the scope of the current IETF work. This is left for vendor differentiation. Note that this does not compromise interoperability across various implementations since the TE schemes rely on LSRs to advertise their local view of the world in terms of Unreserved Bw to other LSRs. This way, regardless of the actual local admission control algorithm used on one given LSR, Constraint Based Routing on other LSRs can rely on advertised information to determine whether an additional LSP will be accepted or rejected by the given LSR. The only requirement is that an LSR advertises unreserved bandwidth values which are consistent with its specific local admission control algorithm. In the context of DS-TE, again, details on admission control algorithms are left for vendor differentiation and formulas for computing "Unreserved Bw [p]" are outside the scope of this specification. However, DS-TE places the additional requirement on the LSR that the unreserved bandwidth values advertised must reflect all of the Bandwidth Constraints relevant to the CT associated with each preemption priority, as discussed in section 2.3.2. A.1 Admission Control Rules Regardless of how the admission control algorithm actually computes "Unreserved Bw [p]" for one of its local link, an LSP of bandwidth B and preemption priority p is admissible on that link iff: B <= Unreserved Bw [p] A.2 Example Formulas for Computing "Unreserved Bw [p]" Keeping in mind that exact formulas for computing "Unreserved Bw [p]" are outside the scope of this specification, we provide below, for illustration purposes, an example of how "Unreserved Bw [p]" might be computed assuming: - The Russian Doll Bandwidth Constraints Model is used - the very simple admission control algorithm which simply deducts the exact bandwidth of any established LSP from all of the Bandwidth Constraints relevant to the CT associated with that LSP's preemption. - The optional per-CT Local Overbooking Multipliers are not used (.i.e. LOM[i]=1, 0<= i <=3). - Only 4 CTs are used (although the formulas below can be extended trivially to cover more CTs). If preemption p is used by CT0, then "Unreserved Bw [p]" = Le Faucheur et. al 13 Protocols for Diff-Serv-aware TE November 2001 [ BC0 - SUM (reserved [q]) ] for q <=p AND q used by CT0, CT1, CT2 or CT3 If preemption p is used by CT1, then "Unreserved Bw [p]" = MIN [ [ BC1 - SUM (reserved [q]) ] for q <=p AND q used by CT1, CT2 or CT3, [ BC0 - SUM (reserved [q]) ] for q <=p AND q used by CT0, CT1, CT2 or CT3, ] If preemption p is used by CT2, then "Unreserved Bw [p]" = MIN [ [ BC2 - SUM (reserved [q]) ] for q <=p AND q used by CT2 or CT3, [ BC1 - SUM (reserved [q]) ] for q <=p AND q used by CT1, CT2 or CT3, [ BC0 - SUM (reserved [q]) ] for q <=p AND q used by CT0, CT1, CT2 or CT3, ] If preemption p is used by CT3, then "Unreserved Bw [p]" = MIN [ [ BC3 - SUM (reserved [q]) ] for q <=p AND q used by CT3, [ BC2 - SUM (reserved [q]) ] for q <=p AND q used by CT2 or CT3, [ BC1 - SUM (reserved [q]) ] for q <=p AND q used by CT1, CT2 or CT3, [ BC0 - SUM (reserved [q]) ] for q <=p AND q used by CT0, CT1, CT2 or CT3, ] Appendix B - Prediction for Multiple Path Computation There are situations where a Head-End needs to compute paths for multiple LSPs. There are potential advantages for the Head-end in trying to predict the impact of the n-th LSP on the unreserved bandwidth when computing the path for the (n+1)-th LSP, before receiving updated IGP information. One example would be to perform better load-distribution of the multiple LSPs across multiple paths. Another example would be to avoid CAC rejection when the (n+1)-th LSP would no longer fit on a link after establishment of the n-th LSP.While there are also a number of conceivable scenarios where doing such predictions might result in a worse situation, it is more likely to improve the situation. As a matter of fact, a number of network administrators have elected to use such predictions when deploying existing TE. Such predictions are local matters, are optional and are outside the scope of this specification. Le Faucheur et. al 14 Protocols for Diff-Serv-aware TE November 2001 Where such predictions are not used, the optional Bandwidth Constraint sub-TLV and the optional Local Overbooking Multiplier sub-TLV need not be advertised in IGP since the information contained in the Unreserved Bw sub-TLV is all that is required by Head-Ends to perform Constraint Based Routing. Where such predictions are used on Head-Ends, the optional Bandwidth Constraint sub-TLV and (if different overbooking ratios need to be supported on different links) the optional Local Overbooking Multiplier sub-TLV are likely to need to be advertised in IGP. This is in order for the Head-ends to predict as accurately as possible how an LSP affects unreserved bandwidth values for subsequent LSPs. Remembering that actual admission control algorithms are left for vendor differentiation, we observe that predictions may only be used effectively when the Head-end LSR predictions are based on the same (or a very close) admission control algorithm as used by other LSRs. 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]. C.1 Scenario 1: Limiting Amount of Voice By configuring on every link: - Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage" of link capacity - BC0= Max Reservable Link Bandwidth = link capacity By configuring: - every CT1/Voice TE-LSP with preemption =0 - every CT0/Data 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 C.2 Scenario 2: Maintain Relative Proportion of Traffic Classes By configuring on every link: - BC2 for CT2 = e.g. 45% - BC1 for CT1+CT2 = e.g. 80% - BC0 for CT0+CT1+CT2= 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 Le Faucheur et. al 15 Protocols for Diff-Serv-aware TE November 2001 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. C.3 Scenario 3: Guaranteed Bandwidth Services By configuring on every link: - BC1 for CT1 = "given" percentage of bandwidth (appropriate to achieve the Guaranteed Bandwidth service's QoS objectives) - BC0 for CT0+CT1 = 100% The proposed DS-TE solution will ensure that the amount of Guaranteed Bandwidth Trafic established on every link remains below the given percentage so that it will always meet its QoS objectives. AT the same time it will allow traffic engineering of the rest of the traffic such that links can be filled up. Le Faucheur et. al 16