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

Versions: (draft-heinanen-diffserv-af) 00 01 02 03 04 06 RFC 2597

Internet Engineering Task Force                            Juha Heinanen
INTERNET DRAFT                                             Telia Finland
Expires March 1999                                            Fred Baker
                                                           Cisco Systems
                                                            Walter Weiss
                                                     Lucent Technologies
                                                         John Wroclawski
                                                                 MIT LCS
                                                         September, 1998


                      Assured Forwarding PHB Group
                    <draft-ietf-diffserv-af-00.txt>



Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This document proposes a general use Differentiated Services (DS)
   [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).
   The AF PHB group provides delivery of IP packets in four
   independently forwarded AF classes.  Within each AF class, an IP
   packet can be assigned one of three different levels of drop
   precedence.  A DS node will not reorder IP packets of the same
   microflow if they belong to the same AF class.

1. Purpose and Overview


   There is a demand to offer assured delivery of IP packets over the



Heinanen              Assured Forwarding PHB Group              [Page 1]


INTERNET DRAFT                                           September, 1998


   Internet.  In a typical application, a company uses the Internet to
   connect its geographically distributed sites and wants assured
   delivery of IP packets within this intranet as long as the aggregate
   traffic from a site does not exceed the subscribed information rate
   (profile).  It is desirable that the site may exceed the subscribed
   profile with the understanding that the excess traffic is not
   delivered with as high a probability as the traffic that is within
   the profile.  It is also important that the network does not reorder
   packets that belong to the same microflow no matter if they are in or
   out of the profile.

   Assured Forwarding (AF) PHB group is a means for a provider DS domain
   to offer different levels of delivery assurances and, if so desired,
   also different levels of delay and jitter, for IP packets received
   from a customer DS domain.  IP packets that wish to use the services
   provided by the AF PHB group are assigned by the customer or the
   provider DS domain into up to four subscribed AF classes, where each
   AF class is in each DS node allocated a certain amount of forwarding
   resources (buffer space, bandwidth).

   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 first discarding packets with a
   higher drop precedence value.

   In a DS node, the level of delivery assurance and forwarding delay of
   an IP packet thus depends on (1) how much forwarding resources has
   been allocated to the AF class that the packet belongs to, (2) what
   is the current load of the AF class, and, in case of congestion, (3)
   what is the drop precedence of the packet.

   For example, if traffic conditioning actions at the ingress of the
   provider DS domain make sure that an AF class in the DS nodes is only
   moderately loaded by packets with the lowest drop precedence value
   and is not overloaded by packets with the two lowest drop precedence
   values, then the AF class can offer a high level of delivery
   assurance for packets that are within the subscribed profile and
   offer up to two lower levels of delivery assurance for the excess
   traffic.

2. The AF PHB Group

   Assured Forwarding (AF) PHB group provides delivery of IP packets in
   N independent AF classes.  Within each AF class, an IP packet can be
   assigned one of M different levels of drop precedence.  An IP packet



Heinanen              Assured Forwarding PHB Group              [Page 2]


INTERNET DRAFT                                           September, 1998


   that belongs to an AF class i and has drop precedence j is marked
   with the AF code point AFij, where 1 <= i <= N and 1 <= j <= M.  At
   this point, we define four classes (N=4), with three drop precedences
   in each class (M=3).

   A DS node must allocate forwarding resources (buffer space and
   bandwidth) to AF classes so that, relative to the loads, the AF class
   k has no more forwarding resources than the AF class l if k < l.
   Similarly, within an AF class, an IP packet with drop precedence l
   must not be delivered with greater probability than an IP packet with
   drop precedence k if k < l.

   A DS node must not reorder AF packets of the same microflow when they
   belong to the same AF class regardless of their drop precedence.
   There is no timing requirements (delay or delay variation) associated
   with the forwarding of AF packets.  The delay properties of an AF
   class are determined by the forwarding resources and load assigned to
   the class.

   The AF PHB group is proposed for general use.  It can be used to
   implement either end-to-end or domain edge-to-domain edge services.

3. Traffic Conditioning Actions

   If a provider DS domain wants to commit to a customer DS domain that
   an AF class provides a certain level of delivery and/or delay
   assurance, the provider DS domain must at the ingress limit the
   amount and/or kind of traffic that enters the AF class.  The traffic
   conditioning actions that may be used to limit the incoming traffic
   include packet discarding and packet demotion.  Packet demotion means
   increasing the drop precedence of the packet.

   A DS node at the edge of a DS domain may also promote a packet if the
   amount of lower drop precedence traffic in that AF class would
   otherwise be less than what has been agreed between the two DS
   domains.  Packet promotion means increasing the drop precedence of
   the packet.

4. Queueing and Discard Behavior

   A DS node should implement all four AF classes.  Packets in one AF
   class must be forwarded independently from packets in another AF
   class, i.e., a DS node must aggregate two or more AF classes
   together.

   Within each AF class, the three drop precedence values must yield at
   least two different levels of loss probability.  In some networks,
   particularly in enterprise networks, where transient congestion is a



Heinanen              Assured Forwarding PHB Group              [Page 3]


INTERNET DRAFT                                           September, 1998


   rare and brief occurrence, it may be reasonable to only support two
   actual levels of drop precedence.  While this may suffice for some
   networks, two actual levels of drop precedence should be avoided in
   networks where congestion is a common occurrence.

   If only two actual levels of drop precedence is supported, then the
   lowest drop precedence level (AFx1) must be mapped to the one that
   yields the lower loss probability and the two higher levels (AFx2 and
   AFx3) to the one that yields the higher loss probability.

   In order to protect packets within an AF class x that have been
   marked with a lower drop precedence value from being discarded with
   greater probability than packets marked with a higher drop precedence
   value, a DS node must not start discarding AFxi packets before it
   starts discarding AFxj packets if i < j.

   Inconsistent discard behaviors lead to inconsistent end-to-end
   service semantics.  It is recommended that the discard mechanism is
   based on a RED-like algorithm with three configurable levels of drop
   precedence and a configurable averaging function (interval).  Future
   versions of this document may say more about specific aspects of the
   desirable behavior.

5. Tunneling

   AF packets may be tunneled provided that the PHB of the tunneling
   packet does not reduce the delivery assurance of the tunneled AF
   packet and does not cause reordering of AF packets belonging to the
   same microflow.

6. Recommended Codepoints

   It is recommended that the AF codepoints AF10, AF20, AF30, and AF40,
   i.e., the codepoints that denote the lowest drop precedence in each
   AF class, are mapped to the Class Selector [Nichols] codepoints
   '010000', '011000', '100000', '101000'.  This is done in order to
   save DS code space, because the forwarding rules associated with
   these AF codepoints are consistent and compatible with the forwarding
   rules of the corresponding Class Selector codepoints.

   The recommended values of the remaining AF codepoints are as follows:
   AF11 = '010010', AF12 = '010100', AF21 = '011010' AF22 = '011100',
   AF31 = '100010' AF32 = '100100', AF41 = '101010' and AF42 = '101100'.
   The table below summarizes the recommended AF codepoint values.







Heinanen              Assured Forwarding PHB Group              [Page 4]


INTERNET DRAFT                                           September, 1998


                        Class 1    Class 2    Class 3    Class 4
                      +----------+----------+----------+----------+
     Low Drop Pref    |  010000  |  011000  |  100000  |  101000  |
     Medium Drop Pref |  010010  |  011010  |  100010  |  101010  |
     High Drop Pref   |  010100  |  011100  |  100100  |  101100  |
                      +----------+----------+----------+----------+

7. Interactions with Other PHB Groups

   The AF codepoint mapping recommended above does not interfere with
   the local use spaces nor does it use the Class Selector codepoints
   '00x000' and '11x000'.  The PHBs selected by those Class Selector
   codepoints can thus coexist with the AF PHB group, and retain the
   forwarding behavior and relationships that was defined for them in
   [Nichols].  In particular, the Default PHB codepoint of '000000' may
   remain to be used for conventional best effort traffic.  Similarly,
   the codepoints '11x000' can remain to be used for network control
   traffic.

   In addition to the Class Selector PHBs, any other PHB groups may co-
   exist with the AF group within the same DS domain provided that the
   other PHB groups don't preempt the resources allocated to the AF
   classes.

8. Security Implications

   In order to protect itself against denial of service attacks, a
   provider DS domain must limit the traffic entering the domain to the
   subscribed profiles.  Also, in order to protect a link to a customer
   DS domain from denial of service attacks, the provider DS domain
   should allow the customer DS domain to specify how the resources of a
   link to the customer DS domain are allocated to AF packets.  If a
   service offering requires that traffic marked with an AF codepoint be
   limited by such attributes as source or destination address, it is
   the responsibility of the ingress node in a network to verify
   validity of such attributes.

Appendix: Example Services

   The AF PHB group can be used to implement, for example, the so-called
   Olympic service, which consists of three service classes: bronze,
   silver, and gold.  Packets are assigned to these three classes so
   that packets in the gold class experience lighter load (and thus have
   greater probability for timely delivery) than packets assigned to the
   silver class.  Same kind of relationship exists between the silver
   class and the bronze class.  If desired, packets within each class
   can be further separated by giving them either low, medium, or high
   drop precedence.



Heinanen              Assured Forwarding PHB Group              [Page 5]


INTERNET DRAFT                                           September, 1998


   The bronze, silver, and gold service classes can in the network be
   mapped to the AF classes 1, 2, and 3.  Similarly, low, medium, and
   high drop precedence can be mapped to AF drop precedence indexes 1,
   2, or 3.

   The drop precedence level of a packet can be assigned, for example,
   by using a dual leaky bucket traffic policer, which has as its
   parameters a rate and two burst sizes: a committed burst and an
   excess burst.  If a packet falls within the committed burst, it is
   assigned low drop precedence.  If a packet falls between the
   committed burst and the excess burst, it is assigned medium drop
   precedence. And finally, if the packet falls out of the excess burst,
   it is assigned high drop precedence.

   Another possibility would be to limit the user traffic of an Olympic
   service class to a given peak rate and distribute it evenly across
   each drop precedence.  This would yield a proportional bandwidth
   service, which equally apportions available capacity during times of
   congestion under the assumption that customers with high bandwidth
   microflows have subscribed to higher peak rates than customers with
   low bandwidth microflows.

   The AF PHB group could also be used to implement a low loss, low
   delay, and low jitter service using an over provisioned AF class, if
   the maximum arrival rate to that class is known a priori in each DS
   node.  Specification of the required admission control services,
   however, is beyond the scope of this document.

References

   [Blake] Blake, Steve, et al., An Architecture for Differentiated
   Services. Internet draft draft-ietf-diffserv-arch-01.txt, August
   1998.

   [Nichols] Nichols, Kathleen, et al., Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet
   draft draft-ietf-diffserv-header-02.txt, August 1998.

Author Information

   Juha Heinanen
   Telia Finland
   Myyrmaentie 2
   01600 Vantaa, Finland
   Email: jh@telia.fi

   Fred Baker
   Cisco Systems



Heinanen              Assured Forwarding PHB Group              [Page 6]


INTERNET DRAFT                                           September, 1998


   519 Lado Drive
   Santa Barbara, California 93111
   E-mail: fred@cisco.com

   Walter Weiss
   Lucent Technologies
   300 Baker Avenue, Suite 100,
   Concord, MA  01742-2168
   E-mail: wweiss@lucent.com

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139
   Email: jtw@lcs.mit.edu




































Heinanen              Assured Forwarding PHB Group              [Page 7]


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