An Expedited Forwarding PHB (Per-Hop Behavior)
obsoletes
- rfc-2598 — An Expedited Forwarding PHB
Extracted elements (25)
E_p can optionally be decomposed into E_fixed (minimum fixed delay through the node) plus E_variable to enable tighter jitter bounds; without decomposition, the delay bound D = B/R + E_p also serves as the jitter bound since minimum delay >= 0.
E_p may be specified as 'undefined' for schedulers performing non-FIFO intra-aggregate scheduling (e.g., per-microflow scheduling within EF). For such implementations, providing a meaningful worst-case bound on individual packet delay that holds for any traffic pattern may not be feasible.
Loss conformance is handled by an off-line test: lost packets are notionally removed from the input stream, and the equations are verified against the packets that successfully traversed the node. This avoids the impossibility of requiring conformance for packets that never departed.
RFC 3246 replaces RFC 2598 primarily by adding mathematical formalism to give a more rigorous definition. The original EF definition lacked equations that could be used to bound the delay of an individual EF packet; the new equations address this deficiency. Full rationale is in RFC 3247.
The formal definition uses two sets of equations: 'aggregate behavior' (eq_1/eq_2), which are packet-identity-unaware and describe service to the EF aggregate, and 'packet-identity-aware' (eq_3/eq_4), which enable bounding the delay of an individual EF packet. Both characterize a single device's behavior, not two modes.
The 'last bit' of a packet is defined to include the layer-2 trailer (if present) for both arrival time a_j/A_j and departure time d_j/D_j, because a packet cannot generally be considered available for forwarding until such a trailer has been received.
A Differentiated Services domain may provide multiple instances of EF simultaneously. Each instance must independently satisfy the Section 2.2 equations. E_a and E_p values per instance depend heavily on the scheduler implementation: multi-level priority schedulers may yield large error terms for lower-priority EF instances, while WFQ-like schedulers preserve smaller error terms.
A weighted round-robin scheduler implementing EF will typically not support R values as high as link speed, because the maximum EF service rate in the presence of competing traffic is bounded by the number of other queues and their weights. Its E_a is also typically higher than a strict priority queue implementation.
A node supporting EF MUST also satisfy the packet-identity-aware equations: D_j <= F_j + E_p (eq_3), where F_j = max(A_j, min(D_{j-1}, F_{j-1})) + L_j/R (eq_4). Unlike eq_1/eq_2, these track individual packet departure times rather than aggregate ordering.
A node supporting EF on interface I at configured rate R MUST satisfy the aggregate behavior equations: d_j <= f_j + E_a (eq_1), where f_j = max(a_j, min(d_{j-1}, f_{j-1})) + l_j/R (eq_2). These equations bound actual departure times against ideal departure times.
An EF-compliant node MUST be able to be characterized by the range of possible R values it can support on each interface while conforming to the aggregate equations, and the value of E_a that can be met. E_a MAY be specified as a worst-case value for all R or as a function of R.
An EF-compliant node SHOULD be able to be characterized by the range of R values and the value of E_p that can be met on each interface. E_p MAY be specified as worst-case, as a function of R, or as 'undefined' for schedulers where a meaningful bound cannot be provided.
DSCP codepoint 101110 is RECOMMENDED for the EF PHB.
If the EF PHB is implemented by a mechanism allowing unlimited preemption of other traffic (e.g., a strict 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, and the maximum EF rate and burst size MUST be settable by a network administrator.
In the event that packet loss occurs, those packets not lost MUST conform to the equations of Section 2.2. Conformance is tested off-line by removing lost packets from the input stream and verifying the remaining arrival/departure sequences satisfy eq_1 through eq_4.
Packets belonging to a single microflow within the EF aggregate passing through a device SHOULD NOT experience re-ordering in normal operation.
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 SHOULD NOT be demoted or promoted to another PHB by a DS domain.
The EF aggregate service equations of Section 2.2 MUST hold for a node independent of the amount of non-EF traffic offered to it.
When a DS-compliant node claims to implement the EF PHB, the implementation MUST conform to the specification given in this document. However, the EF PHB is NOT REQUIRED to be implemented in order for a node to be considered DS-compliant.
When EF packets are tunneled, the tunneling packets SHOULD be marked as EF.
The delay bound for EF traffic leaving a node interface is D = B/R + E_p (eq_5), where R is the configured EF service rate and B is the token bucket depth bounding the offered EF load at rate r <= R. Since minimum delay >= 0, D also bounds jitter.
The EF PHB is characterized by two error terms: E_a (aggregate error term, worst-case deviation between actual and ideal departure time for the EF aggregate) and E_p (per-packet error term, worst-case deviation for an individually tracked EF packet). E_p >= E_a typically.
This document allocates DSCP codepoint 101110 in Pool 1 of the code space defined by RFC 2474 for the EF PHB.
To protect against denial-of-service attacks, the edge of a DS domain SHOULD strictly police all EF-marked packets to a negotiated rate, dropping excess packets. If two adjacent domains have not negotiated an EF rate, the downstream domain SHOULD use 0 as the rate (i.e., drop all EF-marked packets).
Traffic conditioning at the ingress of a DS domain MUST ensure that only packets whose DSCPs correspond to EF when entering the domain are marked with an EF DSCP inside the domain. This protects against theft-of-service and DoS attacks exploiting unmarked or miscoded DSCPs.