Network Working Group W. Lai Request for Comments: 4128 AT&T Labs Category: Informational June 2005 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). IESG Note The content of this RFC has been considered by the IETF (specifically in the TE-WG working group, which has no problem with publication as an Informational RFC), and therefore it may resemble a current IETF work in progress or a published IETF work. However, this document is an individual submission and not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
Abstract"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.
1. Introduction ....................................................3 1.1. Conventions used in this document ..........................4 2. Bandwidth Constraints Models ....................................4 3. Performance Model ...............................................5 3.1. LSP Blocking and Preemption ................................6 3.2. Example Link Traffic Model .................................8 3.3. Performance under Normal Load ..............................9 4. Performance under Overload .....................................10 4.1. Bandwidth Sharing versus Isolation ........................10 4.2. Improving Class 2 Performance at the Expense of Class 3 ...12 4.3. Comparing Bandwidth Constraints of Different Models .......13 5. Performance under Partial Preemption ...........................15 5.1. Russian Dolls Model .......................................16 5.2. Maximum Allocation Model ..................................16 6. Performance under Pure Blocking ................................17 6.1. Russian Dolls Model .......................................17 6.2. Maximum Allocation Model ..................................18 7. Performance under Complete Sharing .............................19 8. Implications on Performance Criteria ...........................20 9. Conclusions ....................................................21 10. Security Considerations .......................................22 11. Acknowledgements ..............................................22 12. References ....................................................22 12.1. Normative References ....................................22 12.2. Informative References ..................................22
1] and  respectively. To achieve per-class traffic engineering, rather than on an aggregate basis across all classes, DS-TE enforces different Bandwidth Constraints (BCs) on different classes. Reference  specifies the requirements and selection criteria for Bandwidth Constraints Models (BCMs) for the purpose of allocating bandwidth to individual classes. This document presents a performance analysis for the two BCMs described in : (1) Maximum Allocation Model (MAM) - the maximum allowable bandwidth usage of each class, together with the aggregate usage across all classes, are explicitly specified. (2) Russian Dolls Model (RDM) - specification of maximum allowable usage is done cumulatively by grouping successive priority classes recursively. The following criteria are also listed in  for investigating the performance and trade-offs of different operational aspects of BCMs: (1) addresses the scenarios in Section 2 of  (2) works well under both normal and overload conditions (3) applies equally when preemption is either enabled or disabled (4) minimizes signaling load processing requirements (5) maximizes efficient use of the network (6) minimizes implementation and deployment complexity The use of any given BCM has significant impacts on the capability of a network to provide protection for different classes of traffic, particularly under high load, so that performance objectives can be met . This document complements  by presenting the results of a performance evaluation of the above two BCMs under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. Thus, our focus is only on the performance-oriented criteria and their
implications for a network implementation. In other words, we are only concerned with criteria (2), (3), and (5); we will not address criteria (1), (4), or (6). Related documents in this area include , , , , and . In the rest of this document, the following DS-TE acronyms are used: BC Bandwidth Constraint BCM Bandwidth Constraints Model MAM Maximum Allocation Model RDM Russian Dolls Model There may be differences between the quality of service expressed and obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE uses Constraint Based Routing, and because of the type of admission control capabilities it adds to Diffserv, DS-TE has capabilities for traffic that Diffserv does not. Diffserv does not indicate preemption, by intent, whereas DS-TE describes multiple levels of preemption for its Class-Types. Also, Diffserv does not support any means of explicitly controlling overbooking, while DS-TE allows this. When considering a complete quality of service environment, with Diffserv routers and DS-TE, it is important to consider these differences carefully. RFC 2119. 1]. We assume that (1) there are only three classes of traffic, and that (2) all label-switched paths (LSPs), regardless of class, require the same amount of bandwidth. Furthermore, the focus is on the bandwidth usage of an individual link with a given capacity; routing aspects of LSP setup are not considered. The concept of reserved bandwidth is also defined in  to account for the possible use of overbooking. Rather than get into these details, we assume that each LSP is allocated 1 unit of bandwidth on a given link after establishment. This allows us to express link bandwidth usage simply in terms of the number of simultaneously established LSPs. Link capacity can then be used as the aggregate constraint on bandwidth usage across all classes.
Suppose that the three classes of traffic assumed above for the purposes of this document are denoted by class 1 (highest priority), class 2, and class 3 (lowest priority). When preemption is enabled, these are the preemption priorities. To define a generic class of BCMs for the purpose of our analysis in accordance with the above assumptions, let Nmax = link capacity; i.e., the maximum number of simultaneously established LSPs for all classes together Nc = the number of simultaneously established class c LSPs, for c = 1, 2, and 3, respectively. For MAM, let Bc = maximum number of simultaneously established class c LSPs. Then, Bc is the Bandwidth Constraint for class c, and we have Nc <= Bc <= Nmax, for c = 1, 2, and 3 N1 + N2 + N3 <= Nmax B1 + B2 + B3 >= Nmax For RDM, the BCs are specified as: B1 = maximum number of simultaneously established class 1 LSPs B2 = maximum number of simultaneously established LSPs for classes 1 and 2 together B3 = maximum number of simultaneously established LSPs for classes 1, 2, and 3 together Then, we have the following relationships: N1 <= B1 N1 + N2 <= B2 N1 + N2 + N3 <= B3 B1 < B2 < B3 = Nmax 8] presents a 3-class Markov-chain performance model to analyze a general class of BCMs. The BCMs that can be analyzed include, besides MAM and RDM, BCMs with privately reserved bandwidth that cannot be preempted by other classes.
The Markov-chain performance model in  assumes Poisson arrivals for LSP requests with exponentially distributed lifetime. The Poisson assumption for LSP requests is relevant since we are not dealing with the arrivals of individual packets within an LSP. Also, LSP lifetime may exhibit heavy-tail characteristics. This effect should be accounted for when the performance of a particular BCM by itself is evaluated. As the effect would be common for all BCMs, we ignore it for simplicity in the comparative analysis of the relative performance of different BCMs. In principle, a suitably chosen hyperexponential distribution may be used to capture some aspects of heavy tail. However, this will significantly increase the complexity of the non-product-form preemption model in . The model in  assumes the use of admission control to allocate link bandwidth to LSPs of different classes in accordance with their respective BCs. Thus, the model accepts as input the link capacity and offered load from different classes. The blocking and preemption probabilities for different classes under different BCs are generated as output. Thus, from a service provider's perspective, given the desired level of blocking and preemption performance, the model can be used iteratively to determine the corresponding set of BCs. To understand the implications of using criteria (2), (3), and (5) in the Introduction Section to select a BCM, we present some numerical results of the analysis in . This is intended to facilitate discussion of the issues that can arise. The major performance objective is to achieve a balance between the need for bandwidth sharing (for increasing bandwidth efficiency) and the need for bandwidth isolation (for protecting bandwidth access by different classes). Section 2, the three classes of traffic used as an example are class 1 (highest priority), class 2, and class 3 (lowest priority). Preemption may or may not be used, and we will examine the performance of each scenario. When preemption is used, the priorities are the preemption priorities. We consider cross-class preemption only, with no within-class preemption. In other words, preemption is enabled so that, when necessary, class 1 can preempt class 3 or class 2 (in that order), and class 2 can preempt class 3. Each class offers a load of traffic to the network that is expressed in terms of the arrival rate of its LSP requests and the average lifetime of an LSP. A unit of such a load is an erlang. (In packet-based networks, traffic volume is usually measured by counting the number of bytes and/or packets that are sent or received over an interface during a measurement period. Here we are only concerned
with bandwidth allocation and usage at the LSP level. Therefore, as a measure of resource utilization in a link-speed independent manner, the erlang is an appropriate unit for our purpose .) To prevent Diffserv QoS degradation at the packet level, the expected number of established LSPs for a given class should be kept in line with the average service rate that the Diffserv scheduler can provide to that class. Because of the use of overbooking, the actual traffic carried by a link may be higher than expected, and hence QoS degradation may not be totally avoidable. However, the use of admission control at the LSP level helps minimize QoS degradation by enforcing the BCs established for the different classes, according to the rules of the BCM adopted. That is, the BCs are used to determine the number of LSPs that can be simultaneously established for different classes under various operational conditions. By controlling the number of LSPs admitted from different classes, this in turn ensures that the amount of traffic submitted to the Diffserv scheduler is compatible with the targeted packet-level QoS objectives. The performance of a BCM can therefore be measured by how well the given BCM handles the offered traffic, under normal or overload conditions, while maintaining packet-level service objectives. Thus, assuming that the enforcement of Diffserv QoS objectives by admission control is a given, the performance of a BCM can be expressed in terms of LSP blocking and preemption probabilities. Different BCMs have different strengths and weaknesses. Depending on the BCs chosen for a given load, a BCM may perform well in one operating region and poorly in another. Service providers are mainly concerned with the utility of a BCM to meet their operational needs. Regardless of which BCM is deployed, the foremost consideration is that the BCM works well under the engineered load, such as the ability to deliver service-level objectives for LSP blocking probabilities. It is also expected that the BCM handles overload "reasonably" well. Thus, for comparison, the common operating point we choose for BCMs is that they meet specified performance objectives in terms of blocking/preemption under given normal load. We then observe how their performance varies under overload. More will be said about this aspect later in Section 4.2.
Section 2 that although RDM imposes a strict ordering of the different BCs (B1 < B2 < B3) and a hard boundary (B3 = Nmax), MAM uses a soft boundary (B1+B2+B3 >= Nmax) with no specific ordering. As will be explained in Section 4.3, this allows RDM to have a higher degree of sharing among different classes. Such a higher degree of coupling means that the numerical values of the BCs can be relatively smaller than those for MAM, to meet given performance requirements under normal load.
Thus, in the above example, the RDM BCs of (6, 11, 15) may be thought of as roughly corresponding to the MAM BCs of (6, 6+7, 6+7+15). (The intent here is just to point out that the design parameters for the two BCMs need to be different, as they operate differently; strictly speaking, the numerical correspondence is incorrect.) Of course, both BCMs are bounded by the same aggregate constraint of the link capacity (15). The BCs chosen in the above example are not intended to be regarded as typical values used by any service provider. They are used here mainly for illustrative purposes. The method we used for analysis can easily accommodate another set of parameter values as input.
Then, we observe that the (PB1, PB2+PP2, PB3+PP3) values for MAM are very similar to the (PB1, PB2+PP2, PB3+PP3) values for RDM. This indicates that, in this scenario, both BCMs offer very similar performance under normal load. From column 2 of Table 1, it can be seen that class 1 sees exactly the same blocking under both BCMs. This should be obvious since both allocate up to 6 simultaneous LSPs for use by class 1 only. Slightly better results are obtained from RDM, as shown by the last two columns in Table 1. This comes about because the cascaded bandwidth separation in RDM effectively gives class 3 some form of protection from being preempted by higher-priority classes. Also, note that PP2 is zero in this particular case, simply because the BCs for MAM happen to have been chosen in such a way that class 1 never has to preempt class 2 for any of the bandwidth that class 1 needs. (This is because class 1 can, in the worst case, get all the bandwidth it needs simply by preempting class 3 alone.) In general, this will not be the case. It is interesting to compare these results with those for the case of a single class. Based on the Erlang loss formula, a capacity of 15 servers can support an offered load of 10 erlangs with a blocking probability of 0.0364969. Whereas the total load for the 3-class BCM is less with 2.7 + 3.5 + 3.5 = 9.7 erlangs, the probabilities of blocking/preemption are higher. Thus, there is some loss of efficiency due to the link bandwidth being partitioned to accommodate for different traffic classes, thereby resulting in less sharing. This aspect will be examined in more detail later, in Section 7 on Complete Sharing. Section 3.2 is varied separately. The three series of data in each of these figures are, respectively,
class 1 blocking probability ("Class 1 B"), class 2 blocking/preemption probability ("Class 2 B+P"), and class 3 blocking/preemption probability ("Class 3 B+P"). For each of these series, the first set of four points is for the performance when class 1 load is increased from half of its normal load to twice its normal. Similarly, the next and the last sets of four points are when class 2 and class 3 loads are increased correspondingly. The following observations apply to both BCMs: 1. The performance of any class generally degrades as its load increases. 2. The performance of class 1 is not affected by any changes (increases or decreases) in either class 2 or class 3 traffic, because class 1 can always preempt others. 3. Similarly, the performance of class 2 is not affected by any changes in class 3 traffic. 4. Class 3 sees better (worse) than normal performance when either class 1 or class 2 traffic is below (above) normal. In contrast, the impact of the changes in class 1 traffic on class 2 performance is different for the two BCMs: It is negligible in MAM and significant in RDM. 1. Although class 2 sees little improvement (no improvement in this particular example) in performance when class 1 traffic is below normal when MAM is used, it sees better than normal performance under RDM. 2. Class 2 sees no degradation in performance when class 1 traffic is above normal when MAM is used. In this example, with BCs 6 + 7 < 15, class 1 and class 2 traffic is effectively being served by separate pools. Therefore, class 2 sees no preemption, and only class 3 is being preempted whenever necessary. This fact is confirmed by the Erlang loss formula: a load of 2.7 erlangs offered to 6 servers sees a 0.03692 blocking, and a load of 3.5 erlangs offered to 7 servers sees a 0.03961 blocking. These blocking probabilities are exactly the same as the corresponding entries in Table 1: PB1 and PB2 for MAM. 3. This is not the case in RDM. Here, the probability for class 2 to be preempted by class 1 is nonzero because of two effects. (1) Through the cascaded bandwidth arrangement, class 3 is protected
somewhat from preemption. (2) Class 2 traffic is sharing a BC with class 1. Consequently, class 2 suffers when class 1 traffic increases. Thus, it appears that although the cascaded bandwidth arrangement and the resulting bandwidth sharing makes RDM work better under normal conditions, such interaction makes it less effective to provide class isolation under overload conditions. Section 4.1 regarding the difference in the general behavior between the two BCMs still apply, as shown in Figures 1bis and 2bis. The following are two frequently asked questions about the operation of BCMs. (1) For a link capacity of 15, would a class 1 BC of 6 and a class 2 BC of 9 in MAM result in the possibility of a total lockout for class 3? This will certainly be the case when there are 6 class 1 and 9 class 2 LSPs being established simultaneously. Such an offered load (with 6 class 1 and 9 class 2 LSP requests) will not cause a lockout of class 3 with RDM having a BC of 13 for classes 1 and 2 combined, but
will result in class 2 LSPs being rejected. If class 2 traffic were considered relatively more important than class 3 traffic, then RDM would perform very poorly compared to MAM with BCs of (6, 9, 15). (2) Should MAM with BCs of (6, 7, 15) be used instead so as to make the performance of RDM look comparable? The answer is that the above scenario is not very realistic when the offered load is assumed to be (2.7, 3.5, 3.5) for the three classes, as stated in Section 3.2. Treating an overload of (6, 9, x) as a normal operating condition is incompatible with the engineering of BCs according to needed bandwidth from different classes. It would be rare for a given class to need so much more than its engineered bandwidth level. But if the class did, the expectation based on design and normal traffic fluctuations is that this class would quickly release unneeded bandwidth toward its engineered level, freeing up bandwidth for other classes. Service providers engineer their networks based on traffic projections to determine network configurations and needed capacity. All BCMs should be designed to operate under realistic network conditions. For any BCM to work properly, the selection of values for different BCs must therefore be based on the projected bandwidth needs of each class, as well as on the bandwidth allocation rules of the BCM itself. This is to ensure that the BCM works as expected under the intended design conditions. In operation, the actual load may well turn out to be different from that of the design. Thus, an assessment of the performance of a BCM under overload is essential to see how well the BCM can cope with traffic surges or network failures. Reflecting this view, the basis for comparison of two BCMs is that they meet the same or similar performance requirements under normal conditions, and how they withstand overload. In operational practice, load measurement and forecast would be useful to calibrate and fine-tune the BCs so that traffic from different classes could be redistributed accordingly. Dynamic adjustment of the Diffserv scheduler could also be used to minimize QoS degradation. Section 3.2, the higher degree of sharing among the different classes in RDM means that the numerical values of the BCs could be relatively smaller than those for MAM. We now examine this aspect in more detail by considering the following scenario. We set the BCs so that (1) for both BCMs, the same value is used for class 1, (2) the same minimum deterministic guarantee of bandwidth for class 3 is offered by both BCMs, and (3) the blocking/preemption
probability is minimized for class 2. We want to emphasize that this may not be the way service providers select BCs. It is done here to investigate the statistical behavior of such a deterministic mechanism. For illustration, we use BCs (6, 7, 15) for MAM, and (6, 13, 15) for RDM. In this case, both BCMs have 13 units of bandwidth for classes 1 and 2 together, and dedicate 2 units of bandwidth for use by class 3 only. The performance of the two BCMs under normal conditions is shown in Table 3. It is clear that MAM with (6, 7, 15) gives fairly comparable performance objectives across the three classes, whereas RDM with (6, 13, 15) strongly favors class 2 at the expense of class 3. They therefore cater to different service requirements. Table 3. Blocking and preemption probabilities BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3 MAM 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659 RDM 0.03692 0.00449 0.02759 0.00272 0.02436 0.00721 0.05195 By comparing Figures 1 and 2bis, it can be seen that, when being subjected to the same set of BCs, RDM gives class 2 much better performance than MAM, with class 3 being only slightly worse. This confirms the observation in Section 3.2 that, when the same service requirements under normal conditions are to be met, the numerical values of the BCs for RDM can be relatively smaller than those for MAM. This should not be surprising in view of the hard boundary (B3 = Nmax) in RDM versus the soft boundary (B1+B2+B3 >= Nmax) in MAM. The strict ordering of BCs (B1 < B2 < B3) gives RDM the advantage of a higher degree of sharing among the different classes; i.e., the ability to reallocate the unused bandwidth of higher-priority classes to lower-priority ones, if needed. Consequently, this leads to better performance when an identical set of BCs is used as exemplified above. Such a higher degree of sharing may necessitate the use of minimum deterministic bandwidth guarantee to offer some protection for lower-priority traffic from preemption. The explicit lack of ordering of BCs in MAM and its soft boundary imply that the use of minimum deterministic guarantees for lower- priority classes may not need to be enforced when there is a lesser degree of sharing. This is demonstrated by the example in Section 4.2 with BCs (6, 9, 15) for MAM. For illustration, Table 4 shows the performance under normal conditions of RDM with BCs (6, 15, 15).
Table 4. Blocking and preemption probabilities BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3 RDM 0.03692 0.00060 0.02800 0.00032 0.02740 0.00092 0.05540 Regardless of whether deterministic guarantees are used, both BCMs are bounded by the same aggregate constraint of the link capacity. Also, in both BCMs, bandwidth access guarantees are necessarily achieved statistically because of traffic fluctuations, as explained in Section 4.2. (As a result, service-level objectives are typically specified as monthly averages, under the use of statistical guarantees rather than deterministic guarantees.) Thus, given the fundamentally different operating principles of the two BCMs (ordering, hard versus soft boundary), the dimensions of one BCM should not be adopted to design for the other. Rather, it is the service requirements, and perhaps also the operational needs, of a service provider that should be used to drive how the BCs of a BCM are selected.
the BCs of Section 3.2 are used for illustration; i.e., (6, 7, 15) for MAM and (6, 11, 15) for RDM. However, the general behavior is similar when the BCs are changed to those in Sections 4.2 and 4.3; i.e., (6, 9, 15) and (6, 13, 15), respectively.
1. When class 1 load is increased. (See the first set of four points in the series for class 2 shown in Figures 7 and 8, when comparing with Figures 1 and 6.) 2. When class 3 load is increased. (See the last set of four points in the series for class 2 shown in Figures 7 and 8, when comparing with Figures 1 and 6.) This is similar to RDM; i.e., class 2 and class 3 are now competing with each other. When Figure 1 (for the case of fully enabled preemption) is compared to Figures 6 through 8 (for partially enabled preemption), it can be seen that the performance of MAM is relatively insensitive to the different preemption modes. This is because when each class has its own bandwidth access limits, the degree of interference among the different classes is reduced. This is in contrast with RDM, whose behavior is more dependent on the preemption mode in use.
As observed in Section 4, the cascaded bandwidth arrangement is intended to offer lower-priority traffic some protection from preemption by higher-priority traffic. This is to avoid starvation. In a pure blocking environment, such protection is no longer necessary. As depicted in Figure 9, it actually produces the opposite, undesirable effect: higher-priority traffic sees higher blocking than lower-priority traffic. With no preemption, higher- priority traffic should be protected instead to ensure that it could get through when under high load. Indeed, when the reverse cascade is used in "Russian Dolls (2)", the required performance of lower blocking for higher-priority traffic is achieved, as shown in Figure 10. In this specific example, there is very little difference among the performance of the three classes in the first eight data points for each of the three series. However, the BCs can be tuned to get a bigger differentiation.
tends to degrade together when the load of any one class is increased. By imposing explicit maximum bandwidth usage on each class individually, better class isolation is achieved. The trade- off is that, generally, blocking performance in MAM is somewhat higher than in RDM, because of reduced sharing. The difference in the behavior of RDM with or without preemption has already been discussed at the beginning of this section. For MAM, some notable differences can also be observed from a comparison of Figures 1 and 11. If preemption is used, higher-priority traffic tends to be able to maintain its performance despite the overloading of other classes. This is not so if preemption is not allowed. The trade-off is that, generally, the overloaded class sees a relatively higher blocking/preemption when preemption is enabled than there would be if preemption is disabled. Section 3, the partitioning of bandwidth capacity for access by different traffic classes tends to reduce the maximum link efficiency achievable. We now consider the case where there is no such partitioning, thereby resulting in full sharing of the total bandwidth among all the classes. This is referred to as the Complete Sharing Model. For MAM, this means that the BCs are such that up to 15 simultaneous LSPs are allowed for any class. Similarly, for RDM, the BCs are up to 15 simultaneous LSPs for class 1 by itself, up to 15 simultaneous LSPs for classes 1 and 2 together, and up to 15 simultaneous LSPs for all three classes together. Effectively, there is now no distinction between MAM and RDM. Figure 13 shows the performance when all classes have equal access to link bandwidth under Complete Sharing. With preemption being fully enabled, class 1 sees virtually no blocking, regardless of the loading conditions of the link. Since class 2 can only preempt class 3, class 2 sees some blocking and/or preemption when either class 1 load or its own load is above normal; otherwise, class 2 is unaffected by increases of class 3 load. As higher priority classes always preempt class 3 when the link is full, class 3 suffers the most, with high blocking/preemption when there is any load increase from any class. A comparison of Figures 1, 2, and 13 shows that, although the performance of both classes 1 and 2 is far superior under Complete Sharing, class 3 performance is much
better off under either MAM or RDM. In a sense, class 3 is starved under overload as no protection of its traffic is being provided under Complete Sharing. 6] showed that Complete Sharing does not necessarily lead to maximum network-wide bandwidth efficiency.) Increasing the degree of bandwidth sharing among the different traffic classes helps increase link efficiency. Such increase, however, will lead to a tighter coupling between different classes. Under normal loading conditions, proper dimensioning of the link so that there is adequate capacity for each class can minimize the effect of such coupling. Under overload conditions, when there is a scarcity of capacity, such coupling will be unavoidable and can cause severe degradation of service to the lower-priority classes. Thus, the objective of maximizing link usage as stated in criterion (5) of Section 1 must be exercised with care, with due consideration to the effect of interactions among the different classes. Otherwise, use of this criterion alone will lead to the selection of the Complete Sharing Model, as shown in Figure 14. The intention of criterion (2) in judging the effectiveness of different BCMs is to evaluate how they help the network achieve the expected performance. This can be expressed in terms of the blocking and/or preemption behavior as seen by different classes under various loading conditions. For example, the relative strength of a BCM can
be demonstrated by examining how many times the per-class blocking or preemption probability under overload is worse than the corresponding probability under normal load.
10] and MPLS Traffic Engineering [11, 12, 13, 14], and the same security measures and procedures described in those documents apply here. For example, the approach for defense against theft- and denial-of-service attacks discussed in , which consists of the combination of traffic conditioning at Diffserv boundary nodes along with security and integrity of the network infrastructure within a Diffserv domain, may be followed when DS-TE is in use. Also, as stated in , it is specifically important that manipulation of administratively configurable parameters (such as those related to DS-TE LSPs) be executed in a secure manner by authorized entities. For example, as preemption is an administratively configurable parameter, it is critical that its values be set properly throughout the network. Any misconfiguration in any label switch may cause new LSP setup requests either to be blocked or to unnecessarily preempt LSPs already established. Similarly, the preemption values of LSP setup requests must be configured properly; otherwise, they may affect the operation of existing LSPs.  Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.  Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.  Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
 Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.  Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.  Ash, J., "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", RFC 4126, June 2005.  F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress.  W.S. Lai, "Traffic Engineering for MPLS," Internet Performance and Control of Network Systems III Conference, SPIE Proceedings Vol. 4865, Boston, Massachusetts, USA, 30-31 July 2002, pp. 256-267.  W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP Networks," Internet Performance and Control of Network Systems II Conference, SPIE Proceedings Vol. 4523, Denver, Colorado, USA, 21-22 August 2001, pp. 359-367.  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.  Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.