draft-ietf-diffserv-af-01.txt   draft-ietf-diffserv-af-02.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
INTERNET DRAFT Telia Finland INTERNET DRAFT Telia Finland
Expires April 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
October, 1998 October, 1998
Assured Forwarding PHB Group Assured Forwarding PHB Group
<draft-ietf-diffserv-af-01.txt> <draft-ietf-diffserv-af-02.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), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This document proposes a general use Differentiated Services (DS) This document defines 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 does 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 provide assured forwarding of IP packets over
Internet. In a typical application, a company uses the Internet to the Internet. In a typical application, a company uses the Internet
connect its geographically distributed sites and wants an assurance to interconnect its geographically distributed sites and wants an
that IP packets within this intranet are delivered with high assurance that IP packets within this intranet are forwarded with
probability as long as the aggregate traffic from each site does not high probability as long as the aggregate traffic from each site does
exceed the subscribed information rate (profile). It is desirable not exceed the subscribed information rate (profile). It is
that a site may exceed the subscribed profile with the understanding desirable that a site may exceed the subscribed profile with the
that the excess traffic is not delivered with as high a probability understanding that the excess traffic is not delivered with as high
as the traffic that is within the profile. It is also important that probability as the traffic that is within the profile. It is also
the network does not reorder packets that belong to the same important that the network does not reorder packets that belong to
microflow no matter if they are in or out of the profile. 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 Assured Forwarding (AF) PHB group is a means for a provider DS domain
to offer different levels of delivery assurances for IP packets to offer different levels of forwarding assurances for IP packets
received from a customer DS domain. Four AF classes are defined, received from a customer DS domain. Four AF classes are defined,
where each AF class is in each DS node allocated a certain amount of where each AF class is in each DS node allocated a certain amount of
forwarding resources (buffer space, bandwidth). IP packets that wish forwarding resources (buffer space and bandwidth). IP packets that
to use the services provided by the AF PHB group are assigned by the wish to use the services provided by the AF PHB group are assigned by
customer or the provider DS domain into one or more of these AF the customer or the provider DS domain into one or more of these AF
classes according to the subscribed services. classes according to the services that the customer has subscribed
to.
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 preferably discarding packets precedence value from being lost by preferably discarding packets
with a higher drop precedence value. with a higher drop precedence value.
In a DS node, the level of delivery assurance of an IP packet thus In a DS node, the level of forwarding assurance of an IP packet thus
depends on (1) how much forwarding resources has been allocated to 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 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 of the AF class, and, in case of congestion, (3) 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 forwarding
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 forwarding assurance for the excess
traffic. traffic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [Bradner]. 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 forwarding of IP packets
N independent AF classes. Within each AF class, an IP packet is in 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 codepoint AFij, where 1 <= i <= N and 1 <= j <= M. At with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M.
this point, four classes (N=4) with three drop precedences in each Currently, four classes (N=4) with three levels of drop precedence in
class (M=3) are defined for general use. More AF classes or levels each class (M=3) are defined for general use. More AF classes or
of drop precedence MAY be defined for local use. 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, an AF class bandwidth) to AF classes so that, under reasonable operating
x has no more forwarding resources than an AF class y if x < y. conditions and traffic loads, packets of an AF class x do not have
Similarly, within an AF class, an IP packet with drop precedence p higher probability of timely forwarding than packets of an AF class y
MUST NOT be delivered with smaller probability than an IP packet with if x < y. Similarly, within an AF class, an IP packet with drop
drop precedence q if p < q. precedence p MUST NOT be forwarded with smaller probability than an
IP packet with 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 are no timing requirements (delay or delay variation) There are no quantifiable timing requirements (delay or delay
associated with the forwarding of AF packets. variation) associated with the forwarding of AF packets.
The AF PHB group MAY be used to implement both end-to-end and domain The AF PHB group MAY be used to implement both end-to-end and domain
edge-to-domain edge services. edge-to-domain edge services.
3. Traffic Conditioning Actions 3. Traffic Conditioning Actions
A DS domain MAY at the edge of a domain control the amount of AF A DS domain MAY at the edge of a domain control the amount of AF
traffic that enters or exists the domain at various levels of drop traffic that enters or exists the domain at various levels of drop
precedence. The traffic conditioning actions MAY include discarding precedence. Such traffic conditioning actions MAY include traffic
of packets, increasing or decreasing the drop precedence of packets, shaping, discarding of packets, increasing or decreasing the drop
and reassigning of packets to other AF classes. The latter action precedence of packets, and reassigning of packets to other AF
MUST NOT distribute packets of the same microflow to more than one AF classes. The traffic conditioning actions MUST NOT cause reordering
class. of packets of the same microflow.
4. Queueing and Discard Behavior 4. Queueing and Discard Behavior
A DS node SHOULD implement all four general use AF classes. Packets A DS node SHOULD implement all four general use AF classes. Packets
in one AF class MUST be forwarded independently from packets in in one AF class MUST be forwarded independently from packets in
another AF class, i.e., a DS node MUST NOT aggregate two or more AF another AF class, i.e., a DS node MUST NOT aggregate two or more AF
classes together. classes together.
Within each AF class, the three drop precedence codepoints MUST yield Within each AF class, a DS node MUST accept all three drop precedence
at least two different levels of loss probability. In some networks, codepoints and they MUST yield at least two different levels of loss
particularly in enterprise networks, where transient congestion is a probability. In some networks, particularly in enterprise networks,
rare and brief occurrence, it may be reasonable for a DS node to where transient congestion is a rare and brief occurrence, it may be
support only two different levels of loss probability. While this reasonable for a DS node to implement only two different levels of
may suffice for some networks, three different levels of loss loss probability. While this may suffice for some networks, three
probability SHOULD be supported in DS domains where congestion is a different levels of loss probability SHOULD be supported in DS
common occurrence. domains where congestion is a common occurrence.
If a DS node only implements two different levels of loss probability If a DS node only implements two different levels of loss probability
for an AF class x, the codepoint AFx1 MUST yield the lower loss for an AF class x, the codepoint AFx1 MUST yield the lower loss
probability and the codepoints AFx2 and AFx3 MUST yield the higher probability and the codepoints AFx2 and AFx3 MUST yield the higher
loss probability. loss probability.
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 [Floyd] algorithm with three configurable levels based on a RED-like [Floyd] algorithm with three configurable levels
of drop precedence and a configurable averaging function (interval). of drop precedence and a configurable averaging function (interval).
Future versions of this document may say more about specific aspects Future versions of this document may say more about specific aspects
of the desirable behavior. of the desirable behavior.
5. Tunneling 5. Tunneling
When AF packets are tunneled, the PHB of the tunneling packet MUST When AF packets are tunneled, the PHB of the tunneling packet MUST
NOT reduce the delivery assurance of the tunneled AF packet nor cause NOT reduce the forwarding assurance of the tunneled AF packet nor
reordering of AF packets belonging to the same microflow. cause reordering of AF packets belonging to the same microflow.
6. Recommended Codepoints 6. Recommended Codepoints
It is RECOMMENDED that the AF codepoints AF11, AF21, AF31, and AF41, 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:
AF12 = '010010', AF13 = '010100', AF22 = '011010', AF23 = '011100', AF12 = '010010', AF13 = '010100', AF22 = '011010', AF23 = '011100',
AF32 = '100010', AF33 = '100100', AF42 = '101010', and AF43 = AF32 = '100010', AF33 = '100100', AF42 = '101010', and AF43 =
'101100'. The table below summarizes the recommended AF codepoint '101100'. The table below summarizes the recommended AF codepoint
values. 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 Prec | 010000 | 011000 | 100000 | 101000 |
Medium Drop Pref | 010010 | 011010 | 100010 | 101010 | Medium Drop Prec | 010010 | 011010 | 100010 | 101010 |
High Drop Pref | 010100 | 011100 | 100100 | 101100 | High Drop Prec | 010100 | 011100 | 100100 | 101100 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
7. Interactions with Other PHB Groups 7. Interactions with Other PHB Groups
The AF codepoint mappings recommended above do not interfere with the The AF codepoint mappings recommended above do not interfere with the
local use spaces nor use the Class Selector codepoints '00x000' and local use spaces nor use the Class Selector codepoints '00x000' and
'11x000'. The PHBs selected by those Class Selector codepoints may '11x000'. The PHBs selected by those Class Selector codepoints may
thus coexist with the AF PHB group, and retain the forwarding thus coexist with the AF PHB group, and retain the forwarding
behavior and relationships that was defined for them in [Nichols]. behavior and relationships that was defined for them in [Nichols].
In particular, the Default PHB codepoint of '000000' may remain to be In particular, the Default PHB codepoint of '000000' may remain to be
skipping to change at page 5, line 38 skipping to change at page 5, line 38
resources of the link are allocated to AF packets. If a service resources of the link are allocated to AF packets. If a service
offering requires that traffic marked with an AF codepoint be limited offering requires that traffic marked with an AF codepoint be limited
by such attributes as source or destination address, it is the by such attributes as source or destination address, it is the
responsibility of the ingress node in a network to verify validity of responsibility of the ingress node in a network to verify validity of
such attributes. such attributes.
Other security considerations are covered in [Blake] and [Nichols]. Other security considerations are covered in [Blake] and [Nichols].
Appendix: Example Services Appendix: Example Services
The AF PHB group may be used to implement, for example, the so-called The AF PHB group could be used to implement, for example, the so-
Olympic service, which consists of three service classes: bronze, called Olympic service, which consists of three service classes:
silver, and gold. Packets are assigned to these three classes so bronze, silver, and gold. Packets are assigned to these three
that packets in the gold class experience lighter load (and thus have classes so that packets in the gold class experience lighter load
greater probability for timely delivery) than packets assigned to the (and thus have greater probability for timely forwarding) than
silver class. Same kind of relationship exists between the silver packets assigned to the silver class. Same kind of relationship
class and the bronze class. If desired, packets within each class exists between the silver class and the bronze class. If desired,
may be further separated by giving them either low, medium, or high packets within each class may be further separated by giving them
drop precedence. either low, medium, or high drop precedence.
The bronze, silver, and gold service classes may in the network be The bronze, silver, and gold service classes could 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 may be mapped to AF drop precedence indexes 1, high drop precedence may be mapped to AF drop precedence levels 1, 2,
2, or 3. or 3.
The drop precedence level of a packet may be assigned, for example, The drop precedence level of a packet could 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. It may also be necessary to set
an upper limit to the amount of high drop precedence traffic from a
customer DS domain in order to avoid the situation where an avalanche
of undeliverable high drop precedence packets from one customer DS
domain can deny service to possibly deliverable high drop precedence
packets from other domains.
Another possibility would be to limit the user traffic of an Olympic Another way to assign the drop precedence level of a packet could be
service class to a given peak rate and distribute it evenly across to limit the user traffic of an Olympic service class to a given peak
each level of drop precedence. This would yield a proportional rate and distribute it evenly across each level of drop precedence.
bandwidth service, which equally apportions available capacity during This would yield a proportional bandwidth service, which equally
times of congestion under the assumption that customers with high apportions available capacity during times of congestion under the
bandwidth microflows have subscribed to higher peak rates than assumption that customers with high bandwidth microflows have
customers with low bandwidth microflows. 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 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
 End of changes. 23 change blocks. 
74 lines changed or deleted 82 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/