RFC1633Internet 体系结构中的综合服务概述.docx
《RFC1633Internet 体系结构中的综合服务概述.docx》由会员分享，可在线阅读，更多相关《RFC1633Internet 体系结构中的综合服务概述.docx（36页珍藏版）》请在冰豆网上搜索。
RFC1633Internet体系结构中的综合服务概述
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
jonel_t（jonel_ttian_lj@）
译文发布时间：
2001-8-14
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。
NetworkWorkingGroupR.Braden
RequestforComments:
1633ISI
Category:
InformationalD.Clark
MIT
S.Shenker
XeroxPARC
June1994
Internet体系结构中的综合服务概述
（RFC1633——IntegratedServicesintheInternetArchitecture:
:
anOverview）
本备忘录的状态：
本备忘录提供关于Internet社区的信息。
它不指定任何一种形式的标准。
本备忘录的发布不受任何限制。
摘要
本备忘录讨论了提供综合服务的Internet架构和协议的一个提议性扩展，例如，同时
支持实时和非实时服务的IP。
这个扩展必须满足多种新应用不断增长的实时服务要求，包
括电信会议、远程研究会、电信科学及分布式仿真。
本备忘录是DaveClark,ScottShenker,LixiaZhang,DeborahEstrin,SugihJamin,John
Wroclawski,ShaiHerzog和BobBraden近期工作的直接成果，而且利用了很多其他人的工作。
目录
1.简介2
2.体系结构的元素3
2.1.综合服务模型3
2.2.参考实现框架5
3.综合服务模型7
3.1.服务质量需求8
3.2.资源共享需求和服务模型10
3.3.分组丢弃11
3.4.使用反馈11
3.5.预留模型11
4.通信量控制机制12
4.2.机制的应用14
4.3.一个例子：
CSZ模式14
5.预留设置协议15
5.1.RSVP概述15
5.2.路由选择与预留17
6.致谢18
参考文献：
18
安全考虑20
作者地址20
1.简介
通过Internet的IETF会议的多播是对在一个分组交换架构中传送数字化音频和视频
的一个大范围试验。
这些高度可视化的试验依赖于三个技术的支持。
（1）很多现代的工作站
都装有内置的多媒体硬件，包括音频codecs（多媒体数字信号编解码器）和视频
frame-grabbers，而且现在的视频设备也不贵。
（2）IP多播虽然在商业路由器中还没有得
到广泛应用，但在MBONE，一个临时性的“多播骨干网”中却得到了支持。
（3）已开发出高
度复杂的数字音频和视频应用程序。
这些试验也表明，还缺少一个重要的技术元素：
由于不断变化的排队延迟和拥塞丢失的
原因，实时应用在Internet中的表现经常不好。
在Internet最初的构想中，它仅提供一个
非常简单的服务质量，即点到点的尽力而为的数据传送。
在实时应用如远程视频，多媒体会
议，可视化和虚拟现实能够得到广泛使用前，Internet架构必须被修改，以支持为端到端
分组延迟提供某种控制的实时QoS。
这种扩展在开始时就应是为了多播而设计；简单地从单
播（点到点）推广是不行的。
实时QoS并不是下一代Internet中通信量管理的唯一问题。
要求网络经营者有能力对
不同的通信量类中的一个特定链接上的带宽共享进行控制。
他们应该能够把通信量分成几个
管理类，而且根据负载情况为每一个链接带宽指定一个最小百分比，同时还要允许在别的时
间有有效的“未用”带宽。
例如，这些类可能表示不同的用户组或不同的协议族。
这样一种
管理措施通常被叫做控制链路共享。
我们使用术语综合服务（IS）来表示一个包括尽力而为服
务、实时服务以及控制链路共享的Internet服务模型。
在过去几年中，综合服务的需求和机制是许多讨论和研究的主题（由于文献太多，即使
列出一个代表性的例子在这里也是太大了，作为一个不完全的列表可参见[CSZ92,Floyd92,
Jacobson91,JSCZ93,Partridge92,SCZ93,RSVP93a]）。
这一工作导致了支持本备忘录中
所描述的综合服务的统一方法。
我们相信现在是时候开始在Internet中综合服务的预先配
置工程了。
本备忘录第二部分介绍Internet的一个IS扩展的元素。
第三部分讨论实时服务模型
[SCZ93a,SCZ93b]。
第四部分讨论用于路由器的通信量控制、转发算法[CSZ92]。
第五部分讨
论RSVP，一个与我们所设想的IS模型兼容的资源设置协议的设计[RSVP93a,RSVP93b]。
2.体系结构的元素
Internet的基本服务模型，具体就是IP的尽力而为传输服务，自20年前开始Internet
研究工程以来就没有改变过[CerfKahn74]。
我们现在提议改变这个模型，以包含综合服务。
从学术的角度看，Internet服务模型的更改是一个大事业；但事实上我们我们只想扩展原
有的体系结构，从而减轻了它的影响。
新增的组件和机制将补充而不是替代基本IP服务。
理论上，被提议的体系结构扩展包含两个元素：
（1）一个扩展的服务模型，我们叫它
IS模型，和
（2）一个参考实现框架，它给我们一个实现IS模型的词汇表集和一个通用计划
组织。
把定义外部可见行为的服务模型跟实现的讨论分开是很重要的，因为具体实现在服务
模型的生命周期中可能（而且必将会）改变。
但是，这两者是有关系的；为使服务模型可信，
提供一个如何实现这个模型的实例是有用的。
2.1.综合服务模型
我们提议的IS模型为实时通信量提供两种类型的服务：
保证服务和可预测服务。
这个
模型把这些服务和控制链路共享整合在一起，而且被设计成对多播和单播都有效。
IS模型
概要推迟到第三部分中再讨论，我们首先讨论在模型后面的一些关键设想。
第一个设想是资源（如带宽）必须得到明确管理，以便达到应用程序的需求。
这意味着
“资源预留”和“接入控制”都是这种服务的关键构件。
另一种可选择的方法，试图在不对
Internet服务模型作出明确改变情况下支持实时通信量，我们把它否定了。
实时服务的本质就是对某些服务保证的需求，而且我们认为不作预留是无法实现这些保
证的。
术语“保证”在这里是一种广义的意思；即可以是绝对的或统计的，严格的或近似的。
但是，在一个用户决定的时间段内应用程序以一种可接受的方式运行情况下，用户应该能得
到一个质量可充分预测的服务。
其次，“充分”和“可接受”都是模糊的术语。
通常情况下，
更严格的保证对资源耗费更多，使得这些不能与其他应用共享。
下面的论点是在Internet中提出来反对资源保证的。
“带宽是无限的。
”
光纤不可思议的巨大的负载能力，使得有人断定带宽在将来是如此的充足、遍地都是而
且便宜，以至除了光速限制外将没有通信延迟，因此将不需要预留资源。
但是，我们相信这
在短期内是不可能的，在较长时期内也不太可能。
虽然物理带宽看来会不贵，但作为一种网
络服务而被提供的带宽不太可能变得如此便宜，以至浪费它们会是最划算的设计原则。
尽管
廉价的带宽在最后确实将普遍可用，但我们不能接受在Internet中会“无处不在”的可用。
除非我们能够提供处理拥塞链路的可能性，否则实时服务将只能被简单的排除在外了。
我们
发现那些限制是不可接受的。
“简单的分级就足够了”
在某些时间和某种条件下为实时通信量简单地分配一个更高的优先级是对的，这将为其
提供足够的实时服务。
但分级是一种实现机制，而不是一个服务模型。
如果我们根据一种特
定机制来定义模型，我们将不能得到我们想要的准确特性。
在简单分级情况下的问题是，一
旦有过多的实时流要求更高的优先级，则每一个流都被降级了。
将我们的模型限制在这个简
单的失败模型内是不能接受的。
在某种情况下，用户将要求在一些新的请求收到“忙信号”
是仍能成功传送某些流。
“应用可以适应”
适应性实时应用的发展，如Jacobson的音频程序VAT，并没有消除对发送分组传输时
间的要求。
人类对交互和可理解性的要求限制了网络延迟适应性的可能范围。
我们已经见过
在真实的试验里，尽管VAT可以适用网络延迟达数秒钟，但用户发现在这种情况下进行交互
是不可能的。
我们认为为了向特定的用户分组流提供特定的QoS，路由器具有资源预留的能力是一种
不可避免的需求。
这导致了在路由器中对特定流状态的需求，这是对Internet模型的一个
重要而且基本的改变。
Internet体系结构是在这样的思想下建成的，这种思想认为应将流
相关的状态留在终端系统中[Clark88]。
在这种思想基础上设计的TCP/IP协议包导致的健壮
性是Internet成功的关键之一。
在第五部分中我们讨论这种流状态是怎样加入路由器的而
用于资源预留的，为了保留Internet协议包的健壮性，这种状态必须做成“软性的”。
路由器中的资源预留有一个现实的副作用。
尽管它意味着一些用户可以获得优先服务，
但是资源预留需要强制实行策略和管理控制。
这因此而导致两种认证需求：
对谁提出预留请
求的用户认证，以及对使用这些预留资源的分组认证。
然而这些问题并不是“IS”独有的，
Internet发展过程中的其他方面，包括商业化和商业安全，都有同样的需求。
在本备忘录
中我们将不对这些问题作进一步的讨论，但它们是需要关注的。
我们提出的另一个设想就是有必要把Internet用作同时对非实时及实时通信的公共架
构。
人们也可以选择为实时服务建立一个新的、完整的并行架构，而不改变Internet。
我
们否定了这种方法，因为它将失去实时和非实时通信量统计共享的重要优势，而且它比建立
和管理一个公共架构更加复杂得多。
除了这个公共架构的设想，我们还采纳了一个统一的协议栈模型，对实时及实时服务使
用一个简单的网络层协议。
因此，我们提议为实时数据使用已有的网络层协议（如IP或
CLNP）。
另一个方法是在网络层增加一个新的实时协议[ST2-90]。
我们的统一栈方法提供经
济的机制，而且它允许我们很容易的把控制链路共享包括进来。
它也处理部分覆盖的问题，
例如，允许在有IS能力的Internet系统和那些没有扩展的系统之间的交互，而没有通道的
复杂性。
我们认为Internet应该有一个简单的服务模型。
如果在Internet的不同地方有不同的
服务模型，将很难知道任何的端到端服务质量声明是如何实现的。
然而，一个简单的服务模
型并不意味着就需要一个分组调度或接入控制的简单实现。
尽管已开发出满足我们服务模型
的特定分组调度或接入控制机制，但很可能还会有其它的机制满足这个服务模型。
后面介绍
的参考实现框架，允许在没有一个简单设计情况下讨论有关实现的问题。
基于上述考虑，我们相信为了提供必要的服务，一个包括在路由器中增加流状态以及一
个明确的设置机制的IS扩展是必要的。
一个不考虑这点的不完备解决方案将是一次不明智
的投资。
我们相信我们提议的扩展保持了Internet架构的基本健壮性和效率，而且允许对
网络资源进行有效的管理；这将是重要的目标，尽管带宽将变得非常便宜。
2.2.参考实现框架
我们提议一个实现这个IS模型的参考实现框架。
这个框架包括四个组件：
分组调度、
接入控制程序、分类器和预留设置协议。
在后面先作简单的讨论，在第四和第五部分中将作
进一步讨论。
在接下来的讨论中，我们定义来自单一用户活动而且有相同QoS需求的数据报的相应可
识别数据流为抽象的“流”。
例如，一个流可能包含一个传输链接或一个给定主机对之间的
视频流。
这是IS能识别的最好分组流粒度。
我们定义一个流应是单一的，例如，它具有一
个单一的原端和N个目的端。
因此，一个N方的电视会议一般需要N个流，每个站点产生一
个。
在今天的Internet中，IP转发是完全的平均主义；所有的分组都获得相同的服务质量，
而且分组一般都是按一个严格的FIFO排队原则进行转发。
对于综合服务，路由器必须根服
务模型为每一个流实现合适的QoS。
路由器创建不同服务质量的功能称为“通信量控制”。
相应的通信量控制由三个组件实现：
分组调度器，分类器以及接入控制。
分组调度器
分组调度器使用多个队列及其它可能的机制如计时器来管理不同分组流的转发。
分组调
度器必须根据分组在何处排队的思想来实现；这是在一个典型操作系统的输出驱动器层次，
而且符合数据链路层协议。
调度算法的细节可能与特定的输出介质有关。
例如，输出驱动器
在面对具有内部带宽分配机制的网络技术时需要激发合适的链路层控制。
在第三部分和[SCZ93]中描述了为实现这个IS模型而建立的一个实验性分组调度器；
这个调度器被称为CSZ调度器，在第四部分中将对其作进一步讨论。
应该注意为完成我们的
服务模型并不强制要求这个CSZ模式；大家知道一部分网络实际上是未满载的，FIFO就可
以传送满意的服务。
另外一个组件可以认为是分组调度器的部件，也可认为是单独的组件：
评估器
[Jacobson91]。
这个算法被用来衡量输出数据流的性质，以显示控制分组调度和接入控制的
统计信息。
本备忘录将评估器作为分组调度器的一个部件。
分类器
为了便于通信量控制（和计费），必须把每个输入分组映射到某个类；分组调度器对同
一类的所有分组给予相同的处理。
这种映射由分类器来执行。
类的选择可能基于已知分组头
的内容和/或某些加入每个分组的类别号码。
一个类可以与很多类型的流相关，例如，所有的视频流或所有来自某一特定组织的流。
另一方面，一个类仅只一个单一的流。
一个类可能只是某个特定路由器的抽象概念；相同的
分组在通路上的不同路由器中可能被划为不同的类。
例如，骨干网路由器可能选择把很多流
映射在少数几个汇聚类中，而靠近外围的路由器，由于汇聚流要少得多，可能为每一个流使
用一个单独的类。
接入控制
接入控制实现决定算法，路由器或主机用这个算法来决定在不影响原来保证的条件下是
否同意一个新流的QoS请求。
在一个主机请求通过Internet的某些通路的实时服务时，接
入控制在每一个节点中都被激活，以作出一个本地的接受/拒绝决定。
接入控制算法必须与
服务模型一致，而且它在逻辑上是通信量控制的一部分。
尽管接入控制仍然存在着开放研究
问题，一个优先的切入点已经有了[JCSZ92]。
接入控制有时会与策略或实施混淆在一起，策略与实施是网络中“边”上的每一分组功
能，以确保主机不能违反它答应的通信量特征。
我们认为策略是分组调度器的一项功能。
除了确保达到QoS保证的要求，接入控制还将参与资源预留管理策略的实施。
某些策略
会对那些预留请求要求认证。
最后接入控制还将在计费和管理报告中起重要作用。
我们实现框架的第四个也是最后一个组件是预留设置协议，它在终端主机和流所经过路
径上的路由器中创建和维护特定流的状态是必要的。
第五部分讨论了一个称为RSVP（预留
协议）的预留设置协议[RSVP93a,RSVP93b]。
在Internet中坚持只有一种预留协议将会是不
可能的，但我们认为预留协议的多种选择会导致混乱。
我们相信多种协议只有在支持不同的
预留模型是才会存在。
对服务模型的链路共享部分的设置需求远没有对资源预留的设置需求清楚。
尽管我们期
待大多数这方面的问题可以通过网络管理接口来解决，而且因此而不必把RSVP作为整体架
构的一部分，但我们也可能需要RSVP在提供需求状态能起作用。
为了声明其资源需求，应用必须用一个称为“流规约”的参数列表来指定想得到的
QoS[Partridge92]。
流规约由预留设置协议发送，传给接入控制以测试其可接受性，最终被
用来确定分组调度机制的参数。
图1展示了这些组件是怎样装进一个IP路由器中的，该路由器已经被扩展以提供综合
服务。
这个路由器具有两个主要的功能：
在双向水平线下的路径转发，已及在水平线上的后
台代码。
由于路由器必须为每个分组执行路径转发，因此必须将其高度优化。
事实上，在大多数
商业路由器中，它的实现还包括硬件支持。
路径转发被分成三个部分：
输入驱动器、网络转
发器和输出驱动器。
网络转发器解释相应协议包的网络协议头，如TCP/IP的IP头,或OSI
的CLNP头。
网络转发器为每一个分组执行一个包相关的分类器，然后把该分组及它的类传
给合适的输出驱动器。
分类器必须全面而有效。
为提高效率，应为资源分类和路由查找采用
一个公共机制。
输出驱动器实现了分组调度器。
（分层主义者会注意到输出驱动器现在有两个不同的部
分：
与具体机制高度无关的分组调度器，以及只关心硬件细部分的实际I/O驱动。
评估器置
于两者之间某处。
我们只是注意到这个事实，并不意味着将其提升为一个原则）。
_____________________________________________________________
|___________________________________|
||||||||
||路由代理||预留设置||管理代理||
||||代理||||
||______._____||______._____||_____._____||
|..|.|
|.._V________.|
|..||.|
|..|接入控制|.|
|V.|__________|.|
||
|[路由数据库][通信量控制数据库]|
|=============================================================|
|||_______|
||__________||_|_|_|_|=>o|
|||||分组|_____|
|====>|分类器|=====>调度器|===>|_|_|_|===>
|||__________||_______||
||||_|_|_|_|=>o|
|输出|Internet||
|驱动|转发器|输出驱动器|
|________|__________________|_________________________________|
图1:
路由器参考实现模型
后台代码被简单的装入路由器的内存中，而且由一个通用CPU执行。
这些后台的程序创
建控制路径转发的数据结构。
路由代理实现一个特定的路由协议，而且建立一个路由数据库。
路由设置协议实现这个协议以建立资源预留，见第五部分。
如果接入控制同意一个新的请求，
分类器和分组调度器数据库会作出相应的改变以实现要求的QoS。
最后，每个路由器都支持
网络管理代理。
这个代理必须能够修改分类器和分组调度器数据库以设置控制链路共享以及
设置接入控制策略。
主机的实现框架基本上与路由器的相似，只是多了一些应用程序。
主机应用程序产生和
接收数据，而不是转发数据。
应用程序的一个流在需要实施QoS时必须激活一个本地预留设
置代理。
应用程序接口的最佳方法还有待决定。
例如，可能存在一个明确的网络资源设置
API，也可能设置只是作为操作系统调度功能的一部分被不明确的激活。
主机的IP输出路径
可能不需要分类器，因此分组的类分配可以由相应流的本地I/O控制结构来指定。
在路由器中，综合服务改变路径转发以及后台功能。
对取决于硬件加速性能的路径转发
的改变将会是更困难和更昂贵的。
为大量不同的策略需求和未来环境选择一个通用而且能修
改的通信量控制机制集将是最重要的，以达到高效的实现。
3.综合服务模型
应用程序激活置入网络服务接口的服务模型来定义它们可以请求的服务集。
尽管下层网
络技术和上层应用包将会发展，但对这种服务接口兼容性需求的要求会是相对稳定的（或者，
更准确的说是扩展的；我们确实希望在将来增加新服务，但我们也希望改变现有服务是困难
的）。
由于其持续性的影响，所以应在基本服务需求的基础上而不是参考任何特定网络来设
计服务模型。
我们现在简单的描叙一个Internet核心服务集的提案；所提议的这个核心服务模型的更完
全描叙见[SCZ93a,SCZ93b]。
该核心服务模型提出了那些与分组传输时间有最直接关系的服
务。
我们把其他的服务（如路由选择、安全或流同步）留给别的标准化组织。
一个服务模型
包含一个服务承诺集；网络对相应的服务请求承诺某种传送服务。
这些服务承诺可以根据提
出请求的实体而划分为：
单个流实体或集合实体（流类）。
对单个流作出的服务承诺的目标
是提供合理的应用性能，因此而被应用的环境改造需求所驱动；这些与服务质量有关的服务
承诺被传送给一个单一的流。
对集合实体作出的服务承诺被资源共享或经济、需求所驱动；
这些与汇聚资源有关的服务承诺对多种实体有效。
在本部分中我们先探讨单个流的服务需求，并且提议一个相应的服务集。
然后，我们讨论服
务需求和资源共享服务。
最后，我们总结一些关于分组丢弃的评论。
3.1.服务质量需求
核心服务模型主要关注分组传输时间。
每一分组延迟是网络所作出的服务质量承诺中的
主要指标。
我们提出更严格的假设，就是我们作出的量化服务承诺的唯一指标就是延迟的最
大值和最小值。
应用性能依赖低延迟服务的程度变化很大，我们可以根据其依赖程度而将应用定性的分成几
个级别。
有一类应用在确定的时间内需要每一分组的数据，如果数据到时不能到达，则这些
数据就完全没用了；我们称这类应用为实时应用。
另外一类应用总是会等待数据的到达；我
们称其为“弹性”应用。
我们现在分别地考虑这两个类的延迟需求。
3.1.1.实时应用
这种实时应用的一个重要的类，“回放”应用，将是我们在后面的讨论中明确考虑的唯
一实时应用。
在一个回放应用中，原端取得一些信号，将其分组然后将这些分组通过网络传
输。
网络不可避免的对这些传送分组引入了某种延迟变化。
接收方将这些数据分组解开，然
后试图忠实的还原这些信号。
这是通过缓冲输入数据然后根据原发送时间的某个固定延迟偏
移来还原信号；术语“回放点”是指原发送时间的固定延迟偏移时间点。
任何在其回放点之
前到达的数据都可以被用来重构这个信号；在回放点之后到达的数据对于重构实时数据来说
根本没有了。
为了给延迟偏移选择一个合理的值，应用需要某种指定其分组可承受的最大延迟的“先
验”特性。
这种“先验”特性可能是网络提供的对延迟范围的一种量化服务承诺；也可能是
通过观察已经到达分组而得到的延迟经验值；应用需要知道它期望的是何种延迟，但这种期
望值不需要在流的整个持续时间内都保持恒定。
一个回放应用的性能可由两种不同的尺度来衡量：
反应时间和可信度。
某些回放应用，
特别是那些在链接两端包括交互的应用，如电话呼叫，
升级会员 