Network Working Group Y. Bernet
Request for Comments: 3290 Microsoft
Category: Informational S. Blake
Ericsson
D. Grossman
Motorola
A. Smith
Harbour Networks
May 2002
Network Working Group Y. Bernet
Request for Comments: 3290 Microsoft
Category: Informational S. Blake
Ericsson
D. Grossman
Motorola
A. Smith
Harbour Networks
May 2002
An Informal Management Model for Diffserv Routers
一种区分服务路由器的非正式管理模型
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture.
本文提出了一种区分服务（Diffserv）路由器的非正式管理模型，用于路由器的管理和配置。该模型定义了功能数据路径元素（例如，分类器、仪表、动作、标记、绝对丢弃、计数、多路复用）、算法丢弃器、队列和调度程序。它描述了这些元素的可能配置参数，以及它们如何相互连接以实现Diffserv体系结构中描述的流量调节和每跳行为（PHB）功能范围。
Table of Contents
目录
1 Introduction ................................................. 3
2 Glossary ..................................................... 4
3 Conceptual Model ............................................. 7
3.1 Components of a Diffserv Router ............................ 7
3.1.1 Datapath ................................................. 7
3.1.2 Configuration and Management Interface ................... 9
3.1.3 Optional QoS Agent Module ................................ 10
3.2 Diffserv Functions at Ingress and Egress ................... 10
3.3 Shaping and Policing ....................................... 12
3.4 Hierarchical View of the Model ............................. 12
4 Classifiers .................................................. 13
1 Introduction ................................................. 3
2 Glossary ..................................................... 4
3 Conceptual Model ............................................. 7
3.1 Components of a Diffserv Router ............................ 7
3.1.1 Datapath ................................................. 7
3.1.2 Configuration and Management Interface ................... 9
3.1.3 Optional QoS Agent Module ................................ 10
3.2 Diffserv Functions at Ingress and Egress ................... 10
3.3 Shaping and Policing ....................................... 12
3.4 Hierarchical View of the Model ............................. 12
4 Classifiers .................................................. 13
4.1 Definition ................................................. 13
4.1.1 Filters .................................................. 15
4.1.2 Overlapping Filters ...................................... 15
4.2 Examples ................................................... 16
4.2.1 Behavior Aggregate (BA) Classifier ....................... 16
4.2.2 Multi-Field (MF) Classifier .............................. 17
4.2.3 Free-form Classifier ..................................... 17
4.2.4 Other Possible Classifiers ............................... 18
5 Meters ....................................................... 19
5.1 Examples ................................................... 20
5.1.1 Average Rate Meter ....................................... 20
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ......... 21
5.1.3 Two-Parameter Token Bucket Meter ......................... 21
5.1.4 Multi-Stage Token Bucket Meter ........................... 22
5.1.5 Null Meter ............................................... 23
6 Action Elements .............................................. 23
6.1 DSCP Marker ................................................ 24
6.2 Absolute Dropper ........................................... 24
6.3 Multiplexor ................................................ 25
6.4 Counter .................................................... 25
6.5 Null Action ................................................ 25
7 Queuing Elements ............................................. 25
7.1 Queuing Model .............................................. 26
7.1.1 FIFO Queue ............................................... 27
7.1.2 Scheduler ................................................ 28
7.1.3 Algorithmic Dropper ...................................... 30
7.2 Sharing load among traffic streams using queuing ........... 33
7.2.1 Load Sharing ............................................. 34
7.2.2 Traffic Priority ......................................... 35
8 Traffic Conditioning Blocks (TCBs) ........................... 35
8.1 TCB ........................................................ 36
8.1.1 Building blocks for Queuing .............................. 37
8.2 An Example TCB ............................................. 37
8.3 An Example TCB to Support Multiple Customers ............... 42
8.4 TCBs Supporting Microflow-based Services ................... 44
8.5 Cascaded TCBs .............................................. 47
9 Security Considerations ...................................... 47
10 Acknowledgments ............................................. 47
11 References .................................................. 47
Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 50
Authors' Addresses ............................................. 55
Full Copyright Statement........................................ 56
4.1 Definition ................................................. 13
4.1.1 Filters .................................................. 15
4.1.2 Overlapping Filters ...................................... 15
4.2 Examples ................................................... 16
4.2.1 Behavior Aggregate (BA) Classifier ....................... 16
4.2.2 Multi-Field (MF) Classifier .............................. 17
4.2.3 Free-form Classifier ..................................... 17
4.2.4 Other Possible Classifiers ............................... 18
5 Meters ....................................................... 19
5.1 Examples ................................................... 20
5.1.1 Average Rate Meter ....................................... 20
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ......... 21
5.1.3 Two-Parameter Token Bucket Meter ......................... 21
5.1.4 Multi-Stage Token Bucket Meter ........................... 22
5.1.5 Null Meter ............................................... 23
6 Action Elements .............................................. 23
6.1 DSCP Marker ................................................ 24
6.2 Absolute Dropper ........................................... 24
6.3 Multiplexor ................................................ 25
6.4 Counter .................................................... 25
6.5 Null Action ................................................ 25
7 Queuing Elements ............................................. 25
7.1 Queuing Model .............................................. 26
7.1.1 FIFO Queue ............................................... 27
7.1.2 Scheduler ................................................ 28
7.1.3 Algorithmic Dropper ...................................... 30
7.2 Sharing load among traffic streams using queuing ........... 33
7.2.1 Load Sharing ............................................. 34
7.2.2 Traffic Priority ......................................... 35
8 Traffic Conditioning Blocks (TCBs) ........................... 35
8.1 TCB ........................................................ 36
8.1.1 Building blocks for Queuing .............................. 37
8.2 An Example TCB ............................................. 37
8.3 An Example TCB to Support Multiple Customers ............... 42
8.4 TCBs Supporting Microflow-based Services ................... 44
8.5 Cascaded TCBs .............................................. 47
9 Security Considerations ...................................... 47
10 Acknowledgments ............................................. 47
11 References .................................................. 47
Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 50
Authors' Addresses ............................................. 55
Full Copyright Statement........................................ 56
Differentiated Services (Diffserv) [DSARCH] is a set of technologies which allow network service providers to offer services with different kinds of network quality-of-service (QoS) objectives to different customers and their traffic streams. This document uses terminology defined in [DSARCH] and [NEWTERMS] (some of these definitions are included here in Section 2 for completeness).
区分服务（Diffserv）[DSARCH]是一组允许网络服务提供商向不同的客户及其业务流提供具有不同类型的网络服务质量（QoS）目标的服务的技术。本文件使用[DSARCH]和[NEWTERMS]中定义的术语（为了完整起见，其中一些定义包含在第2节中）。
The premise of Diffserv networks is that routers within the core of the network handle packets in different traffic streams by forwarding them using different per-hop behaviors (PHBs). The PHB to be applied is indicated by a Diffserv codepoint (DSCP) in the IP header of each packet [DSFIELD]. The DSCP markings are applied either by a trusted upstream node, e.g., a customer, or by the edge routers on entry to the Diffserv network.
Diffserv网络的前提是，网络核心内的路由器通过使用不同的每跳行为（PHB）转发不同流量流中的数据包来处理数据包。要应用的PHB由每个数据包的IP报头中的Diffserv代码点（DSCP）指示[DSFIELD]。DSCP标记由受信任的上游节点（例如客户）或进入Diffserv网络的边缘路由器应用。
The advantage of such a scheme is that many traffic streams can be aggregated to one of a small number of behavior aggregates (BA), which are each forwarded using the same PHB at the router, thereby simplifying the processing and associated storage. In addition, there is no signaling other than what is carried in the DSCP of each packet, and no other related processing that is required in the core of the Diffserv network since QoS is invoked on a packet-by-packet basis.
这种方案的优点是，许多业务流可以聚合为少量行为聚合（BA）中的一个，每个行为聚合（BA）在路由器处使用相同的PHB转发，从而简化处理和相关存储。此外，除了每个分组的DSCP中承载的内容之外，没有其他信令，并且由于QoS是在分组的基础上调用的，因此Diffserv网络的核心中不需要其他相关处理。
The Diffserv architecture enables a variety of possible services which could be deployed in a network. These services are reflected to customers at the edges of the Diffserv network in the form of a Service Level Specification (SLS - see [NEWTERMS]). Whilst further discussion of such services is outside the scope of this document (see [PDBDEF]), the ability to provide these services depends on the availability of cohesive management and configuration tools that can be used to provision and monitor a set of Diffserv routers in a coordinated manner. To facilitate the development of such configuration and management tools it is helpful to define a conceptual model of a Diffserv router that abstracts away implementation details of particular Diffserv routers from the parameters of interest for configuration and management. The purpose of this document is to define such a model.
Diffserv体系结构允许在网络中部署各种可能的服务。这些服务以服务级别规范（SLS-见[NEWTERMS]）的形式反映给Diffserv网络边缘的客户。虽然对此类服务的进一步讨论不在本文件的范围内（见[PDBDEF]），但提供这些服务的能力取决于是否有统一的管理和配置工具，这些工具可用于以协调的方式提供和监控一组区分服务路由器。为了促进此类配置和管理工具的开发，有助于定义区分服务路由器的概念模型，该模型从配置和管理的相关参数中抽象出特定区分服务路由器的实现细节。本文件旨在定义此类模型。
The basic forwarding functionality of a Diffserv router is defined in other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
Diffserv路由器的基本转发功能在其他规范中定义；e、 例如，[DSARCH、DSFIELD、AF-PHB、EF-PHB]。
This document is not intended in any way to constrain or to dictate the implementation alternatives of Diffserv routers. It is expected that router implementers will demonstrate a great deal of variability in their implementations. To the extent that implementers are able
本文档无意以任何方式限制或规定Diffserv路由器的实现备选方案。预计路由器实现者将在其实现中展示大量的可变性。在实施者能够
to model their implementations using the abstractions described in this document, configuration and management tools will more readily be able to configure and manage networks incorporating Diffserv routers of assorted origins.
为了使用本文档中描述的抽象对其实现进行建模，配置和管理工具将更容易配置和管理包含各种来源的Diffserv路由器的网络。
This model is intended to be abstract and capable of representing the configuration parameters important to Diffserv functionality for a variety of specific router implementations. It is not intended as a guide to system implementation nor as a formal modeling description. This model serves as the rationale for the design of an SNMP MIB [DSMIB] and for other configuration interfaces (e.g., other policy-management protocols) and, possibly, more detailed formal models (e.g., [QOSDEVMOD]): these should all be consistent with this model.
该模型是抽象的，能够表示对各种特定路由器实现的区分服务功能非常重要的配置参数。它既不是系统实现的指南，也不是正式的建模描述。该模型作为设计SNMP MIB[DSMIB]和其他配置接口（如其他策略管理协议）以及更详细的正式模型（如[QOSDEVMOD]）的基本原理：这些都应与该模型一致。
o Section 3 starts by describing the basic high-level blocks of a Diffserv router. It explains the concepts used in the model, including the hierarchical management model for these blocks which uses low-level functional datapath elements such as Classifiers, Actions, Queues.
o 第3节首先描述区分服务路由器的基本高级模块。它解释了模型中使用的概念，包括这些块的分层管理模型，该模型使用低级功能数据路径元素，如分类器、动作、队列。
o Section 4 describes Classifier elements.
o 第4节描述了分类器元素。
o Section 5 discusses Meter elements.
o 第5节讨论仪表元件。
o Section 6 discusses Action elements.
o 第6节讨论了行动要素。
o Section 7 discusses the basic queuing elements of Algorithmic Droppers, Queues, and Schedulers and their functional behaviors (e.g., traffic shaping).
o 第7节讨论了算法拖放器、队列和调度器的基本排队元素及其功能行为（例如，流量整形）。
o Section 8 shows how the low-level elements can be combined to build modules called Traffic Conditioning Blocks (TCBs) which are useful for management purposes.
o 第8节说明了如何将低级元素组合起来，以构建称为流量调节块（TCB）的模块，这些模块对于管理目的非常有用。
o Section 9 discusses security concerns.
o 第9节讨论了安全问题。
o Appendix A contains a brief discussion of the token bucket and leaky bucket algorithms used in this model and some of the practical effects of the use of token buckets within the Diffserv architecture.
o 附录A简要讨论了该模型中使用的令牌桶和漏桶算法，以及在Diffserv体系结构中使用令牌桶的一些实际效果。
This document uses terminology which is defined in [DSARCH]. There is also current work-in-progress on this terminology in the IETF and some of the definitions provided here are taken from that work. Some
本文件使用[DSARCH]中定义的术语。IETF中关于该术语的当前工作也在进行中，此处提供的一些定义取自该工作。一些
of the terms from these other references are defined again here in order to provide additional detail, along with some new terms specific to this document.
此处再次定义了这些其他参考文献中的术语，以提供更多详细信息，以及本文件特定的一些新术语。
Absolute A functional datapath element which simply discards all Dropper packets arriving at its input.
绝对一个功能数据路径元素，它简单地丢弃到达其输入端的所有滴管数据包。
Algorithmic A functional datapath element which selectively Dropper discards packets that arrive at its input, based on a discarding algorithm. It has one data input and one output.
算法一种功能性数据路径元素，根据丢弃算法，滴管有选择地丢弃到达其输入端的数据包。它有一个数据输入和一个输出。
Classifier A functional datapath element which consists of filters that select matching and non-matching packets. Based on this selection, packets are forwarded along the appropriate datapath within the router. A classifier, therefore, splits a single incoming traffic stream into multiple outgoing streams.
分类器一种功能性数据路径元素，由选择匹配和非匹配数据包的过滤器组成。基于此选择，数据包沿着路由器内的适当数据路径转发。因此，分类器将单个传入业务流拆分为多个传出流。
Counter A functional datapath element which updates a packet counter and also an octet counter for every packet that passes through it.
计数器一种功能性数据通路元素，它为通过它的每个数据包更新一个数据包计数器和一个八位字节计数器。
Datapath A conceptual path taken by packets with particular characteristics through a Diffserv router. Decisions as to the path taken by a packet are made by functional datapath elements such as Classifiers and Meters.
数据路径具有特定特征的数据包通过区分服务路由器所采用的概念路径。关于数据包采取的路径的决定是由功能数据路径元素（如分类器和仪表）做出的。
Filter A set of wildcard, prefix, masked, range and/or exact match conditions on the content of a packet's headers or other data, and/or on implicit or derived attributes associated with the packet. A filter is said to match only if each condition is satisfied.
根据数据包头或其他数据的内容和/或与数据包相关联的隐式或派生属性筛选一组通配符、前缀、掩码、范围和/或精确匹配条件。仅当满足每个条件时，才称过滤器匹配。
Functional A basic building block of the conceptual router. Datapath Typical elements are Classifiers, Meters, Actions, Element Algorithmic Droppers, Queues and Schedulers.
功能路由器是概念路由器的基本构建块。数据路径的典型元素有分类器、仪表、动作、元素算法拖放器、队列和调度程序。
Multiplexer A multiplexor. (Mux)
多路复用器多路复用器。（多路复用器）
Multiplexor A functional datapath element that merges multiple (Mux) traffic streams (datapaths) into a single traffic stream (datapath).
多路复用器将多个（Mux）业务流（数据路径）合并为单个业务流（数据路径）的功能数据路径元素。
Non-work- A property of a scheduling algorithm such that it conserving services packets no sooner than a scheduled departure time, even if this means leaving packets queued while the output (e.g., a network link or connection to the next element) is idle.
非工作-调度算法的一种属性，使得它在不早于预定出发时间的情况下保存服务数据包，即使这意味着在输出（例如，网络链路或到下一个元素的连接）空闲时让数据包排队。
Policing The process of comparing the arrival of data packets against a temporal profile and forwarding, delaying or dropping them so as to make the output stream conformant to the profile.
监控将数据包的到达与时间配置文件进行比较的过程，并转发、延迟或丢弃数据包，以使输出流符合该配置文件。
Queuing A combination of functional datapath elements Block that modulates the transmission of packets belonging to a traffic streams and determines their ordering, possibly storing them temporarily or discarding them.
排队功能数据通路元素的组合块，用于调制属于业务流的数据包的传输并确定其顺序，可能临时存储或丢弃它们。
Scheduling An algorithm which determines which queue of a set algorithm of queues to service next. This may be based on the relative priority of the queues, on a weighted fair bandwidth sharing policy or some other policy. Such an algorithm may be either work-conserving or non-work-conserving.
调度一种算法，用于确定队列集合算法中下一个要服务的队列。这可能基于队列的相对优先级、加权公平带宽共享策略或某些其他策略。这种算法可以是保功算法，也可以是非保功算法。
Service-Level A set of parameters and their values which together Specification define the treatment offered to a traffic stream by a (SLS) Diffserv domain.
服务级别一组参数及其值，这些参数和值共同定义了（SLS）区分服务域对业务流的处理。
Shaping The process of delaying packets within a traffic stream to cause it to conform to some defined temporal profile. Shaping can be implemented using a queue serviced by a non-work-conserving scheduling algorithm.
对业务流中的数据包进行延迟以使其符合某个定义的时间分布的过程进行整形。成形可以使用由非工作节约调度算法提供服务的队列来实现。
Traffic A logical datapath entity consisting of a number of Conditioning functional datapath elements interconnected in Block (TCB) such a way as to perform a specific set of traffic conditioning functions on an incoming traffic stream. A TCB can be thought of as an entity with one input and one or more outputs and a set of control parameters.
流量：一种逻辑数据路径实体，由多个在块（TCB）中互连的调节功能数据路径元素组成，以便对传入流量流执行一组特定的流量调节功能。TCB可以被视为具有一个输入、一个或多个输出以及一组控制参数的实体。
Traffic A set of parameters and their values which together Conditioning specify a set of classifier rules and a traffic Specification profile. A TCS is an integral element of a SLS. (TCS)
流量一组参数及其值，共同指定一组分类器规则和流量规范配置文件。TCS是SLS的一个组成部分。（TCS）
Work- A property of a scheduling algorithm such that it conserving services a packet, if one is available, at every transmission opportunity.
工作-调度算法的一种属性，使得它在每个传输机会为一个数据包（如果有）提供服务。
This section introduces a block diagram of a Diffserv router and describes the various components illustrated in Figure 1. Note that a Diffserv core router is likely to require only a subset of these components: the model presented here is intended to cover the case of both Diffserv edge and core routers.
本节介绍Diffserv路由器的框图，并描述图1所示的各种组件。请注意，Diffserv核心路由器可能只需要这些组件的一个子集：此处提供的模型旨在涵盖Diffserv边缘路由器和核心路由器的情况。
The conceptual model includes abstract definitions for the following:
概念模型包括以下方面的抽象定义：
o Traffic Classification elements.
o 交通分类要素。
o Metering functions.
o 计量功能。
o Actions of Marking, Absolute Dropping, Counting, and Multiplexing.
o 标记、绝对下降、计数和多路复用的动作。
o Queuing elements, including capabilities of algorithmic dropping and scheduling.
o 队列元素，包括算法丢弃和调度功能。
o Certain combinations of the above functional datapath elements into higher-level blocks known as Traffic Conditioning Blocks (TCBs).
o 将上述功能数据路径元素的某些组合放入称为流量调节块（TCB）的高级块中。
The components and combinations of components described in this document form building blocks that need to be manageable by Diffserv configuration and management tools. One of the goals of this document is to show how a model of a Diffserv device can be built using these component blocks. This model is in the form of a connected directed acyclic graph (DAG) of functional datapath elements that describes the traffic conditioning and queuing behaviors that any particular packet will experience when forwarded to the Diffserv router. Figure 1 illustrates the major functional blocks of a Diffserv router.
本文档中描述的组件和组件组合构成了需要通过Diffserv配置和管理工具进行管理的构建块。本文档的目标之一是展示如何使用这些组件块构建区分服务设备的模型。该模型采用功能数据路径元素的连接有向无环图（DAG）的形式，该图描述了任何特定数据包在转发到Diffserv路由器时所经历的流量调节和排队行为。图1显示了Diffserv路由器的主要功能块。
An ingress interface, routing core, and egress interface are illustrated at the center of the diagram. In actual router implementations, there may be an arbitrary number of ingress and egress interfaces interconnected by the routing core. The routing core element serves as an abstraction of a router's normal routing
图的中心显示了入口接口、路由核心和出口接口。在实际路由器实现中，可能存在由路由核心互连的任意数量的入口和出口接口。路由核心元素用作路由器正常路由的抽象
and switching functionality. The routing core moves packets between interfaces according to policies outside the scope of Diffserv (note: it is possible that such policies for output-interface selection might involve use of packet fields such as the DSCP but this is outside the scope of this model). The actual queuing delay and packet loss behavior of a specific router's switching fabric/backplane is not modeled by the routing core; these should be modeled using the functional datapath elements described later. The routing core of this model can be thought of as an infinite bandwidth, zero-delay interconnect between interfaces - properties like the behavior of the core when overloaded need to be reflected back into the queuing elements that are modeled around it (e.g., when too much traffic is directed across the core at an egress interface), the excess must either be dropped or queued somewhere: the elements performing these functions must be modeled on one of the interfaces involved.
和切换功能。路由核心根据Diffserv范围之外的策略在接口之间移动数据包（注意：用于输出接口选择的此类策略可能涉及使用数据包字段，如DSCP，但这不在该模型的范围内）。路由核心不模拟特定路由器交换结构/背板的实际排队延迟和丢包行为；应该使用后面描述的功能性数据路径元素对它们进行建模。该模型的路由核心可被视为接口之间的无限带宽、零延迟互连——过载时核心的行为等属性需要反射回围绕其建模的队列元素中（例如，当过多流量在出口接口通过核心定向时），多余的部分必须丢弃或排队：执行这些功能的元素必须在所涉及的一个接口上建模。
The components of interest at the ingress to and egress from interfaces are the functional datapath elements (e.g., Classifiers, Queuing elements) that support Diffserv traffic conditioning and per-hop behaviors [DSARCH]. These are the fundamental components comprising a Diffserv router and are the focal point of this model.
接口入口和出口处感兴趣的组件是支持区分服务流量调节和每跳行为[DSARCH]的功能数据路径元素（例如，分类器、队列元素）。这些是构成区分服务路由器的基本组件，也是该模型的重点。
+---------------+
| Diffserv |
Mgmt | configuration |
<----+-->| & management |------------------+
SNMP,| | interface | |
COPS | +---------------+ |
etc. | | |
| | |
| v v
| +-------------+ +-------------+
| | ingress i/f | +---------+ | egress i/f |
-------->| classify, |-->| routing |-->| classify, |---->
data | | meter, | | core | | meter |data out
in | | action, | +---------+ | action, |
| | queuing | | queuing |
| +-------------+ +-------------+
| ^ ^
| | |
| | |
| +------------+ |
+-->| QOS agent | |
-------->| (optional) |---------------------+
QOS |(e.g., RSVP)|
cntl +------------+
msgs
+---------------+
| Diffserv |
Mgmt | configuration |
<----+-->| & management |------------------+
SNMP,| | interface | |
COPS | +---------------+ |
etc. | | |
| | |
| v v
| +-------------+ +-------------+
| | ingress i/f | +---------+ | egress i/f |
-------->| classify, |-->| routing |-->| classify, |---->
data | | meter, | | core | | meter |data out
in | | action, | +---------+ | action, |
| | queuing | | queuing |
| +-------------+ +-------------+
| ^ ^
| | |
| | |
| +------------+ |
+-->| QOS agent | |
-------->| (optional) |---------------------+
QOS |(e.g., RSVP)|
cntl +------------+
msgs
Figure 1: Diffserv Router Major Functional Blocks
图1：区分服务路由器主要功能块
Diffserv operating parameters are monitored and provisioned through this interface. Monitored parameters include statistics regarding traffic carried at various Diffserv service levels. These statistics may be important for accounting purposes and/or for tracking compliance to Traffic Conditioning Specifications (TCSs) negotiated with customers. Provisioned parameters are primarily the TCS parameters for Classifiers and Meters and the associated PHB configuration parameters for Actions and Queuing elements. The network administrator interacts with the Diffserv configuration and management interface via one or more management protocols, such as SNMP or COPS, or through other router configuration tools such as serial terminal or telnet consoles.
Diffserv操作参数通过该接口进行监控和设置。监控的参数包括关于不同Diffserv服务级别上承载的流量的统计信息。这些统计数据对于会计目的和/或跟踪与客户协商的交通调节规范（TCS）的合规性可能很重要。配置的参数主要是分类器和仪表的TCS参数以及操作和队列元素的相关PHB配置参数。网络管理员通过一个或多个管理协议（如SNMP或COPS）或通过其他路由器配置工具（如串行终端或telnet控制台）与Diffserv配置和管理接口进行交互。
Specific policy rules and goals governing the Diffserv behavior of a router are presumed to be installed by policy management mechanisms. However, Diffserv routers are always subject to implementation limits
控制路由器区分服务行为的特定策略规则和目标假定由策略管理机制安装。然而，区分服务路由器总是受到实现限制
which scope the kinds of policies which can be successfully implemented by the router. External reporting of such implementation capabilities is considered out of scope for this document.
路由器可以成功实现的策略类型。此类实施能力的外部报告不在本文件范围内。
Diffserv routers may snoop or participate in either per-microflow or per-flow-aggregate signaling of QoS requirements [E2E] (e.g., using the RSVP protocol). Snooping of RSVP messages may be used, for example, to learn how to classify traffic without actually participating as a RSVP protocol peer. Diffserv routers may reject or admit RSVP reservation requests to provide a means of admission control to Diffserv-based services or they may use these requests to trigger provisioning changes for a flow-aggregation in the Diffserv network. A flow-aggregation in this context might be equivalent to a Diffserv BA or it may be more fine-grained, relying on a multi-field (MF) classifier [DSARCH]. Note that the conceptual model of such a router implements the Integrated Services Model as described in [INTSERV], applying the control plane controls to the data classified and conditioned in the data plane, as described in [E2E].
Diffserv路由器可窥探或参与QoS要求[E2E]的每微流或每流聚合信令（例如，使用RSVP协议）。例如，可以使用对RSVP消息的窥探来了解如何在不作为RSVP协议对等方实际参与的情况下对流量进行分类。区分服务路由器可以拒绝或接纳RSVP保留请求，以提供对基于区分服务的服务的接纳控制手段，或者它们可以使用这些请求来触发区分服务网络中的流聚合的设置更改。在此上下文中，流聚合可能相当于Diffserv BA，或者它可能更细粒度，依赖于多字段（MF）分类器[DSARCH]。注意，这种路由器的概念模型实现了[INTSERV]中所述的综合服务模型，将控制平面控制应用于数据平面中分类和调节的数据，如[E2E]中所述。
Note that a QoS Agent component of a Diffserv router, if present, might be active only in the control plane and not in the data plane. In this scenario, RSVP could be used merely to signal reservation state without installing any actual reservations in the data plane of the Diffserv router: the data plane could still act purely on Diffserv DSCPs and provide PHBs for handling data traffic without the normal per-microflow handling expected to support some Intserv services.
请注意，Diffserv路由器的QoS代理组件（如果存在）可能仅在控制平面中处于活动状态，而不在数据平面中。在这种情况下，RSVP可以仅用于发出保留状态的信号，而无需在Diffserv路由器的数据平面中安装任何实际保留：数据平面仍然可以纯粹作用于Diffserv DSCP，并提供PHB来处理数据流量，而无需正常的每微流处理来支持某些Intserv服务。
This document focuses on the Diffserv-specific components of the router. Figure 2 shows a high-level view of ingress and egress interfaces of a router. The diagram illustrates two Diffserv router interfaces, each having a set of ingress and a set of egress elements. It shows classification, metering, action and queuing functions which might be instantiated at each interface's ingress and egress.
本文档重点介绍路由器的区分服务特定组件。图2显示了路由器入口和出口接口的高级视图。该图显示了两个Diffserv路由器接口，每个接口都有一组入口和一组出口元素。它显示了分类、计量、操作和排队功能，这些功能可能在每个接口的入口和出口处实例化。
The simple diagram of Figure 2 assumes that the set of Diffserv functions to be carried out on traffic on a given interface are independent of those functions on all other interfaces. There are some architectures where Diffserv functions may be shared amongst multiple interfaces (e.g., processor and buffering resources that handle multiple interfaces on the same line card before forwarding across a routing core). The model presented in this document may be easily extended to handle such cases; however, this topic is not
图2的简单示意图假设在给定接口上对流量执行的一组Diffserv函数独立于所有其他接口上的那些函数。在某些架构中，Diffserv功能可以在多个接口之间共享（例如，处理器和缓冲资源，在通过路由核心转发之前处理同一线路卡上的多个接口）。本文件中提出的模型可轻松扩展以处理此类情况；然而，这个话题并不重要
treated further here as it leads to excessive complexity in the explanation of the concepts.
在这里进一步处理，因为它导致概念解释过于复杂。
Interface A Interface B
+-------------+ +---------+ +-------------+
| ingress: | | | | egress: |
| classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |--->
| action, | | | | action, |
| queuing | | routing | | queuing |
+-------------+ | core | +-------------+
| egress: | | | | ingress: |
| classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<---
| action, | | | | action, |
| queuing | +---------+ | queuing |
+-------------+ +-------------+
Interface A Interface B
+-------------+ +---------+ +-------------+
| ingress: | | | | egress: |
| classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |--->
| action, | | | | action, |
| queuing | | routing | | queuing |
+-------------+ | core | +-------------+
| egress: | | | | ingress: |
| classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<---
| action, | | | | action, |
| queuing | +---------+ | queuing |
+-------------+ +-------------+
Figure 2. Traffic Conditioning and Queuing Elements
图2。交通调节和排队要素
In principle, if one were to construct a network entirely out of two-port routers (connected by LANs or similar media), then it might be necessary for each router to perform four QoS control functions in the datapath on traffic in each direction:
原则上，如果要完全由两个端口路由器（通过LAN或类似介质连接）构成网络，则每个路由器可能需要在数据路径中对每个方向的流量执行四项QoS控制功能：
- Classify each message according to some set of rules, possibly just a "match everything" rule.
- 根据一组规则对每条消息进行分类，可能只是“匹配所有内容”规则。
- If necessary, determine whether the data stream the message is part of is within or outside its rate by metering the stream.
- 如有必要，通过测量数据流来确定消息所属的数据流是否在其速率之内或之外。
- Perform a set of resulting actions, including applying a drop policy appropriate to the classification and queue in question and perhaps additionally marking the traffic with a Differentiated Services Code Point (DSCP) [DSFIELD].
- 执行一组生成的操作，包括应用适用于所讨论的分类和队列的丢弃策略，可能还使用区分服务代码点（DSCP）[DSFIELD]标记流量。
- Enqueue the traffic for output in the appropriate queue. The scheduling of output from this queue may lead to shaping of the traffic or may simply cause it to be forwarded with some minimum rate or maximum latency assurance.
- 将要输出的通信排队到适当的队列中。该队列输出的调度可能导致流量的成形，或者可能仅仅导致以某种最小速率或最大延迟保证转发流量。
If the network is now built out of N-port routers, the expected behavior of the network should be identical. Therefore, this model must provide for essentially the same set of functions at the ingress as on the egress of a router's interfaces. The one point of difference in the model between ingress and the egress is that all traffic at the egress of an interface is queued, while traffic at the ingress to an interface is likely to be queued only for shaping
如果网络现在由N端口路由器构建，那么网络的预期行为应该是相同的。因此，该模型必须在路由器接口的入口和出口提供基本相同的功能集。入口和出口之间的模型中的一个不同点是，接口出口处的所有流量都排队，而接口入口处的流量很可能仅为整形而排队
purposes, if at all. Therefore, equivalent functional datapath elements may be modeled at both the ingress to and egress from an interface.
目的，如果有的话。因此，可以在接口的入口和出口处对等效功能数据路径元素进行建模。
Note that it is not mandatory that each of these functional datapath elements be implemented at both ingress and egress; equally, the model allows that multiple sets of these elements may be placed in series and/or in parallel at ingress or at egress. The arrangement of elements is dependent on the service requirements on a particular interface on a particular router. By modeling these elements at both ingress and egress, it is not implied that they must be implemented in this way in a specific router. For example, a router may implement all shaping and PHB queuing at the interface egress or may instead implement it only at the ingress. Furthermore, the classification needed to map a packet to an egress queue (if present) need not be implemented at the egress but instead might be implemented at the ingress, with the packet passed through the routing core with in-band control information to allow for egress queue selection.
注意，这些功能数据路径元素中的每一个都必须在入口和出口处实现，这不是强制性的；同样，该模型允许在入口或出口处串联和/或并联放置多组这些元件。元素的排列取决于特定路由器上特定接口上的服务要求。通过在入口和出口处对这些元素进行建模，并不意味着它们必须以这种方式在特定路由器中实现。例如，路由器可以在接口出口处实现所有整形和PHB排队，或者可以改为仅在入口处实现。此外，将分组映射到出口队列（如果存在）所需的分类不需要在出口处实现，而是可以在入口处实现，其中分组通过具有带内控制信息的路由核心以允许出口队列选择。
Specifically, some interfaces will be at the outer "edge" and some will be towards the "core" of the Diffserv domain. It is to be expected (from the general principles guiding the motivation of Diffserv) that "edge" interfaces, or at least the routers that contain them, will implement more complexity and require more configuration than those in the core although this is obviously not a requirement.
具体来说，一些接口将位于Diffserv域的外部“边缘”，一些接口将朝向Diffserv域的“核心”。可以预期（根据指导Diffserv动机的一般原则），“边缘”接口，或至少包含它们的路由器，将实现比核心更复杂的功能，需要更多的配置，尽管这显然不是一个要求。
Diffserv nodes may apply shaping, policing and/or marking to traffic streams that exceed the bounds of their TCS in order to prevent one traffic stream from seizing more than its share of resources from a Diffserv network. In this model, Shaping, sometimes considered as a TC action, is treated as a function of queuing elements - see section 7. Algorithmic Dropping techniques (e.g., RED) are similarly treated since they are often closely associated with queues. Policing is modeled as either a concatenation of a Meter with an Absolute Dropper or as a concatenation of an Algorithmic Dropper with a Scheduler. These elements will discard packets which exceed the TCS.
区分服务节点可以对超出其tc边界的业务流应用整形、监管和/或标记，以防止一个业务流从区分服务网络夺取超过其资源份额的资源。在该模型中，成形（有时被视为TC动作）被视为排队元素的函数-见第7节。算法丢弃技术（如RED）也被类似地处理，因为它们通常与队列密切相关。警务建模为仪表与绝对滴管的连接，或算法滴管与调度器的连接。这些元素将丢弃超过TCS的数据包。
From a device-level configuration management perspective, the following hierarchy exists:
从设备级配置管理的角度来看，存在以下层次结构：
At the lowest level considered here, there are individual functional datapath elements, each with their own configuration parameters and management counters and flags.
在这里考虑的最低级别上，有单独的功能数据路径元素，每个元素都有自己的配置参数、管理计数器和标志。
At the next level, the network administrator manages groupings of these functional datapath elements interconnected in a DAG. These functional datapath elements are organized in self-contained TCBs which are used to implement some desired network policy (see Section 8). One or more TCBs may be instantiated at each interface's ingress or egress; they may be connected in series and/or in parallel configurations on the multiple outputs of a preceding TCB. A TCB can be thought of as a "black box" with one input and one or more outputs (in the data path). Each interface may have a different TCB configuration and each direction (ingress or egress) may too.
在下一级，网络管理员管理在DAG中互连的这些功能数据路径元素的分组。这些功能性数据路径元素组织在自包含的TCB中，用于实现某些期望的网络策略（参见第8节）。可以在每个接口的入口或出口处实例化一个或多个tcb；它们可以在先前TCB的多个输出上以串联和/或并联配置连接。TCB可以被认为是一个“黑匣子”，有一个输入和一个或多个输出（在数据路径中）。每个接口可能具有不同的TCB配置，每个方向（入口或出口）也可能不同。
At the topmost level considered here, the network administrator manages interfaces. Each interface has ingress and egress functionality, with each of these expressed as one or more TCBs. This level of the hierarchy is what was illustrated in Figure 2.
在这里考虑的最顶层，网络管理员管理接口。每个接口都具有入口和出口功能，其中每个接口都表示为一个或多个TCB。这一层次结构如图2所示。
Further levels may be built on top of this hierarchy, in particular ones for aiding in the repetitive configuration tasks likely for routers with many interfaces: some such "template" tools for Diffserv routers are outside the scope of this model but are under study by other working groups within IETF.
可在该层次结构的基础上建立进一步的层次结构，特别是用于帮助具有许多接口的路由器执行重复配置任务的层次结构：一些用于区分服务路由器的“模板”工具不在该模型的范围内，但正在由IETF内的其他工作组进行研究。
Classification is performed by a classifier element. Classifiers are 1:N (fan-out) devices: they take a single traffic stream as input and generate N logically separate traffic streams as output. Classifiers are parameterized by filters and output streams. Packets from the input stream are sorted into various output streams by filters which match the contents of the packet or possibly match other attributes associated with the packet. Various types of classifiers using different filters are described in the following sections. Figure 3 illustrates a classifier, where the outputs connect to succeeding functional datapath elements.
分类由分类器元素执行。分类器是1:N（扇出）设备：它们将单个业务流作为输入，并生成N个逻辑上独立的业务流作为输出。分类器由过滤器和输出流参数化。来自输入流的包通过匹配包的内容或可能匹配与包相关联的其他属性的过滤器被分类到各种输出流中。以下各节介绍了使用不同过滤器的各种类型的分类器。图3展示了一个分类器，其中输出连接到后续的功能数据路径元素。
The simplest possible Classifier element is one that matches all packets that are applied at its input. In this case, the Classifier element is just a no-op and may be omitted.
最简单的分类器元素是匹配在其输入端应用的所有数据包的元素。在这种情况下，分类器元素只是no op，可以省略。
Note that we allow a Multiplexor (see Section 6.5) before the Classifier to allow input from multiple traffic streams. For example, if traffic streams originating from multiple ingress interfaces feed through a single Classifier then the interface number could be one of the packet classification keys used by the Classifier. This optimization may be important for scalability in the management plane. Classifiers may also be cascaded in sequence to perform more complex lookup operations whilst still maintaining such scalability.
请注意，我们允许在分类器之前使用多路复用器（见第6.5节），以允许来自多个业务流的输入。例如，如果来自多个入口接口的业务流馈送通过单个分类器，则接口号可以是分类器使用的分组分类密钥之一。这种优化对于管理平面中的可伸缩性可能很重要。分类器也可以按顺序级联以执行更复杂的查找操作，同时仍然保持这种可伸缩性。
Another example of a packet attribute could be an integer representing the BGP community string associated with the packet's best-matching route. Other contextual information may also be used by a Classifier (e.g., knowledge that a particular interface faces a Diffserv domain or a legacy IP TOS domain [DSARCH] could be used when determining whether a DSCP is present or not).
包属性的另一个示例可以是一个整数，表示与包的最佳匹配路由相关联的BGP团体字符串。分类器也可以使用其他上下文信息（例如，当确定是否存在DSCP时，可以使用特定接口面对区分服务域或传统IP-TOS域[DSARCH]的知识）。
unclassified classified
traffic traffic
+------------+
| |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC
+------------+
unclassified classified
traffic traffic
+------------+
| |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC
+------------+
Figure 3. An Example Classifier
图3。示例分类器
The following BA classifier separates traffic into one of three output streams based on matching filters:
以下BA分类器基于匹配过滤器将流量分离为三个输出流之一：
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
Where the filters are defined to be the following BA filters ([DSARCH], Section 4.2.1):
其中，过滤器定义为以下BA过滤器（[DSARCH]，第4.2.1节）：
Filter DSCP
------ ------
Filter1 101010
Filter2 111111
Filter3 ****** (wildcard)
Filter DSCP
------ ------
Filter1 101010
Filter2 111111
Filter3 ****** (wildcard)
A filter consists of a set of conditions on the component values of a packet's classification key (the header values, contents, and attributes relevant for classification). In the BA classifier example above, the classification key consists of one packet header field, the DSCP, and both Filter1 and Filter2 specify exact-match conditions on the value of the DSCP. Filter3 is a wildcard default filter which matches every packet, but which is only selected in the event that no other more specific filter matches.
筛选器由一组关于数据包分类键的组件值（与分类相关的头值、内容和属性）的条件组成。在上面的BA分类器示例中，分类键由一个数据包头字段DSCP组成，Filter1和Filter2都指定了DSCP值的精确匹配条件。Filter3是一个通配符默认筛选器，它匹配每个数据包，但只有在没有其他更具体的筛选器匹配的情况下才选择它。
In general there are a set of possible component conditions including exact, prefix, range, masked and wildcard matches. Note that ranges can be represented (with less efficiency) as a set of prefixes and that prefix matches are just a special case of both masked and range matches.
通常，存在一组可能的组件条件，包括精确匹配、前缀匹配、范围匹配、屏蔽匹配和通配符匹配。请注意，范围可以表示为一组前缀（效率较低），前缀匹配只是屏蔽匹配和范围匹配的特例。
In the case of a MF classifier, the classification key consists of a number of packet header fields. The filter may specify a different condition for each key component, as illustrated in the example below for a IPv4/TCP classifier:
在MF分类器的情况下，分类密钥由多个数据包头字段组成。过滤器可以为每个关键组件指定不同的条件，如下面的IPv4/TCP分类器示例所示：
Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort
------ ------------- -------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort
------ ------------- -------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
In this example, the fourth octet of the destination IPv4 address and the source TCP port are wildcard or "don't care".
在本例中，目标IPv4地址的第四个八位字节和源TCP端口是通配符或“不在乎”。
MF classification of IP-fragmented packets is impossible if the filter uses transport-layer port numbers (e.g., TCP port numbers). MTU-discovery is therefore a prerequisite for proper operation of a Diffserv network that uses such classifiers.
如果筛选器使用传输层端口号（例如TCP端口号），则无法对IP碎片数据包进行MF分类。因此，MTU发现是使用此类分类器的Diffserv网络正常运行的先决条件。
Note that it is easy to define sets of overlapping filters in a classifier. For example:
请注意，在分类器中定义重叠过滤器集很容易。例如：
Filter IPv4 Src Addr IPv4 Dest Addr
------ ------------- --------------
Filter5 172.31.8.X/24 X/0
Filter6 X/0 172.30.10.1/32
Filter IPv4 Src Addr IPv4 Dest Addr
------ ------------- --------------
Filter5 172.31.8.X/24 X/0
Filter6 X/0 172.30.10.1/32
A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr 172.30.10.1} cannot be uniquely classified by this pair of filters and so a precedence must be established between Filter5 and Filter6 in order to break the tie. This precedence must be established
包含{IP Dest Addr 172.31.8.1，IP Src Addr 172.30.10.1}的数据包不能由这对筛选器唯一分类，因此必须在筛选器5和筛选器6之间建立优先级，以打破这种关系。必须确立这一优先地位
either (a) by a manager which knows that the router can accomplish this particular ordering (e.g., by means of reported capabilities), or (b) by the router along with a mechanism to report to a manager which precedence is being used. Such precedence mechanisms must be supported in any translation of this model into specific syntax for configuration and management protocols.
（a）由知道路由器可以完成该特定排序的管理者（例如，通过报告的能力）或（b）由路由器连同向管理者报告使用的优先级的机制。在将此模型转换为配置和管理协议的特定语法时，必须支持这种优先机制。
As another example, one might want first to disallow certain applications from using the network at all, or to classify some individual traffic streams that are not Diffserv-marked. Traffic that is not classified by those tests might then be inspected for a DSCP. The word "then" implies sequence and this must be specified by means of precedence.
作为另一个示例，您可能希望首先禁止某些应用程序使用网络，或者对一些未进行区分服务标记的单个业务流进行分类。然后，可能会针对DSCP检查那些测试未分类的通信量。“then”一词表示顺序，必须通过优先顺序来指定。
An unambiguous classifier requires that every possible classification key match at least one filter (possibly the wildcard default) and that any ambiguity between overlapping filters be resolved by precedence. Therefore, the classifiers on any given interface must be "complete" and will often include an "everything else" filter as the lowest precedence element in order for the result of classification to be deterministic. Note that this completeness is only required of the first classifier that incoming traffic will meet as it enters an interface - subsequent classifiers on an interface only need to handle the traffic that it is known that they will receive.
无歧义分类器要求每个可能的分类键至少匹配一个过滤器（可能是通配符默认值），并且重叠过滤器之间的任何歧义都可以通过优先级来解决。因此，任何给定接口上的分类器都必须是“完整”的，并且通常会包含一个“其他所有内容”过滤器作为优先级最低的元素，以便分类结果具有确定性。请注意，这种完整性仅要求传入流量在进入接口时遇到的第一个分类器——接口上的后续分类器只需要处理已知它们将接收的流量。
This model of classifier operation makes the assumption that all filters of the same precedence be applied simultaneously. Whilst convenient from a modeling point-of-view, this may or may not be how the classifier is actually implemented - this assumption is not intended to dictate how the implementation actually handles this, merely to clearly define the required end result.
该分类器操作模型假设同时应用具有相同优先级的所有过滤器。虽然从建模的角度来看很方便，但这可能是也可能不是分类器的实际实现方式-此假设并不旨在说明实现如何实际处理此问题，只是为了明确定义所需的最终结果。
The simplest Diffserv classifier is a behavior aggregate (BA) classifier [DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a packet's IP header to determine the logical output stream to which the packet should be directed. We allow only an exact-match condition on this field because the assigned DSCP values have no structure, and therefore no subset of DSCP bits are significant.
最简单的区分服务分类器是行为聚合（BA）分类器[DSARCH]。BA分类器仅使用数据包IP报头中的Diffserv码点（DSCP）来确定数据包应定向到的逻辑输出流。我们只允许该字段上的精确匹配条件，因为指定的DSCP值没有结构，因此DSCP位的子集不重要。
The following defines a possible BA filter:
以下定义了一个可能的BA筛选器：
Filter8: Type: BA Value: 111000
过滤器8:类型：BA值：111000
Another type of classifier is a multi-field (MF) classifier [DSARCH]. This classifies packets based on one or more fields in the packet (possibly including the DSCP). A common type of MF classifier is a 6-tuple classifier that classifies based on six fields from the IP and TCP or UDP headers (destination address, source address, IP protocol, source port, destination port, and DSCP). MF classifiers may classify on other fields such as MAC addresses, VLAN tags, link-layer traffic class fields, or other higher-layer protocol fields.
另一种类型的分类器是多字段（MF）分类器[DSARCH]。这基于数据包中的一个或多个字段（可能包括DSCP）对数据包进行分类。MF分类器的一种常见类型是6元组分类器，它基于来自IP和TCP或UDP头的六个字段（目标地址、源地址、IP协议、源端口、目标端口和DSCP）进行分类。MF分类器可以在其他字段上进行分类，例如MAC地址、VLAN标记、链路层流量类别字段或其他更高层协议字段。
The following defines a possible MF filter:
以下定义了可能的MF过滤器：
Filter9: Type: IPv4-6-tuple IPv4DestAddrValue: 0.0.0.0 IPv4DestAddrMask: 0.0.0.0 IPv4SrcAddrValue: 172.31.8.0 IPv4SrcAddrMask: 255.255.255.0 IPv4DSCP: 28 IPv4Protocol: 6 IPv4DestL4PortMin: 0 IPv4DestL4PortMax: 65535 IPv4SrcL4PortMin: 20 IPv4SrcL4PortMax: 20
筛选器9:类型：IPv4-6元组IPv4DestAddrValue:0.0.0 IPv4DestAddrMask:0.0.0 IPv4SrcAddrValue:172.31.8.0 IPv4SrcAddrMask:255.255.0 IPv4DSCP:28 IPv4协议：6 IPv4DestL4PortMin:0 IPv4DestL4PortMax:65535 IPv4SrcL4PortMin:20 IPv4SrcL4PortMax:20
A similar type of classifier can be defined for IPv6.
可以为IPv6定义类似类型的分类器。
A Free-form classifier is made up of a set of user definable arbitrary filters each made up of {bit-field size, offset (from head of packet), mask}:
自由形式分类器由一组用户可定义的任意过滤器组成，每个过滤器由{位字段大小、偏移量（从数据包头部）、掩码}组成：
Classifier2: Filter12: OutputA Filter13: OutputB Default: OutputC
Classifier2:Filter12:OutputA Filter13:OutputB默认值：OutputUTC
Filter12: Type: FreeForm SizeBits: 3 (bits) Offset: 16 (bytes) Value: 100 (binary) Mask: 101 (binary)
Filter12:Type:FreeForm SizeBits:3（位）偏移量：16（字节）值：100（二进制）掩码：101（二进制）
Filter13: Type: FreeForm SizeBits: 12 (bits) Offset: 16 (bytes) Value: 100100000000 (binary) Mask: 111111111111 (binary)
Filter13:Type:FreeForm SizeBits:12（位）偏移量：16（字节）值：100100000000（二进制）掩码：111111（二进制）
Free-form filters can be combined into filter groups to form very powerful filters.
自由形式的过滤器可以组合成过滤器组，以形成非常强大的过滤器。
Classification may also be performed based on information at the datalink layer below IP (e.g., VLAN or datalink-layer priority) or perhaps on the ingress or egress IP, logical or physical interface identifier (e.g., the incoming channel number on a channelized interface). A classifier that filters based on IEEE 802.1p Priority and on 802.1Q VLAN-ID might be represented as:
分类还可以基于IP之下的数据链路层的信息（例如，VLAN或数据链路层优先级）或者可能基于入口或出口IP、逻辑或物理接口标识符（例如，信道化接口上的输入信道号）来执行。基于IEEE 802.1p优先级和802.1Q VLAN-ID进行过滤的分类器可以表示为：
Classifier3: Filter14 AND Filter15: OutputA Default: OutputB
分类器3:Filter14和Filter15:OutputA默认值：OutputB
Filter14: -- priority 4 or 5 Type: Ieee8021pPriority Value: 100 (binary) Mask: 110 (binary)
过滤器14:--优先级4或5类型：IEEE8021PPRITY值：100（二进制）掩码：110（二进制）
Filter15: -- VLAN 2304 Type: Ieee8021QVlan Value: 100100000000 (binary) Mask: 111111111111 (binary)
过滤器15:--VLAN 2304类型：Ieee8021QVlan值：100100000000（二进制）掩码：111111111（二进制）
Such classifiers may be the subject of other standards or may be proprietary to a router vendor but they are not discussed further here.
此类分类器可能是其他标准的主题，也可能是路由器供应商的专有产品，但此处不作进一步讨论。
Metering is defined in [DSARCH]. Diffserv network providers may choose to offer services to customers based on a temporal (i.e., rate) profile within which the customer submits traffic for the service. In this event, a meter might be used to trigger real-time traffic conditioning actions (e.g., marking) by routing a non-conforming packet through an appropriate next-stage action element. Alternatively, by counting conforming and/or non-conforming traffic using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management functions such as billing applications.
计量在[DSARCH]中定义。Diffserv网络提供商可以根据客户提交服务流量的时间（即速率）配置文件选择向客户提供服务。在这种情况下，仪表可用于通过适当的下一阶段动作元件路由不合格数据包，从而触发实时流量调节动作（例如，标记）。或者，通过使用电表下游的计数器元件对符合和/或不符合要求的流量进行计数，它也可用于帮助为带外管理功能（如计费应用程序）收集数据。
Meters are logically 1:N (fan-out) devices (although a multiplexor can be used in front of a meter). Meters are parameterized by a temporal profile and by conformance levels, each of which is associated with a meter's output. Each output can be connected to another functional element.
仪表在逻辑上是1:N（扇出）设备（尽管可以在仪表前面使用多路复用器）。仪表通过时间剖面和一致性级别进行参数化，每个一致性级别都与仪表的输出相关联。每个输出都可以连接到另一个功能元件。
Note that this model of a meter differs slightly from that described in [DSARCH]. In that description the meter is not a datapath element but is instead used to monitor the traffic stream and send control signals to action elements to dynamically modulate their behavior based on the conformance of the packet. This difference in the description does not change the function of a meter. Figure 4 illustrates a meter with 3 levels of conformance.
请注意，此型号的仪表与[DSARCH]中描述的仪表略有不同。在该描述中，仪表不是数据路径元素，而是用于监控业务流，并向动作元素发送控制信号，以基于数据包的一致性动态调节其行为。描述中的这种差异不会改变仪表的功能。图4显示了具有3个一致性级别的仪表。
In some Diffserv examples (e.g., [AF-PHB]), three levels of conformance are discussed in terms of colors, with green representing conforming, yellow representing partially conforming and red representing non-conforming. These different conformance levels may be used to trigger different queuing, marking or dropping treatment later on in the processing. Other example meters use a binary notion of conformance; in the general case N levels of conformance can be supported. In general there is no constraint on the type of functional datapath element following a meter output, but care must be taken not to inadvertently configure a datapath that results in packet reordering that is not consistent with the requirements of the relevant PHB specification.
在一些区分服务示例（例如[AF-PHB]）中，根据颜色讨论了三个一致性级别，绿色表示一致性，黄色表示部分一致性，红色表示不一致性。这些不同的一致性级别可用于在处理过程中触发不同的排队、标记或丢弃处理。其他示例仪表使用一致性的二元概念；在一般情况下，可以支持N个级别的一致性。通常情况下，仪表输出后的功能数据路径元素的类型没有限制，但必须注意不要无意中配置导致数据包重新排序的数据路径，该数据路径与相关PHB规范的要求不一致。
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
图4。通用仪表
A meter, according to this model, measures the rate at which packets making up a stream of traffic pass it, compares the rate to some set of thresholds, and produces some number of potential results (two or more): a given packet is said to be "conformant" to a level of the meter if, at the time that the packet is being examined, the stream appears to be within the rate limit for the profile associated with that level. A fuller discussion of conformance to meter profiles (and the associated requirements that this places on the schedulers upstream) is provided in Appendix A.
根据此模型，仪表测量组成流量流的数据包通过它的速率，将速率与某一组阈值进行比较，并产生一些潜在结果（两个或更多）：如果在检查数据包时，给定数据包被称为与仪表的某个级别“一致”，则称其为“一致”，流似乎在与该级别关联的配置文件的速率限制内。附录A中提供了仪表配置文件合规性的更全面讨论（以及这对上游调度员提出的相关要求）。
The following are some examples of possible meters.
以下是一些可能的仪表示例。
An example of a very simple meter is an average rate meter. This type of meter measures the average rate at which packets are submitted to it over a specified averaging time.
一个非常简单的仪表示例是平均速率仪表。这种类型的仪表测量在指定的平均时间内向其提交数据包的平均速率。
An average rate profile may take the following form:
平均费率配置文件可采用以下形式：
Meter1: Type: AverageRate Profile: Profile1 ConformingOutput: Queue1 NonConformingOutput: Counter1
Meter1:类型：AverageRate配置文件：配置文件1符合输出：队列1不符合输出：计数器1
Profile1: Type: AverageRate AverageRate: 120 kbps Delta: 100 msec
配置文件1:类型：平均值平均值：120 kbps增量：100毫秒
A Meter measuring against this profile would continually maintain a count that indicates the total number and/or cumulative byte-count of packets arriving between time T (now) and time T - 100 msecs. So long as an arriving packet does not push the count over 12 kbits in the last 100 msec, the packet would be deemed conforming. Any packet
根据此配置文件测量的仪表将持续保持一个计数，该计数指示在时间T（现在）和时间T-100毫秒之间到达的数据包的总数和/或累积字节计数。只要到达的数据包在最后100毫秒内未将计数推到12 kbits以上，则该数据包将被视为符合要求。任何包
that pushes the count over 12 kbits would be deemed non-conforming. Thus, this Meter deems packets to correspond to one of two conformance levels: conforming or non-conforming, and sends them on for the appropriate subsequent treatment.
将计数推到12 kbit以上将被视为不合格。因此，该仪表认为数据包对应于两个一致性级别中的一个：一致性或不一致性，并将其发送给适当的后续处理。
The EWMA form of Meter is easy to implement in hardware and can be parameterized as follows:
EWMA形式的仪表易于在硬件中实现，并可按如下方式进行参数化：
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t = t' + Delta
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t = t' + Delta
For a packet arriving at time t:
对于在时间t到达的数据包：
if (avg_rate(t) > AverageRate) non-conforming else conforming
如果（平均速率（t）>平均值）不合格，则为合格
"Gain" controls the time constant (e.g., frequency response) of what is essentially a simple IIR low-pass filter. "Rate(t)" measures the number of incoming bytes in a small fixed sampling interval, Delta. Any packet that arrives and pushes the average rate over a predefined rate AverageRate is deemed non-conforming. An EWMA Meter profile might look something like the following:
“增益”控制基本上是简单IIR低通滤波器的时间常数（例如频率响应）。“速率（t）”测量在小的固定采样间隔Delta中传入的字节数。任何到达并将平均速率推送到预定义速率平均器上的数据包都被视为不合格。EWMA仪表配置文件可能如下所示：
Meter2: Type: ExpWeightedMovingAvg Profile: Profile2 ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Meter2:类型：ExpWeightedMovingAvg配置文件：配置文件2符合输出：队列1不符合输出：绝对滴管1
Profile2: Type: ExpWeightedMovingAvg AverageRate: 25 kbps Delta: 10 usec Gain: 1/16
配置文件2：类型：ExpWeightedMovingAvg平均速率：25 kbps增量：10 usec增益：1/16
A more sophisticated Meter might measure conformance to a token bucket (TB) profile. A TB profile generally has two parameters, an average token rate, R, and a burst size, B. TB Meters compare the arrival rate of packets to the average rate specified by the TB profile. Logically, tokens accumulate in a bucket at the average
一个更复杂的测量仪可以测量与令牌桶（TB）配置文件的一致性。TB配置文件通常有两个参数，平均令牌速率R和突发大小B。TB仪表将数据包的到达速率与TB配置文件指定的平均速率进行比较。从逻辑上讲，代币平均累积在一个桶中
rate, R, up to a maximum credit which is the burst size, B. When a packet of length L arrives, a conformance test is applied. There are at least two such tests in widespread use:
速率R，最大信用度为突发大小B。当长度为L的数据包到达时，应用一致性测试。至少有两种此类测试被广泛使用：
Strict conformance Packets of length L bytes are considered conforming only if there are sufficient tokens available in the bucket at the time of packet arrival for the complete packet (i.e., the current depth is greater than or equal to L): no tokens may be borrowed from future token allocations. For examples of this approach, see [SRTCM] and [TRTCM].
只有当数据包到达完整数据包时（即，当前深度大于或等于L），桶中有足够的令牌可用时，长度为L字节的严格一致性数据包才被认为是一致的：不能从未来的令牌分配中借用令牌。有关此方法的示例，请参见[SRTCM]和[TRTCM]。
Loose conformance Packets of length L bytes are considered conforming if any tokens are available in the bucket at the time of packet arrival: up to L bytes may then be borrowed from future token allocations.
如果在数据包到达时bucket中有任何令牌可用，则长度为L字节的松散一致性数据包被视为一致性数据包：随后可从未来的令牌分配中借用多达L字节的令牌。
Packets are allowed to exceed the average rate in bursts up to the burst size. For further discussion of loose and strict conformance to token bucket profiles, as well as system and implementation issues, see Appendix A.
允许数据包在突发中超过平均速率，直到突发大小。有关令牌桶配置文件的松散和严格一致性以及系统和实现问题的进一步讨论，请参阅附录A。
A two-parameter TB meter has exactly two possible conformance levels (conforming, non-conforming). Such a meter might appear as follows:
双参数TB计有两个可能的一致性级别（一致性、不一致性）。此类仪表可能显示如下：
Meter3: Type: SimpleTokenBucket Profile: Profile3 ConformanceType: loose ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Meter3:类型：SimpleTokenBucket配置文件：配置文件3一致性类型：松散一致性输出：队列1不一致性输出：绝对滴管1
Profile3: Type: SimpleTokenBucket AverageRate: 200 kbps BurstSize: 100 kbytes
Profile3:类型：SimpleTokenBucket平均值：200 kbps突发大小：100 kbytes
More complicated TB meters might define multiple burst sizes and more conformance levels. Packets found to exceed the larger burst size are deemed non-conforming. Packets found to exceed the smaller burst size are deemed partially-conforming. Packets exceeding neither are deemed conforming. Some token bucket meters designed for Diffserv networks are described in more detail in [SRTCM, TRTCM]; in some of these references, three levels of conformance are discussed in terms of colors with green representing conforming, yellow representing partially conforming, and red representing non-conforming. Note that
更复杂的TB表可能定义多个突发大小和更多的一致性级别。发现超过较大突发大小的数据包被视为不合格。超过较小突发大小的数据包被视为部分符合要求。超过两者的数据包视为合格。[SRTCM，TRTCM]中详细描述了一些为Diffserv网络设计的令牌桶表；在其中一些参考文献中，根据颜色讨论了三个一致性级别，绿色表示一致性，黄色表示部分一致性，红色表示不一致性。注意
these multiple-conformance-level meters can sometimes be implemented using an appropriate sequence of multiple two-parameter TB meters.
这些多个一致性级别仪表有时可以使用多个双参数TB仪表的适当序列来实现。
A profile for a multi-stage TB meter with three levels of conformance might look as follows:
具有三个一致性级别的多级TB计的配置文件可能如下所示：
Meter4: Type: TwoRateTokenBucket ProfileA: Profile4 ConformanceTypeA: strict ConformingOutputA: Queue1
Meter4:类型：TwoRateTokenBucket配置文件A:配置文件4一致性类型A:严格一致性输出PUTA:队列1
ProfileB: Profile5 ConformanceTypeB: strict ConformingOutputB: Marker1 NonConformingOutput: AbsoluteDropper1
档案B：档案5符合类型B：严格符合输出B:Marker1不符合输出：绝对滴管1
Profile4: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 20 kbytes
Profile4:类型：SimpleTokenBucket平均值：100 kbps突发大小：20 kbytes
Profile5: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 100 kbytes
Profile5:类型：SimpleTokenBucket平均值：100 kbps突发大小：100 kbytes
A null meter has only one output: always conforming, and no associated temporal profile. Such a meter is useful to define in the event that the configuration or management interface does not have the flexibility to omit a meter in a datapath segment.
空表只有一个输出：始终一致，并且没有相关的时间剖面。如果配置或管理接口不能灵活地省略数据路径段中的仪表，则此类仪表可用于定义。
Meter5: Type: NullMeter Output: Queue1
Meter5:类型：NullMeter输出：Queue1
The classifiers and meters described up to this point are fan-out elements which are generally used to determine the appropriate action to apply to a packet. The set of possible actions that can then be applied include:
到目前为止描述的分类器和仪表是扇出元素，通常用于确定应用于数据包的适当操作。然后可以应用的一组可能操作包括：
- Marking
- 标记
- Absolute Dropping
- 绝对下降
- Multiplexing
- 多路复用
- Counting
- 计数
- Null action - do nothing
- 空操作-不执行任何操作
The corresponding action elements are described in the following sections.
以下各节介绍了相应的动作元素。
DSCP Markers are 1:1 elements which set a codepoint (e.g., the DSCP in an IP header). DSCP Markers may also act on unmarked packets (e.g., those submitted with DSCP of zero) or may re-mark previously marked packets. In particular, the model supports the application of marking based on a preceding classifier match. The mark set in a packet will determine its subsequent PHB treatment in downstream nodes of a network and possibly also in subsequent processing stages within this router.
DSCP标记是设置码点的1:1元素（例如，IP报头中的DSCP）。DSCP标记还可以作用于未标记的数据包（例如，使用零DSCP提交的数据包），或者可以重新标记先前标记的数据包。特别是，该模型支持基于先前分类器匹配的标记应用。分组中设置的标记将确定其在网络的下游节点中的后续PHB处理，并且可能也在该路由器内的后续处理阶段中。
DSCP Markers for Diffserv are normally parameterized by a single parameter: the 6-bit DSCP to be marked in the packet header.
Diffserv的DSCP标记通常由一个参数参数化：要在数据包头中标记的6位DSCP。
Marker1: Type: DSCPMarker Mark: 010010
标记1：类型：DSCPMarker标记：010010
Absolute Droppers simply discard packets. There are no parameters for these droppers. Because this Absolute Dropper is a terminating point of the datapath and has no outputs, it is probably desirable to forward the packet through a Counter Action first for instrumentation purposes.
绝对滴管只是丢弃数据包。这些滴管没有参数。由于该绝对滴管是数据路径的终止点，并且没有输出，因此可能需要首先通过反操作转发数据包，以便进行检测。
AbsoluteDropper1: Type: AbsoluteDropper
绝对滴管1:类型：绝对滴管
Absolute Droppers are not the only elements than can cause a packet to be discarded: another element is an Algorithmic Dropper element (see Section 7.1.3). However, since this element's behavior is closely tied the state of one or more queues, we choose to distinguish it as a separate functional datapath element.
绝对滴管不是导致数据包被丢弃的唯一元素：另一个元素是算法滴管元素（见第7.1.3节）。但是，由于该元素的行为与一个或多个队列的状态密切相关，因此我们选择将其区分为单独的功能性datapath元素。
It is occasionally necessary to multiplex traffic streams into a functional datapath element with a single input. A M:1 (fan-in) multiplexor is a simple logical device for merging traffic streams. It is parameterized by its number of incoming ports.
有时需要使用单个输入将业务流多路复用到功能数据路径元素中。M:1（扇入）多路复用器是用于合并业务流的简单逻辑设备。它由其传入端口数参数化。
Mux1: Type: Multiplexor Output: Queue2
Mux1:类型：多路复用器输出：队列2
One passive action is to account for the fact that a data packet was processed. The statistics that result might be used later for customer billing, service verification or network engineering purposes. Counters are 1:1 functional datapath elements which update a counter by L and a packet counter by 1 every time a L-byte sized packet passes through them. Counters can be used to count packets about to be dropped by an Absolute Dropper or to count packets arriving at or departing from some other functional element.
一个被动动作是解释数据包被处理的事实。该结果的统计数据可能稍后用于客户计费、服务验证或网络工程目的。计数器是1:1的功能数据路径元素，每当L字节大小的数据包通过计数器时，计数器和数据包计数器分别更新1和1。计数器可用于计算绝对滴管即将丢弃的数据包，或计算到达或离开某个其他功能元件的数据包。
Counter1: Type: Counter Output: Queue1
计数器1:类型：计数器输出：队列1
A null action has one input and one output. The element performs no action on the packet. Such an element is useful to define in the event that the configuration or management interface does not have the flexibility to omit an action element in a datapath segment.
空操作有一个输入和一个输出。元素对数据包不执行任何操作。在配置或管理接口不能灵活地省略数据路径段中的操作元素的情况下，定义这样的元素非常有用。
Null1: Type: Null Output: Queue1
Null1:类型：Null输出：Queue1
Queuing elements modulate the transmission of packets belonging to the different traffic streams and determine their ordering, possibly storing them temporarily or discarding them. Packets are usually stored either because there is a resource constraint (e.g., available bandwidth) which prevents immediate forwarding, or because the queuing block is being used to alter the temporal properties of a traffic stream (i.e., shaping). Packets are discarded for one of the following reasons:
排队元件调制属于不同业务流的数据包的传输并确定其顺序，可能暂时存储它们或丢弃它们。数据包通常被存储，这是因为存在阻止立即转发的资源约束（例如，可用带宽），或者因为队列块被用来改变业务流的时间属性（例如，整形）。由于以下原因之一，数据包被丢弃：
- because of buffering limitations. - because a buffer threshold is exceeded (including when shaping is performed). - as a feedback control signal to reactive control protocols such as TCP. - because a meter exceeds a configured profile (i.e., policing).
- 因为缓冲限制因为超过了缓冲区阈值（包括执行成形时）。-作为反馈控制信号发送到反应控制协议，如TCP。-因为仪表超过了配置的配置文件（即，监控）。
The queuing elements in this model represent a logical abstraction of a queuing system which is used to configure PHB-related parameters. The model can be used to represent a broad variety of possible implementations. However, it need not necessarily map one-to-one with physical queuing systems in a specific router implementation. Implementors should map the configurable parameters of the implementation's queuing systems to these queuing element parameters as appropriate to achieve equivalent behaviors.
该模型中的排队元素表示用于配置PHB相关参数的排队系统的逻辑抽象。该模型可用于表示各种可能的实现。然而，在特定的路由器实现中，它不必与物理排队系统一一对应。实现者应该将实现的队列系统的可配置参数映射到这些队列元素参数，以实现等效的行为。
Queuing is a function which lends itself to innovation. It must be modeled to allow a broad range of possible implementations to be represented using common structures and parameters. This model uses functional decomposition as a tool to permit the needed latitude.
排队是一种有助于创新的功能。必须对其进行建模，以允许使用公共结构和参数来表示广泛的可能实现。该模型使用功能分解作为工具来允许所需的范围。
Queuing systems perform three distinct, but related, functions: they store packets, they modulate the departure of packets belonging to various traffic streams and they selectively discard packets. This model decomposes queuing into the component elements that perform each of these functions: Queues, Schedulers, and Algorithmic Droppers, respectively. These elements may be connected together as part of a TCB, as described in section 8.
排队系统执行三种不同但相关的功能：它们存储数据包，调节属于各种业务流的数据包的离开，并有选择地丢弃数据包。该模型将队列分解为执行每个功能的组件元素：队列、调度器和算法滴管。如第8节所述，这些元件可作为TCB的一部分连接在一起。
The remainder of this section discusses FIFO Queues: typically, the Queue element of this model will be implemented as a FIFO data structure. However, this does not preclude implementations which are not strictly FIFO, in that they also support operations that remove or examine packets (e.g., for use by discarders) other than at the head or tail. However, such operations must not have the effect of reordering packets belonging to the same microflow.
本节的其余部分将讨论FIFO队列：通常，此模型的队列元素将作为FIFO数据结构实现。然而，这并不排除非严格FIFO的实现，因为它们还支持除去或检查数据包（例如，供丢弃者使用）的操作，而不是在头部或尾部。但是，此类操作不得具有对属于同一微流的数据包重新排序的效果。
Note that the term FIFO has multiple different common usages: it is sometimes taken to mean, among other things, a data structure that permits items to be removed only in the order in which they were inserted or a service discipline which is non-reordering.
请注意，FIFO一词有多种不同的常用用法：它有时被认为是指仅允许按插入顺序删除项目的数据结构，或者是指不重新排序的服务规程。
In this model, a FIFO Queue element is a data structure which at any time may contain zero or more packets. It may have one or more thresholds associated with it. A FIFO has one or more inputs and exactly one output. It must support an enqueue operation to add a packet to the tail of the queue and a dequeue operation to remove a packet from the head of the queue. Packets must be dequeued in the order in which they were enqueued. A FIFO has a current depth, which indicates the number of packets and/or bytes that it contains at a particular time. FIFOs in this model are modeled without inherent limits on their depth - obviously this does not reflect the reality of implementations: FIFO size limits are modeled here by an algorithmic dropper associated with the FIFO, typically at its input. It is quite likely that every FIFO will be preceded by an algorithmic dropper. One exception might be the case where the packet stream has already been policed to a profile that can never exceed the scheduler bandwidth available at the FIFO's output - this would not need an algorithmic dropper at the input to the FIFO.
在该模型中，FIFO队列元素是一种数据结构，在任何时候都可能包含零个或多个数据包。它可能有一个或多个与之关联的阈值。FIFO有一个或多个输入，只有一个输出。它必须支持将数据包添加到队列尾部的排队操作和从队列头部移除数据包的出列操作。数据包必须按照其排队顺序排队。FIFO有一个当前深度，它指示在特定时间包含的数据包和/或字节数。此模型中的FIFO建模时没有其深度的固有限制-显然，这并不反映实现的现实：FIFO大小限制在这里由与FIFO相关的算法滴管建模，通常在其输入端。很可能每个FIFO之前都会有一个算法滴管。一种例外情况可能是，数据包流已经被监控到一个配置文件，该配置文件永远不能超过FIFO输出端可用的调度程序带宽——这将不需要FIFO输入端的算法滴管。
This representation of a FIFO allows for one common type of depth limit, one that results from a FIFO supplied from a limited pool of buffers, shared between multiple FIFOs.
FIFO的这种表示允许一种常见类型的深度限制，一种是由有限的缓冲池提供的FIFO产生的，在多个FIFO之间共享。
In an implementation, packets are presumably stored in one or more buffers. Buffers are allocated from one or more free buffer pools. If there are multiple instances of a FIFO, their packet buffers may or may not be allocated out of the same free buffer pool. Free buffer pools may also have one or more thresholds associated with them, which may affect discarding and/or scheduling. Other than this, buffering mechanisms are implementation specific and not part of this model.
在一个实现中，数据包可能存储在一个或多个缓冲区中。缓冲区是从一个或多个空闲缓冲池分配的。如果一个FIFO有多个实例，则它们的数据包缓冲区可以从同一个空闲缓冲池中分配，也可以不从同一个空闲缓冲池中分配。空闲缓冲池还可能有一个或多个与之关联的阈值，这可能会影响丢弃和/或调度。除此之外，缓冲机制是特定于实现的，不是此模型的一部分。
A FIFO might be represented using the following parameters:
FIFO可以使用以下参数表示：
Queue1: Type: FIFO Output: Scheduler1
队列1:类型：FIFO输出：Scheduler1
Note that a FIFO must provide triggers and/or current state information to other elements upstream and downstream from it: in particular, it is likely that the current depth will need to be used by Algorithmic Dropper elements placed before or after the FIFO. It will also likely need to provide an implicit "I have packets for you" signal to downstream Scheduler elements.
请注意，FIFO必须向其上游和下游的其他元件提供触发器和/或当前状态信息：特别是，FIFO前后的算法滴管元件可能需要使用当前深度。它还可能需要向下游调度器元素提供一个隐式的“我有数据包给你”信号。
A scheduler is an element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline. It has one or more inputs and exactly one output. Each input has an upstream element to which it is connected, and a set of parameters that affects the scheduling of packets received at that input.
调度器是一个元素，它根据服务规程对到达其输入端的每个数据包的离开进行控制。它有一个或多个输入，只有一个输出。每个输入都有一个与其连接的上游元素，以及一组影响在该输入处接收的数据包的调度的参数。
The service discipline (also known as a scheduling algorithm) is an algorithm which might take any of the following as its input(s):
服务规程（也称为调度算法）是一种算法，可将以下任一项作为其输入：
a) static parameters such as relative priority associated with each of the scheduler's inputs.
a) 静态参数，例如与每个调度程序输入关联的相对优先级。
b) absolute token bucket parameters for maximum or minimum rates associated with each of the scheduler's inputs.
b) 与每个调度器输入相关联的最大或最小速率的绝对令牌桶参数。
c) parameters, such as packet length or DSCP, associated with the packet currently present at its input.
c) 与当前存在于其输入端的数据包相关联的参数，如数据包长度或DSCP。
d) absolute time and/or local state.
d) 绝对时间和/或本地状态。
Possible service disciplines fall into a number of categories, including (but not limited to) first come, first served (FCFS), strict priority, weighted fair bandwidth sharing (e.g., WFQ), rate-limited strict priority, and rate-based. Service disciplines can be further distinguished by whether they are work-conserving or non-work-conserving (see Glossary). Non-work-conserving schedulers can be used to shape traffic streams to match some profile by delaying packets that might be deemed non-conforming by some downstream node: a packet is delayed until such time as it would conform to a downstream meter using the same profile.
可能的服务规程可分为若干类别，包括（但不限于）先到先得（FCFS）、严格优先级、加权公平带宽共享（如WFQ）、速率限制严格优先级和基于速率的。服务规程可以通过工作节约还是非工作节约来进一步区分（参见术语表）。通过延迟可能被某个下游节点视为不一致的数据包，非保功调度器可用于塑造流量流以匹配某个配置文件：数据包被延迟，直到它符合使用相同配置文件的下游仪表为止。
[DSARCH] defines PHBs without specifying required scheduling algorithms. However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF [AF-PHB] have descriptions or configuration parameters which strongly suggest the sort of scheduling discipline needed to implement them. This document discusses a minimal set of queue parameters to enable realization of these PHBs. It does not attempt to specify an all-embracing set of parameters to cover all possible implementation models. A minimal set includes:
[DSARCH]定义PHB而不指定所需的调度算法。然而，诸如类选择器[DSFIELD]、EF[EF-PHB]和AF[AF-PHB]等PHB具有描述或配置参数，这些描述或配置参数强烈建议了实现它们所需的调度规程。本文档讨论了一组最小的队列参数，以实现这些PHB。它并不试图指定一组包罗万象的参数来涵盖所有可能的实现模型。最小集合包括：
a) a minimum service rate profile which allows rate guarantees for each traffic stream as required by EF and AF without specifying the details of how excess bandwidth between these traffic streams is shared. Additional parameters to control this behavior should be made available, but are dependent on the particular scheduling algorithm implemented.
a) 最小服务速率配置文件，允许按照EF和AF的要求为每个业务流提供速率保证，而无需指定这些业务流之间如何共享多余带宽的详细信息。控制此行为的其他参数应可用，但取决于所实现的特定调度算法。
b) a service priority, used only after the minimum rate profiles of all inputs have been satisfied, to decide how to allocate any remaining bandwidth.
b) 服务优先级，仅在满足所有输入的最低速率配置文件后使用，用于决定如何分配任何剩余带宽。
c) a maximum service rate profile, for use only with a non-work-conserving service discipline.
c) 最大服务费率配置文件，仅用于非工作节约服务规程。
Any one of these profiles is composed, for the purposes of this model, of both a rate (in suitable units of bits, bytes or larger chunks in some unit of time) and a burst size, as discussed further in Appendix A.
出于本模型的目的，这些配置文件中的任何一个都由速率（在某个时间单位中以合适的比特、字节或更大的块为单位）和突发大小组成，如附录a中进一步讨论的。
By way of example, for an implementation of the EF PHB using a strict priority scheduling algorithm that assumes that the aggregate EF rate has been appropriately bounded by upstream policing to avoid starvation of other BAs, the service rate profiles are not used: the minimum service rate profile would be defaulted to zero and the maximum service rate profile would effectively be the "line rate". Such an implementation, with multiple priority classes, could also be used for the Diffserv class selectors [DSFIELD].
举例来说，对于使用严格优先级调度算法的EF PHB的实现，该算法假设聚合EF速率已被上游策略适当地限定以避免其他ba的饥饿，不使用服务费率配置文件：最低服务费率配置文件默认为零，最高服务费率配置文件实际上是“线路费率”。这种具有多个优先级类的实现也可用于Diffserv类选择器[DSFIELD]。
Alternatively, setting the service priority values for each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rates for each input, so long as the sum of all minimum service rates is less than or equal to the line rate.
或者，将调度器的每个输入的服务优先级值设置为相同的值，使得调度器能够满足每个输入的最小服务速率，只要所有最小服务速率之和小于或等于线路速率。
For example, a non-work-conserving scheduler, allocating spare bandwidth equally between all its inputs, might be represented using the following parameters:
例如，可以使用以下参数表示在其所有输入之间平均分配备用带宽的非工作节省调度程序：
Scheduler1: Type: Scheduler2Input
Scheduler1:类型：Scheduler2输入
Input1: MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: none
Input1:MaxRateProfile:Profile1 MinRateProfile:Profile2优先级：无
Input2: MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: none
Input2:MaxRateProfile:Profile3 MinRateProfile:Profile4优先级：无
A work-conserving scheduler might be represented using the following parameters:
可以使用以下参数表示节省工时的计划程序：
Scheduler2: Type: Scheduler3Input Input1: MaxRateProfile: WorkConserving MinRateProfile: Profile5 Priority: 1
Scheduler2:类型：Scheduler3输入输入1:MaxRateProfile:工作保护MinRateProfile:Profile5优先级：1
Input2: MaxRateProfile: WorkConserving MinRateProfile: Profile6 Priority: 2
输入2:MaxRateProfile:WorkConserving MinRateProfile:Profile6优先级：2
Input3: MaxRateProfile: WorkConserving MinRateProfile: none Priority: 3
输入3:MaxRateProfile:工作保存MinRateProfile:无优先级：3
An Algorithmic Dropper is an element which selectively discards packets that arrive at its input, based on a discarding algorithm. It has one data input and one output. In this model (but not necessarily in a real implementation), a packet enters the dropper at its input and either its buffer is returned to a free buffer pool or the packet exits the dropper at the output.
算法滴管是基于丢弃算法选择性丢弃到达其输入端的数据包的元件。它有一个数据输入和一个输出。在这个模型中（但不一定在实际实现中），数据包在其输入端进入滴管，其缓冲区返回到空闲缓冲池，或者数据包在输出端退出滴管。
Alternatively, an Algorithmic Dropper can be thought of as invoking operations on a FIFO Queue which selectively remove a packet and return its buffer to the free buffer pool based on a discarding algorithm. In this case, the operation could be modeled as being a side-effect on the FIFO upon which it operated, rather than as having a discrete input and output. This treatment is equivalent and we choose the one described in the previous paragraph for this model.
或者，可以将算法丢弃器视为调用FIFO队列上的操作，该操作基于丢弃算法选择性地移除数据包并将其缓冲区返回到空闲缓冲池。在这种情况下，可以将操作建模为对其操作的FIFO的副作用，而不是具有离散的输入和输出。这种处理方法是等效的，我们为该模型选择上一段中描述的方法。
One of the primary characteristics of an Algorithmic Dropper is the choice of which packet (if any) is to be dropped: for the purposes of this model, we restrict the packet selection choices to one of the following and we indicate the choice by the relative positions of Algorithmic Dropper and FIFO Queue elements in the model:
算法滴管的一个主要特征是选择要丢弃的数据包（如果有）：出于此模型的目的，我们将数据包选择限制为以下选择之一，并通过模型中算法滴管和FIFO队列元素的相对位置指示选择：
a) selection of a packet that is about to be added to the tail of a queue (a "Tail Dropper"): the output of the Algorithmic Dropper element is connected to the input of the relevant FIFO Queue element.
a) 选择即将添加到队列尾部的数据包（“尾部滴管”）：算法滴管元素的输出连接到相关FIFO队列元素的输入。
b) a packet that is currently at the head of a queue (a "Head Dropper"): the output of the FIFO Queue element is connected to the input of the Algorithmic Dropper element.
b) 当前位于队列头部的数据包（“头部滴管”）：FIFO队列元素的输出连接到算法滴管元素的输入。
Other packet selection methods could be added to this model in the form of a different type of datapath element.
其他数据包选择方法可以以不同类型的数据路径元素的形式添加到此模型中。
The Algorithmic Dropper is modeled as having a single input. It is possible that packets which were classified differently by a Classifier in this TCB will end up passing through the same dropper. The dropper's algorithm may need to apply different calculations based on characteristics of the incoming packet (e.g., its DSCP). So there is a need, in implementations of this model, to be able to relate information about which classifier element was matched by a packet from a Classifier to an Algorithmic Dropper. In the rare cases where this is required, the chosen model is to insert another Classifier element at this point in the flow and for it to feed into multiple Algorithmic Dropper elements, each one implementing a drop calculation that is independent of any classification keys of the packet: this will likely require the creation of a new TCB to contain the Classifier and the Algorithmic Dropper elements.
算法滴管被建模为具有单个输入。在该TCB中由分类器进行不同分类的数据包可能最终通过相同的滴管。滴管算法可能需要根据传入数据包的特征（例如，其DSCP）应用不同的计算。因此，在该模型的实现中，需要能够将关于哪个分类器元素由来自分类器的数据包匹配到算法滴管的信息关联起来。在极少数情况下需要这样做，选择的模型是在流中的这一点插入另一个分类器元素，并将其输入到多个算法滴管元素中，每一个都实现一个独立于包的任何分类键的丢弃计算：这可能需要创建一个新的TCB来包含分类器和算法丢弃元素。
NOTE: There are many other formulations of a model that could represent this linkage that are different from the one described above: one formulation would have been to have a pointer from one of the drop probability calculation algorithms inside the dropper to the original Classifier element that selects this algorithm. Another way would have been to have multiple "inputs" to the Algorithmic Dropper element fed from the preceding elements, leading eventually back to the Classifier elements that matched the packet. Yet another formulation might have been for the Classifier to (logically) include some sort of "classification identifier" along with the packet along its path, for use by any subsequent element. And yet another could have been to include a classifier inside the dropper, in order for it to pick out the drop algorithm to be applied. These other approaches could be used by implementations but were deemed to be less clear than the approach taken here.
注：模型的许多其他公式可以表示与上述公式不同的这种联系：其中一个公式应该是有一个指针，从滴管内的一个滴落概率计算算法指向选择该算法的原始分类器元素。另一种方法是将多个“输入”从前面的元素馈送到算法滴管元素，最终返回到与包匹配的分类器元素。另一个公式可能是分类器（逻辑上）包括某种“分类标识符”以及沿着其路径的分组，以供任何后续元素使用。还有一个可能是在滴管中包含一个分类器，以便它选择要应用的滴管算法。这些其他方法可以被实现使用，但被认为不如这里采用的方法清晰。
An Algorithmic Dropper, an example of which is illustrated in Figure 5, has one or more triggers that cause it to make a decision whether or not to drop one (or possibly more than one) packet. A trigger may be internal (the arrival of a packet at the input to the dropper) or it may be external (resulting from one or more state changes at another element, such as a FIFO Queue depth crossing a threshold or a scheduling event). It is likely that an instantaneous FIFO depth will need to be smoothed over some averaging interval before being used as a useful trigger. Some dropping algorithms may require several trigger inputs feeding back from events elsewhere in the system (e.g., depth-smoothing functions that calculate averages over more than one time interval).
一个算法滴管，其示例如图5所示，具有一个或多个触发器，使其决定是否丢弃一个（或可能不止一个）数据包。触发器可以是内部的（数据包到达滴管的输入端），也可以是外部的（由另一个元素的一个或多个状态变化引起，例如FIFO队列深度超过阈值或调度事件）。在将瞬时FIFO深度用作有用的触发器之前，可能需要在某个平均间隔内对其进行平滑处理。一些丢弃算法可能需要从系统中其他地方的事件反馈几个触发器输入（例如，计算一个以上时间间隔的平均值的深度平滑函数）。
+------------------+ +-----------+
| +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)|
| |calc. | | |(optional) |
| +-------+ | +-----------+
| | | ^
| v | |Depth
Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+
| +-------+ | FIFO
| |yes |
| | | | |
| | v | count + |
| +---+ bit-bucket|
+------------------+
Algorithmic
Dropper
+------------------+ +-----------+
| +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)|
| |calc. | | |(optional) |
| +-------+ | +-----------+
| | | ^
| v | |Depth
Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+
| +-------+ | FIFO
| |yes |
| | | | |
| | v | count + |
| +---+ bit-bucket|
+------------------+
Algorithmic
Dropper
Figure 5. Example of Algorithmic Dropper from Tail of a Queue
图5。队列尾部的算法滴管示例
A trigger may be a boolean combination of events (e.g., a FIFO depth exceeding a threshold OR a buffer pool depth falling below a threshold). It takes as its input some set of dynamic parameters (e.g., smoothed or instantaneous FIFO depth), and some set of static parameters (e.g., thresholds), and possibly other parameters associated with the packet. It may also have internal state (e.g., history of its past actions). Note that, although an Algorithmic Dropper may require knowledge of data fields in a packet, as discovered by a Classifier in the same TCB, it may not modify the packet (i.e., it is not a marker).
触发器可以是事件的布尔组合（例如，FIFO深度超过阈值或缓冲池深度低于阈值）。它将一些动态参数集（例如平滑或瞬时FIFO深度）和一些静态参数集（例如阈值）以及可能与数据包相关的其他参数作为输入。它还可能具有内部状态（例如，其过去动作的历史记录）。注意，尽管算法滴管可能需要由同一TCB中的分类器发现的分组中的数据字段的知识，但它可能不会修改分组（即，它不是标记）。
The result of the trigger calculation is that the dropping algorithm makes a decision on whether to forward or to discard a packet. The discarding function is likely to keep counters regarding the discarded packets (there is no appropriate place here to include a Counter Action element).
触发器计算的结果是丢弃算法决定是转发还是丢弃数据包。丢弃函数可能会保留与丢弃的数据包有关的计数器（此处没有合适的位置包含计数器操作元素）。
The example in Figure 5 also shows a FIFO Queue element from whose tail the dropping is to take place and whose depth characteristics are used by this Algorithmic Dropper. It also shows where a depth-smoothing function might be included: smoothing functions are outside the scope of this document and are not modeled explicitly here, we merely indicate where they might be added.
图5中的示例还显示了一个FIFO队列元素，其尾部将发生丢弃，其深度特性由该算法丢弃器使用。它还显示了可能包含深度平滑函数的位置：平滑函数不在本文档的范围内，并且在这里没有显式建模，我们仅指出它们可能添加到的位置。
RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of dropping algorithms. Tail-dropping and head-dropping are effected by the location of the Algorithmic Dropper element relative to the FIFO
RED、RED-on-In-and-Out（RIO）和Drop-on-threshold是丢弃算法的示例。尾部下降和头部下降受算法滴管元件相对于FIFO的位置影响
Queue element. As an example, a dropper using a RIO algorithm might be represented using 2 Algorithmic Droppers with the following parameters:
队列元素。例如，使用RIO算法的滴管可以使用具有以下参数的2个算法滴管表示：
AlgorithmicDropper1: (for in-profile traffic) Type: AlgorithmicDropper Discipline: RED Trigger: Internal Output: Fifo1 MinThresh: Fifo1.Depth > 20 kbyte MaxThresh: Fifo1.Depth > 30 kbyte SampleWeight .002 MaxDropProb 1%
AlgorithmcDropper1：（用于配置文件内流量）类型：AlgorithmcDropper规程：红色触发器：内部输出：Fifo1 MinThresh:Fifo1.深度>20kbyte最大阈值：Fifo1.深度>30kbyte样本权重.002 MaxDropProb 1%
AlgorithmicDropper2: (for out-of-profile traffic) Type: AlgorithmicDropper Discipline: RED Trigger: Internal Output: Fifo1 MinThresh: Fifo1.Depth > 10 kbyte MaxThresh: Fifo1.Depth > 20 kbyte SampleWeight .002 MaxDropProb 2%
AlgorithmicDropper2：（用于配置文件外的流量）类型：AlgorithmicDropper规程：红色触发器：内部输出：Fifo1 MinThresh:Fifo1.深度>10 kbyte最大阈值：Fifo1.深度>20 kbyte样本权重.002 MaxDropProb 2%
Another form of Algorithmic Dropper, a threshold-dropper, might be represented using the following parameters:
另一种形式的算法滴管，阈值滴管，可以使用以下参数表示：
AlgorithmicDropper3: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Fifo2.Depth > 20 kbyte Output: Fifo1
AlgorithmicDropper3:类型：AlgorithmicDropper规程：阈值触发：Fifo2。深度>20千字节输出：Fifo1
Queues are used, in Differentiated Services, for a number of purposes. In essence, they are simply places to store traffic until it is transmitted. However, when several queues are used together in a queuing system, they can also achieve effects beyond that for given traffic streams. They can be used to limit variation in delay or impose a maximum rate (shaping), to permit several streams to share a link in a semi-predictable fashion (load sharing), or to move variation in delay from some streams to other streams.
在区分服务中，队列用于多种目的。本质上，它们只是存储流量直到传输的地方。然而，当在一个排队系统中同时使用多个队列时，它们也可以实现超出给定交通流的效果。它们可用于限制延迟变化或施加最大速率（成形），允许多个流以半可预测的方式共享链路（负载共享），或将延迟变化从一些流移动到其他流。
Traffic shaping is often used to condition traffic, such that packets arriving in a burst will be "smoothed" and deemed conforming by subsequent downstream meters in this or other nodes. In [DSARCH] a shaper is described as a queuing element controlled by a meter which
流量整形通常用于调节流量，使得到达突发的数据包将被“平滑”，并被该节点或其他节点中的后续下游仪表视为符合要求。在[DSARCH]中，整形器被描述为由仪表控制的队列元素，仪表
defines its temporal profile. However, this representation of a shaper differs substantially from typical shaper implementations.
定义其时间配置文件。然而，整形器的这种表示形式与典型的整形器实现有很大的不同。
In the model described here, a shaper is realized by using a non-work-conserving Scheduler. Some implementations may elect to have queues whose sole purpose is shaping, while others may integrate the shaping function with other buffering, discarding, and scheduling associated with access to a resource. Shapers operate by delaying the departure of packets that would be deemed non-conforming by a meter configured to the shaper's maximum service rate profile. The packet is scheduled to depart no sooner than such time that it would become conforming.
在这里描述的模型中，整形器是通过使用一个不节省工作的调度器来实现的。一些实现可以选择具有其唯一目的是成形的队列，而其他实现可以将成形功能与与与资源访问相关联的其他缓冲、丢弃和调度集成。整形器通过延迟被配置为整形器最大服务速率配置文件的仪表视为不合格的数据包的离开来操作。该数据包被安排在不早于其符合要求的时间内离开。
Load sharing is the traditional use of queues and was theoretically explored by Floyd & Jacobson [FJ95], although it has been in use in communications systems since the 1970's.
负载共享是队列的传统用法，Floyd&Jacobson[FJ95]从理论上对其进行了探讨，但自20世纪70年代以来，它一直在通信系统中使用。
[DSARCH] discusses load sharing as dividing an interface among traffic classes predictably, or applying a minimum rate to each of a set of traffic classes, which might be measured as an absolute lower bound on the rate a traffic stream achieves or a fraction of the rate an interface offers. It is generally implemented as some form of weighted queuing algorithm among a set of FIFO queues i.e., a WFQ scheme. This has interesting side-effects.
[DSARCH]将负载共享讨论为可预测地在流量类之间划分接口，或对一组流量类中的每一个应用最小速率，这可能被测量为流量流达到的速率的绝对下限或接口提供的速率的一小部分。它通常被实现为一组FIFO队列中的某种形式的加权排队算法，即WFQ方案。这有有趣的副作用。
A key effect sought is to ensure that the mean rate the traffic in a stream experiences is never lower than some threshold when there is at least that much traffic to send. When there is less traffic than this, the queue tends to be starved of traffic, meaning that the queuing system will not delay its traffic by very much. When there is significantly more traffic and the queue starts filling, packets in this class will be delayed significantly more than traffic in other classes that are under-using their available capacity. This form of queuing system therefore tends to move delay and variation in delay from under-used classes of traffic to heavier users, as well as managing the rates of the traffic streams.
寻求的一个关键效果是，当至少有那么多流量要发送时，确保流中的流量所经历的平均速率永远不会低于某个阈值。当流量小于此值时，队列往往缺乏流量，这意味着排队系统不会将其流量延迟太多。当流量显著增加且队列开始填满时，此类中的数据包将比未充分利用其可用容量的其他类中的数据包延迟显著更多。因此，这种形式的排队系统倾向于将延迟和延迟变化从使用不足的交通类别转移到较重的用户，并管理交通流的速率。
A side-effect of a WRR or WFQ implementation is that between any two packets in a given traffic class, the scheduler may emit one or more packets from each of the other classes in the queuing system. In cases where average behavior is in view, this is perfectly acceptable. In cases where traffic is very intolerant of jitter and there are a number of competing classes, this may have undesirable consequences.
WRR或WFQ实现的一个副作用是，在给定业务类别中的任意两个分组之间，调度器可以从队列系统中的每个其他类别发出一个或多个分组。在考虑到平均行为的情况下，这是完全可以接受的。在流量非常不能容忍抖动的情况下，并且存在多个竞争类别，这可能会产生不良后果。
Traffic Prioritization is a special case of load sharing, wherein a certain traffic class is deemed so jitter-intolerant that if it has traffic present, that traffic must be sent at the earliest possible time. By extension, several priorities might be defined, such that traffic in each of several classes is given preferential service over any traffic of a lower class. It is the obvious implementation of IP Precedence as described in [RFC 791], of 802.1p traffic classes [802.1D], and other similar technologies.
流量优先级是负载共享的一种特殊情况，其中某个流量类别被认为是不可容忍的抖动，因此如果存在流量，则必须在尽可能早的时间发送该流量。通过扩展，可以定义多个优先级，使得多个类别中的每个类别的流量都比任何较低类别的流量得到优先服务。它是[RFC 791]中所述的IP优先级、802.1p流量类别[802.1D]和其他类似技术的明显实现。
Priority is often abused in real networks; people tend to think that traffic which has a high business priority deserves this treatment and talk more about the business imperatives than the actual application requirements. This can have severe consequences; networks have been configured which placed business-critical traffic at a higher priority than routing-protocol traffic, resulting in collapse of the network's management or control systems. However, it may have a legitimate use for services based on an Expedited Forwarding (EF) PHB, where it is absolutely sure, thanks to policing at all possible traffic entry points, that a traffic stream does not abuse its rate and that the application is indeed jitter-intolerant enough to merit this type of handling. Note that, even in cases with well-policed ingress points, there is still the possibility of unexpected traffic loops within an un-policed core part of the network causing such collapse.
在现实网络中，优先级经常被滥用；人们倾向于认为具有高业务优先级的流量应该得到这种处理，并且更多地谈论业务需求，而不是实际的应用程序需求。这可能产生严重后果；已配置的网络将关键业务流量置于比路由协议流量更高的优先级，从而导致网络管理或控制系统崩溃。然而，它可以合法地使用基于加速转发（EF）PHB的服务，在这种情况下，由于在所有可能的流量入口点进行了监控，它可以绝对肯定流量流不会滥用其速率，并且应用程序确实不能容忍抖动，值得进行这种类型的处理。请注意，即使在具有良好策略的入口点的情况下，在未策略的网络核心部分内仍有可能出现意外的流量环路，从而导致此类崩溃。
The Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler functional datapath elements described above can be combined into Traffic Conditioning Blocks (TCBs). A TCB is an abstraction of a set of functional datapath elements that may be used to facilitate the definition of specific traffic conditioning functionality (e.g., it might be likened to a template which can be replicated multiple times for different traffic streams or different customers). It has no likely physical representation in the implementation of the data path: it is invented purely as an abstraction for use by management tools.
上述分类器、计量器、动作、算法滴管、队列和调度器功能数据路径元素可以组合成流量调节块（tcb）。TCB是一组功能数据路径元素的抽象，可用于促进特定流量调节功能的定义（例如，可将其比作可针对不同流量流或不同客户多次复制的模板）。它在数据路径的实现中没有可能的物理表示：它纯粹是作为管理工具使用的抽象而发明的。
This model describes the configuration and management of a Diffserv interface in terms of a TCB that contains, by definition, zero or more Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler elements. These elements are arranged arbitrarily according to the policy being expressed, but always in the order here. Traffic may be classified; classified traffic may be metered; each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it, followed by drop
该模型根据TCB描述Diffserv接口的配置和管理，根据定义，TCB包含零个或多个分类器、仪表、操作、算法滴管、队列和调度程序元素。这些元素根据所表达的策略任意排列，但始终按此处的顺序排列。交通可分类；可对分类交通进行计量；由分类器和计量器组合识别的每个流量流可能会有一组对其执行的操作，然后是丢弃
algorithms; packets of the traffic stream may ultimately be stored into a queue and then be scheduled out to the next TCB or physical interface. It is permissible to omit elements or include null elements of any type, or to concatenate multiple functional datapath elements of the same type.
算法；业务流的分组最终可被存储到队列中，然后被调度到下一个TCB或物理接口。允许省略元素或包含任何类型的空元素，或连接相同类型的多个功能数据路径元素。
When the Diffserv treatment for a given packet needs to have such building blocks repeated, this is performed by cascading multiple TCBs: an output of one TCB may drive the input of a succeeding one. For example, consider the case where traffic of a set of classes is shaped to a set of rates, but the total output rate of the group of classes must also be limited to a rate. One might imagine a set of network news feeds, each with a certain maximum rate, and a policy that their aggregate may not exceed some figure. This may be simply accomplished by cascading two TCBs. The first classifies the traffic into its separate feeds and queues each feed separately. The feeds (or a subset of them) are now fed into a second TCB, which places all input (these news feeds) into a single queue with a certain maximum rate. In implementation, one could imagine this as the several literal queues, a CBQ or WFQ system with an appropriate (and complex) weighting scheme, or a number of other approaches. But they would have the same externally measurable effect on the traffic as if they had been literally implemented with separate TCBs.
当给定分组的Diffserv处理需要重复这样的构建块时，这是通过级联多个TCB来执行的：一个TCB的输出可以驱动后续TCB的输入。例如，考虑一组类的流量被形成为一组速率的情况，但是类组的总输出速率也必须限制在一个速率上。有人可能会设想一组网络新闻提要，每个提要都有一定的最大速率，并且它们的聚合不超过某个数字，这可以通过级联两个TCB来实现。第一种方法将流量分类为单独的提要，并分别对每个提要进行排队。提要（或其中的一个子集）现在被馈送到第二个TCB中，该TCB以一定的最大速率将所有输入（这些新闻提要）放入单个队列中。在实现中，可以将其想象为几个文本队列、具有适当（且复杂）权重方案的CBQ或WFQ系统，或许多其他方法。但是，它们将对流量产生相同的外部可测量的影响，就好像它们实际上是通过单独的TCB实现的一样。
A generalized TCB might consist of the following stages:
广义TCB可能包括以下阶段：
- Classification stage
- 分级阶段
- Metering stage
- 计量阶段
- Action stage (involving Markers, Absolute Droppers, Counters, and Multiplexors)
- 动作阶段（包括标记、绝对滴管、计数器和多路复用器）
- Queuing stage (involving Algorithmic Droppers, Queues, and Schedulers)
- 排队阶段（涉及算法滴管、队列和调度程序）
where each stage may consist of a set of parallel datapaths consisting of pipelined elements.
其中，每个阶段可能由一组由流水线元素组成的并行数据路径组成。
A Classifier or a Meter is typically a 1:N element, an Action, Algorithmic Dropper, or Queue is typically a 1:1 element and a Scheduler is a N:1 element. A complete TCB should, however, result in a 1:1 or 1:N abstract element. Note that the fan-in or fan-out of an element is not an important defining characteristic of this taxonomy.
分类器或仪表通常是1:N元素，动作、算法滴管或队列通常是1:1元素，调度程序是N:1元素。然而，一个完整的TCB应该产生一个1:1或1:N的抽象元素。请注意，元素的扇入或扇出不是此分类法的重要定义特征。
Some particular rules are applied to the ordering of elements within a Queuing stage within a TCB: elements of the same type may appear more than once, either in parallel or in series. Typically, a queuing stage will have relatively many elements in parallel and few in series. Iteration and recursion are not supported constructs (the elements are arranged in an acyclic graph). The following inter-connections of elements are allowed:
某些特定规则适用于TCB内队列阶段中元素的排序：相同类型的元素可能会出现多次，并行或串行。通常，一个排队阶段将有相对多的并行元素，而很少有串联元素。迭代和递归是不受支持的构造（元素排列在非循环图中）。允许以下元件的相互连接：
- The input of a Queue may be the input of the queuing block, or it may be connected to the output of an Algorithmic Dropper, or to an output of a Scheduler.
- 队列的输入可以是队列块的输入，也可以连接到算法滴管的输出，或者连接到调度器的输出。
- Each input of a Scheduler may be connected to the output of a Queue, to the output of an Algorithmic Dropper, or to the output of another Scheduler.
- 调度器的每个输入都可以连接到队列的输出、算法滴管的输出或另一个调度器的输出。
- The input of an Algorithmic Dropper may be the first element of the queuing stage, the output of another Algorithmic Dropper, or it may be connected to the output of a Queue (to indicate head-dropping).
- 算法滴管的输入可以是队列阶段的第一个元素，也可以是另一个算法滴管的输出，或者可以连接到队列的输出（以指示头部掉落）。
- The output of the queuing block may be the output of a Queue, an Algorithmic Dropper, or a Scheduler.
- 队列块的输出可以是队列、算法滴管或调度器的输出。
Note, in particular, that Schedulers may operate in series such so that a packet at the head of a Queue feeding the concatenated Schedulers is serviced only after all of the scheduling criteria are met. For example, a Queue which carries EF traffic streams may be served first by a non-work-conserving Scheduler to shape the stream to a maximum rate, then by a work-conserving Scheduler to mix EF traffic streams with other traffic streams. Alternatively, there might be a Queue and/or a dropper between the two Schedulers.
特别地，注意，调度器可以串联操作，使得仅在满足所有调度标准之后，才服务馈送级联调度器的队列头部的分组。例如，承载EF业务流的队列可首先由非工作节省调度器服务以将该流塑造成最大速率，然后由工作节省调度器服务以将EF业务流与其他业务流混合。或者，两个调度器之间可能有一个队列和/或滴管。
Note also that some non-sensical scenarios (e.g., a Queue preceding an Algorithmic Dropper, directly feeding into another Queue), are prohibited.
还请注意，禁止某些非感官场景（例如，算法滴管前面的队列，直接送入另一个队列）。
A SLS is presumed to have been negotiated between the customer and the provider which specifies the handling of the customer's traffic, as defined by a TCS) by the provider's network. The agreement might be of the following form:
假定客户和提供商之间已协商SLS，该SLS指定由提供商的网络处理客户的通信量（由TCS定义）。协议可以采用以下形式：
DSCP PHB Profile Treatment
---- --- ------- ----------------------
001001 EF Profile4 Discard non-conforming.
001100 AF11 Profile5 Shape to profile, tail-drop when full.
001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000,
tail-drop when full.
other BE none Apply RED-like dropping.
DSCP PHB Profile Treatment
---- --- ------- ----------------------
001001 EF Profile4 Discard non-conforming.
001100 AF11 Profile5 Shape to profile, tail-drop when full.
001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000,
tail-drop when full.
other BE none Apply RED-like dropping.
This SLS specifies that the customer may submit packets marked for DSCP 001001 which will get EF treatment so long as they remain conforming to Profile4, which will be discarded if they exceed this profile. The discarded packets are counted in this example, perhaps for use by the provider's sales department in convincing the customer to buy a larger SLS. Packets marked for DSCP 001100 will be shaped to Profile5 before forwarding. Packets marked for DSCP 001101 will be metered to Profile3 with non-conforming packets "downgraded" by being re-marked with a DSCP of 001000. It is implicit in this agreement that conforming packets are given the PHB originally indicated by the packets' DSCP field.
本SLS规定，客户可提交标记为DSCP 001001的数据包，只要这些数据包仍符合Profile4，则将得到EF处理，如果超过此profile，则将丢弃这些数据包。在本例中，丢弃的数据包被计数，可能供提供商的销售部门用于说服客户购买更大的SLS。标记为DSCP 001100的数据包将在转发前成形为Profile5。标记为DSCP 001101的数据包将通过重新标记为DSCP 001000的不合格数据包“降级”计量至Profile3。在该协议中，一致性数据包被赋予最初由数据包的DSCP字段指示的PHB。
Figures 6 and 7 illustrates a TCB that might be used to handle this SLS at an ingress interface at the customer/provider boundary.
图6和图7显示了一个TCB，可用于在客户/提供商边界的入口接口处处理此SLS。
The Classification stage of this example consists of a single BA classifier. The BA classifier is used to separate traffic based on the Diffserv service level requested by the customer (as indicated by the DSCP in each submitted packet's IP header). We illustrate three DSCP filter values: A, B, and C. The 'X' in the BA classifier is a wildcard filter that matches every packet not otherwise matched.
本例的分类阶段由单个BA分类器组成。BA分类器用于根据客户请求的Diffserv服务级别（如每个提交数据包的IP报头中的DSCP所示）分离流量。我们举例说明了三个DSCP筛选器值：A、B和C。BA分类器中的“X”是一个通配符筛选器，它匹配每个不匹配的数据包。
The path for DSCP 001100 proceeds directly to Dropper1 whilst the paths for DSCP 001001 and 001101 include a metering stage. All other traffic is passed directly on to Dropper3. There is a separate meter for each set of packets corresponding to classifier outputs A and C. Each meter uses a specific profile, as specified in the TCS, for the corresponding Diffserv service level. The meters in this example each indicate one of two conformance levels: conforming or non-conforming.
DSCP 001100的路径直接进入Dropper1，而DSCP 001001和001101的路径包括计量级。所有其他流量都直接传递到Dropper3。与分类器输出a和C相对应的每组数据包都有一个单独的仪表。每个仪表使用TCS中规定的特定配置文件，用于相应的Diffserv服务级别。本例中的仪表分别表示两个一致性等级中的一个：一致性或不一致性。
Following the Metering stage is an Action stage in some of the branches. Packets submitted for DSCP 001001 (Classifier output A) that are deemed non-conforming by Meter1 are counted and discarded while packets that are conforming are passed on to Queue1. Packets submitted for DSCP 001101 (Classifier output C) that are deemed non-conforming by Meter2 are re-marked and then both conforming and non-conforming packets are multiplexed together before being passed on to Dropper2/Queue3.
计量阶段之后是一些分支中的操作阶段。为DSCP 001001（分类器输出A）提交的被Meter1视为不合格的数据包被计数并丢弃，而合格的数据包被传递到Queue1。为DSCP 001101（分类器输出C）提交的、被Meter2视为不合格的数据包被重新标记，然后合格数据包和不合格数据包在传递给Dropper2/Queue3之前被复用在一起。
The Algorithmic Dropping, Queuing and Scheduling stages are realized as follows, illustrated in figure 7. Note that the figure does not show any of the implicit control linkages between elements that allow e.g., an Algorithmic Dropper to sense the current state of a succeeding Queue.
算法丢弃、排队和调度阶段实现如下，如图7所示。请注意，该图未显示允许例如算法滴管感测后续队列的当前状态的元素之间的任何隐式控制链接。
+-----+
| A|---------------------------> to Queue1
+->| |
| | B|--+ +-----+ +-----+
| +-----+ | | | | |
| Meter1 +->| |--->| |
| | | | |
| +-----+ +-----+
| Counter1 Absolute
submitted +-----+ | Dropper1
traffic | A|-----+
--------->| B|--------------------------------------> to AlgDropper1
| C|-----+
| X|--+ |
+-----+ | | +-----+ +-----+
Classifier1| | | A|--------------->|A |
(BA) | +->| | | |--> to AlgDrop2
| | B|--+ +-----+ +->|B |
| +-----+ | | | | +-----+
| Meter2 +->| |-+ Mux1
| | |
| +-----+
| Marker1
+-----------------------------------> to AlgDropper3
+-----+
| A|---------------------------> to Queue1
+->| |
| | B|--+ +-----+ +-----+
| +-----+ | | | | |
| Meter1 +->| |--->| |
| | | | |
| +-----+ +-----+
| Counter1 Absolute
submitted +-----+ | Dropper1
traffic | A|-----+
--------->| B|--------------------------------------> to AlgDropper1
| C|-----+
| X|--+ |
+-----+ | | +-----+ +-----+
Classifier1| | | A|--------------->|A |
(BA) | +->| | | |--> to AlgDrop2
| | B|--+ +-----+ +->|B |
| +-----+ | | | | +-----+
| Meter2 +->| |-+ Mux1
| | |
| +-----+
| Marker1
+-----------------------------------> to AlgDropper3
Figure 6: An Example Traffic Conditioning Block (Part 1)
图6：交通调节块示例（第1部分）
Conforming DSCP 001001 packets from Meter1 are passed directly to Queue1: there is no way, with configuration of the following Scheduler to match the metering, for these packets to overflow the depth of Queue1, so there is no requirement for dropping at this point. Packets marked for DSCP 001100 must be passed through a tail-dropper, AlgDropper1, which serves to limit the depth of the following queue, Queue2: packets that arrive to a full queue will be discarded. This is likely to be an error case: the customer is obviously not sticking to its agreed profile. Similarly, all packets from the original DSCP 001101 stream (some may have been re-marked by this stage) are passed to AlgDropper2 and Queue3. Packets marked for all other DSCPs are passed to AlgDropper3 which is a RED-like Algorithmic Dropper: based on feedback of the current depth of Queue4, this dropper is supposed to discard enough packets from its input stream to keep the queue depth under control.
来自Meter1的符合DSCP 001001的数据包直接传递到Queue1：通过配置以下调度程序以匹配计量，这些数据包无法溢出Queue1的深度，因此此时不需要丢弃。标记为DSCP 001100的数据包必须通过尾部滴管AlgDropper1传递，该滴管用于限制以下队列Queue2的深度：到达完整队列的数据包将被丢弃。这可能是一个错误案例：客户显然没有遵守约定的配置文件。类似地，来自原始DSCP 001101流的所有数据包（一些数据包可能已被此阶段重新标记）都被传递到AlgDropper2和Queue3。标记为所有其他DSCP的数据包被传递给AlgDropper3，AlgDropper3是一个类似红色的算法滴管：根据队列4当前深度的反馈，该滴管应该从其输入流中丢弃足够的数据包，以保持队列深度在控制之下。
These four Queue elements are then serviced by a Scheduler element Scheduler1: this must be configured to give each of its inputs an appropriate priority and/or bandwidth share. Inputs A and C are given guarantees of bandwidth, as appropriate for the contracted profiles. Input B is given a limit on the bandwidth it can use (i.e., a non-work-conserving discipline) in order to achieve the desired shaping of this stream. Input D is given no limits or guarantees but a lower priority than the other queues, appropriate for its best-effort status. Traffic then exits the Scheduler in a single orderly stream.
这四个队列元素随后由调度器元素Scheduler1提供服务：必须将其配置为为为每个输入提供适当的优先级和/或带宽共享。为输入A和C提供带宽保证，适用于合同配置文件。为输入B提供其可以使用的带宽限制（即，非工作节约规程），以实现该流的期望成形。输入D没有限制或保证，但优先级比其他队列低，适合其尽力而为状态。然后，流量以单个有序流的形式退出调度程序。
The interconnections of the TCB elements illustrated in Figures 6 and 7 can be represented textually as follows:
图6和图7所示的TCB元件的互连可按如下文本表示：
TCB1:
TCB1：
Classifier1: FilterA: Meter1 FilterB: Dropper1 FilterC: Meter2 Default: Dropper3
分类器1:FilterA:Meter1过滤器B:Dropper1过滤器C:Meter2默认值：Dropper3
from Meter1 +-----+
------------------------------->| |----+
| | |
+-----+ |
Queue1 |
| +-----+
from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic
AlgDropper1 Queue2 | | +-----+
| | Scheduler1
from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ |
| | | | |
+-----+ +-----+ |
AlgDropper2 Queue3 |
|
from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+
| | | |
+-----+ +-----+
AlgDropper3 Queue4
from Meter1 +-----+
------------------------------->| |----+
| | |
+-----+ |
Queue1 |
| +-----+
from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic
AlgDropper1 Queue2 | | +-----+
| | Scheduler1
from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ |
| | | | |
+-----+ +-----+ |
AlgDropper2 Queue3 |
|
from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+
| | | |
+-----+ +-----+
AlgDropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2)
图7：交通调节块示例（第2部分）
Meter1: Type: AverageRate Profile: Profile4 ConformingOutput: Queue1 NonConformingOutput: Counter1
Meter1:类型：AverageRate配置文件：配置文件4符合输出：队列1不符合输出：计数器1
Counter1: Output: AbsoluteDropper1
计数器1：输出：绝对滴管1
Meter2: Type: AverageRate Profile: Profile3 ConformingOutput: Mux1.InputA NonConformingOutput: Marker1
Meter2:类型：平均值配置文件：配置文件3符合输出：Mux1.输入不符合输出：Marker1
Marker1: Type: DSCPMarker Mark: 001000 Output: Mux1.InputB
标记1:类型：DSCPMarker标记：001000输出：Mux1.InputB
Mux1: Output: Dropper2
Mux1：输出：滴管2
AlgDropper1: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Queue2.Depth > 10kbyte Output: Queue2
AlgDropper1:类型：AlgorithmcDropper规程：阈值触发：Queue2.深度>10KB输出：Queue2
AlgDropper2: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Queue3.Depth > 20kbyte Output: Queue3
AlgDropper2:类型：AlgorithmcDropper规程：阈值触发时丢弃：Queue3.深度>20kbyte输出：Queue3
AlgDropper3:
Type: AlgorithmicDropper
Discipline: RED93
Trigger: Internal
Output: Queue3
MinThresh: Queue3.Depth > 20 kbyte
MaxThresh: Queue3.Depth > 40 kbyte
<other RED parms too>
AlgDropper3:
Type: AlgorithmicDropper
Discipline: RED93
Trigger: Internal
Output: Queue3
MinThresh: Queue3.Depth > 20 kbyte
MaxThresh: Queue3.Depth > 40 kbyte
<other RED parms too>
Queue1: Type: FIFO Output: Scheduler1.InputA
队列1:类型：FIFO输出：Scheduler1.InputA
Queue2: Type: FIFO Output: Scheduler1.InputB
队列2:类型：FIFO输出：Scheduler1.InputB
Queue3: Type: FIFO Output: Scheduler1.InputC
队列3:类型：FIFO输出：Scheduler1.InputC
Queue4: Type: FIFO Output: Scheduler1.InputD
队列4:类型：FIFO输出：Scheduler1.InputD
Scheduler1: Type: Scheduler4Input InputA: MaxRateProfile: none MinRateProfile: Profile4 Priority: 20 InputB: MaxRateProfile: Profile5 MinRateProfile: none Priority: 40 InputC: MaxRateProfile: none MinRateProfile: Profile3 Priority: 20 InputD: MaxRateProfile: none MinRateProfile: none Priority: 10
Scheduler1:类型：Scheduler4输入输入：MaxRateProfile:无MinRateProfile:配置文件4优先级：20输入B:MaxRateProfile:配置文件5 MinRateProfile:无优先级：40输入UTC:MaxRateProfile:无MinRateProfile:配置文件3优先级：20输入：MaxRateProfile:无MinRateProfile:无优先级：10
The TCB described above can be installed on an ingress interface to implement a provider/customer TCS if the interface is dedicated to the customer. However, if a single interface is shared between multiple customers, then the TCB above will not suffice, since it does not differentiate among traffic from different customers. Its classification stage uses only BA classifiers.
如果接口专用于客户，则可以将上述TCB安装在入口接口上，以实现提供商/客户TCS。但是，如果一个接口在多个客户之间共享，那么上面的TCB就不够了，因为它不能区分来自不同客户的流量。其分类阶段仅使用BA分类器。
The configuration is readily modified to support the case of multiple customers per interface, as follows. First, a TCB is defined for each customer to reflect the TCS with that customer: TCB1, defined above is the TCB for customer 1. Similar elements are created for
配置很容易修改，以支持每个接口有多个客户的情况，如下所示。首先，为每个客户定义TCB，以反映该客户的TCS：TCB1，上面定义的是客户1的TCB。类似的元素是为
TCB2 and for TCB3 which reflect the agreements with customers 2 and 3 respectively. These 3 TCBs may or may not contain similar elements and parameters.
TCB2和TCB3，分别反映与客户2和3的协议。这3个TCB可能包含也可能不包含类似的元素和参数。
Finally, a classifier is added to the front end to separate the traffic from the three different customers. This forms a new TCB, TCB4, which is illustrated in Figure 8.
最后，在前端添加一个分类器来分离来自三个不同客户的流量。这形成了一个新的TCB，TCB4，如图8所示。
A representation of this multi-customer TCB might be:
此多客户TCB的表示可能是：
TCB4:
TCB4：
Classifier4: Filter1: to TCB1 Filter2: to TCB2 Filter3: to TCB3 No Match: AbsoluteDropper4
分类器4:过滤器1:至TCB1过滤器2:至TCB2过滤器3:至TCB3不匹配：绝对滴管4
AbsoluteDropper4: Type: AbsoluteDropper
绝对滴管4:类型：绝对滴管
TCB1: (as defined above)
TCB1：（如上定义）
TCB2: (similar to TCB1, perhaps with different elements or numeric parameters)
TCB2：（与TCB1类似，可能有不同的元素或数值参数）
TCB3: (similar to TCB1, perhaps with different elements or numeric parameters)
TCB3：（与TCB1类似，可能有不同的元素或数字参数）
and the filters, based on each customer's source MAC address, could be defined as follows:
基于每个客户的源MAC地址的过滤器可定义如下：
Filter1:
过滤器1：
submitted +-----+
traffic | A|--------> TCB1
--------->| B|--------> TCB2
| C|--------> TCB3
| X|------+ +-----+
+-----+ +-->| |
Classifier4 +-----+
AbsoluteDrop4
submitted +-----+
traffic | A|--------> TCB1
--------->| B|--------> TCB2
| C|--------> TCB3
| X|------+ +-----+
+-----+ +-->| |
Classifier4 +-----+
AbsoluteDrop4
Figure 8: An Example of a Multi-Customer TCB
图8：多客户TCB示例
Type: MacAddress SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) SrcMask: FF-FF-FF-FF-FF-FF DestValue: 00-00-00-00-00-00 DestMask: 00-00-00-00-00-00
类型：MacAddress SrcValue:01-02-03-04-05-06（客户1的源MAC地址）SrcMask:FF-FF-FF-FF-FF DestValue:00-00-00-00 DestMask:00-00-00-00
Filter2: (similar to Filter1 but with customer 2's source MAC address as SrcValue)
Filter2：（与Filter1类似，但客户2的源MAC地址为SrcValue）
Filter3: (similar to Filter1 but with customer 3's source MAC address as SrcValue)
Filter3：（与Filter1类似，但客户3的源MAC地址为SrcValue）
In this example, Classifier4 separates traffic submitted from different customers based on the source MAC address in submitted packets. Those packets with recognized source MAC addresses are passed to the TCB implementing the TCS with the corresponding customer. Those packets with unrecognized source MAC addresses are passed to a dropper.
在本例中，Classifier4基于提交的数据包中的源MAC地址来分离从不同客户提交的流量。具有可识别源MAC地址的那些数据包被传递给与相应客户实现TCS的TCB。那些具有无法识别的源MAC地址的数据包被传递到滴管。
TCB4 has a Classifier stage and an Action element stage performing dropping of all unmatched traffic.
TCB4具有分类器阶段和动作元素阶段，用于执行所有不匹配流量的丢弃。
The TCB illustrated above describes a configuration that might be suitable for enforcing a SLS at a router's ingress. It assumes that the customer marks its own traffic for the appropriate service level. It then limits the rate of aggregate traffic submitted at each service level, thereby protecting the resources of the Diffserv network. It does not provide any isolation between the customer's individual microflows.
上面所示的TCB描述了可能适合于在路由器的入口处实施SLS的配置。它假设客户为适当的服务级别标记自己的流量。然后，它限制在每个服务级别提交的聚合流量的速率，从而保护区分服务网络的资源。它不在客户的单个微流之间提供任何隔离。
A more complex example might be a TCB configuration that offers additional functionality to the customer. It recognizes individual customer microflows and marks each one independently. It also isolates the customer's individual microflows from each other in order to prevent a single microflow from seizing an unfair share of the resources available to the customer at a certain service level. This is illustrated in Figure 9.
更复杂的示例可能是向客户提供附加功能的TCB配置。它识别单个客户微流量，并独立标记每个微流量。它还将客户的单个微流彼此隔离，以防止单个微流在某个服务级别占用客户可用资源的不公平份额。如图9所示。
Suppose that the customer has an SLS which specifies 2 service levels, to be identified to the provider by DSCP A and DSCP B. Traffic is first directed to a MF classifier which classifies traffic based on miscellaneous classification criteria, to a granularity sufficient to identify individual customer microflows. Each microflow can then be marked for a specific DSCP The metering
假设客户有一个指定2个服务级别的SLS，由DSCP A和DSCP B向提供商标识。流量首先被定向到MF分类器，该分类器根据杂项分类标准对流量进行分类，粒度足以识别单个客户微流量。然后，可以在计量过程中为每个微流标记一个特定的DSCP
elements limit the contribution of each of the customer's microflows to the service level for which it was marked. Packets exceeding the allowable limit for the microflow are dropped.
元素限制每个客户微流对其标记的服务级别的贡献。超过微流允许限制的数据包将被丢弃。
+-----+ +-----+
Classifier1 | | | |---------------+
(MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | |
| A|------ +-----+ +-----+ +-----+ |
-->| B|-----+ Marker1 Meter1 Absolute |
| C|---+ | Dropper1 | +-----+
| X|-+ | | +-----+ +-----+ +-->|A |
+-----+ | | | | | | |------------------>|B |--->
| | +->| |-->| | +-----+ +-->|C | to TCB2
| | | | | |---->| | | +-----+
| | +-----+ +-----+ +-----+ | Mux1
| | Marker2 Meter2 Absolute |
| | Dropper2 |
| | +-----+ +-----+ |
| | | | | |---------------+
| |--->| |-->| | +-----+
| | | | |---->| |
| +-----+ +-----+ +-----+
| Marker3 Meter3 Absolute
| Dropper3
V etc.
+-----+ +-----+
Classifier1 | | | |---------------+
(MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | |
| A|------ +-----+ +-----+ +-----+ |
-->| B|-----+ Marker1 Meter1 Absolute |
| C|---+ | Dropper1 | +-----+
| X|-+ | | +-----+ +-----+ +-->|A |
+-----+ | | | | | | |------------------>|B |--->
| | +->| |-->| | +-----+ +-->|C | to TCB2
| | | | | |---->| | | +-----+
| | +-----+ +-----+ +-----+ | Mux1
| | Marker2 Meter2 Absolute |
| | Dropper2 |
| | +-----+ +-----+ |
| | | | | |---------------+
| |--->| |-->| | +-----+
| | | | |---->| |
| +-----+ +-----+ +-----+
| Marker3 Meter3 Absolute
| Dropper3
V etc.
Figure 9: An Example of a Marking and Traffic Isolation TCB
图9：标记和交通隔离TCB示例
This TCB could be formally specified as follows:
该TCB可正式规定如下：
TCB1: Classifier1: (MF) FilterA: Marker1 FilterB: Marker2 FilterC: Marker3 etc.
TCB1:Classifier1：（MF）过滤器A:Marker1过滤器B:Marker2过滤器C:Marker3等。
Marker1: Output: Meter1
Marker1:输出：Meter1
Marker2: Output: Meter2
Marker2:输出：Meter2
Marker3: Output: Meter3
Marker3:输出：米3
Meter1: ConformingOutput: Mux1.InputA NonConformingOutput: AbsoluteDropper1
流量计1：符合输出：Mux1。输入不符合输出：绝对滴管1
Meter2: ConformingOutput: Mux1.InputB NonConformingOutput: AbsoluteDropper2
仪表2：符合输出：Mux1。输入B不符合输出：绝对滴管2
Meter3: ConformingOutput: Mux1.InputC NonConformingOutput: AbsoluteDropper3
仪表3：符合输出：Mux1。输入UTC不符合输出：绝对滴管3
etc.
等
Mux1: Output: to TCB2
Mux1：输出：至TCB2
Note that the detailed traffic element declarations are not shown here. Traffic is either dropped by TCB1 or emerges marked for one of two DSCPs. This traffic is then passed to TCB2 which is illustrated in Figure 10.
请注意，此处未显示详细的流量元素声明。TCB1丢弃通信量或标记为两个DSCP中的一个。然后，该流量被传递到TCB2，如图10所示。
TCB2 could then be specified as follows:
然后，可以按如下方式指定TCB2：
Classifier2: (BA) FilterA: Meter5 FilterB: Meter6
分类器2：（BA）过滤器A:Meter5过滤器B:Meter6
+-----+
| |---------------> to Queue1
+->| | +-----+
+-----+ | | |---->| |
| A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4
| B|---+ +-----+
+-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+
(BA) | |---->| |
+-----+ +-----+
Meter6 AbsoluteDropper5
+-----+
| |---------------> to Queue1
+->| | +-----+
+-----+ | | |---->| |
| A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4
| B|---+ +-----+
+-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+
(BA) | |---->| |
+-----+ +-----+
Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2
图10：附加示例：TCB2
Meter5: ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper4
Meter5:符合输出：队列1不符合输出：绝对滴管4
Meter6: ConformingOutput: Queue2 NonConformingOutput: AbsoluteDropper5
流量计6:符合输出：队列2不符合输出：绝对滴管5
Nothing in this model prevents more complex scenarios in which one microflow TCB precedes another (e.g., for TCBs implementing separate TCSs for the source and for a set of destinations).
该模型中的任何内容都无法阻止一个微流TCB先于另一个微流TCB的更复杂场景（例如，对于为源和一组目的地实施单独TCS的TCB）。
Security vulnerabilities of Diffserv network operation are discussed in [DSARCH]. This document describes an abstract functional model of Diffserv router elements. Certain denial-of-service attacks such as those resulting from resource starvation may be mitigated by appropriate configuration of these router elements; for example, by rate limiting certain traffic streams or by authenticating traffic marked for higher quality-of-service.
[DSARCH]中讨论了区分服务网络操作的安全漏洞。本文档描述了Diffserv路由器元件的抽象功能模型。通过适当配置这些路由器元件，可以减轻某些拒绝服务攻击，例如由资源不足引起的攻击；例如，通过对某些流量流进行速率限制，或通过对标记为具有更高服务质量的流量进行身份验证。
There may be theft-of-service scenarios where a malicious host can exploit a loose token bucket policer to obtain slightly better QoS than that committed in the TCS.
可能存在盗用服务的情况，恶意主机可以利用松散令牌桶策略获得比TCS中提交的略好的QoS。
Concepts, terminology, and text have been borrowed liberally from [POLTERM], as well as from other IETF work on MIBs and policy-management. We wish to thank the authors of some of those documents: Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, Scott Hahn, and Andrea Westerinen for their contributions.
概念、术语和文本大量借用自[POLTERM]，以及IETF在MIB和策略管理方面的其他工作。我们要感谢其中一些文件的作者：弗雷德·贝克、迈克尔·费恩、基思·麦克洛赫里、约翰·塞利格森、郭·陈、斯科特·哈恩和安德里亚·维斯特林，感谢他们的贡献。
This document has benefited from the comments and suggestions of several participants of the Diffserv working group, particularly Shahram Davari, John Strassner, and Walter Weiss. This document could never have reached this level of rough consensus without the relentless pressure of the co-chairs Brian Carpenter and Kathie Nichols, for which the authors are grateful.
本文件得益于Diffserv工作组若干参与者的评论和建议，特别是Shahram Davari、John Strassner和Walter Weiss。如果没有Brian Carpenter和Kathie Nichols联席主席的不懈压力，这份文件不可能达到如此粗略的共识水平，作者对此表示感谢。
[AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF-PHB]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[DSARCH] Carlson, M., Weiss, W., Blake, S., Wang, Z., Black, D. and E. Davies, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DSARCH]Carlson，M.，Weiss，W.，Blake，S.，Wang，Z.，Black，D.和E.Davies，“差异化服务架构”，RFC 24751998年12月。
[DSFIELD] 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.
[DSFIELD]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 24741998年12月。
[DSMIB] Baker, F., Smith, A., and K. Chan, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[DSMIB]Baker，F.，Smith，A.，和K.Chan，“差异化服务体系结构的管理信息库”，RFC 3289，2002年5月。
[E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Nichols, K., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[E2E]Bernet，Y.，Yavatkar，R.，Ford，P.，Baker，F.，Zhang，L.，Speer，M.，Nichols，K.，Braden，R.，Davie，B.，Wroclawski，J.和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 29982000年11月。
[EF-PHB] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[EF-PHB]Davie，B.，Charny，A.，Bennett，J.C.R.，Benson，K.，Le Boudec，J.Y.，Courtney，W.，Davari，S.，Firoiu，V.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[FJ95] Floyd, S. and V. Jacobson, "Link Sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 No. 4, August 1995l.
[FJ95]Floyd，S.和V.Jacobson，“分组网络的链路共享和资源管理模型”，IEEE/ACM网络事务，第3卷第4期，1995年8月L。
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[INTSERV]Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[NEWTERMS] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April, 2002
[NEWTERMS]Grossman，D.，“区分服务的新术语和澄清”，RFC3260，2002年4月
[PDBDEF] K. Nichols and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for Their Specification", RFC 3086, April 2001.
[PDBDEF]K.Nichols和B.Carpenter，“每域区分服务行为的定义及其规范规则”，RFC 3086，2001年4月。
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Policy Terminology", RFC 3198, November 2001.
[POLTERM]Westerinen，A.，Schnizlein，J.，Strassner，J.，Scherling，M.，Quinn，B.，Herzog，S.，Huynh，A.，Carlson，M.，Perry，J.和S.Waldbusser，“政策术语”，RFC 3198，2001年11月。
[QOSDEVMOD] Strassner, J., Westerinen, A. and B. Moore, "Information Model for Describing Network Device QoS Mechanisms", Work in Progress.
[QOSDEVMOD]Strassner，J.，Westerinen，A.和B.Moore，“描述网络设备QoS机制的信息模型”，正在进行中。
[QUEUEMGMT] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, C., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[QUEUEMGMT]布拉登，R.，克拉克，D.，克劳克罗夫特，J.，戴维斯，B.，迪林，S.，埃斯特林，D.，弗洛伊德，S.，雅各布森，V.，明厅，C.，帕特里奇，C.，彼得森，L.，罗马克里希南，K.，申克，S.，沃克罗夫斯基，J.和L.张，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[SRTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[SRTCM]Heinanen，J.和R.Guerin，“单速率三色标记”，RFC 26971999年9月。
[TRTCM] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999.
[TRTCM]Heinanen，J.和R.Guerin，“双速率三色标记”，RFC 26981999年9月。
[VIC] McCanne, S. and Jacobson, V., "vic: A Flexible Framework
for Packet Video", ACM Multimedia '95, November 1995, San
Francisco, CA, pp. 511-522.
<ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[VIC] McCanne, S. and Jacobson, V., "vic: A Flexible Framework
for Packet Video", ACM Multimedia '95, November 1995, San
Francisco, CA, pp. 511-522.
<ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[802.1D] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.", ISO/IEC 15802-3: 1998.
[802.1D]“信息技术-系统间电信和信息交换-局域网和城域网-通用规范-第3部分：媒体访问控制（MAC）网桥：修订版。这是ISO/IEC 10038:1993、802.1j-1992和802.6k-1992的修订版。它包含了P802.11c、P802.1p和P802.12e。”，ISO/IEC 15802-3:1998。
"Leaky bucket" and/or "Token Bucket" models are used to describe rate control in several architectures, including Frame Relay, ATM, Integrated Services and Differentiated Services. Both of these models are, by definition, theoretical relationships between some defined burst size, B, a rate, R, and a time interval, t:
“漏桶”和/或“令牌桶”模型用于描述几种架构中的速率控制，包括帧中继、ATM、集成服务和区分服务。根据定义，这两种模型都是某些已定义的突发大小B、速率R和时间间隔t之间的理论关系：
R = B/t
R = B/t
Thus, a token bucket or leaky bucket might specify an information rate of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token rate is 1,200,000 bits per second, the token burst is 12,000 bits and the token interval is 10 milliseconds. The specification says that conforming traffic will, in the worst case, come in 100 bursts per second of 1500 bytes each and at an average rate not exceeding 1.2 Mbps.
因此，令牌桶或泄漏桶可以指定信息速率为1.2Mbps，突发大小为1500字节。在这种情况下，令牌速率为每秒1200000位，令牌突发为12000位，令牌间隔为10毫秒。该规范指出，在最坏的情况下，一致性通信量将以每秒100次突发的方式出现，每次突发1500字节，平均速率不超过1.2Mbps。
A leaky bucket algorithm is primarily used for shaping traffic as it leaves an interface onto the network (handled under Queues and Schedulers in this model). Traffic theoretically departs from an interface at a rate of one bit every so many time units (in the example, one bit every 0.83 microseconds) but, in fact, departs in multi-bit units (packets) at a rate approximating the theoretical, as measured over a longer interval. In the example, it might send one 1500 byte packet every 10 ms or perhaps one 500 byte packet every 3.3 ms. It is also possible to build multi-rate leaky buckets in which traffic departs from the interface at varying rates depending on recent activity or inactivity.
漏桶算法主要用于在流量离开网络接口时形成流量（在此模型中，在队列和调度器下处理）。理论上，通信量以每这么多时间单位一位的速率（在本例中，每0.83微秒一位）离开接口，但事实上，以多位单位（数据包）的速率离开接口，其速率接近理论速率，如在较长时间间隔内测得的。在该示例中，它可能每10毫秒发送一个1500字节的数据包，或者可能每3.3毫秒发送一个500字节的数据包。还可能构建多速率泄漏桶，其中流量根据最近的活动或不活动以不同的速率离开接口。
Implementations generally seek as constant a transmission rate as achievable. In theory, a 10 Mbps shaped transmission stream from an algorithmic implementation and a stream which is running at 10 Mbps because its bottleneck link has been a 10 Mbps Ethernet link should be indistinguishable. Depending on configuration, the approximation to theoretical smoothness may vary by moving as much as an MTU from one token interval to another. Traffic may also be jostled by other traffic competing for the same transmission resources.
实现通常寻求尽可能恒定的传输速率。理论上，来自算法实现的10 Mbps形状的传输流和由于其瓶颈链路是10 Mbps以太网链路而以10 Mbps速度运行的流应该是不可区分的。根据配置，理论平滑度的近似值可能因MTU从一个令牌间隔移动到另一个令牌间隔而有所不同。通信量也可能被竞争相同传输资源的其他通信量所推挤。
A token bucket, on the other hand, measures the arrival rate of traffic from another device. This traffic may originally have been shaped using a leaky bucket shaper or its equivalent. The token bucket determines whether the traffic (still) conforms to the specification. Multi-rate token buckets (e.g., token buckets with
另一方面，令牌桶测量来自另一个设备的流量到达率。该流量最初可能是使用漏桶成形器或其等效物成形的。令牌桶确定通信量（仍然）是否符合规范。多速率令牌桶（例如，具有
both a peak rate and a mean rate, and sometimes more) are commonly used, such as those described in [SRTCM] and [TRTCM]. In this case, absolute smoothness is not expected, but conformance to one or more of the specified rates is.
通常使用峰值速率和平均速率（有时更多），如[SRTCM]和[TRTCM]中所述。在这种情况下，不需要绝对平滑度，但需要符合一个或多个指定速率。
Simplistically, a data stream is said to conform to a simple token bucket parameterized by a {R, B} if the system receives in any time interval, t, at most, an amount of data not exceeding (R * t) + B.
简单地说，如果系统在任何时间间隔t内最多接收不超过（R*t）+B的数据量，则数据流被称为符合由a{R，B}参数化的简单令牌桶。
For a multi-rate token bucket case, the data stream is said to conform if, for each of the rates, the stream conforms to the token-bucket profile appropriate for traffic of that class. For example, received traffic that arrives pre-classified as one of the "excess" rates (e.g., AF12 or AF13 traffic for a device implementing the AF1x PHB) is only compared to the relevant "excess" token bucket profile.
对于多速率令牌桶情况，如果对于每个速率，数据流符合适合于该类业务的令牌桶配置文件，则称数据流符合。例如，预先分类为“超额”速率之一的到达的接收流量（例如，对于实现AF1x PHB的设备，AF12或AF13流量）仅与相关的“超额”令牌桶配置文件进行比较。
The fact that Internet Protocol data is organized into variable length packets introduces some uncertainty in the conformance decision made by any downstream Meter that is attempting to determine conformance to a traffic profile that is theoretically designed for fixed-length units of data.
互联网协议数据被组织成可变长度的数据包，这一事实在试图确定与理论上为固定长度数据单元设计的流量配置文件的一致性的任何下游仪表所做的一致性决策中引入了一些不确定性。
When used as a leaky bucket shaper, the above definition interacts with clock granularity in ways one might not expect. A leaky bucket releases a packet only when all of its bits would have been allowed: it does not borrow from future capacity. If the clock is very fine grain, on the order of the bit rate or faster, this is not an issue. But if the clock is relatively slow (and millisecond or multi-millisecond clocks are not unusual in networking equipment), this can introduce jitter to the shaped stream.
当用作漏桶整形器时，上述定义与时钟粒度的交互方式可能出乎意料。漏桶只有在其所有位都被允许的情况下才会释放数据包：它不会借用未来的容量。如果时钟是非常精细的，在比特率或更快的顺序上，这不是一个问题。但是，如果时钟相对较慢（毫秒或多毫秒时钟在网络设备中并不少见），这可能会给成形流带来抖动。
This leaves an implementor of a token bucket Meter with a dilemma. When the number of bandwidth tokens, b, left in the token bucket is positive but less than the size of the packet being operated on, L, one of three actions can be performed:
这使得令牌桶计量器的实现者陷入了两难境地。当留在令牌桶中的带宽令牌b的数量为正但小于正在操作的分组L的大小时，可以执行三个操作之一：
(1) The whole size of the packet can be subtracted from the bucket, leaving it negative, remembering that, when new tokens are next added to the bucket, the new token allocation, B, must be added to b rather than simply setting the bucket to "full". This option potentially puts more than the desired burst size of data into this token bucket interval and correspondingly less into the next. It does, however, keep the average amount accepted per token bucket interval equal to the token burst. This approach accepts traffic if any one bit in the packet would have been
(1) 可以从bucket中减去数据包的整个大小，将其保留为负值，记住，当下一次向bucket添加新令牌时，必须将新令牌分配B添加到B，而不是简单地将bucket设置为“full”。此选项可能会将超过所需的数据突发大小的数据放入此令牌桶间隔，并相应地将更少的数据放入下一个令牌桶间隔。但是，它确实会使每个令牌桶间隔接受的平均数量等于令牌突发。如果数据包中的任何一个比特都被删除，这种方法接受通信量
accepted and borrows up to one MTU of capacity from one or more subsequent intervals when necessary. Such a token bucket meter implementation is said to offer "loose" conformance to the token bucket.
必要时，接受并从一个或多个后续间隔借用最多一个MTU的容量。这种令牌桶计量器实现据说提供了与令牌桶的“松散”一致性。
(2) Alternatively, the packet can be rejected and the amount of tokens in the bucket left unchanged (and maybe an attempt could be made to accept the packet under another threshold in another bucket), remembering that, when new tokens are next added to the bucket, the new token allocation, B, must be added to b rather than simply setting the bucket to "full". This potentially puts less than the permissible burst size of data into this token bucket interval and correspondingly more into the next. Like the first option, it keeps the average amount accepted per token bucket interval equal to the token burst. This approach accepts traffic only if every bit in the packet would have been accepted and borrows up to one MTU of capacity from one or more previous intervals when necessary. Such a token bucket meter implementation is said to offer "strict" (or perhaps "stricter") conformance to the token bucket. This option is consistent with [SRTCM] and [TRTCM] and is often used in ATM and frame-relay implementations.
(2) 或者，可以拒绝该分组并且保持该桶中的令牌量不变（并且可以尝试在另一桶中的另一阈值下接受该分组），记住，当下一次向该桶添加新令牌时，新令牌分配B，必须添加到b，而不是简单地将铲斗设置为“满”。这可能会将小于允许的数据突发大小的数据放入此令牌桶间隔，并相应地将更多数据放入下一令牌桶间隔。与第一个选项一样，它保持每个令牌桶间隔接受的平均数量等于令牌突发。这种方法仅当数据包中的每一位都被接受时才接受流量，并在必要时从一个或多个以前的间隔借用最多一个MTU的容量。这种令牌桶计量器实现据说提供了对令牌桶的“严格”（或者可能是“更严格”）一致性。此选项与[SRTCM]和[TRTCM]一致，通常用于ATM和帧中继实现。
(3) The TB variable can be set to zero to account for the first part of the packet and the remainder of the packet size can be taken out of the next-colored bucket. This, of course, has another bug: the same packet cannot have both conforming and non-conforming components in the Diffserv architecture and so is not really appropriate here and we do not discuss this option further here.
(3) TB变量可以设置为零，以考虑数据包的第一部分，数据包大小的剩余部分可以从下一个彩色存储桶中取出。当然，这还有另一个缺陷：同一个数据包在Diffserv体系结构中不能同时包含一致性组件和不一致性组件，因此在这里并不合适，我们在此不再进一步讨论此选项。
Unfortunately, the thing that cannot be done is exactly to fit the token burst specification with random sized packets: therefore token buckets in a variable length packet environment always have a some variance from theoretical reality. This has also been observed in the ATM Guaranteed Frame Rate (GFR) service category specification and Frame Relay. A number of observations may be made:
不幸的是，不能做的事情就是用随机大小的数据包精确地匹配令牌突发规范：因此，可变长度数据包环境中的令牌桶总是与理论实际存在一些差异。在ATM保证帧速率（GFR）服务类别规范和帧中继中也观察到了这一点。可以提出一些意见：
o Operationally, a token bucket meter is reasonable for traffic which has been shaped by a leaky bucket shaper or a serial line. However, traffic in the Internet is rarely shaped in that way: TCP applies no shaping to its traffic, but rather depends on longer-range ACK-clocking behavior to help it approximate a certain rate and explicitly sends traffic bursts during slow start, retransmission, and fast recovery. Video-on-IP implementations such as [VIC] may have a leaky bucket shaper available to them,
o 在操作上，令牌桶流量计对于由漏桶成形器或串行线路成形的流量是合理的。但是，Internet中的流量很少以这种方式成形：TCP不对其流量进行成形，而是依赖于较长范围的ACK时钟行为来帮助其接近一定的速率，并在慢启动、重传和快速恢复期间显式发送流量突发。IP视频实现（如[VIC]）可能有一个漏洞桶形器可供使用，
but often do not, and simply enqueue the output of their codec for transmission on the appropriate interface. As a result, in each of these cases, a token bucket meter may reject traffic in the short term (over a single token interval) which it would have accepted if it had a longer time in view and which it needs to accept for the application to work properly. To work around this, the token interval, B/R, must approximate or exceed the RTT of the session(s) in question and the burst size, B, must accommodate the largest burst that the originator might send.
但通常不会，只需将编解码器的输出排队，以便在适当的接口上传输。因此，在上述每种情况下，令牌桶计量器可能会在短期内（在单个令牌间隔内）拒绝流量，如果它有更长的时间，它会接受该流量，并且它需要接受该流量才能使应用程序正常工作。为了解决这个问题，令牌间隔B/R必须接近或超过所讨论会话的RTT，突发大小B必须适应发起者可能发送的最大突发。
o The behavior of a loose token bucket is significantly different from the token bucket description for ATM and for Frame Relay.
o 松散令牌桶的行为与ATM和帧中继的令牌桶描述明显不同。
o A loose token bucket does not accept packets while the token count is negative. This means that, when a large packet has just borrowed tokens from the future, even a small incoming packet (e.g., a 40-byte TCP ACK/SYN) will not be accepted. Therefore, if such a loose token bucket is configured with a burst size close to the MTU, some discrimination against smaller packets can take place: use of a larger burst size avoids this problem.
o 当令牌计数为负值时，松散令牌桶不接受数据包。这意味着，当一个大数据包刚刚从未来借用了令牌时，即使是一个小的传入数据包（例如，一个40字节的TCP ACK/SYN）也不会被接受。因此，如果将这种松散令牌桶配置为具有接近MTU的突发大小，则可以对较小的分组进行一些区分：使用较大的突发大小可以避免此问题。
o The converse of the above is that a strict token bucket sometimes does not accept large packets when a loose one would do so. Therefore, if such a strict token bucket is configured with a burst size close to the MTU, some discrimination against larger packets can take place: use of a larger burst size avoids this problem.
o 与上述相反的是，当松散的令牌桶接受大数据包时，严格的令牌桶有时不接受大数据包。因此，如果将这样一个严格的令牌桶配置为具有接近MTU的突发大小，则可以对较大的分组进行一些区分：使用较大的突发大小可以避免此问题。
o In real-world deployments, MTUs are often larger than the burst size offered by a link-layer network service provider. If so then it is possible that a strict token bucket meter would find that traffic never matches the specified profile: this may be avoided by not allowing such a specification to be used. This situation cannot arise with a loose token bucket since the smallest burst size that can be configured is 1 bit, by definition limiting a loose token bucket to having a burst size of greater than one MTU.
o 在实际部署中，MTU通常大于链路层网络服务提供商提供的突发大小。如果是这样，那么严格的令牌桶计量器可能会发现流量从未与指定的配置文件匹配：这可以通过不允许使用此类规范来避免。松散令牌桶不会出现这种情况，因为可以配置的最小突发大小是1位，根据定义，将松散令牌桶限制为具有大于一个MTU的突发大小。
o Both strict token bucket specifications, as specified in [SRTCM] and [TRTCM], and loose ones, are subject to a persistent under-run. These accumulate burst capacity over time, up to the maximum burst size. Suppose that the maximum burst size is exactly the size of the packets being sent - which one might call the "strictest" token bucket implementation. In such a case, when one packet has been accepted, the token depth becomes zero and starts to accumulate again. If the next packet is received any time earlier than a token interval later, it will not be accepted. If the next packet arrives exactly on time, it will be accepted and the token depth again set to zero. If it arrives later, however,
o [SRTCM]和[TRTCM]中规定的严格令牌桶规范和松散令牌桶规范都会持续运行不足。它们会随着时间的推移累积突发容量，直至达到最大突发大小。假设最大突发大小正好是正在发送的数据包的大小——这可以称为“最严格”的令牌桶实现。在这种情况下，当一个分组被接受时，令牌深度变为零并再次开始累积。如果下一个数据包在令牌间隔之后的任何时间之前被接收，它将不被接受。如果下一个数据包准时到达，它将被接受，并且令牌深度再次设置为零。但是，如果它晚到，
accumulation of tokens will have stopped because it is capped by the maximum burst size: during the interval between the bucket becoming full and the actual arrival of the packet, no new tokens are added. As a result, jitter that accumulates across multiple hops in the network conspires against the algorithm to reduce the actual acceptance rate. Thus it usually makes sense to set the maximum token bucket size somewhat greater than the MTU in order to absorb some of the jitter and allow a practical acceptance rate more in line with the desired theoretical rate.
令牌的累积将停止，因为它受到最大突发大小的限制：在bucket变满和数据包实际到达之间的间隔期间，不会添加新令牌。因此，在网络中多个跃点之间累积的抖动与降低实际接受率的算法背道而驰。因此，通常将最大令牌桶大小设置为略大于MTU，以便吸收一些抖动，并允许实际接受率更符合期望的理论速率。
The strict token bucket conformance behavior defined in [SRTCM] and [TRTCM] is not mandatory for compliance with any current Diffserv standards, but we give here a mathematical definition of two-parameter token bucket operation which is consistent with those documents and which can also be used to define a shaping profile.
[SRTCM]和[TRTCM]中定义的严格令牌桶一致性行为对于遵守任何当前的Diffserv标准来说都不是强制性的，但我们在这里给出了双参数令牌桶操作的数学定义，它与这些文档一致，也可用于定义成型配置文件。
Define a token bucket with bucket size B, token accumulation rate R and instantaneous token occupancy b(t). Assume that b(0) = B. Then after an arbitrary interval with no packet arrivals, b(t) will not change since the bucket is already full of tokens.
使用存储桶大小B、令牌累积率R和瞬时令牌占用率B（t）定义令牌存储桶。假设b（0）=b。然后在没有数据包到达的任意间隔之后，b（t）将不会改变，因为bucket中已经充满了令牌。
Assume a packet of size L bytes arrives at time t'. The bucket occupancy is still B. Then, as long as L <= B, the packet conforms to the meter, and afterwards
假设大小为L字节的数据包在时间t'到达。桶占用率仍然是B。然后，只要L<=B，数据包就符合仪表，然后
b(t') = B - L.
b（t'）=b-L。
Assume now an interval delta_t = t - t' elapses before the next packet arrives, of size L' <= B. Just before this, at time t-, the bucket has accumulated delta_t*R tokens over the interval, up to a maximum of B tokens so that:
现在假设在下一个数据包到达之前，时间间隔delta_t=t-t'已经过去，大小为L'<=B。就在这之前，在时间t-，存储桶已经在该时间间隔内累积了delta_t*R令牌，最大值为B令牌，以便：
b(t-) = min{ B, b(t') + delta_t*R }
b(t-) = min{ B, b(t') + delta_t*R }
For a strict token bucket, the conformance test is as follows:
对于严格的令牌桶，一致性测试如下：
if (b(t-) - L' >= 0) {
/* the packet conforms */
b(t) = b(t-) - L';
}
else {
/* the packet does not conform */
b(t) = b(t-);
}
if (b(t-) - L' >= 0) {
/* the packet conforms */
b(t) = b(t-) - L';
}
else {
/* the packet does not conform */
b(t) = b(t-);
}
This function can also be used to define a shaping profile. If a packet of size L arrives at time t, it will be eligible for transmission at time te given as follows (we still assume L <= B):
此功能还可用于定义成型轮廓。如果大小为L的数据包在时间t到达，则它将有资格在如下给定的时间te进行传输（我们仍然假设L<=B）：
te = max{ t, t" }
te = max{ t, t" }
where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L
credits have accumulated in the bucket, and when the packet would
conform if the token bucket were a meter. te != t" only if t > t".
where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L
credits have accumulated in the bucket, and when the packet would
conform if the token bucket were a meter. te != t" only if t > t".
A mathematical definition along these lines for loose token bucket conformance is left as an exercise for the reader.
关于松散令牌桶一致性的数学定义留给读者作为练习。
Authors' Addresses
作者地址
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
Yoram Bernet微软一路微软雷德蒙，华盛顿州98052
Phone: +1 425 936 9568
EMail: ybernet@msn.com
Phone: +1 425 936 9568
EMail: ybernet@msn.com
Steven Blake Ericsson 920 Main Campus Drive, Suite 500 Raleigh, NC 27606
史蒂文·布莱克·爱立信美国北卡罗来纳州罗利市主校区大道920号500室，邮编：27606
Phone: +1 919 472 9913
EMail: steven.blake@ericsson.com
Phone: +1 919 472 9913
EMail: steven.blake@ericsson.com
Daniel Grossman Motorola Inc. 20 Cabot Blvd. Mansfield, MA 02048
丹尼尔·格罗斯曼摩托罗拉公司，卡博特大道20号。马萨诸塞州曼斯菲尔德02048
Phone: +1 508 261 5312
EMail: dan@dma.isg.mot.com
Phone: +1 508 261 5312
EMail: dan@dma.isg.mot.com
Andrew Smith (editor) Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC
安德鲁·史密斯（编辑）中国北京西三环北路21号港湾网络九陵大厦，邮编：100089
Fax: +1 415 345 1827
EMail: ah_smith@acm.org
Fax: +1 415 345 1827
EMail: ah_smith@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。