RFC 4126

Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons

📅 published June 2005, from ietf

RFC 4126 (Part 1 of 5) 🦋

Network Working Group 💖 (the group that cooks these documents up)

Author: J. Ash of AT&T 🎀 Category: Experimental 🧪 (an experiment, not an official Internet standard!) Date: June 2005 📅 Obsoletes / Updates: the title block doesn't list either one 🌸

Okay bestie, the title is Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons ✨ It's a whole mouthful, but it basically means: here's a fancy new way to split up bandwidth on a network, and here's how it stacks up against the other ways. Main character energy 👑

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The authors want feedback and suggestions for improvement, and this memo can be distributed freely 💌

Copyright Notice 🌈

Abstract 💜

Okay so this doc is the sidekick to the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements doc 🫶 It gives a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model, which is a rulebook for bandwidth. It also walks through assumptions, where it fits, and examples of how it runs. Then it analyzes MAR against the criteria used to pick a Bandwidth Constraints Model, so people building it in their own networks get some guidance 🔥

Table of Contents 🍓

   1. Introduction ....................................................2
      1.1. Specification of Requirements ..............................3
   2. Definitions .....................................................3
   3. Assumptions & Applicability .....................................5
   4. Functional Specification of the MAR Bandwidth
      Constraints Model ...............................................6
   5. Setting Bandwidth Constraints ...................................7
   6. Example of MAR Operation ........................................8
   7. Summary .........................................................9
   8. Security Considerations ........................................10
   9. IANA Considerations ............................................10
   10. Acknowledgements ..............................................10
   A. MAR Operation & Performance Analysis  ..........................11
   B. Bandwidth Prediction for Path Computation ......................19
   Normative References ..............................................20
   Informative References ............................................20

1. Introduction ✨

Okay, the big picture 🧚 DS-TE requirements and protocol extensions are specified in [DSTE-REQ, DSTE-PROTO]. A big requirement for implementing DS-TE is having Bandwidth Constraints Models, which are the "rules" for handing out bandwidth to individual class types (CTs). CTs are groupings of service classes in DS-TE, and each one gets its own bandwidth allocation, priorities, and QoS objectives. Several CTs can share one common bandwidth pool on an integrated, multiservice MPLS/Diffserv network. Sharing is so iconic 💅

This doc is meant to complement the DS-TE requirements document [DSTE-REQ] by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. It shows examples of how MAR runs, analyzes MAR against the criteria for choosing a model, and gives implementers guidance for their networks 🦋

There are two other Bandwidth Constraints Models being specified for DS-TE too:

Maximum Allocation Model (MAM) [MAM]: the maximum allowable bandwidth usage of each CT is explicitly specified. 🎀
Russian Doll Model (RDM) [RDM]: the maximum allowable bandwidth usage is added up cumulatively by grouping successive CTs according to priority classes. 🪆

So MAR is kind of like MAM, because every CT still gets a maximum bandwidth allocation. The twist is that with bandwidth reservation and protection mechanisms, CTs are allowed to go over their allocations when there's no congestion 🙌 But when overload and congestion show up, they go right back to their allocated bandwidths. Very responsible of them, honestly 😭

Every Bandwidth Constraints Model should meet these objectives 🎯

It applies equally whether preemption is enabled or disabled. (When preemption is disabled, the model still works "reasonably" well.) 🌸
It has bandwidth efficiency, which means good bandwidth sharing among CTs under both normal and overload conditions. 🍓
It has bandwidth isolation, which means a CT cannot hog the bandwidth of another CT under overload conditions. No bandwidth hogs allowed 🚫💅
It protects against QoS degradation, at least for the high-priority CTs (for example, high-priority voice or high-priority data). 💖
It's reasonably simple, meaning it does not require additional IGP extensions and it minimizes signaling load processing requirements. 🧠

Appendix A has the modeling analysis, and it shows that the MAR Model meets all of these objectives 🔥 It also shows that MAR gives good network performance compared to MAM and full-sharing models, both under normal and abnormal operating conditions. The big takeaway is that MAR gets bandwidth efficiency, bandwidth isolation, and protection against QoS degradation all at once, without preemption. Iconic. 👑

Here's the roadmap 🗺️ Section 3 covers assumptions and applicability. Section 4 is the functional specification of the MAR Bandwidth Constraints Model. Section 5 has examples of how it operates. Appendix A analyzes MAR performance against the criteria for choosing a Bandwidth Constraints Model, to guide implementers in their networks. Appendix B talks about bandwidth prediction for path computation.

1.1. Specification of Requirements 📝

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 [RFC2119]. 🫶

2. Definitions 📖

For readability, a bunch of definitions from [DSTE-REQ, DSTE-PROTO] are repeated here, so you don't have to go hunting 🧚

Traffic Trunk: an aggregation of traffic flows of the same class (meaning they're treated equivalently from the DS-TE perspective), which is placed inside a Label Switched Path (LSP). 🎀

Class-Type (CT): the set of Traffic Trunks crossing a link that is governed by a specific set of bandwidth constraints. CT is used for link bandwidth allocation, constraint-based routing, and admission control. A given Traffic Trunk belongs to the same CT on all links. 🌈

Up to 8 CTs (MaxCT = 8) are supported. They are referred to as CTc, where 0 <= c <= MaxCT-1 = 7. Each CT is assigned either a Bandwidth Constraint, or a set of Bandwidth Constraints. Up to 8 Bandwidth Constraints (MaxBC = 8) are supported, and they are referred to as BCc, where 0 <= c <= MaxBC-1 = 7. 🔢

TE-Class: a pair of (a) a CT, and (b) a preemption priority allowed for that CT. This means an LSP transporting a Traffic Trunk from that CT can use that preemption priority as the set-up priority, the holding priority, or both. ⭐

MAX_RESERVABLE_BWk: the maximum reservable bandwidth on link k. It specifies the maximum bandwidth that may be reserved. This may be greater than the maximum link bandwidth, in which case the link may be oversubscribed [OSPF-TE]. 💫

BCck: the bandwidth constraint for CTc on link k, which equals the allocated (minimum guaranteed) bandwidth for CTc on link k (see Section 4). 🍓

RBW_THRESk: the reservation bandwidth threshold for link k (see Section 4). 🌸

RESERVED_BWck: the reserved bandwidth-in-progress on CTc on link k (0 <= c <= MaxCT-1). It equals the total amount of bandwidth reserved by all the established LSPs that belong to CTc. 💜

UNRESERVED_BWk: the unreserved link bandwidth on link k. It specifies the amount of bandwidth not yet reserved for any CT, calculated as:

UNRESERVED_BWk = MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <= c <= MaxCT-1)]

UNRESERVED_BWck: the unreserved link bandwidth on CTc on link k. It specifies the amount of bandwidth not yet reserved for CTc. It's calculated like this, where delta0/1(CTck) is 0 or 1 depending on whether the reserved amount has reached the constraint 🧮

UNRESERVED_BWck = UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk

delta0/1(CTck) = 0 if RESERVED_BWck < BCck
delta0/1(CTck) = 1 if RESERVED_BWck >= BCck

A number of recovery mechanisms under investigation in the IETF take advantage of sharing bandwidth across particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and the "Facility-based Computation Model" in [MPLS-BACKUP] are example mechanisms. They increase bandwidth efficiency by sharing bandwidth across backup LSPs that protect against independent failures 🛡️ To make sure the notion of RESERVED_BWck introduced in [DSTE-REQ] works with this kind of sharing across multiple LSPs, the wording of that definition in [DSTE-REQ] is generalized. With this generalization, the definition is compatible with Shared Mesh Restoration defined in [GMPLS-RECOV], so DS-TE and Shared Mesh Protection can operate at the same time. This assumes that Shared Mesh Restoration operates independently within each DS-TE Class-Type and does not operate across Class-Types. For example, backup LSPs protecting primary LSPs of CTc also need to belong to CTc, and excess traffic LSPs that share bandwidth with backup LSPs of CTc also need to belong to CTc. Everything stays in its own lane, bestie 🚗💨

3. Assumptions & Applicability ✨

okay so DS-TE is basically a bandwidth allocation mechanism 🎀 It splits bandwidth up for different classes of traffic, called CTs (class-types), like voice, normal data, and best-effort data. Network folks who handle capacity design, bandwidth allocation, routing design, and network planning usually base all of that on traffic-measured load and forecast [ASH1]. literally the vibe of planning ahead 🔮

So for MAR, we're assuming the following 💅

Connection admission control (CAC) allocates bandwidth for network flows/LSPs according to the traffic load assigned to each CT, based on traffic measurement and forecast.
CAC could allocate bandwidth per flow, per LSP, per traffic trunk, or otherwise. No specific CAC method is assumed. The only real requirement is that CT bandwidth allocation is related to measured or forecasted traffic load, per assumption #1.
CT bandwidth allocation gets adjusted up or down according to measured or forecast traffic load. No specific time period is assumed. It could be short term (seconds, minutes, hours), daily, weekly, monthly, or whatever works 🌸
Capacity management and CT bandwidth allocation thresholds (e.g., BCc) are designed according to traffic load, and are based on traffic measurement and forecast. Again, no specific time period is assumed for this adjustment. It could be short term (hours), daily, weekly, monthly, or otherwise.
No assumption is made on the order in which traffic is allocated to various CTs. Traffic allocation is assumed to be based only on traffic load as it is measured and/or forecast 📊
If link bandwidth is exhausted on a given path for a flow/LSP/traffic trunk, alternate paths may be attempted to satisfy CT bandwidth allocation. 🦋

Note that the above assumptions are not unique to MAR. They're generic, common assumptions for all BC Models, so everybody's in the same boat ⛵

4. Functional Specification of the MAR Bandwidth Constraints Model 💜

A DS-TE Label Switching Router (LSR) that implements MAR MUST support enforcement of bandwidth constraints, in compliance with the specifications in this section. This part is non-negotiable, bestie 🫶

In the MAR Bandwidth Constraints Model, the bandwidth allocation control for each CT is based on estimated bandwidth needs, bandwidth use, and status of links. The Label Edge Router (LER) makes the needed bandwidth allocation changes, and uses [RSVP-TE], for example, to determine if link bandwidth can be allocated to a CT. Bandwidth allocated to individual CTs is protected as needed, but otherwise it is shared. Under normal, non-congested network conditions, all CTs/services fully share all available bandwidth ✨ When congestion happens for a particular CTc, bandwidth reservation stops traffic from other CTs from seizing the allocated capacity for CTc. Protective 😤

On a given link k, a small amount of bandwidth RBW_THRESk (the reservation bandwidth threshold for link k) is reserved and governs the admission control on link k. Also associated with each CTc on link k are the allocated bandwidth constraints BCck, which govern bandwidth allocation and protection. The reservation bandwidth on a link (RBW_THRESk) can be accessed when a given CTc has bandwidth-in-use (RESERVED_BWck) below its allocated bandwidth constraint (BCck). However, if RESERVED_BWck exceeds its allocated bandwidth constraint (BCck), then the reservation bandwidth (RBW_THRESk) cannot be accessed. In this way, bandwidth can be fully shared among CTs if available, but is otherwise protected by bandwidth reservation methods. It's giving balance ⚖️

Bandwidth can be accessed for a bandwidth request = DBW for CTc on a given link k based on the following rules 📋

Table 1: Rules for Admitting LSP Bandwidth Request = DBW on Link k

For LSP on a high priority or normal priority CTc:

  If RESERVED_BWck <= BCck: admit if DBW <= UNRESERVED_BWk
  If RESERVED_BWck > BCck:  admit if DBW <= UNRESERVED_BWk - RBW_THRESk;

  or, equivalently:

  If DBW <= UNRESERVED_BWck, admit the LSP.

For LSP on a best-effort priority CTc:
  allocated bandwidth BCck = 0;
  Diffserv queuing admits BE packets only if there is available link
  bandwidth.

The normal semantics of setup and holding priority are applied in the MAR Bandwidth Constraints Model, and cross-CT preemption is permitted when preemption is enabled 🔥

The bandwidth allocation rules defined in Table 1 are illustrated with an example in Section 6 and simulation analysis in Appendix A 🎀

5. Setting Bandwidth Constraints 🍓

For a normal priority CTc, the bandwidth constraints BCck on link k are set by allocating the maximum reservable bandwidth (MAX_RESERVABLE_BWk) in proportion to the forecast or measured traffic load bandwidth (TRAF_LOAD_BWck) for CTc on link k. Here's the math 🧮

PROPORTIONAL_BWck = TRAF_LOAD_BWck/[sum {TRAF_LOAD_BWck, c=0, MaxCT-1}]
                    X MAX_RESERVABLE_BWk

For normal priority CTc:
BCck = PROPORTIONAL_BWck

For a high priority CT, the bandwidth constraint BCck is set to a multiple of the proportional bandwidth. That is:

For high priority CTc:
BCck = FACTOR X PROPORTIONAL_BWck

where FACTOR is set to a multiple of the proportional bandwidth (e.g., FACTOR = 2 or 3 is typical). This results in some "over-allocation" of the maximum reservable bandwidth, and gives priority to the high priority CTs 👑 Normally the bandwidth allocated to high priority CTs should be a relatively small fraction of the total link bandwidth, with a maximum of 10-15 percent being a reasonable guideline.

As stated in Section 4, the bandwidth allocated to a best-effort priority CTc should be set to zero. That is:

For best-effort priority CTc:
BCck = 0

6. Example of MAR Operation 🧚

In the example, assume there are three class-types: CT0, CT1, CT2. We consider a particular link with

MAX-RESERVABLE_BW = 100

And with the allocated bandwidth constraints set as follows:

BC0 = 30
BC1 = 20
BC2 = 20

These bandwidth constraints are based on the normal traffic loads, as discussed in Section 5. With MAR, any of the CTs is allowed to exceed its bandwidth constraint (BCc) as long as there are at least RBW_THRES (reservation bandwidth threshold on the link) units of spare bandwidth remaining. Let's assume

RBW_THRES = 10

So under overload, if

RESERVED_BW0 = 50
RESERVED_BW1 = 30
RESERVED_BW2 = 10

Therefore, for this loading

UNRESERVED_BW = 100 - 50 - 30 - 10 = 10

CT0 and CT1 can no longer increase their bandwidth on the link, because they are above their BC values and there is only RBW_THRES=10 units of spare bandwidth left on the link. But CT2 can take the additional bandwidth (up to 10 units) if the demand arrives, because it is below its BC value 🥺

As also discussed in Section 4, if best effort traffic is present, it can always seize whatever spare bandwidth is available on the link at the moment, but it is subject to being lost at the queues in favor of the higher priority traffic.

Let's say an LSP arrives for CT0 needing 5 units of bandwidth (i.e., DBW = 5). We need to decide, based on Table 1, whether to admit this LSP or not. Since for CT0

RESERVED_BW0 > BC0 (50 > 30), and
DBW > UNRESERVED_BW - RBW_THRES (i.e., 5 > 10 - 10)

Table 1 says the LSP is rejected/blocked 🙅‍♀️

Now let's say an LSP arrives for CT2 needing 5 units of bandwidth (i.e., DBW = 5). We need to decide based on Table 1 whether to admit this LSP or not. Since for CT2

RESERVED_BW2 < BC2 (10 < 20), and
DBW < UNRESERVED_BW (i.e., 5 < 10)

Table 1 says to admit the LSP ✨

Hence, in the above example, in the current state of the link and in the current CT loading, CT0 and CT1 can no longer increase their bandwidth on the link, because they are above their BCc values and there is only RBW_THRES=10 units of spare bandwidth left on the link. But CT2 can take the additional bandwidth (up to 10 units) if the demand arrives, because it is below its BCc value. Main character energy for CT2 rn 👑

7. Summary 🌈

The proposed MAR Bandwidth Constraints Model includes the following:

allocation of bandwidth to individual CTs,
protection of allocated bandwidth by bandwidth reservation methods, as needed, but otherwise full sharing of bandwidth,
differentiation between high-priority, normal-priority, and best-effort priority services, and
provision of admission control to reject connection requests, when needed, in order to meet performance objectives.

The modeling results presented in Appendix A show that MAR bandwidth allocation achieves a) greater efficiency in bandwidth sharing while still providing bandwidth isolation and protection against QoS degradation, and b) service differentiation for high-priority, normal-priority, and best-effort priority services. Iconic results, honestly 💅

8. Security Considerations 🔐

Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. They apply independently of the Bandwidth Constraints Model, including the MAR specified in this document. Don't skip this part, bestie 💀

9. IANA Considerations 📝

[DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model Id". The guidelines for allocation of values in that name space are detailed in Section 13.1 of [DSTE-PROTO]. In accordance with these guidelines, the IANA has assigned a Bandwidth Constraints Model Id for MAR from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).

Bandwidth Constraints Model Id 2 was allocated by IANA to MAR 🎉

10. Acknowledgements 🫶

DS-TE and Bandwidth Constraints Models have been an active area of discussion in the TEWG. I would like to thank Wai Sum Lai for his support and review of this document. I also appreciate helpful discussions with Francois Le Faucheur. Thank you, legends 💖

Appendix A. MAR Operation & Performance Analysis 🦋

A.1. MAR Operation

Okay so in the MAR Bandwidth Constraints Model 💅, the bandwidth allocation control for each CT is based on estimated bandwidth needs, actual bandwidth use, and the status of the links 🔗. The LER makes the bandwidth allocation changes it needs, and it uses [RSVP-TE], for example, to check whether link bandwidth can be allocated to a CT. Bandwidth allocated to individual CTs is protected when needed, but otherwise it's shared 🫶. Under normal, non-congested conditions, all CTs/services fully share all the available bandwidth ✨. When congestion hits a particular CTc, bandwidth reservation kicks in to stop traffic from other CTs from seizing the capacity allocated to CTc 🛡️. Every CT has an allocated bandwidth constraint (BCc) that controls allocation and protection, and we'll walk through examples of these parameters in this Appendix 🎀.

In performing MAR bandwidth allocation for a given flow/LSP, the LER first figures out the egress LSR address, the service-identity, and the CT 🧭. The connection request gets an equivalent bandwidth so it can be routed on a particular CT. Then the LER looks at the CT priority, the QoS/traffic parameters, and the routing table between the LER and the egress LSR, and sets up the connection request using the MAR bandwidth allocation rules 💖. The LER picks a first-choice path and checks whether bandwidth can be allocated on that path using the MAR bandwidth allocation rules given in Section 4 🔍. If the first-choice path doesn't have enough bandwidth, the LER can try alternate paths, and it applies those same MAR bandwidth allocation rules again 🦋.

MAR bandwidth allocation happens on a per-CT basis, where the aggregated CT bandwidth is managed to meet the overall bandwidth requirements of the CT's service needs 📊. Individual flows/LSPs get bandwidth in their corresponding CT based on how much CT bandwidth is available 🌸. A core principle of MAR bandwidth allocation is using bandwidth reservation techniques 👑.

Bandwidth reservation gives preference to the preferred traffic by letting it grab idle bandwidth on a link more easily than non-preferred traffic 😭. Burke [BUR] was the first to analyze bandwidth reservation behavior, by solving the birth-death equations for the bandwidth reservation model 🧠. Burke's model showed the relative level of lost traffic for preferred traffic, which isn't subject to bandwidth reservation restrictions, compared with non-preferred traffic, which is subject to them. Bandwidth reservation protection is robust to traffic variations and gives significant dynamic protection to particular streams of traffic 💅. It's widely used in large-scale network applications [ASH1, MUM, AKI, KRU, NAK] 🌈.

Bandwidth reservation is what MAR uses to control how link bandwidth is shared across different CTs 🎀. On a given link, a small amount of bandwidth (RBW_THRES) is reserved (perhaps 1% of the total link bandwidth) ✨, and that reserved bandwidth can be accessed when a given CT's reserved bandwidth-in-progress (RESERVED_BW) is below its allocated bandwidth (BC). Here's the logic 🧩: if the available link bandwidth (the unreserved idle link bandwidth, UNRESERVED_BW) is more than RBW_THRES, then any CT is free to access the available bandwidth on the link. But if UNRESERVED_BW is less than RBW_THRES, then a CT can only use the available bandwidth if its current bandwidth usage is below its allocated amount (BC). So bandwidth can be fully shared among CTs when it's available, but it's protected by bandwidth reservation when it drops below the reservation level 🫧.

Through the bandwidth reservation mechanism, MAR bandwidth allocation also gives preference to high-priority CTs, compared with normal-priority and best-effort priority CTs 👑.

So, to sum it up 💖, bandwidth allocated to each CT is protected by bandwidth reservation methods when needed, and otherwise it's shared. Each LER monitors the CT bandwidth use on each CT and decides whether connection requests can be allocated to the CT bandwidth 👀. For example, for a bandwidth request of DBW on a given flow/LSP, the LER determines the CT priority (high, normal, or best-effort), the CT bandwidth-in-use, and the CT bandwidth allocation thresholds. It uses those parameters to work out the allowed load state threshold up to which capacity can be allocated 🍓. When allocating bandwidth DBW to a CT on a given LSP (say, A-B-E), each link in the path gets checked for available bandwidth against the allowed load state 🔎. If bandwidth is unavailable on any link in path A-B-E, another LSP could be tried, such as A-C-D-E 🛤️. That means figuring out the link load state is a must for MAR bandwidth allocation ⭐. Two link load states are distinguished: available (non-reserved) bandwidth (ABW_STATE) and reserved-bandwidth (RBW_STATE) 🌸. CT capacity management uses the link state and the allowed load state threshold together to decide whether a bandwidth allocation request can be accepted on a given CT 🫶.

A.2. Analysis of MAR Performance

In this Appendix we present modeling analysis showing that MAR bandwidth allocation delivers good network performance, compared with full sharing models, under both normal and abnormal operating conditions 🔥. The analysis uses a large-scale Diffserv-aware MPLS traffic engineering simulation model, where several CTs with different priority classes share the pool of bandwidth on a multiservice, integrated voice/data network 🎀. MAR methods have also been analyzed in practice for networks that use time division multiplexing (i.e., TDM-based networks) [ASH1], and in modeling studies for IP-based networks [ASH2, ASH3, E.360] 🌈.

All Bandwidth Constraints Models should meet these objectives 💅:

applies equally whether preemption is enabled or disabled (when preemption is disabled, the model still works 'reasonably' well) 💫,
bandwidth efficiency, i.e., good bandwidth sharing among CTs under both normal and overload conditions 🌟,
bandwidth isolation, i.e., a CT can't hog the bandwidth of another CT under overload conditions 🙅‍♀️,
protection against QoS degradation, at least for the high-priority CTs (e.g., high-priority voice, high-priority data, etc.) 🛡️, and
reasonably simple, i.e., doesn't require additional IGP extensions and minimizes signaling load processing requirements 🧁.

The model you pick has a big impact on how a network performs, as explained later 📈. So the criteria used to select a model need to let us evaluate how a particular model delivers its performance, relative to other models 🔍. Lai [LAI, DSTE-PERF] analyzed the MAM and RDM Models and gave us valuable insights into how these models perform relative to each other under various network conditions 🧠.

When preemption isn't used, MAM is attractive for two reasons 💖: a) it's good at achieving isolation, and b) it achieves reasonable bandwidth efficiency, with some QoS degradation of lower classes. When preemption is used, RDM is attractive because it can achieve bandwidth efficiency under normal load 🦋. But RDM can't provide service isolation under high load or when preemption isn't used 😬.

Our performance analysis of MAR bandwidth allocation methods is based on a full-scale, 135-node simulation model of a national network, combined with a multiservice traffic demand model to study various scenarios and tradeoffs [ASH3, E.360] 🗺️. Three levels of traffic priority (high, normal, and best effort) are spread across 5 CTs: normal priority voice, high priority voice, normal priority data, high priority data, and best effort data 🎶.

The performance analyses for overloads and failures include a) the MAR Bandwidth Constraints Model, as specified in Section 4, b) the MAM Bandwidth Constraints Model, and c) the No-DSTE Bandwidth Constraints Model 📚.

The allocated bandwidth constraints for MAR are described in Section 5 as:

Normal priority CTs:      BCck = PROPORTIONAL_BWk,
High priority CTs:        BCck = FACTOR X PROPORTIONAL_BWk
Best-effort priority CTs: BCck = 0

In the MAM Bandwidth Constraints Model, the bandwidth constraints for each CT are set to a multiple of the proportional bandwidth allocation 🌸:

Normal priority CTs:      BCck = FACTOR1 X PROPORTIONAL_BWk,
High priority CTs:        BCck = FACTOR2 X PROPORTIONAL_BWk
Best-effort priority CTs: BCck = 0

Simulations show that for MAM, the sum (BCc) should exceed MAX_RESERVABLE_BWk for better efficiency, as follows 🍭:

The normal priority CTs and the BCc values need to be over-allocated to get reasonable performance. Over-allocating by 100% (i.e., setting FACTOR1 = 2) gave reasonable performance 💜.
The high priority CTs can be over-allocated by a larger multiple, FACTOR2, in MAM, and this gives better performance ⭐.

That's a lot of over-allocation 😳. It improves efficiency, but it kinda defeats the 'bandwidth protection/isolation' a BC Model is supposed to give you, because one CT can now invade the bandwidth allocated to another CT 🙈. Each CT is still restricted to its allocated bandwidth constraint BCck, which is the maximum level of bandwidth allocated to each CT on each link, just like in normal MAM operation 🔒.

In the No-DSTE Bandwidth Constraints Model, no reservation or protection of CT bandwidth is applied, and bandwidth allocation requests are admitted if bandwidth is available 🌊. On top of that, no queuing priority is applied to any of the CTs in the No-DSTE Bandwidth Constraints Model 😤.

Table 2 gives performance results for a six-times overload on a single network node at Oakbrook, Illinois 📍. The numbers in the table are the total network percent lost (i.e., blocked) or delayed traffic. Note that in the focused overload scenario studied here, the percentage of lost/delayed traffic on the Oakbrook node is much higher than the network-wide average values given ⚠️.

                                   Table 2
               Performance Comparison for MAR, MAM, & No-DSTE
                      Bandwidth Constraints (BC) Models
                       6X Focused Overload on Oakbrook
                    (Total Network % Lost/Delayed Traffic)

   Class Type                    MAR BC  MAM BC  No-DSTE BC
                                 Model   Model   Model
   NORMAL PRIORITY VOICE         0.00    1.97    10.30
   HIGH PRIORITY VOICE           0.00    0.00    7.05
   NORMAL PRIORITY DATA          0.00    6.63    13.30
   HIGH PRIORITY DATA            0.00    0.00    7.05
   BEST EFFORT PRIORITY DATA     12.33   11.92   9.65

Clearly the performance is better with MAR bandwidth allocation 🏆, and the results show that performance improves when bandwidth reservation is used ✨. The poor No-DSTE Model performance, without bandwidth reservation, comes down to the lack of protection for allocated bandwidth 🥲. Add the bandwidth reservation mechanism and the network's performance gets a huge boost 🚀.

The simulations also showed that MAM's performance is pretty sensitive to the over-allocation factors discussed above 🫠. For example, if the BCc values are proportionally allocated with FACTOR1 = 1, the results are much worse, as shown in Table 3 📉:

                              Table 3
        Performance Comparison for MAM Bandwidth Constraints Model
             with Different Over-allocation Factors
                 6X Focused Overload on Oakbrook
             (Total Network % Lost/Delayed Traffic)

Picking up right where the tables left off 💅✨ Here's the Table 4 context: the first set of numbers is the leftover chunk of the table before it.

   Class Type                   (FACTOR1 = 1)   (FACTOR1 = 2)
   NORMAL PRIORITY VOICE        31.69           1.97
   HIGH PRIORITY VOICE          0.00            0.00
   NORMAL PRIORITY DATA         31.22           6.63
   HIGH PRIORITY DATA           0.00            0.00
   BEST EFFORT PRIORITY DATA    8.76            11.92

Table 4 🌸 shows how the MAR, MAM, and No-DSTE Bandwidth Constraints Models perform for a high-day network load pattern with a 50% general overload 🔥 The numbers are the total network percent lost (i.e., blocked) or delayed traffic.

                                   Table 4
               Performance Comparison for MAR, MAM, & No-DSTE
                      Bandwidth Constraints (BC) Models
        50% General Overload (Total Network % Lost/Delayed Traffic)

   Class Type                    MAR BC  MAM BC  No-DSTE BC
                                 Model   Model   Model
   NORMAL PRIORITY VOICE         0.02    0.13    7.98
   HIGH PRIORITY VOICE           0.00    0.00    8.94
   NORMAL PRIORITY DATA          0.00    0.26    6.93
   HIGH PRIORITY DATA            0.00    0.00    8.94
   BEST EFFORT PRIORITY DATA     10.41   10.39   8.40

Again, we can see the performance is always better when MAR bandwidth allocation and reservation is used 👑💖

Table 5 🦋 covers the performance of the MAR, MAM, and No-DSTE Bandwidth Constraints Models for a single link failure scenario (3 OC-48) ✨ The numbers are the total network percent lost (blocked) or delayed traffic.

                                   Table 5
               Performance Comparison for MAR, MAM, & No-DSTE
                      Bandwidth Constraints (BC) Models
                       Single Link Failure (2 OC-48)
                   (Total Network % Lost/Delayed Traffic)

   Class Type                    MAR BC  MAM BC  No-DSTE BC
                                 Model   Model   Model
   NORMAL PRIORITY VOICE         0.00    0.62    0.63
   HIGH PRIORITY VOICE           0.00    0.31    0.32
   NORMAL PRIORITY DATA          0.00    0.48    0.50
   HIGH PRIORITY DATA            0.00    0.31    0.32
   BEST EFFORT PRIORITY DATA     0.12    0.72    0.63

Again, we can see the performance is always better when MAR bandwidth allocation and reservation is used 🫶🌈

Table 6 🧚 illustrates the performance of the MAR, MAM, and No-DSTE Bandwidth Constraints Models for a multiple link failure scenario (3 links with 3 OC-48, 3 OC-3, 4 OC-3 capacity, respectively) 💅 The numbers are the total network percent lost (blocked) or delayed traffic.

                                   Table 6
               Performance Comparison for MAR, MAM, & No-DSTE
                      Bandwidth Constraints (BC) Models
                             Multiple Link Failure
             (3 Links with 2 OC-48, 2 OC-12, 1 OC-12, Respectively)
                   (Total Network % Lost/Delayed Traffic)

   Class Type                    MAR BC  MAM BC  No-DSTE BC
                                 Model   Model   Model
   NORMAL PRIORITY VOICE         0.00    0.91    0.92
   HIGH PRIORITY VOICE           0.00    0.44    0.44
   NORMAL PRIORITY DATA          0.00    0.70    0.72
   HIGH PRIORITY DATA            0.00    0.44    0.44
   BEST EFFORT PRIORITY DATA     0.14    1.03    1.04

Again, we can see the performance is always better when MAR bandwidth allocation and reservation is used 💜😭

Okay, so Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth sharing and service protection/isolation, using an analytic model of a single link 🧠 He shows that RDM has a higher degree of sharing than MAM. Furthermore, for a single link, the overall loss probability is the smallest under full sharing and largest under MAM, with RDM being intermediate. Hence, on a single link, Lai shows that the full sharing model yields the highest link efficiency, while MAM yields the lowest, and that full sharing has the poorest service protection capability 🥲

The results of the present study show that, when considering a network context in which there are many links and multiple-link routing paths are used, full sharing does not necessarily lead to maximum, network-wide bandwidth efficiency 🙈 In fact, the results in Table 4 show that the No-DSTE Model not only degrades total network throughput, but also degrades the performance of every CT that should be protected. Allowing more bandwidth sharing may improve performance up to a point, but it can severely degrade performance if care is not taken to protect allocated bandwidth under congestion 💀

Both Lai's study and this study show that increasing the degree of bandwidth sharing among the different CTs leads to a tighter coupling between CTs. Under normal loading conditions, there is adequate capacity for each CT, which minimizes the effect of such coupling 🍓

Under overload conditions, when there is a scarcity of capacity, such coupling can cause severe degradation of service, especially for the lower priority CTs 😩

Thus, the objective of maximizing efficient bandwidth usage, as stated in Bandwidth Constraints Model objectives, needs to be exercised with care. Due consideration also needs to be given to achieving bandwidth isolation under overload, in order to minimize the effect of interactions among the different CTs. The proper tradeoff of bandwidth sharing and bandwidth isolation needs to be achieved in the selection of a Bandwidth Constraints Model. Bandwidth reservation supports greater efficiency in bandwidth sharing, while still providing bandwidth isolation and protection against QoS degradation ✨

In summary, the proposed MAR Bandwidth Constraints Model includes the following 👑

a) allocation of bandwidth to individual CTs,
b) protection of allocated bandwidth by bandwidth reservation methods, as needed, but otherwise full sharing of bandwidth,
c) differentiation between high-priority, normal-priority, and best-effort priority services, and
d) provision of admission control to reject connection requests, when needed, in order to meet performance objectives.

In the modeling results, the MAR Bandwidth Constraints Model compares favorably with methods that do not use bandwidth reservation 🎀 In particular, some of the conclusions from the modeling are as follows:

MAR bandwidth allocation is effective in improving performance over methods that lack bandwidth reservation; this allows more bandwidth sharing under congestion.
MAR achieves service differentiation for high-priority, normal-priority, and best-effort priority services.
Bandwidth reservation supports greater efficiency in bandwidth sharing while still providing bandwidth isolation and protection against QoS degradation, and is critical to stable and efficient network performance.

Appendix B. Bandwidth Prediction for Path Computation 🔮

As discussed in [DSTE-PROTO], there are potential advantages for a Head-end when predicting the impact of an LSP on the unreserved bandwidth for computing the path of the LSP 🧚‍♀️ One example would be to perform better load-distribution of multiple LSPs across multiple paths. Another example would be to avoid CAC rejection when the LSP no longer fits on a link after establishment.

Where such predictions are used on Head-ends, the optional Bandwidth Constraints sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be advertised in the IGP 🌸 This can be used by Head-ends to predict how an LSP affects unreserved bandwidth values. Such predictions can be made with MAR by using the unreserved bandwidth values advertised by the IGP, as discussed in Sections 2 and 4:

UNRESERVED_BWck = MAX_RESERVABLE_BWk - UNRESERVED_BWk -
                  delta0/1(CTck) * RBW-THRESk

where

delta0/1(CTck) = 0 if RESERVED_BWck < BCck
delta0/1(CTck) = 1 if RESERVED_BWck >= BCck

Furthermore, the following estimate can be made for RBW_THRESk:

RBW_THRESk = RBW_% * MAX_RESERVABLE_BWk,

where RBW_% is a locally configured variable, which could take on different values for different link speeds 🍭 This information could be used in conjunction with the BC sub-TLV, MAX_RESERVABLE_BW sub-TLV, and UNRESERVED_BW sub-TLV to make predictions of available bandwidth on each link for each CT. Because admission control algorithms are left for vendor differentiation, predictions can only be performed effectively when the Head-end LSR predictions are based on the same (or a very close) admission control algorithm used by other LSRs 💅

LSPs may occasionally be rejected when head-ends are establishing LSPs through a common link. As an example, consider some link L, and two head-ends H1 and H2. If only H1 or only H2 is establishing LSPs through L, then the prediction is accurate. But if both H1 and H2 are establishing LSPs through L at the same time, the prediction would not work perfectly. In other words, the CAC will occasionally run into a rejected LSP on a link with such 'race' conditions 🏁 Also, as mentioned in Appendix A, such a prediction is optional and outside the scope of the document.

Normative References 📚

[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005.
[RFC2119] Bradner, S., "Key words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Informative References ✨

okay bestie, here's the reading list 📚 these are the sources the RFC leans on, but you don't need them to get the main ideas 💅

[AKI] Akinpelu, J. M., "The Overload Performance of Engineered Networks with Nonhierarchical & Hierarchical Routing," BSTJ, Vol. 63, 1984.
[ASH1] Ash, G. R., "Dynamic Routing in Telecommunications Networks," McGraw-Hill, 1998.
[ASH2] Ash, G. R., et al., "Routing Evolution in Multiservice Integrated Voice/Data Networks," Proceeding of ITC-16, Edinburgh, June 1999.
[ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for IP-Based Multiservice Networks," Computer Communications Magazine, May 2003.
[BUR] Burke, P. J., Blocking Probabilities Associated with Directional Reservation, unpublished memorandum, 1961.
[DSTE-PERF] Lai, W., "Bandwidth Constraints Models for Differentiated Services-aware MPLS Traffic Engineering: Performance Evaluation", RFC 4128, June 2005.
[E.360] ITU-T Recommendations E.360.1 - E.360.7, "QoS Routing & Related Traffic Engineering Methods for Multiservice TDM-, ATM-, & IP-Based Networks".
[GMPLS-RECOV] Lang, J., et al., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", Proceedings of ICC, Philadelphia, 1982.
[LAI] Lai, W., "Traffic Engineering for MPLS, Internet Performance and Control of Network Systems III Conference", SPIE Proceedings Vol. 4865, pp. 256-267, Boston, Massachusetts, USA, 29 July-1 August 2002.
[MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[MPLS-BACKUP] Vasseur, J. P., et al., "MPLS Traffic Engineering Fast Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", Work in Progress.
[MUM] Mummert, V. S., "Network Management and Its Implementation on the No. 4ESS, International Switching Symposium", Japan, 1976.
[NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global Communication Network, Proceedings of ITC-7, Stockholm, 1973.
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RSVP-TE] 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.

Author's Address 📮

Here's where to find the author, Jerry Ash, over at AT&T 💼

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA

Phone: +1 732-420-4578
EMail: gash@att.com

Full Copyright Statement 🎀

okay so this doc is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep 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 doesn't take a side on whether any IPR claims covering this technology are valid or how far they reach, and it doesn't say whether licenses are available either. it also hasn't done its own digging to find any of those rights 🕵️‍♀️ if you want the rules on rights in RFC documents, check BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, plus any licence assurances, or the results of trying to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone to flag copyrights, patents, patent applications or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🫶

shoutout to the Internet Society, which is currently the one funding the RFC Editor function 🙌🌈

📦 where this page comes from

ietf: rfc4126 2005-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms