rfc2212.txt

很多RFC的中文文档

和最高速率直接映射到ATM'的VBR流的Q.2931 QoS参数的相同的信元、突发大小和最高信
元速率。
	通过将路由器的缓冲区B设置为令牌桶的b和一些错误词之和，就能够获得书局报不会
丢失的保证。
	另一个和子网相关的问题是TSpec令牌桶速率衡量IP流量，不是(也不能)计算链路水平
头。所以子网网络元素必须调整速率和桶大小来计算增加的链路水平头，通道也必须它们
增加的额外的IP头。
	对于数据网络来说，通过将速率和桶大小除以最小策略单元来计算最大头速率。对于作
内部分段的网络而言，如ATM，由于必须计算每一个分段和任何数据报大小和分段之间不符
而造成的浪费，使得计算更复杂，例如，通过ATM AAL5与ATM分割和重组而造成的额外
数据速率的保守估计为：
((r/48)*5)+((r/m)*(8+52))
这代表着速率为速率除以48字节的信元再乘以5字节的ATM头，再加上最大数据报速
率(r/m)乘以8个字节的AAL5头与ATM对于数据报分组而浪费的最大空间(在每一个信元包
含一个字节时为52个字节)，但是这个估计可能很高，特别如果m很小，而ATM的浪费通常
比52个字节小的多(ATM实现者应该注意到当设置VC参数时，令牌桶可能不得不缩放，且
这个例子并不计算由于象在RFC 1483中指定的封装而造成的多余头)。
为了保证无丢失，网络元素不得不为突发的数据流分配缓冲区，如果每一跳实现流模型
状况良好，缓冲区大小只要为b(令牌桶的大小)。然而，如在前面重整形中所提到的，实现是
相近的，且我们期望在经过网络时流会变的更突发。然而，整形缓冲区的大小来处理突发为
b+Csum+Dsum*R，如果计算最高速率，可以进一步减小到：
M + (b-M)(p-X)/(p-r) + (Csum/R + Dsum)X
在此如果(b-M)/(p-r)小于Csum/R+Dsum的话，X被设置为r，如果(b-M)/(p-r)大于
Csum/R+Dsum的话，X被设置为R,否则X被设置为p,这种降低来自最高速率限制了网络中
突发数据b的放置这样的事实。反过来，如果网络元素返回一个非零的疏散词，Sout,需要的
缓冲区通过将Dsum加到Sout。
当发送应用程序鼓励设置最高速率参数时，且重整形点需要与之一致，为了计算最高端
到端的延时和缓冲区而忽略最高速率，这是可以接受的。正如上面所提到的，如果最高速率
是未知的(因此有可能是无限的)，所需的缓冲区大小为b+Csum+Dsum*R，无最高速率的端到
端延时为b/R+Ctot/R+Dtot。
对于每个网络元素参数D应该被设置为通过网络元素的最大数据报传输延时(与速率和
桶的大小无关)，例如，在一个路由器中，可能计算在最好和最坏情况下的差异，这个时间为
对于一个数据报通过输入接口传输到处理器，再从处理机到输出链路调度器所需的时间(假设
排队调度工作正常)。
对于在数据报环境下的加权公平排队而言，D被设置为链路的MTU除以链路带宽，以此
来计算一个分组一个最大分组开始传输的可能性，和到达分组在最大的分组之前已经离开。
对于一个基于帧、时间片系统，如Stop 和 Go队列，D为一个数据报在有机会发送之前需要
等待的最大时间片数。
注意到在多播时决定D可能很困难，在许多子网中，ATM就是一个例子，子网的性质依
赖于多播发送方到接受方的路径。对于这个问题有许多方法。其中之一是选择一个对于所有
的子网有代表性的时延，并将D设置为与时延不同的值。另一种是在子网的出口点估计子网
的性质，因为出口点是计算从源的路径的最好的地方。
注意：关于一个子网怎样决定它的性质并没有固定的规则集合。每一个子网技术都发展
它自己的过程来准确计算C 和 D及疏散值。
D被有意与在网络元素的延时区分开来，延时是通过设备的最小时间(在光纤中光速时延
或在移动一个分组时在路由器中花费的绝对最小时间)，而参数D被有意来限制在非基于速率
延时中的可变性。在实际应用中，这种区别有时是任意的(延时有时是最小的)，在这种情况下，
用D来混合延时并将延时广播为零是很合理的。
注意：在这种配置中，为了得到一个分组完整保证的最大延时，这个服务用户需要知道
排队延时和反应时间。反应时间并不是由这个服务来广播的，而是一个普通的特征参数。
然而，即使反应时间没有广播，这个服务还能被使用。最简单的方法是测量第一个分组
所经历的反应时间，并将这个延时作为反应时间的上界。
参数C是从一个特别的实现怎样从一个严格的比特服务发展来的数据日志，所以，对于
数据报加权公平排队而言，C被设置为M来衡量分组化效果。
如果一个网络元素使用一定数量的疏散，Si，来降低它为某个特别流所保留的资源数量，
I，Si的值应该存贮在网络元素中，之后，如果流I的保留更新收到的话，网络元素必须使用
同一Si，而不用进行进一步的计算，这保证了保留过程中的连贯性。
作为使用疏散词的一个例子，考虑这种情况，端到端所需的延时，Dreq，比流系统的最
大延时要大，后者通过将流延时公式中设置为R=r(为了稳定性，R应>=r)，如下所示：
                           b/r + Ctot/r + Dtot.
在这种情况下，疏散词为
S = Dreq - (b/r + Ctot/r + Dtot).
	S可以被网络元素用来调整它们的本地保留，以便它们能访问那些否则会被拒绝的流，
在中间网络元素的网络元素能够利用这些信息来减低为这个流保留的资源的数量，例如，通
过取一个 s<=S，一个RCSD调度器能够叫分配给流的本地延时,d增加到d+s,给定一个Rspec，
Rin, Sin)，通过将Rout = Rin 和Sout = Sin – s也可以作到这点。
	同样，一个使用WFQ调度器的网络元素通过使用在Rspec中的疏散词将本地保留从Rin
降到Rout。通过使用在前面几节的转换规则可以完成，这也保证减低保留水平不会增加所有
的端到端时延。

10评价标准
	元素的调度算法和访问控制算法必须保证在一个源流和TSpec一致时，延时界值不会被
破坏，数据报不会被丢失。此外，元素必须保证非一致的流不会影响给其他流的服务，提供
者鼓励去证明他们的实现是和流模型相近的。

11实现例子
	有几种算法和实现和流模型相近的，它们包括加权公平排队(WFQ)、Jitter- EDD [3]、
Virtual Clock [4]和IBM提议的一种配置，一种好的理论上表述表明这些配置是一大类算法的
一部分，这种理论可以在[6]中找到。

12使用例子
	考虑到一个对于任何丢失或延迟的数据报不能容忍的应用程序，它使用Ctot 和Dtot的
广播和流的TSpec值，来计算一个速率R的服务请求的延时界值。假设R<p,将其回访点设置
为[(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot。

13安全考虑
	本备忘录讨论了这个服务这样滥用来进行拒绝服务攻击。这个服务不容许拒绝服务(虽然
在一定的条件下可能会降低)
附录1：用RSVP的保证服务的使用
	和RSVP一起来使用保证服务在在参考[9]中指定。本文档给出了需要支持期望保证服务
的应用程序的RSVP FLOWSPEC, SENDER_TSPEC, 和ADSPEC对象。RSVP协议本身在参
考[10]中有指定。

14参考文献

   [1] Shenker, S., and J. Wroclawski, "Network Element Service
   Specification Template", RFC 2216, September 1997.

   [2] A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of
   a Fair Queueing Algorithm," in Internetworking: Research and
   Experience, Vol 1, No. 1., pp. 3-26.

   [3] L. Zhang, "Virtual Clock: A New Traffic Control Algorithm for
   Packet Switching Networks," in Proc. ACM SIGCOMM '90, pp. 19-29.

   [4] D. Verma, H. Zhang, and D. Ferrari, "Guaranteeing Delay Jitter
   Bounds in Packet Switching Networks," in Proc. Tricomm '91.

   [5] L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan,
   "Efficient Network QoS Provisioning Based on per Node Traffic
   Shaping," IBM Research Report No. RC-20064.

   [6] P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End Delay
   Bounds in Heterogeneous Networks," in Proc. 5th Intl. Workshop on
   Network and Operating System Support for Digital Audio and Video,
   April 1995.

   [7] A.K.J. Parekh, A Generalized Processor Sharing Approach to Flow
   Control in Integrated Services Networks, MIT Laboratory for
   Information and Decision Systems, Report LIDS-TH-2089, February 1992.

   [8] Shenker, S., and J. Wroclawski, "General Characterization
   Parameters for Integrated Service Network Elements", RFC 2215,
   September 1997.

   [9] Wroclawski, J., "Use of RSVP with IETF Integrated Services", RFC
   2210, September 1997.

   [10] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP)
   - Version 1 Functional Specification", RFC 2205, September 1997.

Authors' Addresses

   Scott Shenker
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA  94304-1314

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

   Craig Partridge
   BBN
   2370 Amherst St
   Palo Alto CA 94306

   EMail: [e-mail]

   Roch Guerin
   IBM T.J. Watson Research Center
   Yorktown Heights, NY 10598

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

RFC2212—— Specification of Guaranteed Quality of Service          保证服务质量的规范



1
RFC文档中文翻译计划