组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：liqiang（liqiang-007&nbsp;&nbsp;&nbsp;&nbsp;liqiang-007@263.net）<br />
译文发布时间：2001-7-16<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;K.&nbsp;Nichols<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2474&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
Obsoletes:&nbsp;1455,&nbsp;1349&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Blake<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Torrent&nbsp;Networking&nbsp;Technologies<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;F.&nbsp;Baker<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D.&nbsp;Black<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EMC&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;December&nbsp;1998<br />
<br />
&nbsp;&nbsp;&nbsp;IPv4与IPv6包头中差分服务字段（DS&nbsp;Field）的定义<br />
（RFC2474&nbsp;&nbsp;Definition&nbsp;of&nbsp;the&nbsp;Differentiated&nbsp;Services&nbsp;Field&nbsp;(DS&nbsp;Field)<br />
in&nbsp;the&nbsp;IPv4&nbsp;and&nbsp;IPv6&nbsp;Headers）<br />
<br />
本备忘录概况<br />
<br />
本文为Internet团体制定了一个标准协议，并在此请求得到讨论以使之得到完善。为得<br />
到本协议的标准声明与地位，请参考最新修订的“Internet官方协议标准”（STD&nbsp;1）。本文的<br />
分发是无限制的。<br />
版权通知<br />
<br />
版权属于&nbsp;?&nbsp;the&nbsp;Internet&nbsp;Society(1998)。版权所有。<br />
<br />
摘要<br />
差分业务作为互连网协议提出，目的在于：在不需要规定每一数据流的状况以及每一跳<br />
都要有所动作的情况下，使得能够对可以升级的、有区别的要求进行区分对待。而不同的服<br />
务类型可以从配置于网络节点中的小的、已定义了的构造块组中来构造。这些服务即可以是<br />
端到端的，也可以是在整个与内（定义）的；他们包括那些能满足一定性能的要求（如峰值<br />
带宽）也包括那些具有相对性的性能（如“等级”区分）。这些服务可由以下方式结合建立：<br />
?	在网络边界处（自治区域边界，内部管理边界或各个主机）的IP包头中设置特定<br />
比特；<br />
?	用这些比特来决定网络内部的节点如何转发这些包；<br />
?	在网络边界处，调节带有标记的包（的调度）使之与各个服务的要求或规则一致。<br />
这些各种服务的要求与规则必须由管理策略机构来制定，而这超出了本文的范围。一个适<br />
用于差分服务的网络节点包含有过滤器、缓冲管理与包调度机制。过滤器基于包头的DS字<br />
段的值来选择包，协同缓冲管理与包调度机制按该值所对应的转发方式来发送包。DS字段<br />
的设置与带有标志的包的调整训练只需在网络边界进行，而且在复杂性问题上有很大的区<br />
别。<br />
本文定义了IP包头一特定字段，我们称之为DS(为差分服务而定)字段。实际上，这个<br />
字段在IPv4定义为TOS及服务类型比特组，而在IPv6中则对应为流标签字段。另外，本<br />
文定义了一些基本的转发方式，如“单段行为”（PHB）。<br />
若想更完整的了解差分服务，请参阅“区分服务结构框架”[ARCH]。<br />
<br />
目录<br />
<br />
1.	导言	2<br />
2.	本文所用术语	4<br />
3.	DS字段的定义	5<br />
4.	从前的码值定义与PHB需求	6<br />
4.1默认PHB	6<br />
4.3&nbsp;&nbsp;总结	9<br />
5.	单段行为的标准化指南	9<br />
6.	IANA考虑	10<br />
7.	安全性考虑	11<br />
7.1盗用与拒绝差分服务	11<br />
7.2&nbsp;&nbsp;与IPsec和隧道技术的交互	11<br />
8.	致谢	12<br />
9.	参考资料	12<br />
10.	作者地址	13<br />
11.	版权陈述	14<br />
<br />
&nbsp;&nbsp;<br />
1.	导言<br />
<br />
差分服务的意图在于在因特网中配置一种能够对可以升级的、有区别的要求进行区分对<br />
待的网络框架与区块构造。差分服务的目标是将整个构造系统分为两个主要部分来加速这种<br />
配置的展开。这两部分一个相当容易理解，另一个我们才刚开始去理解。在这方面，我们以<br />
一种起初构造因特网时的思想作为指导，即将转发与路由部件分离。包转发机制是一个相对<br />
容易的工作，它只需要尽快的将每一个IP包转发出去。转发时，找到与包头所指对应的路<br />
由表项来决定该包的输出接口。而路由要设置路由表中表项，而且要对一定范围内的有关变<br />
化与其他一些情况如跟踪失败路由作出反应。路由表的维护是作为转发工作的背景程序进行<br />
的。进一步说，路由这一复杂的问题今天已经解决了二十年，而且还在继续发展。<br />
类似的，差分服务的框架也包含两个部分。一个是相当易于理解的在转发途中的处理举<br />
措，另一个是十分复杂的、还是刚刚显现出来的用来配置在转发过程中所用参数的后台程序<br />
与配置部件。其中，转发举措包括对于接受到的不同的包的区别对待，就如同在队列服务规<br />
则与队列管理规则中实现的一样。这些“单段行为”是十分必要的，且不论我们怎样构建端<br />
到端或整个域内的服务，需要网络中的节点能够转发我们区分对待了的包。我们的焦点在于<br />
一般语义上的“行为”而非用来实现他们的特定机制。这是因为这些“行为”会比机制发展<br />
的慢。<br />
在每一个包的基础上选择它们的单段行为及其机制如今可以放置在网络节点中，这也是<br />
差分服务所最先强调的问题。另外，转发所经的途径也需要训练、维护与整理来满足某些包<br />
所需要的“特殊对待”。这种类型的流调控机制也是相当易于理解的。这种调控的广泛配置<br />
在服务业务的构造中也是相当重要的，尽管它们的实际用途还要演化一段时间。<br />
为使特定的包得到特定的对待而如何配置网络组成部分与使用何种规则来应用资源是<br />
不大好理解的。尽管如此，用简单的策略与静态的配置在网络中展开差分服务还是可行的。<br />
正如在[ARCH]中所描述的一般，构造单段行为与流边界调节器来创建不同服务的方法由许<br />
多种。而且在此过程中，会得到许多经验来指导我们构建更复杂的策略与配置。当这一部件<br />
演变发展之后，转发途中的基本行为仍是不变的。构造这些服务的经验会在相当一段时间内<br />
继续发展下去，所以我们在这里尽量避免在这个构造成熟之前就把它标准化。进一步说，许<br />
多服务构造的细节问题是与不同的商业实体之间的法定协议相关的，我们也避开这个问题因<br />
为它不在IETF的研究范围内。<br />
本文着重与转发途径上面的问题。在包转发的过程中，差分服务通过包含于IP包头的<br />
一个字段的码值来映射一种特定的转发处理方式，即单段行为（PHB）,这是在转发途中的<br />
每一节点中都要进行的。而这之中的码值，则可以从本文所定义的强制应用的值中选择，也<br />
可从未来的文档所推荐的值中选择，或仅仅只是本地的自定义值。PHB的实现方法是：在<br />
网络节点的输出接口处使用一系列队列服务或队列管理规则，如加权轮询(WRR)队列服务或<br />
丢包优先级队列服务。<br />
做标记的工作是由网络边界处的流调节器包括网络边缘节点（第一跳路由或源主机）与<br />
有管理权限的边界点完成的。调节器的工作包括粗糙的打标记、测量与整理（这些机制在<br />
[ARCH]中描述）。而整个服务的完成时通过利用在边界点上的特定包的分类与流调整机制再<br />
加上在传送途中一连串的单段行为来表现的。差分服务的目的之一就是考虑将来的扩展性来<br />
规定这些构造区块，包括区块的数量与种类，也包括从中构建的服务。<br />
本文众说用道的术语在第二节中定义。差分业务字段的定义在第三节中给出。在第四届<br />
中我们讨论它与IPv4优先级的向后兼容性。作为结论，我们介绍了类选择码值与类选择下<br />
的PHB。第五章是单段行为标准化指南。第六章是定义码值的说明。第七章包含了一些有<br />
关安全性的考虑。<br />
本文只是简明的描述了DS字段及其使用。它应该参照“差分服务框架”（ARCH）阅读。<br />
本文中用到的关键字“必须”、“不允许”、“需要”、“应该”、“不应该”、“可以”、“不可<br />
以”、“建议”、“可能”、与“可选择”将在RFC2112中解释。<br />
2.	本文所用术语<br />
<br />
分组聚合：积聚通过某一通向某一特定方向的链路的具有相同码值的包。“聚合”与“分<br />
组聚合”在本文中是等价交替使用的。<br />
分类器：根据所定义的包头的内容选择包的一种实体。<br />
类选择码值：在‘xxx000’（此处的‘x’可为‘0’或‘1’）之间的任意一个码值。我<br />
们在4.2.2中讨论有关类选择码值的问题。<br />
类选择对应的PHB：满足4.2.2.2中指定的类选择PHB条件的单段行为。<br />
码值：DS字段中DS标记（DSCP）部分所指定的值。建议码值应该映射于特定的、标<br />
准化的单段行为。多个码值可以对应同一PHB。<br />
差分服务域边界：DS与的边缘。分类器与流定型器在此处配置。一个差分服务域边界<br />
可一细化分为两种节点：入口节点与出口节点。它们分别对应在边缘链路的指定方向的上行<br />
/下行流。典型的差分服务域边界位于包进入差分服务域的第一跳所对应的路由器（或网络<br />
节点），或包离开差分服务域边界在到达目的之前所经过的最后一跳所对应的路由器（或网<br />
络节点）。这种情况通常叫“叶路由器上的边界”，一个差分服务边界可以根据本地需要配置<br />
在主机中。差分服务域边界也叫DS边界。<br />
满足差分服务：与本文所指定的要求一致。<br />
差分服务域：一系列协同满足差分服务策略管理的、连续的英特网的一部分。一个差分<br />
服务于可以包括不同的主机与路由器、管理区域、自治域，不同的信任域与不同的网络技术<br />
（比如信元或帧）等等。差分服务域也叫DS域。<br />
差分服务字段：本文所给出定义的IP包头字段。实际上是IPv4中的TOS和IPv6中的<br />
流标签八位组。也叫DS字段。<br />
机制：特定算法所对应的一种或多种单段行为的实现方法。<br />
微量流：应用程序到应用程序间的定义了源地址、目的地址、协议ID、源端口号、目<br />
的端口号（当可用时）的流的一个实例。<br />
单段行为（PHB）：有关DS节点对通过某一条链路的具有相同DSCP的分组集合所施<br />
加的外部可见的转发行为的描述。PHB的描述应该足够详细，使之如[ARCH]中所描述的一<br />
样可以构建可预见的服务。<br />
PHB集合：一个或多个PHB组成的集合。这些PHB具有相同的指定意义，可以同时<br />
完成，因为这些PHB具有相同的约束，比如队列服务或队列管理策略。<br />
业务流定型：可用在分类聚合、应用业务流、或其他由意义的可操作的流的子集如路由<br />
更新等方面的控制功能。这些功能可能包括计量、整形、丢弃、标记。业务流定型用来增强<br />
域之间的协定，也可以通过在DS字段中作合适的标记与在必要时检查、改变某个聚合的临<br />
时特性来在域中得到差分服务。详情请参看[ARCH]。<br />
业务流定型器：一个具有业务流定型功能的实体。具体功能可以包括计量、整形、丢弃、<br />
标记。业务流定型器一般配置于DS边界节点（也就是说，不在DS域的内部节点中）。<br />
服务：对于客户的通过一特定的域、通过一系列互连的DS域或只是端对端的业务流的<br />
全部的（或一个子集）的处理。服务的描述由管理机制所表现。服务的构造是通过应用业务<br />
量定型来得到分组聚合（分组聚合在DS域中的每个节点都经历了特定的PHB）。多重服务<br />
可以通过许多业务流定型器中所应用的同一单段行为来支持。<br />
综上所述，分类器与业务流定型器起选择哪些包应该加入哪个分组聚合的作用。各个聚<br />
合在DS域中由其差别而受到不同的服务，而业务流定型器可能会依照某些请求改变聚合的<br />
短时特性。一个包的DS字段用来指定该报的分组聚合类别，从而达到决定这个包受到什么<br />
样的转发处理。一个分组聚合分类器可以选择一种PHB方式（比如说，用差分输出对流服<br />
务规则），这种选择基于包含在该DS域中所有网络节点中所定义的DS字段的码值。DS边<br />
界的分类器于业务流定型器是按照特定的服务所设置的，而这种管理策略不在本文的讨论范<br />
围之内。<br />
与差分服务相关的一些附加定义在[ARCH]中给出。<br />
3.	DS字段的定义<br />
<br />
我们定义DS字段来代表在[RFC791]中定义的IPv4包头中的TOS八位组与[IPv6]中所<br />
定义的流标签八位组。<br />
DS字段中的前六位定义为DS标记（码值），它用来在每个节点中选择包的PHB。剩下<br />
的两位目前未定义的比特为CU字段。这个字段的定义与解释不在本文的讨论范围内。CU<br />
位的值在差分服务节点对某一包进行单段行为时忽略。<br />
DS字段的结构如下所示：<br />
0&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;6&nbsp;&nbsp;&nbsp;7<br />
&nbsp;&nbsp;&nbsp;&nbsp;+---+---+---+---+---+---+---+---+---+---+<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DSCP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;CU&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;+---+---+---+---+---+---+---+---+---+---+<br />
<br />
DSCP：差分服务码值，即DS标记值<br />
CU：目前未定义<br />
<br />
在本文所示的DS标记中，标记‘xxxxxx’（此处‘x’可为‘0’或‘1’）的最左端比特位<br />
代表DS字段的0比特位，而其最右端比特代表DS字段的第5比特位。<br />
业务的提供者要注意DS标记字段宽度是6比特。提供DS服务的节点必须严格的以这<br />
6比特的DS标记字段来选择PHB。举例来说，用这个字段中定义的值作为一个索引表来选<br />
定应该对一个特定的包作何种处理（当然这种处理机制已经在该节点中实现了）。CU字段<br />
的值必须在选择PHB使被忽略（以便未来扩展功能）。，以便将来更加灵活的定义单端行为，<br />
DS标记字段并未系统化定义。<br />
由于以下所列出的问题，码值到PHB的映射必须是可以配置的。一个DS服务节点必<br />
须支持可配置的由码值到PHB的映射表的逻辑等同性。PHB的定义必须包括所建议的默认<br />
码值，这个码值必然是在对应的标准格式下（见第六节）独一无二的。就是说，服务必须在<br />
其默认设置下支持本文建议的码值到PHB的映射。但相关操作可以对不同的码值用同一个<br />
PHB，不论这个PHB是不是建议默认的。要注意的是，如果做出了这样的选择，就可能需<br />
要在DS管理域边界对DS字段重新做标记，就算是边界两边所执行的PHB相同也是一样。<br />
有关重新标记的深一步讨论请参考[ARCH]。<br />
对于与一般设置不同的例外即码值为‘xxx000’的情况，我们将在4.2.2与4.3中讨论。<br />
节点接到的包的码值若不能识别的话，节点应该把它当成作了默认标记的包而转发出去<br />
（详见第四节），而且包的码值不能被改变。这类包不可以让网络节点产生故障。<br />
上面所讲到的DS字段和现有的[RFC791]中的IPv4TOS八位组的定义是不同的。但正<br />
如一个网段使用RFC791的指定优先级一样，我们可以假设DS域可以通过配置重新做标记<br />
的边界节点来保护自己。正确的操作过程应当遵循[RFC791]，它指出：“如果这些指定优先<br />
级只是在一特定网段中使用，那么这个网段就有责任控制接入与使用这些优先级。”在任何<br />
情况下，DS边界确认DS字段的值都是明智的。因为一个上行流处的节点可以将这个值设<br />
成任意数。这样，未做到独立与未正确配置边界节点的DS域可能会承担不可预见的服务。<br />
为了提供所希望的本地的或端到端的服务，节点可能要重设DS字段的值。DS边界之间的<br />
DS字段如何转换事关业务提供者与用户之间的业务性条约，不再本文的讨论范围之内。标<br />
准的PHB使业务提供者可以从一系列众所周知的包转发策略中构建他们的服务。而这些策<br />
略可能已经配置在用户的设备中了。<br />
4.	从前的码值定义与PHB需求<br />
<br />
正如本节将要讨论的一样，DS字段与现行协议的先后兼容性有一定的限制。我们强调<br />
的“向后兼容性”有两个含义。首先，有一些单段行为已经广泛应用了（比方说，有一些满<br />
足[RFC1812]所指定的IPv4优先级队列条件的行为），我们希望使他们在DS与节点中能够<br />
得到不变得服务。另外，有一些现行码值满足IP优先级字段的描述，我们保留这些码值，<br />
并将他们映射到满足一般需要（在4.2.2.2中详细说明）的PHB上，但注意这些码值对应的<br />
特定的差分服务PHB可能有一些附加的说明。<br />
注意，我们并未在维护与“DTR”或IPv4服务类型八位组“TOS”的向后兼容性方面<br />
做过努力。<br />
4.1默认PHB<br />
<br />
DS服务节点中必须有一个默认的PHB。而这个PHB就是现行路由器中普遍的尽力转<br />
发行为（见[RFC1812]）。但没有达到其他共识时，节点就应该假设该包是属于默认聚合的。<br />
这种类型的包个能没有进行任何处理（没有要求服务）就发到网络中，网络应该尽可能多、<br />
尽可能快的转发这类包，当然这是受到其他一些运用资源的策略限制的了。对这种PHB的<br />
一种合理的实现方式为：当输出链路未被其他PHB要求所占用时，尽力法这个聚合中的包。<br />
而构建服务的一个合理的策略应该是：不要让聚合空闲。这种情况下的一种实现机制可以是：<br />
每个节点预留一小部分资源（比如说缓冲、带宽）来为默认聚合服务。这样就可以是根本不<br />
知道差分服务的用户像今天一样使用尽力转发的网络了。而一个域引入差分服务所给它的消<br />
费者与旁观者带来的对服务质量期望的冲击不在本文范围之内。默认PHB的建议码值的形<br />
式为‘000000’；而‘000000’这个值必须映射到满足这些规范的PHB上。这个默认码值的<br />
选择是与现行的[RFC791]兼容的。但节点发现一个包的码值没有映射到标准的或本地定义的<br />
PHB上时，因该将它映射到默认PHB。<br />
一个开始时做了默认行为标记的包在它进入另一个DS域的边界处可能会重新作另一个<br />
标记，这样它在这个域中的转发会使用不同的PHB。这可能受制于域与域之间的合约。<br />
4.2&nbsp;&nbsp;&nbsp;曾经和将来的IP优先级字段<br />
<br />
	我们希望在差分业务中可以维护与现行IP优先级字段即IPv4TOS八位组的0-2比特位<br />
的向后兼容性。现今的路由器在根据IP优先级字段选择不同的单段转发处理的操作与使用<br />
我们所提议的DSCP字段是相同的。所以，适当的调整这些路由器就可以很快的构造出一个<br />
简单的差分服务框架原型。另外，当今的IP系统知道IP优先级字段的位置，所以当我们配<br />
置了用于DS服务的设备之后以相同的方式运用这个字段，不会在网络配置过程中出现重大<br />
的错误。换句话说，就算在业务提供者的一个简单的网络中，若其DSCP字段的0-2比特与<br />
其从前配置的IP优先级字段的配置方式相同或是包含于它的话，严格满足DS条件的设备<br />
并不需要普遍存在。<br />
<br />
4.2.1&nbsp;&nbsp;IP优先级的历史与演变简述<br />
<br />
从某种意义上说，IP优先级字段是DS字段的先驱，我们最初对IP优先级字段的定义<br />
是在[RFC791]中。这个字段中的三个比特的值可能会指定起不同的作用，包括网络控制流、<br />
路由信息流、或不同级别的优先级。其中的最低优先级是“路由信息流”。在[RFC791]中，<br />
优先级的概念被广义的定义为“视数据流的重要程度而对其进行的独立处理”。并不是所有<br />
的IP优先级字段的值在包通过边界节点时都被认为是有意义的，例如“网络控制的优先级<br />
指定只会用在一个网段中，使用与管理这个指定权是网段自己的事”([RFC791])。<br />
尽管早期的BBN&nbsp;IMPs（路由器）就实现了这种优先级特性，但早期的商用路由器与<br />
UNIX&nbsp;IP转发机制不支持它。当网络越来越复杂、用户的要求越来越多时，上用路由器的卖<br />
主们开始开发实现不同种类的排队服务的方法，包括优先级排队。优先级排队一般来说基于<br />
路由器的过滤其中所编制的策略，它检查包的IP地址、IP端口号、TCP或UDP端口号与<br />
其它字段。IP优先级字段就是过滤器可以检查的内容的一项。<br />
总之，IP优先级已经广泛的配置与应用了，只不过它没有准确的按[RFC791]的方式进<br />
行。[RFC1122]认识到了这个问题，它指出，设定IP优先级字段是正确的，但是[RFC791]<br />
中明确指定的优先级已经成为历史。<br />
4.2.2&nbsp;&nbsp;包含IP优先级的类选择码值<br />
<br />
根据IP优先级字段来规范一个包的转发策略在当今已经是十分普遍的了，但对于来构<br />
建一个可预见服务质量的差分服务框架来说还不够完善。为了在不牺牲对于未来扩展的灵活<br />
性的前提下保留对于现存IP优先级字段的部分兼容性，我们的方法是：用一系列PHB描述<br />
最小的要求来与尽可能多的IP优先级字段配置的转发对策相对应。另外，我们给出了一系<br />
列必须映射于满足这些最小要求的PHB的码值。注意，这些PHB可能在除了此处提到的条<br />
件外还有一些详细的规范。剩余的码值可以映射的到这些PHB上。我们把这一系列码值叫<br />
做类选择码值，而这些码值对应的PHB的最小需求叫类选择PHB条件。<br />
4.2.2.1&nbsp;&nbsp;类选择码值<br />
由DS字段字为‘xxx000|xx’，或‘xxx000’加上未定义的CU自子段为保留类选择码<br />
值。由这些码值所映射的PHB除保留‘000000’所对应的默认PHB需求外必须满足类选择<br />
PHB条件（见4.1）。<br />
4.2.2.2&nbsp;类选择PHB条件<br />
	<br />
我们所说的类选择码值的数字越大，其相对的地位就越高；码值越小，其相对地位就越<br />
低。八个类选择码所映射的一系列PHB至少要产生两类独立的流，而且在合理的操作情况<br />
与业务负载下，一个类选择码值所规范的PHB应该给与对应包以不低于处于较低地位的类<br />
选择码值所规范的、更及时的转发服务。丢包现象是不及时转发的极端情况。另外，码值<br />
‘11x000’所选择的PHB必须要比码值‘000000’所选择的PHB优先，这是为了维护现行<br />
的路由信息所对应的IP优先级值‘110’和‘111’的作用。<br />
进一步说，明确的类选择码值选择的PHB应该被独立的转发，也就是说，作了不同的<br />
类选择码值记号的包可能会被重新排序。一个网络节点可能会对每个PHB所需的节点资源<br />
的量进行限制。<br />
满足这些规范的PHB集就是满足类选择的PHB。<br />
码值‘000000’的类选择PHB条件与4.1中所列出的默认PHB一致。<br />
4.2.2.3&nbsp;&nbsp;用类选择PHB条件与IP优先级兼容<br />
<br />
一个DS服务节点中可以配置一系列的单个或多个类选择PHB集。本文已指出码自己<br />
和‘xxx000’必须映射到这样的一系列PHB上。而由于多个码值可能映射到一个PHB，网<br />
络的投资者或网络管理者可以在不考虑DSCP字段的3-5比特的情况下配置网络节点，这样<br />
产生的网络必然与从前使用IP优先级的包兼容。比如说，码值‘011010’与码值‘011000’<br />
在这种情况下受到的PHB是一样的。<br />
4.2.2.4&nbsp;&nbsp;实现满足类选择PHB集的机制举例<br />
<br />
满足类选择PHB可通过多种机制实现，包括严格的优先级排队、加权公平排对（WFQ）、<br />
WRR及其变种[RPS,HPFQA,DRR]、CBQ[CBQ]等等。这些机制及其对应PHB的区别将在第<br />
五节中描述。<br />
值得注意的是，这些机制可能会在某些的定卖主的设备中所可行的（标准或非标准的）<br />
PHB中可行。举个例子来说，未来的文档可能会把严格优先级排队的PHB集定义在一组建<br />
议码值上，而网络管理员会将这些路由器设置为选择码值‘xxx000’的包进行严格优先级排<br />
队来满足该文档的要求。<br />
再例如，某个卖主可能将CBQ机制做入了路由器，那么CBQ机制可能会被用来完成<br />
严格优先级排队。这正如有很多特性的一系列类选择PHB在仅有最小的类选择PHB条件特<br />
性下可行一样。<br />
4.3&nbsp;&nbsp;总结<br />
<br />
本文定义了码值‘xxx000’来作为类选择码值，而由这些码值选择的PHB必须满足4.2.2.2<br />
中描述的类选择PHB条件。这是为了保持当前所用的IP优先级字段的可用性的向后兼容性<br />
且不影响未来的灵活性而指定的。另外，码值‘000000’用作默认PHB值而不准任意配置。<br />
剩下的七个非零类选择码值可进行配置，但要满足4.2.2.2的要求。<br />
5.	单段行为的标准化指南<br />
	<br />
此处要标准化的是PHB的操作特征，而不是具体的实现它们的特定算法与机制。一个<br />
节点可能会有（相当大）一组参数来控制如何调度包，并将它们送到输出接口（比方说，N<br />
个独立队列参数，队列长度，轮询加权值，丢包算法，丢包优先加权与门限等等）。为了说<br />
明PHB与其机制的区别，我们应该看到类选择PHB可以为许多机制所实现，包括严格的优<br />
先级排队、加权公平排对（WFQ）、WRR及其变种[RPS,HPFQA,DRR]、CBQ[CBQ]等等。<br />
它们可以单独或混合使用。<br />
PHB可以单独的设定，也可以作为集合而指定（单独的PHB是PHB集的特例）。PHB<br />
集通常一个或多个PHB组成的集合。这些PHB具有相同的指定意义，可以同时完成，因为<br />
这些PHB具有相同的约束，比如队列服务或队列管理策略。PHB集中有这样的情况：一个<br />
包可能会为了在包中选择另一PHB而重新做了标记。在这里，建议完成PHB是不要对流中<br />
包进行重新排序。还有，PHB集必须识别会发生在每个PHB上的包的重排序的任何可能，<br />
以及在集合中一个微流中的不同的包做了不同的PHB标记的可能。<br />
只有那些没有在现存PHB标准中描述过的、而被实现、配置且表明是有效的单段行为<br />
是应该被标准化的。但是由于当今的差分服务的经验还十分有限，假定确切的单段行为的规<br />
范是有欠成熟的。<br />
任意一个标准化的PHB必须有一个对应的建议码值，这个码值是从32个值（见第六节）<br />
中选择分配的。这一条给将来的演化发展流出了码值空间。这里定义的值（‘xxx000’）是有<br />
意的定在了小范围内。<br />
网络设备卖主可以提供它们认为有用的或由市场的任何参数和性能的设备。但一个节点<br />
实现了特定的表准化PHB，买主可以在满足标准定义的PHB的情况下使用任意算法。节点<br />
的性能与其特定设置决定了处理包的不同方法。<br />
业务提供者不需要在其网络中使用不变的节点机制或配置来进行差分服务，他们可以任<br />
意配置节点参数，只要它满足服务要求与业务工程目标即可。一段时间之后，某些通用的单<br />
段行为可能要演变（即那些对实现端到端服务有其有效的操作），他们可能会与DS字段的<br />
特定EXP/LU&nbsp;PHB码值有关，用来通过域边界（见第六节）。这些PHB有待未来的标准化。<br />
建议参照[ARCH]来指定标准化PHB。<br />
6.	IANA考虑<br />
<br />
DS字段中的DSCP字段可以有64个不同的码值。这个码值空间划分为三个部分（三个<br />
池）：有32个建议码值的池一用作[CONS]中定义的标准操作，有16个码值的池二为[CONS]<br />
中定义的实验与本地使用（EXP/LU）预留，剩下的有16个池三的值开始四是用作实验与本<br />
地使用，但可能会在标准指定的池一耗尽后补充使用。这三个池的定义如下表（‘x’指‘0’<br />
或‘1’）：<br />
池&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;码值空间&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;分配策略<br />
&nbsp;&nbsp;&nbsp;----&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;---------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-----------------<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xxxxx0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;标准操作<br />
&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xxxx11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EXP/LU<br />
&nbsp;&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xxxx01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EXP/LU&nbsp;(*)<br />
<br />
（*）可能将来需要使用作标准操作<br />
<br />
本文指定的八个建议码值（‘xxx000’），是从上面所说的池一中取的。这些码值必须被<br />
映射，不是映射到特定的PHB，而是按先前4.2.2.2中所要求的最低要求来提供与[RFC791]<br />
中定义的IP优先级（当今的一些设备所用）的最小限度的向后兼容性。<br />
7.	安全性考虑<br />
<br />
本节讨论由差分服务的引入所带来的安全性问题，主要问题在于拒绝访问攻击与未授权<br />
的业务流的窃取服务的潜在可能性（7.1）。7.2节着重讲在IPsec的情况下差分服务的操作，<br />
还有它与IPsec隧道模式和其他隧道模式协议的交互。有关差分服务整个结构的安全性问题<br />
的广泛讨论请参阅[ARCH]。<br />
7.1盗用与拒绝差分服务<br />
<br />
差分服务的最初目标在于在相同的网络基础结构下，为业务流提供不同级别的服务。许<br />
多技术都可以用来达到这一目标，即最终一些包将受到与其它包不同的（比如说更好的）服<br />
务。将网络中的流映射于特定的转发行为将最终得到不同（好或坏）的服务，而这个服务从<br />
根本上说是由DS码值所决定的。因此我们的对手可以通过改变码值，使码值代表增强服务，<br />
或直接将有这种码值的包注入网络来得到更好的服务。作为这个问题的极端，当修改过的或<br />
注入的流耗尽了用来转发它与其它业务流的资源时，这种盗用服务就成了拒绝服务攻击。对<br />
于这种盗用与拒绝服务攻击的防范措施在于DS域边界的业务流整形与DS域网络基础构造<br />
的安全性与整体性的结合。DS与边界节点必须保证所有进入域中的流所作的标记码值对本<br />
地情况都是恰当的，且必要的话对流重新做标记。这些DS边界节点是防范基于码值修改的<br />
盗用与拒绝服务攻击的第一道防线，因为这种攻击的成功表示攻击流所用的码值是不正确的<br />
码值。需要指出的是边缘节点可以是DS域中任一流的源节点。DS域内的节点依靠DS码<br />
字来确定流转发的PHB，不用再使用码值之前检查它。所以，内部节点可依赖DS域边界节<br />
点的正确操作来防止得到不正确码值流或超出预备级别的服务而中断域的正常工作。<br />
7.2&nbsp;&nbsp;与IPsec和隧道技术的交互<br />
<br />
在[ESP,AH]中定义的IPsec协议没有对IP包头的DS字段进行加密计算（在隧道模式中，<br />
在外部的IP包头的DS字段未加密）。网络节点对DS字段的改变对于IPsec的端到端安全<br />
性并没有任何影响，因为它不能使任何IPsec的校验失败。作为结论，IPsec并不提供任何<br />
用来防范我们对手改变DS字段（换句话说，是中间人攻击）的方法，正如同我们对手对<br />
DS字段的改变对IPsec的端到端安全性没作用一样。<br />
IPsec的隧道模式对封装了的IP头中的DS字段提供安全保证。在隧道模式下的IPsec<br />
包有两个包头：外部包头由隧道入口节点提供，而封装了的内部包头由包的源提供。但差封<br />
服务网络（全部或部分）建立了IPsec隧道后，中间网络节点只能在外部包头的DS地段操<br />
作了。在隧道的出口节点，IPsec的操作包括去掉外部包头与按包的内部包头转发（如果要<br />
求这样的话）。IPsec协议要求内部包头的DS字段在解封装的过程中不改变，以次来保证在<br />
IPsec隧道两端之间对DS字段的修改不会达到盗用与拒绝服务攻击的目的。本文对这一条<br />
件没有变动。如果内部IP由于隧道出口节点在域内而未被DS边界节点处理的话，隧道的<br />
出口节点就成为对于业务流出隧道的边界节点，因此必须确保得到的业务流有正确的DS码<br />
值。<br />
当在IPsec隧道出口的解封装过程中包含足够强度的对已封装的包的密码完整性的校验<br />
（此处的强度是由本地安全策略决定的）时，隧道的出口节点可以安全的假设内部包头的<br />
DS字段在与其到达隧道入口节点的值是相同。所以我们可以得到结论：DS域中的非安全链<br />
路的安全性可以通过足够强度的IPsec隧道来保证。这一结论及其含义适用于任何进行完整<br />
性校验的隧道协议技术，但内部包头DS字段的安全程度还有赖于隧道协议所进行的校验的<br />
强度。在使用缺乏足够信任度的、可能经过当前DS域外的节点（或是易受攻击）的隧道的<br />
情况下，封装了的包必须被当作是从DS域外来到了域边界来处理。<br />
8.	致谢<br />
<br />
作者在此感谢差分服务工作组，谢谢你们有助于定型本文的的讨论。<br />
9.	参考资料<br />
<br />
[AH]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Kent,&nbsp;S.&nbsp;and&nbsp;R.&nbsp;Atkinson,&nbsp;"IP&nbsp;Authentication&nbsp;Header",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;2402,&nbsp;November&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[ARCH]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Blake,&nbsp;S.,&nbsp;Black,&nbsp;D.,&nbsp;Carlson,&nbsp;M.,&nbsp;Davies,&nbsp;E.,&nbsp;Wang,&nbsp;Z.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and&nbsp;W.&nbsp;Weiss,&nbsp;"An&nbsp;Architecture&nbsp;for&nbsp;Differentiated<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Services",&nbsp;RFC&nbsp;2475,&nbsp;December&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[CBQ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Floyd&nbsp;and&nbsp;V.&nbsp;Jacobson,&nbsp;"Link-sharing&nbsp;and&nbsp;Resource<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Management&nbsp;Models&nbsp;for&nbsp;Packet&nbsp;Networks",&nbsp;IEEE/ACM<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Transactions&nbsp;on&nbsp;Networking,&nbsp;Vol.&nbsp;3&nbsp;no.&nbsp;4,&nbsp;pp.&nbsp;365-386,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;August&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[CONS]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Narten,&nbsp;T.&nbsp;and&nbsp;H.&nbsp;Alvestrand,&nbsp;"Guidelines&nbsp;for&nbsp;Writing&nbsp;an<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IANA&nbsp;Considerations&nbsp;Section&nbsp;in&nbsp;RFCs",&nbsp;RFC&nbsp;2434,&nbsp;October<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[DRR]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Shreedhar&nbsp;and&nbsp;G.&nbsp;Varghese,&nbsp;"Efficient&nbsp;Fair&nbsp;Queueing<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;using&nbsp;Deficit&nbsp;Round&nbsp;Robin",&nbsp;Proc.&nbsp;ACM&nbsp;SIGCOMM&nbsp;95,&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[ESP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Kent,&nbsp;S.&nbsp;and&nbsp;R.&nbsp;Atkinson,&nbsp;"IP&nbsp;Encapsulating&nbsp;Security<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Payload&nbsp;(ESP)",&nbsp;RFC&nbsp;2406,&nbsp;November&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[HPFQA]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Bennett&nbsp;and&nbsp;Hui&nbsp;Zhang,&nbsp;"Hierarchical&nbsp;Packet&nbsp;Fair<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Queueing&nbsp;Algorithms",&nbsp;Proc.&nbsp;ACM&nbsp;SIGCOMM&nbsp;96,&nbsp;August&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[IPv6]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Deering,&nbsp;S.&nbsp;and&nbsp;R.&nbsp;Hinden,&nbsp;"Internet&nbsp;Protocol,&nbsp;Version&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(IPv6)&nbsp;Specification",&nbsp;RFC&nbsp;2460,&nbsp;December&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC791]&nbsp;&nbsp;&nbsp;&nbsp;Postel,&nbsp;J.,&nbsp;Editor,&nbsp;"Internet&nbsp;Protocol",&nbsp;STD&nbsp;5,&nbsp;RFC&nbsp;791,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;September&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1122]&nbsp;&nbsp;&nbsp;Braden,&nbsp;R.,&nbsp;"Requirements&nbsp;for&nbsp;Internet&nbsp;hosts&nbsp;-<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;communication&nbsp;layers",&nbsp;STD&nbsp;3,&nbsp;RFC&nbsp;1122,&nbsp;October&nbsp;1989.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1812]&nbsp;&nbsp;&nbsp;Baker,&nbsp;F.,&nbsp;Editor,&nbsp;"Requirements&nbsp;for&nbsp;IP&nbsp;Version&nbsp;4<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Routers",&nbsp;RFC&nbsp;1812,&nbsp;June&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC2119]&nbsp;&nbsp;&nbsp;Bradner,&nbsp;S.,&nbsp;"Key&nbsp;words&nbsp;for&nbsp;use&nbsp;in&nbsp;RFCs&nbsp;to&nbsp;Indicate<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Requirement&nbsp;Levels",&nbsp;BCP&nbsp;14,&nbsp;RFC&nbsp;2119,&nbsp;March&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[RPS]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D.&nbsp;Stiliadis&nbsp;and&nbsp;A.&nbsp;Varma,&nbsp;"Rate-Proportional&nbsp;Servers:&nbsp;&nbsp;A<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Design&nbsp;Methodology&nbsp;for&nbsp;Fair&nbsp;Queueing&nbsp;Algorithms",&nbsp;IEEE/<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ACM&nbsp;Trans.&nbsp;on&nbsp;Networking,&nbsp;April&nbsp;1998.<br />
<br />
10.	作者地址<br />
&nbsp;&nbsp;&nbsp;Kathleen&nbsp;Nichols<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;170&nbsp;West&nbsp;Tasman&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;CA&nbsp;&nbsp;95134-1706<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;+1-408-525-4857<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;kmn@cisco.com<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;Steven&nbsp;Blake<br />
&nbsp;&nbsp;&nbsp;Torrent&nbsp;Networking&nbsp;Technologies<br />
&nbsp;&nbsp;&nbsp;3000&nbsp;Aerial&nbsp;Center,&nbsp;Suite&nbsp;140<br />
&nbsp;&nbsp;&nbsp;Morrisville,&nbsp;NC&nbsp;&nbsp;27560<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;+1-919-468-8466&nbsp;x232<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;slblake@torrentnet.com<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;Fred&nbsp;Baker<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;519&nbsp;Lado&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Santa&nbsp;Barbara,&nbsp;CA&nbsp;&nbsp;93111<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;+1-408-526-4257<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;fred@cisco.com<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;David&nbsp;L.&nbsp;Black<br />
&nbsp;&nbsp;&nbsp;EMC&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;35&nbsp;Parkwood&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Hopkinton,&nbsp;MA&nbsp;&nbsp;01748<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;+1-508-435-1000&nbsp;x76140<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;black_david@emc.com<br />
<br />
11.	版权陈述<br />
版权?&nbsp;the&nbsp;Internet&nbsp;Society(1998)。版权所有。<br />
本文和它的翻译可能被复制和提供给别人，并且引出一些评论或者解释它或援助它执行<br />
可能被准备，拷贝，出版和分配，不管是整体的还是局部的，没有任何限制，提供这上面的<br />
版权告示和包含所有拷贝和起源工作的章节。但是，这个文章它自己本身不能以任何方式修<br />
改，例如通过移走版权告示或因特网团体或别的因特网组织的参考书目，除了发展因特网标<br />
准的需要，在这种情况下，定义在因特网标准过程中的版权程序应该要有，或者需要翻译成<br />
不同于英语的别的语言。<br />
这个受限的许可同意以上的声明是永久的，并且它将不会被因特网团体或它的继任者或<br />
设计者废除。<br />
包含在这儿的这个文件和通知作为一个基础来提供。这个因特网团体和这个因特网工程<br />
任务迫使它宣布所有的授权，表达或隐含，包括但是不限制任何授权，在这儿信息的用途不<br />
破坏任何权利或任何隐含的购买授权或一个特别的目的。<br />
<br />
<br />
RFC2474—Definition&nbsp;of&nbsp;the&nbsp;Differentiated&nbsp;Services&nbsp;Field&nbsp;(DS&nbsp;Field)<br />
in&nbsp;the&nbsp;IPv4&nbsp;and&nbsp;IPv6&nbsp;Headers<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IPv4与IPv6包头中差分服务字段（DS&nbsp;Field）的定义<br />
1<br />
<br />
1<br />
RFC中文翻译计划<br />