Assured Forwarding PHB Group
updated by
- rfc-3260 — New Terminology and Clarifications for Diffserv
Extracted elements (27)
Active queue management (e.g., RED) is required rather than simple tail-drop because gradual, randomized early discard provides proportional treatment across microflows and prevents global synchronization of TCP flows upon congestion.
Four AF classes with three drop precedence levels each were chosen for general use as a practical tradeoff providing meaningful service differentiation; more classes or precedence levels are explicitly permitted for local use to accommodate specialized deployment needs.
The non-reordering requirement exists because applications (and in particular TCP) can misinterpret reordering as packet loss and unnecessarily reduce their transmission rate. This applies regardless of whether packets are in or out of the traffic profile.
The specification deliberately does not mandate a specific active queue management algorithm, requiring only that certain behavioral properties hold, to allow flexibility across implementations and operating environments while maintaining end-to-end service consistency.
Any AF PHB implementation MUST document which other PHB groups may preempt AF forwarding resources (this MUST NOT happen in normal operation) and how excess resources are allocated between AF PHB and other PHB groups. Implementations MAY allow these relationships to be configurable.
The AF PHB group in conjunction with edge traffic conditioning can be used to obtain the overall behavior implied by the Class Selector PHBs; within a DS domain it may be appropriate to use some or all Class Selector codepoints as aliases of AF codepoints.
The recommended AF codepoint mappings do not interfere with the local use spaces nor the Class Selector codepoints defined in RFC 2474. The Default PHB codepoint '000000' may continue to be used for best-effort traffic, and '11x000' may remain for network control traffic.
A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) to each implemented AF class. Each class SHOULD be serviced in a manner to achieve the configured service rate over both small and large time scales.
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 are no quantifiable timing requirements associated with the forwarding of AF packets.
A DS node SHOULD implement all four general use AF classes. Packets in one AF class MUST be forwarded independently from packets in another AF class; a DS node MUST NOT aggregate two or more AF classes together.
An AF implementation MUST attempt to minimize long-term congestion within each class while allowing short-term congestion from bursts, requiring an active queue management algorithm such as RED.
An AF implementation MUST detect and respond to long-term congestion by dropping packets while handling short-term congestion by queueing. A smoothing or filtering function MUST monitor instantaneous congestion and compute a smoothed congestion level used by the dropping algorithm.
Congestion indication feedback to end nodes MUST be gradual rather than abrupt to allow the overall system to reach a stable operating point. RED uses two thresholds: no drop below first, linearly increasing drop probability between thresholds, and 100% drop above the second.
If a DS node only implements two different levels of loss probability for AF class x, codepoint AFx1 MUST yield the lower loss probability and AFx2 and AFx3 MUST yield the higher loss probability.
Implementations MUST specify what excess resource allocation algorithms are actually supported and how they can be parameterized when an AF class is configurable to receive more forwarding resources than the minimum.
The dropping algorithm control parameters MUST be independently configurable for each packet drop precedence and for each AF class, to allow AF PHB use in many different operating environments.
The dropping algorithm MUST be insensitive to short-term traffic characteristics of microflows: flows with different burst shapes but identical longer-term rates should have packets discarded with essentially equal probability, achievable via randomness in the dropping function.
The dropping algorithm MUST treat all packets within a single class and precedence level identically, so discard rate of a microflow's packets is proportional to that flow's share of total traffic through that precedence level.
Traffic conditioning actions at the edge of a DS domain MUST NOT cause reordering of packets of the same microflow, even when performing shaping, discarding, or reclassification.
When AF packets are tunneled, the PHB of the tunneling packet MUST NOT reduce the forwarding assurance of the tunneled AF packet nor cause reordering of AF packets belonging to the same microflow.
Within an AF class, a DS node MUST NOT forward an IP packet with smaller probability if it has drop precedence p than if it has drop precedence q when p < q, ensuring lower drop precedence packets are preferentially forwarded.
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. Three different levels SHOULD be supported in DS domains where congestion is common.
The AF PHB group defines N independent AF classes each with M drop precedence levels. A packet in AF class i with drop precedence j is marked AFij. Currently four classes (N=4) with three drop precedence levels (M=3) are defined for general use; additional classes or precedence levels MAY be defined for local use.
This document allocates twelve codepoints (AF11 through AF43) in Pool 1 of the DS codepoint space defined by RFC 2474. These codepoints do not overlap with any other general use PHB groups.
If a service offering requires that AF-marked traffic be limited by source or destination address attributes, it is the responsibility of the ingress node to verify the validity of such attributes.
To protect against denial of service attacks, a provider DS domain SHOULD limit traffic entering the domain to subscribed profiles. The provider SHOULD also allow the customer DS domain to specify how link resources are allocated to AF packets to protect customer-facing links from DoS.
AF codepoints are 6-bit DSCP values encoded in the DS field. Recommended values: AF11='001010', AF12='001100', AF13='001110', AF21='010010', AF22='010100', AF23='010110', AF31='011010', AF32='011100', AF33='011110', AF41='100010', AF42='100100', AF43='100110'.