组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)<br />
E-mail：ouyang@china-pub.com<br />
译者：王保利（wwwbl&nbsp;wwwbl@sina.com）<br />
译文发布时间：2002-6-1<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;J.&nbsp;Heinanen<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2597&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Telia&nbsp;Finland<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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;&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;&nbsp;&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Wroclawski<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MIT&nbsp;LCS<br />
June&nbsp;1999<br />
<br />
保证转发每一跳行为组<br />
（Assured&nbsp;Forwarding&nbsp;PHB&nbsp;Group）<br />
本文档的状况<br />
本篇文档详细说明为互联网社团制定的互联网标准跟踪协议，希望得到讨论和改进建议。如果想了解这个协议标准化的声明和状况，请参考最新版本的“互联网官方协议标准”(STD1)。本文档的分发不受限制。	<br />
版权声明<br />
版权属于(C)the&nbsp;Internet&nbsp;Society(1999)。版权所有。<br />
摘要<br />
本文档定义了一个常规的使用区分服务(DS)(参见[Blake])的称之为保证转发(AF)的每一跳行为（PHB）组。保证转发PHB组为IP包的转发提供4个独立的前向保证转发类。每一个保证转发类中，一个IP包可以被分配到3个不同的丢包优先级。如果同一微流的IP包属于一个保证转发类，区分服务节点不对它们重新排序。<br />
1．目的和综述<br />
在互联网上存在提供保证转发的需求。在一个典型应用中，某公司使用互联网连接地理位置上分布的各个站点，当来自每个站点的流量聚集后不超过预定的信息速率特征描述(profile)，希望可以保证在这个内联网内IP包可以以一个高优先级被转发。超过的流量和在特征描述范围内的流量不应该得到同样的发送概率，在这个条件下，一个站点流量可以超过预定特征描述。属于同一个微流(定义见[Nichols]）的包不应该在网络中被重新排序，这一点也很重要，不论这些包是否在特征描述内。<br />
保证转发PHB组为提供方区分服务域提供一种方法，使它可以为来自客户区分服务域的IP包提供不同等级的转发保证。定义了4个保证转发类，每一个区分服务节点为每一个保证转发类分配一定数量的转发资源（缓冲区空间和带宽）。希望使用保证转发PHB组所提供服务的IP包，根据客户预定的服务，被区分服务域的提供者或者客户分配到一个或者多个保证转发类中。关于使用方法和性能的进一步的背景知识参阅[Clark]。<br />
在每一个保证转发类中，IP包被标记（由区分服务域的提供方或者客户）为三种可能的丢弃优先值。在发生拥塞的时候，一个包的丢弃优先级决定这个包在这个保证转发类中的相对重要性。发生拥塞的区分服务节点通过丢弃有较高丢弃优先级的包，尽量保护具有低的丢弃优先级的包不被丢掉，<br />
在一个区分服务节点，一个包的转发保证级别依赖于（1）分配给这个包所属的保证转发类的转发资源的多少。(2)这个保证转发类当前的负载，以及万一这个类发生拥塞。（3）包的丢弃优先级。<br />
例如,如果在提供方的区分服务入口节点处的流量控制动作可以保证区分服务节点的保证转发类在包的丢弃优先级最低时处于适度负载，在包具有两个最低的丢弃优先级时也没有超负载，那么这个保证转发类可以提供一个在预定特征描述（即：标记为最低丢弃优先值）范围内的高水平的包转发保证，并且可以为额外流量提供多余两级的低转发保证。<br />
本文档描述保证转发PHB组。不同的区分服务兼容节点如果想被认为是区分服务兼容的，并不需要实现此PHB组，但是当一个区分服务兼容节点要实现保证转发每一条行为组，它必须遵循本文档的规范。<br />
在本文档中出现的关键词“必须”，“禁止”&nbsp;，“需要”，“会”，“不会”，“应该”，“不应该”，“被推荐的”，“可以”，“可选的”在[Bradner]中有解释。<br />
2．保证转发PHB组<br />
保证转发PHB组提供在N个相互独立的保证转发类中的IP包转发。在每一个保证转发类中，每个IP包被分配给M个不同等级的丢弃优先级之一。一个属于保证转发类I且丢弃优先级为j的IP包被标记为保证转发编码点Afij，其中1&nbsp;&lt;=&nbsp;i&nbsp;&lt;=&nbsp;N&nbsp;，1&nbsp;&lt;=&nbsp;j&nbsp;&lt;=&nbsp;M。定义4个类（N=4），每个类有3个丢弃优先级（M=3）是通常的用法。局部使用的时候可以定义更多的保证转发类或者丢弃优先级。<br />
一个区分服务节点应该实现4个通常使用的保证转发类。一个保证转发类的包必须和来自其他保证转发类的包相互独立的转发出去。即，一个区分服务节点禁止汇集两个或者更多的保证转发类。<br />
一个区分服务节点必须为每一个实现的保证转发类分配一个可配置的，最小数量的转发资源（缓冲空间和带宽）。不论在短期还是长期，每一个类都应该获得设定的服务速率（带宽）。	&nbsp;&nbsp;&nbsp;&nbsp;<br />
当来自其他保证转发类或者其他PHB组的额外资源是可以利用时，一个保证转发类可以被配置为接收比最小数量多的转发资源。本文档没有规定如何分配额外资源。但是实现必须说明所支持的算法和参数设置。<br />
在每一个保证转发类中，如果一个包的丢弃优先级为p时，区分服务节点转发该包的概率决不能比该包的丢弃优先级为q的时候小，这里p&nbsp;&lt;&nbsp;q。注意这个要求可以在不需要出列和丢弃已经排队的包的情况下实现。<br />
在每一个保证转发类中，一个区分服务节点必须接收所有这3个丢弃优先级编码点，它们也必须产生至少两个不同级别的丢失概率。在某些网络中，尤其在企业网中，短暂拥塞发生的很少且时间很短，一个区分服务节点对每一个保证转发类只需要实现两级不同的丢失概率可能是合理的。尽管这对于某些网络可能是足够的，但当区分服务域经常发生拥塞的时候，应该支持3个不同级别的丢失概率。<br />
如果一个区分服务节点为保证转发类x只实现两个不同级别的丢失概率，编码点AFx1必须产生较低的丢失概率，编码点AFx2和AFx3必须产生较高的丢失概率。<br />
当同一个微流的保证转发包属于同一个保证转发类的时候，不论它们的丢弃优先级，区分服务节点禁止对它们重新排序。对于保证转发包的转发没有一个可以计量的时间要求（时延或者差分时延）。<br />
本文档的第7节描述了保证转发类和其他PHB组的关系。<br />
保证转发PHB组可以用来实现端到端和域边界到域边界的服务。<br />
3．流量控制动作&nbsp;<br />
一个区分服务域可以在域边界控制以不同丢弃优先级进入或者离开该域的保证转发流的数量。这种流量控制动作可以包含流量整形，丢包，增加或者减少包的丢弃优先级，将包重新分配到其它保证转发类中。然而，流量控制动作禁止产生同一个微流的重排序。<br />
4．队列和丢包行为<br />
本节详细说明保证转发PHB组的队列和丢包行为。PHB组的其他情况在第2节说明。<br />
当允许由于突发行为产生的短期拥塞时，一个保证转发的实现必须尽量使每一个类的长期拥塞最小化。这需要一个动态的队列管理算法。这个算法的一个例子是随机早期丢弃(RED)[Flord]。本文档没有说明一个特定算法的使用，但确实需要掌握一些道具(properties)。<br />
一个保证转发实现必须能检测每个类中发生的长期拥塞，并通过丢包对其作出反应，而通过包排队处理短期拥塞（包的突发）。这暗示平衡和过滤函数的出现可以监控瞬时拥塞水平并计算一个平滑的拥塞水平。丢包算法使用平滑拥塞水平决定包什么时候被丢弃。<br />
丢包算法必须做到对于使用保证转发类的微流的短期流量特性不敏感。即，具有不同的短期突发形状但同样长期的包速率流应该具有相同的包丢弃概率。实现这个目的的一种方法是使用丢包函数的随机性。<br />
丢包算法对待同一个类中具有相同优先级的包必须完全一样。这说明对于每一个给定的平滑拥塞水平，一个在同一优先级内的特定微流的包的丢弃速率应该和这个流在通过该优先级的总流量的百分比成正比。<br />
拥塞指示反馈给终端节点，这样每个丢弃优先级的包的丢弃水平和拥塞相关联。应该是逐渐的而不是突然的使整个系统达到一个稳定的操作态。一种实现RED的方法是使用两个（可配置）平滑拥塞水平阈值。当平滑拥塞水平超过第一个阈值，相应优先级的包不能被丢弃。当平滑拥塞水平在第一和第二个阈值之间，以线性增加的概率丢包，范围从0到恰好比第二个阈值高的可配置的值。当平滑拥塞水平超过第二个阈值，以100％的概率丢弃相应优先级的包。<br />
为允许保证转发PHB组运用在许多不同的操作环境下，丢包算法控制参数必须为每一个丢包优先级和每一个保证转发类独立配置。<br />
在上述限制下，本规范适用于一定范围内的包丢弃行为。不一致的丢包行为导致不一致的端到端服务语义，并限制了在一个多卖方（multi-vendor）环境下保证转发PHB可能的使用范围。如同实验中得到的，本文档今后的版本可能更多的定义合适的行为规范。<br />
5．隧道<br />
当一个保证转发包进入隧道时，隧道包的PHB禁止减少进入隧道的包的转发保证，也不允许出现同一个微流的保证转发类的重排序。<br />
6．推荐编码点<br />
下面给出4个通用保证转发类的推荐编码点。这些编码点和其他通用的PHB组没有重叠。<br />
保证转发编码点的推荐取值为：AF11&nbsp;=&nbsp;'001010',&nbsp;AF12&nbsp;=&nbsp;'001100',&nbsp;AF13&nbsp;=&nbsp;'001110',&nbsp;AF21&nbsp;=&nbsp;'010010',&nbsp;AF22&nbsp;=&nbsp;'010100',&nbsp;AF23&nbsp;=&nbsp;'010110',&nbsp;AF31&nbsp;=&nbsp;'011010',&nbsp;AF32&nbsp;=&nbsp;'011100',&nbsp;AF33&nbsp;=&nbsp;'011110',&nbsp;AF41&nbsp;=&nbsp;'100010',&nbsp;AF42&nbsp;=&nbsp;'100100',&nbsp;AF43&nbsp;=&nbsp;'100110'。&nbsp;&nbsp;	<br />
下表总结了推荐的保证转发编码点的取值。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	类&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;类&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;类&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;类&nbsp;4<br />
&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;001010&nbsp;&nbsp;|&nbsp;&nbsp;010010&nbsp;&nbsp;|&nbsp;&nbsp;011010&nbsp;&nbsp;|&nbsp;&nbsp;100010&nbsp;&nbsp;|<br />
中丢弃优先级&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;001100&nbsp;&nbsp;|&nbsp;&nbsp;010100&nbsp;&nbsp;|&nbsp;&nbsp;011100&nbsp;&nbsp;|&nbsp;&nbsp;100100&nbsp;&nbsp;|<br />
高丢弃优先级&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;001110&nbsp;&nbsp;|&nbsp;&nbsp;010110&nbsp;&nbsp;|&nbsp;&nbsp;011110&nbsp;&nbsp;|&nbsp;&nbsp;100110&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+----------+----------+----------+----------+<br />
7．与其他PHB组的互操作<br />
上述推荐的保证转发编码点的映射和本地用户空间以及在[Nichols]中推荐的类选择编码点互不干涉。因此类选择编码点选择的PHB可以和保证转发PHB组共存，并维持为它们定义的转发行为和关系。特别是，缺省的PHB编码点‘000000'仍然可以为传统的尽力而为流量所用。类似的，编码点‘11x000'可以为网络控制流量所用。<br />
保证转发PHB组结合边界流量控制行为可以得到类选择器PHB包含的所有行为，这里的边界流量控制行为是限制每一个保证转发类的流量数（通常是不同的）不超过类所分配资源的百分比范围。在这种情况下，最好在一个区分范围域内使用部分或者所有类选择器编码点作为保证转发编码点的别名。<br />
在同一个区分服务域中，除了类选择器PHB，任何其他的PHB组可以和保证转发PHB组共存。然而，任何保证转发PHB组的实现应该证明以下规则：<br />
(a)如果存在其他PHB组，它们可以抢先占有特别分配给每一个保证转发PHB类的转发资源。这种抢先占有禁止在普通的网络运营中发生，但是在一些不寻常的状况下是可以的－例如，&nbsp;‘11x000'编码点可以抢先占有保证转发的转发资源，在需要的时候，给网络控制流量一个意想不到的高优先级。<br />
(b)&nbsp;“额外”的资源如何分配给保证转发PHB组和其他已实现的PHB组。例如，一旦给每一保证转发类分配最小的资源，任何剩余的资源可以在保证转发类和缺省PHB中平均分配。一个可选择的例子是，任何剩余资源可以被分配给转发额外的保证转发流量，只有当所有的保证转发要求都满足的时候，可以利用分配给缺省PHB的资源。<br />
本文档没有说明任何保证转发PHB组和其他已实现的PHB组的任何特定关系：这只需要选择任何一个想要证明的关系。实现可能允许任一个或者所有可配置的关系。希望可以证明这种级别的配置灵活度对于许多网络管理员是有价值的。<br />
8．安全因素<br />
为了保护自身不受拒绝服务的攻击，一个提供方区分服务域应该将进入该域的流量限制在预定的特征描述内。同时，为了保护到客户区分服务域的链路不受拒绝服务攻击，提供方区分服务域应该允许客户方区分服务域指定链路资源如何分配给一个保证转发包。如果一种服务要求有保证转发编码点标记的流量，受到如源和目的地址这样的属性限制，网络的入口节点有责任检验这些属性的有效性。<br />
其它安全考虑在[Blake]和[Nichols]已经涵盖。<br />
9．知识产权<br />
本文档中包含的部分或者全部规范的版权声明已经通知IETF（互联网工程任务小组）。想要知道更多信息，参考在线产权声明列表。<br />
10．IANA考虑<br />
如第6节所列，本文档分配12个编码点，它们属于[Nichols]中定义的编码空间的1号池。<br />
附录：服务示例<br />
例如，保证转发PHB组可以用来实现所谓的Olympic服务，这包括3个服务类：铜，银和金。包被分配到这3个类中，分配给金类的包比分配给银类的包经受的负载轻（因此具有更高的及时转发的概率）。在银和铜类之间存在一定的关系。如果需要，每一类中的包可以再分为低，中，高丢弃优先级，得到进一步分离。<br />
在网络中的铜，银，金服务类可以被映射到保证转发类1，2，3。相似的，低，中，高丢弃优先级可以映射到保证转发丢弃优先级的1，2，3。<br />
可以分配包的丢弃优先级，例如，使用漏桶流量策略器，它具有速率和大小两个参数，其中大小是承诺的突发大小和额外的突发大小两个突发值的和。如果桶中的令牌数比额外突发大小大，包被分配一个低丢弃优先级，如果桶中的令牌数比0大，但至多为额外突发大小，分配中丢弃优先级，如果桶为空，分配高丢弃优先级。可能需要对来自一个客户区分服务域具有高丢弃优先级流量的数目设置一个上限，以避免出现来自客户区分服务域无法投递的具有高丢弃优先级包的雪崩导致对来自其他域可投递的具有高丢弃优先级包的拒绝服务的情况。<br />
另一种给包分配丢弃优先级的方法可以将一个Olympic服务类的用户流量限制在给定的峰值速率，并将它平均分配到每一种丢弃优先级。假设有高带宽微流的用户比低带宽微流用户预定一个更高的峰值速率，那么可以产生一个均衡的带宽服务，在拥塞发生的时候平均分配有效容量。<br />
如果在每个区分服务节点到达这个类的最大到达速率是先验的，保证转发PHB组也可以利用额外提供的保证转发类来实现一种无时延和低时延服务。然而，必需的进入控制服务规范超出本文档范围。如果低丢失不太客观，那么通过对每个保证转发类的有效缓冲空间设置低的最大限制，无需额外规定，就可以实现低时延服务。<br />
参考文献<br />
[Blake]Blake,&nbsp;S.,&nbsp;Black,&nbsp;D.,&nbsp;Carlson,&nbsp;M.,&nbsp;Davies,&nbsp;E.,&nbsp;Wang,&nbsp;Z.&nbsp;And&nbsp;W.&nbsp;Weiss,&nbsp;"An&nbsp;Architecture&nbsp;for&nbsp;Differentiated&nbsp;Services",&nbsp;RFC&nbsp;2475,&nbsp;December&nbsp;1998.<br />
[Bradner]Bradner,&nbsp;S.,&nbsp;"Key&nbsp;words&nbsp;for&nbsp;use&nbsp;in&nbsp;RFCs&nbsp;to&nbsp;Indicate&nbsp;Requirement&nbsp;Levels",&nbsp;BCP&nbsp;14,&nbsp;RFC&nbsp;2119,&nbsp;March&nbsp;1997.<br />
[Clark]Clark,&nbsp;D.&nbsp;and&nbsp;Fang,&nbsp;W.,&nbsp;Explicit&nbsp;Allocation&nbsp;of&nbsp;Best&nbsp;Effort&nbsp;Packet&nbsp;Delivery&nbsp;Service.&nbsp;&nbsp;IEEE/ACM&nbsp;Transactions&nbsp;on&nbsp;Networking,&nbsp;Volume&nbsp;6,&nbsp;Number&nbsp;4,&nbsp;August&nbsp;1998,&nbsp;pp.&nbsp;362-373.<br />
[Floyd]Floyd,&nbsp;S.,&nbsp;and&nbsp;Jacobson,&nbsp;V.,&nbsp;Random&nbsp;Early&nbsp;Detection&nbsp;gateways&nbsp;for&nbsp;Congestion&nbsp;Avoidance.&nbsp;IEEE/ACM&nbsp;Transactions&nbsp;on&nbsp;Networking,&nbsp;Volume&nbsp;1,&nbsp;Number&nbsp;4,&nbsp;August&nbsp;1993,&nbsp;pp.&nbsp;397-413.<br />
[Nichols]&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;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;December&nbsp;1998.<br />
作者联系地址<br />
Juha&nbsp;Heinanen<br />
Telia&nbsp;Finland<br />
Myyrmaentie&nbsp;2<br />
01600&nbsp;Vantaa,&nbsp;Finland<br />
EMail:&nbsp;jh@telia.fi<br />
<br />
Fred&nbsp;Baker<br />
Cisco&nbsp;Systems<br />
519&nbsp;Lado&nbsp;Drive<br />
Santa&nbsp;Barbara,&nbsp;California&nbsp;93111<br />
EMail:&nbsp;fred@cisco.com<br />
<br />
Walter&nbsp;Weiss<br />
Lucent&nbsp;Technologies<br />
300&nbsp;Baker&nbsp;Avenue,&nbsp;Suite&nbsp;100,<br />
Concord,&nbsp;MA&nbsp;&nbsp;01742-2168<br />
EMail:&nbsp;wweiss@lucent.com<br />
<br />
John&nbsp;Wroclawski<br />
MIT&nbsp;Laboratory&nbsp;for&nbsp;Computer&nbsp;Science<br />
545&nbsp;Technology&nbsp;Sq.<br />
Cambridge,&nbsp;MA&nbsp;&nbsp;02139<br />
EMail:&nbsp;jtw@lcs.mit.edu<br />
完整版权声明<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1999).&nbsp;&nbsp;版权所有.<br />
本文档及其译文可以复制并对外提供。可以部分或全部编著、复制、出版、分发与其有关的评议、解释和有助于实施的派生著作，没有任何限制，但要求在复制文件和派生著作中包括上述版权警告及本节版权声明内容。但是，本文件的内容不允许做任何形式的修改，诸如删除版权警告或者关于互联网社团或者其他互联网组织的介绍，除非为了开发互联网标准或翻译成英语以外的其他语言的需要，即使在这种情况下，也仍然必须遵循互联网标准过程中确定的版权程序。<br />
上述许可是永久性的，不会由互联网社团，它的继承者或转让者予以废除。<br />
本文件及其提供的信息以“现状”为基础，互联网社团与IETF(因特网工程任务小组)否认所有的保证明示或暗示，包含但并不限于任何保证。所含信息的使用将不会侵犯具有特殊目的的商用性或者适用性的任何权利或隐含的保证。<br />
致谢<br />
RFC编者活动基金现在由互联网社团提供。<br />
RFC2597——Assured&nbsp;Forwarding&nbsp;PHB&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;保证转发每一跳行为组<br />
<br />
RFC文档中文翻译计划				1<br />
<br />