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
        
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)

快速转发PHB(每跳行为)

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.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

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.

本文档定义了一种称为快速转发(EF)的PHB(每跳行为)。PHB是区分服务体系结构中的基本构建块。EF旨在通过确保EF聚合以特定的配置速率提供服务,从而为低延迟、低抖动和低损耗服务提供构建块。本文件淘汰了RFC 2598。

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  ...........................................   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
1. 介绍

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).

对IP实施区分服务增强的网络节点使用IP报头中的代码点选择每跳行为(PHB)作为该数据包的特定转发处理[3,4]。本备忘录描述了一种称为快速转发(EF)的特殊PHB。

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.

EF PHB的目的是为低损耗、低延迟和低抖动服务提供构建块。具体如何构建此类服务的细节不在本规范的范围之内。

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.

分组网络延迟的主要原因是广域链路上的固定传播延迟(例如光速延迟引起的延迟)以及交换机和路由器中的排队延迟。由于传播延迟是拓扑的一个固定属性,当排队延迟最小化时,延迟和抖动最小化。在这种情况下,抖动被定义为最大和最小延迟之间的变化。EF PHB的目的是提供一个PHB,其中适当标记的数据包通常会遇到短队列或空队列。此外,如果队列相对于可用的缓冲区空间保持较短,则分组丢失也保持在最小。

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.

为确保EF数据包遇到的队列通常较短,有必要确保给定输出接口上EF数据包的服务速率在长时间和短时间间隔内超过其在该接口的到达速率,与其他(非EF)流量的负载无关。本规范定义了PHB,其中EF数据包保证以配置的速率或高于配置的速率接收服务,并提供了一种方法来量化在任何时间间隔内提供该服务速率的准确性。它还提供了一种量化数据包在有界操作条件下可能经历的最大延迟和抖动的方法。

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.

请注意,EF PHB仅定义单个节点的行为。节点集合的行为规范不在本文档的范围内。每域行为(PDB)规范[7]可提供此类信息。

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.

当DS兼容节点声称实现EF PHB时,实现必须符合本文档中给出的规范。但是,EF PHB不是区分服务体系结构的强制性部分-节点不需要实现EF PHB才能被视为DS兼容。

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].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。

1.1. Relationship to RFC 2598
1.1. 与RFC2598的关系

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].

本文件取代RFC 2598[1]。主要区别在于,它添加了数学形式主义,对所描述的行为给出了更严格的定义。[6]给出了这方面的全部理由。

2. Definition of EF PHB
2. EF PHB的定义
2.1. Intuitive Description of EF
2.1. 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:

直观地说,EF的定义很简单:给定输出接口上EF流量的速率至少应为配置的速率R,在适当定义的间隔内,与该接口提供的非EF流量负载无关。当我们试图将这种直觉形式化时,会出现两个困难:

- 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.

- 很难定义测量R的适当时间尺度。通过在短时间尺度上测量R,我们可能会引入采样误差;在长时间尺度下,我们可能会允许过度抖动。

- 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.

- 如果没有EF数据包等待服务,则EF通信显然不能以速率R服务,但可能无法从外部确定EF数据包是否实际等待由输出调度器服务。例如,如果EF包已进入路由器而未退出,则它可能正在等待服务,或者它可能只是在路由器内遇到了一些处理或传输延迟。

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.

下面的正式定义考虑了这些问题。它假设EF数据包在理想情况下应以R或更快的速率服务,并限制每个数据包的实际离开时间与该数据包的“理想”离开时间的偏差。我们将数据包的离开时间定义为该数据包的最后一位离开节点的时间。迭代计算每个EF包的“理想”离开时间。

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.)

在当EF分组到达设备时,当所有先前的EF分组已经离开时,理想离开时间的计算是简单的。数据包的服务(理想情况下)应在其到达时立即开始,因此理想的离开时间仅为到达时间加上以速率R传输数据包的理想时间。对于长度为L_j的数据包,以配置速率R传输的时间为L_j/R。(当然,一个真正的数据包一旦实际开始传输,通常会以线速率传输,但我们在这里计算的是理想的目标行为;理想的服务以速率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.

在EF分组到达仍然包含等待服务的EF分组的设备的情况下,理想出发时间的计算更加复杂。有两种情况需要考虑。如果上一次(第j-1次)出发发生在其理想出发时间之后,则调度程序正在“延迟”运行。在这种情况下,新分组的理想开始服务时间是前一(j-1)分组的理想离开时间,或新分组的到达时间,以较晚者为准,因为我们不能期望分组在到达之前开始服务。如果上一次(第j-1次)出发发生在其理想出发时间之前,则调度程序正在“提前”运行。在这种情况下,新分组的服务应在前一分组的实际出发时间开始。

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.

一旦我们知道第j个数据包的服务应该(理想)开始的时间,那么第j个数据包的理想出发时间是L_j/R秒之后。因此,我们能够根据第j分组的到达时间、第j-1分组的实际出发时间和第j-1分组的理想出发时间来表示第j分组的理想出发时间。第2.2节中的方程式eq_1和eq_2捕捉了这种关系。

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.

虽然原始EF定义没有提供任何方法来保证单个EF数据包的延迟,但可能需要此属性。因此,第2.2节中的方程式由两部分组成:“聚合行为”集合和“包标识感知”方程式集合。聚合行为方程(eq_1和eq_2)简单地描述了设备交付给EF聚合的服务的属性。“分组标识感知”等式(eq_3和eq_4)使得能够在已知设备的操作条件的情况下计算单个分组的绑定接通延迟。第2.2节将进一步讨论这两组方程的意义。请注意,这两组方程提供了表征单个设备行为的两种方法,而不是两种不同的行为模式。

2.2. Formal Definition of the EF PHB
2.2. EF PHB的正式定义

A node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:

在接口I上以某种配置速率R支持EF的节点必须满足以下等式:

      d_j <= f_j + E_a for all j > 0                             (eq_1)
        
      d_j <= f_j + E_a for all j > 0                             (eq_1)
        

where f_j is defined iteratively by

其中f_j由以下公式迭代定义:

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:

在这一定义中:

- 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.

- d_j是第j个EF包的最后一位实际离开接口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.

- f_j是第j个EF数据包离开I的目标离开时间,即该数据包的最后一位离开节点时或之前的“理想”时间。

- 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.

- a_j是发送到输出I的第j个EF包的最后一位实际到达节点的时间。

- 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.

- l_j是要离开I的第j个EF数据包的大小(位)。l_j在IP数据报(IP报头加有效载荷)上测量,不包括任何较低层(例如MAC层)开销。

- R is the EF configured rate at output I (in bits/second).

- R是输出I处的EF配置速率(以位/秒为单位)。

- 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.

- E_a是EF骨料处理的误差项。注意,E_a表示EF数据包的实际出发时间和同一数据包的理想出发时间之间的最坏情况偏差,即E_a为所有j提供(d_j-f_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.

- d_0和f_0并不表示实际的数据包离开,而是纯粹用于递归。时间原点的选择应确保在时间0时系统中没有EF数据包。

- 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.

- 对于a_j和d_j的定义,分组的“最后一位”包括第2层尾部(如果存在),因为在接收到这样的尾部之前,通常不能认为分组可用于转发。

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.

EF兼容节点必须能够通过其在符合这些等式的同时在其每个接口上支持的可能R值的范围以及在每个接口上可以满足的E_a值来表征。R可以是行速率或更低。E_a可指定为所有可能R值的最坏情况值,或可表示为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.

还注意,由于节点可以具有多个输入和复杂的内部调度,因此到达目的地为某个接口的节点的j-th EF分组可能不是离开该接口的j-th EF分组。正是在这种意义上,eq_1和eq_2不知道分组标识。

In addition, a node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:

此外,在接口I上以某种配置速率R支持EF的节点必须满足以下等式:

      D_j <= F_j + E_p for all j > 0                             (eq_3)
        
      D_j <= F_j + E_p for all j > 0                             (eq_3)
        

where F_j is defined iteratively by

其中F_j由以下公式迭代定义:

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:

在这一定义中:

- 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.

- D_j是在时间A_j到达目的地为接口I的节点的单个EF分组的实际离开时间,即,给定作为目的地为I的第j个EF分组的分组经由任何输入到达节点,D_j是该单个分组的最后一位实际离开接口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.

- F_j是在时间A_j到达目的地为接口I的节点的单个EF分组的目标离开时间。

- 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.

- A_j是发送到输出I的第j个EF分组的最后一位实际到达节点的时间。

- 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.

- L_j是到达目的地为输出I的节点的第j个EF分组的大小(位)。L_j在IP数据报(IP报头加有效载荷)上测量,不包括任何较低层(例如MAC层)开销。

- R is the EF configured rate at output I (in bits/second).

- R是输出I处的EF配置速率(以位/秒为单位)。

- 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.

- E_p是用于处理单个EF数据包的错误项。注意,E_p表示EF数据包的实际出发时间和同一数据包的理想出发时间之间的最坏情况偏差,即E_p为所有j提供了(D_j-F_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.

- D_0和F_0并不表示实际的数据包离开,而是纯粹用于递归。时间原点的选择应确保在时间0时系统中没有EF数据包。

- 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.

- 对于A_j和D_j的定义,分组的“最后一位”包括第2层尾部(如果存在),因为在接收到这样的尾部之前,通常不能认为分组可用于转发。

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.

事实上,D_j和F_j指的是第j个分组到达的离开时间,这使得eq_3和eq_4知道分组标识。这是后两个方程和前两个方程之间的关键区别。

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. For discussion of situations in which E_p may be undefined see the Appendix and [6].

EF兼容节点应能够通过其在符合这些等式的同时在其每个接口上支持的可能R值的范围以及在每个接口上可以满足的E_p值来表征。E_p可指定为所有可能R值的最坏情况值,或可表示为R的函数。可指定“未定义”的E_p值。有关E_p可能未定义的情况的讨论,请参见附录和[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

为了测试这些等式的一致性,可能需要处理时间间隔很近的不同接口上的数据包到达。如果两个或多个EF数据包目的地为同一输出接口(在不同的输入端)到达几乎相同的位置

same time and the difference between their arrival times cannot 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. 功绩

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 more smoothly at rate R over relatively short timescales, whereas a 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 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.

E_a和E_p可被视为设备的“价值数字”。较小的E_A值意味着设备在相对较短的时间尺度上以速率R更平滑地服务于EF聚合,而较大的E_A值意味着更突发的调度器,其仅当在较长的时间间隔上测量时以速率R服务于EF聚合。与具有较小E_A的设备相比,具有较大E_A的设备可以“落后”理想服务速率R更大的量。

A lower value of E_p implies a tighter bound on the delay experienced by an individual packet. Factors that might lead to a higher E_p might include a large number of input interfaces (since an EF packet might arrive just behind a large number of EF packets that arrived on other interfaces), or might be due to internal scheduler details (e.g. per-flow scheduling within the EF aggregate).

较低的E_p值意味着单个数据包所经历的延迟的更严格限制。可能导致更高E_p的因素可能包括大量输入接口(因为EF数据包可能刚好在到达其他接口的大量EF数据包之后到达),或者可能是由于内部调度器细节(例如EF聚合中的每个流调度)。

We observe that factors that increase E_a such as those noted above will also increase E_p, and that E_p is thus typically greater than or equal to E_a. In summary, E_a is a measure of deviation from ideal service of the EF aggregate at rate R, while E_p measures both non-ideal service and non-FIFO treatment of packets within the aggregate.

我们观察到,上述增加E_a的因素也会增加E_p,因此E_p通常大于或等于E_a。总之,E_a是在速率R下对EF聚合的理想服务的偏差的度量,而E_p度量聚合内的包的非理想服务和非FIFO处理。

For more discussion of these issues see the Appendix and [6].

有关这些问题的更多讨论,请参见附录和[6]。

2.4. Delay and jitter
2.4. 延迟和抖动

Given a known value of E_p and a knowledge of the bounds on the EF traffic offered to a given output interface, summed over all input interfaces, it is possible to bound the delay and jitter that will be experienced by EF traffic leaving the node via that interface. The delay bound is

给定已知的E_p值和提供给给定输出接口的EF通信量的边界知识(在所有输入接口上求和),可以限制EF通信量通过该接口离开节点时将经历的延迟和抖动。延迟界限是

      D = B/R + E_p          (eq_5)
        
      D = B/R + E_p          (eq_5)
        

where

哪里

- R is the configured EF service rate on the output interface

- R是输出接口上配置的EF服务速率

- the total offered load of EF traffic destined to the output interface, summed over all input interfaces, is bounded by a token bucket of rate r <= R and depth B

- 发送到输出接口的EF通信量的总提供负载(在所有输入接口上求和)由速率r<=r和深度B的令牌桶限定

Since the minimum delay through the device is clearly at least zero, D also provides a bound on jitter. To provide a tighter bound on jitter, the value of E_p for a device MAY be specified as two separate components such that

由于通过设备的最小延迟显然至少为零,因此D还提供了一个关于抖动的界限。为了提供更严格的抖动限制,设备的E_p值可以指定为两个单独的组件,以便

E_p = E_fixed + E_variable

E_p=E_固定+E_变量

where E_fixed represents the minimum delay that can be experienced by an EF packet through the node.

其中E_fixed表示EF数据包通过节点可经历的最小延迟。

2.5. Loss
2.5. 丧失

The EF PHB is intended to be a building block for low loss services. However, under sufficiently high load of EF traffic (including unexpectedly large bursts from many inputs at once), any device with finite buffers may need to discard packets. Thus, it must be possible to establish whether a device conforms to the EF definition even when some packets are lost. This is done by performing an "off-line" test of conformance to equations 1 through 4. After observing a sequence of packets entering and leaving the node, the packets which did not leave are assumed lost and are notionally removed from the input stream. The remaining packets now constitute the arrival stream (the a_j's) and the packets which left the node constitute the departure stream (the d_j's). Conformance to the equations can thus be verified by considering only those packets that successfully passed through the node.

EF PHB旨在成为低损耗服务的组成部分。然而,在足够高的EF流量负载下(包括来自多个输入的意外大突发),任何具有有限缓冲区的设备都可能需要丢弃数据包。因此,即使某些数据包丢失,也必须能够确定设备是否符合EF定义。这是通过执行符合方程式1至方程式4的“离线”测试来完成的。在观察到进入和离开节点的数据包序列之后,假设没有离开的数据包丢失,并从输入流中名义上移除。剩下的包现在构成到达流(a_j),离开节点的包构成离开流(d_j)。因此,可以通过仅考虑成功通过节点的那些分组来验证与方程的一致性。

In addition, to assist in meeting the low loss objective of EF, a node MAY be characterized by the operating region in which loss of EF due to congestion will not occur. This MAY be specified, using a token bucket of rate r <= R and burstsize B, as the sum of traffic across all inputs to a given output interface that can be tolerated without loss.

此外,为了帮助满足EF的低损耗目标,节点可以由其中不会发生由于拥塞导致的EF损耗的操作区域来表征。这可以使用速率r<=r和burstsize B的令牌桶来指定,作为给定输出接口的所有输入的流量之和,可以在不丢失的情况下容忍。

In the event that loss does occur, the specification of which packets are lost is beyond the scope of this document. However it is a requirement that those packets not lost MUST conform to the equations of Section 2.2.

如果确实发生丢失,则丢失哪些数据包的说明超出了本文档的范围。但是,要求未丢失的数据包必须符合第2.2节的方程式。

2.6. Microflow misordering
2.6. 微流错序

Packets belonging to a single microflow within the EF aggregate passing through a device SHOULD NOT experience re-ordering in normal operation of the device.

属于通过设备的EF聚合内单个微流的数据包在设备正常运行时不应经历重新排序。

2.7. Recommended codepoint for this PHB
2.7. 此PHB的建议代码点

Codepoint 101110 is RECOMMENDED for the EF PHB.

建议EF PHB使用代码点101110。

2.8. Mutability
2.8. 易变性

Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.

标记为EF-PHB的分组可以仅在DS域边界处对满足EF-PHB的其他码点进行注释。DS域不应将标记为EF PHB的数据包降级或升级到另一个PHB。

2.9. Tunneling
2.9. 隧道

When EF packets are tunneled, the tunneling packets SHOULD be marked as EF. A full discussion of tunneling issues is presented in [5].

当EF数据包被隧道化时,隧道化数据包应标记为EF。[5]对隧道问题进行了全面讨论。

2.10. Interaction with other PHBs
2.10. 与其他PHB的相互作用

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 node independent of the amount of non-EF traffic offered to it.

其他PHB和PHB组可以部署在与EF PHB相同的DS节点或域中。第2.2节的方程式必须适用于与提供给它的非EF通信量无关的节点。

If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). 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).

如果EF PHB由允许无限抢占其他流量(例如,优先级队列)的机制实现,则该实现必须包括一些限制EF流量可能对其他流量造成的损害的手段(例如,令牌桶速率限制器)。超过此限制的流量必须丢弃。此最大EF速率和突发大小(如果合适)必须由网络管理员设置(使用节点支持的任何非易失性配置机制)。

3. Security Considerations
3. 安全考虑

To protect itself against denial of service attacks, the edge of a DS domain SHOULD strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. Packets in excess of the negotiated rate SHOULD be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain SHOULD use 0 as the rate (i.e., drop all EF marked packets).

为了保护自身免受拒绝服务攻击,DS域的边缘应严格监控所有EF标记的数据包,以与相邻上游域协商的速率进行监控。应丢弃超过协商速率的数据包。如果两个相邻域未协商EF速率,则下游域应使用0作为速率(即,丢弃所有EF标记的数据包)。

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 the Differentiated Services architecture [4]. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any Traffic Conditioning Specification provisioned at an ingress interface, but which map to EF inside the DS-domain.

此外,DS域入口处的流量调节必须确保只有当其进入DS域时具有与EF PHB相对应的DSCP的数据包被标记为与DS域内的EF相对应的DSCP。这种行为符合区分服务体系结构的要求[4]。它可以防止拒绝服务和盗用服务攻击,这些攻击利用的DSCP未在入口接口提供的任何流量调节规范中识别,但映射到DS域内的EF。

4. IANA Considerations
4. IANA考虑

This document allocates one codepoint, 101110, in Pool 1 of the code space defined by [3].

本文档在[3]定义的代码空间的池1中分配一个代码点101110。

5. Acknowledgments
5. 致谢

This document was the result of collaboration and discussion among a large number of people. In particular, Fred Baker, Angela Chiu, Chuck Kalmanek, and K. K. Ramakrishnan made significant contributions to the new EF definition. John Wroclawski provided many helpful comments to the authors. This document draws heavily on the original EF PHB definition of Jacobson, Nichols, and Poduri. It was also greatly influenced by the work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, Kumar, and Schnizlein.

这份文件是许多人合作和讨论的结果。特别是,弗雷德·贝克、安吉拉·邱、查克·卡尔马内克和K.K.罗摩克里希南对新的环境足迹定义做出了重大贡献。约翰·沃克罗夫斯基为作者提供了许多有益的评论。本文档大量借鉴了雅各布森、尼科尔斯和波杜里的原始EF PHB定义。它还受到阿米蒂奇、卡萨蒂、克罗克罗夫特、哈尔彭、库马尔和施尼兹莱因的埃夫雷索夫团队的工作的极大影响。

6. References
6. 工具书类

[1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.

[1] Jacobson,V.,Nichols,K.和K.Poduri,“快速转发PHB”,RFC 25981999年6月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[3] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[3] Nichols,K.,Blake,S.,Baker,F.和D.Black,“IPv4和IPv6标头中区分服务字段(DS字段)的定义”,RFC 2474,1998年12月。

[4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[4] Black,D.,Blake,S.,Carlson,M.,Davies,E.,Wang,Z.和W.Weiss,“差异化服务架构”,RFC 24751998年12月。

[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.

[5] Black,D.,“差异化服务和隧道”,RFC 2983,2000年10月。

[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 PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.

[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.和D.Stiliadis,“EF PHB(每跳快速转发行为)新定义的补充信息”,RFC 3247,2002年3月。

[7] Nichols K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.

[7] Nichols K.和B.Carpenter,“每个域行为的区分服务定义及其规范规则”,RFC 3086,2001年4月。

Appendix: Implementation Examples

附录:实施示例

This appendix is not part of the normative specification of EF. However, it is included here as a possible source of useful information for implementors.

本附录不是EF规范性规范的一部分。但是,本文将其作为实现者有用信息的可能来源。

A variety of factors in the implementation of a node supporting EF will influence the values of E_a and E_p. These factors are discussed in more detail in [6], and include both output schedulers and the internal design of a device.

支持EF的节点的实现中的各种因素将影响E_A和E_p的值。这些因素在[6]中有更详细的讨论,包括输出调度器和设备的内部设计。

A priority queue is widely considered as the canonical example of an implementation of EF. A "perfect" output buffered device (i.e. one which delivers packets immediately to the appropriate output queue) with a priority queue for EF traffic will provide both a low E_a and a low E_p. We note that the main factor influencing E_a will be the inability to pre-empt an MTU-sized non-EF packet that has just begun transmission at the time when an EF packet arrives at the output interface, plus any additional delay that might be caused by non-pre-emptable queues between the priority queue and the physical interface. E_p will be influenced primarily by the number of interfaces.

优先级队列被广泛认为是EF实现的典型示例。具有EF流量优先级队列的“完美”输出缓冲设备(即将数据包立即发送到适当输出队列的设备)将提供低e_A和低e_p。我们注意到,影响E_a的主要因素是无法抢占在EF分组到达输出接口时刚刚开始传输的MTU大小的非EF分组,加上优先级队列和物理接口之间的非抢占队列可能导致的任何额外延迟。E_p主要受接口数量的影响。

Another example of an implementation of EF is a weighted round robin scheduler. Such an implementation will typically not be able to support values of R as high as the link speeds, because the maximum rate at which EF traffic can be served in the presence of competing traffic will be affected by the number of other queues and the weights given to them. Furthermore, such an implementation is likely to have a value of E_a that is higher than a priority queue implementation, all else being equal, as a result of the time spent serving non-EF queues by the round robin scheduler.

EF实现的另一个示例是加权循环调度程序。这样的实现通常不能支持与链路速度一样高的R值,因为在存在竞争业务的情况下可以服务EF业务的最大速率将受到其他队列的数量和赋予它们的权重的影响。此外,由于循环调度程序服务于非EF队列所花费的时间,这样的实现可能具有高于优先级队列实现的E_a值,所有其他值都相等。

Finally, it is possible to implement hierarchical scheduling algorithms, such that some non-FIFO scheduling algorithm is run on sub-flows within the EF aggregate, while the EF aggregate as a whole could be served at high priority or with a large weight by the top-level scheduler. Such an algorithm might perform per-input scheduling or per-microflow scheduling within the EF aggregate, for example. Because such algorithms lead to non-FIFO service within the EF 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 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 be most appropriate.

最后,可以实现分层调度算法,使得一些非FIFO调度算法在EF聚合内的子流上运行,而EF聚合作为一个整体可以由顶级调度器以高优先级或大权重服务。例如,这种算法可以在EF聚合中执行每输入调度或每微流调度。由于此类算法导致EF聚合内的非FIFO服务,因此此类算法的E_p值可能高于其他实现。对于这种类型的某些调度器,可能很难在E_p上提供适用于任何交通到达模式的有意义的界限,因此“未定义”的值可能是最合适的。

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.

应该注意的是,Diffserv域提供多个EF实例是完全可以接受的。每个实例都应符合本规范第2.2节中的方程式。EF的多个实例对每个实例的E_a和E_p值的影响很大程度上取决于多个实例的实现方式。例如,在多级优先级调度器中,不处于最高优先级的EF实例可能会经历相对较长的时间段,当它没有接收到服务时,却服务于更高优先级的EF实例。这将导致相对较大的E_a和E_p值。相比之下,在类似WFQ的调度器中,EF的每个实例将由以某种配置速率服务的队列表示,并且E_a和E_p的值可能与单个EF实例的值相似。

Authors' Addresses

作者地址

Bruce Davie Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA, 01824

布鲁斯·戴维斯思科系统公司,马萨诸塞州切姆斯福德阿波罗大道300号,邮编01824

   EMail: bsd@cisco.com
        
   EMail: bsd@cisco.com
        

Anna Charny Cisco Systems 300 Apollo Drive Chelmsford, MA 01824

马萨诸塞州切姆斯福德阿波罗大道300号安娜查尼思科系统公司01824

   EMail: acharny@cisco.com
        
   EMail: acharny@cisco.com
        

Jon Bennett Motorola 3 Highwood Drive East Tewksbury, MA 01876

乔恩·贝内特:马萨诸塞州特克斯伯里市东海伍德大道3号摩托罗拉01876

   EMail: jcrb@motorola.com
        
   EMail: jcrb@motorola.com
        

Kent Benson Tellabs Research Center 3740 Edison Lake Parkway #101 Mishawaka, IN 46545

肯特·本森·特拉布研究中心3740爱迪生湖公园路#101米沙瓦卡,46545

   EMail: Kent.Benson@tellabs.com
        
   EMail: Kent.Benson@tellabs.com
        

Jean-Yves Le Boudec ICA-EPFL, INN Ecublens, CH-1015 Lausanne-EPFL, Switzerland

Jean-Yves Le Boudec ICA-EPFL,瑞士洛桑EPFL CH-1015埃克布伦斯酒店

   EMail: jean-yves.leboudec@epfl.ch
        
   EMail: jean-yves.leboudec@epfl.ch
        

Bill Courtney TRW Bldg. 201/3702 One Space Park Redondo Beach, CA 90278

加利福尼亚州雷东多海滩太空公园一号比尔·考特尼TRW大厦201/3702号,邮编90278

   EMail: bill.courtney@trw.com
        
   EMail: bill.courtney@trw.com
        

Shahram Davari PMC-Sierra Inc 411 Legget Drive Ottawa, ON K2K 3C9, Canada

加拿大K2K 3C9渥太华Legget大道411号Shahram Davari PMC Sierra Inc

   EMail: shahram_davari@pmc-sierra.com
        
   EMail: shahram_davari@pmc-sierra.com
        

Victor Firoiu Nortel Networks 600 Tech Park Billerica, MA 01821

Victor Firoiu Nortel Networks 600科技园马萨诸塞州比尔里卡01821

   EMail: vfiroiu@nortelnetworks.com
        
   EMail: vfiroiu@nortelnetworks.com
        

Dimitrios Stiliadis Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733

迪米特里奥斯·斯蒂利亚迪斯·朗讯科技公司,新泽西州霍姆德尔克劳福德角路101号,邮编:07733

   EMail: stiliadi@bell-labs.com
        
   EMail: stiliadi@bell-labs.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。