Request for Comments: 4126 AT&T
Category: Experimental June 2005
Max Allocation with Reservation Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering & Performance Comparisons
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document complements the Diffserv-aware MPLS Traffic Engineering
(DS-TE) requirements document by giving a functional specification
for the Maximum Allocation with Reservation (MAR) Bandwidth
Constraints Model. Assumptions, applicability, and examples of the
operation of the MAR Bandwidth Constraints Model are presented. MAR
performance is analyzed relative to the criteria for selecting a
Bandwidth Constraints Model, in order to provide guidance to user
implementation of the model in their networks.
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
Diffserv-aware MPLS traffic engineering (DS-TE) requirements and
protocol extensions are specified in [DSTE-REQ, DSTE-PROTO]. A
requirement for DS-TE implementation is the specification of
Bandwidth Constraints Models for use with DS-TE. The Bandwidth
Constraints Model provides the ’rules’ to support the allocation of
bandwidth to individual class types (CTs). CTs are groupings of
service classes in the DS-TE 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 DS-TE requirements
document [DSTE-REQ] by giving a functional specification for the
Maximum Allocation with Reservation (MAR) Bandwidth Constraints
Model. Examples of the operation of the MAR Bandwidth Constraints
Model are presented. MAR performance is analyzed relative to the
criteria for selecting a Bandwidth Constraints Model, in order to
provide guidance to user implementation of the model in their
networks.
Two other Bandwidth Constraints Models are being specified for use in
DS-TE:
1. Maximum Allocation Model (MAM) [MAM] - the maximum allowable
bandwidth usage of each CT is explicitly specified.
2. Russian Doll Model (RDM) [RDM] - the maximum allowable bandwidth
usage is done cumulatively by grouping successive CTs according to
priority classes.
MAR is similar to MAM 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 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.
In Appendix A, modeling analysis is presented that shows the MAR
Model meets all of these objectives and provides good network
performance, relative to MAM and full-sharing models, under normal
and abnormal operating conditions. It is demonstrated that MAR
simultaneously achieves bandwidth efficiency, bandwidth isolation,
and protection against QoS degradation without preemption.
In Section 3 we give the assumptions and applicability; in Section 4
a functional specification of the MAR Bandwidth Constraints Model;
and in Section 5 we give examples of its operation. In Appendix A,
MAR performance is analyzed relative to the criteria for selecting a
Bandwidth Constraints Model, in order to provide guidance to user
implementation of the model in their networks. In Appendix B,
bandwidth prediction for path computation is discussed.
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 number of definitions from [DSTE-REQ, DSTE-PROTO]
are repeated here:
Traffic Trunk: an aggregation of traffic flows of the same class
(i.e., 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 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 CTc, 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, 0 <= c <=
MaxBC-1 = 7.
TE-Class: A pair of: a) a CT, and b) 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, the holding priority, or both.
MAX_RESERVABLE_BWk: maximum reservable bandwidth on link k 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: bandwidth constraint for CTc on link k =
allocated (minimum guaranteed) bandwidth for CTc
on link k (see Section 4).
RBW_THRESk: reservation bandwidth threshold for link k (see
Section 4).
RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k
(0 <= c <= MaxCT-1), RESERVED_BWck = total amount
of the bandwidth reserved by all the established
LSPs that belong to CTc.
UNRESERVED_BWk: unreserved link bandwidth on link k specifies the
amount of bandwidth not yet reserved for any CT,
UNRESERVED_BWk = MAX_RESERVABLE_BWk - sum
[RESERVED_BWck (0 <= c <= MaxCT-1)].
UNRESERVED_BWck: unreserved link bandwidth on CTc on link k
specifies the amount of bandwidth not yet
reserved for CTc, UNRESERVED_BWck =
UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk
where
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 the concept of bandwidth sharing across particular sets
of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-
based Computation Model" in [MPLS-BACKUP] are example mechanisms that
increase bandwidth efficiency by sharing bandwidth across backup LSPs
protecting against independent failures. To ensure that the notion
of RESERVED_BWck introduced in [DSTE-REQ] is compatible with such a
concept of bandwidth sharing across multiple LSPs, the wording of the
definition provided in [DSTE-REQ] is generalized. With this
generalization, the definition is compatible with Shared Mesh
Restoration defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh
Protection can operate simultaneously, under the assumption 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; excess traffic LSPs that share bandwidth with backup LSPs of CTc
also need to belong to CTc.
3. Assumptions & Applicability
In general, DS-TE is a bandwidth allocation mechanism for different
classes of traffic allocated to various CTs (e.g., voice, normal
data, best-effort data). Network operation 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 about a
specific CAC method, except that CT bandwidth allocation is
related to the measured/forecasted 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 (seconds,
minutes, hours), daily, weekly, monthly, or otherwise.
4. 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.
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 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.
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 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
occurs for a particular CTc, bandwidth reservation prohibits traffic
from other CTs from seizing the allocated capacity for CTc.
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 to 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.
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. That is:
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 a 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 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.
7. Summary
The proposed MAR Bandwidth Constraints Model includes the following:
1. allocation of bandwidth to individual CTs,
2. protection of allocated bandwidth by bandwidth reservation
methods, as needed, but otherwise full sharing of bandwidth,
3. differentiation between high-priority, normal-priority, and best-
effort priority services, and
4. 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.
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.
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.
Appendix A. MAR Operation & Performance Analysis
A.1. MAR Operation
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 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 it is shared.
Under normal, non-congested network conditions, all CTs/services
fully share all available bandwidth. When congestion occurs for a
particular CTc, bandwidth reservation acts to prohibit traffic from
other CTs from seizing the allocated capacity for CTc. Associated
with each CT is the allocated bandwidth constraint (BCc) which
governs bandwidth allocation and protection; these parameters are
illustrated with examples in this Appendix.
In performing MAR bandwidth allocation for a given flow/LSP, 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/LSPs 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 idle bandwidth on a link more easily than the
non-preferred traffic. 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, AKI,
KRU, NAK].
Bandwidth reservation is used in MAR bandwidth allocation to control
sharing of link bandwidth across different CTs. On a given link, a
small amount of bandwidth (RBW_THRES) is reserved (perhaps 1% of the
total link bandwidth), and the reservation bandwidth can be accessed
when a given CT has reserved bandwidth-in-progress (RESERVED_BW)
below its allocated bandwidth (BC). That is, if the available link