GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4128

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
  1. allows greater sharing of bandwidth among different classes
  1. performs somewhat better under normal conditions
  1. works well when preemption is fully enabled; under partial

preemption, not all preemption modes work equally well

 MAM
  1. does not depend on the use of preemption
  1. is relatively insensitive to the different preemption modes when

preemption is used

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4128.txt · Last modified: 2005/06/22 16:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki