diff options
Diffstat (limited to 'doc/rfc/rfc4128.txt')
| -rw-r--r-- | doc/rfc/rfc4128.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4128.txt b/doc/rfc/rfc4128.txt new file mode 100644 index 0000000..f44389b --- /dev/null +++ b/doc/rfc/rfc4128.txt @@ -0,0 +1,1403 @@ + + + + + + +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. + + + + + + +Lai Standards Track [Page 1] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + +Table of Contents + + 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 + + + + + + + + + + + + + + + + + + + + + + + + +Lai Standards Track [Page 2] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + +1. Introduction + + Differentiated Services (Diffserv)-aware MPLS Traffic Engineering + (DS-TE) mechanisms operate on the basis of different Diffserv classes + of traffic to improve network performance. Requirements for DS-TE + and the associated protocol extensions are specified in references + [1] and [2] 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 [1] 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]: + + (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 [1] for investigating the + performance and trade-offs of different operational aspects of BCMs: + + (1) addresses the scenarios in Section 2 of [1] + + (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 [3]. This document complements [1] 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 + + + +Lai Standards Track [Page 3] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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 [4], [5], [6], [7], and [8]. + + 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. + +1.1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +2. Bandwidth Constraints Models + + To simplify our presentation, we use the informal name "class of + traffic" for the terms Class-Type and TE-Class, defined in [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 [1] 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. + + + +Lai Standards Track [Page 4] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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 + +3. Performance Model + + Reference [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. + + + + + +Lai Standards Track [Page 5] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + The Markov-chain performance model in [8] 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 [8]. + + The model in [8] 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 [8]. 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). + +3.1. LSP Blocking and Preemption + + As described in 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 + + + +Lai Standards Track [Page 6] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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 [9].) + + 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. + + + + + + + + + + +Lai Standards Track [Page 7] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + +3.2. Example Link Traffic Model + + For example, consider a link with a capacity that allows a maximum of + 15 LSPs from different classes to be established simultaneously. All + LSPs are assumed to have an average lifetime of 1 time unit. Suppose + that this link is being offered a load of + + 2.7 erlangs from class 1, + 3.5 erlangs from class 2, and + 3.5 erlangs from class 3. + + We now consider a scenario wherein the blocking/preemption + performance objectives for the three classes are desired to be + comparable under normal conditions (other scenarios are covered in + later sections). To meet this service requirement under the above + given load, the BCs are selected as follows: + + For MAM: + + up to 6 simultaneous LSPs for class 1, + up to 7 simultaneous LSPs for class 2, and + up to 15 simultaneous LSPs for class 3. + + For RDM: + + up to 6 simultaneous LSPs for class 1 by itself, + up to 11 simultaneous LSPs for classes 1 and 2 together, and + up to 15 simultaneous LSPs for all three classes together. + + Note that the driver is service requirement, independent of BCM. The + above BCs are not picked arbitrarily; they are chosen to meet + specific performance objectives in terms of blocking/preemption + (detailed in the next section). + + An intuitive "explanation" for the above set of BCs may be as + follows. Class 1 BC is the same (6) for both models, as class 1 is + treated the same way under either model with preemption. However, + MAM and RDM operate in fundamentally different ways and give + different treatments to classes with lower preemption priorities. It + can be seen from 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. + + + + +Lai Standards Track [Page 8] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +3.3. Performance under Normal Load + + In the example above, based on the BCs chosen, the blocking and + preemption probabilities for LSP setup requests under normal + conditions for the two BCMs are given in Table 1. Remember that the + BCs have been selected for this scenario to address the service + requirement to offer comparable blocking/preemption objectives for + the three classes. + + Table 1. 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.02296 0.02402 0.01578 0.01611 0.03874 0.04013 + + In the above table, the following apply: + + PB1 = blocking probability of class 1 + PB2 = blocking probability of class 2 + PB3 = blocking probability of class 3 + + PP2 = preemption probability of class 2 + PP3 = preemption probability of class 3 + + PB2+PP2 = combined blocking/preemption probability of class 2 + PB3+PP3 = combined blocking/preemption probability of class 3 + + First, we observe that, indeed, the values for (PB1, PB2+PP2, + PB3+PP3) are very similar one to another. This confirms that the + service requirement (of comparable blocking/preemption objectives for + the three classes) has been met for both BCMs. + + + + + + +Lai Standards Track [Page 9] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +4. Performance under Overload + + Overload occurs when the traffic on a system is greater than the + traffic capacity of the system. To investigate the performance under + overload conditions, the load of each class is varied separately. + Blocking and preemption probabilities are not shown separately for + each case; they are added together to yield a combined + blocking/preemption probability. + +4.1. Bandwidth Sharing versus Isolation + + Figures 1 and 2 show the relative performance when the load of each + class in the example of Section 3.2 is varied separately. The three + series of data in each of these figures are, respectively, + + + + + + +Lai Standards Track [Page 10] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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 + + + +Lai Standards Track [Page 11] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +4.2. Improving Class 2 Performance at the Expense of Class 3 + + We now consider a scenario in which the service requirement is to + give better blocking/preemption performance to class 2 than to class + 3, while maintaining class 1 performance at the same level as in the + previous scenario. (The use of minimum deterministic guarantee for + class 3 is to be considered in the next section.) So that the + specified class 2 performance objective can be met, class 2 BC is + increased appropriately. As an example, BCs (6, 9, 15) are now used + for MAM, and (6, 13, 15) for RDM. For both BCMs, as shown in Figures + 1bis and 2bis, although class 1 performance remains unchanged, class + 2 now receives better performance, at the expense of class 3. This is + of course due to the increased access of bandwidth by class 2 over + class 3. Under normal conditions, the performance of the two BCMs is + similar in terms of their blocking and preemption probabilities for + LSP setup requests, as shown in Table 2. + + Table 2. Blocking and preemption probabilities + + BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3 + + MAM 0.03692 0.00658 0.02733 0 0.02709 0.00658 0.05441 + RDM 0.03692 0.00449 0.02759 0.00272 0.02436 0.00721 0.05195 + + Under overload, the observations in 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 + + + +Lai Standards Track [Page 12] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +4.3. Comparing Bandwidth Constraints of Different Models + + As is pointed out in 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 + + + +Lai Standards Track [Page 13] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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). + + + + + +Lai Standards Track [Page 14] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +5. Performance under Partial Preemption + + In the previous two sections, preemption is fully enabled in the + sense that class 1 can preempt class 3 or class 2 (in that order), + and class 2 can preempt class 3. That is, both classes 1 and 2 are + preemptor-enabled, whereas classes 2 and 3 are preemptable. A class + that is preemptor-enabled can preempt lower-priority classes + designated as preemptable. A class not designated as preemptable + cannot be preempted by any other classes, regardless of relative + priorities. + + We now consider the three cases shown in Table 5, in which preemption + is only partially enabled. + + Table 5. Partial preemption modes + + preemption modes preemptor-enabled preemptable + + "1+2 on 3" (Fig. 3, 6) class 1, class 2 class 3 + "1 on 3" (Fig. 4, 7) class 1 class 3 + "1 on 2+3" (Fig. 5, 8) class 1 class 3, class 2 + + In this section, we evaluate how these preemption modes affect the + performance of a particular BCM. Thus, we are comparing how a given + BCM performs when preemption is fully enabled versus how the same BCM + performs when preemption is partially enabled. The performance of + these preemption modes is shown in Figures 3 to 5 for RDM, and in + Figures 6 through 8 for MAM, respectively. In all of these figures, + + + +Lai Standards Track [Page 15] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +5.1. Russian Dolls Model + + Let us first examine the performance under RDM. There are two sets + of results, depending on whether class 2 is preemptable: (1) Figures + 3 and 4 for the two modes when only class 3 is preemptable, and (2) + Figure 2 in the previous section and Figure 5 for the two modes when + both classes 2 and 3 are preemptable. By comparing these two sets of + results, the following impacts can be observed. Specifically, when + class 2 is non-preemptable, the behavior of each class is as follows: + + 1. Class 1 generally sees a higher blocking probability. As the + class 1 space allocated by the class 1 BC is shared with class 2, + which is now non-preemptable, class 1 cannot reclaim any such + space occupied by class 2 when needed. Also, class 1 has less + opportunity to preempt, as it is able to preempt class 3 only. + + 2. Class 3 also sees higher blocking/preemption when its own load is + increased, as it is being preempted more frequently by class 1, + when class 1 cannot preempt class 2. (See the last set of four + points in the series for class 3 shown in Figures 3 and 4, when + comparing with Figures 2 and 5.) + + 3. Class 2 blocking/preemption is reduced even when its own load is + increased, since it is not being preempted by class 1. (See the + middle set of four points in the series for class 2 shown in + Figures 3 and 4, when comparing with Figures 2 and 5.) + + Another two sets of results are related to whether class 2 is + preemptor-enabled. In this case, when class 2 is not preemptor- + enabled, class 2 blocking/preemption is increased when class 3 load + is increased. (See the last set of four points in the series for + class 2 shown in Figures 4 and 5, when comparing with Figures 2 and + 3.) This is because both classes 2 and 3 are now competing + independently with each other for resources. + +5.2. Maximum Allocation Model + + Turning now to MAM, the significant impact appears to be only on + class 2, when it cannot preempt class 3, thereby causing its + blocking/preemption to increase in two situations. + + + + + + +Lai Standards Track [Page 16] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +6. Performance under Pure Blocking + + This section covers the case in which preemption is completely + disabled. We continue with the numerical example used in the + previous sections, with the same link capacity and offered load. + +6.1. Russian Dolls Model + + For RDM, we consider two different settings: + + "Russian Dolls (1)" BCs: + + up to 6 simultaneous LSPs for class 1 by itself, + up to 11 simultaneous LSPs for classes 1 and 2 together, and + up to 15 simultaneous LSPs for all three classes together. + + "Russian Dolls (2)" BCs: + + up to 9 simultaneous LSPs for class 3 by itself, + up to 14 simultaneous LSPs for classes 3 and 2 together, and + up to 15 simultaneous LSPs for all three classes together. + + Note that the "Russian Dolls (1)" set of BCs is the same as + previously with preemption enabled, whereas the "Russian Dolls (2)" + has the cascade of bandwidth arranged in reverse order of the + classes. + + + + + + +Lai Standards Track [Page 17] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +6.2. Maximum Allocation Model + + For MAM, we also consider two different settings: + + "Exp. Max. Alloc. (1)" BCs: + + up to 7 simultaneous LSPs for class 1, + up to 8 simultaneous LSPs for class 2, and + up to 8 simultaneous LSPs for class 3. + + "Exp. Max. Alloc. (2)" BCs: + + up to 7 simultaneous LSPs for class 1, with additional bandwidth for + 1 LSP privately reserved + up to 8 simultaneous LSPs for class 2, and + up to 8 simultaneous LSPs for class 3. + + These BCs are chosen so that, under normal conditions, the blocking + performance is similar to all the previous scenarios. The only + difference between these two sets of values is that the "Exp. Max. + Alloc. (2)" algorithm gives class 1 a private pool of 1 server for + class protection. As a result, class 1 has a relatively lower + blocking especially when its traffic is above normal, as can be seen + by comparing Figures 11 and 12. This comes, of course, with a slight + increase in the blocking of classes 2 and 3 traffic. + + When comparing the "Russian Dolls (2)" in Figure 10 with MAM in + Figures 11 or 12, the difference between their behavior and the + associated explanation are again similar to the case when preemption + is used. The higher degree of sharing in the cascaded bandwidth + arrangement of RDM leads to a tighter coupling between the different + classes of traffic when under overload. Their performance therefore + + + +Lai Standards Track [Page 18] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +7. Performance under Complete Sharing + + As observed towards the end of 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 + + + +Lai Standards Track [Page 19] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +8. Implications on Performance Criteria + + Based on the previous results, a general theme is shown to be the + trade-off between bandwidth sharing and class protection/isolation. + To show this more concretely, let us compare the different BCMs in + terms of the overall loss probability. This quantity is defined as + the long-term proportion of LSP requests from all classes combined + that are lost as a result of either blocking or preemption, for a + given level of offered load. + + As noted in the previous sections, although RDM has a higher degree + of sharing than MAM, both ultimately converge to the Complete Sharing + Model as the degree of sharing in each of them is increased. Figure + 14 shows that, for a single link, the overall loss probability is the + smallest under Complete Sharing and the largest under MAM, with that + under RDM being intermediate. Expressed differently, Complete + Sharing yields the highest link efficiency and MAM the lowest. As a + matter of fact, the overall loss probability of Complete Sharing is + identical to the loss probability of a single class as computed by + the Erlang loss formula. Yet Complete Sharing has the poorest class + protection capability. (Note that, in a network with many links and + multiple-link routing paths, analysis in [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 + + + +Lai Standards Track [Page 20] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + 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. + +9. Conclusions + + BCMs are used in DS-TE for path computation and admission control of + LSPs by enforcing different BCs for different classes of traffic so + that Diffserv QoS performance can be maximized. Therefore, it is of + interest to measure the performance of a BCM by the LSP + blocking/preemption probabilities under various operational + conditions. Based on this, the performance of RDM and MAM for LSP + establishment has been analyzed and compared. In particular, three + different scenarios have been examined: (1) all three classes have + comparable performance objectives in terms of LSP blocking/preemption + under normal conditions, (2) class 2 is given better performance at + the expense of class 3, and (3) class 3 receives some minimum + deterministic guarantee. + + A general theme is the trade-off between bandwidth sharing to achieve + greater efficiency under normal conditions, and to achieve robust + class protection/isolation under overload. The general properties of + the two BCMs are as follows: + + RDM + + - allows greater sharing of bandwidth among different classes + + - performs somewhat better under normal conditions + + - works well when preemption is fully enabled; under partial + preemption, not all preemption modes work equally well + + MAM + + - does not depend on the use of preemption + + - is relatively insensitive to the different preemption modes when + preemption is used + + - provides more robust class isolation under overload + + Generally, the use of preemption gives higher-priority traffic some + degree of immunity to the overloading of other classes. This results + in a higher blocking/preemption for the overloaded class than that in + a pure blocking environment. + + + + + +Lai Standards Track [Page 21] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + +10. Security Considerations + + This document does not introduce additional security threats beyond + those described for Diffserv [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 [10], 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 [11], 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. + +11. Acknowledgements + + Inputs from Jerry Ash, Jim Boyle, Anna Charny, Sanjaya Choudhury, + Dimitry Haskin, Francois Le Faucheur, Vishal Sharma, and Jing Shen + are much appreciated. + +12. References + +12.1. Normative References + + [1] Le Faucheur, F. and W. Lai, "Requirements for Support of + Differentiated Services-aware MPLS Traffic Engineering", RFC + 3564, July 2003. + +12.2. Informative References + + [2] Le Faucheur, F., Ed., "Protocol Extensions for Support of + Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. + + [3] 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. + + + + + +Lai Standards Track [Page 22] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + + [4] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth + Constraints Model for Diffserv-aware MPLS Traffic Engineering", + RFC 4125, June 2005. + + [5] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model + for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June + 2005. + + [6] Ash, J., "Max Allocation with Reservation Bandwidth Constraint + Model for MPLS/DiffServ TE & Performance Comparisons", RFC 4126, + June 2005. + + [7] F. Le Faucheur, "Considerations on Bandwidth Constraints Models + for DS-TE", Work in Progress. + + [8] 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. + + [9] 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. + + [10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. + Weiss, "An Architecture for Differentiated Service", RFC 2475, + December 1998. + + [11] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. + McManus, "Requirements for Traffic Engineering Over MPLS", RFC + 2702, September 1999. + + [12] 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. + + [13] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) + Extensions to OSPF Version 2", RFC 3630, September 2003. + + [14] Smit, H. and T. Li, "Intermediate System to Intermediate System + (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June + 2004. + + + + + + + + +Lai Standards Track [Page 23] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + +Author's Address + + Wai Sum Lai + AT&T Labs + Room D5-3D18 + 200 Laurel Avenue + Middletown, NJ 07748 + USA + + Phone: +1 732-420-3712 + EMail: wlai@att.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lai Standards Track [Page 24] + +RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005 + + +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- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Lai Standards Track [Page 25] + |