[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 rfc4126                                  
Network Working Group                                        Jerry Ash
Internet Draft                                                    AT&T
Category: Experimental
<draft-ietf-tewg-diff-te-mar-00.txt>
Expiration Date:  November 2003
                                                           April, 2003


    Max Allocation with Reservation Bandwidth Constraint Model for
           MPLS/DiffServ TE & Performance Comparisons

               <draft-ietf-tewg-diff-te-mar-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

This document complements the DiffServ-aware MPLS TE (DSTE) requirements
document by giving a functional specification for the Maximum Allocation
with Reservation (MAR) bandwidth constraint model.  Assumptions,
applicability, and examples of the operation of the MAR bandwidth
constraint model are presented.  MAR performance is analyzed relative to
the criteria for selecting a bandwidth constraint model, in order to
provide guidance to user implementation of the model in their networks.

Table of Contents

   1. Introduction
   2. Definitions
   3. Assumptions & Applicability
   4. Functional Specification of the MAR Bandwidth Constraint Model
   5. Examples of MAR Operation
   6. Summary
   7. Security Considerations
   8. Acknowledgments
   9. References
   10. Authors' Addresses
   ANNEX A. MAR Operation & Performance Analysis


1. Introduction

DiffServ-aware MPLS traffic engineering (DSTE) requirements and protocol
extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for
DSTE implementation is the specification of bandwidth constraint models
for use with DSTE.  The bandwidth constraint model provides the 'rules'
to support the allocation of bandwidth to individual class types (CTs).
CTs are groupings of service classes in the DSTE model, which are
provided separate bandwidth allocations, priorities, and QoS objectives.
Several CTs can share a common bandwidth pool on an integrated,
multiservice MPLS/DiffServ network.

This document is intended to complement the DSTE requirements document
[DSTE-REQ] by giving a functional specification for the Maximum
Allocation with Reservation (MAR) bandwidth constraint model.  Examples
of the operation of the MAR bandwidth constraint model are presented.
MAR performance is analyzed relative to the criteria for selecting a
bandwidth constraint model, in order to provide guidance to user
implementation of the model in their networks.

Two other bandwidth constraint models are being specified for use in
DSTE:

1. maximum allocation (MA) model [MAM1, MAM2] - the maximum allowable
bandwidth usage of each CT is explicitly specified.
2. Russian doll (RD) model [RDM] - the maximum allowable bandwidth usage
is done cumulatively by grouping successive CTs according to priority
classes.

MAR is similar to the MA model in that a maximum bandwidth allocation is
given to each CT.  However, through the use of bandwidth reservation and
protection mechanisms, CTs are allowed to exceed their bandwidth
allocations under conditions of no congestion but revert to their
allocated bandwidths when overload and congestion occurs.

All bandwidth constraint 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.

In Annex A modeling analysis is presented which shows that the MAR model
meets all these objectives, and provides good network performance
relative to full sharing models, under normal and abnormal operating
conditions.  It is demonstrated that simultaneously achieves bandwidth
efficiency, bandwidth isolation, and protection against QoS degradation
without preemption.

In Section 3 we give assumptions and applicability, in Section 4 a
functional specification of the MAR bandwidth constraint model, and in
Section 5 we give examples of its operation.  In Annex A, MAR
performance is analyzed relative to the criteria for selecting a
bandwidth constraint model, in order to provide guidance to user
implementation of the model in their networks.

2. Definitions

For readability a number of definitions from [DSTE-REQ, DSTE-PROTO] are
repeated here:

Traffic Trunk: an aggregation of traffic flows of the same class (i.e.
which are to be treated equivalently from the DSTE perspective) which
are placed inside an 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 the
purposes of 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 CTi,
0 <= i <= 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 BCi,
0 <= i <= MaxBC-1 = 7.

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

BWIPi: bandwidth-in-progress on CTi (0 <= i <= MaxCT), BWIPi = sum
of the bandwidth reserved by all established LSPs which belong to CTi.

BWALLOCi: allocated (minimum guaranteed) bandwidth for CTi.

BWMAXi: bandwidth allocation threshold for high-priority CTs (see
Section 4).

TLBWk: the total link bandwidth on link k.

ILBWk: idle link bandwidth on link k = TLBWk - sum BWIPi (0 <= i
<= MaxCT),

RBWk: reserved bandwidth for link k

Normalized(CTi): Normalized(CTi) = BWIPi/LOMi, where LOMi is the Local
Overbooking Multiplier for CTi defined in [DSTE-PROTO].

3. Assumptions & Applicability

In general, DSTE is a bandwidth allocation mechanism, for different
classes of traffic allocated to various CTs (e.g., voice, normal data,
best-effort data).  Network operations functions such as capacity
design, bandwidth allocation, routing design, and network planning are
normally based on traffic measured load and forecast [ASH1].

As such, the following assumptions are made according to the operation
of MAR:

1. 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.
2. CAC could allocate bandwidth per flow, per LSP, per traffic trunk, or
otherwise.  That is, no specific assumption is made on a specific CAC
method, only that CT bandwidth allocation is related to the
measured/forecast traffic load, as per assumption #1.
3. CT bandwidth allocation is adjusted up or down according to
measured/forecast traffic load.  No specific time period is assumed for
this adjustment, it could be short term (hours), daily, weekly, monthly,
or otherwise.
4. Capacity management and CT bandwidth allocation thresholds (e.g.,
BWALLOC) 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.
5. No assumption is made on the order in which traffic is allocated to
various CTs, again traffic allocation is assumed to be based only on
traffic load as it is measured and/or forecast.
6. 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, but are generic,
common assumptions for all BC models.

4. Functional Specification of the MAR Bandwidth Constraint Model

In the MAR bandwidth constraint model, the bandwidth allocation control
for each CT is based on estimated bandwidth needs, bandwidth use, and
status of links.  The LER makes 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 shared. Under normal non-congested network
conditions, all CTs/services fully share all available bandwidth.  When
congestion occurs for a particular CTi, bandwidth reservation acts to
prohibit traffic from other CTs from seizing the allocated capacity for
CTi.

On a given link k, a small amount of bandwidth RBWk is reserved, and the
link load state definition is as follows:

Table 1:

Reserved-bandwidth state (RBW): ILBWk <= RBWk
Available-bandwidth state (ABW): ILBWk > RBWk

Associated with each CTi are the allocated bandwidth BWALLOCi and
maximum bandwidth BWMAXi parameters to govern bandwidth allocation and
protection.  The reserved bandwidth on a link, RBWk, can be accessed
when a given CTi has bandwidth-in-use BWIPi below its allocated
bandwidth BWALLOCi.  That is, if the available link bandwidth ILBWk
exceeds RBWk, then any CTi is free to access the available bandwidth on
the link.  However, if ILBWk is less than RBWk, then the CTi can utilize
the available bandwidth only if its current bandwidth usage is below the
allocated amount BWALLOCi. In this way, bandwidth can be fully shared
among CTs if available, but is protected by bandwidth reservation if
below the reservation level.

When preemption is disabled, i.e., all LSP holding priorities are set to
zero, bandwidth can be accessed for a bandwidth request = DBW for CTi
on a given path based on the following rules:

Table 2:

For a high priority LSP (setup priority = 0):
On primary and alternate paths for CTi:
If BWIPi <= 2 X BWMAXi: RBWk state allowed on all links k in path
If BWIPi > 2 X BWMAXi:  ABWk state allowed on all links k in path

For a normal priority LSP (setup priority = 1):
On primary path for CTi:
If BWIPi <= BWALLOCi:   RBWk state allowed on all links k in path
If BWIPi > BWALLOCi:    ABWk state allowed on all links k in path
On alternate path for CTi:
If BWIPi <= BWALLOCi:   ABWk state allowed on all links k in path
If BWIPi > BWALLOCi:    alternate path not allowed

For a best-effort priority LSP (setup priority >= 2):
On primary path for CTi:
allocated bandwidth BWALLOCi = 0;
DiffServ queuing admits BE packets only if there is available bandwidth
on a link;
Alternate paths not allowed.

When preemption is enabled, the normal semantics of setup and holding
priority are applied, in addition to the above bandwidth allocation
thresholds in Table 1 and Table 2.

These parameters defined in Table 1 and Table 2 are illustrated with
examples in Section 5.

5. Examples of MAR Operation

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

In practice, MAR allocates CT bandwidth for the normal traffic loads, so
in an engineered network it never winds up that the BWALLOC values on a
given link add to 100% of the link bandwidth.  For example these could
be typical allocated bandwidths:

CT0-BWALLOC = 30
CT1-BWALLOC = 20
CT2-BWALLOC = 20

These are based on the normal traffic loads.  This leaves 100 - 70 =
30 units of spare bandwidth on the link under normal loading.  With MAR,
any of the CTs is allowed to exceed its BWALLOC as long a there is at
least RBW (reserved bandwidth on the link) units of spare bandwidth
remaining.

Let's say RBW = 10.  So under overload, if

CT0 has taken 50 units of bandwidth,
CT1 has taken 30 units of bandwidth,
CT2 has taken 10 units of bandwidth,

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

RBW is set such that the probability that each CT can get at least its
BWALLOC is quite high.

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 (30 units average for this example), but is subject to being
lost at the queues in favor of the higher priority traffic.

We now expand the example to give some illustration of the use of Table
1 and Table 2 in Section 4.

We still assume 3 CTs: CT0, CT1, CT2, all with 'normal' priority, and a
particular link with capacity = 100.  BWALLOC values and RBW are as in
the above example:

BWALLOC for CT0 = BWALLOC0 = 30
BWALLOC for CT1 = BWALLOC1 = 20
BWALLOC for CT2 = BWALLOC2 = 20
Reserved bandwidth (RBW) = 10

This leaves 100 - 70 = 30 units of spare bandwidth on the link under
normal loading.  With MAR, any of the CTs is allowed to exceed its
BWALLOC as long a there is at least RBW (reserved bandwidth on the link)
units of spare bandwidth remaining.

Now assume an overload condition, such that

CT0 has taken 50 units of bandwidth (bandwidth-in-progress for CT0 =
BWIP0 = 50),
CT1 has taken 30 units of bandwidth (bandwidth-in-progress for CT1 =
BWIP1 = 30),
CT2 has taken 10 units of bandwidth (bandwidth-in-progress for CT2 =
BWIP2 = 10),

Therefore, for this loading,
Idle link bandwidth (ILBW) = 100 - 50 - 30 - 10 = 10

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

The link load state is determined from Table 1.  Since ILBW - RBW < DBW
(i.e., 10 - 10 < 5), Table 1 says the link is in the RBW (reserved
bandwidth) state.

The allowed load state is determined from Table 2 (the allowed load
state is the minimum level of bandwidth that must be available on a link
to admit the flow).  Since for CT0 (normal priority) BWALLOC0 < BWIP0
(30 < 50), Table 2 says the allowed load state is ABW (available
bandwidth).

Hence since the link has less bandwidth (RBW state) than the allowed
load state level of bandwidth required to admit the flow (ABW), the flow
is rejected/blocked.

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

The link load state is determined from Table 1.  Since ILBW - RBW < DBW
(i.e., 10 - 10 < 5), Table 1 says the link is in the RBW (reserved
bandwidth) state.

The allowed load state is determined from Table 2 (the allowed load
state is the minimum level of bandwidth that must be available on a link
to admit the flow).  Since for CT2 (normal priority) BWIP2 < BWALLOC2
(10 < 20), Table 2 says the allowed load state is RBW (reserved
bandwidth).

Hence since the link has sufficient bandwidth (RBW state) compared to
the allowed load state level of bandwidth required to admit the flow
(also RBW), the flow is admitted.

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

6. Summary

The proposed MAR bandwidth constraint model includes the following: a)
allocate bandwidth to individual CTs, b) protect allocated bandwidth by
bandwidth reservation methods, as needed, but otherwise fully share
bandwidth, c) differentiate high-priority, normal-priority, and
best-effort priority services, and d) provide admission control to
reject connection requests when needed to meet performance objectives.
Modeling results presented in Annex A show that MAR bandwidth allocation
a) achieves greater efficiency in bandwidth sharing while still
providing bandwidth isolation and protection against QoS degradation,
and b) achieves service differentiation for high-priority,
normal-priority, and best-effort priority services.

7. Security Considerations

No new security considerations are raised by this document, they are the
same as in the DSTE requirements document [DSTE-REQ].

8. Acknowledgements

DSTE and bandwidth constraint 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 draft.  I also appreciate helpful discussions
with Francois Le Faucheur.

8. 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., Traffic Engineering & QoS Methods for IP-, ATM-, &
TDM-Based Multiservice Networks, work in progress.
[BUR] Burke, P. J., Blocking Probabilities Associated with Directional
Reservation, unpublished memorandum, 1961.
[E.360] ITU-T Recommendations, QoS Routing & Related Traffic Engineering
Methods for Multiservice TDM-, ATM-, & IP-Based Networks.
[DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC
3270, May 2002.
[DSTE-REQ] Le Faucheur, F., et. al., "Requirements for Support of
Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support
of Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[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
(http://www.columbia.edu/~ffl5/waisum/bcmodel.pdf).
[MAM1] Lai, W., "Maximum Allocation Bandwidth Constraints Model for
Diffserv-TE & Performance Comparisons", work in progress.
[MAM2] Le Faucheur, F., "Maximum Allocations Bandwidth Constraints Model
for Diff-Serv-aware MPLS Traffic Engineering", 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.
[MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching
Architecture," RFC 3031, January 2001.
[RDM] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for
Diff-Serv-aware MPLS Traffic Engineering", work in progress.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.

9. Authors' Addresses

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
Email: gash@att.com

ANNEX A - MAR Operation & Performance Analysis

A.1 MAR Operation

In the MAR bandwidth constraint model, the bandwidth allocation control
for each CT is based on estimated bandwidth needs, bandwidth use, and
status of links. The LER makes 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 shared. Under normal non-congested network
conditions, all CTs/services fully share all available bandwidth.  When
congestion occurs for a particular CTi, bandwidth reservation acts to
prohibit traffic from other CTs from seizing the allocated capacity for
CTi.  Associated with each CT are the allocated bandwidth (BWALLOC) and
maximum bandwidth (BWmax) parameters to govern bandwidth allocation and
protection.  An allowed load state (ALS) parameter controls the
bandwidth allocation on individual links in a CT, based on their
available bandwidth.  These parameters are illustrated with examples in
this Annex.

In performing MAR bandwidth allocation for a given flow, the LER first
determines the egress LSR address, service-identity, and CT.  The
connection request is allocated an equivalent bandwidth to be routed on
a particular CT. The LER then accesses the CT priority, QoS/traffic
parameters, and routing table between the LER and egress LSR, and sets
up the connection request using the MAR bandwidth allocation rules.  The
LER selects a first choice path and determines if bandwidth can be
allocated on the path based on the MAR bandwidth allocation rules given
in Section 4.  If the first choice path has insufficient bandwidth, the
LER may then try alternate paths, and again applies the MAR bandwidth
allocation rules now described.

MAR bandwidth allocation is done on a per-CT basis, in which aggregated
CT bandwidth is managed to meet the overall bandwidth requirements of CT
service needs.  Individual flows are allocated bandwidth in the
corresponding CT according to CT bandwidth availability.  A fundamental
principle applied in MAR bandwidth allocation methods is the use of
bandwidth reservation techniques.

Bandwidth reservation gives preference to the preferred traffic by
allowing it to seize any idle bandwidth on a link, while allowing the
non-preferred traffic to only seize bandwidth if there is a minimum
level of idle bandwidth available called the reserved bandwidth RBW.
Burke [BUR] first analyzed bandwidth reservation behavior from the
solution of the birth-death equations for the bandwidth reservation
model.  Burke's model showed the relative lost-traffic level for
preferred traffic, which is not subject to bandwidth reservation
restrictions, as compared to non-preferred traffic, which is subject to
the restrictions. Bandwidth reservation protection is robust to traffic
variations and provides significant dynamic protection of particular
streams of traffic.  It is widely used in large-scale network
applications [ASH1, MUM].

Bandwidth reservation is used in two ways in MAR bandwidth allocation,
first to control sharing of link bandwidth across different CTs, and
second to prevent inefficient (long) routing paths from degrading
network performance.  On a given link, a small amount of bandwidth RBW
is reserved (say 1% of the total link bandwidth), and the reserved
bandwidth can be accessed when a given CT has bandwidth-in-use below its
allocated bandwidth BWALLOC.  That is, if the available link bandwidth
ABW exceeds RBW, then any CT is free to access the available bandwidth
on the link.  However, if ABW is less than RBW, then the CT can utilize
the available bandwidth only if its current bandwidth usage is below the
allocated amount BWALLOC. In this way, bandwidth can be fully shared
among CTs if available, but is protected by bandwidth reservation if
below the reservation level.

Bandwidth reservation is also used to prevent inefficient (long) routing
paths from degrading network performance, which if uncontrolled can lead
to network "instability" and severely reduce throughput in periods of
congestion, perhaps by as much as 50 percent of the traffic-carrying
capacity of a network. Bandwidth reservation is used to prevent this
unstable behavior by having the preferred traffic on a link be the
traffic on the primary, shortest path, and the non-preferred traffic,
subjected to bandwidth reservation restrictions as described above, be
the alternate-routed traffic on longer paths. In this way the
alternate-routed traffic is inhibited from selecting longer alternate
paths when sufficient idle trunk capacity is not available on all links
of an alternate-routed connection, which is the likely condition under
network and link congestion.  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, 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 (ALSi) to which capacity can be allocated.
In allocating bandwidth DBW to a CT on given LSP, say A-B-E, each link
in the path is checked for available bandwidth in comparison to ALSi.
If bandwidth is unavailable on any link in path A-B-E, another LSP could
by tried, such as A-C-D-E.  Hence determination of the link load state
is necessary for MAR bandwidth allocation, and three link load states
are distinguished: available (non-reserved) bandwidth (ABW),
reserved-bandwidth (RBW), and bandwidth-not-available (BNA).  Management
of CT capacity uses the link state and the ALS threshold to determine if
a bandwidth allocation request can be accepted on a given CT.

A.2 Analysis of MAR Performance

In this Annex, 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 MPLS/DiffServ TE 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 TDM-based networks [ASH1], and in modeling
studies for IP-based networks [ASH2, ASH3, E.360].

All bandwidth constraint 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 constraint model has significant impacts
on the performance of a network, as explained later. Therefore, the
criteria used to select a model must enable us to evaluate how a
particular model delivers its performance, relative to other models. Lai
[LAI, MAM1] has analyzed the MA and RD models and provided valuable
insights into the relative performance of these models under various
network conditions.

In environments where preemption is not used, the MA model 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, the RD model is attractive because it
can achieve bandwidth efficiency under normal load.  However, the RD
model 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 together
with a multiservice traffic demand model to study various scenarios and
tradeoffs [ASH3].  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 constraint model, as specified in Section 4, and b) the full
sharing bandwidth constraint model.  In the full sharing bandwidth
constraint model, no reservation or protection of CT bandwidth is
applied, and bandwidth allocation requests are admitted if bandwidth is
available.

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

                             Table 3
                      Performance Comparison
          for MAR & Full Sharing Bandwidth Constraint Models
6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic)

Class Type                  MAR Bandwidth       Full Sharing Bandwidth
                            Constraint Model    Constraint Model
----------------------------------------------------------------------
NORMAL PRIORITY VOICE       0.16                10.83
HIGH PRIORITY VOICE         0.00                8.47
NORMAL PRIORITY DATA        3.18                12.88
HIGH PRIORITY DATA          0.00                0.46
BEST EFFORT PRIORITY DATA   12.32               9.75
----------------------------------------------------------------------

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 full sharing model,
without bandwidth reservation, is due to the lack of protection of
allocated bandwidth, and the tendency to admit flows on longer paths
rather than protect shorter primary paths under network congestion.
Without bandwidth reservation, networks can exhibit unstable behavior in
which essentially all connections are established on longer alternate
paths as opposed to shorter primary paths, which greatly reduces network
throughput and increases network congestion [AKI, KRU, NAK].  If we add
the bandwidth reservation mechanism, then performance of the network is
greatly improved.

Table 4 illustrates the performance of the MAR and full sharing
bandwidth constraint 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 (blocked) or delayed traffic.

                             Table 4
                       Performance Comparison
          for MAR & Full Sharing Bandwidth Constraint Models
      50% General Overload (Total Network % Lost/Delayed Traffic)

Class Type                  MAR Bandwidth       Full Sharing Bandwidth
                            Constraint Model    Constraint Model
----------------------------------------------------------------------
NORMAL PRIORITY VOICE       0.03                2.00
HIGH PRIORITY VOICE         0.00                2.41
NORMAL PRIORITY DATA        0.01                1.90
HIGH PRIORITY DATA          0.00                2.04
BEST EFFORT PRIORITY DATA   11.15               24.95
----------------------------------------------------------------------

Again, we can see the performance is always better when MAR bandwidth
allocation and reservation is used, including the best effort traffic.

Lai's results [LAI, MAM1] show the trade-off between bandwidth sharing
and service protection/isolation, using an analytic model of a single
link. He shows that the RD model has a higher degree of sharing than the
MA model. Furthermore, for a single link, the overall loss probability
is the smallest under full sharing and largest under MA, with the RD
model being intermediate. Hence, on a single link, Lai shows that the
full sharing model yields the highest link efficiency and MA model 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
full sharing model not only degrades total network throughput, but also
degrades the performance of every CT.  Allowing more bandwidth sharing
may improve performance up to a point, but 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 constraint model objectives, must be exercised with care.
Due consideration needs to be given also 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 default bandwidth constraint 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 constraint model includes the
following: a) allocate bandwidth to individual CTs, b) protect allocated
bandwidth by bandwidth reservation methods, as needed, but otherwise
fully share bandwidth, c) differentiate high-priority, normal-priority,
and best-effort priority services, and d) provide admission control to
reject connection requests when needed to meet performance objectives.


In the modeling results, the MAR bandwidth constraint model compares
favorably with methods that permit more bandwidth sharing.  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 protection and allow 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.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.

However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures  for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.