[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET DRAFT                                                  N. Seddigh
Internet Engineering Task Force                                   B. Nandy
Differentiated Services Working Group                      Tropic Networks
Expires January, 2002                                          J. Heinanen
                                                             Song Networks
                                                                July, 2001

    An Assured Rate Per-Domain Behaviour for Differentiated Services

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-

   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

   The list of Internet-Draft Shadow  Directories  can  be  accessed  at

   Distribution of this memo is unlimited.


   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.
   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 parameters such as  the  peak  information

Seddigh, Nandy, Heinanen                                        [Page 1]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

   rate  (PIR)  to place additional constraints for packets to which the
   assurance applies or to further differentiate  packets  which  exceed
   the CIR.

   This PDB is referred to as the Assured Rate (AR) PDB and  is  defined
   in accordance with the guidelines in [PDBDEF].

   It may be possible to determine delay and jitter bounds  for  traffic
   aggregates  using the AR PDB. However, such parameters are beyond the
   scope of this PDB definition and no attempt is made  to  characterize
   them. Development of a mathematical model to predict delay and jitter
   for the  AR  PDB  is  left  as  a  subject  of  future  research  and

   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 document uses  "one-to-one"  to  describe  a  traffic  aggregate
   entering  via  a  single ingress point of a domain and exiting from a
   single egress point for the domain. One-to-any refers  to  a  traffic
   aggregate  with  single entry point and multiple (any) exit points in
   the domain. One-to-few refers to  a  traffic  aggregate  with  single
   ingress point and fixed set of egress points within a domain.

   The possibility of obtaining excess bandwidth allows  development  of
   various novel SLA models. For example, 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 definitions are outside the scope of
   this  document.  They  are 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

Seddigh, Nandy, Heinanen                                        [Page 2]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

   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

3.0 Technical Specification

   The specification for this PDB consist of two parts:

   1. A set of Edge rules that classifies packets arriving at
      the domain ingress into a traffic aggregate,
      performs metering/policing on the aggregate and associates
      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
   interface 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 colouring  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.

Seddigh, Nandy, Heinanen                                        [Page 3]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

   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 N. N is the number of AF classes supported by  the  routers
   in the domain.

   The service provider may utilize any policer algorithm to colour  the
   packets  as  long  as  it adheres to the general colouring principles
   outlined above.  Examples of such policers include [SRTCM] [TRTCM] or

3.2 PHB Configuration

   As described above, the AR traffic aggregate is to be  treated  using
   PHBs  AFx1,  AFx2  and  AFx3 from a single AF class x.  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 N AF classes may be  selected  to
   treat  this  PDB.  This  makes  it  possible to create in a single DS
   domain, multiple instances of the AR PDB, each with their own minimum
   forwarding   resources.   However,  all  aggregates  using  the  same
   instance of the PDB in a single domain SHOULD  utilize  the  same  AF
   class PHB set.

4.0 Attributes of AR PDB

   The attributes of this PDB include a rate that  is  assured  and  low
   drop probability for the traffic conformant to this rate.

Seddigh, Nandy, Heinanen                                        [Page 4]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

5.0 Parameters

   The AR PDB MUST have the following parameters:

   - A committed information rate (CIR) that is assured with high
     probability. The AR PDB specification does not define "high"
     quantitatively, but an SLS MAY do so.

   - Traffic parameters that are needed to measure CIR.  The AR PDB
     specification 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 AR PDB MAY have other, optional 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

   Deployment of the AR PDB requires an assumption that the  network  is
   well-provisioned enough so that the likelyhood of green packets being
   dropped in case of congestion  is  very  low.  This  draft  does  not
   dictate  a particular method to achieve the above objective.  Various
   traffic engineering methods may be used.  As an example, the  network
   operator monitors the level of green packets in the selected AF class
   on all links and takes appropriate action to limit the  green  packet

   The PDB also assumes that there is relatively stable  routing  within
   the domain.

7.0 Security

   There are no specific  security  exposures  for  this  PDB.  See  the
   general  security considerations in the Diffserv Header RFC [RFC2474]
   and the Diffserv Architecture RFC [RFC2475].

   All the security concerns expressed in [RFC 2597] apply  for  the  AR

8.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.

Seddigh, Nandy, Heinanen                                        [Page 5]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

   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

   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 egress nodes where packets
   are sent from an ingress node during the measurement interval.  These
   measurements  then  have to be correlated to determine the cumulative
   bandwidth of the aggregate as it exits the domain.

   Most of the previous portion of this document discussed deployment of
   the  AR  PDB  in  the  context  of  an  IP routed network. It is also
   possible to deploy the AR PDB in other networks - for example, in  an
   MPLS  network which supports the Diffserv architecture and mechanisms
   [DIFFMPLS].  In  a  Diffserv-enabled  MPLS  network  with  dedicated,
   constraint  based  LSPs, the AR PDB could be deployed using either E-
   LSPs or L-LSPs. In such a network, traffic engineering can be used in
   conjunction  with  per-LSP admission control mechanisms to provide AR
   PDB-based services that are quantitative in nature.

   In such a network, the AR PDB could be used as the basis for  an  SLS
   that  includes  additional  parameters  such as statistical assurance
   probabilities or packet drop assurance.  As an example of the former,
   the  SLS  MAY  specify  a Y% assurance for the CIR (with CBS/T1) when
   sampled every X minutes. As an example of the  latter,  the  SLS  MAY
   specify  a  CIR  (with CBS/T1) and a Y% drop ratio for AR PDB traffic
   for a particular customer.

9.0 Simulation Summary

   There have been a number  of  simulation  and  emulation  studies  of
   involving  PDBs  that essentially provide similar behaviour to the AR
   PDB.  In this section, we briefly summarize some  of  those  studies.
   The  primary  aim is to show that with the deployment of the required
   mechanisms, in general, it is possible to provide rate assurance over
   a   time  period.   Some  of  the  studies  also  point  to  suitable
   provisioning or subscription levels for network  links  in  order  to
   support such a PDB.

   In [TON98], the authors perform simulations that show how AR PDB-like
   behaviour  can  be  realized  in  a  simple topology utilizing RIO in
   conjunction with a sliding window policer. This  set  of  simulations
   showed that the rate for individual TCP or UDP flows can be assured.

   In [YEOM], the authors perform simulation tests involving  aggregates

Seddigh, Nandy, Heinanen                                        [Page 6]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

   of  TCP  flows  with  different RTTs. The topology in this case was a
   dumbell  topology.  The  results  indicated  that  for  the  utilized
   topology,   the   aggregate   rate  could  be  assured  with  a  link
   subscription level of as high as 80%.

   In [REZENDE], the authors perform simulations with  more  complicated
   topologies  involving flow merge and split points, congestion in both
   directions of a link. In this set of  experiments,  individual  flows
   had  their  assured  rates.  The  simulations  showed  that  for link
   provisioning levels of 40%, the network could assure  the  rates  for
   the individual flows.

   In [HPN2000], the authors perform simulations involving aggregates of
   TCP  and  UDP  flows.  It  is observed that if UDP and TCP in-profile
   packets are marked  green,  the  aggregates  achieve  their  CIR.  In
   another  simulation,  different  flow aggregates with different CIRs,
   share  the  same  bottleneck  link  with  total  allocated  bandwidth
   constituting  40%  and  80% of link capacity. It is observed that for
   the 40% case,  the  CIR  for  the  different  aggregates  are  always
   achieved.  However,  in  the  80%  case,  the  CIR  for  a few of the
   aggregates are not achieved.

10.0 Acknowledgements

   The authors would like to thank the following individuals  for  their
   helpful  comments  and  suggestions: Marcus Brunner, Brian Carpenter,
   Shahram Davari and Alper Demir.

10.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

   [YEOM]    Yeom I and Reddy N, "Impact of Marking Strategy for Aggregated
             Flows in a Differentiated Services Network", Proceedings of
             IWQOS Workshop, June 1999

   [SRTCM]   J. Heinanen and R. Guerin, "A Single Rate Three Colour Marker",
             Internet RFC 2697, September 1999

Seddigh, Nandy, Heinanen                                        [Page 7]

INTERNET DRAFT draft-ietf-diffserv-pdb-ar-01.txt            January 2002

   [TRTCM]   J. Heinanen and R. Guerin, "A Two Rate Three Colour Marker",
             Internet RFC 2698,  September 1999

   [REZENDE] J Rezende, "Assured Service Evaluation", Proceedings of
             GLOBECOM 99, Rio De Janiero, December 1999

   [TSWTCM]  W. Fang, N. Seddigh and B. Nandy, "A Time Sliding Window
             Three Colour Marker", Internet RFC 2859, June 2000

   [HPN2000] Nandy B, Seddigh N, Pieda P and Ethridge J, "Intelligent Traffic
             Conditioners for Assured Forwarding Based Differentiated Services
             Networks", Proceedings of HPN 2000, Paris, June 2000.

   [PDBDEF]  Nichols K and Carpenter B, "Definition of Differentiated
             Services Per Domain Behaviours and Rules for their
             Specification", Internet Draft, October 2000

   [DIFFMPLS] Le Faucher et al, "MPLS Support of Differentiated Services",
              Internet Draft, <draft-ietf-mpls-diff-ext-09.txt>, April 2001

9.0 Author Addresses

   Nabil Seddigh
   Tropic Networks,
   135 Michael Cowpland Drive
   Kanata, ON, K2M 2E9
   Email: nseddigh@tropicnetworks.com

   Biswajit Nandy
   Tropic Networks,
   135 Michael Cowpland Drive
   Kanata, ON, K2M 2E9
   Email: bnandy@tropicnetworks.com

   Juha Heinanen
   Song Networks, Inc.
   Hallituskatu 16
   33200 Tampere
   Email: juha.heinanen@mail.com

Seddigh, Nandy, Heinanen                                        [Page 8]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/