draft-ietf-diffserv-af-00.txt   draft-ietf-diffserv-af-01.txt 
Internet Engineering Task Force Juha Heinanen Internet Engineering Task Force Juha Heinanen
INTERNET DRAFT Telia Finland INTERNET DRAFT Telia Finland
Expires March 1999 Fred Baker Expires April 1999 Fred Baker
Cisco Systems Cisco Systems
Walter Weiss Walter Weiss
Lucent Technologies Lucent Technologies
John Wroclawski John Wroclawski
MIT LCS MIT LCS
September, 1998 October, 1998
Assured Forwarding PHB Group Assured Forwarding PHB Group
<draft-ietf-diffserv-af-00.txt> <draft-ietf-diffserv-af-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This document proposes a general use Differentiated Services (DS) This document proposes a general use Differentiated Services (DS)
[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).
The AF PHB group provides delivery of IP packets in four The AF PHB group provides delivery of IP packets in four
independently forwarded AF classes. Within each AF class, an IP independently forwarded AF classes. Within each AF class, an IP
packet can be assigned one of three different levels of drop packet can be assigned one of three different levels of drop
precedence. A DS node will not reorder IP packets of the same precedence. A DS node does not reorder IP packets of the same
microflow if they belong to the same AF class. microflow if they belong to the same AF class.
1. Purpose and Overview 1. Purpose and Overview
There is a demand to offer assured delivery of IP packets over the There is a demand to offer assured delivery of IP packets over the
Internet. In a typical application, a company uses the Internet to Internet. In a typical application, a company uses the Internet to
connect its geographically distributed sites and wants assured connect its geographically distributed sites and wants an assurance
delivery of IP packets within this intranet as long as the aggregate that IP packets within this intranet are delivered with high
traffic from a site does not exceed the subscribed information rate probability as long as the aggregate traffic from each site does not
(profile). It is desirable that the site may exceed the subscribed exceed the subscribed information rate (profile). It is desirable
profile with the understanding that the excess traffic is not that a site may exceed the subscribed profile with the understanding
delivered with as high a probability as the traffic that is within that the excess traffic is not delivered with as high a probability
the profile. It is also important that the network does not reorder as the traffic that is within the profile. It is also important that
packets that belong to the same microflow no matter if they are in or the network does not reorder packets that belong to the same
out of the profile. 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 Assured Forwarding (AF) PHB group is a means for a provider DS domain
to offer different levels of delivery assurances and, if so desired, to offer different levels of delivery assurances for IP packets
also different levels of delay and jitter, for IP packets received received from a customer DS domain. Four AF classes are defined,
from a customer DS domain. IP packets that wish to use the services where each AF class is in each DS node allocated a certain amount of
provided by the AF PHB group are assigned by the customer or the forwarding resources (buffer space, bandwidth). IP packets that wish
provider DS domain into up to four subscribed AF classes, where each to use the services provided by the AF PHB group are assigned by the
AF class is in each DS node allocated a certain amount of forwarding customer or the provider DS domain into one or more of these AF
resources (buffer space, bandwidth). classes according to the subscribed services.
Within each AF class IP packets are marked (again by the customer or Within each AF class IP packets are marked (again by the customer or
the provider DS domain) with one of three possible drop precedence the provider DS domain) with one of three possible drop precedence
values. In case of congestion, the drop precedence of a packet values. In case of congestion, the drop precedence of a packet
determines the relative importance of the packet within the AF class. determines the relative importance of the packet within the AF class.
A congested DS node tries to protect packets with a lower drop A congested DS node tries to protect packets with a lower drop
precedence value from being lost by first discarding packets with a precedence value from being lost by preferably discarding packets
higher drop precedence value. with a higher drop precedence value.
In a DS node, the level of delivery assurance and forwarding delay of In a DS node, the level of delivery assurance of an IP packet thus
an IP packet thus depends on (1) how much forwarding resources has depends on (1) how much forwarding resources has been allocated to
been allocated to the AF class that the packet belongs to, (2) what the AF class that the packet belongs to, (2) what is the current load
is the current load of the AF class, and, in case of congestion, (3) of the AF class, and, in case of congestion, (3) what is the drop
what is the drop precedence of the packet. precedence of the packet.
For example, if traffic conditioning actions at the ingress of the 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 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 moderately loaded by packets with the lowest drop precedence value
and is not overloaded by packets with the two lowest drop precedence and is not overloaded by packets with the two lowest drop precedence
values, then the AF class can offer a high level of delivery values, then the AF class can offer a high level of delivery
assurance for packets that are within the subscribed profile and assurance for packets that are within the subscribed profile and
offer up to two lower levels of delivery assurance for the excess offer up to two lower levels of delivery assurance for the excess
traffic. traffic.
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 [Bradner].
2. The AF PHB Group 2. The AF PHB Group
Assured Forwarding (AF) PHB group provides delivery of IP packets in Assured Forwarding (AF) PHB group provides delivery of IP packets in
N independent AF classes. Within each AF class, an IP packet can be N independent AF classes. Within each AF class, an IP packet is
assigned one of M different levels of drop precedence. An IP packet assigned one of M different levels of drop precedence. An IP packet
that belongs to an AF class i and has drop precedence j is marked 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 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 this point, four classes (N=4) with three drop precedences in each
in each class (M=3). class (M=3) are defined for general use. More AF classes or levels
of drop precedence MAY be defined for local use.
A DS node must allocate forwarding resources (buffer space and A DS node MUST allocate forwarding resources (buffer space and
bandwidth) to AF classes so that, relative to the loads, the AF class bandwidth) to AF classes so that, relative to the loads, an AF class
k has no more forwarding resources than the AF class l if k < l. x has no more forwarding resources than an AF class y if x < y.
Similarly, within an AF class, an IP packet with drop precedence l Similarly, within an AF class, an IP packet with drop precedence p
must not be delivered with greater probability than an IP packet with MUST NOT be delivered with smaller probability than an IP packet with
drop precedence k if k < l. drop precedence q if p < q.
A DS node must not reorder AF packets of the same microflow when they 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. belong to the same AF class regardless of their drop precedence.
There is no timing requirements (delay or delay variation) associated There are no timing requirements (delay or delay variation)
with the forwarding of AF packets. The delay properties of an AF associated with the forwarding of AF packets.
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 The AF PHB group MAY be used to implement both end-to-end and domain
implement either end-to-end or domain edge-to-domain edge services. edge-to-domain edge services.
3. Traffic Conditioning Actions 3. Traffic Conditioning Actions
If a provider DS domain wants to commit to a customer DS domain that A DS domain MAY at the edge of a domain control the amount of AF
an AF class provides a certain level of delivery and/or delay traffic that enters or exists the domain at various levels of drop
assurance, the provider DS domain must at the ingress limit the precedence. The traffic conditioning actions MAY include discarding
amount and/or kind of traffic that enters the AF class. The traffic of packets, increasing or decreasing the drop precedence of packets,
conditioning actions that may be used to limit the incoming traffic and reassigning of packets to other AF classes. The latter action
include packet discarding and packet demotion. Packet demotion means MUST NOT distribute packets of the same microflow to more than one AF
increasing the drop precedence of the packet. class.
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 4. Queueing and Discard Behavior
A DS node should implement all four AF classes. Packets in one AF A DS node SHOULD implement all four general use AF classes. Packets
class must be forwarded independently from packets in another AF in one AF class MUST be forwarded independently from packets in
class, i.e., a DS node must aggregate two or more AF classes another AF class, i.e., a DS node MUST NOT aggregate two or more AF
together. classes together.
Within each AF class, the three drop precedence values must yield at Within each AF class, the three drop precedence codepoints MUST yield
least two different levels of loss probability. In some networks, at least two different levels of loss probability. In some networks,
particularly in enterprise networks, where transient congestion is a particularly in enterprise networks, where transient congestion is a
rare and brief occurrence, it may be reasonable to only support two rare and brief occurrence, it may be reasonable for a DS node to
actual levels of drop precedence. While this may suffice for some support only two different levels of loss probability. While this
networks, two actual levels of drop precedence should be avoided in may suffice for some networks, three different levels of loss
networks where congestion is a common occurrence. probability SHOULD be supported in DS domains 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 If a DS node only implements two different levels of loss probability
marked with a lower drop precedence value from being discarded with for an AF class x, the codepoint AFx1 MUST yield the lower loss
greater probability than packets marked with a higher drop precedence probability and the codepoints AFx2 and AFx3 MUST yield the higher
value, a DS node must not start discarding AFxi packets before it loss probability.
starts discarding AFxj packets if i < j.
Inconsistent discard behaviors lead to inconsistent end-to-end Inconsistent discard behaviors lead to inconsistent end-to-end
service semantics. It is recommended that the discard mechanism is service semantics. It is RECOMMENDED that the discard mechanism is
based on a RED-like algorithm with three configurable levels of drop based on a RED-like [Floyd] algorithm with three configurable levels
precedence and a configurable averaging function (interval). Future of drop precedence and a configurable averaging function (interval).
versions of this document may say more about specific aspects of the Future versions of this document may say more about specific aspects
desirable behavior. of the desirable behavior.
5. Tunneling 5. Tunneling
AF packets may be tunneled provided that the PHB of the tunneling When AF packets are tunneled, the PHB of the tunneling packet MUST
packet does not reduce the delivery assurance of the tunneled AF NOT reduce the delivery assurance of the tunneled AF packet nor cause
packet and does not cause reordering of AF packets belonging to the reordering of AF packets belonging to the same microflow.
same microflow.
6. Recommended Codepoints 6. Recommended Codepoints
It is recommended that the AF codepoints AF10, AF20, AF30, and AF40, It is RECOMMENDED that the AF codepoints AF11, AF21, AF31, and AF41,
i.e., the codepoints that denote the lowest drop precedence in each i.e., the codepoints that denote the lowest drop precedence in each
AF class, are mapped to the Class Selector [Nichols] codepoints AF class, are mapped to the Class Selector [Nichols] codepoints
'010000', '011000', '100000', '101000'. This is done in order to '010000', '011000', '100000', '101000'. This is done in order to
save DS code space, because the forwarding rules associated with save DS code space, because the forwarding rules associated with
these AF codepoints are consistent and compatible with the forwarding these AF codepoints are consistent and compatible with the forwarding
rules of the corresponding Class Selector codepoints. rules of the corresponding Class Selector codepoints.
The recommended values of the remaining AF codepoints are as follows: The RECOMMENDED values of the remaining AF codepoints are as follows:
AF11 = '010010', AF12 = '010100', AF21 = '011010' AF22 = '011100', AF12 = '010010', AF13 = '010100', AF22 = '011010', AF23 = '011100',
AF31 = '100010' AF32 = '100100', AF41 = '101010' and AF42 = '101100'. AF32 = '100010', AF33 = '100100', AF42 = '101010', and AF43 =
The table below summarizes the recommended AF codepoint values. '101100'. The table below summarizes the recommended AF codepoint
values.
Class 1 Class 2 Class 3 Class 4 Class 1 Class 2 Class 3 Class 4
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Low Drop Pref | 010000 | 011000 | 100000 | 101000 | Low Drop Pref | 010000 | 011000 | 100000 | 101000 |
Medium Drop Pref | 010010 | 011010 | 100010 | 101010 | Medium Drop Pref | 010010 | 011010 | 100010 | 101010 |
High Drop Pref | 010100 | 011100 | 100100 | 101100 | High Drop Pref | 010100 | 011100 | 100100 | 101100 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
7. Interactions with Other PHB Groups 7. Interactions with Other PHB Groups
The AF codepoint mapping recommended above does not interfere with The AF codepoint mappings recommended above do not interfere with the
the local use spaces nor does it use the Class Selector codepoints local use spaces nor use the Class Selector codepoints '00x000' and
'00x000' and '11x000'. The PHBs selected by those Class Selector '11x000'. The PHBs selected by those Class Selector codepoints may
codepoints can thus coexist with the AF PHB group, and retain the thus coexist with the AF PHB group, and retain the forwarding
forwarding behavior and relationships that was defined for them in behavior and relationships that was defined for them in [Nichols].
[Nichols]. In particular, the Default PHB codepoint of '000000' may In particular, the Default PHB codepoint of '000000' may remain to be
remain to be used for conventional best effort traffic. Similarly, used for conventional best effort traffic. Similarly, the codepoints
the codepoints '11x000' can remain to be used for network control '11x000' may remain to be used for network control traffic.
traffic.
In addition to the Class Selector PHBs, any other PHB groups may co- 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 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 other PHB groups don't preempt the resources allocated to the AF
classes. classes.
8. Security Implications 8. Security Implications
In order to protect itself against denial of service attacks, a In order to protect itself against denial of service attacks, a
provider DS domain must limit the traffic entering the domain to the provider DS domain SHOULD limit the traffic entering the domain to
subscribed profiles. Also, in order to protect a link to a customer the subscribed profiles. Also, in order to protect a link to a
DS domain from denial of service attacks, the provider DS domain customer DS domain from denial of service attacks, the provider DS
should allow the customer DS domain to specify how the resources of a domain SHOULD allow the customer DS domain to specify how the
link to the customer DS domain are allocated to AF packets. If a resources of the link are allocated to AF packets. If a service
service offering requires that traffic marked with an AF codepoint be offering requires that traffic marked with an AF codepoint be limited
limited by such attributes as source or destination address, it is by such attributes as source or destination address, it is the
the responsibility of the ingress node in a network to verify responsibility of the ingress node in a network to verify validity of
validity of such attributes. such attributes.
Other security considerations are covered in [Blake] and [Nichols].
Appendix: Example Services Appendix: Example Services
The AF PHB group can be used to implement, for example, the so-called The AF PHB group may be used to implement, for example, the so-called
Olympic service, which consists of three service classes: bronze, Olympic service, which consists of three service classes: bronze,
silver, and gold. Packets are assigned to these three classes so silver, and gold. Packets are assigned to these three classes so
that packets in the gold class experience lighter load (and thus have that packets in the gold class experience lighter load (and thus have
greater probability for timely delivery) than packets assigned to the greater probability for timely delivery) than packets assigned to the
silver class. Same kind of relationship exists between the silver silver class. Same kind of relationship exists between the silver
class and the bronze class. If desired, packets within each class class and the bronze class. If desired, packets within each class
can be further separated by giving them either low, medium, or high may be further separated by giving them either low, medium, or high
drop precedence. drop precedence.
The bronze, silver, and gold service classes can in the network be The bronze, silver, and gold service classes may in the network be
mapped to the AF classes 1, 2, and 3. Similarly, low, medium, and 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, high drop precedence may be mapped to AF drop precedence indexes 1,
2, or 3. 2, or 3.
The drop precedence level of a packet can be assigned, for example, The drop precedence level of a packet may be assigned, for example,
by using a dual leaky bucket traffic policer, which has as its by using a dual leaky bucket traffic policer, which has as its
parameters a rate and two burst sizes: a committed burst and an parameters a rate and two burst sizes: a committed burst and an
excess burst. If a packet falls within the committed burst, it is excess burst. If a packet falls within the committed burst, it is
assigned low drop precedence. If a packet falls between the assigned low drop precedence. If a packet falls between the
committed burst and the excess burst, it is assigned medium drop committed burst and the excess burst, it is assigned medium drop
precedence. And finally, if the packet falls out of the excess burst, precedence. And finally, if the packet falls out of the excess burst,
it is assigned high drop precedence. it is assigned high drop precedence.
Another possibility would be to limit the user traffic of an Olympic Another possibility would be to limit the user traffic of an Olympic
service class to a given peak rate and distribute it evenly across service class to a given peak rate and distribute it evenly across
each drop precedence. This would yield a proportional bandwidth each level of drop precedence. This would yield a proportional
service, which equally apportions available capacity during times of bandwidth service, which equally apportions available capacity during
congestion under the assumption that customers with high bandwidth times of congestion under the assumption that customers with high
microflows have subscribed to higher peak rates than customers with bandwidth microflows have subscribed to higher peak rates than
low bandwidth microflows. customers with low bandwidth microflows.
The AF PHB group could also be used to implement a low loss, low 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 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 the maximum arrival rate to that class is known a priori in each DS
node. Specification of the required admission control services, node. Specification of the required admission control services,
however, is beyond the scope of this document. however, is beyond the scope of this document.
References References
[Blake] Blake, Steve, et al., An Architecture for Differentiated [Blake] Blake, Steve, et al., An Architecture for Differentiated
Services. Internet draft draft-ietf-diffserv-arch-01.txt, August Services. Internet draft draft-ietf-diffserv-arch-01.txt, August
1998. 1998.
[Bradner] Bradner, S., Key words for use in RFCs to Indicate
Requirement Levels. Internet RFC 2119, March 1997.
[Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways
for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume
1, Number 4, August 1993, pp. 397-413.
[Nichols] Nichols, Kathleen, et al., Definition of the Differentiated [Nichols] Nichols, Kathleen, et al., Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet
draft draft-ietf-diffserv-header-02.txt, August 1998. draft draft-ietf-diffserv-header-02.txt, August 1998.
Author Information Author Information
Juha Heinanen Juha Heinanen
Telia Finland Telia Finland
Myyrmaentie 2 Myyrmaentie 2
01600 Vantaa, Finland 01600 Vantaa, Finland
skipping to change at line 299 skipping to change at page 7, line 21
Lucent Technologies Lucent Technologies
300 Baker Avenue, Suite 100, 300 Baker Avenue, Suite 100,
Concord, MA 01742-2168 Concord, MA 01742-2168
E-mail: wweiss@lucent.com E-mail: wweiss@lucent.com
John Wroclawski John Wroclawski
MIT Laboratory for Computer Science MIT Laboratory for Computer Science
545 Technology Sq. 545 Technology Sq.
Cambridge, MA 02139 Cambridge, MA 02139
Email: jtw@lcs.mit.edu Email: jtw@lcs.mit.edu
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
 End of changes. 36 change blocks. 
119 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/