rfc3247.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,348 行 · 第 1/4 页
TXT
1,348 行
Network Working Group A. Charny
Request for Comments: 3247 Cisco Systems, Inc.
Category: Informational J.C.R. Bennett
Motorola
K. Benson
Tellabs
J.Y. Le Boudec
EPFL
A. Chiu
Celion Networks
W. Courtney
TRW
S. Davari
PMC-Sierra
V. Firoiu
Nortel Networks
C. Kalmanek
AT&T Research
K.K. Ramakrishnan
TeraOptic Networks
March 2002
Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document was written during the process of clarification of
RFC2598 "An Expedited Forwarding PHB" that led to the publication of
revised specification of EF "An Expedited Forwarding PHB". Its
primary motivation is providing additional explanation to the revised
EF definition and its properties. The document also provides
additional implementation examples and gives some guidance for
computation of the numerical parameters of the new definition for
several well known schedulers and router architectures.
Charny, et. al. Informational [Page 1]
RFC 3247 Supplemental Information March 2002
Table of Contents
1 Introduction ........................................... 2
2 Definition of EF PHB ................................... 3
2.1 The formal definition .................................. 3
2.2 Relation to Packet Scale Rate Guarantee ................ 6
2.3 The need for dual characterization of EF PHB ........... 7
3 Per Packet delay ....................................... 9
3.1 Single hop delay bound ................................. 9
3.2 Multi-hop worst case delay ............................. 10
4 Packet loss ............................................ 10
5 Implementation considerations .......................... 11
5.1 The output buffered model with EF FIFO at the output. .. 12
5.1.1 Strict Non-preemptive Priority Queue ................... 12
5.1.2 WF2Q ................................................... 13
5.1.3 Deficit Round Robin (DRR) .............................. 13
5.1.4 Start-Time Fair Queuing and Self-Clocked Fair Queuing .. 13
5.2 Router with Internal Delay and EF FIFO at the output ... 13
6 Security Considerations ................................ 14
7 References ............................................. 14
Appendix A. Difficulties with the RFC 2598 EF PHB Definition .. 16
Appendix B. Alternative Characterization of Packet Scale Rate
Guarantee ......................................... 20
Acknowledgements .............................................. 22
Authors' Addresses ............................................ 22
Full Copyright Statement ...................................... 24
1. Introduction
The Expedited Forwarding (EF) Per-Hop Behavior (PHB) was designed to
be used to build a low-loss, low-latency, low-jitter, assured
bandwidth service. The potential benefits of this service, and
therefore the EF PHB, are enormous. Because of the great value of
this PHB, it is critical that the forwarding behavior required of and
delivered by an EF-compliant node be specific, quantifiable, and
unambiguous.
Unfortunately, the definition of EF PHB in the original RFC2598 [10]
was not sufficiently precise (see Appendix A and [4]). A more
precise definition is given in [6]. This document is intended to aid
in the understanding of the properties of the new definition and
provide supplemental information not included in the text of [6] for
sake of brevity.
This document is outlined as follows. In section 2, we briefly
restate the definition for EF PHB of [6]. We then provide some
additional discussion of this definition and describe some of its
properties. We discuss the issues associated with per-packet delay
Charny, et. al. Informational [Page 2]
RFC 3247 Supplemental Information March 2002
and loss in sections 3 and 4. In section 5 we discuss the impact of
known scheduling architectures on the critical parameters of the new
definition. We also discuss the impact of deviation of real devices
from the ideal output-buffered model on the magnitude of the critical
parameters in the definition.
2. Definition of EF PHB
2.1. The formal definition
An intuitive explanation of the new EF definition is described in
[6]. Here we restate the formal definition from [6] verbatim.
A node that supports EF on an interface I at some configured rate R
MUST satisfy the following equations:
d_j <= f_j + E_a for all j>0 (eq_1)
where f_j is defined iteratively by
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 to
depart actually leaves the node from the interface I.
- 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 that packet should leave the node.
- a_j is the time that the last bit of the j-th EF packet
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) and
does not include any lower layer (e.g. MAC layer) overhead.
- 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.
Note that E_a represents the worst case deviation between
actual 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 all j.
Charny, et. al. Informational [Page 3]
RFC 3247 Supplemental Information March 2002
- 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 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
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
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 function of R.
Note also that, since a node may have multiple inputs and complex
internal scheduling, the j-th EF packet to arrive at the node
destined for a certain interface may not be the j-th EF packet to
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 some
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 by
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 packet
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 to arrive at the node via any input, D_j is the time at which
the 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
that arrived at the node destined for interface I at time A_j.
Charny, et. al. Informational [Page 4]
RFC 3247 Supplemental Information March 2002
- 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.
- 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
datagram (IP header plus payload) and does not include any
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 EF
packets. Note that E_p represents the worst case deviation
between the actual departure time of an EF packet and the ideal
departure time of the same packet, i.e. E_p provides an upper
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 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.
- 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 j-th
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
the first two.
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
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 all possible R values or MAY be expressed as a function of R. An
E_p value of "undefined" MAY be specified.
Finally, there is an additional recommendation in [6] that an EF
compliant node SHOULD NOT reorder packets within a micorflow.
The definitions described in this section are referred to as
aggregate and packet-identity-aware packet scale rate guarantee
[4],[2]. An alternative mathematical characterization of packet
scale rate guarantee is given in Appendix B.
Charny, et. al. Informational [Page 5]
RFC 3247 Supplemental Information March 2002
2.2. Relation to Packet Scale Rate Guarantee
Consider the case of an ideal output-buffered device with an EF FIFO
at the output. For such a device, the i-th packet to arrive to the
device is also the i-th packet to depart from the device. Therefore,
in this ideal model the aggregate behavior and packet-identity-aware
characteristics are identical, and E_a = E_p. In this section we
therefore omit the subscript and refer to the latency term simply as
E.
It could be shown that for such an ideal device the definition of
section 2.1 is stronger than the well-known rate-latency curve [2] in
the sense that if a scheduler satisfies the EF definition it also
satisfies the rate-latency curve. As a result, all the properties
known for the rate-latency curve also apply to the modified EF
definition. However, we argue below that the definition of section
2.1 is more suitable to reflect the intent of EF PHB than the rate-
latency curve.
It is shown in [2] that the rate-latency curve is equivalent to the
following definition:
Definition of Rate Latency Curve (RLC):
D(j) <= F'(j) + E (eq_5)
where
F'(0)=0, F'(j)=max(a(j), F'(j-1))+ L(j)/R for all j>0 (eq_6)
It can be easily verified that the EF definition of section 2.1 is
stronger than RLC by noticing that for all j, F'(j) >= F(j).
It is easy to see that F'(j) in the definition of RLC corresponds to
the time the j-th departure should have occurred should the EF
aggregate be constantly served exactly at its configured rate R.
Following the common convention, we refer to F'(j) as the "fluid
finish time" of the j-th packet to depart.
The intuitive meaning of the rate-latency curve of RLC is that any
packet is served at most time E later than this packet would finish
service in the fluid model.
For RLC (and hence for the stronger EF definition) it holds that in
any interval (0,t) the EF aggregate gets close to the desired service
rate R (as long as there is enough traffic to sustain this rate).
The discrepancy between the ideal and the actual service in this
interval depends on the latency term E, which in turn depends on the
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?