Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 5865 J. Polk
Updates: 4542, 4594 Cisco Systems
Category: Standards Track M. Dolly
ISSN: 2070-1721 AT&T Labs
May 2010
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 5865 J. Polk
Updates: 4542, 4594 Cisco Systems
Category: Standards Track M. Dolly
ISSN: 2070-1721 AT&T Labs
May 2010
A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
容量允许流量的区分服务代码点（DSCP）
Abstract
摘要
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.
本文件要求互联网分配号码管理局（IANA）为一类实时流量提供一个区分服务代码点（DSCP）。此流量类别符合每跳加速转发行为。网络还使用涉及认证、授权和容量接纳的呼叫接纳控制（CAC）过程接纳该流量。这不同于符合每跳加速转发行为但不受容量许可或非常粗略的容量许可约束的实时流量类别。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5865.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5865.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Candidate Implementations of the Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . 9
2.3. Recommendations on implementation of an Admitted
Telephony Service Class . . . . . . . . . . . . . . . . . 10
3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Candidate Implementations of the Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . 9
2.3. Recommendations on implementation of an Admitted
Telephony Service Class . . . . . . . . . . . . . . . . . 10
3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This class conforms to the Expedited Forwarding (EF) [RFC3246] [RFC3247] Per-Hop Behavior. It is also admitted using a CAC procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.
本文件要求互联网分配号码管理局（IANA）为一类实时流量提供一个区分服务代码点（DSCP）。此类符合加速转发（EF）[RFC3246][RFC3247]每跳行为。它还可以使用涉及身份验证、授权和容量许可的CAC过程进行许可。这不同于符合每跳加速转发行为但不受容量许可或非常粗略的容量许可约束的实时流量类别。
In addition, this document recommends that certain classes of video described in [RFC4594] be treated as requiring capacity admission.
此外，本文件建议将[RFC4594]中描述的某些类别的视频视为需要容量许可。
Real-time traffic flows have one or more potential congestion points between the endpoints. Reserving capacity for these flows is important to application performance. All of these applications have low tolerance to jitter (aka delay variation) and loss, as summarized in Section 2, and most (except for multimedia conferencing) have inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow behavior and low jitter/loss tolerance are the service characteristics that define the need for admission control behavior.
实时交通流在端点之间有一个或多个潜在的拥塞点。为这些流保留容量对于应用程序性能很重要。如第2节所述，所有这些应用对抖动（又称延迟变化）和损耗的容忍度都很低，并且大多数（多媒体会议除外）具有[RFC4594]图1中的非弹性流行为。非弹性流行为和低抖动/损耗容限是定义准入控制行为需求的服务特征。
One of the reasons behind the requirement for capacity admission is the need for classes of traffic that are handled under special policies. Service providers need to distinguish between special-policy traffic and other classes, particularly the existing Voice over IP (VoIP) services that perform no capacity admission or only very coarse capacity admission and can exceed their allocated resources.
通行能力准入要求背后的一个原因是需要根据特殊政策处理不同类别的交通。服务提供商需要区分特殊策略流量和其他类别，特别是现有的IP语音（VoIP）服务，这些服务不执行容量许可或仅执行非常粗略的容量许可，并且可能超过其分配的资源。
The requested DSCP applies to the Telephony Service Class described in [RFC4594].
请求的DSCP适用于[RFC4594]中描述的电话服务类。
Since video classes have not had the history of mixing admitted and non-admitted traffic in the same Per-Hop Behavior (PHB) as has occurred for EF, an additional DSCP code point is not recommended within this document for video. Instead, the recommended "best practice" is to perform admission control for all traffic in three of the video classes from [RFC4594]:
由于视频类没有以与EF相同的每跳行为（PHB）混合接纳和非接纳流量的历史，因此不建议在本文档中为视频添加额外的DSCP代码点。相反，建议的“最佳实践”是对[RFC4594]中三个视频类中的所有流量执行准入控制：
o The Interactive Real-Time Traffic (CS4, used for Video conferencing and Interactive gaming),
o 交互式实时流量（CS4，用于视频会议和交互式游戏），
o The Broadcast TV (CS3) for use in a video on demand context, and
o 用于视频点播上下文的广播电视（CS3），以及
o The AF4 Multimedia Conferencing (video conferencing).
o AF4多媒体会议（视频会议）。
Other video classes are believed not to have the current problem of confusion with unadmitted traffic and therefore would not benefit from the notion of a separate DSCP for admitted traffic. Within an ISP and on inter-ISP links (i.e., within networks whose internal paths are uniform at hundreds of megabits per second or faster), one would expect all of this traffic to be carried in the Real-Time Traffic (RTP) class described in [RFC5127].
其他视频类被认为不存在当前与未经许可的流量混淆的问题，因此不会从单独的DSCP概念中受益。在ISP内和ISP间链路上（即，在内部路径以每秒数百兆比特或更快的速度一致的网络内），所有这些通信量都将以[RFC5127]中所述的实时通信量（RTP）类别进行传输。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following terms and acronyms are used in this document.
本文件中使用了以下术语和首字母缩略词。
PHB: A Per-Hop Behavior (PHB) is the externally observable forwarding behavior applied at a Differentiated Services compliant node to a DS behavior aggregate [RFC2475]. It may be thought of as a program configured on the interface of an Internet host or router, specified in terms of drop probabilities, queuing priorities or rates, and other handling characteristics for the traffic class.
PHB:Per-Hop Behavior（PHB）是在符合区分服务的节点上应用于DS行为聚合的外部可观察的转发行为[RFC2475]。它可以被认为是在因特网主机或路由器的接口上配置的程序，根据丢弃概率、排队优先级或速率以及流量类别的其他处理特征来指定。
DSCP: The Differentiated Services Code Point (DSCP), as defined in [RFC2474], is a value that is encoded in the DS field, and that each DS Node MUST use to select the PHB that is to be experienced by each packet it forwards [RFC3260]. It is a 6-bit number embedded into the 8-bit TOS (type of service) field of an IPv4 datagram or the Traffic Class field of an IPv6 datagram.
DSCP:[RFC2474]中定义的区分服务代码点（DSCP）是一个在DS字段中编码的值，每个DS节点必须使用该值来选择其转发的每个数据包将经历的PHB[RFC3260]。它是嵌入IPv4数据报的8位TOS（服务类型）字段或IPv6数据报的流量类别字段中的6位数字。
CAC: Call Admission Control includes concepts of authorization and capacity admission. "Authorization" refers to any procedure that identifies a user, verifies the authenticity of the identification, and determines whether the user is authorized to use the service under the relevant policy. "Capacity Admission" refers to any procedure that determines whether capacity exists supporting a session's requirements under some policy.
CAC：呼叫接纳控制包括授权和容量接纳的概念。“授权”是指识别用户、验证身份真实性并确定用户是否有权根据相关政策使用服务的任何程序。“容量许可”是指根据某些策略确定是否存在支持会话要求的容量的任何程序。
In the Internet, these are separate functions; while in the Public Switched Telephone Network (PSTN), they and call routing are carried out together.
在互联网上，这些是独立的功能；而在公共交换电话网（PSTN）中，它们和呼叫路由一起执行。
UNI: A User/Network Interface (UNI) is the interface (often a physical link or its virtual equivalent) that connects two entities that do not trust each other, and in which one (the user) purchases connectivity services from the other (the network).
UNI：用户/网络接口（UNI）是连接两个彼此不信任的实体的接口（通常是物理链路或其虚拟等效物），其中一个（用户）从另一个（网络）购买连接服务。
Figure 1 shows two user networks connected by what appears to each of them to be a single network ("The Internet", access to which is provided by their service provider) that provides connectivity services to other users.
图1显示了两个用户网络，它们通过一个单独的网络（“互联网”，由其服务提供商提供访问）连接起来，该网络向其他用户提供连接服务。
UNIs tend to be the bottlenecks in the Internet, where users purchase relatively low amounts of bandwidth for cost or service reasons, and as a result are most subject to congestion issues and therefore issues requiring traffic conditioning and service prioritization.
UNIs往往是互联网的瓶颈，用户出于成本或服务原因购买相对较低的带宽，因此最容易出现拥塞问题，因此需要流量调节和服务优先级。
NNI: A Network/Network Interface (NNI) is the interface (often a physical link or its virtual equivalent) that connects two entities that trust each other within limits, and in which the two are seen as trading services for value. Figure 1 shows three service networks that together provide the connectivity services that we call "the Internet". They are different administrations and are very probably in competition, but exchange contracts for connectivity and capacity that enable them to offer specific services to their customers.
NNI：网络/网络接口（NNI）是一种接口（通常是物理链路或其虚拟等效物），用于连接在一定范围内相互信任的两个实体，并将这两个实体视为价值交易服务。图1显示了三个服务网络，它们共同提供我们称之为“Internet”的连接服务。它们是不同的管理机构，很可能处于竞争中，但交换连接和容量合同，使它们能够向客户提供特定服务。
NNIs may not be bottlenecks in the Internet if service providers contractually agree to provision excess capacity at them, as they commonly do. However, NNI performance may differ by ISP, and the performance guarantee interval may range from a month to a much shorter period. Furthermore, a peering point NNI may not have contractual performance guarantees or may become overloaded under certain conditions. They are also policy-controlled interfaces, especially in BGP. As a result, they may require a traffic prioritization policy.
如果服务提供商按照合同约定提供过剩容量，NNI可能不会成为互联网的瓶颈，就像他们通常做的那样。但是，ISP的NNI性能可能有所不同，性能保证期可能从一个月到更短的时间段不等。此外，对等点NNI可能没有合同性能保证，或者在某些条件下可能过载。它们也是策略控制的接口，特别是在BGP中。因此，他们可能需要流量优先级策略。
Queue: There are multiple ways to build a multi-queue scheduler. Weighted Round Robin (WRR) literally builds multiple lists and visits them in a specified order, while a calendar queue (often used to implement Weighted Fair Queuing, or WFQ) builds a list for each time interval and queues at most a stated amount of data in each such list for transmission during that time interval. While these differ dramatically in implementation, the external difference in behavior is generally negligible when they are properly configured. Consistent with the definitions used in the Differentiated Services Architecture [RFC2475], these are treated as
队列：有多种方法可以构建多队列调度程序。加权循环（WRR）字面上构建多个列表并按指定顺序访问它们，而日历队列（通常用于实现加权公平队列或WFQ）为每个时间间隔构建一个列表，并在每个这样的列表中最多排队指定数量的数据，以便在该时间间隔内传输。虽然它们在实现上有很大的不同，但是当它们被正确配置时，行为上的外部差异通常可以忽略。与区分服务体系结构[RFC2475]中使用的定义一致，这些定义被视为
equivalent in this document, and the lists of WRR and the classes of a calendar queue will be referred to uniformly as "queues".
在本文件中等效，WRR列表和日历队列的类将统一称为“队列”。
_.--------.
,-'' `--.
,-' `-.
,-------. ,',-------. `.
,' `. ,',' `. `.
/ User \ UNI / / Service \ \
( Network +-----+ Network ) `.
\ / ; \ / :
`. ,' ; `. .+ :
'-------' / '-------' \ NNI \
; \ :
; "The Internet" \ ,-------. :
; +' `. :
UNI: User/Network Interface / Service \ |
| ( Network ) |
NNI: Network/Network Interface \ / |
: +. ,' ;
: / '-------' ;
: / ;
,-------. \ ,-------. / NNI /
,' `. : ,' `+ ;
/ User \ UNI / Service \ ;
( Network +-----+ Network ) ,'
\ / \ \ / /
`. ,' `.`. ,' ,'
'-------' `.'-------' ,'
`-. ,-'
`--. _.-'
`--------''
_.--------.
,-'' `--.
,-' `-.
,-------. ,',-------. `.
,' `. ,',' `. `.
/ User \ UNI / / Service \ \
( Network +-----+ Network ) `.
\ / ; \ / :
`. ,' ; `. .+ :
'-------' / '-------' \ NNI \
; \ :
; "The Internet" \ ,-------. :
; +' `. :
UNI: User/Network Interface / Service \ |
| ( Network ) |
NNI: Network/Network Interface \ / |
: +. ,' ;
: / '-------' ;
: / ;
,-------. \ ,-------. / NNI /
,' `. : ,' `+ ;
/ User \ UNI / Service \ ;
( Network +-----+ Network ) ,'
\ / \ \ / /
`. ,' `.`. ,' ,'
'-------' `.'-------' ,'
`-. ,-'
`--. _.-'
`--------''
Figure 1: UNI and NNI Interfaces
图1:UNI和NNI接口
In short, the Telephony Service Class, described in [RFC4594], permits the use of capacity admission in implementing the service, but present implementations either provide no capacity admission services or do so in a manner that depends on specific traffic engineering. In the context of the Internet backbone, the two are essentially equivalent; the edge network depends on specific engineering by the service provider that might not be present, especially in a mobile environment.
简而言之，[RFC4594]中描述的电话服务类允许在实现服务时使用容量许可，但目前的实现要么不提供容量许可服务，要么以依赖于特定流量工程的方式提供容量许可服务。在互联网主干网的背景下，两者基本上是等价的；边缘网络取决于服务提供商可能不存在的特定工程，特别是在移动环境中。
However, services are being requested of the network that would specifically make use of capacity admission, and would distinguish among users or the uses of available Voice-over-IP or Video-over-IP capacity in various ways. Various agencies would like to provide services as described in RFC [RFC4190] or in Section 2.6 of [RFC4504].
然而，正在向网络请求专门利用容量许可的服务，并以各种方式区分用户或可用IP语音或IP视频容量的使用。各机构希望提供RFC[RFC4190]或[RFC4504]第2.6节所述的服务。
This requires the use of capacity admission to differentiate among users to provide services to them that are not afforded to non-capacity admitted customer-to-customer IP telephony sessions.
这就需要使用容量许可来区分向他们提供服务的用户，而这些服务不提供给非容量许可的客户对客户IP电话会话。
There are at least two possible ways to implement isolation between the Capacity Admitted PHB and the Expedited Forwarding PHB in this model. They are to implement separate classes as a set of
在该模型中，至少有两种可能的方法来实现允许容量的PHB和快速转发PHB之间的隔离。它们将实现一组单独的类
o Multiple data plane traffic classes, each consisting of a policer and a queue, with the queues enjoying different priorities, or
o 多个数据平面流量类，每个类由一个policer和一个队列组成，队列具有不同的优先级，或者
o Multiple data plane traffic classes, each consisting of a policer but feeding into a common queue or multiple queues at the same priority.
o 多个数据平面流量类，每个类由一个policer组成，但以相同优先级馈入一个公共队列或多个队列。
We will explain the difference and describe in what way they differ in operation. The reason this is necessary is that there is current confusion in the industry.
我们将解释这种差异，并描述它们在操作上的差异。之所以有必要这样做，是因为该行业目前存在混乱。
The multi-priority model is shown in Figure 2. In this model, traffic from each service class is placed into a separate priority queue. If data is present in more than one queue, traffic from one of them will always be selected for transmission. This has the effect of transferring jitter from the higher-priority queue to the lower-priority queues, and reordering traffic in a way that gives the higher-priority traffic a smaller average queuing delay. Each queue must have its own policer, however, to protect the network from errors and attacks; if a traffic class thinks it is carrying a certain data rate but an abuse sends significantly more, the effect of simple prioritization would not preserve the lower priorities of traffic, which could cause routing to fail or otherwise impact a service level agreement (SLA).
多优先级模型如图2所示。在该模型中，来自每个服务类别的流量被放入一个单独的优先级队列中。如果数据存在于多个队列中，则将始终选择其中一个队列中的流量进行传输。这具有将抖动从高优先级队列转移到低优先级队列的效果，并以使高优先级流量具有较小平均排队延迟的方式重新排序流量。但是，每个队列必须有自己的策略，以保护网络免受错误和攻击；如果某个流量类别认为它承载了一定的数据速率，但滥用发送的数据速率明显更高，那么简单的优先级排序不会保留较低的流量优先级，这可能导致路由失败或影响服务级别协议（SLA）。
.
policers priorities |`.
Admitted EF <=> ----------||----+ `.
high| `.
Unadmitted EF <=> ----------||----+ .'-----------
. medium .'
rate queues |`. +-----+ .' Priority
AF1------>||----+ `. / low |' Scheduler
| `. /
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)
.
policers priorities |`.
Admitted EF <=> ----------||----+ `.
high| `.
Unadmitted EF <=> ----------||----+ .'-----------
. medium .'
rate queues |`. +-----+ .' Priority
AF1------>||----+ `. / low |' Scheduler
| `. /
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)
Figure 2: Implementation as a Data Plane Priority
图2：作为数据平面优先级的实现
The multi-policer model is shown in Figure 3. In this model, traffic from each service class is policed according to its SLA requirements, and then placed into a common priority queue. Unlike the multi-priority model, the jitter experienced by the traffic classes in this case is the same, as there is only one queue, but the sum of the traffic in this higher-priority queue experiences less average jitter than the elastic traffic in the lower-priority.
多策略模型如图3所示。在该模型中，来自每个服务类别的流量根据其SLA要求进行策略控制，然后放入公共优先级队列。与多优先级模型不同，在这种情况下，流量类别所经历的抖动是相同的，因为只有一个队列，但与低优先级的弹性流量相比，此高优先级队列中的流量总和所经历的平均抖动更小。
policers priorities .
Admitted EF <=> -------\ |`.
--||----+ `.
Unadmitted EF <=> -------/ high| `.
. | .'--------
rate queues |`. +-----+ .'
AF1------>||----+ `. / low | .' Priority
| `. / |' Scheduler
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)
policers priorities .
Admitted EF <=> -------\ |`.
--||----+ `.
Unadmitted EF <=> -------/ high| `.
. | .'--------
rate queues |`. +-----+ .'
AF1------>||----+ `. / low | .' Priority
| `. / |' Scheduler
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)
Figure 3: Implementation as a Data Plane Policer
图3：作为数据平面策略的实现
The difference between the two operationally is, as stated, the issues of loss due to policing and distribution of jitter.
如前所述，二者在操作上的区别在于由于监管和抖动分布而造成的损失问题。
If the two traffic classes are, for example, voice and video, datagrams containing video data can be relatively large (often of variable sizes up to the path MTU), while datagrams containing voice are relatively small, on the order of only 40 to 200 bytes, depending on the codec. On lower-speed links (less than 10 MBPS), the jitter introduced by video to voice can be disruptive, while at higher
例如，如果两个流量类别是语音和视频，则包含视频数据的数据报可能相对较大（通常大小可变，直到路径MTU），而包含语音的数据报相对较小，大约只有40到200字节，具体取决于编解码器。在低速链路（小于10 MBPS）上，视频到语音引入的抖动可能会造成中断，而在高速链路上则会造成中断
speeds, the jitter is nominal compared to the jitter requirements of voice. Therefore, at access network speeds, [RFC4594] recommends the separation of video and voice into separate queues, while at optical speeds, [RFC5127] recommends that they use a common queue.
与语音的抖动要求相比，抖动是标称的。因此，在接入网络速度下，[RFC4594]建议将视频和语音分离为单独的队列，而在光速下，[RFC5127]建议使用公共队列。
If, on the other hand, the two traffic classes are carrying the same type of application with the same jitter requirements, then giving one preference in this sense does not benefit the higher-priority traffic and may harm the lower-priority traffic. In such a case, using separate policers and a common queue is a superior approach.
另一方面，如果两个通信量类别承载具有相同抖动要求的相同类型的应用程序，则在这种意义上给予一个优先权不利于较高优先级的通信量，并且可能损害较低优先级的通信量。在这种情况下，使用单独的策略和公共队列是一种更好的方法。
There are at least six major ways that capacity admission is done or has been proposed to be done for real-time applications. Each will be described below, and Section 3 will judge which ones are likely to meet the requirements of the Admitted Telephony service class. These include:
对于实时应用程序，至少有六种主要的容量许可方式。下文将对每一种服务进行描述，第3节将判断哪些服务可能满足认可电话服务类别的要求。这些措施包括：
o Drop Precedence used to force sessions to voluntarily exit,
o 删除用于强制会话自动退出的优先级，
o Capacity admission control by assumption or engineering,
o 通过假设或工程实现容量允许控制，
o Capacity admission control by call counting,
o 通过呼叫计数进行容量接纳控制，
o Endpoint capacity admission performed by probing the network,
o 通过探测网络执行端点容量许可，
o Centralized capacity admission control via bandwidth broker, and
o 通过带宽代理进行集中式容量许可控制，以及
o Distributed capacity admission control using protocols such as Resource Reservation Protocol (RSVP) or Next Steps in Signaling (NSIS).
o 使用诸如资源预留协议（RSVP）或信令中的后续步骤（NSIS）等协议的分布式容量接纳控制。
The problem with dropping traffic to force users to hang up is that it affects a broad class of users -- if there is capacity for N calls and the N+1 calls are active, data is dropped randomly from all sessions to ensure that offered load doesn't exceed capacity. On very fast links, that is acceptable, but on lower speed links it can seriously affect call quality. There is also a behavioral issue involved here, in which users who experience poor quality calls tend to hang up and call again, making the problem better -- then worse.
丢弃流量以迫使用户挂断的问题是，它会影响到一大类用户——如果有N个呼叫的容量，并且N+1个呼叫处于活动状态，则会从所有会话中随机丢弃数据，以确保提供的负载不会超过容量。在非常快的链路上，这是可以接受的，但在低速链路上，这会严重影响通话质量。这里还涉及到一个行为问题，在这个问题上，遇到质量差的电话的用户往往会挂断电话，然后再打电话，使问题变得更好，然后更糟。
The problem with capacity admission by assumption, which is widely deployed in today's VoIP environment, is that it depends on the assumptions made. One can do careful traffic engineering to ensure needed bandwidth, but this can also be painful, and has to be revisited when the network is changed or network usage changes.
在今天的VoIP环境中广泛使用的假设容量许可的问题在于，它取决于所做的假设。人们可以做仔细的流量工程来确保所需的带宽，但这也可能是痛苦的，当网络发生变化或网络使用发生变化时，必须重新考虑。
The problem with call-counting-based admission control is that it gets exponentially worse the farther you get from the control point (e.g., it lacks sufficient scalability on the outskirts of the network).
基于呼叫计数的准入控制的问题是，距离控制点越远，情况就越严重（例如，它在网络外围缺乏足够的可扩展性）。
There are two fundamental problems with depending on the endpoint to perform capacity admission: it may not be able to accurately measure the impact of the traffic it generates on the network, and it tends to be greedy (e.g., it doesn't care). If the network operator is providing a service, he must be able to guarantee the service, which means that he cannot trust systems that are not controlled by his network.
依赖端点执行容量接纳有两个基本问题：它可能无法准确测量它在网络上产生的流量的影响，并且它往往是贪婪的（例如，它不在乎）。如果网络运营商提供服务，他必须能够保证服务，这意味着他不能信任不受其网络控制的系统。
The problem with capacity controls via a bandwidth broker is that centralized servers lack far away awareness, and also lack effective real-time reaction to dynamic changes in all parts of the network at all instances of time.
通过带宽代理进行容量控制的问题在于，集中式服务器缺乏远距离感知，并且在任何时间都缺乏对网络所有部分动态变化的有效实时反应。
The problem with mechanisms that do not enable the association of a policy with the request is that they do not allow for multi-policy services, which are becoming important.
无法将策略与请求关联的机制的问题在于，它们不允许多策略服务，这一点正变得越来越重要。
The operator's choice of admission procedure MUST, for this DSCP, ensure the following:
对于该DSCP，运营商选择的准入程序必须确保：
o The actual links that a session uses have enough bandwidth to support it.
o 会话使用的实际链路有足够的带宽来支持它。
o New sessions are refused admission if there is inadequate bandwidth under the relevant policy.
o 根据相关政策，如果带宽不足，新会话将被拒绝。
o A user is identified and the correct policy is applied if multiple policies are in use in a network.
o 如果网络中使用多个策略，则会识别用户并应用正确的策略。
o Under periods of network stress, the process of admission of new sessions does not disrupt existing sessions, unless the service explicitly allows for disruption of calls.
o 在网络紧张时期，接纳新会话的过程不会中断现有会话，除非服务明确允许中断呼叫。
2.3. Recommendations on Implementation of an Admitted Telephony Service Class
2.3. 关于实施认可电话服务类别的建议
When coupled with adequate Authentication, Authorization, and Accounting (AAA) and capacity admission procedures as described in Section 2.2, either of the two PHB implementations described in Section 2.1 is sufficient to provide the services required for an Admitted Telephony service class. If preemption is required, Section 2.3.5.2 of [RFC4542] provides the tools for carrying out the preemption. If preemption is not in view, or if used in addition to
当与第2.2节所述的充分认证、授权和计费（AAA）和容量许可程序结合时，第2.1节所述的两种PHB实现中的任何一种都足以提供许可的电话服务类别所需的服务。如果需要抢占，则[RFC4542]第2.3.5.2节提供了实施抢占的工具。如果未考虑抢占权，或者在
preemptive services, the application of different thresholds depending on call precedence has the effect of improving the probability of call completion by admitting preferred calls at a time when other calls are being refused. Routine and priority traffic can be admitted using the same DSCP value, as the choice of which calls are admitted is handled in the admission procedure executed in the control plane, not the policing of the data plane.
抢占式服务，根据呼叫优先级应用不同的阈值，通过在其他呼叫被拒绝时接纳首选呼叫，可以提高呼叫完成的概率。可以使用相同的DSCP值接纳常规和优先级通信量，因为在控制平面中执行的接纳过程中处理接纳哪些呼叫的选择，而不是在数据平面的监管中。
On the point of what protocols and procedures are required for authentication, authorization, and capacity admission, we note that clear standards do not exist at this time for bandwidth brokers, NSIS has not been finalized at this time and in any event is limited to unicast sessions, and that RSVP has been standardized and has the relevant services. We therefore RECOMMEND the use of a protocol, such as RSVP, at the UNI. Procedures at the NNI are business matters to be discussed between the relevant networks, and are RECOMMENDED but NOT REQUIRED.
关于认证、授权和容量许可所需的协议和程序，我们注意到，目前没有针对带宽代理的明确标准，NSI目前尚未最终确定，并且在任何情况下仅限于单播会话，RSVP已经标准化并提供相关服务。因此，我们建议在UNI使用协议，如RSVP。NNI的程序是相关网络之间讨论的业务事项，是建议的，但不是必需的。
To summarize, there are two changes to [RFC4594] discussed in this document:
总之，本文件中讨论了[RFC4594]的两个变更：
Telephony class: The Telephony Service Class in RFC 4594 does not involve capacity admission, but depends on application layer admission that only estimates capacity, and does that through static engineering. In addition to that class, a separate Admitted Telephony Class is added that performs capacity admission dynamically.
电话类：RFC4594中的电话服务类不涉及容量许可，而是依赖于仅估计容量的应用层许可，并通过静态工程实现。除了该类之外，还添加了一个单独的允许的电话类，该类动态执行容量允许。
Video classes: Capacity admission is added to three video classes. These are the Interactive Real-Time Traffic class, Broadcast TV class when used for video on demand, and the Multimedia Conferencing class.
视频课程：三个视频课程增加了容量准入。这些课程包括交互式实时交通课程、用于视频点播的广播电视课程以及多媒体会议课程。
IANA assigned a DSCP value to a second EF traffic class consistent with [RFC3246] and [RFC3247] in the "Differentiated Services Field Codepoints" registry. It implements the Telephony Service Class described in [RFC4594] at lower speeds and is included in the Real-Time Treatment Aggregate [RFC5127] at higher speeds. The code point value should be from pool 1 within the dscp-registry. The value is parallel with the existing EF code point (101110), as IANA assigned
IANA将DSCP值分配给第二个EF通信量类别，该类别与“区分服务字段代码点”注册表中的[RFC3246]和[RFC3247]一致。它以较低的速度实现[RFC4594]中描述的电话服务类，并以较高的速度包含在实时处理聚合[RFC5127]中。代码点值应来自dscp注册表中的池1。该值与IANA指定的现有EF代码点（101110）平行
the code point 101100 -- keeping the (left-to-right) first 4 binary values the same in both. The code point described in this document is referred to as VOICE-ADMIT and has been registered as follows:
代码点101100——保持前4个二进制值（从左到右）在这两个值中相同。本文件中所述的代码点称为语音识别，其注册方式如下：
Sub-registry: Pool 1 Codepoints Reference: [RFC2474] Registration Procedures: Standards Action
子注册表：池1代码点参考：[RFC2474]注册程序：标准操作
Registry:
Name Space Reference
--------- ------- ---------
VOICE-ADMIT 101100 [RFC5865]
Registry:
Name Space Reference
--------- ------- ---------
VOICE-ADMIT 101100 [RFC5865]
This traffic class REQUIRES the use of capacity admission, such as RSVP services together with AAA services, at the User/Network Interface (UNI); the use of such services at the NNI is at the option of the interconnected networks.
该流量等级要求在用户/网络接口（UNI）处使用容量许可，例如RSVP服务和AAA服务；在NNI使用此类服务由互联网络选择。
A major requirement of this service is effective use of a signaling protocol, such as RSVP, with the capabilities to identify its user as either an individual or a member of some corporate entity, and assert a policy such as "normal", "routine", or some level of "priority".
该服务的一个主要要求是有效使用信令协议（如RSVP），能够将其用户识别为个人或某个公司实体的成员，并维护诸如“正常”、“常规”或某种级别的“优先级”等策略。
This capability, one has to believe, will be abused by script kiddies and others if the proof of identity is not adequately strong or if policies are written or implemented improperly by the carriers. This goes without saying, but this section is here for it to be said.
人们不得不相信，如果身份证明不够有力，或者如果运营商编写或执行的政策不正确，脚本儿童和其他人将滥用这种能力。这是不言而喻的，但这一节是要说的。
Many of the security considerations from RFC 3246 [RFC3246] apply to this document, as well as the security considerations in RFC 2474 and RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some gap analysis to the NSIS WG as they started their work. Keep in mind that this document is advocating RSVP at the UNI only, while RFC 4230 discusses (mostly) RSVP from a more complete point of view (i.e., e2e and edge2edge). When considering the RSVP aspect of this document, understanding Section 6 of RFC 4230 is a good source of information.
RFC 3246[RFC3246]中的许多安全注意事项以及RFC 2474和RFC 4542中的安全注意事项适用于本文档。RFC 4230[RFC4230]分析RSVP，在NSIS工作组开始工作时向其提供一些差距分析。请记住，本文件仅在UNI提倡RSVP，而RFC 4230（主要）从更完整的角度（即e2e和edge2edge）讨论RSVP。在考虑本文件的RSVP方面时，了解RFC 4230第6节是一个很好的信息来源。
Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe commented and offered text. The impetus for including video in the discussion, which initially only targeted voice, is from Dave McDysan.
陈国浩、乔治奥斯·卡拉吉安尼斯、丹·沃奇和鲍勃·布里斯科发表了评论并提供了文本。将视频纳入讨论的动力来自Dave McDysan，讨论最初只针对声音。
[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月。
[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月。
[RFC3246] Davie, B., Charny, A., Bennet, J., 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.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[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月。
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[RFC3247]Charny，A.，Bennet，J.，Benson，K.，Boudec，J.，Chiu，A.，Courtney，W.，Davari，S.，Firoiu，V.，Kalmanek，C.，和K.Ramakrishnan，“EF PHB（每跳快速转发行为）新定义的补充信息”，RFC 3247，2002年3月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[RFC4190]Carlberg，K.，Brown，I.，和C.Beard，“IP电话中支持紧急电信服务（ETS）的框架”，RFC 41902005年11月。
[RFC4504] Sinnreich, H., Ed., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.
[RFC4504]Sinnreich，H.，Ed.，Lass，S.，和C.Stredicke，“SIP电话设备要求和配置”，RFC 4504，2006年5月。
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4542]Baker，F.和J.Polk，“在互联网协议套件中为实时服务实施紧急电信服务（ETS）”，RFC 4542，2006年5月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008.
[RFC5127]Chan，K.，Babiarz，J.，和F.Baker，“区分服务类的聚合”，RFC 5127，2008年2月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月。
Authors' Addresses
作者地址
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
Phone: +1-408-526-4257
EMail: fred@cisco.com
Phone: +1-408-526-4257
EMail: fred@cisco.com
James Polk Cisco Systems Richardson, Texas 75082 USA
James Polk思科系统公司Richardson，德克萨斯州，美国75082
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Martin Dolly AT&T Labs Middletown Township, New Jersey 07748 USA
美国新泽西州米德尔顿镇马丁·多利AT&T实验室07748
Phone: +1-732-420-4574
EMail: mdolly@att.com
Phone: +1-732-420-4574
EMail: mdolly@att.com