draft-ietf-diffserv-rfc2598bis-00.txt   draft-ietf-diffserv-rfc2598bis-01.txt 
Network Working Group Bruce Davie, Editor Network Working Group Bruce Davie, Editor
Internet Draft Anna Charny Internet Draft Anna Charny
Expiration Date: August 2001 Fred Baker Expiration Date: October 2001 Fred Baker
Cisco Systems, Inc. Cisco Systems, Inc.
Jon Bennet Jon Bennet
Riverdelta Networks Riverdelta Networks
Kent Benson Jean-Yves Le Boudec Kent Benson Jean-Yves Le Boudec
Tellabs EPFL Tellabs EPFL
Angela Chiu William Courtney Angela Chiu William Courtney
AT&T Labs TRW AT&T Labs TRW
Shahram Davari Victor Firoiu Shahram Davari Victor Firoiu
PMC-Sierra Nortel Networks PMC-Sierra Nortel Networks
Charles Kalmanek K.K. Ramakrishnam Charles Kalmanek K.K. Ramakrishnam
AT&T Research TeraOptic Networks AT&T Research TeraOptic Networks
Dimitrios Stiliadis Dimitrios Stiliadis
Lucent Technologies Lucent Technologies
February 2001
An Expedited Forwarding PHB An Expedited Forwarding PHB
draft-ietf-diffserv-rfc2598bis-00.txt draft-ietf-diffserv-rfc2598bis-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the Diffserv working group of the This document is a product of the Diffserv working group of the
Internet Engineering Task Force. Please address comments to the Internet Engineering Task Force. Please address comments to the
group's mailing list at diffserv@ietf.org, with a copy to the group's mailing list at diffserv@ietf.org, with a copy to the
authors. 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 The PHB (per-hop behavior) is a basic building block in the
Differentiated Services architecture. This document defines a PHB Differentiated Services architecture. This document defines a PHB
called Expedited Forwarding (EF). EF is intended to provide a called Expedited Forwarding (EF). EF is intended to provide a
building block for low delay and low loss services by ensuring that building block for low delay, low jitter and low loss services by
the EF aggregate is served at a certain configured rate. ensuring that the EF aggregate is served at a certain configured
rate.
Contents Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
2 Definition of EF PHB ................................... 4 2 Definition of EF PHB ................................... 4
2.1 Intuitive Description of EF ............................ 4 2.1 Intuitive Description of EF ............................ 4
2.2 Formal Definition of the EF PHB ........................ 5 2.2 Formal Definition of the EF PHB ........................ 5
2.3 Figures of merit ....................................... 8 2.3 Figures of merit ....................................... 8
2.4 Delay and jitter ....................................... 9 2.4 Delay and jitter ....................................... 9
2.5 Loss ................................................... 9 2.5 Loss ................................................... 10
2.6 Microflow misordering .................................. 10 2.6 Microflow misordering .................................. 10
2.7 Recommended codepoint for this PHB ..................... 10 2.7 Recommended codepoint for this PHB ..................... 10
2.8 Mutability ............................................. 10 2.8 Mutability ............................................. 11
2.9 Tunneling .............................................. 10 2.9 Tunneling .............................................. 11
2.10 Interaction with other PHBs ............................ 10 2.10 Interaction with other PHBs ............................ 11
3 Security Considerations ................................ 11 3 Security Considerations ................................ 11
4 IANA Considerations .................................... 11 4 IANA Considerations .................................... 12
5 Acknowledgments ........................................ 11 5 Acknowledgments ........................................ 12
6 References ............................................. 11 6 References ............................................. 12
7 Full Copyright ......................................... 15 7 Full Copyright ......................................... 16
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
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 [RFC2474, (PHB) as the specific forwarding treatment for that packet [RFC2474,
RFC2475]. This memo describes a particular PHB called expedited RFC2475]. This memo describes a particular PHB called expedited
forwarding (EF). forwarding (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 speed-of-light The dominant causes of delay in packet networks are fixed propagation
propagation delays on wide area links and queuing delays in switches delays (e.g. those arising from speed-of-light delays) on wide area
and routers. Since propagation delays are a fixed property of the links and queuing delays in switches and routers. Since propagation
topology, delay and jitter are minimized when queueing delays are delays are a fixed property of the topology, delay and jitter are
minimized. In this context, jitter is defined as the variation minimized when queueing delays are minimized. In this context, jitter
between maximum and minimum delay. The intent of the EF PHB is to is defined as the variation between maximum and minimum delay. The
provide a PHB in which suitably marked packets usually encounter intent of the EF PHB is to provide a PHB in which suitably marked
short or empty queues. Furthermore, if queues remain short relative packets usually encounter short or empty queues. Furthermore, if
to the buffer space available, packet loss is also kept to a minimum. queues remain short relative to the buffer space available, packet
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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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 to a device which still In the case when an EF packet arrives to a device that still contains
contains EF packets awaiting service, the computation of the ideal EF packets awaiting service, the computation of the ideal departure
departure time is more complicated. There are two cases to be time is more complicated. There are two cases to be considered. If
considered. If the previous (j-1-th) departure occurred after its own the previous (j-1-th) departure occurred after its own ideal
ideal departure time, then the scheduler is running "late". In this departure time, then the scheduler is running "late". In this case,
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 can't 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 packet
should begin at the actual departure time of the previous 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 jth packet should
(ideally) begin, then the ideal departure time of the jth packet is (ideally) begin, then the ideal departure time of the jth 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 jth packet in terms of the arrival time of the jth
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 two
parts: a "colorblind" set and a "packet-identity-aware" set of parts: an "aggregate behavior" set and a "packet-identity-aware" set
equations. The colorblind equations (eq_1 and eq_2) simply describe of equations. The aggregate behavior equations (eq_1 and eq_2) simply
the properties of the service delivered to the EF aggregate by the describe the properties of the service delivered to the EF aggregate
device. The "packet-identity-aware" equations (eq_3 and eq_4) enable by the device. The "packet-identity-aware" equations (eq_3 and eq_4)
the bound on delay of an individual packet to be calculated given a enable the bound on delay of an individual packet to be calculated
knowledge of the operating conditions of the device. The significance given a knowledge of the operating conditions of the device. The
of these two sets of equations is discussed further in Section 2.2. significance of these two sets of equations is discussed further in
Note that these two sets of equations provide two ways of Section 2.2. Note that these two sets of equations provide two ways
characterizing the behavior of a single device, not two different of characterizing the behavior of a single device, not two different
modes of behavior. 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 (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 of
that packet should leave the node. 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 destined
to the output I to arrive actually arrives at the node. 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 actual
departure time of an EF packet and ideal departure time of the departure time of an EF packet and ideal departure time of the
same packet, i.e. E_a provides an upper bound on (d_j - f_j) for same packet, i.e. E_a provides an upper bound on (d_j - f_j) for
all j. 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 used
purely for the purposes of the recursion. The time origin should purely for the purposes of the recursion. The time origin should
be chosen such that no EF packets are in the system at time 0. 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
includes the layer 2 trailer if present, because a packet cannot
generally be considered available for forwarding 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 packet to arrive may not be the jth internal scheduling, the jth EF packet to arrive at the node destined
packet to depart. It is in this sense that eq_1 and eq_2 are for a certain interface may not be the jth EF packet to depart from
colorblind with regard to packet identity. 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 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 (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 actual the departure time of the individual EF packet
that arrived at time A_j, i.e., given a packet which was the j-th that arrived at the node destined for interface I at time A_j,
EF packet destined for I to arrive at the node via any input, D_j i.e., given a packet which was the j-th EF packet destined for I
is the time at which the last bit of that individual packet to arrive at the node via any input, D_j is the time at which the
actually leaves the node from the interface I. last bit of that individual packet actually leaves the node 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
which arrived 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 destined
to the output I to arrive actually arrives at the node. 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 lower
layer (e.g. MAC layer) overhead. 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).
skipping to change at page 8, line 5 skipping to change at page 8, line 10
- 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 between
actual departure time of an EF packet and ideal departure time of actual departure time of an EF packet and ideal departure time of
the same packet, i.e. E_p provides an upper bound on (D_j - F_j) the same packet, i.e. E_p provides an upper bound on (D_j - F_j)
for all 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 used
purely for the purposes of the recursion. The time origin should purely for the purposes of the recursion. The time origin should
be chosen such that no EF packets are in the system at time 0. 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
includes the layer 2 trailer if present, because a packet cannot
generally be considered available for forwarding 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 jth
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 for
all possible R values or MAY be expressed as a function of R. An E_p all possible R values or MAY be expressed as a function of R. An E_p
value of "undefined" MAY be specified. For discussion of situations value of "undefined" MAY be specified. For discussion of situations
in which E_p may be undefined see the Appendix and [6]. in which E_p may be undefined see the Appendix and [6].
For the purposes of testing conformance to these equations, it may be
necessary to deal with packet arrivals on different interfaces that
are closely spaced in time. If two or more EF packets destined for
the same output interface arrive (on different inputs) at almost the
same time and the difference between their arrival times can't be
measured, then it is acceptable to use a random tie-breaking method
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.
skipping to change at page 9, line 25 skipping to change at page 9, line 36
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 token
bucket of rate r <= R and depth B 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 provided a tighter bound on
jitter, a device MAY advertise E_p as two separate components such jitter, the value of E_p for a device MAY be specified as two
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
skipping to change at page 10, line 44 skipping to change at page 11, line 25
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 SHOULD include some means to limit the damage EF implementation MUST include some means to limit the damage EF traffic
traffic could inflict on other traffic. This will be reflected in the could inflict on other traffic (e.g., a token bucket rate limiter).
range of supported R values as described in section 2.2. Traffic that exceeds this limit MUST be discarded. This maximum EF
rate, and burst size if appropriate, MUST be settable by a network
administrator (using whatever mechanism the node supports for non-
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
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
to EF inside the DS-domain. Such behavior is as required by RFC
2475. It protects against denial-of-service and theft-of-service
attacks which exploit DSCPs that are not identified in any TCS
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 [RFC2474]. space defined by [RFC2474].
5. Acknowledgments 5. Acknowledgments
This document draws heavily on the original EF PHB definition of This document draws heavily on the original EF PHB definition of
Jacobson, Nichols and Poduri. It was also greatly influenced by the Jacobson, Nichols and Poduri. It was also greatly influenced by the
work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern,
skipping to change at page 13, line 6 skipping to change at page 13, line 43
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 scheduling
or per-microflow scheduling within the EF aggregate, for example. or per-microflow scheduling within the EF aggregate, for example.
Because such algorithms lead to non-FIFO service within the EF Because such algorithms lead to non-FIFO service within the EF
aggregate, the value of E_p for such algorithms may be higher than 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 be
difficult to provide a meaningful bound on E_p that would hold for 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
to provide multiple instances of EF. Each instance should be
characterizable by the equations in Section 2.2 of this
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
the multiple instances are implemented. For example, in a multi-level
priority scheduler, an instance of EF that is not at the highest
priority may experience relatively long periods when it receives no
service while higher priority instances of EF are served. This would
result in relatively large values of E_a and E_p. By contrast, in a
WFQ-like scheduler, each instance of EF would be represented by a
queue served at some configured rate and the values 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 E-mail: bsd@cisco.com
Anna Charny Anna Charny
 End of changes. 24 change blocks. 
55 lines changed or deleted 106 lines changed or added

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