组织：中国互动出版网（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;		V.&nbsp;Jacobson<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2598&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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 />
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;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;K.&nbsp;Poduri<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;Bay&nbsp;Networks<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;June&nbsp;1999<br />
<br />
快速转发每一跳行为<br />
（An&nbsp;Expedited&nbsp;Forwarding&nbsp;PHB）<br />
本文档状况<br />
	本篇文档详细说明为互联网社团制定的互联网标准跟踪协议，希望得到讨论和改进建议。如果想了解这个协议标准化的声明和状况，请参考最新版本的“互联网官方协议标准”(STD1)。本文档的分发不受限制。<br />
版权声明<br />
	版权属于(C)the&nbsp;Internet&nbsp;Society(1999)。版权所有。<br />
摘要<br />
	在区分服务工作组的工作中PHBs（每一跳转发行为）是关键部分。本文档定义了称为快速转发的每一跳行为（PHB）。通过指出这种PHB可以被一种以上的机制实现，并给出它至少可以产生的一种服务，虚拟租用链路服务的用例，我们展示了该PHB的一般特性。本文给出了这种PHB的推荐编码点。<br />
	本文档的pdf版本从以下站点可以得到：<br />
ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf<br />
1．介绍<br />
	实现增强IP的区分服务的网络节点利用IP头中的一个编码点来选择一个PHB作为对该包的特定转发处理&nbsp;[RFC2474,RFC2475]。本文档说明一个特定的称为快速转发的PHB。快速转发PHB可以用来在区分服务域中建立一个低丢失，低时延，低抖动，保证带宽，端到端的服务。这种服务对于终端就象一个点到点连接或者“虚拟租用链路”。这种服务也被描述为特级服务(Premium&nbsp;service)[2BIT]。<br />
丢失率，时延和抖动都是排队流量穿越网络时的经历。因此为流量聚集提供低丢失率，低延时和低抖动意味着保证聚集不经历或者很少经历排队。当（短期）流量到达某些节点的速率超过它离开时候的速率，就会出现排队。因此一个保证某些聚集不用排队的服务等价于限制速率，这样在每一个通过的节点，聚集的最大到达速率比聚集的最小离开速率小。<br />
	建立一个这样的服务需要两部分：<br />
	1）配置节点使聚集具有一个明确定义的最小离开速率。（“明确定义”意味着不依赖于节点的动态状态，尤其是不依赖其它流量在此节点的强度）<br />
	2)&nbsp;调整聚集（通过策略和整形）使它在任何节点的到达速率总是小于这个节点配置的最小离开速率。<br />
	保证转发PHB提供第一部分服务。在[RFC2475]中定义的网络边界链路调节器提供第二部分服务。&nbsp;&nbsp;<br />
	保证转发PHB不是区分服务体系结构的必需部分。即，一个想成为区分服务兼容的节点不需要实现保证转发PHB。然而，当一个区分服务兼容节点声明要实现保证转发PHB，它的实现必须符合本文档中的规定。<br />
下一节详细描述保证转发PHB，并给出它可能被实现的例子。关键字“必须”，“禁止”&nbsp;，“需要”，“应该”，“不应该”，“可以”在[Bradner97]中有解释.<br />
2．快速转发每一跳行为说明<br />
	快速转发PHB被定义为对一个特定的区分聚集的转发行为，这些聚集的包离开任何区分节点的速率必须等于或者超过配置速率。快速转发流量获得的速率应该是独立于任何其他企图穿越该节点的流量的强度。在等于或者超过以配置速率发送一个输出连接大小为MTU（最大传输单元）包所需时间的任何时间间隔内测量的时候，它应该达到至少是配置速率的平均水平。（小于以配置速率发送一个包的时间刻度内的行为在这里没有说明）。配置的最小速率对于网络管理员必须是可设置的（使用该节点支持非易变结构的任何机制）。<br />
如果快速转发PHB被允许用无限制的抢先占有（preemption）其他流量（例如，一个优先队列）的机制实现，该实现必须包含一些方法限制快速转发流量可能给其他流量造成的损失（例如，一个令牌桶速率限制器）。超过限制的流量必须被抛弃。最大快速转发速率和合适的突发数，对于网络管理员必须是可以设置的（使用该节点支持非易变结构的任何机制）。最小和最大速率可能相同且只需设置一个参数。<br />
附录中描述如何用该PHB来构造端到端服务。<br />
2.2实现快速转发PHB的示例机制<br />
	可以使用一些队列调度机制提供2.1节描述的转发行为，以此实现快速转发PHB。只要其他高优先级队列抢先占有快速转发的时间没有超过以配置速率发送一个包的时间，一个简单的优先级队列可以给出合适的行为。（通过一个速率策略器（policer），例如用令牌桶和每一个优先级队列关联来限制队列可以饿死其他流量的程度）<br />
&nbsp;&nbsp;在一个加权循环调度器服务的队列组中使用单一队列也是可能的，该调度器分配给快速转发队列的输出带宽的份额等于配置速率。例如，可以用一个PHBs的类选择兼容集中的一个PHB实现[RFC2474]。<br />
	另外一种可能的实现是CBQ调度器，它给快速转发队列的优先级可以达到配置速率。<br />
	虽然不同的选择结果导致不同的辅助行为，如对单独的微流可见的抖动，所有这些机制都具有快速转发PHB需要的基本属性。参看附录A.3仿真量化其中的一些差别。<br />
2.3快速转发PHB的推荐编码点<br />
&nbsp;&nbsp;&nbsp;快速转发PHB的推荐编码点是101110。<br />
2.4多变性<br />
有快速转发PHB标记的包可能在区分服务域边界被重新标记为满足快速转发PHB的其他编码点。有快速转发PHBs标记的包不应该被一个区分服务域降级或者升级为其他PHB。<br />
2.5隧道<br />
	当一个快速转发包进入隧道时，隧道包必须被标记为快速转发。<br />
2.6与其他PHB的互操作<br />
	只要满足2.1的条件，在具有快速转发PHB的同一个区分服务节点或者域内可以配置其他PHBs和PHB组。<br />
3．需要考虑的安全因素<br />
	为保护自身不受拒绝服务攻击，区分服务域边界必须严格监控所有标记为快速转发的包的速率不超过和邻接上游域协商的值。（这个速率必须&lt;=快速转发PHB配置速率）。超过协商速率的包必须被丢弃。如果两个邻接域没有协商快速转发速率，下游域必须使用0作为速率（即，丢弃所有有快速转发标记的包）。<br />
	既然从快速转发PHB建立的端到端特级服务需要上游域对有快速转发标记的流量进行监控和整形以满足和下游域协商的速率，下游域监控器永远不需要丢弃包。因此应该注意丢包可能是由于违反安全或者有严重的误配置造成的（例如，借助简单网络管理协议（SNMP）来捕获（traps））。类似的，既然聚集快速转发流量速率是在每一个内部节点被建立的，快速转发队列就不应该发生溢出，所以如果有溢出，应该注意丢包可能是由于攻击或者严重的误配置造成的。<br />
4．IANA考虑<br />
	本文档在[RFC2474]中定义的编码空间的一号池中分配一个编码点，101110。<br />
5．参考文献<br />
[Bradner97]&nbsp;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 />
[RFC2474]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 />
[RFC2475]Black,&nbsp;D.,&nbsp;Blake,&nbsp;S.,&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 />
[2BIT]K.&nbsp;Nichols,&nbsp;V.&nbsp;Jacobson,&nbsp;and&nbsp;L.&nbsp;Zhang,&nbsp;"A&nbsp;Two-bit&nbsp;Differentiated&nbsp;Services&nbsp;Architecture&nbsp;for&nbsp;the&nbsp;Internet",&nbsp;Work&nbsp;in&nbsp;Progress,&nbsp;ftp://ftp.ee.lbl.gov/papers/dsarch.pdf<br />
[CBQ]S.&nbsp;Floyd&nbsp;and&nbsp;V.&nbsp;Jacobson,&nbsp;"Link-sharing&nbsp;and&nbsp;Resource&nbsp;Management&nbsp;Models&nbsp;for&nbsp;Packet&nbsp;Networks",&nbsp;IEEE/ACM&nbsp;Transactions&nbsp;on&nbsp;Networking,&nbsp;Vol.&nbsp;3&nbsp;no.&nbsp;4,&nbsp;pp.&nbsp;365-386,&nbsp;August&nbsp;1995.<br />
[RFC2415]Poduri,&nbsp;K.&nbsp;and&nbsp;K.&nbsp;Nichols,&nbsp;"Simulation&nbsp;Studies&nbsp;of&nbsp;Increased&nbsp;Initial&nbsp;TCP&nbsp;Window&nbsp;Size",&nbsp;RFC&nbsp;2415,&nbsp;September&nbsp;1998.<br />
[LCN]K.&nbsp;Nichols,&nbsp;"Improving&nbsp;Network&nbsp;Simulation&nbsp;with&nbsp;Feedback",&nbsp;Proceedings&nbsp;of&nbsp;LCN&nbsp;'98,&nbsp;October&nbsp;1998.<br />
6．作者联系地址<br />
Van&nbsp;Jacobson<br />
Cisco&nbsp;Systems,&nbsp;Inc<br />
170&nbsp;W.&nbsp;Tasman&nbsp;Drive<br />
San&nbsp;Jose,&nbsp;CA&nbsp;95134-1706<br />
EMail:&nbsp;van@cisco.com<br />
<br />
Kathleen&nbsp;Nichols<br />
Cisco&nbsp;Systems,&nbsp;Inc<br />
170&nbsp;W.&nbsp;Tasman&nbsp;Drive<br />
San&nbsp;Jose,&nbsp;CA&nbsp;95134-1706<br />
EMail:&nbsp;kmn@cisco.com<br />
<br />
Kedarnath&nbsp;Poduri<br />
Bay&nbsp;Networks,&nbsp;Inc.<br />
4401&nbsp;Great&nbsp;America&nbsp;Parkway<br />
Santa&nbsp;Clara,&nbsp;CA&nbsp;95052-8185<br />
EMail:&nbsp;kpoduri@baynetworks.com<br />
附录A：快速转发PHB的使用示例和经验<br />
A.1&nbsp;虚拟租用链路服务<br />
	一个已知的特级服务[2BIT]虚拟租用链路（VLL）服务，用峰值带宽量化。<br />
A.2&nbsp;在能源科学网（ESNET）中的使用经验<br />
	VLL服务原型在能源部[美]（DOE）的能源科学网（ESNet）的骨干网中配置。使用Cisco75xx系列路由器的加权循环队列特性实现快速转发PHB。早期测试非常成功，正在开展使该服务在常规生产基础上有效的工作。（详情参看&nbsp;ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf&nbsp;和<br />
&nbsp;&nbsp;&nbsp;ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf）<br />
A.3&nbsp;仿真结果<br />
A.3.1&nbsp;抖动变化<br />
	在2.2节，我们指出有许多机制可以用来实现快速转发PHB。最简单的是优先级队列（PQ）,该队列的到达速率严格小于它的服务速率。因为抖动是由通路上的排队时延产生的，该实现的特性是按预定速率转发具有快速转发标记的微流将经历非常小的抖动，这是由于包在队列中的时间很短。快速转发PHB没有明确的时延要求，但定义中很明确，使用基于快速转发PHB服务的包流利用优先级队列比尽力而为转发的期望抖动值要小。我们使用仿真研究和比较加权循环和优先级队列的抖动值。既然它们的抖动值分别是最好和最坏的情况，我们选择这两个，而且我们想为选择加权循环或者类似机制的快速转发实施者提供大致的指导方针。<br />
	我们的仿真模型在一个改进的[RFC2415]和[LCN]中描述的ns-2中实现。我们使用包含ns-2的CBQ（类基队列）模型作为实现优先级队列和加权平均队列的基础。我们的拓扑结构包含在单一的1.5Mbps瓶颈链路方向上带宽递减的6段（看图6）。源端以等于预定包速率的平均比特速率产生具有快速转发标记的包。以预定包速率产生的包和包内间隔（interpacket&nbsp;spacing）具有+-10%的偏差。每个源速率被选择聚集达到瓶颈链路或者450&nbsp;Kbps的30％。FTPs和HTTPs的混合物用来填充该链路。每一个快速转发包的源端或者全部产生160字节的包或者全部产生1500字节的包。虽然我们用一个包大小展示统计信息，所有的实验都使用长短包混合的快速转发源端，因此快速转发队列具有两种包长度。<br />
	我们将抖动定义为两个临接包到达时间减去离开时间的绝对差值|(aj-dj)&nbsp;-&nbsp;(ai-di)|。对于每个实验的目的流，我们将中间和第90％的抖动值记录在表中（表示为预定快速转发速率的％）。本文档的Pdf版本包含抖动百分点的图。<br />
我们的实验比较了加权循环和优先级队列实现的快速转发PHB的抖动值。我们评价了不同加权循环队列的权值和队列数量对于抖动的影响。对于加权循环，我们定义服务/到达速率的比值为快速转发队列的服务比率（或者是该队列在输出链路中的最小份额）乘以输出链路带宽除以队列中有快速转发标记包的峰值到达速率。如果加权循环队列权值的选择是严格的平衡了到达和离开速率，结果将是不稳定的，因此我们使用一个最小的服务/到达速率比值1.03。在我们的仿真中，这意味着快速转发队列得到至少31％的输出链路。如上述，我们在加权循环仿真中用其他流量填满链路，将无快速转发标记的流量分裂到非快速转发队列中。（从实验的描述中，应该很清楚我们企图产生最坏的抖动情况，不希望这些设置或者流量重现一个“正常”的运行点）。<br />
	我们的第一个实验集使用最小的服务/到达比值1.06，我们将每一个组成快速转发聚集的微流的数量从2变到36。我们将这些和一个用24个流实现的优先级队列相比较。首先，我们检查一个以预定速率56Kbps发送包大小为1500字节的微流，然后是同样速率但包大小为160字节的流。表1所示以预定速率发送一个包的时间的第50和第90个百分点的抖动。图1描划了包大小为1500字节的流，图2描划了包大小为160字节的流。注意以56Kbps发送一个大小为1500字节的包的时间是214ms，对于160字节大小的包是23ms。尽管大部分小包的抖动至少是一个预定速率的包时间，大包的抖动很少超过一个预定速率包时间的一半。记住所有情况下，快速转发聚集的是一个大包和小包的混合，因此短包可能在快速转发队列中等待长包。优先级队列给出了一个很小的抖动。<br />
	表1：多个快速转发流抖动变化：服务/到达速率的比值是1.06，预定的速率是56Kbps（所有的值都是以预定速率％的形式给出）<br />
			1500字节的包&nbsp;&nbsp;&nbsp;160字节的包<br />
＃快速转发流&nbsp;&nbsp;&nbsp;50th&nbsp;%&nbsp;&nbsp;90th&nbsp;%&nbsp;&nbsp;50th&nbsp;%&nbsp;&nbsp;90th&nbsp;%<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PQ&nbsp;(24)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;43<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;47&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;96&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;513<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;35&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;278<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;25&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;96&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;126<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;24&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;18&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;47&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;96&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;143<br />
	下一步我们看看增加服务/到达的比值的影响。这意味着快速转发包应该保持更短的入对时间，尽管对其他队列的有效带宽保持不变。在这个实验集中，快速转发聚集流的数量固定为8，总的队列数量为5（4个非快速转发队列）。表2所示为1500和160字节流的结果。图3描划1500字节的结果，图4是160字节的结果。当服务/到达的比值为1.5时性能增加达到稳定。注意更高的服务/到达的比值不能象对优先级队列那些提供同样的性能，但是现在90％的包经历的抖动小于一个预定速率包时间，即使对于小包。<br />
	表2：快速转发流抖动变化：服务/到达的比值变化，8个流聚集，预定的速率是56Kbps<br />
&nbsp;&nbsp;&nbsp;	加权循环队列&nbsp;&nbsp;1500字节的包&nbsp;&nbsp;&nbsp;160字节的包<br />
服务/到达&nbsp;&nbsp;50th&nbsp;%&nbsp;&nbsp;90th&nbsp;%&nbsp;&nbsp;50th&nbsp;%&nbsp;&nbsp;90th&nbsp;%<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PQ&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;43<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.03&nbsp;&nbsp;&nbsp;&nbsp;14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;27&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;178<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.30&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;65&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;113<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.50&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;13&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;57&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;104<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.70&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;13&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;57&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;13&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;57&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;104<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;13&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;57&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100<br />
	增加输出端口队列的数量可以导致在对快速转发包的服务时间内的可变性，因此我们实现一个改变每个输出端口队列数量的实验。我们将聚集流的数量固定为8，使用最小的服务/到达的比值1.03。结果如图5和表3所示。图5包含以8个流为底线的优先级队列。<br />
表3：输出端口具有多个队列的抖动变化：服务/到达速率的比值是1.03，8个流聚集&nbsp;<br />
	＃快速转发流&nbsp;&nbsp;1500字节的包&nbsp;&nbsp;&nbsp;<br />
	流&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;50th&nbsp;%&nbsp;&nbsp;90th&nbsp;%&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PQ&nbsp;(8)&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;21<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;21<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;22<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;23<br />
	看起来大多数加权循环的抖动都很低，而且考虑预定速率，选取合适的快速转发队列中加权循环在输出链路的份额，还可以减小抖动。如已经指出的，当优先级队列是最好的情况时，加权循环是最坏的情况。其他快速转发队列可能包含固定速率限制的加权循环或者类基队列，但是给它的优先级高于其他队列。我们期待后者的性能和优先级队列近似相同，尽管未来的仿真需要证明这一点。我们还没有系统的研究跳数，快速转发分配除这30％以外的带宽，或者更复杂的拓扑的影响。本节的信息不是快速转发PHB定义的一部分，但是简单的提供指导实现的背景。<br />
A.3.2&nbsp;虚拟租用链路服务<br />
	我们使用仿真来看看利用快速转发PHB建立的VLL服务是如何运转的，也就是看看它是否象一条具有预定速率的“租用链路”。在最后部分的仿真中，网络中没有一个快速转发包被丢弃，同时对于这些固定比特率（CBR）源也能达到目标速率。然而，我们想看看VLL是否真的象一条到达使用它的TCP的“线路”。因此我们使用VLL服务仿真一个长生存器的FTPs。表4给出每一次仿真中分配给快速转发流量的链路百分比（链路上的快速转发微流少的，带宽也小），预定的VLL速率，按照预定速率和VLL流平均速率用全双工专用链路连接的同类型的发送者－接受者对的平均速率（所有的发送者－接收者对具有同样的值）。只有当输入整形缓存而不是网络有溢出的时候才出现丢失。由于已知的TCP行为，目标速率是不能达到的。<br />
&nbsp;&nbsp;			表4：使用VLL服务的FTP性能<br />
	％连接到&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	平均发送速率（kbps）	<br />
	快速转发&nbsp;&nbsp;&nbsp;&nbsp;预定的	专用的	VLL<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;20&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;90&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;90<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;40&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;150&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;143&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;143<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;60&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;225&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;213&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;215<br />
完整版权声明&nbsp;&nbsp;&nbsp;&nbsp;<br />
Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1999).&nbsp;&nbsp;版权所有.<br />
本文档及其译文可以复制并对外提供。可以部分或全部编著、复制、出版、分发与其有关的评议、解释和有助于实施的派生著作，没有任何限制，但要求在复制文件和派生著作中包括上述版权警告及本节版权声明内容。但是，本文件的内容不允许做任何形式的修改，诸如删除版权警告或者关于互联网社团或者其他互联网组织的介绍，除非为了开发互联网标准或翻译成英语以外的其他语言的需要，即使在这种情况下，也仍然必须遵循互联网标准过程中确定的版权程序。<br />
上述许可是永久性的，不会由互联网社团，它的继承者或转让者予以废除。<br />
本文件及其提供的信息以“现状”为基础，互联网社团与IETF(因特网工程任务小组)否认所有的保证明示或暗示，包含但并不限于任何保证。所含信息的使用将不会侵犯具有特殊目的的商用性或者适用性的任何权利或隐含的保证。<br />
致谢<br />
	RFC编者活动基金现在由互联网社团提供。<br />
<br />
RFC2598——An&nbsp;Expedited&nbsp;Forwarding&nbsp;PHB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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 />