Network Working Group K. Nichols
Request for Comments: 2474 Cisco Systems
Obsoletes: 1455, 1349 S. Blake
Category: Standards Track Torrent Networking Technologies
F. Baker
Cisco Systems
D. Black
EMC Corporation
December 1998
Network Working Group K. Nichols
Request for Comments: 2474 Cisco Systems
Obsoletes: 1455, 1349 S. Blake
Category: Standards Track Torrent Networking Technologies
F. Baker
Cisco Systems
D. Black
EMC Corporation
December 1998
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
IPv4和IPv6标头中区分服务字段（DS字段）的定义
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of:
互联网协议的差异化服务增强旨在实现互联网中的可伸缩服务区分，而无需每流状态和每跳信令。可以从部署在网络节点中的一组小的、定义良好的构建块构建各种服务。服务可以是端到端或域内服务；它们包括能够满足定量性能要求（例如，峰值带宽）和基于相对性能的要求（例如，“等级”差异）。服务可以通过以下组合构建：
- setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts), - using those bits to determine how packets are forwarded by the nodes inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.
- 在网络边界（自治系统边界、内部管理边界或主机）的IP报头字段中设置位，使用这些位确定网络内节点如何转发数据包，并根据每个服务的要求或规则调整网络边界处标记的数据包。
The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity.
每个服务的要求或规则必须通过本文档范围之外的管理策略机制进行设置。区分服务兼容网络节点包括基于DS字段的值选择分组的分类器，以及能够递送由DS字段值指示的特定分组转发处理的缓冲器管理和分组调度机制。DS字段的设置和标记分组的时间行为的调节只需要在网络边界处执行，并且可能在复杂性上有所不同。
This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.
本文档定义了IP头字段，称为DS（用于区分服务）字段。在IPv4中，它定义了TOS八位组的布局；在IPv6中，通信量类八位字节。此外，还定义了一组基本的数据包转发处理或每跳行为。
For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].
要更全面地了解区分服务，请参见区分服务体系结构[ARCH]。
Table of Contents
目录
1. Introduction ................................................. 3
2. Terminology Used in This Document ............................ 5
3. Differentiated Services Field Definition ..................... 7
4. Historical Codepoint Definitions and PHB Requirements ........ 9
4.1 A Default PHB ............................................. 9
4.2 Once and Future IP Precedence Field Use ................... 10
4.2.1 IP Precedence History and Evolution in Brief .......... 10
4.2.2 Subsuming IP Precedence into Class Selector .......... 11
Codepoints
4.2.2.1 The Class Selector Codepoints ..................... 11
4.2.2.2 The Class Selector PHB Requirements ............... 11
4.2.2.3 Using the Class Selector PHB Requirements ......... 12
for IP Precedence Compatibility
4.2.2.4 Example Mechanisms for Implementing Class ......... 12
Selector Compliant PHB Groups
4.3 Summary ................................................... 13
5. Per-Hop Behavior Standardization Guidelines .................. 13
6. IANA Considerations .......................................... 14
7. Security Considerations ...................................... 15
7.1 Theft and Denial of Service ............................... 15
7.2 IPsec and Tunneling Interactions .......................... 16
8. Acknowledgments .............................................. 17
9. References ................................................... 17
Authors' Addresses ............................................... 19
Full Copyright Statement ......................................... 20
1. Introduction ................................................. 3
2. Terminology Used in This Document ............................ 5
3. Differentiated Services Field Definition ..................... 7
4. Historical Codepoint Definitions and PHB Requirements ........ 9
4.1 A Default PHB ............................................. 9
4.2 Once and Future IP Precedence Field Use ................... 10
4.2.1 IP Precedence History and Evolution in Brief .......... 10
4.2.2 Subsuming IP Precedence into Class Selector .......... 11
Codepoints
4.2.2.1 The Class Selector Codepoints ..................... 11
4.2.2.2 The Class Selector PHB Requirements ............... 11
4.2.2.3 Using the Class Selector PHB Requirements ......... 12
for IP Precedence Compatibility
4.2.2.4 Example Mechanisms for Implementing Class ......... 12
Selector Compliant PHB Groups
4.3 Summary ................................................... 13
5. Per-Hop Behavior Standardization Guidelines .................. 13
6. IANA Considerations .......................................... 14
7. Security Considerations ...................................... 15
7.1 Theft and Denial of Service ............................... 15
7.2 IPsec and Tunneling Interactions .......................... 16
8. Acknowledgments .............................................. 17
9. References ................................................... 17
Authors' Addresses ............................................... 19
Full Copyright Statement ......................................... 20
Differentiated services are intended to provide a framework and building blocks to enable deployment of scalable service discrimination in the Internet. The differentiated services approach aims to speed deployment by separating the architecture into two major components, one of which is fairly well-understood and the other of which is just beginning to be understood. In this, we are guided by the original design of the Internet where the decision was made to separate the forwarding and routing components. Packet forwarding is the relatively simple task that needs to be performed on a per-packet basis as quickly as possible. Forwarding uses the packet header to find an entry in a routing table that determines the packet's output interface. Routing sets the entries in that table and may need to reflect a range of transit and other policies as well as to keep track of route failures. Routing tables are maintained as a background process to the forwarding task. Further, routing is the more complex task and it has continued to evolve over the past 20 years.
差异化服务旨在提供一个框架和构建块，以便在互联网上部署可扩展的服务。区分服务方法旨在通过将体系结构分为两个主要组件来加快部署速度，其中一个组件已经被很好地理解，另一个刚刚开始被理解。在这方面，我们遵循互联网的原始设计，决定将转发和路由组件分离。数据包转发是一项相对简单的任务，需要在每个数据包的基础上尽快执行。转发使用数据包头在路由表中查找确定数据包输出接口的条目。路由设置该表中的条目，可能需要反映一系列运输和其他策略，并跟踪路由故障。路由表作为转发任务的后台进程进行维护。此外，路由是一项更为复杂的任务，在过去20年中一直在不断发展。
Analogously, the differentiated services architecture contains two main components. One is the fairly well-understood behavior in the forwarding path and the other is the more complex and still emerging background policy and allocation component that configures parameters used in the forwarding path. The forwarding path behaviors include the differential treatment an individual packet receives, as implemented by queue service disciplines and/or queue management disciplines. These per-hop behaviors are useful and required in network nodes to deliver differentiated treatment of packets no matter how we construct end-to-end or intra-domain services. Our focus is on the general semantics of the behaviors rather than the specific mechanisms used to implement them since these behaviors will evolve less rapidly than the mechanisms.
类似地，区分服务体系结构包含两个主要组件。一个是转发路径中相当容易理解的行为，另一个是配置转发路径中使用的参数的更复杂且仍在出现的后台策略和分配组件。转发路径行为包括由队列服务规程和/或队列管理规程实现的单个分组接收的差异处理。无论我们如何构造端到端或域内服务，这些每跳行为在网络节点中都是有用且必需的，以提供分组的差异化处理。我们的重点是行为的一般语义，而不是用于实现它们的特定机制，因为这些行为的发展速度不如机制快。
Per-hop behaviors and mechanisms to select them on a per-packet basis can be deployed in network nodes today and it is this aspect of the differentiated services architecture that is being addressed first. In addition, the forwarding path may require that some monitoring, policing, and shaping be done on the network traffic designated for "special" treatment in order to enforce requirements associated with the delivery of the special treatment. Mechanisms for this kind of traffic conditioning are also fairly well-understood. The wide deployment of such traffic conditioners is also important to enable the construction of services, though their actual use in constructing services may evolve over time.
如今，可以在网络节点中部署每跳行为和在每包基础上选择它们的机制，而首先解决的正是区分服务体系结构的这一方面。此外，转发路径可能要求对指定用于“特殊”处理的网络流量进行一些监视、监管和整形，以强制执行与特殊处理的交付相关的要求。这种交通调节的机制也相当清楚。这种流量调节器的广泛部署对于服务的构建也很重要，尽管它们在构建服务时的实际使用可能会随着时间的推移而变化。
The configuration of network elements with respect to which packets get special treatment and what kinds of rules are to be applied to the use of resources is much less well-understood. Nevertheless, it is possible to deploy useful differentiated services in networks by using simple policies and static configurations. As described in [ARCH], there are a number of ways to compose per-hop behaviors and traffic conditioners to create services. In the process, additional experience is gained that will guide more complex policies and allocations. The basic behaviors in the forwarding path can remain the same while this component of the architecture evolves. Experiences with the construction of such services will continue for some time, thus we avoid standardizing this construction as it is premature. Further, much of the details of service construction are covered by legal agreements between different business entities and we avoid this as it is very much outside the scope of the IETF.
对于网络元素的配置，哪些数据包得到了特殊处理，以及哪些类型的规则将应用于资源的使用，人们还不太了解。然而，通过使用简单的策略和静态配置，可以在网络中部署有用的区分服务。如[ARCH]中所述，有许多方法可以组合每跳行为和流量调节器来创建服务。在此过程中，获得了更多的经验，将指导更复杂的政策和分配。转发路径中的基本行为可以保持不变，而体系结构的这个组件可以继续发展。此类服务的建设经验将持续一段时间，因此我们避免将此建设标准化，因为这还为时过早。此外，服务构建的许多细节都包含在不同商业实体之间的法律协议中，我们避免这样做，因为这在IETF的范围之外。
This document concentrates on the forwarding path component. In the packet forwarding path, differentiated services are realized by mapping the codepoint contained in a field in the IP packet header to a particular forwarding treatment, or per-hop behavior (PHB), at each network node along its path. The codepoints may be chosen from a set of mandatory values defined later in this document, from a set of recommended values to be defined in future documents, or may have purely local meaning. PHBs are expected to be implemented by employing a range of queue service and/or queue management disciplines on a network node's output interface queue: for example weighted round-robin (WRR) queue servicing or drop-preference queue management.
本文档主要介绍转发路径组件。在分组转发路径中，通过将包含在IP分组报头中的字段中的码点映射到沿其路径的每个网络节点处的特定转发处理或每跳行为（PHB）来实现区分服务。代码点可以从本文件后面定义的一组强制值、未来文件中定义的一组建议值中选择，也可以具有纯本地含义。PHB预计将通过在网络节点的输出接口队列上采用一系列队列服务和/或队列管理规程来实现：例如加权循环（WRR）队列服务或丢弃首选队列管理。
Marking is performed by traffic conditioners at network boundaries, including the edges of the network (first-hop router or source host) and administrative boundaries. Traffic conditioners may include the primitives of marking, metering, policing and shaping (these mechanisms are described in [ARCH]). Services are realized by the use of particular packet classification and traffic conditioning mechanisms at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic. A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them.
标记由网络边界处的流量调节器执行，包括网络边缘（第一跳路由器或源主机）和管理边界。交通调节器可能包括标记、计量、监管和塑造的原语（这些机制在[ARCH]中描述）。服务是通过在边界处使用特定的分组分类和流量调节机制以及沿流量传输路径的每跳行为的串联来实现的。区分服务体系结构的一个目标是为将来的可扩展性指定这些构建块，包括构建块的数量和类型以及由它们构建的服务。
Terminology used in this memo is defined in Sec. 2. The differentiated services field definition (DS field) is given in Sec. 3. In Sec. 4, we discuss the desire for partial backwards compatibility with current use of the IPv4 Precedence field. As a solution, we introduce Class Selector Codepoints and Class Selector
本备忘录中使用的术语定义见第节。2.区分服务字段定义（DS字段）在第节中给出。3.以秒计。4，我们讨论了部分向后兼容IPv4优先字段当前使用的愿望。作为解决方案，我们引入了类选择器代码点和类选择器
Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior standardization. Sec. 6 discusses guidelines for allocation of codepoints. Sec. 7 covers security considerations.
合规PHB。秒。5介绍了每跳行为标准化的指导原则。秒。6讨论代码点分配的指导原则。秒。7包括安全考虑。
This document is a concise description of the DS field and its uses. It is intended to be read along with the differentiated services architecture [ARCH].
本文档简要介绍DS字段及其用途。它将与差异化服务体系结构[ARCH]一起阅读。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. The terms "aggregate" and "behavior aggregate" are used interchangeably in this document.
行为聚合：具有相同代码点的数据包在特定方向上穿过链路的集合。术语“聚合”和“行为聚合”在本文档中互换使用。
Classifier: an entity which selects packets based on the content of packet headers according to defined rules.
分类器：根据定义的规则，根据数据包头的内容选择数据包的实体。
Class Selector Codepoint: any of the eight codepoints in the range ' xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints are discussed in Sec. 4.2.2.
类选择器代码点：“xxx000”范围内的八个代码点中的任意一个（其中“x”可能等于“0”或“1”）。第节讨论了类选择器代码点。4.2.2.
Class Selector Compliant PHB: a per-hop behavior satisfying the Class Selector PHB Requirements specified in Sec. 4.2.2.2.
类选择器兼容PHB：满足第节中指定的类选择器PHB要求的每跳行为。4.2.2.2.
Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. Multiple codepoints MAY map to the same PHB.
代码点：DS字段的DSCP部分的特定值。建议的代码点应映射到特定的标准化PHB。多个代码点可以映射到同一PHB。
Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary.
区分服务边界：DS域的边缘，可能部署分类器和流量调节器。区分服务边界可进一步细分为入口和出口节点，其中入口/出口节点是给定业务方向上边界链路的下游/上游节点。区分服务边界通常位于主机的分组穿过的第一跳区分服务兼容路由器（或网络节点）的入口处，或在分组到达主机之前穿过的最后一跳区分服务兼容路由器或网络节点的出口处。这有时被称为叶路由器的边界。根据当地政策，差异化服务边界可能与主机位于同一位置。还包括DS边界。
Differentiated Services-Compliant: in compliance with the requirements specified in this document. Also DS-compliant.
符合差异化服务：符合本文件规定的要求。也符合DS标准。
Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain.
差异化服务域：Internet的一个连续部分，在该部分上以协调的方式管理一组一致的差异化服务策略。区分服务域可以表示不同的管理域或自治系统、不同的信任区域、不同的网络技术（例如，小区/帧）、主机和路由器等，也可以表示DS域。
Differentiated Services Field: the IPv4 header TOS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in this document. Also DS field.
区分服务字段：当按照本文档中给出的定义进行解释时，IPv4报头TOS八位字节或IPv6通信类八位字节。还包括DS字段。
Mechanism: The implementation of one or more per-hop behaviors according to a particular algorithm.
机制：根据特定算法实现一个或多个每跳行为。
Microflow: a single instance of an application-to-application flow of packets which is identified by source address, destination address, protocol id, and source port, destination port (where applicable).
微流：应用程序到应用程序的数据包流的单个实例，由源地址、目标地址、协议id和源端口、目标端口（如适用）标识。
Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate. The description of a PHB SHOULD be sufficiently detailed to allow the construction of predictable services, as documented in [ARCH].
每跳行为（PHB）：在符合区分服务的节点上应用于行为聚合的外部可观察转发处理的描述。PHB的描述应足够详细，以允许构建可预测的服务，如[ARCH]中所述。
Per-hop Behavior Group: a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. Also PHB Group.
每跳行为组：一组一个或多个PHB，由于适用于该组中所有PHB的公共约束（如队列服务或队列管理策略），只能同时有意义地指定和实现。还有PHB组。
Traffic Conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These MAY include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between domains and to condition traffic to receive a differentiated service within a domain by marking packets with the appropriate codepoint in the DS field and by monitoring and altering the temporal characteristics of the aggregate where necessary. See [ARCH].
流量调节：可应用于行为聚合、应用程序流或其他操作上有用的流量子集（例如路由更新）的控制功能。这些可能包括计量、监管、成型和数据包标记。流量调节用于强制域之间的协议，并通过在DS字段中使用适当的代码点标记数据包，以及在必要时监控和更改聚合的时间特征，调节流量以在域内接收差异化服务。见[拱门]。
Traffic Conditioner: an entity that performs traffic conditioning functions and which MAY contain meters, policers, shapers, and markers. Traffic conditioners are typically deployed in DS boundary nodes (i.e., not in interior nodes of a DS domain).
交通调节器：执行交通调节功能的实体，可能包含仪表、警察、整形器和标记。流量调节器通常部署在DS边界节点中（即，不在DS域的内部节点中）。
Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected DS domains, or end-to-end. Service descriptions are covered by administrative policy and services are constructed by
服务：对客户在特定域、一组相互连接的DS域或端到端之间的流量的总体处理（子集）的描述。服务描述包含在管理策略中，服务由
applying traffic conditioning to create behavior aggregates which experience a known PHB at each node within the DS domain. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners.
应用流量调节来创建行为聚合，这些行为聚合在DS域内的每个节点上经历已知PHB。通过与一系列流量调节器配合使用的单个每跳行为，可以支持多个服务。
To summarize, classifiers and traffic conditioners are used to select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used to determine which forwarding treatment the packet receives. A behavior aggregate classifier which can select a PHB, for example a differential output queue servicing discipline, based on the codepoint in the DS field SHOULD be included in all network nodes in a DS domain. The classifiers and traffic conditioners at DS boundaries are configured in accordance with some service specification, a matter of administrative policy outside the scope of this document.
总之，分类器和流量调节器用于选择要添加到行为聚合中的数据包。骨料在DS域中接受差异化处理，流量调节器可改变骨料的时间特性，以符合某些要求。数据包的DS字段用于指定数据包的行为聚合，并随后用于确定数据包接收的转发处理。可以基于DS字段中的代码点选择PHB（例如差分输出队列服务规程）的行为聚合分类器应包含在DS域中的所有网络节点中。DS边界处的分类器和流量调节器根据一些服务规范进行配置，这是一个超出本文件范围的管理政策问题。
Additional differentiated services definitions are given in [ARCH].
[ARCH]中给出了其他区分服务定义。
A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6].
定义了一个称为DS字段的替换头字段，该字段旨在取代IPv4 TOS八位字节[RFC791]和IPv6流量类八位字节[IPv6]的现有定义。
Six bits of the DS field are used as a codepoint (DSCP) to select the PHB a packet experiences at each node. A two-bit currently unused (CU) field is reserved and its definition and interpretation are outside the scope of this document. The value of the CU bits are ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet.
DS字段的六位用作代码点（DSCP），以选择每个节点上的PHB a数据包体验。保留两位当前未使用（CU）字段，其定义和解释不在本文件范围内。符合区分服务的节点在确定应用于接收到的数据包的每跳行为时忽略CU位的值。
The DS field structure is presented below:
DS字段结构如下所示：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint CU: currently unused
DSCP:区分服务代码点CU:当前未使用
In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1') used in this document, the left-most bit signifies bit 0 of the DS field (as shown above), and the right-most bit signifies bit 5.
在本文档中使用的DSCP值符号“xxxxxx”（其中“x”可能等于“0”或“1”）中，最左边的位表示DS字段的位0（如上所示），最右边的位表示位5。
Implementors should note that the DSCP field is six bits wide. DS-compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors.
实施者应注意，DSCP字段的宽度为6位。DS兼容节点必须通过匹配整个6位DSCP字段来选择PHB，例如，通过将字段的值作为表索引来处理，表索引用于选择已在该设备中实现的特定数据包处理机制。PHB选择必须忽略CU字段的值。DSCP字段定义为非结构化字段，以便于定义未来的每跳行为。
With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications MUST include a recommended default codepoint, which MUST be unique for codepoints in the standard space (see Sec. 6). Implementations should support the recommended codepoint-to-PHB mappings in their default configuration. Operators may choose to use different codepoints for a PHB, either in addition to or in place of the recommended default. Note that if operators do so choose, re-marking of DS fields may be necessary at administrative boundaries even if the same PHBs are implemented on both sides of the boundary.
除了下面提到的一些例外情况，代码点到PHB的映射必须是可配置的。DS兼容节点必须支持从代码点到PHB的可配置映射表的逻辑等价物。PHB规范必须包括推荐的默认代码点，该代码点对于标准空间中的代码点必须是唯一的（见第6节）。实现应该在默认配置中支持推荐的代码点到PHB的映射。操作员可以选择为PHB使用不同的代码点，除了推荐的默认值之外，也可以选择使用不同的代码点来代替推荐的默认值。请注意，如果运营商选择这样做，则可能需要在行政边界处重新标记DS字段，即使边界两侧实施相同的PHB。
See [ARCH] for further discussion of re-marking.
有关重新标记的进一步讨论，请参见[ARCH]。
The exceptions to general configurability are for codepoints 'xxx000' and are noted in Secs. 4.2.2 and 4.3.
一般可配置性的例外情况适用于代码点“xxx000”，并以秒表示。4.2.2和4.3。
Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction.
使用无法识别的代码点接收的数据包应该被转发，就像它们被标记为默认行为一样（参见第4节），并且它们的代码点不应该被更改。此类数据包不得导致网络节点出现故障。
The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re-marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service.
上述DS字段的结构与[RFC791]中IPv4 TOS八位字节的现有定义不兼容。假定DS域通过部署重新标记边界节点来保护自己，使用RFC 791优先指定的网络也应如此。正确的操作程序应遵循[RFC791]，该程序规定：“如果这些优先指定的实际使用与特定网络有关，则该网络有责任控制这些优先指定的访问和使用。”验证DS边界处DS字段的值在任何情况下都是合理的，因为上游节点可以轻松地将其设置为任意值。未被适当配置的边界节点隔离的DS域可能提供不可预测的服务。
Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors.
节点可根据需要重写DS字段以提供所需的本地或端到端服务。DS边界的DS现场翻译规范是提供商和用户之间服务级别协议的主题，不在本文档范围内。标准化PHB允许提供商从一组众所周知的数据包转发处理构建其服务，这些数据包转发处理预计将出现在许多供应商的设备中。
The DS field will have a limited backwards compatibility with current practice, as described in this section. Backwards 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 queueing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant nodes. 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 Sec. 4.2.2.2, though the specific differentiated services PHBs mapped to by those codepoints MAY have additional specifications.
如本节所述，DS字段与当前实践的向后兼容性有限。向后兼容性有两种解决方法。首先，存在已经广泛使用的每跳行为（例如，那些满足[RFC1812]中指定的IPv4优先排队要求的行为），我们希望允许它们在符合DS的节点中继续使用。此外，还有一些代码点与IP优先字段的历史使用相对应，我们保留这些代码点以映射到符合第节规定的一般要求的PHB。4.2.2.2，尽管由这些代码点映射到的特定区分服务PHB可能有额外的规范。
No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
未尝试与[RFC791]中定义的IPv4 TOS八位字节的“DTR”或TOS位保持向后兼容性。
A "default" PHB MUST be available in a DS-compliant node. This is the common, best-effort forwarding behavior available in existing routers as standardized in [RFC1812]. When no other agreements are in place, it is assumed that packets belong to this aggregate. Such packets MAY be sent into a network without adhering to any particular rules and the network will deliver as many of these packets as possible and as soon as possible, subject to other resource policy constraints. A reasonable implementation of this PHB would be a queueing discipline that sends packets of this aggregate whenever the output link is not required to satisfy another PHB. A reasonable policy for constructing services would ensure that the aggregate was not "starved". This could be enforced by a mechanism in each node that reserves some minimal resources (e.g, buffers, bandwidth) for Default behavior aggregates. This permits senders that are not differentiated services-aware to continue to use the network in the same manner as today. The impact of the introduction of differentiated services into a domain on the service expectations of its customers and peers is a complex matter involving policy decisions by the domain and is outside the scope of this document. The RECOMMENDED codepoint for the Default PHB is the bit pattern ' 000000'; the value '000000' MUST map to a PHB that meets these
“默认”PHB必须在符合DS的节点中可用。这是[RFC1812]中标准化的现有路由器中常见的尽力而为的转发行为。如果没有其他协议，则假定数据包属于此聚合。此类分组可以在不遵守任何特定规则的情况下被发送到网络中，并且网络将根据其他资源策略约束尽可能快地交付尽可能多的这些分组。这种PHB的合理实现是一种排队规则，只要输出链路不需要满足另一个PHB，就发送这种聚合的数据包。合理的服务建设政策将确保总量不会“饿死”。这可以通过每个节点中为默认行为聚合保留一些最小资源（例如，缓冲区、带宽）的机制来实现。这允许没有区分服务意识的发送方继续以与今天相同的方式使用网络。将差异化服务引入域对其客户和对等方的服务期望的影响是一个涉及域决策的复杂问题，不在本文档的范围内。默认PHB的建议代码点是位模式“000000”；值“000000”必须映射到满足以下条件的PHB
specifications. The codepoint chosen for Default behavior is compatible with existing practice [RFC791]. Where a codepoint is not mapped to a standardized or local use PHB, it SHOULD be mapped to the Default PHB.
规格。为默认行为选择的代码点与现有实践兼容[RFC791]。如果代码点未映射到标准化或本地使用PHB，则应将其映射到默认PHB。
A packet initially marked for the Default behavior MAY be re-marked with another codepoint as it passes a boundary into a DS domain so that it will be forwarded using a different PHB within that domain, possibly subject to some negotiated agreement between the peering domains.
最初标记为默认行为的数据包在通过边界进入DS域时，可以用另一个代码点重新标记，以便在该域内使用不同的PHB转发，这可能取决于对等域之间的某种协商协议。
We wish to maintain some form of backward compatibility with present uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet. Routers exist that use the IP Precedence field to select different per-hop forwarding treatments in a similar way to the use proposed here for the DSCP field. Thus, a simple prototype differentiated services architecture can be quickly deployed by appropriately configuring these routers. Further, IP systems today understand the location of the IP Precedence field, and thus if these bits are used in a similar manner as DS-compliant equipment is deployed, significant failures are not likely during early deployment. In other words, strict DS-compliance need not be ubiquitous even within a single service provider's network if bits 0-2 of the DSCP field are employed in a manner similar to, or subsuming, the deployed uses of the IP Precedence field.
我们希望与IP优先字段的当前使用保持某种形式的向后兼容性：IPv4 TOS八位字节的0-2位。存在使用IP优先级字段来选择不同每跳转发处理的路由器，其方式与此处建议使用DSCP字段的方式类似。因此，通过适当配置这些路由器，可以快速部署简单的原型差异化服务体系结构。此外，目前的IP系统了解IP优先级字段的位置，因此，如果这些位以与部署DS兼容设备类似的方式使用，则在早期部署期间不太可能出现重大故障。换句话说，如果DSCP字段的位0-2以类似于或包含IP优先字段的部署使用的方式使用，则即使在单个服务提供商的网络中，严格的DS遵从性也不必无处不在。
The IP Precedence field is something of a forerunner of the DS field. IP Precedence, and the IP Precedence Field, were first defined in [RFC791]. The values that the three-bit IP Precedence Field might take were assigned to various uses, including network control traffic, routing traffic, and various levels of privilege. The least level of privilege was deemed "routine traffic". In [RFC791], the notion of Precedence was defined broadly as "An independent measure of the importance of this datagram." Not all values of the IP Precedence field were assumed to have meaning across boundaries, for instance "The Network Control precedence designation is intended to be used within a network only. The actual use and control of that designation is up to each network." [RFC791]
IP优先级字段是DS字段的前身。IP优先级和IP优先级字段首先在[RFC791]中定义。三位IP优先级字段可能采用的值被分配给各种用途，包括网络控制流量、路由流量和各种权限级别。最低级别的特权被视为“常规交通”。在[RFC791]中，优先级的概念被广泛定义为“此数据报重要性的独立度量”。例如，并非所有IP优先级字段的值都被假定为具有跨边界的含义“网络控制优先指定仅用于网络内。该标识的实际使用和控制取决于每个网络。”[RFC791]
Although early BBN IMPs implemented the Precedence feature, early commercial routers and UNIX IP forwarding code generally did not. As networks became more complex and customer requirements grew, commercial router vendors developed ways to implement various kinds of queueing services including priority queueing, which were
尽管早期的BBN IMP实现了优先功能，但早期的商用路由器和UNIX IP转发代码通常没有实现。随着网络变得越来越复杂，客户需求不断增长，商业路由器供应商开发了实现各种排队服务的方法，包括优先级排队，这是
generally based on policies encoded in filters in the routers, which examined IP addresses, IP protocol numbers, TCP or UDP ports, and other header fields. IP Precedence was and is among the options such filters can examine.
通常基于路由器中过滤器中编码的策略，这些过滤器检查IP地址、IP协议号、TCP或UDP端口以及其他头字段。IP优先级过去和现在都是此类筛选器可以检查的选项之一。
In short, IP Precedence is widely deployed and widely used, if not in exactly the manner intended in [RFC791]. This was recognized in [RFC1122], which states that while the use of the IP Precedence field is valid, the specific assignment of the priorities in [RFC791] were merely historical.
简言之，IP优先级被广泛部署和使用，如果不是以[RFC791]中预期的方式。这一点在[RFC1122]中得到了承认，其中指出，虽然IP优先级字段的使用是有效的，但[RFC791]中优先级的具体分配只是历史性的。
A specification of the packet forwarding treatments selected by the IP Precedence field today would have to be quite general; probably not specific enough to build predictable services from in the differentiated services framework. To preserve partial backwards compatibility with known current uses of the IP Precedence field without sacrificing future flexibility, we have taken the approach of describing minimum requirements on a set of PHBs that are compatible with most of the deployed forwarding treatments selected by the IP Precedence field. In addition, we give a set of codepoints that MUST map to PHBs meeting these minimum requirements. The PHBs mapped to by these codepoints MAY have a more detailed list of specifications in addition to the required ones stated here. Other codepoints MAY map to these same PHBs. We refer to this set of codepoints as the Class Selector Codepoints, and the minimum requirements for PHBs that these codepoints may map to are called the Class Selector PHB Requirements.
今天，由IP优先字段选择的分组转发处理的规范必须非常通用；可能不够具体，无法从差异化服务框架中构建可预测的服务。为了在不牺牲未来灵活性的情况下保持与IP优先级字段已知当前使用的部分向后兼容性，我们采用了描述一组PHB的最低要求的方法，这些PHB与IP优先级字段选择的大多数已部署转发处理兼容。此外，我们还提供了一组必须映射到满足这些最低要求的PHB的代码点。除了此处规定的规范外，这些代码点映射到的PHB可能还有更详细的规范列表。其他代码点可能映射到这些相同的PHB。我们将这组代码点称为类选择器代码点，这些代码点可能映射到的PHB的最低要求称为类选择器PHB要求。
A specification of the packet forwarding treatments selected by the The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU subfield unspecified, are reserved as a set of Class Selector Codepoints. PHBs which are mapped to by these codepoints MUST satisfy the Class Selector PHB requirements in addition to preserving the Default PHB requirement on codepoint '000000' (Sec. 4.1).
由“xxx000 | xx”的DS字段值或DSCP=“xxx000”和未指定的CU子字段选择的数据包转发处理规范保留为一组类选择器代码点。由这些代码点映射到的PHB除了保留代码点“000000”上的默认PHB要求外，还必须满足类选择器PHB要求（第4.1节）。
We refer to a Class Selector Codepoint with a larger numerical value than another Class Selector Codepoint as having a higher relative order while a Class Selector Codepoint with a smaller numerical value than another Class Selector Codepoint is said to have a lower relative order. The set of PHBs mapped to by the eight Class Selector Codepoints MUST yield at least two independently forwarded classes of traffic, and PHBs selected by a Class Selector Codepoint
我们将数值大于另一个类选择器代码点的类选择器代码点称为具有较高的相对阶数，而数值小于另一个类选择器代码点的类选择器代码点称为具有较低的相对阶数。由八个类选择器码点映射到的PHB集必须产生至少两个独立转发的流量类，并且由类选择器码点选择的PHB
SHOULD give packets a probability of timely forwarding that is not lower than that given to packets marked with a Class Selector codepoint of lower relative order, under reasonable operating conditions and traffic loads. A discarded packet is considered to be an extreme case of untimely forwarding. In addition, PHBs selected by codepoints '11x000' MUST give packets a preferential forwarding treatment by comparison to the PHB selected by codepoint '000000' to preserve the common usage of IP Precedence values '110' and '111' for routing traffic.
在合理的操作条件和流量负载下，应为数据包提供不低于标记有较低相对顺序的类选择器码点的数据包的及时转发概率。丢弃的数据包被认为是不及时转发的极端情况。此外，与由代码点“000000”选择的PHB相比，由代码点“11x000”选择的PHB必须给予数据包优先转发处理，以保持IP优先级值“110”和“111”在路由流量方面的通用性。
Further, PHBs selected by distinct Class Selector Codepoints SHOULD be independently forwarded; that is, packets marked with different Class Selector Codepoints MAY be re-ordered. A network node MAY enforce limits on the amount of the node's resources that can be utilized by each of these PHBs.
此外，由不同类别选择器码点选择的PHB应独立转发；也就是说，标记有不同类选择器代码点的包可以被重新排序。网络节点可以对这些phb中的每一个可以使用的节点资源量实施限制。
PHB groups whose specification satisfy these requirements are referred to as Class Selector Compliant PHBs.
规范满足这些要求的PHB组称为符合类别选择器的PHB。
The Class Selector PHB Requirements on codepoint '000000' are compatible with those listed for the Default PHB in Sec. 4.1.
代码点“000000”上的类选择器PHB要求与第节中为默认PHB列出的要求兼容。4.1.
4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence Compatibility
4.2.2.3 使用类选择器PHB对IP优先级兼容性的要求
A DS-compliant network node can be deployed with a set of one or more Class Selector Compliant PHB groups. This document states that the set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is also possible to map multiple codepoints to the same PHB, the vendor or the network administrator MAY configure the network node 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 '011010' would map to the same PHB as codepoint '011000'.
符合DS的网络节点可以与一组符合类选择器的PHB组一起部署。本文件规定，代码点集“xxx000”必须映射到此类PHB集。由于还可以将多个码点映射到同一PHB，因此供应商或网络管理员可以配置网络节点将码点映射到PHB，而不考虑DSCP字段的比特3-5，以产生与历史IP优先使用兼容的网络。因此，例如，代码点“011010”将映射到与代码点“011000”相同的PHB。
4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant PHB Groups
4.2.2.4 实现符合类选择器的PHB组的示例机制
Class Selector Compliant PHBs can be realized by a variety of mechanisms, including strict priority queueing, weighted fair queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based Queuing [CBQ]. The distinction between PHBs and mechanisms is described in more detail in Sec. 5.
符合类选择器的PHB可以通过多种机制实现，包括严格优先级排队、加权公平排队（WFQ）、WRR或变体[RPS、HPFQA、DRR]或基于类的排队[CBQ]。PHB和机制之间的区别在第。5.
It is important to note that these mechanisms might be available through other PHBs (standardized or not) that are available in a particular vendor's equipment. For example, future documents may standardize a Strict Priority Queueing PHB group for a set of
需要注意的是，这些机制可能通过特定供应商设备中可用的其他PHB（标准化或非标准化）提供。例如，未来的文档可能会标准化一组数据的严格优先级排队PHB组
recommended codepoints. A network administrator might configure those routers to select the Strict Priority Queueing PHBs with codepoints 'xxx000' in conformance with the requirements of this document.
建议的代码点。网络管理员可能会根据本文档的要求配置这些路由器，以选择代码点为“xxx000”的严格优先级排队PHB。
As a further example, another vendor might employ a CBQ mechanism in its routers. The CBQ mechanism could be used to implement the Strict Priority Queueing PHBs as well as a set of Class Selector Compliant PHBs with a wider range of features than would be available in a set of PHBs that did no more than meet the minimum Class Selector PHB requirements.
作为进一步的示例，另一个供应商可能在其路由器中使用CBQ机制。CBQ机制可用于实现严格的优先级排队PHB以及一组符合类选择器的PHB，这些PHB具有比一组PHB（仅满足最低类选择器PHB要求）更广泛的功能。
This document defines codepoints 'xxx000' as the Class Selector codepoints, where PHBs selected by these codepoints MUST meet the Class Selector PHB Requirements described in Sec. 4.2.2.2. This is done to preserve a useful level of backward compatibility with current uses of the IP Precedence field in the Internet without unduly limiting future flexibility. In addition, codepoint '000000' is used as the Default PHB value for the Internet and, as such, is not configurable. The remaining seven non-zero Class Selector codepoints are configurable only to the extent that they map to PHBs that meet the requirements in Sec. 4.2.2.2.
本文件将代码点“xxx000”定义为类选择器代码点，其中由这些代码点选择的PHB必须满足第节中所述的类选择器PHB要求。4.2.2.2. 这样做是为了在不过度限制未来灵活性的情况下，保持与Internet中当前使用的IP优先级字段的向后兼容性的有用级别。此外，代码点“000000”用作Internet的默认PHB值，因此不可配置。其余七个非零类选择器代码点仅在映射到满足第节要求的PHB时才可配置。4.2.2.2.
The behavioral characteristics of a PHB are to be standardized, and not the particular algorithms or the mechanisms used to implement them. A node may have a (possibly large) set of parameters that can be used to control how packets are scheduled onto an output interface (e.g., N separate queues with settable priorities, queue lengths, round-robin weights, drop algorithm, drop preference weights and thresholds, etc). To illustrate the distinction between a PHB and a mechanism, we point out that Class Selector Compliant PHBs might be implemented by several mechanisms, including: strict priority queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in isolation or in combination.
PHB的行为特征需要标准化，而不是用于实现它们的特定算法或机制。节点可具有（可能较大）一组参数，可用于控制分组如何调度到输出接口上（例如，N个具有可设置优先级、队列长度、循环权重、丢弃算法、丢弃偏好权重和阈值等的独立队列）。为了说明PHB和机制之间的区别，我们指出，符合类选择器的PHB可以通过几种机制实现，包括：严格优先级排队、WFQ、WRR或变体[HPFQA、RPS、DRR]或CBQ[CBQ]，单独或组合实现。
PHBs may be specified individually, or as a group (a single PHB is a special case of a PHB group). A PHB group usually consists of a set of two or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to each PHB within the group, such as a queue servicing or queue management policy. A PHB group specification SHOULD describe conditions under which a packet might be re-marked to select another PHB within the group. It is RECOMMENDED that PHB implementations do not introduce any packet re-ordering within a microflow. PHB group
PHB可以单独指定，也可以作为一个组指定（单个PHB是PHB组的特例）。PHB组通常由一组两个或多个PHB组成，由于组内每个PHB都有一个共同的约束，例如队列服务或队列管理策略，因此只能同时有意义地指定和实现这些PHB。PHB组规范应描述数据包可能被重新标记以选择组内另一个PHB的条件。建议PHB实现不要在微流中引入任何数据包重新排序。PHB组
specifications MUST identify any possible packet re-ordering implications which may occur for each individual PHB, and which may occur if different packets within a microflow are marked for different PHBs within the group.
规范必须确定每个单独PHB可能发生的任何可能的数据包重新排序影响，以及如果微流中的不同数据包被标记为组中的不同PHB可能发生的任何可能的数据包重新排序影响。
Only those per-hop behaviors that are not described by an existing PHB standard, and have been implemented, deployed, and shown to be useful, SHOULD be standardized. Since current experience with differentiated services is quite limited, it is premature to hypothesize the exact specification of these per-hop behaviors.
只有那些未被现有PHB标准描述的、已经实现、部署并证明有用的每跳行为才应该标准化。由于目前在区分服务方面的经验非常有限，因此假设这些每跳行为的确切规格还为时过早。
Each standardized PHB MUST have an associated RECOMMENDED codepoint, allocated out of a space of 32 codepoints (see Sec. 6). This specification has left room in the codepoint space to allow for evolution, thus the defined space ('xxx000') is intentionally sparse.
每个标准化PHB必须有一个相关的推荐代码点，在32个代码点的空间中分配（见第6节）。本规范在代码点空间中留出了空间，以允许演化，因此定义的空间（“xxx000”）有意稀疏。
Network equipment vendors are free to offer whatever parameters and capabilities are deemed useful or marketable. When a particular, standardized PHB is implemented in a node, a vendor MAY use any algorithm that satisfies the definition of the PHB according to the standard. The node's capabilities and its particular configuration determine the different ways that packets can be treated.
网络设备供应商可以自由提供任何被认为有用或适销对路的参数和功能。当在节点中实现特定的、标准化的PHB时，供应商可以使用根据标准满足PHB定义的任何算法。节点的功能及其特定配置决定了处理数据包的不同方式。
Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives. Over time certain common per-hop behaviors are likely to evolve (i.e., ones that are particularly useful for implementing end-to-end services) and these MAY be associated with particular EXP/LU PHB codepoints in the DS field, allowing use across domain boundaries (see Sec. 6). These PHBs are candidates for future standardization.
服务提供商不需要使用相同的节点机制或配置来实现其网络内的服务差异化，并且可以自由地以适合其服务产品和流量工程目标的任何方式配置节点参数。随着时间的推移，某些常见的每跳行为可能会演变（即，对于实现端到端服务特别有用的行为），这些行为可能与DS字段中的特定EXP/LU PHB代码点相关联，从而允许跨域边界使用（见第6节）。这些PHB是未来标准化的候选。
It is RECOMMENDED that standardized PHBs be specified in accordance with the guidelines set out in [ARCH].
建议按照[ARCH]中规定的指南规定标准化PHB。
The DSCP field within the DS field is capable of conveying 64 distinct codepoints. The codepoint space is divided into three pools for the purpose of codepoint assignment and management: a pool of 32 RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for experimental or Local Use (EXP/LU) as defined in [CONS], and a pool of 16 codepoints (Pool 3) which are initially available for experimental or local use, but which should be preferentially
DS字段中的DSCP字段能够传输64个不同的代码点。为了码点分配和管理的目的，码点空间分为三个池：由[CONS]中定义的标准行动分配的32个推荐码点（池1）、由[CONS]中定义的实验或本地使用（EXP/LU）保留的16个码点（池2）以及由16个码点组成的池（池3）最初可供实验或本地使用，但应优先使用
utilized for standardized assignments if Pool 1 is ever exhausted. The pools are defined in the following table (where 'x' refers to either '0' or '1'):
如果池1耗尽，则用于标准化分配。池在下表中定义（其中“x”表示“0”或“1”）：
Pool Codepoint space Assignment Policy
---- --------------- -----------------
Pool Codepoint space Assignment Policy
---- --------------- -----------------
1 xxxxx0 Standards Action 2 xxxx11 EXP/LU 3 xxxx01 EXP/LU (*)
1 XXXXX 0标准行动2 xxxx11 EXP/LU 3 xxxx01 EXP/LU（*）
(*) may be utilized for future Standards Action allocations as necessary
（*）可根据需要用于未来的标准行动分配
This document assigns eight RECOMMENDED codepoints ('xxx000') which are drawn from Pool 1 above. These codepoints MUST be mapped, not to specific PHBs, but to PHBs that meet "at least" the requirements set forth in Sec. 4.2.2.2 to provide a minimal level of backwards compatibility with IP Precedence as defined in [RFC791] and as deployed in some current equipment.
本文件指定了从上述池1中提取的八个推荐代码点（'xxx000'）。这些代码点必须映射，而不是映射到特定的PHB，而是映射到“至少”满足第节规定要求的PHB。4.2.2.2提供与[RFC791]中定义的IP优先级以及某些当前设备中部署的IP优先级的最低向后兼容性。
This section considers security issues raised by the introduction of differentiated services, primarily the potential for denial-of-service attacks, and the related potential for theft of service by unauthorized traffic (Section 7.1). Section 7.2 addresses the operation of differentiated services in the presence of IPsec including its interaction with IPsec tunnel mode and other tunnelling protocols. See [ARCH] for more extensive treatment of the security concerns raised by the overall differentiated services architecture.
本节讨论了引入差异化服务所引起的安全问题，主要是拒绝服务攻击的可能性，以及未经授权流量窃取服务的相关可能性（第7.1节）。第7.2节介绍了在存在IPsec的情况下区分服务的操作，包括其与IPsec隧道模式和其他隧道协议的交互。请参阅[ARCH]以了解对整体差异化服务体系结构引起的安全问题的更广泛处理。
The primary goal of differentiated services is to allow different levels of service to be provided for traffic streams on a common network infrastructure. A variety of techniques may be used to achieve this, but the end result will be that some packets receive different (e.g., better) service than others. The mapping of network traffic to the specific behaviors that result in different (e.g., better or worse) service is indicated primarily by the DS codepoint, and hence an adversary may be able to obtain better service by modifying the codepoint to values indicating behaviors used for enhanced services or by injecting packets with such codepoint values. Taken to its limits, such theft-of-service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams.
区分服务的主要目标是允许在公共网络基础设施上为业务流提供不同级别的服务。可以使用多种技术来实现这一点，但最终结果将是一些分组接收到与其他分组不同（例如，更好）的服务。网络流量到导致不同（例如，更好或更差）服务的特定行为的映射主要由DS码点表示，因此，对手可以通过将代码点修改为指示用于增强服务的行为的值，或者通过注入具有这种代码点值的包，来获得更好的服务。就其局限性而言，当修改或注入的流量耗尽了可用于转发该流量和其他流量流的资源时，此类服务盗窃就成为拒绝服务攻击。
The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of-service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate. An important instance of a boundary node is that any traffic-originating node within a DS domain is the initial boundary node for that traffic. Interior nodes in a DS domain rely on DS codepoints to associate traffic with the forwarding PHBs, and are NOT REQUIRED to check codepoint values before using them. As a result, the interior nodes depend on the correct operation of the DS domain boundary nodes to prevent the arrival of traffic with inappropriate codepoints or in excess of provisioned levels that would disrupt operation of the domain.
针对此类盗窃和拒绝服务攻击的防御包括DS域边界的流量调节与DS域内网络基础设施的安全性和完整性的结合。DS域边界节点必须确保所有进入域的流量都标记有适合于流量和域的代码点值，必要时用新的代码点值重新标记流量。这些DS边界节点是防御基于修改的代码点的盗窃和拒绝服务攻击的主要防线，因为任何此类攻击的成功都表明攻击流量使用的代码点不适当。边界节点的一个重要实例是，DS域内的任何流量发起节点都是该流量的初始边界节点。DS域中的内部节点依靠DS码点将流量和转发PHB关联起来，并且在使用它们之前不需要检查码点值。结果，内部节点依赖于DS域边界节点的正确操作，以防止具有不适当的码点或超过将中断域操作的供应级别的流量的到达。
The IPsec protocol, as defined in [ESP, AH], does not include the IP header's DS field in any of its cryptographic calculations (in the case of tunnel mode, it is the outer IP header's DS field that is not included). Hence modification of the DS field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the DS field (i.e., a man-in-the-middle attack), as the adversary's modification will also have no effect on IPsec's end-to-end security.
[ESP，AH]中定义的IPsec协议在其任何加密计算中不包括IP头的DS字段（在隧道模式下，不包括外部IP头的DS字段）。因此，网络节点对DS字段的修改不会影响IPsec的端到端安全性，因为它不会导致任何IPsec完整性检查失败。因此，IPsec不会针对对手对DS字段的修改（即中间人攻击）提供任何防御，因为对手的修改也不会影响IPsec的端到端安全。
IPsec's tunnel mode provides security for the encapsulated IP header's DS field. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the tunnel ingress node and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is hosted (in whole or in part) on a differentiated services network, the intermediate network nodes operate on the DS field in the outer header. At the tunnel egress node, IPsec processing includes removing the outer header and forwarding the packet (if required) using the inner header. The IPsec protocol REQUIRES that the inner header's DS field not be changed by this decapsulation processing to ensure that modifications to the DS field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint. This document makes no change to that requirement. If the inner IP header has not been processed by a DS boundary node for the tunnel egress node's DS
IPsec的隧道模式为封装的IP头的DS字段提供安全性。隧道模式IPsec数据包包含两个IP报头：由隧道入口节点提供的外部报头和由数据包原始源提供的封装内部报头。当IPsec隧道（全部或部分）托管在差异化服务网络上时，中间网络节点在外部报头中的DS字段上操作。在隧道出口节点处，IPsec处理包括移除外部报头和使用内部报头转发分组（如果需要）。IPsec协议要求此解除封装处理不会更改内部标头的DS字段，以确保对DS字段的修改不能用于跨IPsec隧道端点发起盗窃或拒绝服务攻击。本文件未对该要求进行任何更改。如果DS边界节点没有为隧道出口节点的DS处理内部IP报头
domain, the tunnel egress node is the boundary node for traffic exiting the tunnel, and hence MUST ensure that the resulting traffic has appropriate DS codepoints.
域中，隧道出口节点是退出隧道的流量的边界节点，因此必须确保生成的流量具有适当的DS码点。
When IPsec tunnel egress decapsulation processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where sufficiency is determined by local security policy), the tunnel egress node can safely assume that the DS field in the inner header has the same value as it had at the tunnel ingress node. An important consequence is that otherwise insecure links within a DS domain can be secured by a sufficiently strong IPsec tunnel. This analysis and its implications apply to any tunnelling protocol that performs integrity checks, but the level of assurance of the inner header's DS field depends on the strength of the integrity check performed by the tunnelling protocol. In the absence of sufficient assurance for a tunnel that may transit nodes outside the current DS domain (or is otherwise vulnerable), the encapsulated packet MUST be treated as if it had arrived at a boundary from outside the DS domain.
当IPsec隧道出口解除封装处理包括对封装的分组的足够强的密码完整性检查（其中充分性由本地安全策略确定）时，隧道出口节点可以安全地假设内部报头中的DS字段具有与在隧道入口节点处相同的值。一个重要的结果是，DS域中不安全的链路可以通过足够强的IPsec隧道来保护。此分析及其含义适用于执行完整性检查的任何隧道协议，但内部报头的DS字段的保证级别取决于隧道协议执行的完整性检查的强度。在对可能在当前DS域外传输节点（或易受攻击）的隧道缺乏足够保证的情况下，必须将封装的数据包视为已从DS域外到达边界。
The authors would like to acknowledge the Differentiated Services Working Group for discussions which helped shape this document.
作者希望感谢差异化服务工作组的讨论，这些讨论有助于形成本文件。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[ARCH]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995.
[CBQ]S.Floyd和V.Jacobson，“分组网络的链路共享和资源管理模型”，IEEE/ACM网络交易，第3卷第4期，第365-386页，1995年8月。
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[CONS]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，RFC 2434，1998年10月。
[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
[DRR]M.Shreedhar和G.Varghese，《使用赤字循环的有效公平排队》，过程ACM SIGCOMM 951995。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[HPFQA]J.Bennett和Hui Zhang，“分层分组公平排队算法”，Proc。ACM SIGCOM96，1996年8月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，编辑，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1122] Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1812] Baker, F., Editor, "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月。
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A Design Methodology for Fair Queueing Algorithms", IEEE/ ACM Trans. on Networking, April 1998.
[RPS]D.Stiliadis和A.Varma，“速率比例服务器：公平排队算法的设计方法”，IEEE/ACM Trans。关于网络，1998年4月。
Authors' Addresses
作者地址
Kathleen Nichols Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
凯萨琳·尼科尔斯思科系统公司加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1-408-525-4857
EMail: kmn@cisco.com
Phone: +1-408-525-4857
EMail: kmn@cisco.com
Steven Blake Torrent Networking Technologies 3000 Aerial Center, Suite 140 Morrisville, NC 27560
Steven Blake Torrent Networking Technologies 3000航空中心，140室，北卡罗来纳州莫里斯维尔，27560
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
弗雷德·贝克思科系统公司，加利福尼亚州圣巴巴拉市拉多大道519号，邮编：93111
Phone: +1-408-526-4257
EMail: fred@cisco.com
Phone: +1-408-526-4257
EMail: fred@cisco.com
David L. Black EMC Corporation 35 Parkwood Drive Hopkinton, MA 01748
David L.Black EMC Corporation马萨诸塞州霍普金顿帕克伍德大道35号01748
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。