draft-ietf-diffserv-af-03.txt   draft-ietf-diffserv-af-04.txt 
Internet Engineering Task Force Juha Heinanen Internet Engineering Task Force Juha Heinanen
INTERNET DRAFT Telia Finland INTERNET DRAFT Telia Finland
Expires May 1999 Fred Baker Expires July 1999 Fred Baker
Cisco Systems Cisco Systems
Walter Weiss Walter Weiss
Lucent Technologies Lucent Technologies
John Wroclawski John Wroclawski
MIT LCS MIT LCS
November, 1998 January, 1999
Assured Forwarding PHB Group Assured Forwarding PHB Group
<draft-ietf-diffserv-af-03.txt> <draft-ietf-diffserv-af-04.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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
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 forwarding 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 within the class, (3)
precedence of the packet. what is the drop 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 forwarding 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 (i.e.,
offer up to two lower levels of forwarding assurance for the excess marked with the lowest drop precedence value) and offer up to two
traffic. lower levels of forwarding assurance for the excess traffic.
This document describes the AF PHB group. An otherwise DS-compliant This document describes the AF PHB group. An otherwise DS-compliant
node is not required to implement this PHB group in order to be node is not required to implement this PHB group in order to be
considered DS-compliant, but when a DS-compliant node is said to considered DS-compliant, but when a DS-compliant node is said to
implement an AF PHB group, it must conform to the specification in implement an AF PHB group, it must conform to the specification in
this document. this document.
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].
skipping to change at page 3, line 24 skipping to change at page 3, line 24
Assured Forwarding (AF) PHB group provides forwarding of IP packets Assured Forwarding (AF) PHB group provides forwarding of IP packets
in 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. with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M.
Currently, four classes (N=4) with three levels of drop precedence in Currently, four classes (N=4) with three levels of drop precedence in
each class (M=3) are defined for general use. More AF classes or each class (M=3) are defined for general use. More AF classes or
levels 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 SHOULD implement all four general use AF classes. Packets
bandwidth) to AF classes so that, under reasonable operating in one AF class MUST be forwarded independently from packets in
conditions and traffic loads, packets of an AF class x do not have another AF class, i.e., a DS node MUST NOT aggregate two or more AF
higher probability of timely forwarding than packets of an AF class y classes together.
if x < y. Similarly, within an AF class, an IP packet with drop
precedence p MUST NOT be forwarded with smaller probability than an A DS node MUST allocate a configurable, minimum amount of forwarding
IP packet with drop precedence q if p < q. resources (buffer space and bandwidth) to each implemented AF class.
Each class SHOULD be serviced in a manner to achieve the configured
service rate (bandwidth) over both small and large time scales.
An AF class MAY also be configurable to receive more forwarding
resources than the minimum when excess resources are available either
from other AF classes or from other PHB groups. This memo does not
specify how the excess resources should be allocated, but
implementations MUST specify what algorithms are actually supported
and how they can be parameterized.
Within an AF class, a DS node MUST NOT forward an IP packet with
smaller probability if it contains a drop precedence value p than if
it contains a drop precedence value q when p < q. Note that this
requirement can be fulfilled without needing to dequeue and discard
already-queued packets.
Within each AF class, a DS node MUST accept all three drop precedence
codepoints and they MUST yield at least two different levels of loss
probability. In some networks, particularly in enterprise networks,
where transient congestion is a rare and brief occurrence, it may be
reasonable for a DS node to implement only two different levels of
loss probability per AF class. While this may suffice for some
networks, three different levels of loss probability SHOULD be
supported in DS domains where congestion is a common occurrence.
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
probability and the codepoints AFx2 and AFx3 MUST yield the higher
loss probability.
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 quantifiable timing requirements (delay or delay There are no quantifiable timing requirements (delay or delay
variation) associated with the forwarding of AF packets. variation) associated with the forwarding of AF packets.
The relationship between AF classes and other PHBs is described in
Section 7 of this memo.
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 exits the domain at various levels of drop
precedence. Such traffic conditioning actions MAY include traffic precedence. Such traffic conditioning actions MAY include traffic
shaping, discarding of packets, increasing or decreasing the drop shaping, discarding of packets, increasing or decreasing the drop
precedence of packets, and reassigning of packets to other AF precedence of packets, and reassigning of packets to other AF
classes. The traffic conditioning actions MUST NOT cause reordering classes. The traffic conditioning actions MUST NOT cause reordering
of packets of the same microflow. 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 This section defines the queueing and discard behavior of the AF PHB
in one AF class MUST be forwarded independently from packets in group. Other aspects of the PHB groups's behavior are defined in
another AF class, i.e., a DS node MUST NOT aggregate two or more AF Section 2.
classes together.
Within each AF class, a DS node MUST accept all three drop precedence An AF implementation MUST attempt to minimize long-term congestion
codepoints and they MUST yield at least two different levels of loss within each class, while allowing short-term congestion resulting
probability. In some networks, particularly in enterprise networks, from bursts. This requires an active queue management algorithm. An
where transient congestion is a rare and brief occurrence, it may be example of such an algorithm is Random Early Drop (RED) [Floyd].
reasonable for a DS node to implement only two different levels of This memo does not specify the use of a particular algorithm, but
loss probability. While this may suffice for some networks, three does require that several properties hold.
different levels of loss probability SHOULD be supported in DS
domains where congestion is a common occurrence.
If a DS node only implements two different levels of loss probability An AF implementation MUST detect and respond to long-term congestion
for an AF class x, the codepoint AFx1 MUST yield the lower loss within each class by dropping packets, while handling short-term
probability and the codepoints AFx2 and AFx3 MUST yield the higher congestion (packet bursts) by queueing packets. This implies the
loss probability. presence of a smoothing or filtering function that monitors the
instantaneous congestion level and computes a smoothed congestion
level. The dropping algorithm uses this smoothed congestion level to
determine when packets should be discarded.
Inconsistent discard behaviors lead to inconsistent end-to-end The dropping algorithm MUST be insensitive to the short-term traffic
service semantics. It is RECOMMENDED that the discard mechanism is characteristics of the microflows using an AF class. That is, flows
based on a RED-like [Floyd] algorithm. In any case, the discard with different short-term burst shapes but identical longer-term
control parameters for each precedence within an AF class MUST be packet rates should have packets discarded with essentially equal
separately configurable. In the case of the RED algorithm, this means probability. One way to achieve this is to use randomness within the
that the start-drop and hard-drop thresholds for each precedence dropping function.
within a class must be separately configurable. Future versions of
this document may say more about specific aspects of the desirable The dropping algorithm MUST treat all packets within a single class
behavior. and precedence level identically. This implies that for any given
smoothed congestion level, the discard rate of a particular
microflow's packets within a single precedence level will be
proportional to that flow's percentage of the total amount of traffic
passing through that precedence level.
The congestion indication feedback to the end nodes, and thus the
level of packet discard at each drop precedence in relation to
congestion, MUST be gradual rather than abrupt, to allow the overall
system to reach a stable operating point. One way to do this (RED)
uses two (configurable) smoothed congestion level thresholds. When
the smoothed congestion level is below the first threshold, no
packets of the relevant precedence are discarded. When the smoothed
congestion level is between the first and the second threshold,
packets are discarded with linearly increasing probability, ranging
from zero to a configurable value reached just prior to the second
threshold. When the smoothed congestion level is above the second
threshold, packets of the relevant precedence are discarded with 100%
probability.
To allow the AF PHB to be used in many different operating
environments, the dropping algorithm control parameters MUST be
independently configurable for each packet drop precedence and for
each AF class.
Within the limits above, this specification allows for a range of
packet discard behaviors. Inconsistent discard behaviors lead to
inconsistent end-to-end service semantics and limit the range of
possible uses of the AF PHB in a multi-vendor environment. As
experience is gained, future versions of this document may more
tightly define specific aspects 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 forwarding assurance of the tunneled AF packet nor NOT reduce the forwarding assurance of the tunneled AF packet nor
cause 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, Recommended codepoints for the four general use AF classes are given
i.e., the codepoints that denote the lowest drop precedence in each below. These codepoints do not overlap with any other general use PHB
AF class, are mapped to the Class Selector [Nichols] codepoints groups.
'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:
AF12 = '010010', AF13 = '010100', AF22 = '011010', AF23 = '011100', The RECOMMENDED values of the AF codepoints are as follows: AF11 =
AF32 = '100010', AF33 = '100100', AF42 = '101010', and AF43 = '001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 =
'101100'. The table below summarizes the recommended AF codepoint '010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 =
values. '011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. 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 Prec | 010000 | 011000 | 100000 | 101000 | Low Drop Prec | 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 010010 | 011010 | 100010 | 101010 | Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec | 010100 | 011100 | 100100 | 101100 | High Drop Prec | 001110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
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 the Class Selector codepoints recommended in
'11x000'. The PHBs selected by those Class Selector codepoints may [Nichols]. 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
behavior and relationships that was defined for them in [Nichols]. and relationships that was defined for them. In particular, the
In particular, the Default PHB codepoint of '000000' may remain to be Default PHB codepoint of '000000' may remain to be used for
used for conventional best effort traffic. Similarly, the codepoints conventional best effort traffic. Similarly, the codepoints '11x000'
'11x000' may remain to be used for network control traffic. may remain to be used for network control traffic.
The AF PHB group, in conjunction with edge traffic conditioning
actions that limit the amount of traffic in each AF class to a
(generally different) percentage of the class's allocated resources,
can be used to obtain the overall behavior implied by the Class
Selector PHBs. In this case it may be appropriate within a DS domain
to use some or all of the Class Selector codepoints as aliases of AF
codepoints.
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 PHB group within the same DS domain. However, any
other PHB groups don't preempt the resources allocated to the AF DS node that supports the AF PHB group MUST determine the following:
classes.
(a) Which, if any, other PHB groups may preempt the forwarding
resources specifically allocated to each AF PHB class. This
preemption MUST NOT happen in normal network operation, but may be
appropriate in certain unusual situations - for example, the '11x000'
codepoint may preempt AF forwarding resources, to give precedence to
unexpectedly high levels of network control traffic when required.
(b) How "excess" resources are allocated between the AF PHB group and
other implemented PHB groups. For example, once the minimum
allocations are given to each AF class, any remaining resources could
be allocated evenly between the AF classes and the Default PHB. In
an alternative example, any remaining resources could be allocated to
forwarding excess AF traffic, with resources devoted to the Default
PHB only when all AF demand is met.
This memo does not specify that any particular relationship hold
between AF PHB groups and other implemented PHB groups; it requires
only that whatever relationship is chosen be documented.
Implementations MAY allow either or both of these relationships to be
configurable. It is expected that this level of configuration
flexibility will prove valuable to many network administrators.
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 SHOULD limit the traffic entering the domain to provider DS domain SHOULD limit the traffic entering the domain to
the subscribed profiles. Also, in order to protect a link to a the subscribed profiles. Also, in order to protect a link to a
customer DS domain from denial of service attacks, the provider DS customer DS domain from denial of service attacks, the provider DS
domain SHOULD allow the customer DS domain to specify how the domain SHOULD allow the customer DS domain to specify how the
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
skipping to change at page 6, line 18 skipping to change at page 8, line 5
packets within each class may be further separated by giving them packets within each class may be further separated by giving them
either low, medium, or high drop precedence. either low, medium, or high drop precedence.
The bronze, silver, and gold service classes could 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 levels 1, 2, high drop precedence may be mapped to AF drop precedence levels 1, 2,
or 3. or 3.
The drop precedence level of a packet could be assigned, for example, The drop precedence level of a packet could be assigned, for example,
by using a leaky bucket traffic policer, which has as its parameters by using a leaky bucket traffic policer, which has as its parameters
a rate and two burst sizes: a committed burst and an excess burst. a rate and a size, which is the sum of two burst values: a committed
If a packet falls within the committed burst, it is assigned low drop burst size and an excess burst size. A packet is assigned low drop
precedence. If a packet falls between the committed burst and the precedence if the number of tokens in the bucket is greater than the
excess burst, it is assigned medium drop precedence. And finally, if excess burst size, medium drop precedence if the number of tokens in
the packet falls out of the excess burst, it is assigned high drop the bucket is greater than zero, but at most the excess burst size,
precedence. It may also be necessary to set an upper limit to the and high drop precedence if the bucket is empty. It may also be
amount of high drop precedence traffic from a customer DS domain in necessary to set an upper limit to the amount of high drop precedence
order to avoid the situation where an avalanche of undeliverable high traffic from a customer DS domain in order to avoid the situation
drop precedence packets from one customer DS domain can deny service where an avalanche of undeliverable high drop precedence packets from
to possibly deliverable high drop precedence packets from other one customer DS domain can deny service to possibly deliverable high
domains. drop precedence packets from other domains.
Another way to assign the drop precedence level of a packet could be Another way to assign the drop precedence level of a packet could be
to limit the user traffic of an Olympic service class to a given peak to limit the user traffic of an Olympic service class to a given peak
rate and distribute it evenly across each level of drop precedence. rate and distribute it evenly across each level of drop precedence.
This would yield a proportional bandwidth service, which equally This would yield a proportional bandwidth service, which equally
apportions available capacity during times of congestion under the apportions available capacity during times of congestion under the
assumption that customers with high bandwidth microflows have assumption that customers with high bandwidth microflows have
subscribed to higher peak rates than customers with low bandwidth subscribed to higher peak rates than customers with low bandwidth
microflows. 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 loss and low
delay, and low jitter service using an over provisioned AF class, if latency service using an over provisioned AF class, if the maximum
the maximum arrival rate to that class is known a priori in each DS arrival rate to that class is known a priori in each DS node.
node. Specification of the required admission control services, Specification of the required admission control services, however, is
however, is beyond the scope of this document. beyond the scope of this document. If low loss is not an objective,
a low latency service could be implemented without over provisioning
by setting a low maximum limit to the buffer space available for an
AF class.
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. RFC 2475, December 1998.
1998.
[Bradner] Bradner, S., Key words for use in RFCs to Indicate [Bradner] Bradner, S., Key words for use in RFCs to Indicate
Requirement Levels. Internet RFC 2119, March 1997. Requirement Levels. RFC 2119, March 1997.
[Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways [Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways
for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume
1, Number 4, August 1993, pp. 397-413. 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. RFC 2474,
draft draft-ietf-diffserv-header-02.txt, August 1998. December 1998.
Author Information Author Information
Juha Heinanen Juha Heinanen
Telia Finland Telia Finland
Myyrmaentie 2 Myyrmaentie 2
01600 Vantaa, Finland 01600 Vantaa, Finland
Email: jh@telia.fi Email: jh@telia.fi
Fred Baker Fred Baker
 End of changes. 22 change blocks. 
88 lines changed or deleted 176 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/