rfc3246.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页
TXT
900 行
Network Working Group B. Davie
Request for Comments: 3246 A. Charny
Obsoletes: 2598 Cisco Systems, Inc.
Category: Standards Track J.C.R. Bennett
Motorola
K. Benson
Tellabs
J.Y. Le Boudec
EPFL
W. Courtney
TRW
S. Davari
PMC-Sierra
V. Firoiu
Nortel Networks
D. Stiliadis
Lucent Technologies
March 2002
An Expedited Forwarding PHB (Per-Hop Behavior)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document defines a PHB (per-hop behavior) called Expedited
Forwarding (EF). The PHB is a basic building block in the
Differentiated Services architecture. EF is intended to provide a
building block for low delay, low jitter and low loss services by
ensuring that the EF aggregate is served at a certain configured
rate. This document obsoletes RFC 2598.
Davie, et. al. Standards Track [Page 1]
RFC 3246 An Expedited Forwarding PHB March 2002
Table of Contents
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. Introduction
Network nodes that implement the differentiated services enhancements
to IP use a codepoint in the IP header to select a per-hop behavior
(PHB) as the specific forwarding treatment for that packet [3, 4].
This memo describes a particular PHB called expedited forwarding
(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 to
build such services are outside the scope of this specification.
The dominant causes of delay in packet networks are fixed propagation
delays (e.g. those arising from speed-of-light delays) on wide area
links and queuing delays in switches and routers. Since propagation
delays are a fixed property of the topology, delay and jitter are
minimized when queuing delays are minimized. In this context, jitter
is defined as the variation between maximum and minimum delay. The
intent of the EF PHB is to provide a PHB in which suitably marked
packets usually encounter short or empty queues. Furthermore, if
queues remain short relative to the buffer space available, packet
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, it
is necessary to ensure that the service rate of EF packets on a given
output interface exceeds their arrival rate at that interface over
long and short time intervals, independent of the load of other
(non-EF) traffic. This specification defines a PHB in which EF
packets are guaranteed to receive service at or above a configured
rate and provides a means to quantify the accuracy with which this
service rate is delivered over any time interval. It also provides a
means to quantify the maximum delay and jitter that a packet may
experience under bounded operating conditions.
Note that the EF PHB only defines the behavior of a single node. The
specification of behavior of a collection of nodes is outside the
scope of this document. A Per-Domain Behavior (PDB) specification
[7] may provide such information.
When a DS-compliant node claims to implement the EF PHB, the
implementation MUST conform to the specification given in this
document. However, the EF PHB is not a mandatory part of the
Differentiated Services architecture - a node is NOT REQUIRED to
implement the EF PHB in order to be considered DS-compliant.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
1.1. Relationship to RFC 2598
This document replaces RFC 2598 [1]. The main difference is that it
adds mathematical formalism to give a more rigorous definition of the
behavior described. The full rationale for this is given in [6].
2. Definition of EF PHB
2.1. Intuitive Description of EF
Intuitively, the definition of EF is simple: the rate at which EF
traffic is served at a given output interface should be at least the
configured rate R, over a suitably defined interval, independent of
the offered load of non-EF traffic to that interface. Two
difficulties arise when we try to formalize this intuition:
- it is difficult to define the appropriate timescale at which to
measure R. By measuring it at short timescales we may introduce
sampling errors; at long timescales we may allow excessive
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 no
EF packets waiting to be served, but it may be impossible to
determine externally whether EF packets are actually waiting to
be served by the output scheduler. For example, if an EF
packet has entered the router and not exited, it may be
awaiting service, or it may simply have encountered some
processing or transmission delay within the router.
The formal definition below takes account of these issues. It
assumes that EF packets should ideally be served at rate R or faster,
and bounds the deviation of the actual departure time of each packet
from the "ideal" departure time of that packet. We define the
departure time of a packet as the time when the last bit of that
packet leaves the node. The "ideal" departure time of each EF packet
is computed iteratively.
In the case when an EF packet arrives at a device when all the
previous EF packets have already departed, the computation of the
ideal departure time is simple. Service of the packet should
(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
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
get transmitted at line rate once its transmission actually starts,
but we are calculating the ideal target behavior here; the ideal
service takes place at rate R.)
In the case when an EF packet arrives at a device that still contains
EF packets awaiting service, the computation of the ideal departure
time is more complicated. There are two cases to be considered. If
the previous (j-1-th) departure occurred after its own ideal
departure time, then the scheduler is running "late". In this case,
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
of the new packet, whichever is later, because we cannot expect a
packet to begin service before it arrives. If the previous (j-1-th)
departure occurred before its own ideal departure time, then the
scheduler is running "early". In this case, service of the new
packet should begin at the actual departure time of the previous
packet.
Once we know the time at which service of the j-th packet should
(ideally) begin, then the ideal departure time of the j-th packet is
L_j/R seconds later. Thus we are able to express the ideal departure
time of the j-th packet in terms of the arrival time of the j-th
packet, the actual departure time of the j-1-th packet, and the ideal
departure time of the j-1-th packet. Equations eq_1 and eq_2 in
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 to
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 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 EF
aggregate by the device. The "packet-identity-aware" equations (eq_3
and eq_4) enable the bound on delay of an individual packet to be
calculated given a knowledge of the operating conditions of the
device. The significance of these two sets of equations is discussed
further in Section 2.2. Note that these two sets of equations provide
two ways of characterizing the behavior of a single device, not two
different modes of behavior.
2.2. Formal Definition of the EF PHB
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).
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 the
actual departure time of an EF packet and the ideal departure
time of the same packet, i.e. E_a 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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?