rfc2212.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：廖正军（jerry.liao   [e-mail]）
译文发布时间：2001-8-7
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                        S. Shenker
Request for Comments: 2212                                        Xerox
Category: Standards Track                                  C. Partridge
                                                                    BBN
                                                              R. Guerin
                                                                    IBM
September 1997

保证服务质量的规范
(RFC——2212  Specification of Guaranteed Quality of Service)

本备忘录的状态
本文档详细讲述了一种Internet社区的标准协议，需要进一步进行讨论和建议以得到改
进。对于本协议的标准化状况请参照“互连网正式协议标准”(STD 1)的当前版本，本备忘录
的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (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网中都是有益的。
RFC 2119中对于在本文象"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT",   "SHOULD", "SHOULD NOT", "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, and Dtot。
注意：当需要用来计算端到端时延的每一跳错误术语由服务模型(见下面的输出信息)
输出时，需要用来采集每一跳的限制和让端到端的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的令牌桶和