Network Working Group J. Babiarz
Request for Comments: 4594 K. Chan
Category: Informational Nortel Networks
F. Baker
Cisco Systems
August 2006
Network Working Group J. Babiarz
Request for Comments: 4594 K. Chan
Category: Informational Nortel Networks
F. Baker
Cisco Systems
August 2006
Configuration Guidelines for DiffServ Service Classes
DiffServ服务类的配置指南
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
本文档描述了使用Diffserv配置的服务类，并建议如何使用它们以及如何使用区分服务代码点（DSCP）、流量调节器、每跳行为（PHB）和主动队列管理（AQM）机制来构造它们。特定的DSCP、流量调节器、PHB和AQM不需要用于特定的服务类别，但作为一种策略和互操作性，一致地应用它们是有用的。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Expected Use in the Network ................................4
1.3. Service Class Definition ...................................5
1.4. Key Differentiated Services Concepts .......................5
1.4.1. Queuing .............................................6
1.4.1.1. Priority Queuing ...........................6
1.4.1.2. Rate Queuing ...............................6
1.4.2. Active Queue Management .............................7
1.4.3. Traffic Conditioning ................................7
1.4.4. Differentiated Services Code Point (DSCP) ...........8
1.4.5. Per-Hop Behavior (PHB) ..............................8
1.5. Key Service Concepts .......................................8
1.5.1. Default Forwarding (DF) .............................9
1.5.2. Assured Forwarding (AF) .............................9
1.5.3. Expedited Forwarding (EF) ..........................10
1.5.4. Class Selector (CS) ................................10
1.5.5. Admission Control ..................................11
2. Service Differentiation ........................................11
2.1. Service Classes ...........................................12
2.2. Categorization of User Service Classes ....................13
2.3. Service Class Characteristics .............................16
2.4. Deployment Scenarios ......................................21
2.4.1. Example 1 ..........................................21
2.4.2. Example 2 ..........................................23
2.4.3. Example 3 ..........................................25
3. Network Control Traffic ........................................27
3.1. Current Practice in the Internet ..........................27
3.2. Network Control Service Class .............................27
3.3. OAM Service Class .........................................29
4. User Traffic ...................................................30
4.1. Telephony Service Class ...................................31
4.2. Signaling Service Class ...................................33
4.3. Multimedia Conferencing Service Class .....................35
4.4. Real-Time Interactive Service Class .......................37
4.5. Multimedia Streaming Service Class ........................39
4.6. Broadcast Video Service Class .............................41
4.7. Low-Latency Data Service Class ............................43
4.8. High-Throughput Data Service Class ........................45
4.9. Standard Service Class ....................................47
4.10. Low-Priority Data ........................................48
5. Additional Information on Service Class Usage ..................49
5.1. Mapping for Signaling .....................................49
5.2. Mapping for NTP ...........................................50
5.3. VPN Service Mapping .......................................50
6. Security Considerations ........................................51
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Expected Use in the Network ................................4
1.3. Service Class Definition ...................................5
1.4. Key Differentiated Services Concepts .......................5
1.4.1. Queuing .............................................6
1.4.1.1. Priority Queuing ...........................6
1.4.1.2. Rate Queuing ...............................6
1.4.2. Active Queue Management .............................7
1.4.3. Traffic Conditioning ................................7
1.4.4. Differentiated Services Code Point (DSCP) ...........8
1.4.5. Per-Hop Behavior (PHB) ..............................8
1.5. Key Service Concepts .......................................8
1.5.1. Default Forwarding (DF) .............................9
1.5.2. Assured Forwarding (AF) .............................9
1.5.3. Expedited Forwarding (EF) ..........................10
1.5.4. Class Selector (CS) ................................10
1.5.5. Admission Control ..................................11
2. Service Differentiation ........................................11
2.1. Service Classes ...........................................12
2.2. Categorization of User Service Classes ....................13
2.3. Service Class Characteristics .............................16
2.4. Deployment Scenarios ......................................21
2.4.1. Example 1 ..........................................21
2.4.2. Example 2 ..........................................23
2.4.3. Example 3 ..........................................25
3. Network Control Traffic ........................................27
3.1. Current Practice in the Internet ..........................27
3.2. Network Control Service Class .............................27
3.3. OAM Service Class .........................................29
4. User Traffic ...................................................30
4.1. Telephony Service Class ...................................31
4.2. Signaling Service Class ...................................33
4.3. Multimedia Conferencing Service Class .....................35
4.4. Real-Time Interactive Service Class .......................37
4.5. Multimedia Streaming Service Class ........................39
4.6. Broadcast Video Service Class .............................41
4.7. Low-Latency Data Service Class ............................43
4.8. High-Throughput Data Service Class ........................45
4.9. Standard Service Class ....................................47
4.10. Low-Priority Data ........................................48
5. Additional Information on Service Class Usage ..................49
5.1. Mapping for Signaling .....................................49
5.2. Mapping for NTP ...........................................50
5.3. VPN Service Mapping .......................................50
6. Security Considerations ........................................51
7. Acknowledgements ...............................................52
8. Appendix A .....................................................53
8.1. Explanation of Ring Clipping ..............................53
9. References .....................................................54
9.1. Normative References ......................................54
9.2. Informative References ....................................55
7. Acknowledgements ...............................................52
8. Appendix A .....................................................53
8.1. Explanation of Ring Clipping ..............................53
9. References .....................................................54
9.1. Normative References ......................................54
9.2. Informative References ....................................55
To aid in understanding the role of this document, we use an analogy: the Differentiated Services specifications are fundamentally a toolkit. The specifications provide the equivalent of band saws, planers, drill presses, and other tools. In the hands of an expert, there is no limit to what can be built, but such a toolkit can be intimidating to the point of being inaccessible to a non-expert who just wants to build a bookcase. This document should be viewed as a set of "project plans" for building all the (diffserv) furniture that one might want. The user may choose what to build (e.g., perhaps our non-expert doesn't need a china cabinet right now), and how to go about building it (e.g., plans for a non-expert probably won't employ mortise/tenon construction, but that absence does not imply that mortise/tenon construction is forbidden or unsound). The authors hope that these diffserv "project plans" will provide a useful guide to Network Administrators in the use of diffserv techniques to implement quality-of-service measures appropriate for their network's traffic.
为了帮助理解本文档的作用，我们使用了一个类比：区分服务规范基本上是一个工具包。规范提供了与带锯、刨床、钻床和其他工具相当的工具。在专家手中，可以构建的内容没有限制，但这样的工具包可能会让那些只想构建书架的非专家望而却步。本文档应被视为一套“项目计划”，用于构建您可能需要的所有（diffserv）家具。用户可以选择建造什么（例如，可能我们的非专家现在不需要瓷器柜），以及如何建造它（例如，非专家的计划可能不会采用榫卯结构，但不使用榫卯结构并不意味着禁止或不合理）。作者希望这些diffserv“项目计划”将为网络管理员提供一个有用的指南，帮助他们使用diffserv技术来实施适合其网络流量的服务质量措施。
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
本文档描述了使用Diffserv配置的服务类，并建议如何使用它们以及如何使用区分服务代码点（DSCP）、流量调节器、每跳行为（PHB）和主动队列管理（AQM）机制来构造它们。特定的DSCP、流量调节器、PHB和AQM不需要用于特定的服务类别，但作为一种策略和互操作性，一致地应用它们是有用的。
Service class definitions are based on the different traffic characteristics and required performance of the applications/services. This approach allows us to map current and future applications/services of similar traffic characteristics and performance requirements into the same service class. Since the applications'/services' characteristics and required performance are end to end, the service class notion needs to be preserved end to end. With this approach, a limited set of service classes is required. For completeness, we have defined twelve different service classes, two for network operation/administration and ten for user/subscriber applications/services. However, we expect that network administrators will implement a subset of these classes
服务类定义基于应用程序/服务的不同流量特征和所需性能。这种方法允许我们将具有类似流量特征和性能要求的当前和未来应用程序/服务映射到相同的服务类别中。由于应用程序/服务的特性和所需的性能是端到端的，因此需要端到端地保留服务类的概念。使用这种方法，需要一组有限的服务类。为了完整起见，我们定义了12个不同的服务类，其中两个用于网络操作/管理，十个用于用户/订户应用程序/服务。但是，我们希望网络管理员将实现这些类的一个子集
relevant to their customers and their service offerings. Network Administrators may also find it of value to add locally defined service classes, although these will not necessarily enjoy end-to-end properties of the same type.
与客户及其服务相关。网络管理员还可能发现添加本地定义的服务类很有价值，尽管这些服务类不一定享受相同类型的端到端属性。
Section 1 provides an introduction and overview of technologies that are used for service differentiation in IP networks. Section 2 is an overview of how service classes are constructed to provide service differentiation, with examples of deployment scenarios. Section 3 provides configuration guidelines of service classes that are used for stable operation and administration of the network. Section 4 provides configuration guidelines of service classes that are used for differentiation of user/subscriber traffic. Section 5 provides additional guidance on mapping different applications/protocols to service classes. Section 6 addresses security considerations.
第1节介绍并概述了IP网络中用于服务差异化的技术。第2节概述了如何构造服务类以提供服务差异化，并给出了部署场景的示例。第3节提供了用于网络稳定运行和管理的服务类的配置指南。第4节提供了用于区分用户/订户流量的服务类的配置指南。第5节提供了关于将不同的应用程序/协议映射到服务类的附加指导。第6节涉及安全考虑。
The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“应”、“不应”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In the Internet today, corporate LANs and ISP WANs are generally not heavily utilized. They are commonly 10% utilized at most. For this reason, congestion, loss, and variation in delay within corporate LANs and ISP backbones is virtually unknown. This clashes with user perceptions, for three very good reasons.
在当今的互联网中，企业局域网和ISP广域网通常没有得到充分利用。它们通常最多使用10%。因此，公司局域网和ISP主干网中的拥塞、丢失和延迟变化几乎是未知的。这与用户的看法有冲突，原因有三个。
o The industry moves through cycles of bandwidth boom and bandwidth bust, depending on prevailing market conditions and the periodic deployment of new bandwidth-hungry applications. o In access networks, the state is often different. This may be because throughput rates are artificially limited or over-subscribed, or because of access network design trade-offs. o Other characteristics, such as database design on web servers (that may create contention points, e.g., in filestore) and configuration of firewalls and routers, often look externally like a bandwidth limitation.
o 该行业经历了带宽繁荣和带宽萧条的周期，这取决于当前的市场条件和新的带宽饥渴型应用程序的周期性部署。o在接入网络中，状态往往不同。这可能是因为吞吐量被人为限制或超额订阅，或者是因为接入网络设计的权衡。o其他特性，例如web服务器上的数据库设计（可能会在文件存储中创建争用点）以及防火墙和路由器的配置，从外观上看通常像是带宽限制。
The intent of this document is to provide a consistent marking, conditioning, and packet treatment strategy so that it can be configured and put into service on any link that is itself congested.
本文件的目的是提供一致的标记、调节和数据包处理策略，以便在任何自身拥塞的链路上配置和投入使用。
A "service class" represents a set of traffic that requires specific delay, loss, and jitter characteristics from the network. Conceptually, a service class pertains to applications with similar characteristics and performance requirements, such as a "High-Throughput Data" service class for applications like the web and electronic mail, or a "Telephony" service class for real-time traffic such as voice and other telephony services. Such a service class may be defined locally in a Differentiated Services (DS) domain, or across multiple DS domains, possibly extending end to end.
“服务类别”表示一组需要网络特定延迟、损耗和抖动特性的流量。从概念上讲，服务类适用于具有类似特征和性能要求的应用程序，例如用于web和电子邮件等应用程序的“高吞吐量数据”服务类，或者用于实时通信（例如语音和其他电话服务）的“电话”服务类。这种服务类可以在区分服务（DS）域中本地定义，或者跨多个DS域定义，可能扩展到端到端。
A service class as defined here is essentially a statement of the required characteristics of a traffic aggregate. The required characteristics of these traffic aggregates can be realized by the use of defined per-hop behavior (PHB) [RFC2474]. The actual specification of the expected treatment of a traffic aggregate within a domain may also be defined as a per-domain behavior (PDB) [RFC3086].
这里定义的服务类本质上是对流量聚合所需特性的声明。通过使用定义的每跳行为（PHB）[RFC2474]，可以实现这些流量聚合所需的特性。域内流量聚合的预期处理的实际规范也可定义为每域行为（PDB）[RFC3086]。
Each domain may choose to implement different service classes or to use different behaviors to implement the service classes or to aggregate different kinds of traffic into the aggregates and still achieve their required characteristics. For example, low delay, loss, and jitter may be realized using the EF PHB, or with an over-provisioned AF PHB. This must be done with care as it may disrupt the end-to-end performance required by the applications/services. This document provides recommendations on usage of PHBs for specific service classes for their consistent implementation. These recommendations are not to be construed as prohibiting use of other PHBs that realize behaviors sufficient for the relevant class of traffic.
每个域可以选择实现不同的服务类，或者使用不同的行为来实现服务类，或者将不同类型的流量聚合到聚合中，并仍然实现其所需的特性。例如，可以使用EF PHB或者使用过度配置的AF PHB来实现低延迟、损耗和抖动。必须小心操作，因为这可能会破坏应用程序/服务所需的端到端性能。本文档提供了针对特定服务类使用PHB以实现其一致性的建议。这些建议不应被解释为禁止使用其他PHB，这些PHB实现的行为足以满足相关类别的流量。
The Default Forwarding "Standard" service class is REQUIRED; all other service classes are OPTIONAL. It is expected that network administrators will base their choice of the level of service differentiation that they will support on their need, starting off with three or four service classes for user traffic and adding others as the need arises.
需要默认的转发“标准”服务类；所有其他服务类都是可选的。预计网络管理员将根据自己的需要选择他们将支持的服务差异化级别，首先为用户流量选择三到四个服务类，然后根据需要添加其他服务类。
The reader SHOULD be familiar with the principles of the Differentiated Services Architecture [RFC2474]. We recapitulate key concepts here only to provide convenience for the reader, the referenced RFCs providing the authoritative definitions.
读者应该熟悉区分服务体系结构的原理[RFC2474]。我们在这里重述关键概念只是为了方便读者，参考的RFC提供了权威的定义。
A queue is a data structure that holds packets that are awaiting transmission. The packets may be delayed while in the queue, possibly due to lack of bandwidth, or because it is low in priority. There are a number of ways to implement a queue. A simple model of a queuing system, however, is a set of data structures for packet data, which we will call queues, and a mechanism for selecting the next packet from among them, which we call a scheduler.
队列是保存等待传输的数据包的数据结构。数据包在队列中时可能会延迟，这可能是由于带宽不足或优先级低。有许多方法可以实现队列。然而，排队系统的一个简单模型是一组数据包数据的数据结构，我们称之为队列，以及一种从中选择下一个数据包的机制，我们称之为调度器。
A priority queuing system is a combination of a set of queues and a scheduler that empties them in priority sequence. When asked for a packet, the scheduler inspects the highest priority queue and, if there is data present, returns a packet from that queue. Failing that, it inspects the next highest priority queue, and so on. A freeway onramp with a stoplight for one lane that allows vehicles in the high-occupancy-vehicle lane to pass is an example of a priority queuing system; the high-occupancy-vehicle lane represents the "queue" having priority.
优先级队列系统是一组队列和按优先级顺序清空队列的调度程序的组合。当请求数据包时，调度器检查最高优先级队列，如果存在数据，则从该队列返回数据包。否则，它将检查下一个优先级最高的队列，以此类推。优先排队系统的一个例子是高速公路入口匝道，其中一条车道有一个停车灯，允许高占用车道上的车辆通过；高占用率车道表示具有优先权的“队列”。
In a priority queuing system, a packet in the highest priority queue will experience a readily calculated delay. This is proportional to the amount of data remaining to be serialized when the packet arrived plus the volume of the data already queued ahead of it in the same queue. The technical reason for using a priority queue relates exactly to this fact: it limits delay and variations in delay and should be used for traffic that has that requirement.
在优先级排队系统中，最高优先级队列中的数据包将经历一个容易计算的延迟。这与数据包到达时要序列化的剩余数据量加上在同一队列中已在其前面排队的数据量成正比。使用优先级队列的技术原因与此事实完全相关：它限制延迟和延迟的变化，并且应该用于具有此要求的流量。
A priority queue or queuing system needs to avoid starvation of lower-priority queues. This may be achieved through a variety of means, such as admission control, rate control, or network engineering.
优先级队列或排队系统需要避免低优先级队列的饥饿。这可以通过各种方式实现，例如接纳控制、速率控制或网络工程。
Similarly, a rate-based queuing system is a combination of a set of queues and a scheduler that empties each at a specified rate. An example of a rate-based queuing system is a road intersection with a stoplight. The stoplight acts as a scheduler, giving each lane a certain opportunity to pass traffic through the intersection.
类似地，基于速率的排队系统是一组队列和调度程序的组合，调度程序以指定速率清空每个队列。基于费率的排队系统的一个例子是带有红绿灯的道路交叉口。红绿灯充当调度器，为每条车道提供一定的机会让车辆通过交叉口。
In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) or Weighted Round Robin (WRR), the delay that a packet in any given queue will experience depends on the parameters and occupancy of its queue and the parameters and occupancy of the queues it is competing with. A queue whose traffic arrival rate is much less than the rate
在基于速率的排队系统中，如加权公平排队（WFQ）或加权循环（WRR），任何给定队列中的数据包将经历的延迟取决于其队列的参数和占用率以及与其竞争的队列的参数和占用率。一种队列，其流量到达率远小于到达率
at which it lets traffic depart will tend to be empty, and packets in it will experience nominal delays. A queue whose traffic arrival rate approximates or exceeds its departure rate will tend not to be empty, and packets in it will experience greater delay. Such a scheduler can impose a minimum rate, a maximum rate, or both, on any queue it touches.
当它允许流量离开时，数据包往往是空的，其中的数据包将经历名义上的延迟。流量到达率接近或超过其离开率的队列将不会为空，其中的数据包将经历更大的延迟。这样的调度器可以对其接触的任何队列施加最小速率、最大速率或两者。
Active Queue Management, or AQM, is a generic name for any of a variety of procedures that use packet dropping or marking to manage the depth of a queue. The canonical example of such a procedure is Random Early Detection (RED), in that a queue is assigned a minimum and maximum threshold, and the queuing algorithm maintains a moving average of the queue depth. While the mean queue depth exceeds the maximum threshold, all arriving traffic is dropped. While the mean queue depth exceeds the minimum threshold but not the maximum threshold, a randomly selected subset of arriving traffic is marked or dropped. This marking or dropping of traffic is intended to communicate with the sending system, causing its congestion avoidance algorithms to kick in. As a result of this behavior, it is reasonable to expect that TCP's cyclic behavior is desynchronized and that the mean queue depth (and therefore delay) should normally approximate the minimum threshold.
主动队列管理，或AQM，是使用数据包丢弃或标记来管理队列深度的各种过程的通用名称。这种过程的典型示例是随机早期检测（RED），即为队列分配最小和最大阈值，队列算法保持队列深度的移动平均值。当平均队列深度超过最大阈值时，将丢弃所有到达的流量。当平均队列深度超过最小阈值而不是最大阈值时，将标记或丢弃随机选择的到达流量子集。这种标记或丢弃流量的目的是与发送系统通信，导致其拥塞避免算法生效。由于这种行为，可以合理地预期TCP的循环行为是不同步的，并且平均队列深度（因此延迟）通常应接近最小阈值。
A variation of the algorithm is applied in Assured Forwarding PHB [RFC2597], in that the behavior aggregate consists of traffic with multiple DSCP marks, which are intermingled in a common queue. Different minima and maxima are configured for the several DSCPs separately, such that traffic that exceeds a stated rate at ingress is more likely to be dropped or marked than traffic that is within its contracted rate.
该算法的一个变体应用于有保证转发PHB[RFC2597]，因为行为聚合由具有多个DSCP标记的流量组成，这些流量混合在一个公共队列中。为多个DSCP分别配置了不同的最小值和最大值，使得在入口超过规定速率的流量比在其约定速率内的流量更有可能被丢弃或标记。
In addition, at the first router in a network that a packet crosses, arriving traffic may be measured and dropped or marked according to a policy, or perhaps shaped on network ingress, as in "A Rate Adaptive Shaper for Differentiated Services" [RFC2963]. This may be used to bias feedback loops, as is done in "Assured Forwarding PHB" [RFC2597], or to limit the amount of traffic in a system, as is done in "Expedited Forwarding PHB" [RFC3246]. Such measurement procedures are collectively referred to as "traffic conditioners". Traffic conditioners are normally built using token bucket meters, for example with a committed rate and burst size, as in Section 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB [RFC2597] uses a variation on a meter with multiple rate and burst size measurements to test and identify multiple levels of conformance.
此外，在分组穿过的网络中的第一路由器处，可以根据策略来测量和丢弃或标记到达的流量，或者可以根据网络入口来成形，如“用于区分服务的速率自适应成形器”[RFC2963]。这可用于偏置反馈回路，如“有保证的转发PHB”[RFC2597]中所述，或用于限制系统中的通信量，如“快速转发PHB”[RFC3246]中所述。此类测量程序统称为“交通调节器”。流量调节器通常使用令牌桶计量器构建，例如具有提交速率和突发大小，如DiffServ模型[RFC3290]第1.5.3节所述。有保证转发PHB[RFC2597]使用具有多个速率和突发大小测量的仪表上的变化来测试和识别多个一致性级别。
Multiple rates and burst sizes can be realized using multiple levels of token buckets or more complex token buckets; these are implementation details. The following are some traffic conditioners that may be used in deployment of differentiated services:
可以使用多级令牌桶或更复杂的令牌桶实现多速率和突发大小；这些是实施细节。以下是一些可用于部署差异化服务的流量调节器：
o For Class Selector (CS) PHBs, a single token bucket meter to provide a rate plus burst size control. o For Expedited Forwarding (EF) PHB, a single token bucket meter to provide a rate plus burst size control. o For Assured Forwarding (AF) PHBs, usually two token bucket meters configured to provide behavior as outlined in "Two Rate Three Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is used to enforce two rates, whereas the single-rate, three-color marker is used to enforce a committed rate with two burst lengths.
o 对于类选择器（CS）PHB，一种单令牌桶计，用于提供速率加突发大小控制。o对于快速转发（EF）PHB，单令牌桶计提供速率加突发大小控制。o对于保证转发（AF）PHB，通常配置两个令牌桶计量器，以提供“双速率三色标记（trTCM）”[RFC2698]或“单速率三色标记（srTCM）”[RFC2697]中概述的行为。双速率三色标记用于强制执行两个速率，而单速率三色标记用于强制执行具有两个突发长度的提交速率。
The DSCP is a number in the range 0..63 that is placed into an IP packet to mark it according to the class of traffic it belongs in. Half of these values are earmarked for standardized services, and the other half of them are available for local definition.
DSCP是一个范围为0..63的数字，放入IP数据包中，根据其所属的通信量类别对其进行标记。这些值中的一半指定用于标准化服务，另一半可用于本地定义。
In the end, the mechanisms described above are combined to form a specified set of characteristics for handling different kinds of traffic, depending on the needs of the application. This document seeks to identify useful traffic aggregates and to specify what PHB should be applied to them.
最后，根据应用的需要，组合上述机制以形成用于处理不同类型的业务的指定特征集。本文件旨在确定有用的交通总量，并规定应采用何种PHB。
While Differentiated Services is a general architecture that may be used to implement a variety of services, three fundamental forwarding behaviors have been defined and characterized for general use. These are basic Default Forwarding (DF) behavior for elastic traffic, the Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF) behavior for real-time (inelastic) traffic. The facts that four code points are recommended for AF and that one code point is recommended for EF are arbitrary choices, and the architecture allows any reasonable number of AF and EF classes simultaneously. The choice of four AF classes and one EF class in the current document is also arbitrary, and operators MAY choose to operate more or fewer of either.
虽然区分服务是一种可用于实现各种服务的通用体系结构，但已定义并描述了三种基本转发行为以供通用。这些是弹性流量的基本默认转发（DF）行为、保证转发（AF）行为和实时（非弹性）流量的加速转发（EF）行为。为AF推荐四个代码点，为EF推荐一个代码点，这是任意的选择，架构允许同时使用任意数量的AF和EF类。在当前文档中，四个AF类和一个EF类的选择也是任意的，操作员可以选择其中的更多或更少。
The terms "elastic" and "real-time" are defined in [RFC1633], Section 3.1, as a way of understanding broad-brush application requirements. This document should be reviewed to obtain a broad understanding of the issues in quality of service, just as [RFC2475] should be reviewed to understand the data plane architecture used in today's Internet.
术语“弹性”和“实时”在[RFC1633]第3.1节中定义，作为理解广泛应用要求的一种方式。应审查本文件以获得对服务质量问题的广泛理解，正如应审查[RFC2475]以了解当今互联网中使用的数据平面架构一样。
The basic forwarding behaviors applied to any class of traffic are those described in [RFC2474] and [RFC2309]. Best-effort service may be summarized as "I will accept your packets" and is typically configured with some bandwidth guarantee. Packets in transit may be lost, reordered, duplicated, or delayed at random. Generally, networks are engineered to limit this behavior, but changing traffic loads can push any network into such a state.
[RFC2474]和[RFC2309]中描述了应用于任何类别流量的基本转发行为。尽力而为服务可以概括为“我将接受您的数据包”，并且通常配置有一些带宽保证。传输中的数据包可能会丢失、重新排序、复制或随机延迟。一般来说，网络的设计是为了限制这种行为，但不断变化的流量负载会将任何网络推到这种状态。
Application traffic in the internet that uses default forwarding is expected to be "elastic" in nature. By this, we mean that the sender of traffic will adjust its transmission rate in response to changes in available rate, loss, or delay.
使用默认转发的internet中的应用程序流量本质上是“弹性”的。这意味着通信量的发送方将根据可用速率、丢失或延迟的变化调整其传输速率。
For the basic best-effort service, a single DSCP value is provided to identify the traffic, a queue to store it, and active queue management to protect the network from it and to limit delays.
对于基本的尽力而为服务，将提供单个DSCP值来标识流量、存储流量的队列以及主动队列管理来保护网络免受流量影响并限制延迟。
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss Priority (CLP) capability. It is intended for networks that offer average-rate Service Level Agreements (SLAs) (as FR and ATM networks do). This is an enhanced best-effort service; traffic is expected to be "elastic" in nature. The receiver will detect loss or variation in delay in the network and provide feedback such that the sender adjusts its transmission rate to approximate available capacity.
有保证的转发PHB[RFC2597]行为是根据帧中继的丢弃合格（DE）标志或ATM的信元丢失优先级（CLP）功能显式建模的。它适用于提供平均速率服务水平协议（SLA）的网络（如FR和ATM网络）。这是一种增强的尽力而为的服务；预计交通在本质上是“弹性”的。接收器将检测网络中的延迟丢失或变化，并提供反馈，以便发送者调整其传输速率以接近可用容量。
For such behaviors, multiple DSCP values are provided (two or three, perhaps more using local values) to identify the traffic, a common queue to store the aggregate, and active queue management to protect the network from it and to limit delays. Traffic is metered as it enters the network, and traffic is variously marked depending on the arrival rate of the aggregate. The premise is that it is normal for users occasionally to use more capacity than their contract stipulates, perhaps up to some bound. However, if traffic should be marked or lost to manage the queue, this excess traffic will be marked or lost first.
对于此类行为，提供了多个DSCP值（两个或三个，可能更多使用本地值）以识别流量、存储聚合的公共队列以及保护网络免受其影响并限制延迟的主动队列管理。流量在进入网络时进行计量，并根据聚合的到达率对流量进行不同的标记。前提是，用户偶尔会使用比合同规定的容量更多的容量，这是正常的，可能会达到一定的限制。但是，如果为了管理队列而应该标记或丢失通信量，那么将首先标记或丢失多余的通信量。
The intent of Expedited Forwarding PHB [RFC3246] is to provide a building block for low-loss, low-delay, and low-jitter services. It can be used to build an enhanced best-effort service: traffic remains subject to loss due to line errors and reordering during routing changes. However, using queuing techniques, the probability of delay or variation in delay is minimized. For this reason, it is generally used to carry voice and for transport of data information that requires "wire like" behavior through the IP network. Voice is an inelastic "real-time" application that sends packets at the rate the codec produces them, regardless of availability of capacity. As such, this service has the potential to disrupt or congest a network if not controlled. It also has the potential for abuse.
快速转发PHB[RFC3246]的目的是为低损耗、低延迟和低抖动服务提供构建块。它可以用于构建增强的尽力而为服务：在路由更改期间，由于线路错误和重新排序，流量仍然会受到损失。然而，使用排队技术，延迟或延迟变化的概率最小化。因此，它通常用于承载语音和传输需要通过IP网络进行“有线”行为的数据信息。语音是一种非弹性的“实时”应用程序，它以编解码器生成数据包的速率发送数据包，而不考虑容量的可用性。因此，如果不加以控制，此服务可能会中断或阻塞网络。它也有可能被滥用。
To protect the network, at minimum one SHOULD police traffic at various points to ensure that the design of a queue is not overrun, and then the traffic SHOULD be given a low-delay queue (often using priority, although it is asserted that a rate-based queue can do this) to ensure that variation in delay is not an issue, to meet application needs.
为了保护网络，至少应在各个点监控通信量，以确保队列的设计不会超限，然后应为通信量提供一个低延迟队列（通常使用优先级，尽管有人断言基于速率的队列可以做到这一点），以确保延迟的变化不是问题，以满足应用程序的需要。
Class Selector provides support for historical codepoint definitions and PHB requirement. The Class Selector DS field provides a limited backward compatibility with legacy (pre DiffServ) practice, as described in [RFC2474], Section 4. Backward compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queuing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant networks. In addition, there are some codepoints that correspond to historical use of the IP Precedence field, and we reserve these codepoints to map to PHBs that meet the general requirements specified in [RFC2474], Section 4.2.2.2.
类选择器支持历史代码点定义和PHB要求。如[RFC2474]第4节所述，类选择器DS字段提供了与传统（区分服务前）实践的有限向后兼容性。向后兼容性有两种解决方法。首先，每跳行为已经广泛使用（例如，那些满足[RFC1812]中规定的IPv4优先队列要求的行为），我们希望允许它们在符合DS的网络中继续使用。此外，还有一些代码点与IP优先字段的历史使用相对应，我们保留这些代码点以映射到符合[RFC2474]第4.2.2.2节规定的一般要求的PHB。
No attempt is made to maintain backward compatibility with the "DTR" or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in [RFC0791] and [RFC1349].
未尝试与[RFC0791]和[RFC1349]中定义的IPv4 TOS八位字节的“DTR”或服务类型（TOS）位保持向后兼容性。
A DS-compliant network can be deployed with a set of one or more Class Selector-compliant PHB groups. Also, a network administrator may configure the network nodes to map codepoints to PHBs, irrespective of bits 3-5 of the DSCP field, to yield a network that is compatible with historical IP Precedence use. Thus, for example, codepoint '011000' would map to the same PHB as codepoint '011010'.
与DS兼容的网络可以部署一组一个或多个与类选择器兼容的PHB组。此外，网络管理员可将网络节点配置为将码点映射到phb，而不考虑DSCP字段的比特3-5，以产生与历史IP优先使用兼容的网络。因此，例如，代码点“011000”将映射到与代码点“011010”相同的PHB。
Admission control (including refusal when policy thresholds are crossed) can ensure high-quality communication by ensuring the availability of bandwidth to carry a load. Inelastic real-time flows such as Voice over Internet Protocol (VoIP) (telephony) or video conferencing services can benefit from use of an admission control mechanism, as generally the telephony service is configured with over-subscription, meaning that some users may not be able to make a call during peak periods.
允许控制（包括超过策略阈值时的拒绝）可以通过确保承载负载的带宽可用性来确保高质量的通信。非弹性实时流，如互联网协议语音（VoIP）（电话）或视频会议服务，可受益于准入控制机制的使用，因为通常电话服务配置为过度订阅，这意味着一些用户可能无法在高峰时段拨打电话。
For VoIP (telephony) service, a common approach is to use signaling protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation Protocol (RSVP) to negotiate admittance and use of network transport capabilities. When a user has been authorized to send voice traffic, this admission procedure has verified that data rates will be within the capacity of the network that it will use. Many RTP voice payloads are inelastic and cannot react to loss or delay in any substantive way. For these voice payloads, the network SHOULD police at ingress to ensure that the voice traffic stays within its negotiated bounds. Having thus assured a predictable input rate, the network may use a priority queue to ensure nominal delay and variation in delay.
对于VoIP（电话）服务，一种常见的方法是使用信令协议，如SIP、H.323、H.248、MEGACO和资源预留协议（RSVP）来协商网络传输能力的准入和使用。当用户被授权发送语音通信时，此接纳过程已验证数据速率将在其将使用的网络容量范围内。许多RTP语音有效载荷是非弹性的，不能以任何实质性的方式对丢失或延迟作出反应。对于这些语音有效负载，网络应在入口进行监控，以确保语音流量保持在其协商的范围内。因此，在确保了可预测的输入速率之后，网络可以使用优先级队列来确保标称延迟和延迟的变化。
Another approach that may be used in small and bandwidth-constrained networks for limited number of flows is RSVP [RFC2205] [RFC2996]. However, there is concern with the scalability of this solution in large networks where aggregation of reservations [RFC3175] is considered to be required.
对于有限数量的流，可在带宽受限的小型网络中使用的另一种方法是RSVP[RFC2205][RFC2996]。但是，在大型网络中，该解决方案的可扩展性值得关注，因为在大型网络中，需要对预订[RFC3175]进行聚合。
There are practical limits on the level of service differentiation that should be offered in the IP networks. We believe we have defined a practical approach in delivering service differentiation by defining different service classes that networks may choose to support in order to provide the appropriate level of behaviors and performance needed by current and future applications and services. The defined structure for providing services allows several applications having similar traffic characteristics and performance requirements to be grouped into the same service class. This approach provides a lot of flexibility in providing the appropriate level of service differentiation for current and new, yet unknown applications without introducing significant changes to routers or network configurations when a new traffic type is added to the network.
IP网络中应提供的服务差异化水平存在实际限制。我们相信，通过定义网络可能选择支持的不同服务类别，我们已经定义了一种提供服务差异化的实用方法，以提供当前和未来应用程序和服务所需的适当级别的行为和性能。为提供服务而定义的结构允许将具有相似流量特征和性能要求的多个应用程序分组到同一服务类别中。这种方法提供了很大的灵活性，可以为当前和新的但未知的应用程序提供适当级别的服务差异，而不会在向网络添加新流量类型时对路由器或网络配置进行重大更改。
Traffic flowing in a network can be classified in many different ways. We have chosen to divide it into two groupings, network control and user/subscriber traffic. To provide service differentiation, different service classes are defined in each grouping. The network control traffic group can further be divided into two service classes (see Section 3 for detailed definition of each service class):
网络中的流量可以用许多不同的方式进行分类。我们选择将其分为两组，网络控制和用户/订户流量。为了提供服务差异化，在每个分组中定义了不同的服务类。网络控制流量组可进一步分为两个服务类别（每个服务类别的详细定义见第3节）：
o "Network Control" for routing and network control function. o "OAM" (Operations, Administration, and Management) for network configuration and management functions.
o “网络控制”用于路由和网络控制功能。o用于网络配置和管理功能的“OAM”（操作、管理和管理）。
The user/subscriber traffic group is broken down into ten service classes to provide service differentiation for all the different types of applications/services (see Section 4 for detailed definition of each service class):
用户/订户流量组分为十个服务类别，为所有不同类型的应用程序/服务提供不同的服务（每个服务类别的详细定义见第4节）：
o Telephony service class is best suited for applications that require very low delay variation and are of constant rate, such as IP telephony (VoIP) and circuit emulation over IP applications. o Signaling service class is best suited for peer-to-peer and client-server signaling and control functions using protocols such as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol (MGCP). o Multimedia Conferencing service class is best suited for applications that require very low delay and have the ability to change encoding rate (rate adaptive), such as H.323/V2 and later video conferencing service. o Real-Time Interactive service class is intended for interactive variable rate inelastic applications that require low jitter and loss and very low delay, such as interactive gaming applications that use RTP/UDP streams for game control commands, and video conferencing applications that do not have the ability to change encoding rates or to mark packets with different importance indications. o Multimedia Streaming service class is best suited for variable rate elastic streaming media applications where a human is waiting for output and where the application has the capability to react to packet loss by reducing its transmission rate, such as streaming video and audio and webcast. o Broadcast Video service class is best suited for inelastic streaming media applications that may be of constant or variable rate, requiring low jitter and very low packet loss, such as broadcast TV and live events, video surveillance, and security.
o 电话服务类别最适合于需要极低延迟变化且速率恒定的应用，如IP电话（VoIP）和IP电路仿真应用。o信令服务类最适合使用诸如SIP、SIP-T、H.323、H.248和媒体网关控制协议（MGCP）等协议的对等和客户端服务器信令和控制功能。o多媒体会议服务类最适合于需要极低延迟且能够更改编码速率（速率自适应）的应用程序，如H.323/V2和更高版本的视频会议服务。o Real-Time Interactive service class适用于要求低抖动、低损耗和极低延迟的交互式可变速率非弹性应用程序，例如使用RTP/UDP流执行游戏控制命令的交互式游戏应用程序，以及视频会议应用程序，这些应用程序无法更改编码速率或标记具有不同重要性指示的数据包。o多媒体流媒体服务类最适合于可变速率弹性流媒体应用，其中人正在等待输出，并且应用程序能够通过降低传输速率对数据包丢失做出反应，例如流视频和音频以及网络广播。o广播视频服务类最适合于非弹性流媒体应用，这些应用可能是恒定或可变速率的，需要低抖动和极低的数据包丢失，如广播电视和现场活动、视频监控和安全。
o Low-Latency Data service class is best suited for data processing applications where a human is waiting for output, such as web-based ordering or an Enterprise Resource Planning (ERP) application. o High-Throughput Data service class is best suited for store and forward applications such as FTP and billing record transfer. o Standard service class is for traffic that has not been identified as requiring differentiated treatment and is normally referred to as best effort. o Low-Priority Data service class is intended for packet flows where bandwidth assurance is not required.
o 低延迟数据服务类最适合于人员等待输出的数据处理应用程序，如基于web的订购或企业资源规划（ERP）应用程序。o高通量数据服务类最适合于存储和转发应用程序，如FTP和计费记录传输。o标准服务等级适用于未被确定为需要区别对待的交通，通常称为“尽力而为”。o低优先级数据服务类别适用于不需要带宽保证的数据包流。
The ten defined user/subscriber service classes listed above can be grouped into a small number of application categories. For some application categories, it was felt that more than one service class was needed to provide service differentiation within that category due to the different traffic characteristic of the applications, control function, and the required flow behavior. Figure 1 provides a summary of service class grouping into four application categories.
上面列出的十个已定义的用户/订户服务类别可以分为少数应用程序类别。对于某些应用类别，由于应用程序的不同流量特性、控制功能和所需的流量行为，人们认为需要不止一个服务类别来提供该类别内的服务差异。图1提供了服务类分组为四个应用程序类别的摘要。
Application Control Category
应用程序控制类别
o The Signaling service class is intended to be used to control applications or user endpoints. Examples of protocols that would use this service class are SIP or H.248 for IP telephone service and SIP or Internet Group Management Protocol (IGMP) for control of broadcast TV service to subscribers. Although user signaling flows have similar performance requirements as Low-Latency Data, they need to be distinguished and marked with a different DSCP. The essential distinction is something like "administrative control and management" of the traffic affected as the protocols in this class tend to be tied to the media stream/session they signal and control.
o 信令服务类用于控制应用程序或用户端点。将使用此服务类别的协议的示例包括用于IP电话服务的SIP或H.248以及用于控制向用户提供的广播电视服务的SIP或互联网组管理协议（IGMP）。尽管用户信令流具有与低延迟数据相似的性能要求，但它们需要区分并用不同的DSCP进行标记。本质上的区别类似于受影响流量的“管理控制和管理”，因为此类协议往往与它们发送信号和控制的媒体流/会话相关联。
Media-Oriented Category
媒体导向范畴
Due to the vast number of new (in process of being deployed) and already-in-use media-oriented services in IP networks, five service classes have been defined.
由于IP网络中有大量新的（正在部署中）和已在使用的面向媒体的服务，因此定义了五个服务类别。
o Telephony service class is intended for IP telephony (VoIP) service. It may also be used for other applications that meet the defined traffic characteristics and performance requirements. o Real-Time Interactive service class is intended for inelastic video flows from applications such as SIP-based desktop video conferencing applications and for interactive gaming.
o 电话服务类用于IP电话（VoIP）服务。它也可用于满足规定流量特性和性能要求的其他应用。o实时交互服务类用于来自诸如基于SIP的桌面视频会议应用程序和交互式游戏等应用程序的非弹性视频流。
o Multimedia Conferencing service class is for video conferencing solutions that have the ability to reduce their transmission rate on detection of congestion. These flows can therefore be classified as rate adaptive. As currently two types of video conferencing equipment are used in IP networks (ones that generate inelastic traffic and ones that generate rate-adaptive traffic), two service class are needed. The Real-Time Interactive service class should be used for equipment that generates inelastic video flows and the Multimedia Conferencing service class for equipment that generates rate-adaptive video flows. o Broadcast Video service class is to be used for inelastic traffic flows, which are intended for broadcast TV service and for transport of live video and audio events. o Multimedia Streaming service class is to be used for elastic multimedia traffic flows. This multimedia content is typically stored before being transmitted. It is also buffered at the receiving end before being played out. The buffering is sufficiently large to accommodate any variation in transmission rate that is encountered in the network. Multimedia entertainment over IP delivery services that are being developed can generate both elastic and inelastic traffic flows; therefore, two service classes are defined to address this space, respectively: Multimedia Streaming and Broadcast Video.
o 多媒体会议服务类用于视频会议解决方案，这些解决方案能够在检测到拥塞时降低传输速率。因此，这些流量可归类为速率自适应。由于目前在IP网络中使用两种类型的视频会议设备（产生非弹性流量的设备和产生速率自适应流量的设备），因此需要两种服务级别。实时交互服务类应用于生成非弹性视频流的设备，多媒体会议服务类应用于生成速率自适应视频流的设备。o广播视频服务等级用于非弹性交通流，用于广播电视服务和现场视频和音频活动的传输。o多媒体流服务类用于弹性多媒体流量。此多媒体内容通常在传输之前存储。在播放之前，它还在接收端进行缓冲。缓冲区足够大，以适应网络中遇到的传输速率的任何变化。正在开发的IP多媒体娱乐交付服务可以产生弹性和非弹性流量；因此，定义了两个服务类来处理这个空间：多媒体流和广播视频。
Data Category
数据类别
The data category is divided into three service classes.
数据类别分为三个服务类别。
o Low-Latency Data for applications/services that require low delay or latency for bursty but short-lived flows. o High-Throughput Data for applications/services that require good throughput for long-lived bursty flows. High Throughput and Multimedia Steaming are close in their traffic flow characteristics with High Throughput being a bit more bursty and not as long-lived as Multimedia Streaming. o Low-Priority Data for applications or services that can tolerate short or long interruptions of packet flows. The Low-Priority Data service class can be viewed as "don't care" to some degree.
o 低延迟数据，用于需要低延迟的应用程序/服务，或用于突发但短暂的流的低延迟。o针对需要高吞吐量的应用程序/服务的高吞吐量数据，以实现长寿命的突发流。高吞吐量和多媒体流传输在流量特性上非常接近，高吞吐量更具突发性，不像多媒体流传输那样持久。o可容忍短时间或长时间分组流中断的应用程序或服务的低优先级数据。低优先级数据服务类在某种程度上可以被视为“不在乎”。
Best-Effort Category
尽力类别
o All traffic that is not differentiated in the network falls into this category and is mapped into the Standard service class. If a packet is marked with a DSCP value that is not supported in the network, it SHOULD be forwarded using the Standard service class.
o 网络中未区分的所有流量都属于此类别，并映射到标准服务类别中。如果数据包标记有网络不支持的DSCP值，则应使用标准服务类转发该数据包。
Figure 1, below, provides a grouping of the defined user/subscriber service classes into four categories, with indications of which ones use an independent flow for signaling or control; type of flow behavior (elastic, rate adaptive, or inelastic); and the last column provides end user Quality of Service (QoS) rating as defined in ITU-T Recommendation G.1010.
下面的图1将定义的用户/订户服务类别分为四个类别，并指出哪些类别使用独立的流来进行信令或控制；流动行为类型（弹性、速率自适应或非弹性）；最后一列提供了ITU-T建议G.1010中定义的最终用户服务质量（QoS）评级。
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | Signaling | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data |High-Throughput| No | Elastic | Timely |
| | Data | | | |
| |---------------+----------+-----------+------------|
| | Low-Priority | No | Elastic |Non-critical|
| | Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | Signaling | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data |High-Throughput| No | Elastic | Timely |
| | Data | | | |
| |---------------+----------+-----------+------------|
| | Low-Priority | No | Elastic |Non-critical|
| | Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------
Figure 1. User/Subscriber Service Classes Grouping
图1。用户/订户服务类分组
Here is a short explanation of the end user QoS category as defined in ITU-T Recommendation G.1010. User traffic is divided into four different categories, namely, interactive, responsive, timely, and non-critical. An example of interactive traffic is between two humans and is most sensitive to delay, loss, and jitter. Another example of interactive traffic is between two servers where very low delay and loss are needed. Responsive traffic is typically between a human and a server but can also be between two servers. Responsive traffic is less affected by jitter and can tolerate longer delays than interactive traffic. Timely traffic is either between servers or servers and humans and the delay tolerance is significantly longer than responsive traffic. Non-critical traffic is normally between servers/machines where delivery may be delay for period of time.
以下是ITU-T建议G.1010中定义的最终用户QoS类别的简要说明。用户流量分为四个不同的类别，即交互、响应、及时和非关键。交互流量的一个例子是在两个人之间，对延迟、丢失和抖动最敏感。交互流量的另一个例子是两台服务器之间的交互流量，需要非常低的延迟和损失。响应流量通常在人员和服务器之间，也可以在两台服务器之间。响应流量受抖动的影响较小，并且比交互流量能够承受更长的延迟。及时的流量在服务器之间或服务器与人之间，延迟容忍度明显长于响应流量。非关键流量通常在服务器/机器之间，交付可能会延迟一段时间。
This document provides guidelines for network administrators in configuring their network for the level of service differentiation that is appropriate in their network to meet their QoS needs. It is expected that network operators will configure and provide in their networks a subset of the defined service classes. Our intent is to provide guidelines for configuration of Differentiated Services for a wide variety of applications, services, and network configurations. In addition, network administrators may choose to define and deploy other service classes in their network.
本文档为网络管理员提供了配置其网络的指导原则，以使其网络中的服务差异化级别能够满足其QoS需求。预计网络运营商将在其网络中配置并提供已定义服务类别的子集。我们的目的是为各种应用程序、服务和网络配置的差异化服务的配置提供指导。此外，网络管理员可以选择在其网络中定义和部署其他服务类。
Figure 2 provides a behavior view for traffic serviced by each service class. The traffic characteristics column defines the characteristics and profile of flows serviced, and the tolerance to loss, delay, and jitter columns define the treatment the flows will receive. End-to-end quantitative performance requirements may be obtained from ITU-T Recommendations Y.1541 and Y.1540.
图2提供了由每个服务类提供服务的流量的行为视图。“流量特性”列定义了所服务流的特性和配置文件，而“损失、延迟和抖动容差”列定义了流将接受的处理。端到端定量性能要求可从ITU-T建议Y.1541和Y.1540中获得。
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------|
| | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low-rate flows | | | |
|---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | Yes |
| | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| Yes |
| Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------|
| Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long- | Low |Medium| Yes |
| Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | |
-------------------------------------------------------------------
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------|
| | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low-rate flows | | | |
|---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | Yes |
| | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| Yes |
| Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------|
| Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long- | Low |Medium| Yes |
| Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | |
-------------------------------------------------------------------
Figure 2. Service Class Characteristics
图2。服务等级特征
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies that data is buffered in the endpoint and that a moderate level of network-induced variation in delay will not affect the application. Applications that use TCP as a transport are generally good examples. Routing protocols and peer-to-peer signaling also fall in this class; although loss can create problems in setting up calls, a moderate level of jitter merely makes call placement a little less predictable in duration.
图2的注释：抖动容忍列中的“是”表示数据在端点中缓冲，网络引起的适度延迟变化不会影响应用程序。使用TCP作为传输的应用程序通常是很好的例子。路由协议和对等信令也属于这一类；虽然丢失会在设置呼叫时产生问题，但适度的抖动只会使呼叫放置的持续时间不太可预测。
Service classes indicate the required traffic forwarding treatment in order to meet user, application, or network expectations. Section 3 defines the service classes that MAY be used for forwarding network control traffic, and Section 4 defines the service classes that MAY be used for forwarding user traffic with examples of intended application types mapped into each service class. Note that the application types are only examples and are not meant to be all-inclusive or prescriptive. Also, note that the service class naming or ordering does not imply any priority ordering. They are simply reference names that are used in this document with associated QoS behaviors that are optimized for the particular application types they support. Network administrators MAY choose to assign different service class names to the service classes that they will support. Figure 3 defines the RECOMMENDED relationship between service classes and DS codepoint assignment with application examples. It is RECOMMENDED that this relationship be preserved end to end.
服务类别表示为满足用户、应用程序或网络期望所需的流量转发处理。第3节定义了可用于转发网络控制流量的服务类，第4节定义了可用于转发用户流量的服务类，以及映射到每个服务类中的预期应用类型示例。请注意，应用程序类型仅为示例，并不意味着包罗万象或规定性的。另外，请注意，服务类命名或排序并不意味着任何优先级排序。它们只是本文档中使用的引用名称，以及针对其支持的特定应用程序类型进行优化的相关QoS行为。网络管理员可以选择为他们将支持的服务类分配不同的服务类名称。图3通过应用程序示例定义了服务类和DS代码点分配之间的推荐关系。建议端到端保留此关系。
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class Name | Name | Value | Examples |
|===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| H.323/V2 video |
| Conferencing | AF43 | 100110 | conferencing (adaptive) |
|---------------+---------+-------------+--------------------------|
| Real-Time | CS4 | 100000 | Video conferencing and |
| Interactive | | | Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------|
|Broadcast Video| CS3 | 011000 |Broadcast TV & live events|
|---------------+---------+-------------+--------------------------|
| Low-Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data | AF23 | 010110 | Web-based ordering |
|---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------|
|High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
| Standard | DF (CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class Name | Name | Value | Examples |
|===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| H.323/V2 video |
| Conferencing | AF43 | 100110 | conferencing (adaptive) |
|---------------+---------+-------------+--------------------------|
| Real-Time | CS4 | 100000 | Video conferencing and |
| Interactive | | | Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------|
|Broadcast Video| CS3 | 011000 |Broadcast TV & live events|
|---------------+---------+-------------+--------------------------|
| Low-Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data | AF23 | 010110 | Web-based ordering |
|---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------|
|High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
| Standard | DF (CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
Figure 3. DSCP to Service Class Mapping
图3。DSCP到服务类映射
Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint, '000000'.
图3的注释：默认转发（DF）和类选择器0（CS0）提供等效的行为，并使用相同的DS代码点“000000”。
It is expected that network administrators will base their choice of the service classes that they will support on their need, starting off with three or four service classes for user traffic and adding others as the need arises.
预计网络管理员将根据他们的需要选择他们将支持的服务类，首先为用户流量选择三个或四个服务类，然后根据需要添加其他服务类。
Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be used for the defined service classes that are further detailed in Sections 3 and 4 of this document. According to what applications/services need to be differentiated, network administrators can choose the service class(es) that need to be supported in their network.
图4提供了应用于已定义服务类的DiffServ QoS机制的摘要，本文档第3节和第4节将进一步详细介绍这些服务类。根据需要区分的应用程序/服务，网络管理员可以选择其网络中需要支持的服务类别。
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 |three-color marker | RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+------+-------------------+---------|--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 |three-color marker | RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | | Yes|
| Throughput | AF12 |three-color marker | RFC2597 | Rate | per|
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 |three-color marker | RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+------+-------------------+---------|--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 |three-color marker | RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | | Yes|
| Throughput | AF12 |three-color marker | RFC2597 | Rate | per|
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
Figure 4. Summary of QoS Mechanisms Used for Each Service Class
图4。每个服务类别使用的QoS机制摘要
Notes for Figure 4:
图4的注释：
o Conditioning at DS edge means that traffic conditioning is performed at the edge of the DiffServ network where untrusted user devices are connected or between two DiffServ networks. o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. o The PHB for Real-Time Interactive service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as a second EF PHB that uses relaxed performance parameters and a rate scheduler. o The PHB for Broadcast Video service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as a third EF PHB that uses relaxed performance parameters and a rate scheduler. o In network segments that use IP precedence marking, only one of the two service classes can be supported, High-Throughput Data or Low-Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to 000xx1 on ingress and changed back to original value(s) on egress of the network segment that uses precedence marking. For example, if Low-Priority Data is mapped to Standard service class, then 000001 DSCP marking MAY be used to distinguish it from Standard marked packets on egress.
o DS边缘条件是指在连接不受信任用户设备的区分服务网络边缘或两个区分服务网络之间执行流量条件。o“sr+bs”表示一种提供单速率和突发大小控制的监管机制。o单速率三色标记（srTCM）行为应等同于RFC 2697，双速率三色标记（trTCM）行为应等同于RFC 2698。o实时交互服务类PHB应配置为提供高带宽保证。它可以配置为第二个EF PHB，使用宽松的性能参数和速率调度器。o广播视频服务类PHB应配置为提供高带宽保证。它可以配置为第三个EF PHB，使用宽松的性能参数和速率调度器。o在使用IP优先标记的网段中，只能支持两种服务类别中的一种，即高吞吐量数据或低优先级数据。我们建议在进入时将不受支持服务类别的DSCP值更改为000xx1，在使用优先标记的网段出口时将其更改回原始值。例如，如果低优先级数据被映射到标准服务类，则000001 DSCP标记可用于将其与出口上的标准标记包区分开来。
It is expected that network administrators will base their choice of the service classes that they will support on their need, starting off with three or four service classes for user traffic and adding more service classes as the need arises. In this section, we provide three examples of possible deployment scenarios.
预计网络管理员将根据他们的需要选择他们将支持的服务类，首先为用户流量选择三个或四个服务类，然后根据需要添加更多的服务类。在本节中，我们提供了三个可能的部署场景示例。
A network administrator determines that he needs to provide different performance levels (quality of service) in his network for the services that he will be offering to his customers. He needs to enable his network to provide:
网络管理员确定他需要在网络中为他将向客户提供的服务提供不同的性能级别（服务质量）。他需要使他的网络能够提供：
o Reliable VoIP (telephony) service, equivalent to Public Switched Telephone Network (PSTN). o A low-delay assured bandwidth data service. o Support for current Internet services.
o 可靠的VoIP（电话）服务，相当于公共交换电话网（PSTN）。o低延迟有保证的带宽数据服务。o支持当前的互联网服务。
For this example, the network administrator's needs are addressed with the deployment of the following six service classes:
在本例中，网络管理员的需求通过部署以下六个服务类来解决：
o Network Control service class for routing and control traffic that is needed for reliable operation of the provider's network. o Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment through the network for support of current Internet service. o Telephony service class for VoIP (telephony) bearer traffic. o Signaling service class for Telephony signaling to control the VoIP service. o Low-Latency Data service class for the low-delay assured bandwidth differentiated data service. o OAM service class for operation and management of the network.
o 网络控制服务类，用于路由和控制提供商网络可靠运行所需的流量。o标准服务等级，适用于通过网络接受正常（无差别）转发处理的所有流量，以支持当前互联网服务。o VoIP（电话）承载流量的电话服务类别。o用于控制VoIP服务的电话信令的信令服务类。o低延迟数据服务类别，用于低延迟有保证的带宽区分数据服务。o用于网络操作和管理的OAM服务类。
Figure 5 provides a summary of the mechanisms needed for delivery of service differentiation for Example 1.
图5总结了示例1中提供服务差异化所需的机制。
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
Figure 5. Service Provider Network Configuration Example 1
图5。服务提供商网络配置示例1
Notes for Figure 5:
图5的注释：
o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697. o Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class.
o “sr+bs”代表一种提供单速率和突发大小控制的监管机制。o单速率三色标记（srTCM）行为应等同于RFC 2697。o应使用标准服务类转发任何标记有DSCP值且不由支持的服务类表示的数据包。
With this example, we show how network operators with Example 1 capabilities can evolve their service offering to provide three new additional services to their customers. The new additional service capabilities that are to be added are:
通过这个示例，我们展示了具有示例1功能的网络运营商如何改进其服务，为其客户提供三种新的附加服务。要添加的新附加服务功能包括：
o SIP-based desktop video conference capability to complement VoIP (telephony) service. o TV and on-demand movie viewing service to residential subscribers. o Network-based data storage and file backup service to business customers.
o 基于SIP的桌面视频会议功能，以补充VoIP（电话）服务。o向住宅用户提供电视和点播电影观看服务。o为企业客户提供基于网络的数据存储和文件备份服务。
The new additional services that the network administrator would like to offer are addressed with the deployment of the following four additional service classes (these are additions to the six service classes already defined in Example 1):
网络管理员希望提供的新附加服务通过部署以下四个附加服务类（这些是对示例1中已定义的六个服务类的添加）来解决：
o Real-Time Interactive service class for transport of MPEG-4 real-time video flows to support desktop video conferencing. The control/signaling for video conferencing is done using the Signaling service class. o Broadcast Video service class for transport of IPTV broadcast information. The channel selection and control is via IGMP mapped into the Signaling service class. o Multimedia Streaming service class for transport of stored MPEG-2 or MPEG-4 content. The selection and control of streaming information is done using the Signaling service class. The selection of Multimedia Streaming service class for on-demand movie service was chosen as the set-top box used for this service has local buffering capability to compensate for the bandwidth variability of the elastic streaming information. Note that if transport of on-demand movie service is inelastic, then the Broadcast Video service class SHOULD be used. o High-Throughput Data service class is for transport of bulk data for network-based storage and file backup service to business customers.
o 实时交互服务类，用于传输MPEG-4实时视频流，以支持桌面视频会议。视频会议的控制/信令使用信令服务类完成。o用于传输IPTV广播信息的广播视频服务类。信道选择和控制通过IGMP映射到信令服务类。o用于传输存储的MPEG-2或MPEG-4内容的多媒体流媒体服务类。流信息的选择和控制是使用信令服务类完成的。选择按需电影服务的多媒体流媒体服务类别是因为用于该服务的机顶盒具有本地缓冲能力，以补偿弹性流媒体信息的带宽变化。请注意，如果按需电影服务的传输是非弹性的，则应使用广播视频服务类。o高通量数据服务类用于向业务客户传输批量数据，用于基于网络的存储和文件备份服务。
Figure 6 provides a summary of the mechanisms needed for delivery of service differentiation for all the service classes used in Example 2.
图6总结了为示例2中使用的所有服务类提供服务差异化所需的机制。
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+-------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | |Yes |
| Streaming | AF32 |three-color marker | RFC2597 | Rate |per |
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | |Yes |
| Latency | AF22 |three-color marker | RFC2597 | Rate |per |
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate |Yes |
| | +other| | | | |
-------------------------------------------------------------------
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+-------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | |Yes |
| Streaming | AF32 |three-color marker | RFC2597 | Rate |per |
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | |Yes |
| Latency | AF22 |three-color marker | RFC2597 | Rate |per |
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate |Yes |
| | +other| | | | |
-------------------------------------------------------------------
Figure 6. Service Provider Network Configuration Example 2
图6。服务提供商网络配置示例2
Notes for Figure 6:
图6的注释：
o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698.
o “sr+bs”代表一种提供单速率和突发大小控制的监管机制。o单速率三色标记（srTCM）行为应等同于RFC 2697，双速率三色标记（trTCM）行为应等同于RFC 2698。
o Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class.
o 应使用标准服务类转发任何标记为DSCP值但不由支持的服务类表示的数据包。
An enterprise network administrator determines that they need to provide different performance levels (quality of service) in their network for the new services that are being offered to corporate users. The enterprise network needs to:
企业网络管理员确定他们需要在网络中为公司用户提供的新服务提供不同的性能级别（服务质量）。企业网络需要：
o Provide reliable corporate VoIP service. o Provide video conferencing service to selected Conference Rooms. o Support on-demand distribution of prerecorded audio and video information to large number of users. o Provide a priority data transfer capability for engineering teams to share design information. o Reduce or deny bandwidth during peak traffic periods for selected applications. o Continue to provide normal IP service to all remaining applications and services.
o 提供可靠的企业VoIP服务。o为选定的会议室提供视频会议服务。o支持按需向大量用户分发预先录制的音频和视频信息。o为工程团队提供优先数据传输能力，以共享设计信息。o在选定应用程序的高峰流量期间减少或拒绝带宽。o继续向所有剩余的应用程序和服务提供正常的IP服务。
For this example, the enterprise's network needs are addressed with the deployment of the following nine service classes:
在本例中，企业的网络需求通过部署以下九种服务类别来解决：
o Network Control service class for routing and control traffic that is needed for reliable operation of the enterprise network. o OAM service class for operation and management of the network. o Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment. o Telephony service class for VoIP (telephony) bearer traffic. o Signaling service class for Telephony signaling to control the VoIP service. o Multimedia Conferencing service class for support of inter-Conference Room video conferencing service using H.323/V2 or similar equipment. o Multimedia Streaming service class for transfer of prerecorded audio and video information. o High-Throughput Data service class to provide bandwidth assurance for timely transfer of large engineering files. o Low-Priority Data service class for selected background applications where data transfer can be delayed or suspended for a period of time during peak network load conditions.
o 网络控制服务类，用于路由和控制企业网络可靠运行所需的流量。o用于网络操作和管理的OAM服务类。o所有将接受正常（无差别）转发处理的流量的标准服务等级。o VoIP（电话）承载流量的电话服务类别。o用于控制VoIP服务的电话信令的信令服务类。o多媒体会议服务类，用于支持使用H.323/V2或类似设备的会议室间视频会议服务。o多媒体流媒体服务课程，用于传输预先录制的音频和视频信息。o高通量数据服务类，为及时传输大型工程文件提供带宽保证。o低优先级数据服务类别，适用于选定的后台应用程序，在峰值网络负载条件下，数据传输可能会延迟或暂停一段时间。
Figure 7 provides a summary of the mechanisms needed for delivery of service differentiation for Example 3.
图7总结了示例3中提供服务差异化所需的机制。
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 | three-color marker| RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 | three-color marker| RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 | three-color marker| RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 | three-color marker| RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
Figure 7. Enterprise Network Configuration Example
图7。企业网络配置示例
Notes for Figure 7:
图7的注释：
o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. o Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class.
o “sr+bs”代表一种提供单速率和突发大小控制的监管机制。o单速率三色标记（srTCM）行为应等同于RFC 2697，双速率三色标记（trTCM）行为应等同于RFC 2698。o应使用标准服务类转发任何标记有DSCP值且不由支持的服务类表示的数据包。
Network control traffic is defined as packet flows that are essential for stable operation of the administered network as well as for information that may be exchanged between neighboring networks across a peering point where SLAs are in place. Network control traffic is different from user application control (signaling) that may be generated by some applications or services. Network control traffic is mostly between routers and network nodes that are used for operating, administering, controlling, or managing the network segments. Network Control Traffic may be split into two service classes, i.e., Network Control and OAM.
网络控制通信量被定义为对于被管理网络的稳定运行以及对于可能在存在sla的对等点上的相邻网络之间交换的信息至关重要的分组流。网络控制流量不同于可能由某些应用程序或服务生成的用户应用程序控制（信令）。网络控制流量主要在路由器和用于操作、管理、控制或管理网段的网络节点之间。网络控制流量可分为两个服务类别，即网络控制和OAM。
Based on today's routing protocols and network control procedures that are used in the Internet, we have determined that CS6 DSCP value SHOULD be used for routing and control and that CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols. Network administrators MAY use a Local/Experimental DSCP; therefore, they may use a locally defined service class within their network to further differentiate their routing and control traffic.
根据当今互联网上使用的路由协议和网络控制程序，我们确定CS6 DSCP值应用于路由和控制，而CS7 DSCP值应保留供将来使用，可能用于将来的路由或控制协议。网络管理员可以使用本地/实验DSCP；因此，他们可以在其网络中使用本地定义的服务类来进一步区分其路由和控制流量。
RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
CS7 DSCP标记数据包的建议网络边缘条件：
o Drop or remark CS7 packets at ingress to DiffServ network domain. o CS7 marked packets SHOULD NOT be sent across peering points. Exchange of control information across peering points SHOULD be done using CS6 DSCP and the Network Control service class.
o 在进入DiffServ网络域时丢弃或标记CS7数据包。o CS7标记的数据包不应跨对等点发送。应使用CS6 DSCP和网络控制服务类在对等点之间交换控制信息。
The Network Control service class is used for transmitting packets between network devices (routers) that require control (routing) information to be exchanged between nodes within the administrative domain as well as across a peering point between different administrative domains. Traffic transmitted in this service class is very important as it keeps the network operational, and it needs to be forwarded in a timely manner.
网络控制服务类用于在需要在管理域内的节点之间以及在不同管理域之间的对等点之间交换控制（路由）信息的网络设备（路由器）之间传输数据包。此服务类别中传输的流量非常重要，因为它可以保持网络的运行，并且需要及时转发。
The Network Control service class SHOULD be configured using the DiffServ Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured so that the traffic receives a minimum bandwidth guarantee, to ensure that the packets always receive timely service. The configured forwarding resources for Network Control service class SHOULD be such that the probability of packet drop under peak load is very low in this service class. The Network
应使用[RFC2474]中定义的区分服务类选择器（CS）PHB配置网络控制服务类。应配置此服务类，以便通信量接收最小带宽保证，以确保数据包始终接收及时的服务。为网络控制服务类别配置的转发资源应使得在该服务类别中在峰值负载下的分组丢弃概率非常低。网络
Control service class SHOULD be configured to use a Rate Queuing system such as defined in Section 1.4.1.2 of this document.
控制服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。
The following are examples of protocols and applications that SHOULD use the Network Control service class:
以下是应使用网络控制服务类的协议和应用程序示例：
o Routing packet flows: OSPF, BGP, ISIS, RIP. o Control information exchange within and between different administrative domains across a peering point where SLAs are in place. o LSP setup using CR-LDP and RSVP-TE.
o 路由分组流：OSPF、BGP、ISIS、RIP。o控制SLA所在对等点内不同管理域之间的信息交换。o使用CR-LDP和RSVP-TE设置LSP。
The following protocols and applications SHOULD NOT use the Network Control service class:
以下协议和应用程序不应使用网络控制服务类：
o User traffic.
o 用户流量。
The following are traffic characteristics of packet flows in the Network Control service class:
以下是网络控制服务类别中分组流的流量特征：
o Mostly messages sent between routers and network servers. o Variable size packets, normally one packet at a time, but traffic can also burst (BGP). o User traffic is not allowed to use this service class. By user traffic, we mean packet flows that originate from user-controlled end points that are connected to the network.
o 主要是在路由器和网络服务器之间发送的消息。o可变大小的数据包，通常一次一个数据包，但流量也可以突发（BGP）。o不允许用户通信使用此服务类。用户流量是指源自连接到网络的用户控制端点的数据包流。
The RECOMMENDED DSCP marking is CS6 (Class Selector 6).
建议的DSCP标记为CS6（类别选择器6）。
RECOMMENDED Network Edge Conditioning:
建议的网络边缘条件：
o At peering points (between two DiffServ networks) where SLAs are in place, CS6 marked packets SHOULD be policed, e.g., using a single rate with burst size (sr+bs) token bucket policer to keep the CS6 marked packet flows to within the traffic rate specified in the SLA. o CS6 marked packet flows from untrusted sources (for example, end user devices) SHOULD be dropped or remarked at ingress to the DiffServ network. o Packets from users/subscribers are not permitted access to the Network Control service classes.
o 在有SLA的对等点（两个DiffServ网络之间），应对CS6标记的数据包进行策略管理，例如，使用具有突发大小的单速率（sr+bs）令牌桶策略将CS6标记的数据包流保持在SLA中指定的流量率内。o在进入DiffServ网络时，应丢弃或标记来自不受信任来源（例如，最终用户设备）的CS6标记的数据包流。o不允许来自用户/订户的数据包访问网络控制服务类。
The fundamental service offered to the Network Control service class is enhanced best-effort service with high bandwidth assurance. Since this service class is used to forward both elastic and inelastic flows, the service SHOULD be engineered so that the Active Queue Management (AQM) [RFC2309] is applied to CS6 marked packets.
向网络控制服务类提供的基本服务是具有高带宽保证的增强型尽力而为服务。由于该服务类用于转发弹性流和非弹性流，因此应设计该服务，以便将主动队列管理（AQM）[RFC2309]应用于CS6标记的数据包。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将红色[RFC2309]用作AQM算法，则最小阈值指定目标队列深度，最大阈值指定所有流量丢弃或标记ECN的队列深度。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold CS6 < max-threshold CS6 o max-threshold CS6 <= memory assigned to the queue
o 最小阈值CS6<最大阈值CS6 o最大阈值CS6<=分配给队列的内存
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The OAM (Operations, Administration, and Management) service class is RECOMMENDED for OAM&P (Operations, Administration, and Management and Provisioning) using protocols such as Simple Network Management Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, and Common Open Policy Service (COPS). Applications using this service class require a low packet loss but are relatively not sensitive to delay. This service class is configured to provide good packet delivery for intermittent flows.
建议使用诸如简单网络管理协议（SNMP）、普通文件传输协议（TFTP）、FTP、Telnet和公共开放策略服务（COPS）等协议为OAM&P（操作、管理、管理和资源调配）提供OAM（操作、管理和管理）服务类。使用此服务类别的应用程序需要较低的数据包丢失，但对延迟相对不敏感。此服务类被配置为为为间歇流提供良好的数据包传递。
The OAM service class SHOULD use the Class Selector (CS) PHB defined in [RFC2474]. This service class SHOULD be configured to provide a minimum bandwidth assurance for CS2 marked packets to ensure that they get forwarded. The OAM service class SHOULD be configured to use a Rate Queuing system such as defined in Section 1.4.1.2 of this document.
OAM服务类应使用[RFC2474]中定义的类选择器（CS）PHB。此服务类应配置为为为CS2标记的数据包提供最低带宽保证，以确保它们得到转发。OAM服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。
The following applications SHOULD use the OAM service class:
以下应用程序应使用OAM服务类：
o Provisioning and configuration of network elements. o Performance monitoring of network elements. o Any network operational alarms.
o 网络元素的供应和配置。o网络元件的性能监控。o任何网络操作警报。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets. o Intermittent traffic flows. o Traffic may burst at times. o Both elastic and inelastic flows. o Traffic not sensitive to delays.
o 可变大小的数据包。o间歇性交通流量。o交通有时可能会中断。o弹性流和非弹性流。o交通对延误不敏感。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o All flows in this service class are marked with CS2 (Class Selector 2).
o 此服务类中的所有流都用CS2（类选择器2）标记。
Applications or IP end points SHOULD pre-mark their packets with CS2 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
应用程序或IP端点应使用CS2 DSCP值预先标记其数据包。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多场（MF）分类。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds. o Packet flows from trusted sources (routers inside administered network) MAY not require policing. o Normally OAM&P CS2 marked packet flows are not allowed to flow across peering points. If that is the case, then CS2 marked packets SHOULD be policed (dropped) at both egress and ingress peering interfaces.
o 应使用[RFC2475]中定义的多字段（MF）分类方法，在进入DiffServ网络时验证来自不受信任来源（最终用户设备）的数据包流标记（DSCP设置）。o来自不受信任来源（最终用户设备）的数据包流应在进入DiffServ网络时进行监控，例如，使用单速率突发大小令牌桶策略，以确保流量保持在其协商或工程边界内。o来自可信来源（受管网络内的路由器）的数据包流可能不需要监控。o通常，OAM&P CS2标记的数据包流不允许跨对等点流动。如果是这种情况，那么应该在出口和入口对等接口处对CS2标记的数据包进行策略（丢弃）。
The fundamental service offered to "OAM" traffic is enhanced best-effort service with controlled rate. The service SHOULD be engineered so that CS2 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since this service class is used to forward both elastic and inelastic flows, the service SHOULD be engineered so that Active Queue Management [RFC2309] is applied to CS2 marked packets.
为“OAM”流量提供的基本服务是具有受控速率的增强型尽力而为服务。服务的设计应确保CS2标记的数据包流在网络中具有足够的带宽，以提供高的传输保证。由于该服务类用于转发弹性流和非弹性流，因此应设计该服务，以便将主动队列管理[RFC2309]应用于CS2标记的数据包。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将RED[RFC2309]用作AQM算法，则最小阈值指定每个DSCP的目标队列深度，最大阈值指定队列深度，在该深度以上，具有此类DSCP的所有流量都将被丢弃或标记为ECN。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold CS2 < max-threshold CS2 o max-threshold CS2 <= memory assigned to the queue
o 最小阈值CS2<最大阈值CS2 o最大阈值CS2<=分配给队列的内存
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
User traffic is defined as packet flows between different users or subscribers. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services. User traffic can be differentiated in many different ways; therefore,
用户流量定义为不同用户或订户之间的数据包流。它是发送到终端或从终端发送的流量，支持非常广泛的应用程序和服务。用户流量可以通过许多不同的方式进行区分；因此
we investigated several different approaches to classifying user traffic. We looked at differentiating user traffic as real-time versus non-real-time, elastic or rate-adaptive versus inelastic, sensitive versus insensitive to loss as well as traffic categorization as interactive, responsive, timely, and non-critical, as defined in ITU-T Recommendation G.1010. In the final analysis, we used all of the above for service differentiation, mapping application types that seemed to have different sets of performance sensitivities, and requirements to different service classes.
我们研究了几种不同的用户流量分类方法。我们将用户流量区分为实时与非实时、弹性或速率自适应与非弹性、对丢失敏感与不敏感，以及ITU-T建议G.1010中定义的交互、响应、及时和非关键流量分类。在最终的分析中，我们将上述所有内容用于服务差异化，将似乎具有不同性能敏感性的应用程序类型和需求映射到不同的服务类别。
Network administrators can categorize their applications according to the type of behavior that they require and MAY choose to support all or a subset of the defined service classes. Figure 3 provides some common applications and the forwarding service classes that best support them, based on their performance requirements.
网络管理员可以根据所需的行为类型对其应用程序进行分类，并可以选择支持所有或部分已定义的服务类。图3根据性能要求提供了一些常见应用程序和最能支持它们的转发服务类。
The Telephony service class is RECOMMENDED for applications that require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service.
对于要求实时、极低延迟、极低抖动和相对恒定速率业务源（非弹性业务源）的极低数据包丢失的应用，建议使用电话服务类别。此服务类应用于IP电话服务。
The fundamental service offered to traffic in the Telephony service class is minimum jitter, delay, and packet loss service up to a specified upper bound. Operation is in some respect similar to an ATM CBR service, which has guaranteed bandwidth and which, if it stays within the negotiated rate, experiences nominal delay and no loss. The EF PHB has a similar guarantee.
为电话服务类中的业务提供的基本服务是最小抖动、延迟和分组丢失服务，达到指定的上限。操作在某些方面类似于ATM CBR服务，该服务具有保证的带宽，并且如果保持在协商的速率范围内，将经历标称延迟且没有损失。EF PHB也有类似的保证。
Typical configurations negotiate the setup of telephone calls over IP, using protocols such as H.248, MEGACO, H.323, or SIP. When a user has been authorized to send telephony traffic, the call admission procedure should have verified that the newly admitted flow will be within the capacity of the Telephony service class forwarding capability in the network. For VoIP (telephony) service, call admission control is usually performed by a telephony call server/ gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on access points to the network. The bandwidth in the core network and the number of simultaneous VoIP sessions that can be supported needs to be engineered and controlled so that there is no congestion for this service. Since the inelastic types of RTP payloads in this class do not react to loss or significant delay in any substantive way, the Telephony service class SHOULD forward packets as soon as possible. Some RTP payloads that may be used in telephony applications are adaptive and will not be in this class.
典型配置使用诸如H.248、MEGACO、H.323或SIP等协议协商IP电话呼叫的设置。当用户已被授权发送电话业务时，呼叫接纳过程应已验证新接纳的流量将在网络中的电话服务类转发能力的容量范围内。对于VoIP（电话）服务，呼叫接纳控制通常由电话呼叫服务器/网守使用网络接入点上的信令（SIP、H.323、H.248、MEGACO等）来执行。需要设计和控制核心网络中的带宽以及可支持的同步VoIP会话的数量，以便此服务不会出现拥塞。由于此类RTP有效载荷的非弹性类型不会以任何实质性方式对丢失或显著延迟作出反应，因此电话服务类应尽快转发数据包。某些RTP应用程序可能不会在此类应用程序中使用。
The Telephony service class SHOULD use Expedited Forwarding (EF) PHB, as defined in [RFC3246], and SHOULD be configured to receive guaranteed forwarding resources so that all packets are forwarded quickly. The Telephony service class SHOULD be configured to use a Priority Queuing system such as that defined in Section 1.4.1.1 of this document.
电话服务类应使用[RFC3246]中定义的快速转发（EF）PHB，并应配置为接收保证的转发资源，以便快速转发所有数据包。电话服务类别应配置为使用优先级排队系统，如本文件第1.4.1.1节中定义的系统。
The following applications SHOULD use the Telephony service class:
以下应用程序应使用电话服务类：
o VoIP (G.711, G.729 and other codecs). o Voice-band data over IP (modem, fax). o T.38 fax over IP. o Circuit emulation over IP, virtual wire, etc. o IP Virtual Private Network (VPN) service that specifies single-rate, mean network delay that is slightly longer then network propagation delay, very low jitter, and a very low packet loss.
o VoIP（G.711、G.729和其他编解码器）。o IP语音带数据（调制解调器、传真）。o T.38 IP传真。o通过IP、虚拟线等进行电路仿真。o IP虚拟专用网络（VPN）服务，指定单速率、平均网络延迟（略长于网络传播延迟）、极低抖动和极低数据包丢失。
The following are traffic characteristics:
以下是交通特征：
o Mostly fixed-size packets for VoIP (60, 70, 120 or 200 bytes in size). o Packets emitted at constant time intervals. o Admission control of new flows is provided by telephony call server, media gateway, gatekeeper, edge router, end terminal, or access node that provides flow admission control function.
o 主要用于VoIP的固定大小数据包（大小为60、70、120或200字节）。o以固定时间间隔发出的数据包。o新流量的准入控制由电话呼叫服务器、媒体网关、网守、边缘路由器、终端或提供流量准入控制功能的接入节点提供。
Applications or IP end points SHOULD pre-mark their packets with EF DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
应用程序或IP端点应使用EF DSCP值预先标记其数据包。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多场（MF）分类。
The RECOMMENDED DSCP marking is EF for the following applications:
对于以下应用，建议的DSCP标记为EF：
o VoIP (G.711, G.729 and other codecs). o Voice-band data over IP (modem and fax). o T.38 fax over IP. o Circuit emulation over IP, virtual wire, etc.
o VoIP（G.711、G.729和其他编解码器）。o IP语音带数据（调制解调器和传真）。o T.38 IP传真。o通过IP、虚拟线等进行电路仿真。
RECOMMENDED Network Edge Conditioning:
建议的网络边缘条件：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the telephony traffic stays within its negotiated bounds.
o 应使用[RFC2475]中定义的多字段（MF）分类方法，在进入DiffServ网络时验证来自不受信任来源（最终用户设备）的数据包流标记（DSCP设置）。o来自不受信任来源（最终用户设备）的数据包流应在进入DiffServ网络时进行监控，例如，使用单速率突发大小令牌桶策略，以确保电话流量保持在其协商范围内。
o Policing is OPTIONAL for packet flows from trusted sources whose behavior is ensured via other means (e.g., administrative controls on those systems). o Policing of Telephony packet flows across peering points where SLA is in place is OPTIONAL as telephony traffic will be controlled by admission control mechanism between peering points.
o 对于来自受信任来源的数据包流，可通过其他方式（例如，对这些系统的管理控制）确保其行为，对其进行监控。o在SLA到位的对等点上对电话分组流进行监管是可选的，因为电话流量将由对等点之间的准入控制机制控制。
The fundamental service offered to "Telephony" traffic is enhanced best-effort service with controlled rate, very low delay, and very low loss. The service MUST be engineered so that EF marked packet flows have sufficient bandwidth in the network to provide guaranteed delivery. Normally traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF marked packet flows.
为“电话”业务提供的基本服务是增强的尽力而为服务，具有受控的速率、极低的延迟和极低的损失。必须对服务进行设计，使EF标记的数据包流在网络中具有足够的带宽，以提供有保证的传输。通常，此服务类中的流量不会对数据包丢失作出动态响应。因此，主动队列管理[RFC2309]不应应用于EF标记的数据包流。
The Signaling service class is RECOMMENDED for delay-sensitive client-server (traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between IP phone and soft-switch, soft-client and soft-switch, and media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. Applications using this service class require a relatively fast response, as there are typically several messages of different sizes sent for control of the session. This service class is configured to provide good response for short-lived, intermittent flows that require real-time packet forwarding. To minimize the possibility of ring clipping at start of call for VoIP service that interfaces to a circuit switch Exchange in the Public Switched Telephone Network (PSTN), the Signaling service class SHOULD be configured so that the probability of packet drop or significant queuing delay under peak load is very low in IP network segments that provide this interface. The term "ring clipping" refers to those instances where the front end of a ringing signal is altered because the bearer path is not made available in time to carry all of the audible ringing signal. This condition may occur due to a race condition between when the tone generator in the circuit switch Exchange is turned on and when the bearer path through the IP network is enabled. See Section 8.1 for additional explanation of "ring clipping" and Section 5.1 for explanation of mapping different signaling methods to service classes.
信令服务类建议用于延迟敏感的客户端服务器（传统电话）和对等应用程序信令。电话信令包括IP电话和软交换、软客户端和软交换、媒体网关和软交换以及使用各种协议的点对点之间的信令。此服务类用于控制会话和应用程序。使用此服务类的应用程序需要相对快速的响应，因为通常会发送多条不同大小的消息来控制会话。此服务类被配置为为为需要实时数据包转发的短命间歇流提供良好响应。为了最大限度地减少与公共交换电话网（PSTN）中的电路交换交换机接口的VoIP服务在呼叫开始时的环路中断的可能性，信令服务类别的配置应确保在提供该接口的IP网段中，峰值负载下的数据包丢失或显著排队延迟的概率非常低。术语“环削波”是指由于承载路径不能及时用于承载所有可听到的振铃信号而改变振铃信号前端的那些实例。这种情况可能是由于电路交换机交换机中的音调发生器接通和通过IP网络的承载路径启用之间的竞争条件造成的。有关“环限幅”的更多说明，请参见第8.1节；关于将不同信令方法映射到服务类别的说明，请参见第5.1节。
The Signaling service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured to provide a minimum bandwidth assurance for CS5 marked packets to ensure that they get forwarded. The Signaling service class SHOULD
信令服务类应使用[RFC2474]中定义的类选择器（CS）PHB。此服务类应配置为为为CS5标记的数据包提供最低带宽保证，以确保它们得到转发。信令服务类应
be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
配置为使用本文件第1.4.1.2节中定义的费率排队系统。
The following applications SHOULD use the Signaling service class:
以下应用程序应使用信令服务类：
o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323). o Peer-to-peer signaling for multimedia applications (e.g., using SIP, H.323). o Peer-to-peer real-time control function. o Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP encapsulated ISDN, or other proprietary protocols. o Signaling to control IPTV applications using protocols such as IGMP. o Signaling flows between high-capacity telephony call servers or soft switches using protocol such as SIP-T. Such high-capacity devices may control thousands of telephony (VoIP) calls.
o 对等IP电话信令（例如，使用SIP、H.323）。o用于多媒体应用的对等信令（例如，使用SIP、H.323）。o点对点实时控制功能。o使用H.248、MEGACO、MGCP、IP封装ISDN或其他专有协议的客户机-服务器IP电话信令。o使用协议（如IGMP）控制IPTV应用的信令。o使用SIP-T等协议在高容量电话呼叫服务器或软交换机之间进行信令流。此类高容量设备可控制数千个电话（VoIP）呼叫。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets, normally one packet at a time. o Intermittent traffic flows. o Traffic may burst at times. o Delay-sensitive control messages sent between two end points.
o 可变大小的数据包，通常一次一个数据包。o间歇性交通流量。o交通有时可能会中断。o在两个端点之间发送延迟敏感控制消息。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o All flows in this service class are marked with CS5 (Class Selector 5).
o 此服务类别中的所有流都用CS5（类别选择器5）标记。
Applications or IP end points SHOULD pre-mark their packets with CS5 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
应用程序或IP端点应使用CS5 DSCP值预先标记其数据包。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多场（MF）分类。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds. o Packet flows from trusted sources (application servers inside administered network) MAY not require policing. o Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
o 应使用[RFC2475]中定义的多字段（MF）分类方法，在进入DiffServ网络时验证来自不受信任来源（最终用户设备）的数据包流标记（DSCP设置）。o来自不受信任来源（最终用户设备）的数据包流应在进入DiffServ网络时进行监控，例如，使用单速率突发大小令牌桶策略，以确保流量保持在其协商或工程边界内。o来自可信来源（受管网络内的应用程序服务器）的数据包流可能不需要监控。o应根据服务水平协议（SLA）对对等点上的数据包流进行监控。
The fundamental service offered to "Signaling" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that CS5 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery and low delay. Normally, traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 marked packet flows.
为“信令”业务提供的基本服务是具有受控速率和延迟的增强型尽力而为服务。服务的设计应确保CS5标记的数据包流在网络中具有足够的带宽，以提供高的传输保证和低延迟。通常，此服务类中的流量不会对数据包丢失作出动态响应。因此，主动队列管理[RFC2309]不应应用于CS5标记的数据包流。
The Multimedia Conferencing service class is RECOMMENDED for applications that require real-time service for rate-adaptive traffic. H.323/V2 and later versions of video conferencing equipment with dynamic bandwidth adjustment are such applications. The traffic sources in this service class have the ability to dynamically change their transmission rate based on feedback from the receiver. One approach used in H.323/V2 equipment is, when the receiver detects a pre-configured level of packet loss, it signals to the transmitter the indication of possible on-path congestion. When available, the transmitter then selects a lower rate encoding codec. Note that today, many H.323/V2 video conferencing solutions implement fixed-step bandwidth change (usually reducing the rate), traffic resembling step-wise CBR.
多媒体会议服务类建议用于需要速率自适应通信实时服务的应用程序。H.323/V2和具有动态带宽调整的视频会议设备的更高版本就是这样的应用。此服务类别中的业务源能够根据来自接收器的反馈动态更改其传输速率。H.323/V2设备中使用的一种方法是，当接收机检测到预先配置的分组丢失水平时，它向发射机发送信号，指示可能的路径拥塞。当可用时，发射机然后选择较低速率的编码解码器。请注意，如今，许多H.323/V2视频会议解决方案实现了固定步长带宽变化（通常降低速率），流量类似于逐级CBR。
Typical video conferencing configurations negotiate the setup of multimedia session using protocols such as H.323. When a user/end-point has been authorized to start a multimedia session, the admission procedure should have verified that the newly admitted data rate will be within the engineered capacity of the Multimedia Conferencing service class. The bandwidth in the core network and the number of simultaneous video conferencing sessions that can be supported SHOULD be engineered to control traffic load for this service.
典型的视频会议配置使用H.323等协议协商多媒体会话的设置。当用户/端点已被授权启动多媒体会话时，接纳程序应已验证新接纳的数据速率将在多媒体会议服务类别的设计容量内。应设计核心网络中的带宽和可支持的同时视频会议会话的数量，以控制此服务的流量负载。
The Multimedia Conferencing service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a bandwidth assurance for AF41, AF42, and AF43 marked packets to ensure that they get forwarded. The Multimedia Conferencing service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
多媒体会议服务类应使用[RFC2597]中定义的保证转发（AF）PHB。此服务类应配置为为AF41、AF42和AF43标记的数据包提供带宽保证，以确保它们得到转发。多媒体会议服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。
The following applications SHOULD use the Multimedia Conferencing service class:
以下应用程序应使用多媒体会议服务类：
o H.323/V2 and later versions of video conferencing applications (interactive video).
o H.323/V2及更高版本的视频会议应用程序（交互式视频）。
o Video conferencing applications with rate control or traffic content importance marking. o Application server-to-application server non-bursty data transfer requiring very low delay. o IP VPN service that specifies two rates and mean network delay that is slightly longer then network propagation delay. o Interactive, time-critical, and mission-critical applications.
o 具有速率控制或流量内容重要性标记的视频会议应用程序。o应用程序服务器到应用程序服务器的非突发数据传输要求极低的延迟。o IP VPN服务，指定两种速率和略长于网络传播延迟的平均网络延迟。o交互式、时间关键型和任务关键型应用程序。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets. o The higher the rate, the higher the density of large packets. o Constant packet emission time interval. o Variable rate. o Source is capable of reducing its transmission rate based on detection of packet loss at the receiver.
o 可变大小的数据包。o速率越高，大数据包的密度越高。o恒定的数据包发射时间间隔。o可变利率。o源能够基于在接收器处检测分组丢失来降低其传输速率。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] and mark all packets as AF4x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
应用程序或IP端点应使用DSCP值预先标记其数据包，如下所示。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应按照[RFC2475]中的定义执行多字段（MF）分类，并将所有数据包标记为AF4x。注意：在这种情况下，双速率三色标记将配置为在色盲模式下工作。
RECOMMENDED DSCP marking when performed by router closest to source:
由距离源最近的路由器执行的建议DSCP标记：
o AF41 = up to specified rate "A". o AF42 = in excess of specified rate "A" but below specified rate "B". o AF43 = in excess of specified rate "B". o Where "A" < "B".
o AF41=达到规定的速率“A”。o AF42=超过规定的速率“A”，但低于规定的速率“B”。o AF43=超过规定的速率“B”。o其中“A”<“B”。
Note: One might expect "A" to approximate the sum of the mean rates and "B" to approximate the sum of the peak rates.
注：人们可能期望“A”近似平均速率之和，“B”近似峰值速率之和。
RECOMMENDED DSCP marking when performed by H.323/V2 video conferencing equipment:
由H.323/V2视频会议设备执行时的建议DSCP标记：
o AF41 = H.323 video conferencing audio stream RTP/UDP. o AF41 = H.323 video conferencing video control RTCP/TCP. o AF41 = H.323 video conferencing video stream up to specified rate "A". o AF42 = H.323 video conferencing video stream in excess of specified rate "A" but below specified rate "B". o AF43 = H.323 video conferencing video stream in excess of specified rate "B". o Where "A" < "B".
o AF41=H.323视频会议音频流RTP/UDP。o AF41=H.323视频会议视频控制RTCP/TCP。o AF41=高达指定速率“A”的H.323视频会议视频流。o AF42=H.323视频会议视频流超过指定速率“A”，但低于指定速率“B”。o AF43=超过指定速率“B”的H.323视频会议视频流。o其中“A”<“B”。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
o 双速率三色标记应配置为提供trTCM[RFC2698]中定义的行为。o如果数据包由受信任的源或以前受信任的DiffServ域标记，并且要保留颜色标记，则应将双速率三色标记配置为在颜色感知模式下运行。o如果不信任数据包标记或不保留颜色标记，则应将双速率三色标记配置为在色盲模式下运行。
The fundamental service offered to "Multimedia Conferencing" traffic is enhanced best-effort service with controlled rate and delay. For video conferencing service, typically a 1% packet loss detected at the receiver triggers an encoding rate change, dropping to the next lower provisioned video encoding rate. As such, Active Queue Management [RFC2309] SHOULD be used primarily to switch the video encoding rate under congestion, changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps. The probability of loss of AF41 traffic MUST NOT exceed the probability of loss of AF42 traffic, which in turn MUST NOT exceed the probability of loss of AF43 traffic.
为“多媒体会议”流量提供的基本服务是具有受控速率和延迟的增强型尽力而为服务。对于视频会议服务，通常在接收器检测到1%的数据包丢失会触发编码速率更改，降低到下一个较低的配置视频编码速率。因此，主动队列管理[RFC2309]应主要用于在拥塞情况下切换视频编码速率，从高速率切换到低速率，即从1472 kbps切换到768 kbps。AF41流量的丢失概率不得超过AF42流量的丢失概率，而AF42流量的丢失概率又不得超过AF43流量的丢失概率。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将RED[RFC2309]用作AQM算法，则最小阈值指定每个DSCP的目标队列深度，最大阈值指定队列深度，在该深度以上，具有此类DSCP的所有流量都将被丢弃或标记为ECN。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold AF43 < max-threshold AF43 o max-threshold AF43 <= min-threshold AF42 o min-threshold AF42 < max-threshold AF42 o max-threshold AF42 <= min-threshold AF41 o min-threshold AF41 < max-threshold AF41 o max-threshold AF41 <= memory assigned to the queue
o 最小阈值AF43<最大阈值AF43 o最大阈值AF43<=最小阈值AF42 o最小阈值AF42<最大阈值AF42 o最大阈值AF42<=最小阈值AF41 o最小阈值AF41<最大阈值AF41 o最大阈值AF41<=分配给队列的内存
Note: This configuration tends to drop AF43 traffic before AF42 and AF42 before AF41. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：此配置倾向于在AF42之前丢弃AF43流量，在AF41之前丢弃AF42流量。存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The Real-Time Interactive service class is RECOMMENDED for applications that require low loss and jitter and very low delay for variable rate inelastic traffic sources. Interactive gaming and video conferencing applications that do not have the ability to change encoding rates or to mark packets with different importance
实时交互服务类建议用于要求低损耗和抖动以及可变速率非弹性业务源极低延迟的应用。交互式游戏和视频会议应用程序无法更改编码速率或标记具有不同重要性的数据包
indications are such applications. The traffic sources in this traffic class do not have the ability to reduce their transmission rate according to feedback received from the receiving end.
适应症就是这样的应用。该业务类别中的业务源不具备根据从接收端接收的反馈降低其传输速率的能力。
Typically, applications in this service class are configured to negotiate the setup of RTP/UDP control session. When a user/end-point has been authorized to start a new session, the admission procedure should have verified that the newly admitted data rates will be within the engineered capacity of the Real-Time Interactive service class. The bandwidth in the core network and the number of simultaneous Real-time Interactive sessions that can be supported SHOULD be engineered to control traffic load for this service.
通常，此服务类中的应用程序配置为协商RTP/UDP控制会话的设置。当用户/端点被授权启动新会话时，接纳程序应验证新接纳的数据速率将在实时交互服务类的设计容量内。应设计核心网络中的带宽和可支持的同时实时交互会话的数量，以控制此服务的流量负载。
The Real-Time Interactive service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured to provide a high assurance for bandwidth for CS4 marked packets to ensure that they get forwarded. The Real-Time Interactive service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document. Note that this service class MAY be configured as a second EF PHB that uses relaxed performance parameter, a rate scheduler, and CS4 DSCP value.
实时交互服务类应使用[RFC2474]中定义的类选择器（CS）PHB。此服务类应配置为为为CS4标记的数据包提供高带宽保证，以确保它们得到转发。实时交互服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。请注意，此服务类可以配置为第二个EF PHB，它使用宽松的性能参数、速率调度器和CS4 DSCP值。
The following applications SHOULD use the Real-Time Interactive service class:
以下应用程序应使用实时交互服务类：
o Interactive gaming and control. o Video conferencing applications without rate control or traffic content importance marking. o IP VPN service that specifies single rate and mean network delay that is slightly longer then network propagation delay. o Inelastic, interactive, time-critical, and mission-critical applications requiring very low delay.
o 互动游戏和控制。o无速率控制或流量内容重要性标记的视频会议应用程序。o IP VPN服务，指定比网络传播延迟稍长的单速率和平均网络延迟。o要求极低延迟的非弹性、交互式、时间关键型和任务关键型应用程序。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets. o Variable rate, non-bursty. o Application is sensitive to delay variation between flows and sessions. o Lost packets, if any, are usually ignored by application.
o 可变大小的数据包。o可变速率，非突发性。o应用程序对流和会话之间的延迟变化很敏感。o应用程序通常会忽略丢失的数据包（如果有）。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o All flows in this service class are marked with CS4 (Class Selector 4).
o 此服务类中的所有流都用CS4（类选择器4）标记。
Applications or IP end points SHOULD pre-mark their packets with CS4 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
应用程序或IP端点应使用CS4 DSCP值预先标记其数据包。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多场（MF）分类。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds. o Packet flows from trusted sources (application servers inside administered network) MAY not require policing. o Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
o 应使用[RFC2475]中定义的多字段（MF）分类方法，在进入DiffServ网络时验证来自不受信任来源（最终用户设备）的数据包流标记（DSCP设置）。o来自不受信任来源（最终用户设备）的数据包流应在进入DiffServ网络时进行监控，例如，使用单速率突发大小令牌桶策略，以确保流量保持在其协商或工程边界内。o来自可信来源（受管网络内的应用程序服务器）的数据包流可能不需要监控。o应根据服务水平协议（SLA）对对等点上的数据包流进行监控。
The fundamental service offered to "Real-Time Interactive" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that CS4 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally, traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS4 marked packet flows.
为“实时交互”流量提供的基本服务是具有受控速率和延迟的增强型尽力而为服务。服务的设计应确保CS4标记的数据包流在网络中具有足够的带宽，以提供高的传输保证。通常，此服务类中的流量不会对数据包丢失作出动态响应。因此，主动队列管理[RFC2309]不应应用于CS4标记的数据包流。
The Multimedia Streaming service class is RECOMMENDED for applications that require near-real-time packet forwarding of variable rate elastic traffic sources that are not as delay sensitive as applications using the Multimedia Conferencing service class. Such applications include streaming audio and video, some video (movies) on-demand applications, and webcasts. In general, the Multimedia Streaming service class assumes that the traffic is buffered at the source/destination; therefore, it is less sensitive to delay and jitter.
建议将多媒体流服务类用于需要变速率弹性流量源的近实时数据包转发的应用程序，这些流量源不像使用多媒体会议服务类的应用程序那样对延迟敏感。这些应用程序包括流式音频和视频、一些视频（电影）点播应用程序和网络广播。一般来说，多媒体流服务类假设流量在源/目的地缓冲；因此，它对延迟和抖动不太敏感。
The Multimedia Streaming service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a minimum bandwidth assurance for AF31, AF32, and AF33 marked packets to ensure that they get forwarded. The Multimedia Streaming service class SHOULD be configured to use Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
多媒体流服务类应使用[RFC2597]中定义的保证转发（AF）PHB。此服务类应配置为为AF31、AF32和AF33标记的数据包提供最低带宽保证，以确保它们得到转发。多媒体流服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。
The following applications SHOULD use the Multimedia Streaming service class:
以下应用程序应使用多媒体流媒体服务类：
o Buffered streaming audio (unicast). o Buffered streaming video (unicast). o Webcasts. o IP VPN service that specifies two rates and is less sensitive to delay and jitter.
o 缓冲流式音频（单播）。o缓冲流式视频（单播）。o网络广播。o指定两种速率且对延迟和抖动不太敏感的IP VPN服务。
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Variable rate.
o Elastic flows.
o Some bursting at start of flow from some applications.
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Variable rate.
o Elastic flows.
o Some bursting at start of flow from some applications.
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF3x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
应用程序或IP端点应使用DSCP值预先标记其数据包，如下所示。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多字段（MF）分类，并将所有数据包标记为AF3x。注意：在这种情况下，双速率三色标记将配置为在色盲模式下工作。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o AF31 = up to specified rate "A". o AF32 = in excess of specified rate "A" but below specified rate "B". o AF33 = in excess of specified rate "B". o Where "A" < "B".
o AF31=达到规定的速率“A”。o AF32=超过规定的速率“A”，但低于规定的速率“B”。o AF33=超过规定的速率“B”。o其中“A”<“B”。
Note: One might expect "A" to approximate the sum of the mean rates and "B" to approximate the sum of the peak rates.
注：人们可能期望“A”近似平均速率之和，“B”近似峰值速率之和。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
o 双速率三色标记应配置为提供trTCM[RFC2698]中定义的行为。o如果数据包由受信任的源或以前受信任的DiffServ域标记，并且要保留颜色标记，则应将双速率三色标记配置为在颜色感知模式下运行。o如果不信任数据包标记或不保留颜色标记，则应将双速率三色标记配置为在色盲模式下运行。
The fundamental service offered to "Multimedia Streaming" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that AF31 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the AF3x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to reduce forwarding rate to the minimum assured rate at congestion points. The probability of loss of AF31 traffic MUST NOT exceed the probability of loss of AF32 traffic, which in turn MUST NOT exceed the probability of loss of AF33.
为“多媒体流”流量提供的基本服务是具有受控速率和延迟的增强型尽力而为服务。服务的设计应确保标记为AF31的数据包流在网络中具有足够的带宽，以提供高的传输保证。由于AF3x流量具有弹性，并对数据包丢失作出动态响应，因此应主要使用主动队列管理[RFC2309]将拥塞点的转发速率降低到最低保证速率。AF31流量的丢失概率不得超过AF32流量的丢失概率，而AF32流量的丢失概率又不得超过AF33流量的丢失概率。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将RED[RFC2309]用作AQM算法，则最小阈值指定每个DSCP的目标队列深度，最大阈值指定队列深度，在该深度以上，具有此类DSCP的所有流量都将被丢弃或标记为ECN。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold AF33 < max-threshold AF33 o max-threshold AF33 <= min-threshold AF32 o min-threshold AF32 < max-threshold AF32 o max-threshold AF32 <= min-threshold AF31 o min-threshold AF31 < max-threshold AF31 o max-threshold AF31 <= memory assigned to the queue
o 最小阈值AF33<最大阈值AF33 o最大阈值AF33<=最小阈值AF32 o最小阈值AF32<最大阈值AF32 o最大阈值AF32<=最小阈值AF31 o最小阈值AF31<最大阈值AF31 o最大阈值AF31<=分配给队列的内存
Note: This configuration tends to drop AF33 traffic before AF32 and AF32 before AF31. Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：此配置倾向于将AF33流量放在AF32之前，将AF32流量放在AF31之前。注：存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The Broadcast Video service class is RECOMMENDED for applications that require near-real-time packet forwarding with very low packet loss of constant rate and variable rate inelastic traffic sources that are not as delay sensitive as applications using the Real-Time Interactive service class. Such applications include broadcast TV, streaming of live audio and video events, some video-on-demand applications, and video surveillance. In general, the Broadcast Video service class assumes that the destination end point has a dejitter buffer, for video application usually a 2 - 8 video-frame buffer (66 to several hundred of milliseconds), and therefore that it is less sensitive to delay and jitter.
广播视频服务类推荐用于需要近实时数据包转发的应用，该类数据包转发具有非常低的恒定速率和可变速率非弹性业务源的数据包丢失，这些数据源不像使用实时交互服务类的应用那样对延迟敏感。这些应用包括广播电视、现场音频和视频活动流、一些视频点播应用和视频监控。一般来说，广播视频服务类假设目标端点有一个去抖动缓冲区，对于视频应用程序，通常是一个2-8视频帧缓冲区（66到几百毫秒），因此它对延迟和抖动不太敏感。
The Broadcast Video service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured to provide high assurance for bandwidth for CS3 marked packets to ensure that they get forwarded. The Broadcast Video service class SHOULD be configured to use Rate Queuing system such as that defined in Section 1.4.1.2 of this document. Note that this service class
广播视频服务类应使用[RFC2474]中定义的类选择器（CS）PHB。此服务类应配置为为为CS3标记的数据包提供高带宽保证，以确保它们得到转发。广播视频服务类别应配置为使用本文件第1.4.1.2节中定义的速率排队系统。请注意，此服务类
MAY be configured as a third EF PHB that uses relaxed performance parameter, a rate scheduler, and CS3 DSCP value.
可以配置为第三个EF PHB，它使用宽松的性能参数、速率调度器和CS3 DSCP值。
The following applications SHOULD use the Broadcast Video service class:
以下应用程序应使用广播视频服务类：
o Video surveillance and security (unicast). o TV broadcast including HDTV (multicast). o Video on demand (unicast) with control (virtual DVD). o Streaming of live audio events (both unicast and multicast). o Streaming of live video events (both unicast and multicast).
o 视频监控和安全（单播）。o电视广播，包括HDTV（多播）。o带控制的视频点播（单播）（虚拟DVD）。o实时音频事件流（单播和多播）。o实时视频事件流（单播和多播）。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets. o The higher the rate, the higher the density of large packets. o Mixture of variable rate and constant rate flows. o Fixed packet emission time intervals. o Inelastic flows.
o 可变大小的数据包。o速率越高，大数据包的密度越高。o可变流量和恒定流量的混合。o固定的数据包发射时间间隔。o非弹性流动。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o All flows in this service class are marked with CS3 (Class Selector 3). o In some cases, such as those for security and video surveillance applications, it may be desirable to use a different DSCP marking. If so, then locally user definable (EXP/LU) codepoints in the range '011xx1' MAY be used to provide unique traffic identification. The locally user definable (EXP/LU) codepoint(s) MAY be associated with the PHB that is used for CS3 traffic. Furthermore, depending on the network scenario, additional network edge conditioning policy MAY be needed for the EXP/LU codepoint(s) used.
o 此服务类中的所有流都用CS3（类选择器3）标记。o在某些情况下，例如用于安全和视频监控应用的情况下，可能需要使用不同的DSCP标记。如果是这样，则可使用“011xx1”范围内的本地用户可定义（EXP/LU）代码点提供唯一的流量标识。本地用户可定义（EXP/LU）码点可与用于CS3通信的PHB相关联。此外，根据网络场景，所使用的EXP/LU码点可能需要额外的网络边缘调节策略。
Applications or IP end points SHOULD pre-mark their packets with CS3 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
应用程序或IP端点应使用CS3 DSCP值预先标记其数据包。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多场（MF）分类。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds.
o 应使用[RFC2475]中定义的多字段（MF）分类方法，在进入DiffServ网络时验证来自不受信任来源（最终用户设备）的数据包流标记（DSCP设置）。o来自不受信任来源（最终用户设备）的数据包流应在进入DiffServ网络时进行监控，例如，使用单速率突发大小令牌桶策略，以确保流量保持在其协商或工程边界内。
o Packet flows from trusted sources (application servers inside administered network) MAY not require policing. o Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
o 来自可信来源（受管网络内的应用程序服务器）的数据包流可能不需要监控。o应根据服务水平协议（SLA）对对等点上的数据包流进行监控。
The fundamental service offered to "Broadcast Video" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that CS3 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally, traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS3 marked packet flows.
为“广播视频”流量提供的基本服务是具有受控速率和延迟的增强型尽力而为服务。服务的设计应确保CS3标记的数据包流在网络中具有足够的带宽，以提供高的传输保证。通常，此服务类中的流量不会对数据包丢失作出动态响应。因此，主动队列管理[RFC2309]不应应用于CS3标记的数据包流。
The Low-Latency Data service class is RECOMMENDED for elastic and responsive typically client-/server-based applications. Applications forwarded by this service class are those that require a relatively fast response and typically have asymmetrical bandwidth need, i.e., the client typically sends a short message to the server and the server responds with a much larger data flow back to the client. The most common example of this is when a user clicks a hyperlink (~ few dozen bytes) on a web page, resulting in a new web page to be loaded (Kbytes of data). This service class is configured to provide good response for TCP [RFC1633] short-lived flows that require real-time packet forwarding of variable rate traffic sources.
建议将低延迟数据服务类用于弹性和响应性（通常是基于客户端/服务器的应用程序）。由该服务类转发的应用程序需要相对快速的响应，并且通常具有不对称的带宽需求，即，客户端通常向服务器发送短消息，而服务器则以更大的数据流返回客户端进行响应。最常见的例子是，用户单击网页上的超链接（~几十字节），导致加载新网页（KB数据）。此服务类被配置为为为TCP[RFC1633]短命流提供良好响应，这些短命流需要对可变速率流量源进行实时数据包转发。
The Low-Latency Data service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a minimum bandwidth assurance for AF21, AF22, and AF23 marked packets to ensure that they get forwarded. The Low-Latency Data service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
低延迟数据服务类应使用[RFC2597]中定义的保证转发（AF）PHB。此服务类应配置为为AF21、AF22和AF23标记的数据包提供最低带宽保证，以确保它们得到转发。低延迟数据服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。
The following applications SHOULD use the Low-Latency Data service class:
以下应用程序应使用低延迟数据服务类：
o Client/server applications. o Systems Network Architecture (SNA) terminal to host transactions (SNA over IP using Data Link Switching (DLSw)). o Web-based transactions (E-commerce). o Credit card transactions. o Financial wire transfers. o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN). o VPN service that supports Committed Information Rate (CIR) with up to two burst sizes.
o 客户端/服务器应用程序。o系统网络体系结构（SNA）终端到主机事务（使用数据链路交换（DLSw）的IP SNA）。o基于网络的交易（电子商务）。o信用卡交易。o金融电汇。o企业资源规划（ERP）应用程序（如SAP/BaaN）。o支持最多两个突发大小的提交信息速率（CIR）的VPN服务。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets. o Variable packet emission rate. o With packet bursts of TCP window size. o Short traffic bursts. o Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification.
o 可变大小的数据包。o可变数据包发射率。o具有TCP窗口大小的数据包突发。o短时间交通突发。o能够基于在接收器处检测到分组丢失或通过显式拥塞通知来降低其传输速率的源。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] and mark all packets as AF2x. Note: In this case, the single-rate, three-color marker will be configured to operate in Color-Blind mode.
应用程序或IP端点应使用DSCP值预先标记其数据包，如下所示。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应按照[RFC2475]中的定义执行多字段（MF）分类，并将所有数据包标记为AF2x。注意：在这种情况下，单速率三色标记将配置为在色盲模式下运行。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o AF21 = flow stream with packet burst size up to "A" bytes. o AF22 = flow stream with packet burst size in excess of "A" but below "B" bytes. o AF23 = flow stream with packet burst size in excess of "B" bytes. o Where "A" < "B".
o AF21=数据包突发大小高达“A”字节的流。o AF22=数据包突发大小超过“A”但低于“B”字节的流。o AF23=数据包突发大小超过“B”字节的流。o其中“A”<“B”。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o The single-rate, three-color marker SHOULD be configured to provide the behavior as defined in srTCM [RFC2697]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the single-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the single-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
o 应配置单速率三色标记，以提供srTCM[RFC2697]中定义的行为。o如果数据包由受信任的源或以前受信任的DiffServ域标记，并且要保留颜色标记，则应将单速率三色标记配置为在颜色感知模式下运行。o如果不信任数据包标记或不保留颜色标记，则应将单速率三色标记配置为在色盲模式下运行。
The fundamental service offered to "Low-Latency Data" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that AF21 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the AF2x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points by dropping packets from TCP flows that have large burst size. The probability of loss of AF21 traffic MUST NOT exceed the probability of loss of AF22 traffic, which in turn MUST NOT exceed the probability of loss
为“低延迟数据”流量提供的基本服务是具有受控速率和延迟的增强型尽力而为服务。服务的设计应确保标记为AF21的数据包流在网络中具有足够的带宽，以提供高的传输保证。由于AF2x流量具有弹性，并对数据包丢失做出动态响应，因此主动队列管理[RFC2309]应主要用于通过从具有大突发大小的TCP流中丢弃数据包来控制拥塞点的TCP流量。AF21流量的丢失概率不得超过AF22流量的丢失概率，而AF22流量的丢失概率也不得超过丢失概率
of AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management.
第23页。显式拥塞通知（ECN）[RFC3168]也可用于主动队列管理。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将RED[RFC2309]用作AQM算法，则最小阈值指定每个DSCP的目标队列深度，最大阈值指定队列深度，在该深度以上，具有此类DSCP的所有流量都将被丢弃或标记为ECN。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold AF23 < max-threshold AF23 o max-threshold AF23 <= min-threshold AF22 o min-threshold AF22 < max-threshold AF22 o max-threshold AF22 <= min-threshold AF21 o min-threshold AF21 < max-threshold AF21 o max-threshold AF21 <= memory assigned to the queue
o 最小阈值AF23<最大阈值AF23 o最大阈值AF23<=最小阈值AF22 o最小阈值AF22<最大阈值AF22 o最大阈值AF22<=最小阈值AF21 o最小阈值AF21<最大阈值AF21 o最大阈值AF21<=分配给队列的内存
Note: This configuration tends to drop AF23 traffic before AF22 and AF22 before AF21. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：此配置倾向于在AF22之前丢弃AF23通信量，在AF21之前丢弃AF22通信量。存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The High-Throughput Data service class is RECOMMENDED for elastic applications that require timely packet forwarding of variable rate traffic sources and, more specifically, is configured to provide good throughput for TCP longer-lived flows. TCP [RFC1633] or a transport with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782] normally will drive as high a data rate as it can obtain over a long period of time. The FTP protocol is a common example, although one cannot definitively say that all FTP transfers are moving data in bulk.
高吞吐量数据服务类建议用于需要对可变速率流量源进行及时数据包转发的弹性应用程序，更具体地说，它被配置为为为TCP寿命更长的流提供良好的吞吐量。TCP[RFC1633]或具有一致拥塞避免过程[RFC2581][RFC3782]的传输通常会在很长一段时间内驱动尽可能高的数据速率。FTP协议是一个常见的例子，尽管不能肯定地说所有FTP传输都是批量移动数据。
The High-Throughput Data service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a minimum bandwidth assurance for AF11, AF12, and AF13 marked packets to ensure that they are forwarded in a timely manner. The High-Throughput Data service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
高通量数据服务类应使用[RFC2597]中定义的保证转发（AF）PHB。此服务类应配置为为为标记为AF11、AF12和AF13的数据包提供最低带宽保证，以确保它们能够及时转发。高通量数据服务类应配置为使用本文件第1.4.1.2节中定义的速率排队系统。
The following applications SHOULD use the High-Throughput Data service class:
以下应用程序应使用高通量数据服务类：
o Store and forward applications. o File transfer applications. o Email. o VPN service that supports two rates (committed information rate and excess or peak information rate).
o 存储和转发应用程序。o文件传输应用程序。o电子邮件。o支持两种速率（提交信息速率和超额或峰值信息速率）的VPN服务。
The following are traffic characteristics:
以下是交通特征：
o Variable size packets. o Variable packet emission rate. o Variable rate. o With packet bursts of TCP window size. o Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification.
o 可变大小的数据包。o可变数据包发射率。o可变利率。o具有TCP窗口大小的数据包突发。o能够基于在接收器处检测到分组丢失或通过显式拥塞通知来降低其传输速率的源。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF1x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
应用程序或IP端点应使用DSCP值预先标记其数据包，如下所示。如果端点无法设置DSCP值，则拓扑上最靠近端点的路由器应执行[RFC2475]中定义的多字段（MF）分类，并将所有数据包标记为AF1x。注意：在这种情况下，双速率三色标记将配置为在色盲模式下工作。
RECOMMENDED DSCP marking:
建议的DSCP标记：
o AF11 = up to specified rate "A". o AF12 = in excess of specified rate "A" but below specified rate "B". o AF13 = in excess of specified rate "B". o Where "A" < "B".
o AF11=达到规定的速率“A”。o AF12=超过规定的速率“A”，但低于规定的速率“B”。o AF13=超过规定的速率“B”。o其中“A”<“B”。
RECOMMENDED conditioning performed at DiffServ network edge:
建议在DiffServ网络边缘执行调节：
o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
o 双速率三色标记应配置为提供trTCM[RFC2698]中定义的行为。o如果数据包由受信任的源或以前受信任的DiffServ域标记，并且要保留颜色标记，则应将双速率三色标记配置为在颜色感知模式下运行。o如果不信任数据包标记或不保留颜色标记，则应将双速率三色标记配置为在色盲模式下运行。
The fundamental service offered to "High-Throughput Data" traffic is enhanced best-effort service with a specified minimum rate. The service SHOULD be engineered so that AF11 marked packet flows have sufficient bandwidth in the network to provide assured delivery. It can be assumed that this class will consume any available bandwidth and that packets traversing congested links may experience higher queuing delays or packet loss. Since the AF1x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points by dropping packets from TCP flows that have higher
为“高吞吐量数据”流量提供的基本服务是具有指定最低速率的增强型尽力而为服务。服务的设计应确保标记为AF11的数据包流在网络中具有足够的带宽，以提供有保证的传输。可以假设该类将消耗任何可用带宽，并且穿过拥塞链路的数据包可能会经历更高的排队延迟或数据包丢失。由于AF1x流量是弹性的，并对数据包丢失作出动态响应，因此主动队列管理[RFC2309]应主要用于通过从具有更高流量的TCP流中丢弃数据包来控制拥塞点的TCP流量
rates first. The probability of loss of AF11 traffic MUST NOT exceed the probability of loss of AF12 traffic, which in turn MUST NOT exceed the probability of loss of AF13. In such a case, if one network customer is driving significant excess and another seeks to use the link, any losses will be experienced by the high-rate user, causing him to reduce his rate. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management.
价格第一。AF11流量的丢失概率不得超过AF12流量的丢失概率，而AF12流量的丢失概率又不得超过AF13流量的丢失概率。在这种情况下，如果一个网络客户过度驾驶，而另一个客户试图使用链路，高速率用户将经历任何损失，从而导致其降低速率。显式拥塞通知（ECN）[RFC3168]也可用于主动队列管理。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将RED[RFC2309]用作AQM算法，则最小阈值指定每个DSCP的目标队列深度，最大阈值指定队列深度，在该深度以上，具有此类DSCP的所有流量都将被丢弃或标记为ECN。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold AF13 < max-threshold AF13 o max-threshold AF13 <= min-threshold AF12 o min-threshold AF12 < max-threshold AF12 o max-threshold AF12 <= min-threshold AF11 o min-threshold AF11 < max-threshold AF11 o max-threshold AF11 <= memory assigned to the queue
o 最小阈值AF13<最大阈值AF13 o最大阈值AF13<=最小阈值AF12 o最小阈值AF12<最大阈值AF12 o最大阈值AF12<=最小阈值AF11 o最小阈值AF11<最大阈值AF11 o最大阈值AF11<=分配给队列的内存
Note: This configuration tends to drop AF13 traffic before AF12 and AF12 before AF11. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：此配置倾向于在AF12之前丢弃AF13流量，在AF11之前丢弃AF12流量。存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The Standard service class is RECOMMENDED for traffic that has not been classified into one of the other supported forwarding service classes in the DiffServ network domain. This service class provides the Internet's "best-effort" forwarding behavior. This service class typically has minimum bandwidth guarantee.
对于在DiffServ网络域中未分类为其他受支持的转发服务类别之一的流量，建议使用标准服务类别。此服务类提供Internet的“尽力”转发行为。此服务类别通常具有最小带宽保证。
The Standard service class MUST use the Default Forwarding (DF) PHB, defined in [RFC2474], and SHOULD be configured to receive at least a small percentage of forwarding resources as a guaranteed minimum. This service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
标准服务类必须使用[RFC2474]中定义的默认转发（DF）PHB，并应配置为至少接收一小部分转发资源作为保证的最低值。该服务类别应配置为使用本文件第1.4.1.2节中定义的费率排队系统。
The following applications SHOULD use the Standard service class:
以下应用程序应使用标准服务类：
o Network services, DNS, DHCP, BootP. o Any undifferentiated application/packet flow transported through the DiffServ enabled network.
o 网络服务，DNS，DHCP，BootP。o通过支持区分服务的网络传输的任何未区分的应用程序/数据包流。
The following is a traffic characteristic:
以下是交通特征：
o Non-deterministic, mixture of everything.
o 不确定的，混合的一切。
The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'.
建议的DSCP标记为DF（默认转发）'000000'。
Network Edge Conditioning:
网络边缘条件：
There is no requirement that conditioning of packet flows be performed for this service class.
不要求对此服务类别执行分组流调节。
The fundamental service offered to the Standard service class is best-effort service with active queue management to limit overall delay. Typical configurations SHOULD use random packet dropping to implement Active Queue Management [RFC2309] or Explicit Congestion Notification [RFC3168], and MAY impose a minimum or maximum rate on the queue.
为标准服务类提供的基本服务是具有主动队列管理以限制总体延迟的尽力而为服务。典型配置应使用随机分组丢弃来实现主动队列管理[RFC2309]或显式拥塞通知[RFC3168]，并可对队列施加最小或最大速率。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将红色[RFC2309]用作AQM算法，则最小阈值指定目标队列深度，最大阈值指定所有流量丢弃或标记ECN的队列深度。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold DF < max-threshold DF o max-threshold DF <= memory assigned to the queue
o 最小阈值DF<最大阈值DF o最大阈值DF<=分配给队列的内存
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The Low-Priority Data service class serves applications that run over TCP [RFC0793] or a transport with consistent congestion avoidance procedures [RFC2581] [RFC3782] and that the user is willing to accept service without guarantees. This service class is specified in [RFC3662] and [QBSS].
低优先级数据服务类服务于通过TCP[RFC0793]或具有一致拥塞避免过程[RFC2581][RFC3782]的传输运行的应用程序，并且用户愿意接受无担保服务。[RFC3662]和[QBSS]中指定了此服务类别。
The following applications MAY use the Low-Priority Data service class:
以下应用程序可能使用低优先级数据服务类别：
o Any TCP based-application/packet flow transported through the DiffServ enabled network that does not require any bandwidth assurances.
o 通过支持区分服务的网络传输的任何基于TCP的应用程序/数据包流，不需要任何带宽保证。
The following is a traffic characteristic:
以下是交通特征：
o Non-real-time and elastic.
o 非实时性和弹性。
Network Edge Conditioning:
网络边缘条件：
There is no requirement that conditioning of packet flows be performed for this service class.
不要求对此服务类别执行分组流调节。
The RECOMMENDED DSCP marking is CS1 (Class Selector 1).
建议的DSCP标记为CS1（类别选择器1）。
The fundamental service offered to the Low-Priority Data service class is best-effort service with zero bandwidth assurance. By placing it into a separate queue or class, it may be treated in a manner consistent with a specific Service Level Agreement.
低带宽保证的基本数据服务级别为零。通过将其放入一个单独的队列或类中，可以按照与特定服务级别协议一致的方式对其进行处理。
Typical configurations SHOULD use Explicit Congestion Notification [RFC3168] or random loss to implement Active Queue Management [RFC2309].
典型配置应使用显式拥塞通知[RFC3168]或随机丢失来实现主动队列管理[RFC2309]。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
如果将红色[RFC2309]用作AQM算法，则最小阈值指定目标队列深度，最大阈值指定所有流量丢弃或标记ECN的队列深度。因此，在此服务类中，队列配置中应存在以下不平等性：
o min-threshold CS1 < max-threshold CS1 o max-threshold CS1 <= memory assigned to the queue
o 最小阈值CS1<最大阈值CS1 o最大阈值CS1<=分配给队列的内存
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
In this section, we provide additional information on how some specific applications should be configured to use the defined service classes.
在本节中，我们将提供有关如何配置某些特定应用程序以使用定义的服务类的附加信息。
There are many different signaling protocols, ways that signaling is used and performance requirements from applications that are controlled by these protocols. We believe that different signaling protocols should use the service class that best meets the objectives of application or service they control. The following mapping is recommended:
有许多不同的信令协议、信令的使用方式以及由这些协议控制的应用程序的性能要求。我们认为，不同的信令协议应该使用最符合其控制的应用或服务目标的服务类别。建议使用以下映射：
o Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP (use Signaling service class).
o 使用SIP/H.323的对等信令标记为CS5 DSCP（使用信令服务类）。
o Client-server signaling as used in many implementation for IP telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or proprietary protocols is marked with CS5 DSCP (use Signaling service class). o Signaling between call servers or soft-switches in carrier's network using SIP, SIP-T, or IP encapsulated ISUP is marked with CS5 DSCP (use Signaling service class). o RSVP signaling depends on the application. If RSVP signaling is "on-path" as used in IntServ, then it needs to be forwarded from the same queue (service class) and marked with the same DSCP value as application data that it is controlling. This may also apply to the "on-path" Next Steps in Signaling (NSIS) protocol. o If IGMP is used for multicast session control such as channel changing in IPTV systems, then IGMP packets should be marked with CS5 DSCP (use Signaling service class). When IGMP is used only for the normal multicast routing purpose, it should be marked with CS6 DSCP (use Network Control service class).
o 在许多使用H.248、MEGACO、MGCP、IP封装ISDN或专有协议的IP电话实现中使用的客户机-服务器信令用CS5 DSCP（使用信令服务类）标记。o使用SIP、SIP-T或IP封装的ISUP在运营商网络中的呼叫服务器或软交换机之间进行信令，并用CS5 DSCP（使用信令服务类别）进行标记。o RSVP信令取决于应用程序。如果RSVP信令在IntServ中使用的是“在路径上”，那么它需要从同一队列（服务类）转发，并用与其控制的应用程序数据相同的DSCP值标记。这也可能适用于信令（NSIS）协议中的“路径上”后续步骤。o如果IGMP用于多播会话控制，如IPTV系统中的信道更改，则IGMP数据包应标记为CS5 DSCP（使用信令服务类）。当IGMP仅用于正常多播路由目的时，应使用CS6 DSCP（使用网络控制服务类）进行标记。
From tests that were performed, indications are that precise time distribution requires a very low packet delay variation (jitter) transport. Therefore, we suggest that the following guidelines for Network Time Protocol (NTP) be used:
从所执行的测试中可以看出，精确的时间分布需要非常低的数据包延迟变化（抖动）传输。因此，我们建议使用以下网络时间协议（NTP）指南：
o When NTP is used for providing high-accuracy timing within an administrator's (carrier's) network or to end users/clients, the Telephony service class should be used, and NTP packets should be marked with EF DSCP value. o For applications that require "wall clock" timing accuracy, the Standard service class should be used, and packets should be marked with DF DSCP.
o 当NTP用于在管理员（运营商）网络内或向最终用户/客户端提供高精度定时时，应使用电话服务类别，并且NTP数据包应标记EF DSCP值。o对于需要“挂钟”计时精度的应用程序，应使用标准服务类别，并且数据包应标有DF DSCP。
"Differentiated Services and Tunnels" [RFC2983] considers the interaction of DiffServ architecture with IP tunnels of various forms. Further to guidelines provided in RFC 2983, below are additional guidelines for mapping service classes that are supported in one part of the network into a VPN connection. This discussion is limited to VPNs that use DiffServ technology for traffic differentiation.
“区分服务和隧道”[RFC2983]考虑了区分服务体系结构与各种形式的IP隧道的交互。除了RFC 2983中提供的指南之外，下面是将网络的一部分中支持的服务类映射到VPN连接的其他指南。此讨论仅限于使用区分服务技术进行流量区分的VPN。
o The DSCP value(s) that is/are used to represent a PHB or a PHB group should be the same for the networks at both ends of the VPN tunnel, unless remarking of DSCP is done as ingress/egress processing function of the tunnel. DSCP marking needs to be preserved end to end.
o 用于表示PHB或PHB组的DSCP值对于VPN隧道两端的网络应相同，除非将DSCP标记为隧道的入口/出口处理功能。DSCP标记需要端到端保留。
o The VPN may be configured to support one or more service classes. It is left up to the administrators of the two networks to agree on the level of traffic differentiation that will be provided in the network that supports VPN service. Service classes are then mapped into the supported VPN traffic forwarding behaviors that meet the traffic characteristics and performance requirements of the encapsulated service classes. o The traffic treatment in the network that is providing the VPN service needs to be such that the encapsulated service class or classes receive comparable behavior and performance in terms of delay, jitter, and packet loss and that they are within the limits of the service specified. o The DSCP value in the external header of the packet forwarded through the network providing the VPN service may be different from the DSCP value that is used end to end for service differentiation in the end network. o The guidelines for aggregation of two or more service classes into a single traffic forwarding treatment in the network that is providing the VPN service is for further study.
o VPN可以配置为支持一个或多个服务类别。由两个网络的管理员就支持VPN服务的网络中提供的流量差异级别达成一致。然后将服务类映射到支持的VPN流量转发行为中，以满足封装服务类的流量特征和性能要求。o提供VPN服务的网络中的流量处理需要确保封装的一个或多个服务类在延迟、抖动和数据包丢失方面收到可比的行为和性能，并且它们在指定服务的限制范围内。o通过提供VPN服务的网络转发的数据包的外部报头中的DSCP值可能不同于端到端用于在端网络中区分服务的DSCP值。o在提供VPN服务的网络中，将两个或多个服务类别聚合为单个流量转发处理的指南供进一步研究。
This document discusses policy and describes a common policy configuration, for the use of a Differentiated Services Code Point by transports and applications. If implemented as described, it should require that the network do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy.
本文档讨论了传输和应用程序使用差异化服务代码点的策略，并描述了常见的策略配置。如果按照所述实施，则应要求网络不做任何网络不允许的事情。如果是这样的话，那么使用这样的策略不应该产生新的安全问题。
It is possible for the policy to be applied incorrectly, or for a wrong policy to be applied in the network for the defined service class. In that case, a policy issue exists that the network SHOULD detect, assess, and deal with. This is a known security issue in any network dependent on policy-directed behavior.
策略可能应用不正确，或者在网络中为定义的服务类应用错误的策略。在这种情况下，网络应该检测、评估和处理一个策略问题。这是任何依赖于策略导向行为的网络中的已知安全问题。
A well-known flaw appears when bandwidth is reserved or enabled for a service (for example, voice transport) and another service or an attacking traffic stream uses it. This possibility is inherent in DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, the use of authentication and flow admission is recommended. To the author's knowledge, there is no known technical way to respond to an unauthenticated data stream using service that it is not intended to use, and such is the nature of the Internet.
当为一项服务（例如，语音传输）保留或启用带宽，而另一项服务或攻击流量流使用带宽时，就会出现一个众所周知的缺陷。这种可能性是DiffServ技术固有的，它依赖于适当的数据包标记。当在易受攻击的网络中使用带宽保留或优先级排队系统时，建议使用身份验证和流许可。据作者所知，目前还没有已知的技术方法可以使用不打算使用的服务来响应未经验证的数据流，这就是互联网的本质。
The use of a service class by a user is not an issue when the SLA between the user and the network permits him to use it, or to use it up to a stated rate. In such cases, simple policing is used in the
当用户和网络之间的SLA允许用户使用服务类，或者允许用户以规定的速率使用服务类时，用户使用服务类不是问题。在这种情况下，警察局采用简单的治安措施
Differentiated Services Architecture. Some service classes, such as Network Control, are not permitted to be used by users at all; such traffic should be dropped or remarked by ingress filters. Where service classes are available under the SLA only to an authenticated user rather than to the entire population of users, authentication and authorization services are required, such as those surveyed in [AUTHMECH].
区分服务体系结构。某些服务类别，如网络控制，根本不允许用户使用；此类流量应通过入口过滤器丢弃或标记。如果SLA下的服务类仅对经过身份验证的用户可用，而不是对所有用户可用，则需要身份验证和授权服务，如[AUTHMECH]中调查的服务。
The authors thank the TSVWG reviewers, David Black, Brian E. Carpenter, and Alan O'Neill for their review and input to this document.
作者感谢TSVWG评审员David Black、Brian E.Carpenter和Alan O'Neill对本文件的评审和投入。
The authors acknowledge a great many inputs, most notably from Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe Zebarth, and Alistair Munroe each did a thorough proofreading, and the document is better for their contributions.
作者承认了大量的投入，最著名的是布鲁斯·戴维斯、戴夫·奥兰、拉尔夫·桑蒂托、加里·肯沃德、弗朗索瓦·奥德特、摩根·利特伍德、罗伯特·米尔恩、约翰·舒勒、纳林·米斯特里、艾尔·莫顿、迈克·皮尔斯、小埃德·科勒、蒂姆·拉赫勒、费尔·狄金森、迈克·菲德勒和谢恩·阿曼特。金伯利·金（Kimberly King）、乔·泽伯斯（Joe Zebarth）和阿利斯泰尔·门罗（Alistair Munroe）三人都做了彻底的校对，这份文件更符合他们的贡献。
The term "ring clipping" refers to those instances where the front end of a ringing signal is altered because the bearer channel is not made available in time to carry all the audible ringing signal. This condition may occur due to a race condition between when the tone generator located in the circuit switch Exchange is turned on and when the bearer path through the IP network is enabled. To reduce ring clipping from occurring, delay of signaling path needs to be minimized. Below is a more detailed explanation.
术语“环削波”是指由于承载信道未及时提供以承载所有音频振铃信号而改变振铃信号前端的那些实例。这种情况可能是由于位于电路交换机交换机中的音调发生器接通时与通过IP网络的承载路径启用时之间的竞争情况造成的。为了减少环削波的发生，需要最小化信令路径的延迟。下面是更详细的解释。
The bearer path setup delay target is defined as the ISUP Initial Address Message (IAM) / Address Complete Message (ACM) round-trip delay. ISUP refers to ISDN User Part of Signaling System No. 7 (SS7), as defined by ITU-T. This consists of the amount of time it takes for the ISUP Initial Address Message (IAM) to leave the Transit Exchange, travel through the SS7 network (including any applicable STPs, or Signaling Transfer Points), and be processed by the End Exchange thus generating the Address Complete Message (ACM) and for the ACM to travel back through the SS7 network and return to the Transit Exchange. If the bearer path has not been set up within the soft-switch media gateway and the IP network that is performing the Transit Exchange function by the time the ACM is forwarded to the originating End Exchange, the phenomenon known as ring clipping may occur. If ACM processing within the soft-switch media gateway and delay through the IP network is excessive, it will delay the setup of the bearer path, and therefore may cause clipping of the ring tone to be heard.
承载路径设置延迟目标定义为ISUP初始地址消息（IAM）/地址完成消息（ACM）往返延迟。ISUP是指ITU-T定义的7号信令系统（SS7）的ISDN用户部分。这包括ISUP初始地址消息（IAM）离开转接交换机、通过SS7网络（包括任何适用的STP或信令传输点）所需的时间量，并由终端交换机处理，从而生成地址完整消息（ACM），并使ACM通过SS7网络返回并返回到中转交换机。如果在ACM被转发到始发端交换机时，承载路径尚未在软交换媒体网关和正在执行传输交换功能的IP网络内建立，则可能发生称为环削波的现象。如果软交换媒体网关内的ACM处理和通过IP网络的延迟过大，则会延迟承载路径的设置，因此可能导致听到铃声的剪辑。
The intra-exchange ISUP IAM signaling delay value should not exceed 240ms. This may include soft-switch, media gateway, router, and propagation delay on the inter-exchange data path. This value represents the threshold where ring clipping theoretically commences. It is important to note that the 240ms delay objective as presented is a maximum value. Service administrators are free to choose specific IAM delay values according to their own preferences (i.e., they may wish to set a very low mean delay objective for strategic reasons to differentiate themselves from other providers). In summary, out of the 240-ms delay budget, 200ms is allocated as cross-Exchange delay (soft-switch and media gateway) and 40ms for network delay (queuing and distance).
内部交换ISUP IAM信令延迟值不应超过240ms。这可能包括软交换、媒体网关、路由器和交换间数据路径上的传播延迟。该值表示环剪裁理论上开始的阈值。需要注意的是，所提出的240ms延迟目标是一个最大值。服务管理员可以根据自己的偏好自由选择特定的IAM延迟值（即，出于战略原因，他们可能希望设置非常低的平均延迟目标，以区别于其他提供商）。总之，在240毫秒的延迟预算中，200毫秒分配为交叉交换延迟（软交换和媒体网关），40毫秒分配为网络延迟（排队和距离）。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349]Almquist，P.，“互联网协议套件中的服务类型”，RFC1349，1992年7月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 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.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2474] 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.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]Bless，R.，Nichols，K.，和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 36622003年12月。
[AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, September 2005.
[AUTHMECH]Rescorla，E.，“认证机制的调查”，正在进行的工作，2005年9月。
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 Technical Report Proposed Service Definition, March 2001.
[QBSS]“QBone清道夫服务（QBSS）定义”，第二代互联网技术报告，建议服务定义，2001年3月。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697]Heinanen，J.和R.Guerin，“单速率三色标记”，RFC 26971999年9月。
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999.
[RFC2698]Heinanen，J.和R.Guerin，“双速率三色标记”，RFC 26981999年9月。
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper for Differentiated Services", RFC 2963, October 2000.
[RFC2963]Bonaventure，O.和S.De Cnodder，“差异化服务的速率自适应成形器”，RFC 2963，2000年10月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996]Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086]Nichols，K.和B.Carpenter，“每域区分服务行为的定义及其规范规则”，RFC 3086，2001年4月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290]Bernet，Y.，Blake，S.，Grossman，D.，和A.Smith，“区分服务路由器的非正式管理模型”，RFC 32902002年5月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782]Floyd，S.，Henderson，T.，和A.Gurtov，“TCP快速恢复算法的NewReno修改”，RFC 3782，2004年4月。
Authors' Addresses
作者地址
Jozef Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada
安大略省渥太华市卡林大道3500号Jozef Babiarz Nortel Networks。K2H 8E9加拿大
Phone: +1-613-763-6098
Fax: +1-613-765-7462
EMail: babiarz@nortel.com
Phone: +1-613-763-6098
Fax: +1-613-765-7462
EMail: babiarz@nortel.com
Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
郭浩灿北电网络美国马萨诸塞州比利里卡科技园路600号01821
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州，美国93117
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。