An Expedited Forwarding PHB
obsoleted by
- rfc-3246 — An Expedited Forwarding PHB (Per-Hop Behavior)
Extracted elements (22)
Codepoint 101110 is recommended (not mandated) for the EF PHB. Remarking to other EF-satisfying codepoints at domain boundaries is permitted to allow flexibility in inter-domain operation.
Creating the EF service has two parts: (1) configuring nodes so the aggregate has a well-defined minimum departure rate independent of dynamic node state, and (2) conditioning the aggregate via policing and shaping so its arrival rate is always less than that node's configured minimum departure rate. The EF PHB handles part 1; boundary traffic conditioners handle part 2.
Low loss, latency, and jitter are all due to queuing delays. Providing these properties for an aggregate means ensuring the aggregate sees no (or very small) queues, which requires bounding rates so that at every transit node the aggregate's maximum arrival rate is less than the aggregate's minimum departure rate.
The EF PHB can be implemented by multiple queue scheduling mechanisms: a simple priority queue (best for jitter), weighted round-robin with the EF queue share equal to the configured rate, or a CBQ scheduler giving the EF queue priority up to the configured rate. Different choices yield different ancillary behaviors such as jitter seen by individual microflows.
The EF PHB can be used to build a Virtual Leased Line (VLL) service, also known as Premium service, which appears to endpoints like a point-to-point connection with quantified peak bandwidth. Simulation results confirm FTP flows over VLL achieve rates nearly identical to a dedicated link at the subscribed rate.
Other PHBs and PHB groups may be deployed in the same DS node or domain with the EF PHB as long as the EF minimum departure rate requirement is met. A priority-queue EF implementation must not preempt other traffic for more than a packet time at the configured rate, achievable via per-queue rate policers.
Simulation results show that weighted round-robin (WRR) implementations of EF PHB produce significantly more jitter than priority queue (PQ) implementations, especially for small packets. Increasing the WRR service-to-arrival ratio to at least 1.5 substantially reduces jitter, but WRR does not achieve PQ-level jitter performance.
If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic exceeding this limit MUST be discarded.
If two adjacent domains have not negotiated an EF rate, the downstream domain MUST use 0 as the rate, i.e., drop all EF marked packets.
Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.
The configured minimum departure rate MUST be settable by a network administrator using whatever mechanism the node supports for non-volatile configuration.
The departure rate of EF aggregate packets from any diffserv node MUST equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node.
The EF PHB SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU-sized packet at the configured rate. Behavior at time scales shorter than a packet time at the configured rate is deliberately not specified.
The maximum EF rate and burst size (if appropriate) MUST be settable by a network administrator via non-volatile configuration. The minimum and maximum rates may be the same and configured by a single parameter.
To protect against denial of service attacks, the edge of a DS domain MUST strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain (which must be <= the EF PHB configured rate). Packets in excess of the negotiated rate MUST be dropped.
Unexpected drops by the downstream domain's policer SHOULD be noted (e.g., via SNMP traps) as possible security violations or serious misconfiguration. Similarly, EF queue overflow drops SHOULD be noted as possible attacks or serious misconfiguration.
When EF packets are tunneled, the tunneling packets must be marked as EF.
The EF PHB is defined as a forwarding treatment for a diffserv aggregate where the departure rate from any diffserv node must equal or exceed a configurable rate, independent of other traffic. It provides the foundation for low loss, low latency, low jitter, assured bandwidth end-to-end service.
The EF PHB is not a mandatory part of the Differentiated Services architecture; a node is not required to implement the EF PHB to be DS-compliant. However, when a DS-compliant node claims to implement EF PHB, the implementation must conform to this specification.
This document allocates codepoint 101110 in Pool 1 of the code space defined by RFC 2474 as the recommended codepoint for the EF PHB.
Since properly configured upstream domains police and shape EF traffic, the downstream policer should never need to drop packets. Any drops by the downstream policer or EF queue overflow should be treated as indicators of possible security attacks or serious misconfiguration and logged (e.g., via SNMP traps).
The primary security threat addressed is denial-of-service attacks where excess EF-marked traffic from an upstream domain could exhaust node resources. Strict per-domain-edge policing to a negotiated rate, with mandatory drop of excess packets and zero-rate default when no rate is negotiated, are the countermeasures.