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