组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)<br />
E-mail：ouyang@china-pub.com<br />
译者：徐国栋（xgdong_y994&nbsp;xgdong@sina.com&nbsp;）<br />
译文发布时间：2001-6-27<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Blake<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2475&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Torrent&nbsp;Networking&nbsp;Technologies<br />
Category:&nbsp;Informational&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Carlson<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;Sun&nbsp;Microsystems<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E.&nbsp;Davies<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Nortel&nbsp;UK<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Z.&nbsp;Wang<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;Bell&nbsp;Labs&nbsp;Lucent&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;W.&nbsp;Weiss<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;Lucent&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;&nbsp;December&nbsp;1998<br />
分类业务的体系结构<br />
(An&nbsp;Architecture&nbsp;for&nbsp;Differentiated&nbsp;Services)<br />
本文档的状态<br />
本文档为互连网社区提供一般性的知识。并未定义任何互连网标准。对本文档资料的<br />
分发、传播不受限制。<br />
<br />
版权声明<br />
&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;&nbsp;Society&nbsp;(1998).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
摘要<br />
本文档定义了一种可以在互连网上实现可扩展的分类业务的体系结构。这种体系结构<br />
通过标记IP&nbsp;层数据包的DS段[DSFIELD]，体现不同的业务级别，从而提供扩展性业务。<br />
在一个数据包的传输路径上的每一节点，都根据该数据包的分类标记为其提供特定的传输<br />
服务。复杂的分类，标记，传输策略，及整形操作仅仅需要在网络边缘或用户主机上实<br />
现。网络资源根据服务策略而被分配给不同的业务流。这些服务策略管理着业务数据在进<br />
入一个具有分类业务能力的网络时，如何标记，调整，并在网络中向前传输。在这些基本<br />
分类业务模块的基础上，可以实现各种各样的服务。<br />
<br />
<br />
<br />
<br />
目&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;录<br />
<br />
1	介绍	3<br />
1.1	综述	3<br />
1.2	术语	4<br />
1.3	需求	6<br />
1.4	和其它方法的比较	7<br />
2	分类业务体系结构模型	8<br />
2.1	分类业务域（DS域）	8<br />
2.1.1	DS&nbsp;边界节点和内部节点	9<br />
2.1.2	DS&nbsp;入口节点和出口节点	9<br />
2.2	分类业务区域	9<br />
2.3	业务量分类和调节	9<br />
2.3.1	分类器	10<br />
2.3.2	业务量简档	10<br />
2.3.3	业务量调节器	10<br />
2.3.4	业务量调节器和MF分类器的位置	12<br />
2.4	每一跳行为	13<br />
2.5	网络资源分配	13<br />
3	每一跳行为（PHB）的规范设计指导方针	14<br />
4	与非分类业务兼容节点的互操作	16<br />
5	关于组播	17<br />
6	安全和隧道问题	17<br />
6.1	窃取和拒绝服务	17<br />
6.2	IPSEC和隧道交互	18<br />
6.3	审查	19<br />
7	感谢	20<br />
8	参考文献	20<br />
9	作者联系地址	21<br />
10	完整版权声明	22<br />
<br />
<br />
<br />
<br />
<br />
1	介绍<br />
1.1	综述<br />
本文档定义了一种可以在互联网上提供可扩展的分类业务的体系结构。一种“业务”，是<br />
由在一个网络内，在同一个传输方向上，通过一条或几条路径传输数据包时的某些重要特征所<br />
定义的。这些特征可能由吞吐率，时延，时延抖动，和/或丢包率的量化值或统计值所指定，<br />
也可能由其获取网络资源的相对优先权来指定。业务分类要求能适应不同应用程序和用户的需<br />
求，并且允许对互联网服务的分类收费。<br />
本体系结构由许多在网络节点上实现的功能实体组成，包括每一跳转发行为集合，数据包<br />
分类功能，和业务量调节功能。其中，业务量调节功能又有测量，标记，整形，和监察四部<br />
分。在本体系结构，只在网络的边界节点上实现复杂的分类和调节功能。并且，通过在IPv4<br />
和IPv6包头的DS段做适当的标记&nbsp;[DSFIELD]，把业务量归为集合，然后根据所做的标记，<br />
采取不同的每一跳转发策略。因此，本体系结构具备可扩展性。“每一跳行为”保证了在每个<br />
网络节点，为互相竞争资源的业务流分配缓冲区和带宽资源时，有一个合理的处理粒度。在核<br />
心网络节点上，为每个应用程序业务流或者为每个用户维护一个转发状态是不可行的。在以下<br />
功能中是有区别的：<br />
?	向业务集合提供的服务<br />
?	用于实现某种服务的调节功能和每一跳行为<br />
?	用于标记数据包从而选择每一跳行为的DS段值（DS编码点）<br />
?	实现每一跳行为时，特定节点的实现机制<br />
在网络内部节点，服务提供和业务量调节策略被有效地同数据包转发策略分离开。这样，<br />
保证了网络可以提供相当广泛的服务类型，并给未来的扩展留下足够的空间。<br />
本体系结构只在一个业务流方向上提供分类业务，它是非对称的。开发出一种对称式的体<br />
系结构是目前研究的一个课题，但已经超出了本文档的描述范围；感兴趣的读者可以参考&nbsp;<br />
[EXPLICIT]。<br />
1.2节是本文档使用的术语表。1.3节列出了本体系结构所解决的需求。1.4节提供了与其<br />
它分类业务解决方案的简要比较。第2节详细介绍了本体系结构中的各个模块。第3节建议了<br />
每一跳行为规范的设计准则。第4节讨论了与没有实现本文档及&nbsp;[DSFIELD]定义的分类业务<br />
功能的节点和网络的互操作问题。第5节讨论了与多点传送有关的问题。第6节讨论安全和隧<br />
道问题。<br />
<br />
1.2	术语<br />
本节给出了在本文档中所使用术语的一般性概念解释。其中的某些术语将在文档后面章节<br />
中给出更准确的解释。<br />
<br />
行为集合（Behavior&nbsp;Aggregate&nbsp;:&nbsp;BA）		一个DS行为集合。<br />
BA分类器（BA&nbsp;Classifier）			仅基于DS段的内容选择数据包的分类器。<br />
边界连接（Boundary&nbsp;Link）			连接两个域的边界节点的连接。<br />
分类器（Classifier）	根据已定义的规则和包头内容选择数据包的<br />
实体。<br />
DS行为集合（DS&nbsp;Behavior&nbsp;Aggregate）	在一个特定方向上，通过一条连路传输的具<br />
有相同DS编码点的数据包集合。<br />
DS边界节点（DS&nbsp;Boundary&nbsp;Node）	在DS域中，负责连接另一个ＤＳ域或者连接<br />
一个没有ＤＳ功能的域的节点。<br />
具有ＤＳ功能（DS-capable）	实现了本体系结构中定义的分类业务功能<br />
的；通常用于形容一个由ＤＳ兼容节点组成<br />
的域。<br />
ＤＳ编码点（DS&nbsp;Codepoint）	ＤＳ段中ＤＳＣＰ部分的特定值，用于选择<br />
ＰＨＢ。<br />
ＤＳ兼容（DS-compliant）	能够支持在[DSFIELD]，本文档，和其它有<br />
关分类业务的文档中定义的分类业务功能<br />
的；通常用来形容一个节点或者网络设备。<br />
ＤＳ域（DS&nbsp;Domain）	具有ＤＳ功能的域；连续分布的节点的集<br />
合，它们具有共同的服务提供策略和ＰＨＢ<br />
定义。<br />
ＤＳ出口节点（DS&nbsp;Egress&nbsp;Node）	处理离开此ＤＳ域的业务流的ＤＳ边界节<br />
点。<br />
ＤＳ入口节点（DS&nbsp;Ingress&nbsp;Node）	处理进入此ＤＳ域的业务流的ＤＳ边界节<br />
点。<br />
ＤＳ内部节点（DS&nbsp;Interior&nbsp;Node）	非边界节点的ＤＳ节点。<br />
ＤＳ段（DS&nbsp;Field）	在ＩＰｖ４中，指ＴＯＳ字节；在ＩＰｖ６<br />
中，指业务类型字节。其中的ＤＳＣＰ段诸<br />
比特用于编码ＤＳ编码点，其它的比特目前<br />
没有使用。<br />
ＤＳ节点（DS&nbsp;Node）	ＤＳ兼容的节点<br />
ＤＳ区（DS&nbsp;Region）	连续分布的ＤＳ域的集合，在其上可以建立<br />
跨越多个ＤＳ域提供分类业务的连路。<br />
下游ＤＳ域（Downstream&nbsp;DS&nbsp;Domain）	一个边界连接中，位于业务流下游的ＤＳ<br />
域。<br />
丢包器（Dropper）	负责丢包的功能模块。<br />
丢包（Dropping）	基于一定的原则丢弃数据包；参见&nbsp;监察<br />
（Policing）。<br />
遗留节点（Legacy&nbsp;Node）	实现了在[RFC791，RFC1812]中定义的<br />
IPv4优先算法，但并非DS兼容的节点。<br />
标记器（Marker）	负责标记的功能模块。<br />
标记（Marking）	基于一定的原则设置一个数据包的DS编码<br />
点；参见&nbsp;预标记（Pre-marking），重标记<br />
（Re-marking）。<br />
机制（Mechanism）	在节点中用于实现一种或多种每一跳行为的<br />
特殊算法或操作（例如，排队策略）。<br />
测量器（Meter）	负责测量的功能模块。<br />
测量（Metering）	计算由分类器选中的业务流的时间性特征<br />
（例如，速率）。这一过程的即时状态可能<br />
会影响标记器，整形器，或者丢包器的行<br />
为，也可能被用于记帐收费或者纯粹的测量<br />
目的。<br />
微流（Microflow）	一个独立的从应用程序到应用程序的数据包<br />
流，由源地址，源端口号，目的地址，目的<br />
端口号和协议标识符区分。<br />
MF分类器（MF&nbsp;Classifier）	根据任意数目的包头字段的内容来选择数据<br />
包的多字段（MF）分类器。典型的字段组合<br />
可能包括源地址，目的地址，DS段，协议标<br />
识符，源端口号和目的端口号。<br />
每一跳行为（Per-Hop-Behavior&nbsp;:&nbsp;PHB）	在DS兼容节点上，作用在DS行为集合上的<br />
外界可观察的转发行为。<br />
PHB组（PHB&nbsp;Group）	由一个或多个PHB组成的集合。这些PHB<br />
由于共同的限制，例如队列服务或队列管理<br />
策略，必须同时被指定及实现。PHB组提供<br />
了构建服务的基石，使得一系列的转发行为<br />
可以被同时指定。一个单独的PHB是PHB<br />
组的特例。<br />
监察（Policing）	根据依照某种业务量简档工作的测量器的状<br />
态，丢弃（通过丢包器）业务流的部分数据<br />
包。<br />
预标记（Pre-mark）	在数据包进入下游DS域之前，设置其DS编<br />
码点。<br />
提供者DS域（Provider&nbsp;DS&nbsp;Domain）	具有DS功能的服务提供者所属的源域。<br />
重标记（Re-mark）	改变数据包的DS编码点。通常由标记器根据<br />
TCA确定如何修改。<br />
服务（Service）	在DS域内或者在端到端条件下，对用户业务<br />
量的一个确定的子集所采取的所有处理措<br />
施。<br />
服务水平协议（Service&nbsp;Level&nbsp;Agreement&nbsp;：SLA）	用户和服务提供者之间达成的关于如<br />
何为用户提供转发服务的服务协议。这里的<br />
用户可能是一个使用者组织（源域），也可<br />
能是另一个ＤＳ域（上游域）。服务水平协<br />
议SLA可以包括部分或全部组成一个ＴＣＡ<br />
的业务量调节规则。<br />
服务提供策略（Service&nbsp;Provisioning&nbsp;Policy）	关于业务调节器如何配置到ＤＳ边界节点<br />
上，及业务流如何映射到特定的ＤＳ行为集<br />
合以获得某些服务的策略。<br />
整形器（Shaper）	负责业务量整形的功能模块。<br />
整形（Shaping）	有意延迟业务流中的某些数据包，以使业务<br />
流符合预先定义的业务量简档。<br />
源域（Source&nbsp;Domain）	发出接受某种特定服务的业务流的节点所在<br />
的域。<br />
业务量调节器（Traffic&nbsp;Conditioner）	负责完成业务量调节功能的功能实体。包括<br />
测量器，标记器，丢包器，和整形器。业务<br />
量调节器可以重新标记业务流，或者丢弃或<br />
整形数据包，从而改变业务流的时间特征，<br />
使业务流符合事先达成的业务量简档。<br />
业务量调节（Traffic&nbsp;Conditioning）	实现ＴＣＡ中确定的控制规则，包括测量，<br />
标记，整形，和监察。<br />
业务量调节协议（Traffic&nbsp;Conditioning&nbsp;Agreement&nbsp;:&nbsp;TCA）	一份指明应用到分类器选中<br />
的业务流的分类规则，相应的业务量简档，<br />
以及对此业务流的测量，标记，丢弃，和／<br />
或整形规则的协议。ＴＣＡ包括来自三方面<br />
的业务量调节规则：ＳＬＡ显式指定，相关<br />
的服务需求隐式指定，和／或来自于ＤＳ域<br />
的服务提供策略。<br />
业务量简档（Traffic&nbsp;Profile）	关于业务流的时间特征的描述，例如速率和<br />
突发包大小。<br />
业务流（Traffic&nbsp;Stream）	具有管理重要性的通过同一段路径的一个或<br />
多个微流的集合。业务流可能包含由特定的<br />
分类器选出的活动的微流集合。<br />
上游ＤＳ域（Upstream&nbsp;DS&nbsp;Domain）	一个边界连接中，位于业务流上游的ＤＳ<br />
域。<br />
<br />
1.3	需求<br />
在互联网的发展历史上，从主机数目，到应用程序的种类和数量，再到网络基础设施的能<br />
力，都有着持续的增长。而且，这种增长在可预见的未来还会持续。因此，必须有一种支持分<br />
类业务的可扩展体系结构与这种持续增长相适应。<br />
在这种体系结构中，下列需求必须得到认可，并能被满足：<br />
?	提供从端到端或者在特定网络（或网络集合）内部的，多种多样的服务和提供策略。<br />
?	允许将服务从特定的应用程序中分离出来。<br />
?	能够与已有的应用程序共存，而无须改变应用程序编程接口或者主机软件（假设适当<br />
配置了分类器，标记器，和其它的业务量调节功能模块）。<br />
?	应该在核心网络节点实现时，将业务量调节和服务提供功能同转发行为相分离。<br />
?	不应依赖逐跳的应用程序信令。<br />
?	仅需要一个很小的转发行为集合。其实现复杂性不应是网络设备开销的主要部分，也<br />
不应给未来高速系统的实现引入瓶颈。<br />
?	应该避免在核心网络节点内为每个微流或者每个用户保持各自的状态。<br />
?	在核心网络节点内，应仅保存集合分类状态。<br />
?	允许在核心网络节点实现简单的数据包分类（BA分类器）。<br />
?	允许同无DS兼容性的网络节点的合理的互操作性。<br />
?	具备增量式布署能力。<br />
<br />
1.4	和其它方法的比较<br />
在本文档中定义的分类业务体系结构可以同其它已存在的分类业务模型相比较。我们把这<br />
些可选的模型分为如下几类：相对优先级标记，服务标记，标签交换，集成业务/RSVP，和静<br />
态逐跳分类。<br />
相对优先级标记模型的例子包括[RFC791]定义的IPv4优先级标记，802.5令牌环优先级<br />
[TR]，和缺省的802.1p业务量分类[802.1p]。在这个模型中，应用程序，主机，或者代理节<br />
点为数据包选择一个相对优先级（例如，延迟或者丢弃优先级）。在整个传输路径上的网络节<br />
点根据包头中指定的优先级采取相应的转发行为。我们的体系结构可以被认为是这种模型的更<br />
新。在这种体系结构中，更清楚的指明了边界节点和业务量调节器的作用及重要性；并且，每<br />
一跳行为模型也允许比相对延迟或丢弃优先级更具一般性的转发行为。<br />
服务标记模型的一个例子是[RFC1349]定义的IPv4&nbsp;TOS。在这个例子中，每个数据包被<br />
标记为需求某种“服务类型”，包括“延迟最小化”，“吞吐量最大化”，“可靠性最大<br />
化”，或者“费用最小化“。网络节点根据标记的服务类型选择路由或者转发行为。这个模型<br />
同我们的体系结构有细微的差别。请注意，我们并没有描述使用DS段做为路由选择的输入。<br />
[RFC1349]定义的TOS标记具有广泛的一般性，无法扩展可能的服务语义范围。而且，其服<br />
务需求是与每一个数据包相关联的，但有些服务语义可能依赖于一系列数据包的整体转发行<br />
为。服务标记模型不能很容易的适应未来服务范围和数量的增长（鉴于其编码空间太小），而<br />
且在每一个核心网络节点都会涉及“TOS到转发行为”的转换。服务标记的标准化还意味着提<br />
供服务的标准化，这已经超出了IETF的工作范围。注意服务提供记录在分配的DS编码空间<br />
中，从而允许具有本地重要性的编码点被提供者用于提供服务标记语义[DSFIELD]。<br />
标签交换（或叫做虚电路）模型的例子包括帧中继，ATM，和MPLS[FRELAY，ATM]。<br />
在这种模型中，沿网络路径的每一跳，都建立业务流的路径转发状态和业务管理或QoS状态。<br />
各种不同粒度的业务量集合在入口节点处与一条标签交换路径相关联。在每一标签交换路径<br />
内，数据包或信元被赋予一个转发标签。转发标签负责寻找下一跳节点，每一跳转发行为，和<br />
在每一跳时的标签置换。由于标签并非全局性的，而只是在一条链路上有效，所以这种模型允<br />
许对业务量分配资源时能采取更好的粒度。也正因为如此，网络资源可以被预留给在某条链路<br />
上收到的具有特定标签的数据包或信元集合，同时，标签交换语义控制着下一跳路由选择，允<br />
许业务流通过特别设计的路径穿过网络。这种改进的粒度控制是以增加建立和维护标签交换路<br />
径的管理和配置需求为代价的。并且，在最好情况下，每个节点保存的转发状态数量与边界节<br />
点数量成正比（假设存在多点到点的标签交换路径）；在最坏情况下（采用提供资源的边到边<br />
标签交换路径），与边界节点数量的平方成正比。<br />
集成业务/RSVP模型在缺省情况下依赖传统方式转发数据包，同时，它也允许发送方和接<br />
收方通过信令交互在两者之间的路径上每个节点处建立额外的数据包分类和转发状态<br />
[RFC1633，RSVP]。由于缺少对业务流的归类，每个节点保存的状态数将与并发的资源预留<br />
数成正比。在一些高速链路上，这个数目可能会很大。这个模型还需要应用程序支持资源预留<br />
信令协议。在核心网络节点，可以使用分类业务机制将集成业务/RSVP状态归类[BERNET]。<br />
集成业务/RSVP模型的一个变种通过在网络路径沿途的每个节点处只采用“静态”分类和<br />
转发策略，使逐跳进行信令交互变的不再需要。这些策略是管理级的，并非针对网络中的活动<br />
微流。这个变种的状态需求可能会比RSVP更多，特别是在骨干网节点处。因为随着时间推<br />
移，一个节点所采用的静态策略数可能比在此节点请求资源预留的活动的发送-接收对话数还要<br />
多。虽然采用大数量的分类规则和转发策略在计算复杂性上可行，但由此而需要在业务流必经<br />
的骨干网节点处安装和维护这些规则的管理负担也是需要认真考虑的。<br />
以上把我们提出的体系结构与其它的分类业务模型进行了比较。需要注意的是，采用这些<br />
技术的链路和节点应该是通过基于第二层交换的网络结构（例如，802.1p&nbsp;局域网，帧中继<br />
/ATM骨干网）互连DS节点，来提供分类业务行为和语义。对于MPLS（多协议标签交换）<br />
条件下，可以作为可选的域内实现技术。在DS域（或者在提供DS域接入的网络内）的特定<br />
区域采用特殊的链路层技术，意味着对业务流更粗粒度的分类。依赖于从PHB到不同的链路<br />
层服务的映射和把数据包安排到有限优先级（或者不同类型和能力的虚电路）的方式，全部或<br />
部分使用中的PHB是可被支持的（或者是不可辨别的）。<br />
<br />
2	分类业务体系结构模型<br />
分类业务体系结构基于这样一个简单模型：进入网络的业务量在网络边缘处进行分类和可<br />
能的调节，然后被分配到不同的行为集合中去。每一个行为集合由唯一的DS编码点标识。在<br />
网络核心处，数据包根据DS编码点对应的每一跳行为转发。在本节中，我们讨论在分类业务<br />
区域中的关键组件，业务量分类和调节功能，以及分类业务是如何通过业务量调节和基于PHB<br />
的转发而实现的。<br />
<br />
2.1	分类业务域（DS域）<br />
DS域是邻接的DS节点集合。这些DS节点执行共同的服务提供策略，并实现相同的<br />
PHB组。每个DS域都拥有完好定义的边界。位于边界处的DS边界节点负责将进入此DS域<br />
的业务流分类及进行可能的调节，以保证穿过此DS域的数据包被适当标记，并按照DS域所<br />
支持的PHB组中的一个PHB转发。DS域内的节点根据DS编码点为数据包选择转发行为。<br />
从DS编码点值到某个被支持的PHB组的映射，依赖的是推荐的编码点到PHB的映射规则或<br />
者用户定义的本地化映射规则[DSFIELD]。如果在DS域中包含非DS兼容节点，那么很可能<br />
导致性能表现的无法预测，并且会妨碍服务水平协议（SLA）的实现。<br />
一个DS域通常包含一个或多个处于同一组织管理下的网络；例如，一个组织的内部网或<br />
者一个Internet服务提供商（ISP）。域管理者必须保证有足够的资源被提供和/或预留，从<br />
而足以支持域提供的SLA。<br />
2.1.1	DS&nbsp;边界节点和内部节点<br />
DS域由DS边界节点和DS内部节点组成。DS边界节点连接本DS域和其它DS域或者<br />
无DS能力的域，DS内部节点连接同一DS域的其它DS内部节点或者边界节点。<br />
无论是DS边界节点还是内部节点都必须能够按照DS编码点信息采用合适的PHB转发数<br />
据包；否则会导致有不可预测的行为发生。另外，DS边界节点可能还需要实现其所在DS域<br />
和其连接的对等DS域之间的业务量调节协议（TCA）所定义的业务量调节功能（参见2.3.3<br />
节）。<br />
内部节点可能会实现有限的业务量调节功能，例如DS编码点的重新标记。那些实现了更<br />
为复杂的分类和业务量调节功能的内部节点与DS边界节点类似（参见2.3.4.4节）。<br />
一台DS域网络中的主机对于源于其上运行的应用程序的业务流，相当于一个DS边界节<br />
点；因此我们称这台主机在DS域内。如果这台主机并未实现边界节点功能，那么在拓扑结构<br />
上最靠近此主机的DS节点，将为主机业务流提供DS边界节点功能。<br />
<br />
2.1.2	DS&nbsp;入口节点和出口节点<br />
DS边界节点对于不同方向的业务流，既可以是DS入口节点，又可以是DS出口节点。业<br />
务流在DS入口节点处进入DS域，在DS出口节点处离开DS域。DS入口节点负责保证进入<br />
DS域的业务流符合本域和此节点直连的另一个域之间的TCA。DS出口节点依据两个域之间<br />
的TCA细节，对转发到其直连的对等域的业务流执行业务量调节功能。注意DS边界节点在某<br />
些接口中可以作为DS内部节点。<br />
<br />
2.2	分类业务区域<br />
一个或多个邻接的DS域统称为分类业务区域（DS区）。DS区可以支持贯穿区内多个<br />
DS域的分类业务。<br />
DS区中的DS域可能支持不同的PHB组，和编码点到PHB的映射规则。不过，为了提<br />
供贯穿多个DS域的业务，每个对等的DS域都必须建立定义（无论显式的或是隐式的）了<br />
TCA的对等SLA。TCA指明了如何在域边界处调节从一个DS域传向另一个DS域的业务<br />
流。<br />
DS区内的DS域也可以采用相同的服务提供策略，并支持相同的PHB组和编码点映射。<br />
这样的好处是消除了在DS域间进行业务量调节的需求。<br />
<br />
2.3	业务量分类和调节<br />
分类业务通过在上游网络和下游DS域之间建立服务水平协议（SLA）跨越DS域边界。<br />
SLA指定了数据包分类和重标记规则，也指定了业务量简档和对于符合或不符此简档的业务流<br />
采取的处理方法（参见2.3.2节）。域间的TCA就是从SLA以直接或间接的方式取得的。<br />
数据包分类策略负责识别出业务量子集，这个子集通过被调节和/或映射到一个或多个行为<br />
集合（通过DS编码点重标记）而取得分类服务。<br />
业务量调节包括测量，整形，监察和/或重标记。其目的是为保证进入DS域的业务流符合<br />
TCA指定的规则。业务量调节的外延依赖于具体的服务细节，涵盖的范围从简单的编码点重标<br />
记到复杂的业务监察和整形操作。业务量调节策略的细节应该由网络间协商确定，这个问题不<br />
在本文档论述范围内。<br />
<br />
2.3.1	分类器<br />
数据包分类器根据数据包包头的某些字段内容选取业务流中的数据包。我们定义了两种分<br />
类器。行为集合分类器（BA分类器）仅根据DS编码点对数据包分类。多字段分类器（MF分<br />
类器）根据包头中的一个或多个字段值，例如源地址，目的地址，DS段，协议标识符，源端<br />
口号，目的端口号，以及其它信息如引入接口，对数据包分类。<br />
分类器的任务就是选出匹配某种规则的数据包，然后指导它们进入其它的业务量调节器模<br />
块接受进一步处理。分类器必须由某个管理例程根据合适的TCA进行配置。<br />
分类器还必须鉴别它用来分类数据包的信息的有效性。（&nbsp;参见第6节）<br />
注意，在上游数据包分片的情况下，MF分类器在检察传输层包头时，可能将来自同一数<br />
据包的后续分片错误分类。这个问题的一种可能的解决方案是保存分片状态信息；然而，由于<br />
上游分片可能乱序到达，也可能采取不同的路由，导致这种解决方案缺少一般性。解决数据包<br />
分片问题的策略不在本文档论述范围内。<br />
<br />
2.3.2	业务量简档<br />
业务量简档描述了分类器选出的业务流的时间特征。它提供了判断一个特定的数据包是否<br />
符合业务量简档的规则。例如，一份基于令牌桶的简档可能会如此描述：<br />
codepoint=X,&nbsp;use&nbsp;token-bucket&nbsp;r,b<br />
上面的简档说明，所有DS编码点值为X的数据包应该通过速率为r，桶大小为b的令牌<br />
桶测量器的检测。在本例中，不符合简档的数据包是那些当它们到达时，桶中剩下的令牌已不<br />
足的。符合及不符简档这样的两级标准可以扩展到多级。就是说，可以定义多个级别的简档一<br />
致性，而不仅是符合，不符合这样两种情况。<br />
对于符合简档和不符合简档的数据包可以采取不同的调节行为，或者不同计费方法。符合<br />
简档的数据包无须进一步的调节便可进入DS域；或者，可选的，可以改变它们的DS编码<br />
点。后一种情况发生在DS编码点第一次被设为非缺省值时[DSFIELD]，或者发生在数据包进<br />
入一个对此业务流使用不同的PHB组或编码点到PHB映射策略的DS域时。不符合简档的数<br />
据包被放入队列，直到它们符合简档（整形），被丢弃（监察），标记一个新编码点（重标<br />
记），或者直接转发但需采用另外的计费标准。不符合简档的数据包可能被映射到一个或多个<br />
更低优先级的行为集合。这里的更低优先级是指在转发性能的某些方面，低于同类数据包中符<br />
合简档的那些所属的行为集合（BA）。<br />
注意，业务量简档是TCA的可选组件，其使用依赖于服务提供和域服务提供策略的详细说<br />
明。<br />
<br />
2.3.3	业务量调节器<br />
业务量调节器包括下列组件：测量器，标记器，整形器，和丢包器。业务流首先经过分类<br />
器的选择，然后被分类器送往业务量调节器的某个组件处。测量器负责（在适当处）测量业务<br />
流是否符合业务量简档。测量器对一个特定数据包的测量结果（例如，是否符合简档）会影响<br />
对此数据包的标记，丢弃，或整形行为。<br />
当数据包在DS边界节点处离开业务量调节器时，每个数据包的DS编码点都会被赋予一<br />
个适当值。<br />
图1说明了分类器和业务量调节器的模块结构。注意，业务量调节器并不一定需要所有四<br />
个组件。例如，在没有有效的业务量简档时，数据包可能只通过分类器和标记器。<br />
&nbsp;<br />
<br />
图1：数据包分类器和业务量调节器逻辑框图<br />
<br />
2.3.3.1	测量器<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;业务量测量器负责测量由分类器根据TCA指定的业务量简档选出的数据包流的时间特征。<br />
测量器将其测量结果（也称为测量器状态）传递给其它调节功能模块，从而引发对符合或不符<br />
（在某种程度上）业务量简档的每个数据包的特殊处理。<br />
<br />
2.3.3.2	标记器<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;数据包标记器负责把数据包的DS段设置为特定的编码点值，并将标记过的数据包加入到<br />
特定的DS行为集合中去。标记器可能被配置为把所有送给它的数据包标记为唯一的编码点<br />
值，也可能被配置为根据测量器状态把数据包标记为一些编码点值中的一个值。如果标记器改<br />
变了数据包的编码点，那么我们就说标记器“重标记”了此数据包。<br />
<br />
2.3.3.3	整形器<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;整形器负责延迟一个业务流中部分或全部数据包的传输，以便使业务流符合业务量简档的<br />
要求。整形器通常有一个有限大小的缓冲区，当缓冲区没有更多的空间容纳需延迟的数据包<br />
时，数据包就会被丢弃。<br />
<br />
2.3.3.4	丢包器<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;丢包器负责丢弃一个业务流中部分或全部的数据包，以便使业务流符合业务量简档的要<br />
求。这一过程也被称做“监察”业务流。注意，丢包器可以作为一个特殊的整形器（该整形器<br />
缓冲区大小为零或仅能容纳几个数据包）而实现。<br />
<br />
2.3.4	业务量调节器和MF分类器的位置<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;业务量调节器通常位于DS入口和出口边界节点处，但也可能位于DS域，或非DS域的<br />
内部节点处。<br />
<br />
2.3.4.1	在源域内<br />
我们定义源域为发起接受特殊服务的业务流的节点所在的DS域。位于源域中的业务源和<br />
媒介节点可以实现业务量分类和调节功能。从源域中发出并穿越边界的业务流可能直接被业务<br />
源做上标记，或者在离开源域之前由媒介节点标记。这两种方式分别被称为“初始标记”和<br />
“预标记”。<br />
考虑这样一个例子：在一家公司中，CEO的数据包通常要求有较高优先级。CEO的主机<br />
会把所有其发出的数据包的DS编码点标记为一个代表“较高优先级”的值。或者，由CEO<br />
主机直接连接的第一跳路由器负责把CEO的数据包分类，并做适当的标记。象这样的高优先<br />
级业务流也可能在靠近数据源处进行调节，以便对特定数据源发出的高优先级业务的总量有所<br />
限制。<br />
在业务源处对数据包进行标记有几点优势。首先，业务源更容易获得应用程序的需求。因<br />
此，它在确定哪些数据包应该享受更好的转发待遇时，可以将应用程序的需求纳入考虑。另<br />
外，在业务流与来自其它数据源的业务流合并之前对其数据包分类，要更简单。因为此时一个<br />
节点所使用的分类规则的数量会较少。<br />
鉴于数据包的标记可能分散在多个节点处进行，源DS域有责任保证流向其服务提供者DS<br />
域的业务流集合与适当的TCA相符合。额外的分配机制，如带宽代理或RSVP，可能被用来为<br />
提供者网络中特定的DS行为集合动态分配资源[3BIT，Bernet]。源域的边界节点应该保证业<br />
务流符合TCA，必要时，要对数据包监察，整形，或重标记。<br />
&nbsp;<br />
2.3.4.2	在DS域边界<br />
业务流可能在边界连接的任何一端（上游域DS出口节点或者下游域DS入口节点）被分<br />
类，标记或者调节。域间的SLA应指明由哪个域负责将业务流映射到DS行为集合，以及调节<br />
这些集合使之符合适当的TCA。然而，DS入口节点必须假定流入的业务流不符合TCA，因此<br />
必须准备根据本地策略强制执行TCA。<br />
如果数据包在上游域中被预标记和调节，那将意味着下游域只需支持很少的分类和业务量<br />
调节规则。在这种情况下，下游DS域可能只需要根据TCA对流入的行为集合重标记或监察。<br />
然而，那些具有路径依赖或源依赖性的更复杂业务可能还需要下游DS域入口节点进行MF分<br />
类。<br />
如果DS入口节点与一个无DS功能的上游域连接，那么DS入口节点就必须能对流入的<br />
业务执行所有需要的业务调节功能。<br />
<br />
2.3.4.3	在无DS功能的域内<br />
在无DS功能的域内的业务源或媒介节点可以使用业务量调节器在业务流到达下游DS域<br />
入口节点之前预标记之。这样，本地分类和标记策略将被隐藏。<br />
<br />
2.3.4.4	在内部DS节点处<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;尽管基本体系结构假设复杂的分类和业务量调节功能位于网络的入口和出口边界节点处，<br />
在网络内部节点处配置这些功能也并未被排除。例如，在一条越洋链路上，需要有更多更严格<br />
的接入策略，这就需要在这条链路的上游节点处实现MF分类和业务量调节功能。当然，这种<br />
方法在可扩展性上有些限制。因为那将意味着在一个节点上，维护大量的分类和调节规则。<br />
<br />
2.4	每一跳行为<br />
每一跳行为（PHB）是指DS节点运用于特定DS行为集合上的，外部可观察的转发行<br />
为。“转发行为”在这里是一个广义概念。例如，当仅有一个行为集合占用一条链路时，可观<br />
察的转发行为（如，丢包率，延迟，时延抖动）就只依赖于链路的相对负载（即是说，在“行<br />
为”采用一种工作保存式的调度策略）。有意义的行为上的差别通常产生于在同一个节点，多<br />
个行为集合竞争缓冲区和带宽资源的情况下。PHB是节点给行为集合分配资源的一种方法，正<br />
是基于这种逐跳进行资源分配的机制，我们才构筑了分类业务模型。<br />
PHB的最简单例子是保证至少把一条链路带宽的X%（在一定的时间间隔内）分配给一个<br />
行为集合。这种PHB在各种业务竞争条件下都可以被公正并且很容易的测量。另一种稍复杂<br />
点的PHB要求确保最少占有X%的链路带宽，同时享受相应份额的链路剩余带宽。一般来说，<br />
PHB的可观察行为依赖于对相关行为集合或其它行为集合的业务量特性的约束。<br />
PHB通过指定其相对于其它PHB的资源（如，缓冲区，带宽）优先级来定义，也可能通<br />
过它们的可观察业务量特性（如，延迟，丢包率）来定义。这些PHB可以作为资源分配的基<br />
石，并且一致性起见，应被指定为一组（PHB组）。PHB组中的每一PHB都享有共同的限<br />
制，例如数据包安排或者缓冲区管理策略等。同组的PHB间的联系在于它们绝对的或者相对<br />
的优先级（例如，采用确定阈值或随机阈值的丢包优先级），但是这并不是必须的（例如，N<br />
等分链路资源）。一个单独定义的PHB可以看作是PHB组的特例。<br />
在节点处，PHB是通过一定的缓冲区管理和数据包安排策略实现的。PHB是通过与服务<br />
提供策略相联系的行为特征定义的，而不是根据采取了何种实现机制。一般来说，可以有很多<br />
种实现机制去实现特定的PHB组。而且，在一个节点上，可以实现多于一个的PHB组，并在<br />
域内使用。所定义的PHB组应该保证适当的组间资源分配简单易行，并且能够实现同时支持<br />
两组或更多组的集成机制。一个PHB组定义时，应指明其与已有组之间可能的冲突。这些冲<br />
突可能来自于有些操作不允许同时执行。<br />
如[DSFIELD]中描述，在节点处，根据收到数据包的DS编码点选择PHB。标准化的<br />
PHB有推荐的编码点。然而，全部编码点空间远大于分配给标准化PHB使用的编码点空间，<br />
[DSFIELD]把剩余空间提供给了局部使用。编码点到PHB的映射表可以即包括一对一，也包<br />
括N对一的映射。注意，所有的编码点都必须被映射到某一PHB：在缺少某些局部策略的情<br />
况下，那些没有映射到标准化PHB的编码点应该被统一映射到一个缺省PHB。<br />
<br />
2.5	网络资源分配<br />
在DS域节点上实现，配置，操作和管理的PHB组，应能根据域服务提供策略，有效的分<br />
配使用这些节点的资源，以及节点间链路。业务量调节器可以通过执行TCA，或者从域中节点<br />
或其它业务量调节器取得反馈，从而更有效的控制资源的使用。尽管在没有复杂的业务量调节<br />
功能时，也可以提供很多服务（例如，仅使用静态标记策略），但类似于监察，整形，和动态<br />
重标记这样的功能，可以允许向用户提供具有量化的性能参数的服务。<br />
业务量调节器及内部节点间的配置和交互需要有域高层的管理控制，可能还需要一个控制<br />
实体和适当的协议。控制模型的实现方案有很多种。<br />
这些模块之间交互的准确特征和实现细节超出了本体系结构的范围。然而，可扩展性要求<br />
域的控制不需要网络资源的微管理。最具扩展性的控制模型应在开环方式下在操作时隙内操作<br />
节点，并且由于SLA是变化的，所以只需要管理时间刻度内的管理操作。这种简单模型可能在<br />
某些情况下并不适用，此时，一些自动的但缓慢改变的操作控制（按分钟而不是秒）在平衡对<br />
网络资源的适用方面就会更具吸引力。<br />
<br />
3	每一跳行为（PHB）的规范设计指导方针<br />
对每一跳行为进行标准化的基本要求在[DSFIELD]中给出。本节详细阐述PHB（组）定<br />
义时的其它要求。主要目的是帮助建立PHB实现时的一致性。当一个PHB组标准化时，它必<br />
须满足这些要求，从而保持本体系结构的完整性。<br />
G.1：一个标准PHB&nbsp;必须从为标准映射保留的编码区域内[DSFIELD]，选择一个推荐的<br />
DS编码点。推荐的编码点由IANA指定。一个PHB提议可以从EXP/LU空间内选取一个临<br />
时编码点，以便进行域间实验。注意，不能要求检查包头除DS域以外的信息域来确定该数据<br />
包所对应的PHB。<br />
G.2：每一个新提出的PHB组规范应该包括其行为及行为目的的概述。概述中应包括此<br />
PHB组要解决的问题的描述。还应包括此PHB组涉及的基本概念。这些概念应包括，但不仅<br />
限于，队列行为，丢弃行为，和输出链路选择行为。最后，概述中应阐明此PHB组解决所描<br />
述问题的方法。<br />
G.3：PHB组规范应说明其包括的单个PHB的个数。当PHB组包括多于一个PHB时，<br />
PHB组规范就必须对这些PHB间的交互和限制做出详细说明。例如，规范必须说明如果同一<br />
微流中不同的数据包被标记为此组中不同的PHB时，数据包被重新排序的可能性是否会增<br />
大。<br />
G.4：如果PHB组的特定功能依赖于某些外部限制，比如服务提供限制，那么PHB定义<br />
中，就必须说明当这些限制被违反时，此PHB所产生的行为。更进一步，如果这些限制被违<br />
反时，又需要采取类似包丢弃或重标记的行为，那么这些行为应被特别规定。<br />
G.5：&nbsp;一个PHB组可能被指明为仅在一个域内局部使用。其作用是在域内提供面向特定<br />
域的功能或服务。在这种情况下，PHB规范有助于向服务提供者提供一份关于此PHB组的一<br />
致性定义。然而，任何只定义为局部使用的PHB组，不能进行标准化。但是，它们可以作为<br />
知识性RFC文档发表。相反的，作为通用的PHB组，就必须经过严格的标准化过程。所以，<br />
所有的PHB组提议都必须明确指明其用途是通用的还是局部的。<br />
PHB组可能被设计来提供主机到主机，WAN边界到WAN边界，和/或域边界到域边界服<br />
务。出于一致性考虑，在PHB定义中使用“端到端（host&nbsp;to&nbsp;host）”应被理解为“主机到<br />
主机”。<br />
由于实验或操作要求，在域内还可以定义和配置其它PHB组。这些局部有效的PHB组并<br />
不需要公开定义，但是它们应使用EXP/LU空间的编码点（[DSFIELD]中定义）。<br />
G.6：被标记为PHB组中某个PHB的数据包，有可能在域中或域边界处，重标记为同<br />
PHB组中的另一个PHB。有三种典型情况需要这种转换：<br />
a.	与此PHB组对应的编码点，也被用来携带网络状态信息。<br />
b.	需要提升或降低数据包的PHB的情况。（如果组内的PHB可进行某种排序）<br />
c.	域边界处缺少SLA。这种情况下，数据包通过边界链路时的编码点/PHB根据上游域<br />
的局部策略决定。<br />
PHB规范应该清楚的说明数据包被重标记（例如，提升或降低）为本组中另一个PHB的<br />
情况。如果某些情况下不能改变数据包的PHB，那么规范中必须清楚说明此时改变PHB的后<br />
果。改变数据包的PHB（无论改为同组的，还是不同组），可能引起的后果之一是，对微流中<br />
数据包重新排序的可能性增加。PHB可能携带某些主机到主机，WAN边界到WAN边界，和<br />
/或域边界到域边界的语义，这些语义很难在数据包重标记为组内（或其它组）另一个PHB时<br />
保存下来。<br />
对于某些PHB组，可以通过重标记数据包为组内其它PHB来反映节点状态的变化。如果<br />
一个PHB组被设计来反映网络状态，那么在相应的PHB规范中，就必须详述组中各个PHB<br />
与其反映的网络状态之间的联系。此外，如果这些PHB对节点转发行为有所限制，那么这些<br />
限制可以被表达为节点应当，或必须执行的行为。<br />
G.7：PHB组规范中应包括一节说明隧道技术在本组的应用。此节应说明当数据包被封装<br />
入隧道后，如何根据其内层包头的DS域，来确定外层包头DS域。还应说明，在隧道出口<br />
处，内层包头应做如何的改变。（参见&nbsp;6.2节）。<br />
G.8：定义PHB组是一个增量式的过程。当定义新的PHB组时，应说明它如何与已定义<br />
的PHB组协调。每一个新建立的PHB组，其作用的范围可能是全新的，也可能是已有PHB<br />
组的扩展。如果一个PHB组完全独立于某些或全部已有PHB组规范，那么在其规范中应有一<br />
节详述它如何与已经标准化的PHB组共存。例如，这一节中应该说明当微流中的数据包被标<br />
记为与两个不同PHB组都相关的编码点时，它们被重排序的可能性有多大。如果在同一节点<br />
中同时操作两个（或更多）PHB组不可能或是有害的，这种情况必须在此节中说明。如果节点<br />
在处理同时收到的被标记为两个（或更多）PHB组的多个数据包时，需采取某些特殊动作，那<br />
么这些特殊动作也应在此节说明。<br />
定义PHB组时，应注意避免循环定义。<br />
如果提议中的PHB组是已有的某个PHB组的扩展，那么规范中应包括一节详述此PHB<br />
组如何与被扩展PHB组交互。更进一步，如果此PHB组改变或更狭义的定义了某些已有行<br />
为，这些情况也应在规范中说明。<br />
G.9：每个PHB规范都应包括一节阐述实现此PHB组的最小一致性需求。这一节主要目<br />
的是提供此PHB组实现时容许变化的行为的变动范围。这一节可以采用规则，表格，伪代<br />
码，或测试的形式叙述。<br />
G.10：PHB规范应包括一节详述其行为的安全性。此节应包括对在隧道出口改变内层包<br />
头的编码点，以及这种改变对数据包转发行为的影响的讨论。<br />
另外，此节还应讨论提议的PHB组如何被用在拒绝服务攻击，减少服务协议攻击，和违<br />
反服务协议攻击。最后，此节应讨论检测这些攻击的可能方案。<br />
G.11：PHB规范中应包括一节详述配置和管理问题。这些问题可能影响PHB的操作和使<br />
用此PHB的候选服务。<br />
G.12：强烈建议每个PHB规范都提供一个附录，详述其对现有服务和潜在服务提供的服<br />
务行为特征。这些服务包括但不限于用户特定的，设备特定的，域特定的或端到端的服务。强<br />
烈建议附录中包括一节描述用户，设备，和/或域如何验证这些服务。<br />
G.13：建议每个PHB规范提供一个附录。此附录面向域内部使用，提供本域向不支持此<br />
PHB组的对等域转发数据包时选择何种PHB的指导。<br />
G.14：建议每个PHB规范提供附录说明提议的PHB组对已有的高层协议的影响。在某<br />
些情况下，PHB允许对高层协议做可能的改变，这些改变可能增加，也可能减少提议的PHB<br />
组的使用。<br />
G.15：建议每个PHB规范提供附录，对使用共享媒体或交换的链路层提供从PHB到链<br />
路层QoS机制映射的建议。在PHB和链路层QoS机制之间进行适当的映射涉及许多因素，<br />
这个问题已超出本文档的论述范围；然而，在PHB规范中应设法给出一些指导。<br />
<br />
4	与非分类业务兼容节点的互操作<br />
我们把非分类业务兼容节点（non-DS-compliant&nbsp;node）定义为任何不会根据<br />
[DSFIELD]描述译解DS域，和/或没有实现部分或全部标准化PHB组（或只在特定DS域使<br />
用的PHB组）的节点。这可能域节点的能力或配置有关。我们把遗留节点（legacy&nbsp;node）定<br />
义为非分类业务兼容节点的特殊情况，这些节点实现了IPv4优先级和[RFC791，RFC1812]<br />
定义的转发策略，但在其它方面是非分类业务兼容的。在[DSFIELD]中定义的等级选择编码点<br />
（Class&nbsp;Selector&nbsp;Codepoints）被特别考虑，保持与IPv4中TOS字节定义的优先值兼容，<br />
同时，在[DSFIELD]中定义的等级选择PHB也与[RFC791，RFC1812]定义的优先转发行为<br />
相兼容。遗留节点和分类业务兼容节点之间的关键区别在于，遗留节点可能，也可能不译解<br />
[RFC1349]定义的TOS字节的3-6比特（“DTRC”比特）；实际上它不会译解[DSFIELD]<br />
指定的那些比特。我们假设使用[RFC1349]中定义的TOS标记是被反对的。注意，那些不是<br />
遗留节点的非分类业务兼容节点，在转发带有非零DS编码点的数据包时，其转发行为是不可<br />
预测的。<br />
分类业务依赖于基于在节点上实现每一跳行为的资源分配机制。如果业务流穿过非分类业<br />
务兼容节点或无分类业务能力域，那么服务的质量或统计确保水平很可能会下降。<br />
我们讨论两种情况。第一种情况关于在DS域中使用非分类业务兼容节点。注意，PHB转<br />
发主要是在对稀有节点和链路资源进行有控制的分配时有用。在高速，轻载荷链路上，最坏包<br />
延迟，抖动，和丢失都是可以忽略的，并且，在这样的链路上游使用非分类业务兼容节点不会<br />
造成服务降级。在多数实际情况下，一个节点缺少PHB转发支持会导致无法对通过此节点的<br />
数据流提供低时延，低丢包率服务，或预定服务带宽。然而，如果在DS域中能够仅使用<br />
[DSFIELD]定义的等级服务编码点，并且在遗留节点上的优先级实现方案与路径上的其它节点<br />
的转发行为兼容，那么在无法兼容分类业务的节点处使用遗留节点就会是一个较好的替代方<br />
案。注意，由于遗留节点可能，也可能不会根据[RFC1394]译解第3-5比特，从而导致不可预<br />
测的转发行为，所以，必须限制只使用等级选择编码点。<br />
第二种情况关于穿越无DS能力域（non-DS-capable&nbsp;domain）的服务行为。出于讨论<br />
目的，我们假定无DS能力域不会在域边界节点处进行业务量调节；因此，即便在域内存在遗<br />
留节点或DS兼容节点的情况下，由于在边界处缺少业务量管理，也会限制本域，使之不能稳<br />
定提供某些服务。DS域和无DS能力域之间可以就如何在进入无DS能力域之前在DS域出<br />
口处标记数据包达成协议。这个协议可通过业务量采样而不是严格的业务量调节确保实施。&nbsp;如<br />
果已知无DS能力域中包含遗留节点，那么上游DS域可以选择将分类业务流重标记为一个或<br />
多个等级选择编码点。如果对下游域的业务量管理能力一无所知，而且缺少域间协议，那么<br />
DS出口节点可以选择将DS编码点重标记为零，并假设无DS能力域会平等对待所有业务<br />
流，遵从尽力而为原则转发。<br />
在无DS能力域与DS域对等的情况下，来自无DS能力域的业务流应在DS域入口节点<br />
处根据适当的SLA或其它协议进行调节。<br />
<br />
<br />
5	关于组播<br />
对组播业务使用分类业务机制引入很多问题。首先，在某个DS域入口节点进入的组播数<br />
据包可能会被复制，然后通过多条不同的路径穿越此DS域。这种情况下，组播业务就会比单<br />
播业务消耗更多的网络资源。由于组播成员是随时变化的，因此很难预测从上游网络来的某一<br />
组播业务会消耗本域的多少网络资源。这种不确定性的后果之一就是很难向组播业务提供者提<br />
供定量服务保证。此外，有必要为单播业务保留编码点和PHB，以便提供不受组播干扰的资<br />
源。<br />
第二个问题是到达DS入口点的组播数据包如何选择DS编码点。组播数据包可能在多个<br />
出口节点流出DS域，每个出口节点都对应一个下游DS域，和相应的SLA。应注意组播数据<br />
包的编码点不能违反任何一个SLA。当为从某一入口节点进入的请求分类服务的组播业务流建<br />
立分类器和业务量调节器状态时，应该考虑到相应的下游DS域标识和SLA细节（使之服从路<br />
由策略及路由体系的稳定性）。这样相应的下游DS域SLA可以部分的在上游DS域入口点处<br />
得以履行，从而减轻上游域入口点的分类和业务量调节负担。当然，在组播业务中采取这样的<br />
方法很困难，因为组播成员是动态变化的。结果是单播业务的服务保证会受到影响。解决此问<br />
题的一种方案是，为组播业务创建单独的SLA，并且或者让组播业务采用特殊的一系列编码<br />
点，或者在DS出口点实现必要的分类和业务量调节机制，根据下游域SLA将单播业务优先分<br />
离，提供服务。<br />
<br />
6	安全和隧道问题<br />
这一节主要讨论由于引入分类业务而引起的安全问题，主要是拒绝服务攻击隐患，和通过<br />
未授权业务窃取服务隐患（参见6.1）。另外，在IPsec条件下分类业务的操作和与IPsec交<br />
互问题也有讨论（参见6.2节）。审查需求也在6.3&nbsp;节有所讨论。本节讨论的问题包括由<br />
IPsec和非IPsec隧道引入的。<br />
<br />
6.1	窃取和拒绝服务<br />
分类业务的主要目的是在统一的网络体系结构上，向业务流提供不同级别服务。很多资源<br />
管理技术被用来完成这一目标，最终的结果是有些数据包会受到不同的（例如，更好的）服<br />
务。把网络业务映射到特定的行为集合从而取得不同的（或好或坏）服务，主要依靠设定DS<br />
域。随之而来的问题就是，可以通过把DS域修改为代表更高优先级的编码点，或者直接注入<br />
DS域置为这些编码点的数据包而获得更好的服务。在极端情况下，如果修改或者注入的数据<br />
包耗尽了网络资源，这种窃取服务行为就演变成拒绝服务攻击。解决方案包括综合使用在DS<br />
边界节点进行业务量调节和增强DS域内网络结构的安全性和完整性。<br />
如第2节描述，DS入口节点必须调节所有进入DS域的业务流，以确保它们带有可接受<br />
的DS编码点。就是说编码点必须符合适用的TCA和域服务提供策略。因此，入口节点是防止<br />
基于修改DS编码点（例如，改为此业务流无权的DS编码点）的窃取和拒绝服务攻击的主要<br />
战线。因为，任何这样的攻击都会违反TCA和/或服务提供策略。一种重要类型的入口节点是<br />
在DS域中可以发起业务的节点。必须保证任何发起的业务都带有可接受的DS编码点。<br />
域服务提供策略和TCA都可能要求入口节点改变某些流入数据包的DS编码点（例如，<br />
入口路由器可能根据适当的SLA设置用户业务流的DS编码点）。入口节点必须调节所有的业<br />
务流以保证DS编码点是可接受的；带有不可接受编码点的数据包必须或者被丢弃，或者将其<br />
DS编码点在转发前改为可接受值。例如，入口节点可能会将从与之无增强业务协议的域收到<br />
的业务流DS编码点设置为缺省PHB编码点[DSFIELD]。某些DS编码点的适用可能需要特<br />
别的业务授权（例如，那些对应于增强业务的编码点），并且这类授权可以采用技术方法<br />
（如，IPsec）和/或非技术方法（如，固定连接到唯一客户的入口链路）。<br />
域间协议可以使上游域部分或全部保证业务流带有下游域可接受的DS编码点，从而降低<br />
入口节点进行业务量调节的要求。这种情况下，入口节点仍可以进行业务量调节检查，以避免<br />
对上游域的依赖（例如，这类检查可以防止跨越域边界传播的窃取服务攻击）。如果由于上游<br />
域未能履行其责任，导致业务流未能通过入口节点检查，那么这一审查事件必须被记录；记录<br />
项包括接收到数据包的日期/时间，源和目的IP地址，和导致未通过此检查的DS编码点值。<br />
实际中，需要在这类检查的好处和它们对系统性能的影响之间做出权衡，确定到底哪些情况需<br />
要检查。<br />
DS域内部节点依赖于DS段向要求分类业务功能的业务流提供服务。节点必须依靠正确<br />
的DS域操作来防止带有不可接受DS编码点的业务流到达。健壮性考虑要求带有不可接受<br />
DS编码点数据包的到达不会引起网络节点瘫痪。内部节点没有义务监督服务提供策略SLA的<br />
执行情况，也不需要对DS编码点进行检查。内部节点可以对DS编码点执行某些业务量调节<br />
检查（例如，检查出在某条特定链路上从不会使用的编码点），从而提高节点安全性和健壮性<br />
（例如，可以防止基于DS编码点修改的窃取服务攻击）。任何检查出的错误都是审查事件，<br />
而应被记录。记录项包括接收到数据包的日期/时间，源和目的IP地址，和导致未通过此检查<br />
的DS编码点值。实际中，需要在这类检查的好处和它们对系统性能的影响之间做出权衡，确<br />
定内部节点处到底需做哪些检查。<br />
如果一条链路不能充分保证其安全性，即是说，不能防止DS编码点修改或者注入不合法<br />
业务流，那么就应该被当作边界连接对待（即，任何从此链路到达的业务流都象从入口节点处<br />
进入DS域的业务流那样进行各种检查）。局部安全策略提供关于“充分安全”的定义。“充<br />
分安全”定义中应给出一个DS编码点修改和/或业务流注入的危险和后果，与对链路的采取额<br />
外安全措施的平衡点。链路安全性可以通过物理接入控制和/或软件方法，如确保数据包完整<br />
性的隧道技术，得到提高。<br />
<br />
6.2	IPsec和隧道交互<br />
在IPsec协议中，如[ESP，AH]描述，不含有对IP头DS段任何形式的加密（在隧道<br />
中，外层IP头的DS段未被加密）。因此，网络节点对DS段的修改不会影响IPsec端到端的<br />
安全性，因为这种修改不会引起IPsec完整性检查失败。其结果是，IPsec不能提供任何措施<br />
防止对DS段的修改（如，中间人攻击man-in-the-middle&nbsp;attach），因为攻击者的修改不<br />
会破坏IPsec的端到端完整性。在有些环境，这种修改DS段而不影响IPsec完整性检查的能<br />
力，可以组成一个隐蔽通道；如果有必要消除这样的通道或减少其带宽，可以把DS域配置<br />
为，可以在业务流离开更高安全性域的DS出口节点处进行所需的处理（如，将敏感业务流的<br />
所有DS段置为同一个值）。<br />
IPsec的隧道模式为封装的IP头DS段提供了安全性支持。隧道模式下的IPsec包含有两<br />
个IP头：由隧道入口节点提供的外层包头和由数据包源节点提供的被封装的内层包头。当一条<br />
IPsec隧道（部分或全部的）经过分类业务网络时，中间的网络节点会对外层包头中的DS段<br />
进行操作。在隧道出口节点处，IPsec会去掉外层包头，并（如果需要）使用内层包头转发数<br />
据包。如果内层IP头没有被隧道出口节点所在DS域的某个DS入口节点处理过，那么隧道出<br />
口节点就作为离开隧道的业务流进入DS域的入口节点，也因此，此节点必须履行相应的业务<br />
量调节策略（参见6.1节）。如果IPsec对所封装数据包有足够强壮的密码完整性检查（这里<br />
的“足够”取决于局部安全策略），那么隧道出口节点就可以安全的假设内层包头的DS段值<br />
与在隧道入口时相同。这就允许与隧道入口节点位于同一DS域的隧道出口节点，可以象对待<br />
从同一DS域其它节点来的数据包一样（即是说，省略DS入口节点业务量调节处理）处理从<br />
隧道流出的数据包，并保证安全性。这样做的一个重要后果就是，局部于DS域的其它不安全<br />
链路可以使用足够强壮的IPsec隧道使其安全。<br />
此分析和隐含适用于任何进行完整性检查的隧道协议，只是对内层包头DS段的确保水平<br />
依赖于隧道协议进行的完整性检查力度。在隧道可能穿越当前DS域之外的节点时，如果缺少<br />
对这类隧道足够的信任，封装的数据包就必须象对待从域外到达DS入口节点的数据包同样处<br />
理。<br />
当前IPsec协议不允许在隧道出口节点处除IPsec封装时改变内层包头的DS段。这保证<br />
了不能利用修改DS段的方法穿越IPsec隧道终点实施窃取服务或拒绝服务攻击，因为任何这<br />
类修改都会在隧道终点处丢弃。本文档不对IPsec做任何修改。<br />
如果IPsec的未来版本允许在隧道出口节点处根据外层包头DS段值修改内层包头DS段<br />
值（例如，复制外层DS段的部分或全部内容到内层DS段），那么就还需对由此而来的安全<br />
性问题额外考虑。当一条隧道完全处于一个DS域中，并且这条链路绝对安全，外层DS段不<br />
会被修改，在修改内层DS段时的唯一限制来自于域服务提供策略。另外，进行这种修改的隧<br />
道出口节点对流出隧道的业务流来说，应是DS入口节点，必须实施必要的业务量调节功能，<br />
包括防止窃取服务和拒绝服务攻击（参见6.1节）。如果隧道不是在其出口节点处进入DS<br />
域，那么隧道出口节点就依靠上游的DS入口节点确保外层DS段值是可接受的。即使在这种<br />
情况下，也有某些检查是必须由隧道出口节点实施的（例如，加密隧道内层和外层DS段值一<br />
致性检查）。任何检查出的错误都必须留有审查记录，记录内容包括数据包到达的日期/时<br />
间，源和目的IP地址，和所携带的不可接收DS编码点。<br />
从体系结构角度，至少可以有两种不同的方式看待IPsec隧道。如果隧道被看作逻辑上只<br />
有一跳的“虚链路”，那么隧道中间节点转发隧道中数据流的行为，对隧道终点来说就应该是<br />
不可见的，并且在解除封装过程中也不应该修改DS段值。相反的，如果隧道被看作是多跳<br />
的，那么在隧道解除封装的过程中修改DS段值，就是可以的了。后一种情况的具体例子如<br />
下。隧道终止于DS域内部节点，而域管理者并不想在此节点安装业务量调节功能（例如，为<br />
了简化业务量管理）。一种解决方案是，根据外层IP包头的DS编码点（根据此值在DS入口<br />
节点处进行业务量调节）设置内层IP包头DS编码点。这样就有效将业务量调节功能从IPsec<br />
隧道出口节点转移到了适当的上游DS入口节点（DS入口节点必须已经对未解除封装的业务<br />
流进行了业务量调节）。]<br />
<br />
6.3	审查<br />
并不是所有支持分类业务的系统都要实现审查功能。然而，如果分类业务支持融入了一个<br />
提供审查功能的系统中，那么分类业务实现也必须支持审查。如果支持审查功能，那么就必须<br />
允许系统管理者整体性的开启或禁止分类业务审查功能，并且允许部分的开启或禁止这类审<br />
查。<br />
大多数情况下，审查功能的粒度是局部问题。然而，本文档中定义了一些审查事件，以及<br />
每一事件记录应包括的最小信息集。额外信息（如，引起此审查事件的数据包本身）也可被包<br />
括在记录信息中。并未在本文档中提到的其他事件，也可以导致一条审查记录。检测到审查事<br />
件后，并不要求接收者向发送者传送任何的消息，因为回传任何消息都有可能导致包括拒绝服<br />
务攻击在内的危险。<br />
<br />
7	感谢<br />
本文档得益于早期由Steven&nbsp;Blake,&nbsp;&nbsp;&nbsp;David&nbsp;Clark,&nbsp;Ed&nbsp;Ellesson,&nbsp;Paul&nbsp;Ferguson,&nbsp;<br />
Juha&nbsp;Heinanen,&nbsp;Van&nbsp;Jacobson,&nbsp;&nbsp;&nbsp;Kalevi&nbsp;Kilkki,&nbsp;Kathleen&nbsp;Nichols,&nbsp;Walter&nbsp;Weiss,&nbsp;John&nbsp;<br />
Wroclawski,&nbsp;和Lixia&nbsp;Zhang撰写的初稿。<br />
很多人为本文档提供了有帮助的建议和意见，作者在此向他们表示感谢：Kathleen&nbsp;Nichols,&nbsp;<br />
Brian&nbsp;&nbsp;&nbsp;&nbsp;Carpenter,&nbsp;Konstantinos&nbsp;Dovrolis,&nbsp;Shivkumar&nbsp;Kalyana,&nbsp;Wu-chang&nbsp;Feng,&nbsp;&nbsp;&nbsp;Marty&nbsp;Borden,&nbsp;<br />
Yoram&nbsp;Bernet,&nbsp;Ronald&nbsp;Bonica,&nbsp;James&nbsp;Binder,&nbsp;Borje&nbsp;&nbsp;Ohlman,&nbsp;Alessio&nbsp;Casati,&nbsp;Scott&nbsp;Brim,&nbsp;Curtis&nbsp;<br />
Villamizar,&nbsp;Hamid&nbsp;Ould-&nbsp;&nbsp;&nbsp;Brahi,&nbsp;Andrew&nbsp;Smith,&nbsp;John&nbsp;Renwick,&nbsp;Werner&nbsp;Almesberger,&nbsp;Alan&nbsp;O'Neill,&nbsp;&nbsp;<br />
James&nbsp;Fu,&nbsp;和&nbsp;Bob&nbsp;Braden.<br />
<br />
8	参考文献<br />
&nbsp;&nbsp;&nbsp;[802.1p]&nbsp;&nbsp;&nbsp;&nbsp;ISO/IEC&nbsp;Final&nbsp;CD&nbsp;15802-3&nbsp;Information&nbsp;technology&nbsp;-&nbsp;<br />
Telecommunications&nbsp;and&nbsp;information&nbsp;exchange&nbsp;between&nbsp;systems&nbsp;-&nbsp;Local&nbsp;and&nbsp;<br />
metropolitan&nbsp;area&nbsp;networks&nbsp;-&nbsp;Common&nbsp;specifications&nbsp;-&nbsp;Part&nbsp;3:&nbsp;Media&nbsp;Access&nbsp;Control&nbsp;<br />
(MAC)&nbsp;bridges,&nbsp;(current&nbsp;draft&nbsp;available&nbsp;as&nbsp;IEEE&nbsp;P802.1D/D15).<br />
&nbsp;&nbsp;&nbsp;[AH]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Kent,&nbsp;S.&nbsp;and&nbsp;R.&nbsp;Atkinson,&nbsp;"IP&nbsp;Authentication&nbsp;Header",&nbsp;RFC&nbsp;2402,&nbsp;<br />
November&nbsp;1998.<br />
&nbsp;&nbsp;&nbsp;[ATM]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ATM&nbsp;Traffic&nbsp;Management&nbsp;Specification&nbsp;Version&nbsp;4.0&nbsp;&lt;af-tm-0056.000&gt;,&nbsp;<br />
ATM&nbsp;Forum,&nbsp;April&nbsp;1996.<br />
&nbsp;&nbsp;&nbsp;[Bernet]&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Bernet,&nbsp;R.&nbsp;Yavatkar,&nbsp;P.&nbsp;Ford,&nbsp;F.&nbsp;Baker,&nbsp;L.&nbsp;Zhang,&nbsp;K.Nichols,&nbsp;and&nbsp;M.&nbsp;<br />
Speer,&nbsp;"A&nbsp;Framework&nbsp;for&nbsp;Use&nbsp;of&nbsp;RSVP&nbsp;with&nbsp;Diff-serv&nbsp;Networks",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
&nbsp;&nbsp;&nbsp;[DSFIELD]&nbsp;&nbsp;&nbsp;Nichols,&nbsp;K.,&nbsp;Blake,&nbsp;S.,&nbsp;Baker,&nbsp;F.&nbsp;and&nbsp;D.&nbsp;Black,&nbsp;"Definition&nbsp;of&nbsp;the&nbsp;<br />
Differentiated&nbsp;Services&nbsp;Field&nbsp;(DS&nbsp;Field)&nbsp;in&nbsp;the&nbsp;IPv4&nbsp;and&nbsp;IPv6&nbsp;Headers",&nbsp;RFC&nbsp;2474,&nbsp;<br />
December，1998.<br />
&nbsp;&nbsp;&nbsp;[EXPLICIT]&nbsp;&nbsp;D.&nbsp;Clark&nbsp;and&nbsp;W.&nbsp;Fang,&nbsp;"Explicit&nbsp;Allocation&nbsp;of&nbsp;Best&nbsp;Effort&nbsp;Packet&nbsp;<br />
Delivery&nbsp;Service",&nbsp;IEEE/ACM&nbsp;Trans.&nbsp;on&nbsp;Networking,&nbsp;vol.&nbsp;6,&nbsp;no.&nbsp;4,&nbsp;August&nbsp;1998,&nbsp;pp.&nbsp;<br />
362-373.<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&nbsp;Payload&nbsp;(ESP)",&nbsp;<br />
RFC&nbsp;2406,&nbsp;November&nbsp;1998.<br />
&nbsp;&nbsp;&nbsp;[FRELAY]&nbsp;&nbsp;&nbsp;&nbsp;ANSI&nbsp;T1S1,&nbsp;"DSSI&nbsp;Core&nbsp;Aspects&nbsp;of&nbsp;Frame&nbsp;Rely",&nbsp;March&nbsp;1990.<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,&nbsp;September&nbsp;<br />
1981.<br />
&nbsp;&nbsp;&nbsp;[RFC1349]&nbsp;&nbsp;&nbsp;Almquist,&nbsp;P.,&nbsp;"Type&nbsp;of&nbsp;Service&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Protocol&nbsp;Suite",&nbsp;RFC&nbsp;<br />
1349,&nbsp;July&nbsp;1992.<br />
&nbsp;&nbsp;&nbsp;[RFC1633]&nbsp;&nbsp;&nbsp;Braden,&nbsp;R.,&nbsp;Clark,&nbsp;D.&nbsp;and&nbsp;S.&nbsp;Shenker,&nbsp;"Integrated&nbsp;Services&nbsp;in&nbsp;the&nbsp;<br />
Internet&nbsp;Architecture:&nbsp;An&nbsp;Overview",&nbsp;RFC&nbsp;1633,&nbsp;July&nbsp;1994.<br />
&nbsp;&nbsp;&nbsp;[RFC1812]&nbsp;&nbsp;&nbsp;Baker,&nbsp;F.,&nbsp;Editor,&nbsp;"Requirements&nbsp;for&nbsp;IP&nbsp;Version&nbsp;4&nbsp;Routers",&nbsp;RFC&nbsp;1812,&nbsp;<br />
June&nbsp;1995.<br />
&nbsp;&nbsp;&nbsp;[RSVP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Braden,&nbsp;B.,&nbsp;Zhang,&nbsp;L.,&nbsp;Berson&nbsp;S.,&nbsp;Herzog,&nbsp;S.&nbsp;and&nbsp;S.&nbsp;Jamin,&nbsp;"Resource&nbsp;<br />
ReSerVation&nbsp;Protocol&nbsp;(RSVP)&nbsp;--&nbsp;Version&nbsp;1&nbsp;Functional&nbsp;Specification",&nbsp;RFC&nbsp;2205,&nbsp;<br />
September&nbsp;1997.<br />
&nbsp;&nbsp;&nbsp;[2BIT]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;K.&nbsp;Nichols,&nbsp;V.&nbsp;Jacobson,&nbsp;and&nbsp;L.&nbsp;Zhang,&nbsp;"A&nbsp;Two-bit&nbsp;Differentiated&nbsp;Services&nbsp;<br />
Architecture&nbsp;for&nbsp;the&nbsp;Internet",&nbsp;&nbsp;ftp://ftp.ee.lbl.gov/papers/dsarch.pdf,&nbsp;November&nbsp;<br />
1997.<br />
&nbsp;&nbsp;&nbsp;[TR]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISO/IEC&nbsp;8802-5&nbsp;Information&nbsp;technology&nbsp;-&nbsp;Telecommunications&nbsp;and&nbsp;<br />
information&nbsp;exchange&nbsp;between&nbsp;systems&nbsp;-&nbsp;Local&nbsp;and&nbsp;metropolitan&nbsp;area&nbsp;networks&nbsp;-&nbsp;<br />
Common&nbsp;specifications&nbsp;-&nbsp;Part&nbsp;5:&nbsp;Token&nbsp;Ring&nbsp;Access&nbsp;Method&nbsp;and&nbsp;Physical&nbsp;Layer&nbsp;<br />
Specifications,&nbsp;(also&nbsp;ANSI/IEEE&nbsp;Std&nbsp;802.5-&nbsp;1995),&nbsp;1995.<br />
<br />
9	作者联系地址<br />
&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 />
&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 />
&nbsp;&nbsp;&nbsp;Mark&nbsp;A.&nbsp;Carlson<br />
&nbsp;&nbsp;&nbsp;Sun&nbsp;Microsystems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;2990&nbsp;Center&nbsp;Green&nbsp;Court&nbsp;South<br />
&nbsp;&nbsp;&nbsp;Boulder,&nbsp;CO&nbsp;&nbsp;80301<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;+1-303-448-0048&nbsp;x115<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;mark.carlson@sun.com<br />
<br />
&nbsp;&nbsp;&nbsp;Elwyn&nbsp;Davies<br />
&nbsp;&nbsp;&nbsp;Nortel&nbsp;UK<br />
&nbsp;&nbsp;&nbsp;London&nbsp;Road<br />
&nbsp;&nbsp;&nbsp;Harlow,&nbsp;Essex&nbsp;&nbsp;CM17&nbsp;9NA,&nbsp;UK<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;+44-1279-405498<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;elwynd@nortel.co.uk<br />
<br />
&nbsp;&nbsp;&nbsp;Zheng&nbsp;Wang<br />
&nbsp;&nbsp;&nbsp;Bell&nbsp;Labs&nbsp;Lucent&nbsp;Technologies<br />
&nbsp;&nbsp;&nbsp;101&nbsp;Crawfords&nbsp;Corner&nbsp;Road<br />
&nbsp;&nbsp;&nbsp;Holmdel,&nbsp;NJ&nbsp;&nbsp;07733<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;zhwang@bell-labs.com<br />
<br />
&nbsp;&nbsp;&nbsp;Walter&nbsp;Weiss<br />
&nbsp;&nbsp;&nbsp;Lucent&nbsp;Technologies<br />
&nbsp;&nbsp;&nbsp;300&nbsp;Baker&nbsp;Avenue,&nbsp;Suite&nbsp;100<br />
&nbsp;&nbsp;&nbsp;Concord,&nbsp;MA&nbsp;&nbsp;01742-2168<br />
<br />
EMail:&nbsp;wweiss@lucent.com<br />
<br />
10	&nbsp;完整版权声明<br />
Copyright&nbsp;?&nbsp;&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1998)，版权所有。<br />
本文件及其译文可以复制并对外提供。可以部分或全部编著、复制、出版、分发与其有关<br />
的评议、解释和有助于实施的派生著作，没有任何限制，但要求在复制文件和派生著作中包括<br />
上述版权警告及本节版权声明内容。但是，本文件的内容不允许做任何形式的修改，诸如删除<br />
版权警告或者关于Internet&nbsp;Society或者其他Internet组织的介绍，除非为了开发Internet<br />
标准或翻译成英语以外的其他语言的需要，即使在这种情况下，也仍然必须遵循Internet标准<br />
过程中确定的版权程序。<br />
上述许可是永久性的，不会由The&nbsp;Internet&nbsp;Society，它的继承者或转让者予以废除。<br />
本文件及其提供的信息以“现状”为基础，The&nbsp;Internet&nbsp;Society与IETF(因特网工程任<br />
务小组)否认所有的保证明示或暗示，包含但并不限于任何保证。所含信息的使用将不会侵犯具<br />
有特殊目的的商用性或者适用性的任何权利或隐含的保证。<br />
<br />
RFC2475——An&nbsp;Architecture&nbsp;for&nbsp;Differentiated&nbsp;Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;分类业务的体系结构&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
<br />
<br />
1<br />
<br />
RFC中文文当翻译计划<br />
RFC2475——An&nbsp;Architecture&nbsp;for&nbsp;Differentiated&nbsp;Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;分类业务的体系结构&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
RFC中文文档翻译计划<br />