draft-ietf-diffserv-rfc2598bis-02.txt   rfc3246.txt 
Network Working Group Bruce Davie, Editor Network Working Group B. Davie
Internet Draft Anna Charny Request for Comments: 3246 A. Charny
Expiration Date: March 2002 Fred Baker Obsoletes: 2598 Cisco Systems, Inc.
Cisco Systems, Inc. Category: Standards Track J.C.R. Bennett
Jon Bennet Motorola
Riverdelta Networks K. Benson
Tellabs
Kent Benson Jean-Yves Le Boudec J.Y. Le Boudec
Tellabs EPFL EPFL
W. Courtney
Angela Chiu William Courtney TRW
AT&T Labs TRW S. Davari
PMC-Sierra
Shahram Davari Victor Firoiu V. Firoiu
PMC-Sierra Nortel Networks Nortel Networks
D. Stiliadis
Charles Kalmanek K.K. Ramakrishnam Lucent Technologies
AT&T Research TeraOptic Networks March 2002
Dimitrios Stiliadis
Lucent Technologies
September 2001
An Expedited Forwarding PHB
draft-ietf-diffserv-rfc2598bis-02.txt An Expedited Forwarding PHB (Per-Hop Behavior)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a product of the Diffserv working group of the
Internet Engineering Task Force. Please address comments to the
group's mailing list at diffserv@ietf.org, with a copy to the
authors.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The PHB (per-hop behavior) is a basic building block in the This document defines a PHB (per-hop behavior) called Expedited
Differentiated Services architecture. This document defines a PHB Forwarding (EF). The PHB is a basic building block in the
called Expedited Forwarding (EF). EF is intended to provide a Differentiated Services architecture. EF is intended to provide a
building block for low delay, low jitter and low loss services by building block for low delay, low jitter and low loss services by
ensuring that the EF aggregate is served at a certain configured ensuring that the EF aggregate is served at a certain configured
rate. rate. This document obsoletes RFC 2598.
Contents
1 Introduction ........................................... 3
1.1 Relationship to RFC 2598 ............................... 4
2 Definition of EF PHB ................................... 4
2.1 Intuitive Description of EF ............................ 4
2.2 Formal Definition of the EF PHB ........................ 6
2.3 Figures of merit ....................................... 9
2.4 Delay and jitter ....................................... 9
2.5 Loss ................................................... 10
2.6 Microflow misordering .................................. 10
2.7 Recommended codepoint for this PHB ..................... 11
2.8 Mutability ............................................. 11
2.9 Tunneling .............................................. 11
2.10 Interaction with other PHBs ............................ 11
3 Security Considerations ................................ 11
4 IANA Considerations .................................... 12
5 Acknowledgments ........................................ 12
6 References ............................................. 12
7 Full Copyright ......................................... 16
Specification of Requirements Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1 Introduction ........................................... 2
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.1 Relationship to RFC 2598 ............................... 3
document are to be interpreted as described in RFC 2119 [3]. 2 Definition of EF PHB ................................... 3
2.1 Intuitive Description of EF ............................ 3
2.2 Formal Definition of the EF PHB ........................ 5
2.3 Figures of merit ....................................... 8
2.4 Delay and jitter ....................................... 8
2.5 Loss ................................................... 9
2.6 Microflow misordering .................................. 9
2.7 Recommended codepoint for this PHB ..................... 9
2.8 Mutability ............................................. 10
2.9 Tunneling .............................................. 10
2.10 Interaction with other PHBs ............................ 10
3 Security Considerations ................................ 10
4 IANA Considerations .................................... 11
5 Acknowledgments ........................................ 11
6 References ............................................. 11
Appendix: Implementation Examples .............................. 12
Authors' Addresses ............................................. 14
Full Copyright Statement ....................................... 16
1. Introduction 1. Introduction
Network nodes that implement the differentiated services enhancements Network nodes that implement the differentiated services enhancements
to IP use a codepoint in the IP header to select a per-hop behavior to IP use a codepoint in the IP header to select a per-hop behavior
(PHB) as the specific forwarding treatment for that packet [3, 4]. (PHB) as the specific forwarding treatment for that packet [3, 4].
This memo describes a particular PHB called expedited forwarding This memo describes a particular PHB called expedited forwarding
(EF). (EF).
The intent of the EF PHB is to provide a building block for low loss, The intent of the EF PHB is to provide a building block for low loss,
low delay, and low jitter services. The details of exactly how to low delay, and low jitter services. The details of exactly how to
build such services are outside the scope of this specification. build such services are outside the scope of this specification.
The dominant causes of delay in packet networks are fixed propagation The dominant causes of delay in packet networks are fixed propagation
delays (e.g. those arising from speed-of-light delays) on wide area delays (e.g. those arising from speed-of-light delays) on wide area
links and queuing delays in switches and routers. Since propagation links and queuing delays in switches and routers. Since propagation
delays are a fixed property of the topology, delay and jitter are delays are a fixed property of the topology, delay and jitter are
minimized when queueing delays are minimized. In this context, jitter minimized when queuing delays are minimized. In this context, jitter
is defined as the variation between maximum and minimum delay. The is defined as the variation between maximum and minimum delay. The
intent of the EF PHB is to provide a PHB in which suitably marked intent of the EF PHB is to provide a PHB in which suitably marked
packets usually encounter short or empty queues. Furthermore, if packets usually encounter short or empty queues. Furthermore, if
queues remain short relative to the buffer space available, packet queues remain short relative to the buffer space available, packet
loss is also kept to a minimum. loss is also kept to a minimum.
To ensure that queues encountered by EF packets are usually short, it To ensure that queues encountered by EF packets are usually short, it
is necessary to ensure that the service rate of EF packets on a given is necessary to ensure that the service rate of EF packets on a given
output interface exceeds their arrival rate at that interface over output interface exceeds their arrival rate at that interface over
long and short time intervals, independent of the load of other long and short time intervals, independent of the load of other
(non-EF) traffic. This specification defines a PHB in which EF (non-EF) traffic. This specification defines a PHB in which EF
packets are guaranteed to receive service at or above a configured packets are guaranteed to receive service at or above a configured
rate and provides a means to quantify the accuracy with which this rate and provides a means to quantify the accuracy with which this
service rate is delivered over any time interval. It also provides a service rate is delivered over any time interval. It also provides a
means to quantify the maximum delay and jitter that a packet may means to quantify the maximum delay and jitter that a packet may
experience under bounded operating conditions. experience under bounded operating conditions.
Note that the EF PHB only defines the behavior of a single node. The Note that the EF PHB only defines the behavior of a single node. The
specification of behavior of a collection of nodes is outside the specification of behavior of a collection of nodes is outside the
scope of this document. A Per-Domain Behavior (PDB) specification [7] scope of this document. A Per-Domain Behavior (PDB) specification
may provide such information. [7] may provide such information.
When a DS-compliant node claims to implement the EF PHB, the When a DS-compliant node claims to implement the EF PHB, the
implementation MUST conform to the specification given in this implementation MUST conform to the specification given in this
document. However, the EF PHB is not a mandatory part of the document. However, the EF PHB is not a mandatory part of the
Differentiated Services architecture - a node is NOT REQUIRED to Differentiated Services architecture - a node is NOT REQUIRED to
implement the EF PHB in order to be considered DS-compliant. implement the EF PHB in order to be considered DS-compliant.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
1.1. Relationship to RFC 2598 1.1. Relationship to RFC 2598
This document replaces RFC 2598 [1]. The main difference is that it This document replaces RFC 2598 [1]. The main difference is that it
adds mathematical formalism to give a more rigorous definition of the adds mathematical formalism to give a more rigorous definition of the
behavior described. The full rationale for this is given in [6]. behavior described. The full rationale for this is given in [6].
2. Definition of EF PHB 2. Definition of EF PHB
2.1. Intuitive Description of EF 2.1. Intuitive Description of EF
Intuitively, the definition of EF is simple: the rate at which EF Intuitively, the definition of EF is simple: the rate at which EF
traffic is served at a given output interface should be at least the traffic is served at a given output interface should be at least the
configured rate R, over a suitably defined interval, independent of configured rate R, over a suitably defined interval, independent of
the offered load of non-EF traffic to that interface. Two the offered load of non-EF traffic to that interface. Two
difficulties arise when we try to formalize this intuition: difficulties arise when we try to formalize this intuition:
- it is difficult to define the appropriate timescale at which to - it is difficult to define the appropriate timescale at which to
measure R. By measuring at short timescales we may introduce measure R. By measuring it at short timescales we may introduce
sampling errors; at long timescales we may allow excessive jitter. sampling errors; at long timescales we may allow excessive
jitter.
- EF traffic clearly cannot be served at rate R if there are no EF - EF traffic clearly cannot be served at rate R if there are no
packets waiting to be served, but it may be impossible to EF packets waiting to be served, but it may be impossible to
determine externally whether EF packets are actually waiting to be determine externally whether EF packets are actually waiting to
served by the output scheduler. For example, if an EF packet has be served by the output scheduler. For example, if an EF
entered the router and not exited, it may be awaiting service, or packet has entered the router and not exited, it may be
it may simply have encountered some processing or transmission awaiting service, or it may simply have encountered some
delay within the router. processing or transmission delay within the router.
The formal definition below takes account of these issues. It assumes The formal definition below takes account of these issues. It
that EF packets should ideally be served at rate R or faster, and assumes that EF packets should ideally be served at rate R or faster,
bounds the deviation of the actual departure time of each packet from and bounds the deviation of the actual departure time of each packet
the "ideal" departure time of that packet. We define the departure from the "ideal" departure time of that packet. We define the
time of a packet as the time when the last bit of that packet leaves departure time of a packet as the time when the last bit of that
the node. The "ideal" departure time of each EF packet is computed packet leaves the node. The "ideal" departure time of each EF packet
iteratively. is computed iteratively.
In the case when an EF packet arrives at a device when all the In the case when an EF packet arrives at a device when all the
previous EF packets have already departed, the computation of the previous EF packets have already departed, the computation of the
ideal departure time is simple. Service of the packet should ideal departure time is simple. Service of the packet should
(ideally) start as soon as it arrives, so the ideal departure time is (ideally) start as soon as it arrives, so the ideal departure time is
simply the arrival time plus the ideal time to transmit the packet at simply the arrival time plus the ideal time to transmit the packet at
rate R. For a packet of length L_j, that transmission time at the rate R. For a packet of length L_j, that transmission time at the
configured rate R is L_j/R. (Of course, a real packet will typically configured rate R is L_j/R. (Of course, a real packet will typically
get transmitted at line rate once its transmission actually starts, get transmitted at line rate once its transmission actually starts,
but we are calculating the ideal target behavior here; the ideal but we are calculating the ideal target behavior here; the ideal
service takes place at rate R.) service takes place at rate R.)
In the case when an EF packet arrives at a device that still contains In the case when an EF packet arrives at a device that still contains
EF packets awaiting service, the computation of the ideal departure EF packets awaiting service, the computation of the ideal departure
time is more complicated. There are two cases to be considered. If time is more complicated. There are two cases to be considered. If
the previous (j-1-th) departure occurred after its own ideal the previous (j-1-th) departure occurred after its own ideal
departure time, then the scheduler is running "late". In this case, departure time, then the scheduler is running "late". In this case,
the ideal time to start service of the new packet is the ideal the ideal time to start service of the new packet is the ideal
departure time of the previous (j-1-th) packet, or the arrival time departure time of the previous (j-1-th) packet, or the arrival time
of the new packet, whichever is later, because we can't expect a of the new packet, whichever is later, because we cannot expect a
packet to begin service before it arrives. If the previous (j-1-th) packet to begin service before it arrives. If the previous (j-1-th)
departure occurred before its own ideal departure time, then the departure occurred before its own ideal departure time, then the
scheduler is running "early". In this case, service of the new packet scheduler is running "early". In this case, service of the new
should begin at the actual departure time of the previous packet. packet should begin at the actual departure time of the previous
packet.
Once we know the time at which service of the jth packet should Once we know the time at which service of the j-th packet should
(ideally) begin, then the ideal departure time of the jth packet is (ideally) begin, then the ideal departure time of the j-th packet is
L_j/R seconds later. Thus we are able to express the ideal departure L_j/R seconds later. Thus we are able to express the ideal departure
time of the jth packet in terms of the arrival time of the jth time of the j-th packet in terms of the arrival time of the j-th
packet, the actual departure time of the j-1-th packet, and the ideal packet, the actual departure time of the j-1-th packet, and the ideal
departure time of the j-1-th packet. Equations eq_1 and eq_2 in departure time of the j-1-th packet. Equations eq_1 and eq_2 in
Section 2.2 capture this relationship. Section 2.2 capture this relationship.
Whereas the original EF definition did not provide any means to Whereas the original EF definition did not provide any means to
guarantee the delay of an individual EF packet, this property may be guarantee the delay of an individual EF packet, this property may be
desired. For this reason, the equations in Section 2.2 consist of two desired. For this reason, the equations in Section 2.2 consist of
parts: an "aggregate behavior" set and a "packet-identity-aware" set two parts: an "aggregate behavior" set and a "packet-identity-aware"
of equations. The aggregate behavior equations (eq_1 and eq_2) simply set of equations. The aggregate behavior equations (eq_1 and eq_2)
describe the properties of the service delivered to the EF aggregate simply describe the properties of the service delivered to the EF
by the device. The "packet-identity-aware" equations (eq_3 and eq_4) aggregate by the device. The "packet-identity-aware" equations (eq_3
enable the bound on delay of an individual packet to be calculated and eq_4) enable the bound on delay of an individual packet to be
given a knowledge of the operating conditions of the device. The calculated given a knowledge of the operating conditions of the
significance of these two sets of equations is discussed further in device. The significance of these two sets of equations is discussed
Section 2.2. Note that these two sets of equations provide two ways further in Section 2.2. Note that these two sets of equations provide
of characterizing the behavior of a single device, not two different two ways of characterizing the behavior of a single device, not two
modes of behavior. different modes of behavior.
2.2. Formal Definition of the EF PHB 2.2. Formal Definition of the EF PHB
A node that supports EF on an interface I at some configured rate R A node that supports EF on an interface I at some configured rate R
MUST satisfy the following equations: MUST satisfy the following equations:
d_j <= f_j + E_a for all j > 0 (eq_1) d_j <= f_j + E_a for all j > 0 (eq_1)
where f_j is defined iteratively by where f_j is defined iteratively by
f_0 = 0, d_0 = 0 f_0 = 0, d_0 = 0
f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2) f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2)
In this definition: In this definition:
- d_j is the time that the last bit of the j-th EF packet to - d_j is the time that the last bit of the j-th EF packet to
depart actually leaves the node from the interface I. depart actually leaves the node from the interface I.
- f_j is the target departure time for the j-th EF packet to - f_j is the target departure time for the j-th EF packet to
depart from I, the "ideal" time at or before which the last bit of depart from I, the "ideal" time at or before which the last bit
that packet should leave the node. of that packet should leave the node.
- a_j is the time that the last bit of the j-th EF packet destined - a_j is the time that the last bit of the j-th EF packet
to the output I actually arrives at the node. destined to the output I actually arrives at the node.
- l_j is the size (bits) of the j-th EF packet to depart from I. - l_j is the size (bits) of the j-th EF packet to depart from I.
l_j is measured on the IP datagram (IP header plus payload) and l_j is measured on the IP datagram (IP header plus payload) and
does not include any lower layer (e.g. MAC layer) overhead. does not include any lower layer (e.g. MAC layer) overhead.
- R is the EF configured rate at output I (in bits/second). - R is the EF configured rate at output I (in bits/second).
- E_a is the error term for the treatment of the EF aggregate. - E_a is the error term for the treatment of the EF aggregate.
Note that E_a represents the worst case deviation between actual Note that E_a represents the worst case deviation between the
departure time of an EF packet and ideal departure time of the actual departure time of an EF packet and the ideal departure
same packet, i.e. E_a provides an upper bound on (d_j - f_j) for time of the same packet, i.e. E_a provides an upper bound on
all j. (d_j - f_j) for all j.
- d_0 and f_0 do not refer to a real packet departure but are used - d_0 and f_0 do not refer to a real packet departure but are
purely for the purposes of the recursion. The time origin should used purely for the purposes of the recursion. The time origin
be chosen such that no EF packets are in the system at time 0. should be chosen such that no EF packets are in the system at
time 0.
- for the definitions of a_j and d_j, the "last bit" of the packet - for the definitions of a_j and d_j, the "last bit" of the
includes the layer 2 trailer if present, because a packet cannot packet includes the layer 2 trailer if present, because a
generally be considered available for forwarding until such a packet cannot generally be considered available for forwarding
trailer has been received. until such a trailer has been received.
An EF-compliant node MUST be able to be characterized by the range of An EF-compliant node MUST be able to be characterized by the range of
possible R values that it can support on each of its interfaces while possible R values that it can support on each of its interfaces while
conforming to these equations, and the value of E_a that can be met conforming to these equations, and the value of E_a that can be met
on each interface. R may be line rate or less. E_a MAY be specified on each interface. R may be line rate or less. E_a MAY be specified
as a worst-case value for all possible R values or MAY be expressed as a worst-case value for all possible R values or MAY be expressed
as a function of R. as a function of R.
Note also that, since a node may have multiple inputs and complex Note also that, since a node may have multiple inputs and complex
internal scheduling, the jth EF packet to arrive at the node destined internal scheduling, the j-th EF packet to arrive at the node
for a certain interface may not be the jth EF packet to depart from destined for a certain interface may not be the j-th EF packet to
that interface. It is in this sense that eq_1 and eq_2 are unaware of depart from that interface. It is in this sense that eq_1 and eq_2
packet identity. are unaware of packet identity.
In addition, a node that supports EF on an interface I at some In addition, a node that supports EF on an interface I at some
configured rate R MUST satisfy the following equations: configured rate R MUST satisfy the following equations:
D_j <= F_j + E_p for all j > 0 (eq_3) D_j <= F_j + E_p for all j > 0 (eq_3)
where F_j is defined iteratively by where F_j is defined iteratively by
F_0 = 0, D_0 = 0 F_0 = 0, D_0 = 0
F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4) F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4)
In this definition: In this definition:
- D_j is actual the departure time of the individual EF packet - D_j is the actual departure time of the individual EF packet
that arrived at the node destined for interface I at time A_j, that arrived at the node destined for interface I at time A_j,
i.e., given a packet which was the j-th EF packet destined for I i.e., given a packet which was the j-th EF packet destined for
to arrive at the node via any input, D_j is the time at which the I to arrive at the node via any input, D_j is the time at which
last bit of that individual packet actually leaves the node from the last bit of that individual packet actually leaves the node
the interface I. from the interface I.
- F_j is the target departure time for the individual EF packet - F_j is the target departure time for the individual EF packet
that arrived at the node destined for interface I at time A_j. that arrived at the node destined for interface I at time A_j.
- A_j is the time that the last bit of the j-th EF packet destined - A_j is the time that the last bit of the j-th EF packet
to the output I to arrive actually arrives at the node. destined to the output I to arrive actually arrives at the
node.
- L_j is the size (bits) of the j-th EF packet to arrive at the - L_j is the size (bits) of the j-th EF packet to arrive at the
node that is destined to output I. L_j is measured on the IP node that is destined to output I. L_j is measured on the IP
datagram (IP header plus payload) and does not include any lower datagram (IP header plus payload) and does not include any
layer (e.g. MAC layer) overhead. lower layer (e.g. MAC layer) overhead.
- R is the EF configured rate at output I (in bits/second). - R is the EF configured rate at output I (in bits/second).
- E_p is the error term for the treatment of individual EF - E_p is the error term for the treatment of individual EF
packets. Note that E_p represents the worst case deviation between packets. Note that E_p represents the worst case deviation
actual departure time of an EF packet and ideal departure time of between the actual departure time of an EF packet and the ideal
the same packet, i.e. E_p provides an upper bound on (D_j - F_j) departure time of the same packet, i.e. E_p provides an upper
for all j. bound on (D_j - F_j) for all j.
- D_0 and F_0 do not refer to a real packet departure but are used - D_0 and F_0 do not refer to a real packet departure but are
purely for the purposes of the recursion. The time origin should used purely for the purposes of the recursion. The time origin
be chosen such that no EF packets are in the system at time 0. should be chosen such that no EF packets are in the system at
time 0.
- for the definitions of A_j and D_j, the "last bit" of the packet - for the definitions of A_j and D_j, the "last bit" of the
includes the layer 2 trailer if present, because a packet cannot packet includes the layer 2 trailer if present, because a
generally be considered available for forwarding until such a packet cannot generally be considered available for forwarding
trailer has been received. until such a trailer has been received.
It is the fact that D_j and F_j refer to departure times for the jth It is the fact that D_j and F_j refer to departure times for the j-th
packet to arrive that makes eq_3 and eq_4 aware of packet identity. packet to arrive that makes eq_3 and eq_4 aware of packet identity.
This is the critical distinction between the last two equations and This is the critical distinction between the last two equations and
the first two. the first two.
An EF-compliant node SHOULD be able to be characterized by the range An EF-compliant node SHOULD be able to be characterized by the range
of possible R values that it can support on each of its interfaces of possible R values that it can support on each of its interfaces
while conforming to these equations, and the value of E_p that can be while conforming to these equations, and the value of E_p that can be
met on each interface. E_p MAY be specified as a worst-case value for met on each interface. E_p MAY be specified as a worst-case value
all possible R values or MAY be expressed as a function of R. An E_p for all possible R values or MAY be expressed as a function of R. An
value of "undefined" MAY be specified. For discussion of situations E_p value of "undefined" MAY be specified. For discussion of
in which E_p may be undefined see the Appendix and [6]. situations in which E_p may be undefined see the Appendix and [6].
For the purposes of testing conformance to these equations, it may be For the purposes of testing conformance to these equations, it may be
necessary to deal with packet arrivals on different interfaces that necessary to deal with packet arrivals on different interfaces that
are closely spaced in time. If two or more EF packets destined for are closely spaced in time. If two or more EF packets destined for
the same output interface arrive (on different inputs) at almost the the same output interface arrive (on different inputs) at almost the
same time and the difference between their arrival times can't be same time and the difference between their arrival times cannot be
measured, then it is acceptable to use a random tie-breaking method measured, then it is acceptable to use a random tie-breaking method
to decide which packet arrived "first". to decide which packet arrived "first".
2.3. Figures of merit 2.3. Figures of merit
E_a and E_p may be thought of as "figures of merit" for a device. A E_a and E_p may be thought of as "figures of merit" for a device. A
smaller value of E_a means that the device serves the EF aggregate smaller value of E_a means that the device serves the EF aggregate
more smoothly at rate R over relatively short timescales, whereas a more smoothly at rate R over relatively short timescales, whereas a
larger value of E_a implies a more bursty scheduler which serves the larger value of E_a implies a more bursty scheduler which serves the
EF aggregate at rate R only when measured over longer intervals. A EF aggregate at rate R only when measured over longer intervals. A
device with a larger E_a can "fall behind" the ideal service rate R device with a larger E_a can "fall behind" the ideal service rate R
by a greater amount than a device with a smaller E_a. by a greater amount than a device with a smaller E_a.
A lower value of E_p implies a tighter bound on the delay experienced A lower value of E_p implies a tighter bound on the delay experienced
by an individual packet. Factors that might lead to a higher E_p by an individual packet. Factors that might lead to a higher E_p
might include a large number of input interfaces (since an EF packet might include a large number of input interfaces (since an EF packet
might arrive just behind a large number of EF packets that arrived on might arrive just behind a large number of EF packets that arrived on
other interfaces), or might be due to internal scheduler details other interfaces), or might be due to internal scheduler details
(e.g. per-flow scheduling within the EF aggregate). (e.g. per-flow scheduling within the EF aggregate).
We observe that factors that increase E_a such as those noted above We observe that factors that increase E_a such as those noted above
will also increase E_p, and that E_p is thus typically greater than will also increase E_p, and that E_p is thus typically greater than
or equal to E_a. In summary, E_a is a measure of deviation from or equal to E_a. In summary, E_a is a measure of deviation from
ideal service of the EF aggregate at rate R, while E_p measures both ideal service of the EF aggregate at rate R, while E_p measures both
non-ideal service and non-FIFO treatment of packets within the non-ideal service and non-FIFO treatment of packets within the
aggregate. aggregate.
For more discussion of these issues see the Appendix and [6]. For more discussion of these issues see the Appendix and [6].
2.4. Delay and jitter 2.4. Delay and jitter
Given a known value of E_p and a knowledge of the bounds on the EF Given a known value of E_p and a knowledge of the bounds on the EF
traffic offered to a given output interface, summed over all input traffic offered to a given output interface, summed over all input
interfaces, it is possible to bound the delay and jitter that will be interfaces, it is possible to bound the delay and jitter that will be
experienced by EF traffic leaving the node via that interface. The experienced by EF traffic leaving the node via that interface. The
delay bound is delay bound is
D = B/R + E_p (eq_5) D = B/R + E_p (eq_5)
where where
- R is the configured EF service rate on the output interface - R is the configured EF service rate on the output interface
- the total offered load of EF traffic destined to the output - the total offered load of EF traffic destined to the output
interface, summed over all input interfaces, is bounded by a token interface, summed over all input interfaces, is bounded by a
bucket of rate r <= R and depth B token bucket of rate r <= R and depth B
Since the minimum delay through the device is clearly at least zero, Since the minimum delay through the device is clearly at least zero,
D also provides a bound on jitter. To provided a tighter bound on D also provides a bound on jitter. To provide a tighter bound on
jitter, the value of E_p for a device MAY be specified as two jitter, the value of E_p for a device MAY be specified as two
separate components such that separate components such that
E_p = E_fixed + E_variable E_p = E_fixed + E_variable
where E_fixed represents the minimum delay that can be experienced by where E_fixed represents the minimum delay that can be experienced by
an EF packet through the node. an EF packet through the node.
2.5. Loss 2.5. Loss
The EF PHB is intended to be a building block for low loss services. The EF PHB is intended to be a building block for low loss services.
However, under sufficiently high load of EF traffic (including However, under sufficiently high load of EF traffic (including
unexpectedly large bursts from many inputs at once), any device with unexpectedly large bursts from many inputs at once), any device with
finite buffers may need to discard packets. Thus, it must be possible finite buffers may need to discard packets. Thus, it must be
to establish whether a device conforms to the EF definition even when possible to establish whether a device conforms to the EF definition
some packets are lost. This is done by performing an "off-line" test even when some packets are lost. This is done by performing an
of conformance to equations 1 through 4. After observing a sequence "off-line" test of conformance to equations 1 through 4. After
of packets entering and leaving the node, the packets which did not observing a sequence of packets entering and leaving the node, the
leave are assumed lost and are notionally removed from the input packets which did not leave are assumed lost and are notionally
stream. The remaining packets now constitute the arrival stream (the removed from the input stream. The remaining packets now constitute
a_j's) and the packets which left the node constitute the departure the arrival stream (the a_j's) and the packets which left the node
stream (the d_j's). Conformance to the equations can thus be verified constitute the departure stream (the d_j's). Conformance to the
by considering only those packets that successfully passed through equations can thus be verified by considering only those packets that
the node. successfully passed through the node.
In addition, to assist in meeting the low loss objective of EF, a In addition, to assist in meeting the low loss objective of EF, a
node MAY be characterized by the operating region in which loss of EF node MAY be characterized by the operating region in which loss of EF
due to congestion will not occur. This MAY be specified, using a due to congestion will not occur. This MAY be specified, using a
token bucket of rate r <= R and burstsize B, as the sum of traffic token bucket of rate r <= R and burstsize B, as the sum of traffic
across all inputs to a given output interface that can be tolerated across all inputs to a given output interface that can be tolerated
without loss. without loss.
In the event that loss does occur, the specification of which packets In the event that loss does occur, the specification of which packets
are lost is beyond the scope of this document. However it is a are lost is beyond the scope of this document. However it is a
requirement that those packets not lost MUST conform to the equations requirement that those packets not lost MUST conform to the equations
of Section 2.2. of Section 2.2.
2.6. Microflow misordering 2.6. Microflow misordering
Packets belonging to a single microflow within the EF aggregate Packets belonging to a single microflow within the EF aggregate
passing through a device SHOULD NOT experience re-ordering in normal passing through a device SHOULD NOT experience re-ordering in normal
operation of the device. operation of the device.
2.7. Recommended codepoint for this PHB 2.7. Recommended codepoint for this PHB
skipping to change at page 11, line 19 skipping to change at page 10, line 15
2.8. Mutability 2.8. Mutability
Packets marked for EF PHB MAY be remarked at a DS domain boundary 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 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 EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
domain. domain.
2.9. Tunneling 2.9. Tunneling
When EF packets are tunneled, the tunneling packets SHOULD be marked When EF packets are tunneled, the tunneling packets SHOULD be marked
as EF. A full discussion of tunneling issues is presented in [5]. as EF. A full discussion of tunneling issues is presented in [5].
2.10. Interaction with other PHBs 2.10. Interaction with other PHBs
Other PHBs and PHB groups may be deployed in the same DS node or Other PHBs and PHB groups may be deployed in the same DS node or
domain with the EF PHB. The equations of Section 2.2 MUST hold for a domain with the EF PHB. The equations of Section 2.2 MUST hold for a
node independent of the amount of non-EF traffic offered to it. node independent of the amount of non-EF traffic offered to it.
If the EF PHB is implemented by a mechanism that allows unlimited If the EF PHB is implemented by a mechanism that allows unlimited
preemption of other traffic (e.g., a priority queue), the preemption of other traffic (e.g., a priority queue), the
implementation MUST include some means to limit the damage EF traffic implementation MUST include some means to limit the damage EF traffic
could inflict on other traffic (e.g., a token bucket rate limiter). could inflict on other traffic (e.g., a token bucket rate limiter).
Traffic that exceeds this limit MUST be discarded. This maximum EF Traffic that exceeds this limit MUST be discarded. This maximum EF
rate, and burst size if appropriate, MUST be settable by a network rate, and burst size if appropriate, MUST be settable by a network
administrator (using whatever mechanism the node supports for non- administrator (using whatever mechanism the node supports for non-
volatile configuration). volatile configuration).
3. Security Considerations 3. Security Considerations
To protect itself against denial of service attacks, the edge of a DS To protect itself against denial of service attacks, the edge of a DS
domain SHOULD strictly police all EF marked packets to a rate domain SHOULD strictly police all EF marked packets to a rate
negotiated with the adjacent upstream domain. Packets in excess of negotiated with the adjacent upstream domain. Packets in excess of
the negotiated rate SHOULD be dropped. If two adjacent domains have the negotiated rate SHOULD be dropped. If two adjacent domains have
not negotiated an EF rate, the downstream domain SHOULD use 0 as the not negotiated an EF rate, the downstream domain SHOULD use 0 as the
rate (i.e., drop all EF marked packets). rate (i.e., drop all EF marked packets).
In addition, traffic conditioning at the ingress to a DS-domain MUST In addition, traffic conditioning at the ingress to a DS-domain MUST
ensure that only packets having DSCPs that correspond to an EF PHB ensure that only packets having DSCPs that correspond to an EF PHB
when they enter the DS-domain are marked with a DSCP that corresponds when they enter the DS-domain are marked with a DSCP that corresponds
to EF inside the DS-domain. Such behavior is as required by the to EF inside the DS-domain. Such behavior is as required by the
Differentiated Services architecture [4]. It protects against Differentiated Services architecture [4]. It protects against
denial-of-service and theft-of-service attacks which exploit DSCPs denial-of-service and theft-of-service attacks which exploit DSCPs
that are not identified in any TCS provisioned at an ingress that are not identified in any Traffic Conditioning Specification
interface, but which map to EF inside the DS-domain. provisioned at an ingress interface, but which map to EF inside the
DS-domain.
4. IANA Considerations 4. IANA Considerations
This document allocates one codepoint, 101110, in Pool 1 of the code This document allocates one codepoint, 101110, in Pool 1 of the code
space defined by [3]. space defined by [3].
5. Acknowledgments 5. Acknowledgments
This document draws heavily on the original EF PHB definition of This document was the result of collaboration and discussion among a
Jacobson, Nichols and Poduri. It was also greatly influenced by the large number of people. In particular, Fred Baker, Angela Chiu,
work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, Chuck Kalmanek, and K. K. Ramakrishnan made significant contributions
Kumar, and Schnizlein. to the new EF definition. John Wroclawski provided many helpful
comments to the authors. This document draws heavily on the original
EF PHB definition of Jacobson, Nichols, and Poduri. It was also
greatly influenced by the work of the EFRESOLVE team of Armitage,
Casati, Crowcroft, Halpern, Kumar, and Schnizlein.
6. References 6. References
[1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding [1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
PHB", RFC 2598, June 1999 Forwarding PHB", RFC 2598, June 1999.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997 Levels", BCP 14, RFC 2119, March 1997.
[3] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the [3] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
Differentiated Services Field (DS Field) in the IPv4 and IPv6 the Differentiated Services Field (DS Field) in the IPv4 and
Headers", RFC 2474, December 1998. IPv6 Headers", RFC 2474, December 1998.
[4] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An [4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W.
Architecture for Differentiated Services", RFC 2475, December 1998. Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[5] D. Black, "Differentiated Services and Tunnels", RFC 2983, [5] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000. October 2000.
[6] A. Charny et al., "Supplemental Information for the New [6] Charny, A., Baker, F., Davie, B., Bennett, J.C.R., Benson, K.,
Definition of the EF PHB", Work in Progress, June 2001. Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu,
V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis,
"Supplemental Information for the New Definition of the EF PHB
(Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[7] K. Nichols and B. Carpenter, "Definition of Differentiated [7] Nichols K. and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their Specification", Services Per Domain Behaviors and Rules for their
RFC 3086, April 2001. Specification", RFC 3086, April 2001.
Appendix: Implementation Examples Appendix: Implementation Examples
This appendix is not part of the normative specification of EF. This appendix is not part of the normative specification of EF.
However, it is included here as a possible source of useful However, it is included here as a possible source of useful
information for implementors. information for implementors.
A variety of factors in the implementation of a node supporting EF A variety of factors in the implementation of a node supporting EF
will influence the values of E_a and E_p. These factors are discussed will influence the values of E_a and E_p. These factors are
in more detail in [6], and include both output schedulers and the discussed in more detail in [6], and include both output schedulers
internal design of a device. and the internal design of a device.
A priority queue is widely considered as the canonical example of an A priority queue is widely considered as the canonical example of an
implementation of EF. A "perfect" output buffered device (i.e. one implementation of EF. A "perfect" output buffered device (i.e. one
which delivers packets immediately to the appropriate output queue) which delivers packets immediately to the appropriate output queue)
with a priority queue for EF traffic will provide both a low E_a and with a priority queue for EF traffic will provide both a low E_a and
a low E_p. We note that the main factor influencing E_a will be the a low E_p. We note that the main factor influencing E_a will be the
inability to pre-empt an MTU-sized non-EF packet that has just begun inability to pre-empt an MTU-sized non-EF packet that has just begun
transmission at the time when an EF packet arrives at the output transmission at the time when an EF packet arrives at the output
interface, plus any additional delay that might be caused by non- interface, plus any additional delay that might be caused by non-
pre-emptable queues between the priority queue and the physical pre-emptable queues between the priority queue and the physical
interface. E_p will be influenced primarily by the number of interface. E_p will be influenced primarily by the number of
interfaces. interfaces.
Another example of an implementation of EF is a weighted round robin Another example of an implementation of EF is a weighted round robin
scheduler. Such an implementation will typically not be able to scheduler. Such an implementation will typically not be able to
support values of R as high as the link speeds, because the maximum support values of R as high as the link speeds, because the maximum
rate at which EF traffic can be served in the presence of competing rate at which EF traffic can be served in the presence of competing
traffic will be affected by the number of other queues and the traffic will be affected by the number of other queues and the
weights given to them. Furthermore, such an implementation is likely weights given to them. Furthermore, such an implementation is likely
to have a value of E_a that is higher than a priority queue to have a value of E_a that is higher than a priority queue
implementation, all else being equal, as a result of the time spent implementation, all else being equal, as a result of the time spent
serving non-EF queues by the round robin scheduler. serving non-EF queues by the round robin scheduler.
Finally, it is possible to implement hierarchical scheduling Finally, it is possible to implement hierarchical scheduling
algorithms, such that some non-FIFO scheduling algorithm is run on algorithms, such that some non-FIFO scheduling algorithm is run on
sub-flows within the EF aggregate, while the EF aggregate as a whole sub-flows within the EF aggregate, while the EF aggregate as a whole
could be served at high priority or with a large weight by the top- could be served at high priority or with a large weight by the top-
level scheduler. Such an algorithm might perform per-input scheduling level scheduler. Such an algorithm might perform per-input
or per-microflow scheduling within the EF aggregate, for example. scheduling or per-microflow scheduling within the EF aggregate, for
Because such algorithms lead to non-FIFO service within the EF example. Because such algorithms lead to non-FIFO service within the
aggregate, the value of E_p for such algorithms may be higher than EF aggregate, the value of E_p for such algorithms may be higher than
for other implementations. For some schedulers of this type it may be for other implementations. For some schedulers of this type it may
difficult to provide a meaningful bound on E_p that would hold for be difficult to provide a meaningful bound on E_p that would hold for
any pattern of traffic arrival, and thus a value of "undefined" may any pattern of traffic arrival, and thus a value of "undefined" may
be most appropriate. be most appropriate.
It should be noted that it is quite acceptable for a Diffserv domain It should be noted that it is quite acceptable for a Diffserv domain
to provide multiple instances of EF. Each instance should be to provide multiple instances of EF. Each instance should be
characterizable by the equations in Section 2.2 of this characterizable by the equations in Section 2.2 of this
specification. The effect of having multiple instances of EF on the specification. The effect of having multiple instances of EF on the
E_a and E_p values of each instance will depend considerably on how E_a and E_p values of each instance will depend considerably on how
the multiple instances are implemented. For example, in a multi-level the multiple instances are implemented. For example, in a multi-
priority scheduler, an instance of EF that is not at the highest level priority scheduler, an instance of EF that is not at the
priority may experience relatively long periods when it receives no highest priority may experience relatively long periods when it
service while higher priority instances of EF are served. This would receives no service while higher priority instances of EF are served.
result in relatively large values of E_a and E_p. By contrast, in a This would result in relatively large values of E_a and E_p. By
WFQ-like scheduler, each instance of EF would be represented by a contrast, in a WFQ-like scheduler, each instance of EF would be
queue served at some configured rate and the values of E_a and E_p represented by a queue served at some configured rate and the values
could be similar to those for a single EF instance. of E_a and E_p could be similar to those for a single EF instance.
Authors' Addresses Authors' Addresses
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
300 Apollo Drive 300 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: bsd@cisco.com EMail: bsd@cisco.com
Anna Charny Anna Charny
Cisco Systems Cisco Systems
300 Apollo Drive 300 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
E-mail: acharny@cisco.com EMail: acharny@cisco.com
Fred Baker
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
E-mail: fred@cisco.com
Jon Bennett Jon Bennett
RiverDelta Networks Motorola
3 Highwood Drive East 3 Highwood Drive East
Tewksbury, MA 01876 Tewksbury, MA 01876
E-mail: jcrb@riverdelta.com EMail: jcrb@motorola.com
Kent Benson Kent Benson
Tellabs Research Center Tellabs Research Center
3740 Edison Lake Parkway #101 3740 Edison Lake Parkway #101
Mishawaka, IN 46545 Mishawaka, IN 46545
E-mail: Kent.Benson@tellabs.com EMail: Kent.Benson@tellabs.com
Jean-Yves Le Boudec Jean-Yves Le Boudec
ICA-EPFL, INN ICA-EPFL, INN
Ecublens, CH-1015 Ecublens, CH-1015
Lausanne-EPFL, Switzerland Lausanne-EPFL, Switzerland
E-mail: leboudec@epfl.ch EMail: jean-yves.leboudec@epfl.ch
Angela Chiu
AT&T Labs
100 Schulz Dr. Rm 4-204
Red Bank, NJ 07701
E-mail: alchiu@att.com
Bill Courtney Bill Courtney
TRW TRW
Bldg. 201/3702 Bldg. 201/3702
One Space Park One Space Park
Redondo Beach, CA 90278 Redondo Beach, CA 90278
E-mail: bill.courtney@trw.com EMail: bill.courtney@trw.com
Shahram Davari Shahram Davari
PMC-Sierra Inc PMC-Sierra Inc
411 Legget Drive 411 Legget Drive
Ottawa, ON K2K 3C9, Canada Ottawa, ON K2K 3C9, Canada
E-mail: shahram_davari@pmc-sierra.com EMail: shahram_davari@pmc-sierra.com
Victor Firoiu Victor Firoiu
Nortel Networks Nortel Networks
600 Tech Park 600 Tech Park
Billerica, MA 01821 Billerica, MA 01821
E-mail: vfirou@nortelnetworks.com EMail: vfiroiu@nortelnetworks.com
Charles Kalmanek
AT&T Labs-Research
180 Park Avenue, Room A113,
Florham Park NJ
E-mail: crk@research.att.com.
K.K. Ramakrishnan
TeraOptic Networks, Inc.
686 W. Maude Ave
Sunnyvale, CA 94086
E-mail: kk@teraoptic.com
Dimitrios Stiliadis Dimitrios Stiliadis
Lucent Technologies Lucent Technologies
1380 Rodick Road 101 Crawfords Corner Road
Markham, Ontario, L3R-4G5, Canada Holmdel, NJ 07733
E-mail: stiliadi@bell-labs.com EMail: stiliadi@bell-labs.com
7. Full Copyright Full Copyright Statement
Copyright (C) The Internet Society 2001. All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 705 skipping to change at page 16, line 32
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 98 change blocks. 
308 lines changed or deleted 270 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/