bandwidth (unreserved idle link bandwidth UNRESERVED_BW) exceeds
RBW_THRES, then any CT is free to access the available bandwidth on
the link. However, if UNRESERVED_BW is less than RBW_THRES, then the
CT can utilize the available bandwidth only if its current bandwidth
usage is below the allocated amount (BC). In this way, bandwidth can
be fully shared among CTs if available, but it is protected by
bandwidth reservation if below the reservation level.
Through the bandwidth reservation mechanism, MAR bandwidth allocation
also gives preference to high-priority CTs, in comparison to normal-
priority and best-effort priority CTs.
Hence, bandwidth allocated to each CT is protected by bandwidth
reservation methods, as needed, but otherwise shared. Each LER
monitors CT bandwidth use on each CT, and determines if 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), CT bandwidth-in-use, and
CT bandwidth allocation thresholds, and uses these parameters to
determine the allowed load state threshold to which capacity can be
allocated. In allocating bandwidth DBW to a CT on given LSP (for
example, A-B-E), each link in the path is checked for available
bandwidth in comparison to 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. Hence, determination of the link load state is
necessary for MAR bandwidth allocation, and two link load states are
distinguished: available (non-reserved) bandwidth (ABW_STATE), and
reserved-bandwidth (RBW_STATE). Management of CT capacity uses the
link state and the allowed load state threshold to determine if a
bandwidth allocation request can be accepted on a given CT.
A.2. Analysis of MAR Performance
In this Appendix, modeling analysis is presented in which MAR
bandwidth allocation is shown to provide good network performance,
relative to full sharing models, under normal and abnormal operating
conditions. A large-scale Diffserv-aware MPLS traffic engineering
simulation model is used, in which 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:
1. applies equally when preemption is either enabled or disabled
(when preemption is disabled, the model still works ’reasonably’
well),
2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under
both normal and overload conditions,
3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of
another CT under overload conditions,
4. protection against QoS degradation, at least of the high-priority
CTs (e.g., high-priority voice, high-priority data, etc.), and
5. reasonably simple, i.e., does not require additional IGP
extensions and minimizes signaling load processing requirements.
The use of any given Bandwidth Constraints Model has significant
impacts on the performance of a network, as explained later.
Therefore, the criteria used to select a model need to enable us to
evaluate how a particular model delivers its performance, relative to
other models. Lai [LAI, DSTE-PERF] has analyzed the MAM and RDM
Models and provided valuable insights into the relative performance
of these models under various network conditions.
In environments where preemption is not used, MAM is attractive
because a) it is 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. However, RDM cannot
provide service isolation under high load or when preemption is not
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 given 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:
1. The normal priority CTs and the BCc values need to be over-
allocated to get reasonable performance. It was found that over-
allocating by 100% (i.e., setting FACTOR1 = 2), gave reasonable
performance.
2. The high priority CTs can be over-allocated by a larger multiple
FACTOR2 in MAM and this gives better performance.
The rather large amount of over-allocation improves efficiency, but
somewhat defeats the ’bandwidth protection/isolation’ needed with a
BC Model, because one CT can now invade the bandwidth allocated to
another CT. Each CT is restricted to its allocated bandwidth
constraint BCck, which is the maximum level of bandwidth allocated to
each CT on each link, as in normal operation of MAM.
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. Furthermore, 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 given 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 reason for the poor performance of the No-DSTE Model,
without bandwidth reservation, is due to the lack of protection of
allocated bandwidth. If we add the bandwidth reservation mechanism,
then performance of the network is greatly improved.
The simulations showed that the performance of MAM is quite sensitive
to the over-allocation factors discussed above. For example, if the
BCc values are proportionally allocated with FACTOR1 = 1, then 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)
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 illustrates the performance of the MAR, MAM, and No-DSTE
Bandwidth Constraints Models for a high-day network load pattern with
a 50% general overload. The numbers given in the table 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 illustrates the performance of the MAR, MAM, and No-DSTE
Bandwidth Constraints Models for a single link failure scenario (3
OC-48). The numbers given in the table 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 given in the table 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.
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:
o MAR bandwidth allocation is effective in improving performance over
methods that lack bandwidth reservation; this allows more bandwidth
sharing under congestion.
o MAR achieves service differentiation for high-priority, normal-
priority, and best-effort priority services.
o 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
[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
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
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors