Network Working Group D. Grossman
Request for Comments: 3260 Motorola, Inc.
Updates: 2474, 2475, 2597 April 2002
Category: Informational
Network Working Group D. Grossman
Request for Comments: 3260 Motorola, Inc.
Updates: 2474, 2475, 2597 April 2002
Category: Informational
New Terminology and Clarifications for Diffserv
Diffserv的新术语和澄清
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs.
本备忘录记录了Diffserv工作组关于新的和改进的术语的协议，并提供了次要的技术澄清。旨在更新RFC 2474、RFC 2475和RFC 2597。当RFC 2474和2597在标准轨道上前进，并且RFC 2475更新时，本备忘录中的修订将被纳入，并且本备忘录将被新的RFC淘汰。
As the Diffserv work has evolved, there have been several cases where terminology has needed to be created or the definitions in Diffserv standards track RFCs have needed to be refined. Some minor technical clarifications were also found to be needed. This memo was created to capture group agreements, rather than attempting to revise the base RFCs and recycle them at proposed standard. It updates in part RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been obsoleted by RFC 3246, and clarifications agreed by the group were incorporated in that revision.
随着Diffserv工作的发展，出现了一些需要创建术语或需要改进Diffserv标准跟踪rfc中的定义的情况。还发现需要进行一些次要的技术澄清。创建此备忘录是为了捕获集团协议，而不是试图修改基本RFC并按照拟定标准回收它们。它在RFC 2474、RFC 2475和RFC 2597部分中进行了更新。RFC 2598已被RFC 3246淘汰，集团同意的澄清已纳入该修订。
The Diffserv Architecture [2] uses the term "Service Level Agreement" (SLA) to describe the "service contract... that specifies the forwarding service a customer should receive". The SLA may include traffic conditioning rules which (at least in part) constitute a Traffic Conditioning Agreement (TCA). A TCA is "an agreement
Diffserv体系结构[2]使用术语“服务级别协议”（SLA）来描述“服务合同……它指定了客户应该接收的转发服务”。SLA可包括构成（至少部分）流量调节协议（TCA）的流量调节规则。TCA是“协议”
specifying classifier rules and any corresponding traffic profiles
and metering, marking, discarding and/or shaping rules which are to
apply...."
specifying classifier rules and any corresponding traffic profiles
and metering, marking, discarding and/or shaping rules which are to
apply...."
As work progressed in Diffserv (as well as in the Policy WG [6]), it came to be believed that the notion of an "agreement" implied considerations that were of a pricing, contractual or other business nature, as well as those that were strictly technical. There also could be other technical considerations in such an agreement (e.g., service availability) which are not addressed by Diffserv. It was therefore agreed that the notions of SLAs and TCAs would be taken to represent the broader context, and that new terminology would be used to describe those elements of service and traffic conditioning that are addressed by Diffserv.
随着Diffserv（以及政策工作组[6]）的工作进展，人们逐渐相信，“协议”的概念意味着定价、合同或其他业务性质的考虑，以及严格的技术性考虑。在此类协议中还可能存在Diffserv未解决的其他技术问题（例如，服务可用性）。因此，各方同意，SLA和TCA的概念将被视为代表更广泛的背景，并将使用新的术语来描述区分服务所涉及的服务和流量调节要素。
- A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain.
- 服务级别规范（SLS）是一组参数及其值，它们共同定义DS域向业务流提供的服务。
- A Traffic Conditioning Specification (TCS) is a set of parameters and their values which together specify a set of classifier rules and a traffic profile. A TCS is an integral element of an SLS.
- 流量调节规范（TCS）是一组参数及其值，共同指定一组分类器规则和流量配置文件。TCS是SLS的一个组成部分。
Note that the definition of "Traffic stream" is unchanged from RFC 2475. A traffic stream can be an individual microflow or a group of microflows (i.e., in a source or destination DS domain) or it can be a BA. Thus, an SLS may apply in the source or destination DS domain to a single microflow or group of microflows, as well as to a BA in any DS domain.
注意，“交通流”的定义与RFC 2475的定义相同。业务流可以是单个微流或一组微流（即，在源或目的DS域中），也可以是BA。因此，SLS可以在源或目的DS域中应用于单个微流或微流组，以及应用于任何DS域中的BA。
Also note that the definition of a "Service Provisioning Policy" is unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning Policy as "a policy which defines how traffic conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services." According to one definition given in RFC 3198 [6], a policy is "...a set of rules to administer, manage, and control access to network resources". Therefore, the relationship between an SLS and a service provisioning policy is that the latter is, in part, the set of rules that express the parameters and range of values that may be in the former.
还请注意，“服务供应策略”的定义与RFC 2475的定义相同。RFC 2475将“服务供应策略”定义为“一种策略，该策略定义了如何在DS边界节点上配置流量调节器，以及如何将流量流映射到DS行为聚合以实现一系列服务。”根据RFC 3198[6]中给出的一个定义，策略是“…一组管理规则，因此，SLS和服务提供策略之间的关系是，服务提供策略在某种程度上是一组规则，表示前者中可能存在的参数和值范围。
Further note that this definition is more restrictive than that in RFC 3198.
进一步注意，该定义比RFC 3198中的定义更具限制性。
RFC 2475 defines a Per-hop behavior (PHB) group to be:
RFC 2475将每跳行为（PHB）组定义为：
"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. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group."
“一组一个或多个PHB，由于适用于该组中所有PHB的共同约束（如队列服务或队列管理策略），只能同时有意义地指定和实现。PHB组提供一个服务构建块，允许同时指定一组相关的转发行为。”（例如，四个丢弃优先级）。单个PHB是PHB组的特例。”
One standards track PHB Group is defined in RFC 2597 [3], "Assured Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding behavior with some assigned level of queuing resources and three drop precedences. An AF PHB Group consists of three PHBs, and uses three Diffserv Codepoints (DSCPs).
RFC 2597[3]“有保证的转发PHB组”中定义了一个标准轨道PHB组。有保证转发（AF）是一种转发行为，具有一定级别的排队资源和三次丢弃先例。AF PHB组由三个PHB组成，并使用三个区分服务码点（DSCP）。
RFC 2597 defines twelve DSCPs, corresponding to four independent AF classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class is one instance of an AF PHB Group.
RFC2597定义了十二个DSCP，对应于四个独立的AF类。AF类被称为AF1x、AF2x、AF3x和AF4x（其中“x”是1、2或3以表示丢弃优先级）。每个AF类都是AF PHB组的一个实例。
There has been confusion expressed that RFC 2597 refers to all four AF classes with their three drop precedences as being part of a single PHB Group. However, since each AF class operates entirely independently of the others, (and thus there is no common constraint among AF classes as there is among drop precedences within an AF class) this usage is inconsistent with RFC 2475. The inconsistency exists for historical reasons and will be removed in future revisions of the AF specification. It should now be understood that AF is a _type_ of PHB group, and each AF class is an _instance_ of the AF type.
有人表示，RFC2597将所有四个具有三次下降先例的AF类称为单个PHB组的一部分，这一点令人困惑。然而，由于每个AF类完全独立于其他类进行操作（因此，AF类之间没有共同的约束，因为AF类中存在丢弃先例），因此该用法与RFC 2475不一致。这种不一致性是由于历史原因而存在的，将在AF规范的未来版本中删除。现在应该理解，AF是PHB组的_类型uu，每个AF类都是AF类型的_实例。
Authors of new PHB specifications should be careful to adhere to the RFC 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB specifications from assigning enough DSCPs to represent multiple independent instances of their PHB Group. However, such a set of DSCPs must not be referred to as a single PHB Group.
新PHB规范的作者应谨慎遵守RFC 2475对PHB组的定义。RFC 2475并不禁止新的PHB规范分配足够的DSCP来表示其PHB组的多个独立实例。但是，这组DSCP不得称为单个PHB组。
Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 header, respectively, to the DS field. The DS Field has a six bit Diffserv Codepoint and two "currently unused" bits.
Diffserv使用IPV4或IPV6报头的六位来传输Diffserv码点（DSCP），该码点选择PHB。RFC 2474尝试将IPV4报头的TOS八位字节和IPV6报头的流量类八位字节分别重命名为DS字段。DS字段有一个六位Diffserv码点和两个“当前未使用”位。
It has been pointed out that this leads to inconsistencies and ambiguities. In particular, the "Currently Unused" (CU) bits of the DS Field have not been assigned to Diffserv, and subsequent to the publication of RFC 2474, they were assigned for explicit congestion notification, as defined in RFC 3168 [4]. In the current text, a DSCP is, depending on context, either an encoding which selects a PHB or a sub-field in the DS field which contains that encoding.
有人指出，这会导致不一致和含糊不清。特别是，DS字段的“当前未使用”（CU）位尚未分配给Diffserv，并且在发布RFC 2474之后，它们被分配用于显式拥塞通知，如RFC 3168[4]中所定义。在当前文本中，DSCP是根据上下文选择PHB的编码或DS字段中包含该编码的子字段。
The present text is also inconsistent with BCP 37, IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class field are superseded by the 6 bit DS field and a 2 bit CU field. The IANA allocates values in the DS field following the IANA considerations section in RFC 2474, as clarified in section 8 of this memo.
目前的文本也不符合BCP 37，互联网协议和相关标题中的值的IANA分配指南[5]。IPV4服务类型（TOS）字段和IPV6流量类别字段被6位DS字段和2位CU字段取代。IANA根据RFC 2474中的IANA注意事项部分在DS字段中分配值，如本备忘录第8节所述。
The consensus of the DiffServ working group is that BCP 37 correctly restates the structure of the former TOS and traffic class fields.
DiffServ工作组的共识是BCP 37正确地重述了前TOS和流量类字段的结构。
Therefore, for use in future documents, including the next update to RFC 2474, the following definitions should apply:
因此，为了在未来的文件中使用，包括RFC 2474的下一次更新，以下定义应适用：
- the Differentiated Services Field (DSField) is the six most significant bits of the (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet.
- 区分服务字段（DSField）是（前）IPV4 TOS八位字节或（前）IPV6流量类八位字节中的六个最高有效位。
- the Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS Node MUST use to select the PHB which is to be experienced by each packet it forwards.
- 区分服务代码点（DSCP）是在DS字段中编码的值，每个DS节点必须使用该值来选择其转发的每个数据包将经历的PHB。
The two least significant bits of the IPV4 TOS octet and the IPV6 Traffic Class octet are not used by Diffserv.
区分服务不使用IPV4 TOS八位字节和IPV6流量类八位字节的两个最低有效位。
When RFC 2474 is updated, consideration should be given to changing the designation "currently unused (CU)" to "explicit congestion notification (ECN)" and referencing RFC 3168 (or its successor).
更新RFC 2474时，应考虑将名称“当前未使用（CU）”更改为“显式拥塞通知（ECN）”，并参考RFC 3168（或其后续版本）。
The update should also reference BCP 37.
更新还应参考BCP 37。
Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to the realization that a concept was needed in Diffserv to capture the notion of a set of BAs with a common ordering constraint. This presently applies to AF behavior aggregates, since a DS node may not reorder packets of the same microflow if they belong to the same AF class. This would, for example, prevent an MPLS LSR, which was also
MPLS标签交换路由器（LSR）在区分服务支持方面的工作使人们认识到，在区分服务中需要一个概念来捕获具有公共顺序约束的一组BAs的概念。这目前适用于AF行为聚合，因为DS节点可能不会对属于相同AF类的相同微流的分组重新排序。例如，这将阻止MPLS LSR，这也是
a DS node, from discriminating between packets of an AF Behavior Aggregate (BA) based on drop precedence and forwarding packets of the same AF class but different drop precedence over different LSPs. The following new terms are defined.
DS节点，用于区分基于丢弃优先级的AF行为聚合（BA）的数据包和转发相同AF类但不同LSP上不同丢弃优先级的数据包。定义了以下新术语。
PHB Scheduling Class: A PHB group for which a common constraint is that, ordering of at least those packets belonging to the same microflow must be preserved.
PHB调度类：一个PHB组，其共同的约束是，必须至少保留属于同一微流的那些数据包的顺序。
Ordered Aggregate (OA): A set of Behavior Aggregates that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class.
有序聚合（OA）：共享排序约束的一组行为聚合。应用于这组行为聚合的PHB集构成PHB调度类。
Several implementors have pointed out ambiguities or conflicts in the Diffserv RFCs concerning behavior when a DS-node receives a packet with a DSCP which it does not understand.
一些实现者指出了Diffserv RFC中关于DS节点接收到不理解的带有DSCP的数据包时的行为的模糊性或冲突。
RFC 2475 states: "Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to the Default PHB codepoint [DSFIELD]."
RFC 2475规定：“入口节点必须调节所有其他入站流量，以确保DS代码点是可接受的；被发现具有不可接受的代码点的数据包必须被丢弃，或者在转发之前必须将其DS代码点修改为可接受的值。例如，从不存在增强服务协议的域接收流量的入口节点可以将DS代码点重置为默认PHB代码点[DSFIELD]”
On the other hand, RFC 2474 states: "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."
另一方面，RFC 2474声明：“接收到的带有无法识别的代码点的数据包应该被转发，就像它们被标记为默认行为一样（参见第4节），并且它们的代码点不应该被更改。”
RFC 2474 is principally concerned with DS-interior nodes. However, this behavior could also be performed in DS-ingress nodes AFTER the traffic conditioning required by RFC 2475 (in which case, an unrecognized DSCP would occur only in the case of misconfiguration). If a packet arrives with a DSCP that hadn't been explicitly mapped to a particular PHB, it should be treated the same way as a packet marked for Default. The alternatives were to assign it another PHB, which could result in misallocation of provisioned resources, or to drop it. Those are the only alternatives within the framework of RFC 2474. Neither alternative was considered desirable. There has been discussion of a PHB which receives worse service than the default; this might be a better alternative. Hence the imperative was "SHOULD" rather than "SHALL".
RFC 2474主要与DS内部节点有关。然而，在RFC 2475要求的流量调节之后，这种行为也可以在DS入口节点中执行（在这种情况下，只有在配置错误的情况下才会出现无法识别的DSCP）。如果数据包到达时带有未显式映射到特定PHB的DSCP，则应以与标记为默认值的数据包相同的方式处理该数据包。替代方案是为其分配另一个PHB，这可能导致配置资源的错误分配，或者放弃它。这些是RFC 2474框架内的唯一备选方案。这两种选择都不可取。有人讨论过PHB的服务比默认服务更差；这可能是一个更好的选择。因此，当务之急是“应该”而不是“应该”。
The intent of RFC 2475 clearly concerns DS-ingress nodes, or more precisely, the ingress traffic conditioning function. This is another context where the "SHOULD" in RFC 2474 provides the flexibility to do what the group intended. Such tortured readings are not desirable.
RFC 2475的意图显然涉及DS入口节点，或者更准确地说，入口流量调节功能。这是RFC 2474中“应该”的另一个上下文，该上下文提供了执行团队意图的灵活性。这种扭曲的解读是不可取的。
Therefore, the statement in RFC 2474 will be clarified to indicate that it is not intended to apply at the ingress traffic conditioning function at a DS-ingress node, and cross reference RFC 2475 for that case.
因此，将澄清RFC 2474中的陈述，以表明其不打算应用于DS入口节点的入口流量调节功能，并在该情况下交叉参考RFC 2475。
There was a similar issue, which manifested itself with the first incarnation of Expedited Forwarding (EF). RFC 2598 states:
有一个类似的问题，这表现在第一次化身的快速转发（EF）。RFC2598规定：
To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. (This rate must be <= the EF PHB configured rate.) Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all EF marked packets).
为了保护自身免受拒绝服务攻击，DS域的边缘必须严格按照与相邻上游域协商的速率对所有EF标记的数据包进行监控。（此速率必须<=EF PHB配置速率。）超过协商速率的数据包必须丢弃。如果两个相邻域尚未协商EF速率，则下游域必须使用0作为速率（即，丢弃所有EF标记的数据包）。
The problem arose in the case of misconfiguration or routing problems. An egress DS-node at the edge of one DS-domain forwards packets to an ingress DS-node at the edge of another DS domain. These packets are marked with a DSCP that the egress node understands to map to EF, but which the ingress node does not recognize. The statement in RFC 2475 would appear to apply to this case. RFC 3246 [7] clarifies this point.
问题出现在错误配置或路由问题的情况下。一个DS域边缘的出口DS节点将数据包转发给另一个DS域边缘的入口DS节点。这些数据包用一个DSCP标记，出口节点理解该DSCP映射到EF，但入口节点不识别该DSCP。RFC 2475中的陈述似乎适用于本案例。RFC 3246[7]澄清了这一点。
At least one implementor has expressed confusion about the relationship of the DSField, as defined in RFC 2474, to the use of the TOS bits, as described in RFC 1349. The RFC 1349 usage was intended to interact with OSPF extensions in RFC 1247. These were never widely deployed and thus removed by standards action when STD 54, RFC 2328, was published. The processing of the TOS bits is described as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10]. RFC 2474 states:
至少有一个实施者对RFC 2474中定义的DSField与RFC 1349中描述的TOS位的使用之间的关系表示困惑。RFC1349的使用旨在与RFC1247中的OSPF扩展交互。当STD 54、RFC 2328发布时，这些设备从未被广泛部署，因此被标准行动删除。TOS位的处理在RFC 1812[8]、RFC 1122[9]和RFC 1123[10]中描述为一项要求。RFC 2474规定：
"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位保持向后兼容性。”，
In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For completeness, when RFC 2474 is updated, the sentence should read:
此外，通过IESG行动，RFC 2474淘汰了RFC 1349。为完整起见，更新RFC 2474时，句子应为：
"No attempt is made to maintain backwards compatibility with the "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and [RFC1349]. This implies that TOS bit processing as described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted by this memo. Also see [RFC2780]."
“未尝试与[RFC791]和[RFC1349]中定义的IPv4 TOS八位字节的“DTR/MBZ”或TOS位保持向后兼容性。这意味着[RFC1812]、[RFC1122]和[RFC1123]中描述的TOS位处理也被本备忘录淘汰。另请参阅[RFC2780]”。”
IANA has requested clarification of a point in RFC 2474, concerning registration of experimental/local use DSCPs. When RFC 2474 is revised, the following should be added to Section 6:
IANA已要求澄清RFC 2474中关于实验/本地使用DSCP注册的一点。修订RFC 2474时，应在第6节中添加以下内容：
IANA is requested to maintain a registry of RECOMMENDED DSCP values assigned by standards action. EXP/LU values are not to be registered.
IANA被要求维护由标准行动分配的建议DSCP值的注册表。EXP/LU值不需要注册。
The following standards track and informational RFCs are expected to be updated to reflect the agreements captured in this memo. It is intended that these updates occur when each standards track RFC progresses to Draft Standard (or if some issue arises that forces recycling at Proposed). RFC 2475 is expected to be updated at about the same time as RFC 2474. Those updates will also obsolete this memo.
预计将更新以下标准跟踪和信息RFC，以反映本备忘录中的协议。当每个标准跟踪RFC进展到标准草案时（或者如果出现某些问题迫使在拟定阶段进行回收），这些更新将发生。RFC 2475预计将与RFC 2474同时更新。这些更新也将使本备忘录作废。
RFC 2474: revise definition of DS field. Clarify that the suggested default forwarding in the event of an unrecognized DSCP is not intended to apply to ingress conditioning in DS-ingress nodes. Clarify effects on RFC 1349 and RFC 1812. Clarify that only RECOMMENDED DSCPs assigned by standards action are to be registered by IANA.
RFC 2474：修订DS字段的定义。澄清在未识别DSCP的情况下建议的默认转发不适用于DS入口节点中的入口条件。澄清对RFC 1349和RFC 1812的影响。澄清IANA仅注册由标准行动指定的推荐DSCP。
RFC 2475: revise definition of DS field. Add SLS and TCS definitions. Update body of document to use SLS and TCS appropriately. Add definitions of PHB scheduling class and ordered aggregate.
RFC 2475：修订DS字段的定义。添加SLS和TCS定义。更新文档正文以适当使用SLS和TCS。添加PHB调度类和有序聚合的定义。
RFC 2497: revise to reflect understanding that, AF classes are instances of the AF PHB group, and are not collectively a PHB group.
RFC 2497：修改以反映以下理解：AF类是AF PHB组的实例，而不是PHB组的集合。
In addition, RFC 3246 [7] has added a reference to RFC 2475 in the security considerations section to cover the case of a DS egress node receiving an unrecognized DSCP which maps to EF in the DS ingress node.
此外，RFC 3246[7]在安全注意事项部分中添加了对RFC 2475的引用，以涵盖DS出口节点接收映射到DS入口节点中EF的未识别DSCP的情况。
Security considerations are addressed in RFC 2475.
RFC 2475中介绍了安全注意事项。
Acknowledgements
致谢
This memo captures agreements of the Diffserv working group. Many individuals contributed to the discussions on the Diffserv list and in the meetings. The Diffserv chairs were Brian Carpenter and Kathie Nichols. Among many who participated actively in these discussions were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur, and Fred Baker. Mike Ayers, Mike Heard and Andrea Westerinen provided valuable editorial comments.
本备忘录包含Diffserv工作组的协议。许多个人参与了关于Diffserv列表和会议的讨论。Diffserv椅子是Brian Carpenter和Kathie Nichols。在积极参与这些讨论的许多人中，有劳埃德·伍德、朱哈·海纳宁、格伦维尔·阿米蒂奇、斯科特·布里姆、沙拉姆·达瓦里、大卫·布莱克、杰拉德·加斯托、乔尔·哈尔潘、约翰·施尼兹林、弗朗索瓦·勒·福彻和弗雷德·贝克。Mike Ayers、Mike Heard和Andrea Westerinen提供了宝贵的编辑评论。
Normative References
规范性引用文件
[1] 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.
[1] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[2] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[3] Heinanen，J.，Baker，F.，Weiss，W.和J.Wrocklawski，“保证货运PHB集团”，RFC 25971999年6月。
[4] Ramakrishnan, K., Floyd, S. and D. Black "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[4] Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[5] Bradner, S. and V. Paxon, "IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers", BCP 37, RFC2780, March 2000.
[5] Bradner，S.和V.Paxon，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC2780，2000年3月。
[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[6] 威斯特林，A.，施尼兹林，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.和S.瓦尔德布瑟，“基于政策的管理术语”，RFC 3198，2001年11月。
[7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[7] Davie，B.，Charny，A.，Baker，F.，Bennett，J.C.R.，Benson，K.，Le Boudec，J.，Chiu，A.，Courtney，W.，Cavari，S.，Firoiu，V.，Kalmanek，C.，Ramakrishnam，K.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[8] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[9] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[9] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[10] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[10] Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
Author's Address
作者地址
Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048
丹格罗斯曼摩托罗拉公司，卡博特大道20号。马萨诸塞州曼斯菲尔德02048
EMail: dan@dma.isg.mot.com
EMail: dan@dma.isg.mot.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。