draft-ietf-diffserv-af-02.txt   draft-ietf-diffserv-af-03.txt 
Internet Engineering Task Force Juha Heinanen Internet Engineering Task Force Juha Heinanen
INTERNET DRAFT Telia Finland INTERNET DRAFT Telia Finland
Expires April 1999 Fred Baker Expires May 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 November, 1998
Assured Forwarding PHB Group Assured Forwarding PHB Group
<draft-ietf-diffserv-af-02.txt> <draft-ietf-diffserv-af-03.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 52 skipping to change at page 2, line 52
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 and
offer up to two lower levels of forwarding assurance for the excess offer up to two lower levels of forwarding assurance for the excess
traffic. traffic.
This document describes the AF PHB group. An otherwise DS-compliant
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
implement an AF PHB group, it must conform to the specification in
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].
2. The AF PHB Group 2. The AF PHB Group
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
skipping to change at page 4, line 19 skipping to change at page 4, line 28
different levels of loss probability SHOULD be supported in DS different levels of loss probability SHOULD be supported in DS
domains where congestion is a 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. In any case, the discard
of drop precedence and a configurable averaging function (interval). control parameters for each precedence within an AF class MUST be
Future versions of this document may say more about specific aspects separately configurable. In the case of the RED algorithm, this means
of the desirable behavior. that the start-drop and hard-drop thresholds for each precedence
within a class must be separately configurable. Future versions of
this document may say more about 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, It is RECOMMENDED that the AF codepoints AF11, AF21, AF31, and AF41,
skipping to change at page 6, line 6 skipping to change at page 6, line 17
exists between the silver class and the bronze class. If desired, exists between the silver class and the bronze class. If desired,
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 dual leaky bucket traffic policer, which has as its by using a leaky bucket traffic policer, which has as its parameters
parameters a rate and two burst sizes: a committed burst and an a rate and two burst sizes: a committed burst and an excess burst.
excess burst. If a packet falls within the committed burst, it is If a packet falls within the committed burst, it is assigned low drop
assigned low drop precedence. If a packet falls between the precedence. If a packet falls between the committed burst and the
committed burst and the excess burst, it is assigned medium drop excess burst, it is assigned medium drop precedence. And finally, if
precedence. And finally, if the packet falls out of the excess burst, the packet falls out of the excess burst, it is assigned high drop
it is assigned high drop precedence. It may also be necessary to set precedence. It may also be necessary to set an upper limit to the
an upper limit to the amount of high drop precedence traffic from a amount of high drop precedence traffic from a customer DS domain in
customer DS domain in order to avoid the situation where an avalanche order to avoid the situation where an avalanche of undeliverable high
of undeliverable high drop precedence packets from one customer DS drop precedence packets from one customer DS domain can deny service
domain can deny service to possibly deliverable high drop precedence to possibly deliverable high drop precedence packets from other
packets from other domains. 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.
 End of changes. 6 change blocks. 
19 lines changed or deleted 28 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/