As per Relevance of the word forwarding, we have this rfc below:
Network Working Group V.
Request for Comments: 2598 K.
Category: Standards Track Cisco
K.
Bay
June 1999
An Expedited Forwarding
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 (1999). All Rights Reserved
The definition of PHBs (per-hop forwarding behaviors) is a
part of the work of the Diffserv Working Group. This
describes a PHB called Expedited Forwarding. We show the
of this PHB by noting that it can be produced by more than
mechanism and give an example of its use to produce at least
service, a Virtual Leased Line. A recommended codepoint for this
is given
A pdf version of this document is available
ftp://ftp.ee.lbl.gov/papers/ef_phb.
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 [RFC2474,
RFC2475]. This memo describes a particular PHB called
forwarding (EF). The EF PHB can be used to build a low loss,
latency, low jitter, assured bandwidth, end-to-end service through
domains. Such a service appears to the endpoints like a point-to
point connection or a "virtual leased line". This service has
been described as Premium service [2BIT].
Jacobson, et al. Standards Track [Page 1]
RFC 2598 An Expedited Forwarding PHB June 1999
Loss, latency and jitter are all due to the queues
experiences while transiting the network. Therefore providing
loss, latency and jitter for some traffic aggregate means
that the aggregate sees no (or very small) queues. Queues arise
(short-term) traffic arrival rate exceeds departure rate at
node. Thus a service that ensures no queues for some aggregate
equivalent to bounding rates such that, at every transit node,
aggregate's maximum arrival rate is less than that aggregate'
minimum departure rate
Creating such a service has two parts
1) Configuring nodes so that the aggregate has a well-
minimum departure rate. ("Well-defined" means independent
the dynamic state of the node. In particular, independent
the intensity of other traffic at the node.)
2) Conditioning the aggregate (via policing and shaping) so
its arrival rate at any node is always less than that node'
configured minimum departure rate
The EF PHB provides the first part of the service. The
boundary traffic conditioners described in [RFC2475] provide
second part
The EF PHB is not a mandatory part of the Differentiated
architecture, i.e., a node is not required to implement the EF PHB
order to be considered DS-compliant. However, when a DS-
node claims to implement the EF PHB, the implementation must
to the specification given in this document
The next sections describe the EF PHB in detail and give examples
how it might be implemented. The keywords "MUST", "MUST NOT",
"REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in
document are to be interpreted as described in [Bradner97].
2. Description of EF per-hop
The EF PHB is defined as a forwarding treatment for a
diffserv aggregate where the departure rate of the aggregate'
packets from any diffserv node must equal or exceed a
rate. The EF traffic SHOULD receive this rate independent of
intensity of any other traffic attempting to transit the node.
SHOULD average at least the configured rate when measured over
time interval equal to or longer than the time it takes to send
output link MTU sized packet at the configured rate. (Behavior
time scales shorter than a packet time at the configured rate
Jacobson, et al. Standards Track [Page 2]
RFC 2598 An Expedited Forwarding PHB June 1999
deliberately not specified.) The configured minimum rate MUST
settable by a network administrator (using whatever mechanism
node supports for non-volatile configuration).
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). The minimum and maximum rates may be
same and configured by a single parameter
The Appendix describes how this PHB can be used to construct end-to
end services
2.2 Example Mechanisms to Implement the EF
Several types of queue scheduling mechanisms may be employed
deliver the forwarding behavior described in section 2.1 and
implement the EF PHB. A simple priority queue will give
appropriate behavior as long as there is no higher priority
that could preempt the EF for more than a packet time at
configured rate. (This could be accomplished by having a
policer such as a token bucket associated with each priority queue
bound how much the queue can starve other traffic.)
It's also possible to use a single queue in a group of
serviced by a weighted round robin scheduler where the share of
output bandwidth assigned to the EF queue is equal to the
rate. This could be implemented, for example, using one PHB of
Class Selector Compliant set of PHBs [RFC2474].
Another possible implementation is a CBQ [CBQ] scheduler that
the EF queue priority up to the configured rate
All of these mechanisms have the basic properties required for the
PHB though different choices result in different ancillary
such as jitter seen by individual microflows. See Appendix A.3
simulations that quantify some of these differences
2.3 Recommended codepoint for this
Codepoint 101110 is recommended for the EF PHB
Jacobson, et al. Standards Track [Page 3]
RFC 2598 An Expedited Forwarding PHB June 1999
2.4
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.5
When EF packets are tunneled, the tunneling packets must be marked
EF
2.6 Interaction with other
Other PHBs and PHB groups may be deployed in the same DS node
domain with the EF PHB as long as the requirement of section 2.1
met
3. Security
To protect itself against denial of service attacks, the edge of a
domain MUST strictly police all EF marked packets to a
negotiated with the adjacent upstream domain. (This rate must be <=
the EF PHB configured rate.) Packets in excess of the
rate MUST be dropped. If two adjacent domains have not negotiated
EF rate, the downstream domain MUST use 0 as the rate (i.e., drop
EF marked packets).
Since the end-to-end premium service constructed from the EF
requires that the upstream domain police and shape EF marked
to meet the rate negotiated with the downstream domain,
downstream domain's policer should never have to drop packets.
these drops SHOULD be noted (e.g., via SNMP traps) as
security violations or serious misconfiguration. Similarly, since
aggregate EF traffic rate is constrained at every interior node,
EF queue should never overflow so if it does the drops SHOULD
noted as possible attacks or serious misconfiguration
4. IANA
This document allocates one codepoint, 101110, in Pool 1 of the
space defined by [RFC2474].
Jacobson, et al. Standards Track [Page 4]
RFC 2598 An Expedited Forwarding PHB June 1999
5.
[Bradner97] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black
"Definition of the Differentiated Services Field (
Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998.
[RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-
Differentiated Services Architecture for the Internet",
Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and
Management Models for Packet Networks", IEEE/
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies
Increased Initial TCP Window Size", RFC 2415,
1998.
[LCN] K. Nichols, "Improving Network Simulation with Feedback",
Proceedings of LCN '98, October 1998.
Jacobson, et al. Standards Track [Page 5]
RFC 2598 An Expedited Forwarding PHB June 1999
6. Authors'
Van
Cisco Systems,
170 W. Tasman
San Jose, CA 95134-1706
EMail: van@cisco.
Kathleen
Cisco Systems,
170 W. Tasman
San Jose, CA 95134-1706
EMail: kmn@cisco.
Kedarnath
Bay Networks, Inc
4401 Great America
Santa Clara, CA 95052-8185
EMail: kpoduri@baynetworks.
Jacobson, et al. Standards Track [Page 6]
RFC 2598 An Expedited Forwarding PHB June 1999
Appendix A: Example use of and experiences with the EF
A.1 Virtual Leased Line
A VLL Service, also known as Premium service [2BIT], is quantified
a peak bandwidth
A.2 Experiences with its use in
A prototype of the VLL service has been deployed on DOE's
backbone. This uses weighted-round-robin queuing features of
75xx series routers to implement the EF PHB. The early tests
been very successful and work is in progress to make the
available on a routine production basis (
ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf
ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf for details).
A.3 Simulation
A.3.1 Jitter
In section 2.2, we pointed out that a number of mechanisms might
used to implement the EF PHB. The simplest of these is a
queue (PQ) where the arrival rate of the queue is strictly less
its service rate. As jitter comes from the queuing delay along
path, a feature of this implementation is that EF-marked
will see very little jitter at their subscribed rate since
spend little time in queues. The EF PHB does not have an
jitter requirement but it is clear from the definition that
expected jitter in a packet stream that uses a service based on
EF PHB will be less with PQ than with best-effort delivery. We
simulation to explore how weighted round-robin (WRR) compares to
in jitter. We chose these two since they"re the best and worst cases
respectively, for jitter and we wanted to supply rough guidelines
EF implementers choosing to use WRR or similar mechanisms
Our simulation model is implemented in a modified ns-2 described
[RFC2415] and [LCN]. We used the CBQ modules included with ns-2 as
basis to implement priority queuing and WRR. Our topology has
hops with decreasing bandwidth in the direction of a single 1.5
bottleneck link (see figure 6). Sources produce EF-marked packets
an average bit rate equal to their subscribed packet rate.
are produced with a variation of +-10% from the interpacket
at the subscribed packet rate. The individual source rates
picked aggregate to 30% of the bottleneck link or 450 Kbps. A
of FTPs and HTTPs is then used to fill the link. Individual EF
sources produce either all 160 byte packets or all 1500 byte packets
Jacobson, et al. Standards Track [Page 7]
RFC 2598 An Expedited Forwarding PHB June 1999
Though we present the statistics of flows with one size of packet
all of the experiments used a mixture of short and long packet
sources so the EF queues had a mix of both packet lengths
We defined jitter as the absolute value of the difference between
arrival times of two adjacent packets minus their departure times
|(aj-dj) - (ai-di)|. For the target flow of each experiment,
record the median and 90th percentile values of jitter (expressed
% of the subscribed EF rate) in a table. The pdf version of
document contains graphs of the jitter percentiles
Our experiments compared the jitter of WRR and PQ implementations
the EF PHB. We assessed the effect of different choices of WRR
weight and number of queues on jitter. For WRR, we define
service-to-arrival rate ratio as the service rate of the EF queue (
the queue"s minimum share of the output link) times the output
bandwidth divided by the peak arrival rate of EF-marked packets
the queue. Results will not be stable if the WRR weight is chosen
exactly balance arrival and departure rates thus we used a
service-to-arrival ratio of 1.03. In our simulations this means
the EF queue gets at least 31% of the output links. In
simulations we kept the link full with other traffic as
above, splitting the non-EF-marked traffic among the non-EF queues
(It should be clear from the experiment description that we
attempting to induce worst-case jitter and do not expect
settings or traffic to represent a "normal" operating point.)
Our first set of experiments uses the minimal service-to-
ratio of 1.06 and we vary the number of individual
composing the EF aggregate from 2 to 36. We compare these to a
implementation with 24 flows. First, we examine a microflow at
subscribed rate of 56 Kbps sending 1500 byte packets, then one at
same rate but sending 160 byte packets. Table 1 shows the 50th
90th percentile jitter in percent of a packet time at the
rate. Figure 1 plots the 1500 byte flows and figure 2 the 160
flows. Note that a packet-time for a 1500 byte packet at 56 Kbps
214 ms, for a 160 byte packet 23 ms. The jitter for the large
rarely exceeds half a subscribed rate packet-time, though
jitters for the small packets are at least one subscribed
packet-time. Keep in mind that the EF aggregate is a mixture of
and large packets in all cases so short packets can wait for
packets in the EF queue. PQ gives a very low jitter
Table 1: Variation in jitter with number of EF flows: Service/
ratio of 1.06 and subscription rate of 56 Kbps (all values given as %
of subscribed rate
Jacobson, et al. Standards Track [Page 8]
RFC 2598 An Expedited Forwarding PHB June 1999
1500 byte pack. 160 byte
# EF flows 50th % 90th % 50th % 90th %
PQ (24) 1 5 17 43
2 11 47 96 513
4 12 35 100 278
8 10 25 96 126
24 18 47 96 143
Next we look at the effects of increasing the service-to-
ratio. This means that EF packets should remain enqueued for
time though the bandwidth available to the other queues remains
same. In this set of experiments the number of flows in the
aggregate was fixed at eight and the total number of queues at
(four non-EF queues). Table 2 shows the results for 1500 and 160
flows. Figures 3 plots the 1500 byte results and figure 4 the 160
byte results. Performance gains leveled off at service-to-
ratios of 1.5. Note that the higher service-to-arrival ratios do
give the same performance as PQ, but now 90% of packets
less than a subscribed packet-time of jitter even for the
packets
Table 2: Variation in Jitter of EF flows: service/arrival
varies, 8 flow aggregate, 56 Kbps subscribed
WRR 1500 byte pack. 160 byte
Ser/Arr 50th % 90th % 50th % 90th %
PQ 1 3 17 43
1.03 14 27 100 178
1.30 7 21 65 113
1.50 5 13 57 104
1.70 5 13 57 100
2.00 5 13 57 104
3.00 5 13 57 100
Increasing the number of queues at the output interfaces can lead
more variability in the service time for EF packets so we carried
an experiment varying the number of queues at each output port.
fixed the number of flows in the aggregate to eight and used
minimal 1.03 service-to-arrival ratio. Results are shown in figure 5
and table 3. Figure 5 includes PQ with 8 flows as a baseline
Jacobson, et al. Standards Track [Page 9]
RFC 2598 An Expedited Forwarding PHB June 1999
Table 3: Variation in Jitter with Number of Queues at
Interface: Service-to-arrival ratio is 1.03, 8 flow
# EF 1500 byte
flows 50th % 90th %
PQ (8) 1 3
2 7 21
4 7 21
6 8 22
8 10 23
It appears that most jitter for WRR is low and can be reduced by
proper choice of the EF queue's WRR share of the output link
respect to its subscribed rate. As noted, WRR is a worst case
PQ is the best case. Other possibilities include WFQ or CBQ with
fixed rate limit for the EF queue but giving it priority over
queues. We expect the latter to have performance nearly
with PQ though future simulations are needed to verify this. We
not yet systematically explored effects of hop count, EF
other than 30% of the link bandwidth, or more complex topologies.
information in this section is not part of the EF PHB definition
provided simply as background to guide implementers
A.3.2 VLL
We used simulation to see how well a VLL service built from the
PHB behaved, that is, does it look like a `leased line' at
subscribed rate. In the simulations of the last section, none of
EF packets were dropped in the network and the target rate was
achieved for those CBR sources. However, we wanted to see if
really looks like a `wire' to a TCP using it. So we simulated long
lived FTPs using a VLL service. Table 4 gives the percentage of
link allocated to EF traffic (bandwidths are lower on the links
fewer EF microflows), the subscribed VLL rate, the average rate
the same type of sender-receiver pair connected by a full
dedicated link at the subscribed rate and the average of the
flows for each simulation (all sender-receiver pairs had the
value). Losses only occur when the input shaping buffer overflows
not in the network. The target rate is not achieved due to
well-known TCP behavior
Table 4: Performance of FTPs using a VLL
% link Average delivered rate (Kbps
to EF Subscribed Dedicated
20 100 90 90
40 150 143 143
60 225 213 215
Jacobson, et al. Standards Track [Page 10]
RFC 2598 An Expedited Forwarding PHB June 1999
Full Copyright
Copyright (C) The Internet Society (1999). 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
Jacobson, et al. Standards Track [Page 11]
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
