INTERNET DRAFT N. Seddigh
Internet Engineering Task Force B. Nandy
Differentiated Services Working Group Nortel Networks
Expires June, 2001 J. Heinanen
Telia Finland
December, 2000
An Assured Rate Per-Domain Behaviour for Differentiated Services
<draft-seddigh-pdb-ar-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.
Distribution of this memo is unlimited.
Abstract
This document describes a diffserv per-domain behaviour (PDB) called
Assured Rate (AR). The AR PDB is suitable for carrying traffic
aggregates that require rate assurance but do not require delay and
jitter bounds. The traffic aggregate will also have the opportunity
to obtain excess bandwidth beyond the assured rate. The PDB can be
created using the diffserv AF PHB along with suitable policers at the
domain ingress nodes.
1.0 Description of the Assured Rate PDB
This document defines a differentiated services per-domain behaviour
(PDB) suitable for traffic aggregates that require rate assurance but
do not require delay and jitter bounds. This PDB ensures that traffic
conforming to a committed information rate (CIR) will incur low drop
probability. The aggregate will have the opportunity of obtaining
excess bandwidth beyond the CIR but there is no assurance. In
addition to the CIR, the edge rules may also include other traffic
Seddigh, Nandy, Heinanen [Page 1]
INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001
parameters such as the peak information rate (PIR) to place
additional constraints for packets to which the assurance applies or
to further differentiate packets which exceed the CIR.
The PDB tries to avoid packet reordering within microflows. The PDB
is applicable for a one-to-one, one-to-few as well as one-to-any
types of service.
This PDB is referred to as the Assured Rate (AR) PDB and is defined
in accordance with the guidelines in [PDBDEF].
The possibility of obtaining excess bandwidth allows development of
various novel SLA models. e.g. Excess bandwidth is charged at a
higher rate than assured bandwidth; Excess bandwidth is cheaper than
assured bandwidth; Excess bandwith is charged proportionally etc.
Development and discussion of such service and charging models are
beyond the scope of this document.
2.0 Applicability
The Assured Rate PDB is intended to carry traffic aggregates that
require assurance for a specific bandwidth level.
This document does not restrict the PDB to any particular application
or traffic type. Regardless of the traffic mix, the CIR for the
aggregate will be assured.
However, it is also possible to use this PDB to create a service for
an aggregate consisting only of TCP microflows or non-responsive UDP
microflows. The provider may wish to create a TCP-only service for a
variety of reasons such as traffic isolation, better treatment of
individual short microflows within an aggregate, greater fairness
among TCP and UDP microflows access to the excess bandwidth allowed
for the aggregate. Such service definition is outside the scope of
this document. It is mentioned here simply to show that the PDB can
be used to create diverse services.
The governing attributes of the PDB are only expressed in relation to
the entire traffic aggregate. The PDB specification does not specify
any attributes for the individual microflows within an aggregate.
The grouping of microflows into the traffic aggregate can be done
either at the customer site or by the provider's ingress router on
behalf of the customer. The AR PDB definition can be used in either
scenario. It is the responsibility of the service provider to
specify which approach is adopted in the service level specification
(SLS).
3.0 Rules
The rule specification for this PDB consist of two parts:
1. A set of Edge rules that classifies packets arriving at
Seddigh, Nandy, Heinanen [Page 2]
INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001
the domain ingress into a traffic aggregate,
perform metering/policing on the aggregate and associate
a packet marking with the aggregate. Traffic shaping
does not need to be performed on the aggregate as it
enters the domain.
2. Per-node PHB treatment for the traffic aggregate
as it weaves its way from the domain ingress to
the domain egress.
3.1 Edge Rules
As packets enter the domain they will be classified into a traffic
aggregate based on the specified filter at the domain ingress port of
the border router. The filter MUST be associated with a traffic
profile that specifies committed information rate (CIR) AND a
description on how it is to be measured. For example, the measurement
may be based on a committed burst size (CBS) or an averaging time
interval (T1).
The traffic profile MAY also include other traffic parameters. These
parameters MAY place additional constraints on packets to which the
assurance applies or MAY further differentiate traffic that exceeds
the CIR.
Such parameters could include: peak information rate (PIR), peak
burst size (PBS), excess burst size (EBS) or even a second averaging
time interval (T2).
The policer causes each packet arriving into the domain to be marked
with one of up to three levels of drop precedence, which we call (in
the increasing order) green, yellow, red. The packets to which the
assurance applies, MUST be marked green. The excess packets MUST be
marked as either yellow or red. The details of packet marking are
dependent on the specific policer utilized at the ingress router.
Red colour packets SHOULD be delivered with equal or lower
probability than yellow colour packets. A special case of this is
that all red colour packets are discarded by the ingress policer.
Yellow packets SHOULD not be dropped by the ingress policer. They MAY
be dropped by the buffer management mechanisms of the ingress router
but that will be due to PHB treatment.
The green, yellow and red packets MUST be marked with the DSCP for
AFx1, AFx2 and AFx3 PHBs respectively, where x MUST be any one value
from 1 to 4.
The service provider may utilize any marker algorithm to colour the
packets as long as it adheres to the general colouring principles
outlined above. Examples of such markers include [SRTCM] [TRTCM] or
[TSWTCM].
Seddigh, Nandy, Heinanen [Page 3]
INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001
3.2 PHB Configuration
The AR traffic aggregate is to be treated using one of three PHBs in
the selected AF PHB class. Based on the
The AR traffic aggregate is to be treated using PHBs from a single AF
class. Based on the edge rules described previously, green, yellow
and red packets will be treated with AFx1, AFx2 and AFx3 PHB
respectively.
The resultant combination of the edge rules and PHB treatment within
a single AF class, will ensure that:
"Within each AF class IP packets are marked (again by the customer or
the provider DS domain) with one of three possible drop precedence
values. In case of congestion, the drop precedence of a packet
determines the relative importance of the packet within the AF class.
A congested DS node tries to protect packets with a lower drop
precedence value from being lost by preferably discarding packets
with a higher drop precedence value." (taken from RFC 2597).
The requirement to achieve the PDB is as follows:
Nodes internal to the domain SHOULD not drop packets marked to
receive treatment with AFx1. Under exceptional circumstances, network
nodes MAY have to drop AFx1 packets for a short period. In such
cases, they should only start dropping AFx1 packets after they have
started dropping all AFx2 and AFx3 packets. See [TON98] for an
example and justification of this approach. In the case where the AF
class is lightly loaded, AFx2 and/or AFx3 packets MAY also be
transmitted successfully through the node. This will allow the
aggregate to obtain excess bandwidth beyond its assured rate.
As mentioned previously, any of the 4 AF classes may be selected to
treat this PDB. However, all aggregates using this PDB in a single
domain SHOULD utilize the same AF class PHB set. At each node, a
certain portion of the forwarding resources should be pre-allocated
for the AF class. The level of this resource should not be pre-empted
by other PHBs. For example, if AF1 PHB class is allocated a minimum
15% of a link's bandwidth, this should not be starved by another PHB
due to over-use by higher priority traffic within the node.
4.0 Attributes of AR PDB
The attributes of this PDB include a throughput rate that is assured
and low drop probability for the traffic conformant to this rate.
5.0 Parameters
This PDB MUST have the following parameters:
Seddigh, Nandy, Heinanen [Page 4]
INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001
- A committed information rate (CIR) that is assured with high
probability. The PDB does not define "high" quantitatively,
but an SLS MAY do so.
- Traffic parameters that are needed to measure CIR. The PDB
does not define these parameters, since they depend on the
policer used. Examples include a Committed Burst Size (CBS)
and an averaging interval (T1).
- A maximum packet size for the aggregate - MAX_PACKET_SIZE.
In addition to the above, the PDB MAY have optional extra traffic parameters.
These parameters MAY place further constraints on the packets
to which the assurance applies or MAY further differentiate
packets to which the assurance does not apply.
The PDB does not define these parameters, since they
depend on the policer used. Examples include a Peak Information Rate
(PIR), a Peak Burst Size (PBS), an Excess Burst Size (EBS), and a second
time averaging interval (T2).
6.0 Assumptions
The assumption is that the network operator monitors the level of
green packets in the selected AF class on all links and, if
necessary, takes traffic engineering actions to keep the level low
enough so that the likelyhood of green packets being dropped in case
of congestion is very low.
7.0 Example Uses
In this section, we provide only a few example services that are
possible with this PDB - the list is not exhaustive. Example
services that can be created out of this PDB include: (i) one-to-one
or one-to-few VPN-like services and (ii) one-to-any general service.
In the case of VPN-like services, the PDB can be utilized to assure a
rate for a traffic aggregate between an ingress and an egress within
a domain or from one ingress to few different egress points in the
domain.
In the case of one-to-any services, the PDB can be utilized to assure
a rate for a traffic aggregate that originates from one ingress node
but whose individual five-tuple flows may exit the domain at any of
the egress nodes.
It is easier for a provider to demonstrate conformance with the SLS
in the one-to-one service since all measurements can be performed at
a single egress point. In the case of a one-to-any service,
measurements need to be performed at all the egress nodes visited by
individual five-tuple flows within the aggregate. These measurements
then have to be correlated to determine the cumulative bandwidth of
the aggregate as it exits the domain.
Seddigh, Nandy, Heinanen [Page 5]
INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001
Such a measurement approach is made viable because a larger sampling
interval may be acceptable to the customer. e.g. sample egress rates
may be obtained once every half hour with random sampling at that
time. The measurements would be performed over averaging intervals as
specified in the SLS.
The AR definition allows coupling of the PDB parameters with
probabilities for statistical assurance. For example, the SLS MAY
specify a Y% assurance for the CIR (with CBS/T1) when sampled every X
minutes.
8.0 References
[TON98] D.D. Clark, W. Fang, "Explicit Allocation of Best Effort
Packet Delivery Service", IEEE/ACM Transactions on Networking,
August 1998, Vol 6. No. 4, pp. 362-373.
[RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", Internet RFC 2474, December 1998.
[RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, "An Architecture for Differentiated Services",
Internet RFC 2475, December 1998.
[AFPHB] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999
[PDBDEF] Nichols K and Carpenter B, "Definition of Differentiated
Services Per Domain Behaviours and Rules for their
Specification", Internet Draft, October 2000
[SRTCM] J. Heinanen and R. Guerin, "A Single Rate Three Colour Marker",
Internet RFC 2697, September 1999
[TRTCM] J. Heinanen and R. Guerin, "A Two Rate Three Colour Marker",
Internet RFC 2698, September 1999
[TSWTCM] W. Fang, N. Seddigh and B. Nandy, "A Time Sliding Window
Three Colour Marker", Internet RFC 2859, June 2000
9.0 Author Addresses
Nabil Seddigh
Nortel Networks,
3500 Carling Ave
Ottawa, ON, K2H 8E9
Canada
Email: nseddigh@nortelnetworks.com
Seddigh, Nandy, Heinanen [Page 6]
INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001
Biswajit Nandy
Nortel Networks,
3500 Carling Ave
Ottawa, ON, K2H 8E9
Canada
Email: bnandy@nortelnetworks.com
Juha Heinanen
Telia Finland,
Email: jh@telia.fi
Seddigh, Nandy, Heinanen [Page 7]