保证服务质量的规范

【保证服务质量的规范】本备忘录的状态
本文档具体讲述了一种Internet社区的标准协议，需要进一步进行讨论和建议以得到改
进。对于本协议的标准化状况请参照“互连网正式协议标准”(STD1)的当前版本，本备忘录
的发布不受任何限制。
版权声明
Copyright(C)TheInternetSociety(2001).
摘要
本备忘录描述了在互连网中为传输保证服务的网络元素行为，保证服务为点到点的数据
报队列的时延提供了严格的限制(在数学上可证实的) ，这种服务使得提供保证时延和带宽的服
务成为可能。本规范遵循在[1]中所描述的服务规范。
1导言 2
2端到端的行为 3
3动机 3
4网络元素数据处理要求 3
5激活信息 4
6输出信息 5
7策略 6
8排序和汇合 7
9实现者指南 9
10评价标准 10
11实现例子 11
12使用例子 11
13安全考虑 11
14参考文献 11
1导言
本文档定义了支持保证服务的网络元素的必要条件，在关于具体说明IP网络中支持各种
服务质量的网络元素的系列文档中，本备忘录是其中之一。在这些文档中描述的服务无论在
整个互连网还是在专用IP网中都是有益的。
RFC2119中对于在本文象"MUST","MUSTNOT","REQUIRED","SHALL","SHALL
NOT","SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"这
样的要害字已有解释。
本文档是基于[1]中的关于服务规范模板的基础上的。关于IP协议族中服务质量的规范的
定义和信息，请参考该文档。
简言之，本备忘录中隐含的概念是使用一个令牌桶来描述流，网络元素(如路由器、子网
等)以此计算它将怎样来处理这个数据流的各种参数，通过结合路径上各种服务元素的参数，
就有可能计算出在通过这条路径传送时经历的最大时延。
注重本备忘录的三个特征和它所规范的服务：
1、在为了获得保证的保留，指定设置机制必须遵守的必要条件时，无论是设置机制本身还是
鉴别流的方法都没有被指定。可以通过使用象RSVP、手工配置相关的路由器或者如SNMP
之类的网络治理协议来创建保证保留。这种指定是有意安排独立于设置机制的。
2、为了获得限定的时延，要求路径上的每一个服务元素都支持保证服务或充分模拟保证服
务。然而。这种必要条件并不意味着保证服务应在整个互连网配置而使之有效，保证服务
甚至在部分配置时也有明显的益处。假如在内部网中完全配置了保证服务，则可在内部支
持保证服务。ISP也能在它的主干网中配置保证服务并在用户之间提供保证服务。
3、因为服务元素产生时延限度为结果，而不是将时延限度作为将获得的输入，有时认为应用
程序不能控制时延，实际上，保证服务在时延上给应用程序提供了相当可观的控制。
总之，时延包含两部分：固定时延(传输时延)和排队时延。固定时延是所选路径的特性，
这是有设置机制而不是有保证服务决定的。只有排队时延才是由保证服务决定的。排队时
延主要是两个参数的函数(正如在本文后面的等式表明)：令牌桶(桶的大小b)和应用程序
所要求的数据速率。这两个值完全由应用程序控制，换句话说，应用程序通常能准确估计
保证服务可能容许的排队时延，此外，假如时延比所期望的要大，应用程序调整其令牌桶
和数据速率来获得较低的时延。
2端到端的行为
由遵守本文的一系列网络元素所提供的端到端的行为是带宽的一中确定水准，当一
个策略流使用时，对所有一致的数据报都产生没有排队丢失的限定时延的服务(假定在流
的生命周期内网络组件没有故障或路由没有改变) 。
端到端行为遵守流模型(在网络元素数据处理中描述) ，其中排队时延不会超过流时延
指定的错误限度。更精确的，端到端的时延区间为：[(b-m)/R*(p-R)/(p-r)] (M Ctot)/R Dtot
(p>R>=r),(M Ctot)/R Dtot(r<=p<=R),本文稍后定义了b,r,p,M,R,Ctot,andDtot 。
注重：当需要用来计算端到端时延的每一跳错误术语由服务模型(见下面的输出信息)
输出时，需要用来采集每一跳的限制和让端到端的Ctot和Dtot对应用程序得知的机制
在本文中并没有描述。这些功能由保留设置协议、路由协议或其他网络治理功能提供，
不在本文的讨论范围之中。
一条路径上的最大端到端排队时延(Ctot、Dtot)和带宽(R)是稳定的，也就是说，只
要端到端的路径不改变，它们就不会改变。
保证服务并没有控制数据报的最小或平均时延，而仅仅是最大排队时延，而且，要
计算数据报将经历的最大时延，必须决定路径上的延迟性，并将起加到保证服务排队时
延中（然而，如下面表明，通过观察其中任意一个包所经历的时延可以计算延时性的保
守范围）
这种服务服从容许控制。
3动机
保证服务质量保证假如流的通信量保持在其指定的通信参数内，数据报将在保证的传输
时间内到达，并且不会发生由于队列溢出造成数据报丢弃。这种服务是为那些需要严格保证
的应用所预备的，它要求一旦从其源点发送数据，数据将在某一特定的时间内到达目的地。
例如，对于象一些音频和视频回放的应用而言，在其回放时间之后的数据报到达是不可容忍
的，其他有实时要求的应用也需要保证服务。
这种服务并不打算将抖动(最大数据报时延和最小数据报时延之间的差)降到最小，它仅仅
是控制最大时延。由于保证时延限制的严格性，时延被设置的足够大以包含有些非常少见的
长的排队时延，有研究表明，对于大部分的数据报而言，其真正的时延比保证服务的时延要
小得多，因此，回放程序的程序员应该注重，数据报通常在比传输时间限制的要求小的多的
时间内到达，所以接受端系统不得不缓冲数据，直至有应用程序来处理它们，
这种服务表现了对网络时延控制的一种极端情况，大部分提供时延控制的其它服务对于
因而发生的时延提供更弱的保证，为了提供高水平的保证，只有在路径上每一网络元素都提
供保证服务时，保证服务才真正有效，而且，如在输出信息部分所描述的，服务的有效配备
和使用需要设置或其他协议，用以请求服务提供中间路由器和端点的服务描述。
4网络元素数据处理要求
网络元素必须保证服务和服务的流模型接近，在服务速率R上的流模型从本质上来说，
在源和接收方之间服务有专门的R带宽提供，因此，在固定速率R上的流服务模型，流服务
是完全和其他任何流无关的。
在每一个网络元素上，流的服务速率一网络带宽(R)和缓冲区大小(B)来标志， R表示流被
赋予的链接网络带宽， B表示在网络元素中流可能消耗的缓冲区大小，在某一明显的错误限
度内，网络元素必须保证它的服务与同一速率上的流模型相匹配，
保证服务的定义依靠这样一个结果，即只要R比r大，服从令牌桶(r,b)和在带宽R的条
件下的流的时延被限制在b/R内，在服务速率R上的保证服务和这种行为接近，在此， R为
共享带宽，而不是对于专用线路而言，
从而，网络元素必须保证任何数据报的排队时延必须比b/R C/R D小，在此， C和D描
述了对流模型的最大偏差。强调C和D是最大的是很重要的，因为假如在执行时服务偶然存
在差距(也许由于处理路由更新) ， D需要足够大，可能数据报在这个差距内会丢失(C和D在
输出信息部分有更具体的描述) ，
注重：严格来说，本备忘录仅仅要求流得到的服务从来不应该会比它在流模型的近似条
件下差，赋予更好的服务会是完全可接收的，例如，假如一个流当前并没有使用它的部分带
宽R ，象加权公平排队算法这样暂时分配其他流没有用的带宽是完全可以接收的(实际上，也
鼓励这样做) 。
作为保证服务的一部分，链路不容许将数据报分段，比链路的MTU大的数据报必须作为
例外情况治理，这意味着它们将通过下面的治理部分的规则来治理。
5激活信息
通过向网络元素指定通信量(TSpec)和期望的服务(RSpec) ，可以激活保证服务，对于一个
存在的有新的TSpec和Rspec的流的服务请求应该被当做一次新的激活，这意味着容许控制
应被重新应用到这个流上，对于那些降低它们的TSpec和Rspec的流(如在下面命令规则部分
所描述的，流的新TSpec和Rspec严格地比旧的TSpec和Rspec小)而言，决不应拒绝它们
的服务。
Tspec是采取令牌桶加上最高速率(p)、最小治理单元(m)和最大数据报大小(M)的形式。
令牌桶有一个桶深(b)和桶速率(r) 。r和b都必须大于0,r是以每秒内的IP数据报的字节
数来衡量的，范围从1B/s到40TB/s(或相信可以接近单一光纤的最大理论带宽) 。很明显，特
别是对于高带宽，仅仅是最开始的数字是有意义的，所以鼓励使用至少精确到0.1%的浮点数
表示法。
令牌深(b)也是一字节数来衡量的，范围从1B/s到250TB/s ，同样，鼓励使用至少精确到
0.1%的浮点数表示法。
这些值的范围这样大是为容许将来的带宽，并不是有意暗示网络元素必须支持整个范围。
最高速率(p)是以每秒内的IP数据报的字节数来衡量的，和桶速率有相同的范围和表示方
法。最高速率是源和改造点(在下面定义)之间的可以注入到网络中的突发通信量的最大速率。
更精确的说，在所有的时间段内，数据量不能超过M pT ，在此M是最大的数据报大小， T
是时间段的长度，这一点是很重要的。而且， p必须大于或等于令牌桶的速率,r 。假如最高速
率未知或没有指定，那么p必须设置为无穷大。
最小治理单元m是以字节数衡量的整数，在为了与Tspec一致的治理和测试中，所有比
m小的IP数据报都被以m的大小计算在内，最大数据报大小,M,是和通信量规范一致的最大
数据报，假如请求的最大数据报比链路容许的MTU大，这个流将被拒绝。M和m都应该大
于0 ，且m必须小于等于M 。
保证服务使用在[8]中定义的TOKEN_BUCKET_TSPEC参数来描述一个数据流的通信特
征，以上的描述就是这种参数， TOKEN_BUCKET_TSPEC是通常参数号127 ，使用保证服务
的这个参数Tspec可以简化在多服务环境下的保证服务的使用。
Rspec是速率R和疏散词S,在此， R必须大于等于r,且S必须是非负的，速率(R)是以每
秒内的IP数据报的字节数来衡量的，和桶速率、最高速率有相同的范围和表示方法。S是以
毫秒来计算的，因为较高的速率会降低排队时延， Rspec速率会比TSpec速率大。S意味着在
期望时延和使用保留水平R所得到的时延之间的差别。S可以被网络元素来降低它为这个流
保留的资源。当一个网络元素选择使用Rspec中的S时，在更新Rspec的R和S字段中，它
必须遵循指定的规则。这些规则在命令和融合部分指定。假如在服务激活的时候，没有指定
S,那么S将被指定为0 。因为网络元素期望有足够的缓冲空间来保证没有在Tspec的令牌桶和
最高速率、Rspec中的保留速率和疏散量及网络元素中， Ctot和Dtot或Csum和Dsum等
关于元素怎样治理通信量的的输出信息有排队丢失的现象。
Tspec能够以两个网络字节顺序的单精度IEEE浮点数的格式的三个浮点数来表示。第一
个浮点数值是速率(r),第二个浮点数值是桶的大小(b),第三个值是最高速率(p),第一个整数是最
小治理单元(m),第二个整数是最大数据报大小(M) 。
Rspec速率词， R,也可以用单精度IEEE浮点数来表示。
疏散词， S ，也能够用32位整数来表示，它的值的范围从0到2**32-1微秒。
当r,b,p,和R用IEEE浮点数的形式表示时，符号位必须为0(所有的值必须是非负的) 。
禁止使用小于127(如0)的指数，也不鼓励使用大于162的指数(如35) ，除非指定了一个无穷
大的最高速率。无穷大是用全为1(255)的指数表示，有一个符号为，尾数全为0 。
6输出信息
每一种保证服务模型至少必须输出以下信息，所有下面描述的参数都是描述性的参数。
网络服务的一个网络元素实现是由两个错误词， C和D来描述的，这两个词表示保证服
务的元素与流模型的偏差程度。这两个参数是附加的组成规则。错误词C是依靠于速率的错
误词。它代表流中的数据报由于流的参数速率可能经历的时延。象这样的一个例子是在ATM
信元以1/r的速率发送时，需要计算将一个数据报分解成ATM信元的时间。
注重：
在计算延时范围时，参数C被保留速率R去除，注重到这一点是很重要的，仍以序
列化数据报的例子来说明去这样做的目的，因为C是发送速率的函数，在实现时应注重到，
在用不同的速率值去除C时，应保证C对都具有相近的结果。不依靠于速率的时延值应与合
到D参数之中去。
错误词， D,是依靠于速率的每个元素错误词，代表通过服务元素的非基于速率传输时间
变更。它通常在启动或配置时决定或设置。D的一个例子是时间片网络，在一个时间片的循
环中，保证服务流被分配到特定的时间片上去，每个流的时延的一部分可能由时间片的循环
中被分配到流的时间片来决定。在这种情况下， D将估计一个流在一旦预备发送后，可能等
待一个时间片的最大时间。注重，这个值在时间片被分配之前可以被计算，因此可以被广播，
例如，有100个时间片，在最坏的情况下，一个流可能得到它的所有的时间片，以至于有一
分组正好在时间簇片用完后预备发送，这个分组在发送之前可能需要等待100-N个时间片，
在这种情况下，可以通过将D设置为100个时间片来使时延最接近。
假如合成函数在计算C和D(Ctot和Dtot)的端到端的和时，应用于整个路径上，并将
结果提供给端点。端点可以以此来计算最大数据报排队时延。然而，假如从最近重整形点(重
整形在下面定义)得到的向接收者的下行流的部分和(Csum和Dsum)被传送到每一个网络元
素，这些网络元素可以计算获得无数据报丢失的必须缓冲区大小分配，具体细节在实现指南
中描述。正确使用和配备这种服务需要Ctot、Dtot、Csum、Dsum的值。因此，我们假
设在这些值对端点和网络元素都可用的环境下，使用保证服务。
错误词C是以字节为单位来衡量的，单个元素可以广播从1到2**28之间的C值，且所
有元素总共可以的值可达2**32-1 ，假如不同元素时延之和超过了2**32-1 ，端到端的错误词
必须设置为2**32-1 。
错误词D是以毫秒为单位来衡量的，单个元素可以广播从1到2**28(大概2分钟)的值，
所有元素可以的值之和可达2**32-1 ，假如不同元素的时延之和超过了2**32-1 ，端到端的时
延必须设置为2**32-1 。
保证服务是服务名2 。
Rspec参数被编号为130 。
错误特征参数C和D被编号为131和132 ，端到端的C和D(Ctot和Dtot)被编号为133
和134 。最后重整形点的C和D(Ctot和Dtot)被编号为135和136 。
7策略
在保证服务中有两种形式的策略，一种形式是简单策略(仅称为策略与其他文档一致) ，此
时到达的流与Tspec比较。另一种形式是重整形，尝试去恢复(也有可能破坏)流的外形，使之
符合Tspec ，由于重整形失败(重整形缓冲区溢出) ，会发现流破坏Tspec的状况。
策略是在网络的边缘进行的，重整形是在所有不同源分支点和所有源汇合点进行的。在
不同源分支点，从一个源分支到不同路径的多播分叉树点，在不同输出链路上的Tspec保留
值并不完全相同。假如在输出链路上的Tspec值“小于”在上行链路上保留的Tspec值，仅仅
需要进行重整形。在源汇合点，从不同源(分享相同的保留)的分枝路径或树汇合。确定在哪个
地方需要策略是服务激活者(设置协议、本地配置工具或者相似的机制)的责任，重整形
也可能在除了上面描述的其他点进行。策略不能在网络边缘的其他地方进行。
令派桶和最高速率要求通信流在所有时间内都遵守的规则：发送的数据量不能超过
M min[pT,rT b-M],r和b都是令牌桶的参数， M是最大数据报的大小， T是时间间隔的长度
(当p为无穷大时，将会减小到标准的令牌桶要求) 。因为这个目的，链路必须对比最小策略单
元m小的数据包计数，到达一个元素的数据包而超过了M min[pT,rT b-M]的被认为是非一
致的。
在网络的边缘，对通信流进行策略来保证它与令牌桶一致，非一致的数据包被当作是“尽
力而为”的数据包。[当且仅当标记的能力有效时，这些非一致的数据包应该被标记成非一致
的，然后在所有余下的路由器中当作尽力而为的数据包对待] 。
尽力而为服务被定义为一个网络元素的缺省服务，对于不是流的一部分的数据包，在流
的源和目的之间传送时，提供尽力而为服务，在其他的暗示中，这个定义意味着，假如一个
流改变为尽量而为的数据包，所有适合于尽力而为服务的流控制也将适合于这个数据报。
注重：可能有在本文档范围之外的情况，如当保证服务的实现模型被用来实现流量共享
时，而不是服务质量时，此时对于非一致的数据包希望采取的操作是丢弃数据包，为了容许
这种应用，实现者应该保证对于非一致数据包的操作应该是可配置的。
在网络内部，由于排队影响会偶然使的原来进入网络时一致的数据流在一些下行的网络
元素中变得不再一致，因此策略可能不会产生期望的结果，因此，在网络内部，希望策略流
量的网络元素必须通过重整形流量到令牌桶，重整形使得延时的数据报符合Tspec的指定。
重整形是通过以令牌桶和最高速率调节器来结合缓冲区进行的，直到数据报符合令牌桶
和最高速率参数后，才发送数据(令牌桶调节器必须从它的满令牌桶开始) ，在保证服务下，需
要对任何一致的流量重整形回它原来的令牌桶外形的缓冲区的数量是b Csum (Dsum*r) ，
Csum和Dsum是在上一次重整形点和当前重整形点之间的C和D参数之和。注重，在对重
整形者处的最高速率的熟悉能够被用来降低这些缓冲区的要求(参照下面的“实现指南部分”) ，
网络元素必须提供必须的缓冲区来保证在重整形处一致的流量不会丢失。
注重：我们看到一个不重整形的路由器通过对那些超过b Csum (Dsum*r)的排队流量观
察，能够分辨出非一致的数据报(丢弃它们或以较低的优先权调度它们) 。
假如到达的数据报发现重整形缓冲区是满的，那么这个数据报是非一致的，这意味着一
个重整形点也是一个有效的策略，作为一个策略者，重整形者应该将非一致的数据报转交到
尽力而为上去[假如可以使用标记，非一致数据报应该被标记] 。
注重：作为一个策略者，它应该有可能去配置重整形者怎样去处理非一致数据。
有可能会注重到大的缓冲区会使得重整形显得增加了一定的时延，但情况并不是这样，
在给定一个准确描述流量的有效Tspec时，在重整形点重整形只造成很少的额外时延(根本不
会影响时延界限) ，另外，在正常情况下，重整形并不会造成任何数据的丢失。
然而， (典型地在汇合点或分枝点) ， Tspec比实际的流小的情况也可能会发生，假如这种
情况发生，在重整形点，重整形会造成较长的队列，这样会导致额外的时延，并强行将有些
数据报当做非一致数据对待。这种情况使得一种令人不快的拒绝服务成为可能，一个通过尽
力而为成功接受流数据的接收方会被一个要求为流保留资源但TSpec和Rspec不足的新的
接受者抢空，现在流数据被策略，还有可能被整形，假如策略功能选择去丢弃数据报，尽力
而为接收者将停止接受流，因为这个原因，在正常情况下，策略者仅仅将非一致数据报当作
尽力而为的数据对待(并在标记可行时标记它) ，尽管可以采取这样的方法来防止拒绝服务，实
际上，差的Tspec值还是有可能造成时延增加。
注重：为了将重排序数据问题最小化，在一个新的数据报到达且重整形缓冲区已满时，
重整形点希望从一个重整形队列的头来转发一个尽力而为的数据报。
我们注重到重分类为尽力而为的数据报也使的对更具弹性的流的支持更叫轻易，它们能
保留一个暖和的令牌桶，当它们的流量超过令牌桶时，超过的流量将被以尽力而为的数据发
送。
一个相关的问题是在所有的网络元素中，比网络元素的MTU大的数据报必须被认为是非
一致的，应该被当作尽力而为来分类(根据网络元素对于尽力而为服务的数据的处理或者分段
或者丢弃) ， [还有，假如标记是可行的，这些重分类的数据报应该被作上标签] 。
8排序和汇合
TSpec"s通过以下的规则来排序。
TSpecA是一个TSpecB代替值(等同或好于) ，假如满足(1)TSpecA的令牌速率r
和桶深b都大于或等于TSpecB的相应的值；(2)TSpecA的最高速率p至少有TSpecB
的p那么大。(3)TSpecA中的最小策略单元至少大于TSpecB中相应的值， (4)TSpecA
中的最大数据报M至少大于TSpecB中相应的值。
TSpecA等同或不如TSpecB ，假如满足(1)(1)TSpecA的令牌速率r和桶深b都小于或
等于TSpecB的相应的值；(2)TSpecA的最高速率p至多有TSpecB的p那么大。(3)TSpec
A中的最小策略单元至多大于TSpecB中相应的值， (4)TSpecA中的最大数据报M至多
大于TSpecB中相应的值。
一个汇合的TSpec可以通过以下的参数来计算， (1)最大令牌桶速率， (2)最大桶的大
小， (3)最大最高速率， (4)最小策略单元(5)在集合成员中的最小最大数据报大小。使用“汇
合”一词与在RSVP中的相似。一个汇合的TSpec是足够从TSpec的各个组成成分来描
述流量的TSpec 。
一个求和的TSpec可以通过对Tspecs的集合的计算得到：(1)令牌桶的速率的和,(2)
桶的大小的和,(3)最高速率的和， (4)最小策略单元， (5)最大数据报参数。
一个最小的普通TSpec对于描述任意一个流量集合中的流都是足够了的，一个最小
的普通TSpec对Tspecs的集合的计算得到：(1)最大令牌桶的速率,(2)最大桶的大小， (3)
最大最高速率， (4)最小策略单元， (5)在集合所有成员中的最大数据报大小。
在对Tspecs是否可以排序的判定上，两个Tspecs的最小值是不同的。假如其中一个
小于另一个。则它为最小者。否则通过比较在两个Tspecs中的相对值来决定最小者，并
选择(1)较小的令牌桶速率， (2)较大的令牌桶大小， (3)较小的最高速率,(4)较小的最小策
略单元， (5)较小的最大数据报大小。
Rspec以与Tspecs相似的方式处理。如通过在Rspecs集合中取最大速率R和最小疏
散S来汇合成一个Rspecs 。更精确的，假如在RspecsA中的保留服务速率R的值大于等
于在RspecsB中的值，并且RspecsA中的S小于等于RspecsB中的S的值， RspecsA
则可以代替RspecsB 。
每一个网络元素收到一个(TSpec,RSpec)形式的服务请求，而Rspec是(Rin,Sin)形式的，
网络元素处理这个请求并采取下面的两种处理方式之一：
a、它接受请求并以(Rout,Sout)形式返回一个新的Rspec 。
b、拒绝请求。
通过以下的延时约束条件来治理产生新的Rspec的处理规则：
Sout b/Rout Ctoti/Rout<=Sin b/Rin Ctoti/Rin,
在此Ctoti是错误词， C的累计和，包括所有的上行网络元素和当前网络元素， I 。换句
话说，这个网络元素消耗了(Sin-Sout)的疏散，并可用它来降低它的保留水平，假如上述不等
式满足的话，那么Rin和Rout必须满足以下约束条件：
r<=Rout<=Rin.
当有几个Rspec ，每一个以速率Rj(j=1,2…)在某个分离点汇合时， Rout为所有速率Rj中
的最大值，并且Sout为所有疏散词Sj中的最小值。
注重：以上描述的各种TSpec函数有那些希望混合Tspecs的应用程序来使用，然而，注
意到真正的保留是将TSpec和TSpec的速率R混合而决定的，这一点是很重要的。
因为保证保留需要TSpec和Rspec速率，对于在RSVP中的共享保留存在一些困难，特
别是在两个或两个以上的源流相汇处。在相汇点的上行流中，它希望降低TSpec和Rspec来
使用单个源流所需的带宽和缓冲区(实际上，假如发送方正在一条较低的链路上发送数据，这
也是必要的) 。
然而，设置Rspec的速率来获得一个非凡的延时界值(不仅仅是一个TSpec的函数) ，所以
改变Rspec的值有可能使的保留失效，无法适合接受方的延时要求。同时，不调整Rspec速
率意味着使用保证服务的共享RSVP保留有可能无效，无论何时某条非凡的链路上可用的带
宽小于接受方要求的速率， R,即使带宽支持一定数量的发送者使用链路，在这种情况下，以
RSVP来使用保证服务存在限制是一个公认的难题。
9实现者指南
本节讨论在无非凡情况时的一系列重要实现问题。
单个子网为网络元素且路由器和子网必须支持保证服务模型来获得保证服务，熟悉到这
一点是很重要的。由于子网不能使用基于IP的协议来协商服务，作为提供保证服务的一部分，
路由器不得不作为与它相连的子网的代理。
在有些情况下，这种代理服务是很简单的，如在一个由WFQ调度器治理的上行节点的租
用线上，代理仅仅需要保证所有的流的Rspec的速率之和不超过这条租用线上的带宽，和广
播以C和D值的形式的基于速率和非基于速率的链路延时。
在其他情况下，这种代理服务很复杂，如在一个ATM网络中，可能需要为某个流建立一
条ATMVC ，并计算这条虚拟通道的C和D值，有可能大家会注重到保证服务使用的令牌桶
和最高速率直接映射到ATM"的VBR流的Q.2931QoS参数的相同的信元、突发大小和最高信
元速率。
通过将路由器的缓冲区B设置为令牌桶的b和一些错误词之和，就能够获得书局报不会
丢失的保证。
另一个和子网相关的问题是TSpec令牌桶速率衡量IP流量，不是(也不能)计算链路水平
头。所以子网网络元素必须调整速率和桶大小来计算增加的链路水平头，通道也必须它们
增加的额外的IP头。
对于数据网络来说，通过将速率和桶大小除以最小策略单元来计算最大头速率。对于作
内部分段的网络而言，如ATM ，由于必须计算每一个分段和任何数据报大小和分段之间不符
而造成的浪费，使得计算更复杂，例如，通过ATMAAL5与ATM分割和重组而造成的额外
数据速率的保守估计为：
((r/48)*5) ((r/m)*(8 52))
这代表着速率为速率除以48字节的信元再乘以5字节的ATM头，再加上最大数据报速
率(r/m)乘以8个字节的AAL5头与ATM对于数据报分组而浪费的最大空间(在每一个信元包
含一个字节时为52个字节) ，但是这个估计可能很高，非凡假如m很小，而ATM的浪费通常
比52个字节小的多(ATM实现者应该注重到当设置VC参数时，令牌桶可能不得不缩放，且
这个例子并不计算由于象在RFC1483中指定的封装而造成的多余头) 。
为了保证无丢失，网络元素不得不为突发的数据流分配缓冲区，假如每一跳实现流模型
状况良好，缓冲区大小只要为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]、
VirtualClock[4]和IBM提议的一种配置，一种好的理论上表述表明这些配置是一大类算法的
一部分，这种理论可以在[6]中找到。
12使用例子
考虑到一个对于任何丢失或延迟的数据报不能容忍的应用程序，它使用Ctot和Dtot的
广播和流的TSpec值，来计算一个速率R的服务请求的延时界值。假设R为[(b-M)/R*(p-R)/(p-r)] (M Ctot)/R Dtot 。
13安全考虑
本备忘录讨论了这个服务这样滥用来进行拒绝服务攻击。这个服务不容许拒绝服务(虽然
在一定的条件下可能会降低)
附录1：用RSVP的保证服务的使用
和RSVP一起来使用保证服务在在参考[9]中指定。本文档给出了需要支持期望保证服务
的应用程序的RSVPFLOWSPEC,SENDER_TSPEC,和ADSPEC对象。RSVP协议本身在参
考[10]中有指定。
14参考文献
[1]Shenker,S.,andJ.Wroclawski,"NetworkElementService
SpecificationTemplate",RFC2216,September1997.
[2]A.Demers,S.KeshavandS.Shenker,"AnalysisandSimulationof
aFairQueueingAlgorithm,"inInternetworking:Researchand
EXPerience,Vol1,No.1.,pp.3-26.
[3]L.Zhang,"VirtualClock:ANewTrafficControlAlgorithmfor
PacketSwitchingNetworks,"inProc.ACMSIGCOMM"90,pp.19-29.
[4]D.Verma,H.Zhang,andD.Ferrari,"GuaranteeingDelayJitter
BoundsinPacketSwitchingNetworks,"inProc.Tricomm"91.
[5]L.Georgiadis,R.Guerin,V.Peris,andK.N.Sivarajan,
"EfficientNetworkQoSProvisioningBasedonperNodeTraffic
Shaping,"IBMResearchReportNo.RC-20064.
[6]P.Goyal,S.S.LamandH.M.Vin,"DeterminingEnd-to-EndDelay
BoundsinHeterogeneousNetworks,"inProc.5thIntl.Workshopon
NetworkandOperatingSystemSupportforDigitalAudioandVideo,
April1995.
[7]A.K.J.Parekh,AGeneralizedProcessorSharingApproachtoFlow
ControlinIntegratedServicesNetworks,MITLaboratoryfor
InformationandDecisionSystems,ReportLIDS-TH-2089,February1992.
[8]Shenker,S.,andJ.Wroclawski,"GeneralCharacterization
ParametersforIntegratedServiceNetworkElements",RFC2215,
September1997.
[9]Wroclawski,J.,"UseofRSVPwithIETFIntegratedServices",RFC
2210,September1997.
[10]Braden,R.,Ed.,et.al.,"ResourceReservationProtocol(RSVP)
-Version1FunctionalSpecification",RFC2205,September1997.
Authors"Addresses
ScottShenker
XeroxPARC
3333CoyoteHillRoad
PaloAlto,CA94304-1314
Phone:415-812-4840
Fax:415-812-4471
EMail:shenker@parc.xerox.com
CraigPartridge
BBN
2370AmherstSt
PaloAltoCA94306
EMail:craig@bbn.com
RochGuerin
IBMT.J.WatsonResearchCenter
YorktownHeights,NY10598
Phone:914-784-7038
Fax:914-784-6318
EMail:guerin@watson.ibm.com