组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：jonel_t（jonel_t&nbsp;&nbsp;&nbsp;&nbsp;tian_lj@china.com）<br />
译文发布时间：2001-8-14<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<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;R.&nbsp;Braden<br />
Request&nbsp;for&nbsp;Comments:&nbsp;1633&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISI<br />
Category:&nbsp;Informational&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D.&nbsp;Clark<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;MIT<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;S.&nbsp;Shenker<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;Xerox&nbsp;PARC<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;June&nbsp;1994<br />
<br />
<br />
<br />
Internet&nbsp;体系结构中的综合服务概述<br />
（RFC1633——Integrated&nbsp;Services&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Architecture:&nbsp;:&nbsp;an&nbsp;Overview）<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;<br />
本备忘录的状态：<br />
本备忘录提供关于Internet社区的信息。它不指定任何一种形式的标准。<br />
本备忘录的发布不受任何限制。<br />
<br />
摘要<br />
本备忘录讨论了提供综合服务的Internet架构和协议的一个提议性扩展，例如，同时<br />
支持实时和非实时服务的IP。这个扩展必须满足多种新应用不断增长的实时服务要求，包<br />
括电信会议、远程研究会、电信科学及分布式仿真。<br />
本备忘录是Dave&nbsp;Clark,Scott&nbsp;Shenker,&nbsp;Lixia&nbsp;Zhang,&nbsp;Deborah&nbsp;Estrin,&nbsp;Sugih&nbsp;Jamin,&nbsp;John&nbsp;<br />
Wroclawski,&nbsp;Shai&nbsp;Herzog和Bob&nbsp;Braden近期工作的直接成果，而且利用了很多其他人的工作。<br />
<br />
<br />
<br />
目&nbsp;&nbsp;录<br />
1.简介	2<br />
2.&nbsp;体系结构的元素	3<br />
2.1.&nbsp;综合服务模型	3<br />
2.2.参考实现框架	5<br />
3.&nbsp;综合服务模型	7<br />
3.1.&nbsp;服务质量需求	8<br />
3.2.&nbsp;资源共享需求和服务模型	10<br />
3.3.&nbsp;分组丢弃	11<br />
3.4.&nbsp;使用反馈	11<br />
3.5.&nbsp;预留模型	11<br />
4.&nbsp;通信量控制机制	12<br />
4.2.机制的应用	14<br />
4.3.&nbsp;一个例子：CSZ模式	14<br />
5.&nbsp;预留设置协议	15<br />
5.1.RSVP&nbsp;概述	15<br />
5.2.&nbsp;路由选择与预留	17<br />
6.&nbsp;致谢	18<br />
参考文献：	18<br />
安全考虑	20<br />
作者地址	20<br />
<br />
1.简介<br />
&nbsp;&nbsp;&nbsp;&nbsp;通过Internet&nbsp;的IETF会议的多播是对在一个分组交换架构中传送数字化音频和视频<br />
的一个大范围试验。这些高度可视化的试验依赖于三个技术的支持。（1）很多现代的工作站<br />
都装有内置的多媒体硬件，包括音频codecs（多媒体数字信号编解码器）和视频<br />
frame-grabbers，而且现在的视频设备也不贵。(2)&nbsp;IP多播虽然在商业路由器中还没有得<br />
到广泛应用，但在MBONE，一个临时性的“多播骨干网”中却得到了支持。（3）已开发出高<br />
度复杂的数字音频和视频应用程序。<br />
&nbsp;&nbsp;&nbsp;&nbsp;这些试验也表明，还缺少一个重要的技术元素：由于不断变化的排队延迟和拥塞丢失的<br />
原因，实时应用在Internet中的表现经常不好。在Internet最初的构想中，它仅提供一个<br />
非常简单的服务质量，即点到点的尽力而为的数据传送。在实时应用如远程视频，多媒体会<br />
议，可视化和虚拟现实能够得到广泛使用前，Internet架构必须被修改，以支持为端到端<br />
分组延迟提供某种控制的实时QoS。这种扩展在开始时就应是为了多播而设计；简单地从单<br />
播（点到点）推广是不行的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;实时QoS并不是下一代Internet中通信量管理的唯一问题。要求网络经营者有能力对<br />
不同的通信量类中的一个特定链接上的带宽共享进行控制。他们应该能够把通信量分成几个<br />
管理类，而且根据负载情况为每一个链接带宽指定一个最小百分比，同时还要允许在别的时<br />
间有有效的“未用”带宽。例如，这些类可能表示不同的用户组或不同的协议族。这样一种<br />
管理措施通常被叫做控制链路共享。我们使用术语综合服务(IS)来表示一个包括尽力而为服<br />
务、实时服务以及控制链路共享的Internet服务模型。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在过去几年中，综合服务的需求和机制是许多讨论和研究的主题（由于文献太多，即使<br />
列出一个代表性的例子在这里也是太大了，作为一个不完全的列表可参见[CSZ92,&nbsp;Floyd92,&nbsp;<br />
Jacobson91,&nbsp;JSCZ93,&nbsp;Partridge92,&nbsp;SCZ93,&nbsp;RSVP93a]）。这一工作导致了支持本备忘录中<br />
所描述的综合服务的统一方法。我们相信现在是时候开始在Internet中综合服务的预先配<br />
置工程了。<br />
&nbsp;&nbsp;&nbsp;&nbsp;本备忘录第二部分介绍Internet的一个IS扩展的元素。第三部分讨论实时服务模型<br />
[SCZ93a,SCZ93b]。第四部分讨论用于路由器的通信量控制、转发算法[CSZ92]。第五部分讨<br />
论RSVP，一个与我们所设想的IS模型兼容的资源设置协议的设计[RSVP93a,&nbsp;RSVP93b]。<br />
<br />
2.&nbsp;体系结构的元素&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;Internet的基本服务模型，具体就是IP的尽力而为传输服务，自20年前开始Internet<br />
研究工程以来就没有改变过[CerfKahn74]。我们现在提议改变这个模型，以包含综合服务。<br />
从学术的角度看，Internet服务模型的更改是一个大事业；但事实上我们我们只想扩展原<br />
有的体系结构，从而减轻了它的影响。新增的组件和机制将补充而不是替代基本IP服务。<br />
&nbsp;&nbsp;&nbsp;&nbsp;理论上，被提议的体系结构扩展包含两个元素：（1）一个扩展的服务模型，我们叫它<br />
IS模型，和(2)一个参考实现框架，它给我们一个实现IS模型的词汇表集和一个通用计划<br />
组织。把定义外部可见行为的服务模型跟实现的讨论分开是很重要的，因为具体实现在服务<br />
模型的生命周期中可能（而且必将会）改变。但是，这两者是有关系的；为使服务模型可信，<br />
提供一个如何实现这个模型的实例是有用的。<br />
&nbsp;&nbsp;&nbsp;<br />
2.1.&nbsp;综合服务模型<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们提议的IS模型为实时通信量提供两种类型的服务：保证服务和可预测服务。这个<br />
模型把这些服务和控制链路共享整合在一起，而且被设计成对多播和单播都有效。IS模型<br />
概要推迟到第三部分中再讨论，我们首先讨论在模型后面的一些关键设想。<br />
&nbsp;&nbsp;&nbsp;&nbsp;第一个设想是资源（如带宽）必须得到明确管理，以便达到应用程序的需求。这意味着<br />
“资源预留”和“接入控制”都是这种服务的关键构件。另一种可选择的方法，试图在不对<br />
Internet服务模型作出明确改变情况下支持实时通信量，我们把它否定了。<br />
&nbsp;&nbsp;&nbsp;&nbsp;实时服务的本质就是对某些服务保证的需求，而且我们认为不作预留是无法实现这些保<br />
证的。术语“保证”在这里是一种广义的意思；即可以是绝对的或统计的，严格的或近似的。<br />
但是，在一个用户决定的时间段内应用程序以一种可接受的方式运行情况下，用户应该能得<br />
到一个质量可充分预测的服务。其次，“充分”和“可接受”都是模糊的术语。通常情况下，<br />
更严格的保证对资源耗费更多，使得这些不能与其他应用共享。<br />
&nbsp;&nbsp;&nbsp;&nbsp;下面的论点是在Internet中提出来反对资源保证的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;“带宽是无限的。”<br />
&nbsp;&nbsp;&nbsp;&nbsp;光纤不可思议的巨大的负载能力，使得有人断定带宽在将来是如此的充足、遍地都是而<br />
且便宜，以至除了光速限制外将没有通信延迟，因此将不需要预留资源。但是，我们相信这<br />
在短期内是不可能的，在较长时期内也不太可能。虽然物理带宽看来会不贵，但作为一种网<br />
络服务而被提供的带宽不太可能变得如此便宜，以至浪费它们会是最划算的设计原则。尽管<br />
廉价的带宽在最后确实将普遍可用，但我们不能接受在Internet中会“无处不在”的可用。<br />
除非我们能够提供处理拥塞链路的可能性，否则实时服务将只能被简单的排除在外了。我们<br />
发现那些限制是不可接受的。<br />
&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;“简单的分级就足够了”<br />
&nbsp;&nbsp;&nbsp;&nbsp;在某些时间和某种条件下为实时通信量简单地分配一个更高的优先级是对的，这将为其<br />
提供足够的实时服务。但分级是一种实现机制，而不是一个服务模型。如果我们根据一种特<br />
定机制来定义模型，我们将不能得到我们想要的准确特性。在简单分级情况下的问题是，一<br />
旦有过多的实时流要求更高的优先级，则每一个流都被降级了。将我们的模型限制在这个简<br />
单的失败模型内是不能接受的。在某种情况下，用户将要求在一些新的请求收到“忙信号”<br />
是仍能成功传送某些流。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;“应用可以适应”<br />
&nbsp;&nbsp;&nbsp;&nbsp;适应性实时应用的发展，如Jacobson的音频程序VAT，并没有消除对发送分组传输时<br />
间的要求。人类对交互和可理解性的要求限制了网络延迟适应性的可能范围。我们已经见过<br />
在真实的试验里，尽管VAT可以适用网络延迟达数秒钟，但用户发现在这种情况下进行交互<br />
是不可能的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们认为为了向特定的用户分组流提供特定的QoS，路由器具有资源预留的能力是一种<br />
不可避免的需求。这导致了在路由器中对特定流状态的需求，这是对Internet模型的一个<br />
重要而且基本的改变。Internet体系结构是在这样的思想下建成的，这种思想认为应将流<br />
相关的状态留在终端系统中[Clark88]。在这种思想基础上设计的TCP/IP协议包导致的健壮<br />
性是Internet成功的关键之一。在第五部分中我们讨论这种流状态是怎样加入路由器的而<br />
用于资源预留的，为了保留Internet协议包的健壮性，这种状态必须做成“软性的”。<br />
&nbsp;&nbsp;&nbsp;&nbsp;路由器中的资源预留有一个现实的副作用。尽管它意味着一些用户可以获得优先服务，<br />
但是资源预留需要强制实行策略和管理控制。这因此而导致两种认证需求：对谁提出预留请<br />
求的用户认证，以及对使用这些预留资源的分组认证。然而这些问题并不是“IS”独有的，<br />
Internet发展过程中的其他方面，包括商业化和商业安全，都有同样的需求。在本备忘录<br />
中我们将不对这些问题作进一步的讨论，但它们是需要关注的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们提出的另一个设想就是有必要把Internet用作同时对非实时及实时通信的公共架<br />
构。人们也可以选择为实时服务建立一个新的、完整的并行架构，而不改变Internet。我<br />
们否定了这种方法，因为它将失去实时和非实时通信量统计共享的重要优势，而且它比建立<br />
和管理一个公共架构更加复杂得多。<br />
&nbsp;&nbsp;&nbsp;&nbsp;除了这个公共架构的设想，我们还采纳了一个统一的协议栈模型，对实时及实时服务使<br />
用一个简单的网络层协议。因此，我们提议为实时数据使用已有的网络层协议（如IP或<br />
CLNP）。另一个方法是在网络层增加一个新的实时协议[ST2-90]。我们的统一栈方法提供经<br />
济的机制，而且它允许我们很容易的把控制链路共享包括进来。它也处理部分覆盖的问题，<br />
例如，允许在有IS能力的Internet系统和那些没有扩展的系统之间的交互，而没有通道的<br />
复杂性。<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们认为Internet应该有一个简单的服务模型。如果在Internet的不同地方有不同的<br />
服务模型，将很难知道任何的端到端服务质量声明是如何实现的。然而，一个简单的服务模<br />
型并不意味着就需要一个分组调度或接入控制的简单实现。尽管已开发出满足我们服务模型<br />
的特定分组调度或接入控制机制，但很可能还会有其它的机制满足这个服务模型。后面介绍<br />
的参考实现框架，允许在没有一个简单设计情况下讨论有关实现的问题。<br />
&nbsp;&nbsp;&nbsp;&nbsp;基于上述考虑，我们相信为了提供必要的服务，一个包括在路由器中增加流状态以及一<br />
个明确的设置机制的IS扩展是必要的。一个不考虑这点的不完备解决方案将是一次不明智<br />
的投资。我们相信我们提议的扩展保持了Internet架构的基本健壮性和效率，而且允许对<br />
网络资源进行有效的管理；这将是重要的目标，尽管带宽将变得非常便宜。&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
2.2.参考实现框架<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们提议一个实现这个IS模型的参考实现框架。这个框架包括四个组件：分组调度、<br />
接入控制程序、分类器和预留设置协议。在后面先作简单的讨论，在第四和第五部分中将作<br />
进一步讨论。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在接下来的讨论中，我们定义来自单一用户活动而且有相同QoS需求的数据报的相应可<br />
识别数据流为抽象的“流”。例如，一个流可能包含一个传输链接或一个给定主机对之间的<br />
视频流。这是IS能识别的最好分组流粒度。我们定义一个流应是单一的，例如，它具有一<br />
个单一的原端和N个目的端。因此，一个N方的电视会议一般需要N个流，每个站点产生一<br />
个。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在今天的Internet中，IP转发是完全的平均主义；所有的分组都获得相同的服务质量，<br />
而且分组一般都是按一个严格的FIFO排队原则进行转发。对于综合服务，路由器必须根服<br />
务模型为每一个流实现合适的QoS。路由器创建不同服务质量的功能称为“通信量控制”。<br />
相应的通信量控制由三个组件实现：分组调度器，分类器以及接入控制。<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
分组调度器<br />
&nbsp;&nbsp;&nbsp;&nbsp;分组调度器使用多个队列及其它可能的机制如计时器来管理不同分组流的转发。分组调<br />
度器必须根据分组在何处排队的思想来实现；这是在一个典型操作系统的输出驱动器层次，<br />
而且符合数据链路层协议。调度算法的细节可能与特定的输出介质有关。例如，输出驱动器<br />
在面对具有内部带宽分配机制的网络技术时需要激发合适的链路层控制。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在第三部分和[SCZ93]中描述了为实现这个IS模型而建立的一个实验性分组调度器；<br />
这个调度器被称为CSZ调度器，在第四部分中将对其作进一步讨论。应该注意为完成我们的<br />
服务模型并不强制要求这个CSZ模式；大家知道一部分网络实际上是未满载的，FIFO就可<br />
以传送满意的服务。<br />
&nbsp;&nbsp;&nbsp;&nbsp;另外一个组件可以认为是分组调度器的部件，也可认为是单独的组件：评估器<br />
[Jacobson91]。这个算法被用来衡量输出数据流的性质，以显示控制分组调度和接入控制的<br />
统计信息。本备忘录将评估器作为分组调度器的一个部件。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
分类器<br />
&nbsp;&nbsp;&nbsp;&nbsp;为了便于通信量控制（和计费），必须把每个输入分组映射到某个类；分组调度器对同<br />
一类的所有分组给予相同的处理。这种映射由分类器来执行。类的选择可能基于已知分组头<br />
的内容和/或某些加入每个分组的类别号码。<br />
&nbsp;&nbsp;&nbsp;&nbsp;一个类可以与很多类型的流相关，例如，所有的视频流或所有来自某一特定组织的流。<br />
另一方面，一个类仅只一个单一的流。一个类可能只是某个特定路由器的抽象概念；相同的<br />
分组在通路上的不同路由器中可能被划为不同的类。例如，骨干网路由器可能选择把很多流<br />
映射在少数几个汇聚类中，而靠近外围的路由器，由于汇聚流要少得多，可能为每一个流使<br />
用一个单独的类。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
接入控制<br />
&nbsp;&nbsp;&nbsp;&nbsp;接入控制实现决定算法，路由器或主机用这个算法来决定在不影响原来保证的条件下是<br />
否同意一个新流的QoS请求。在一个主机请求通过Internet的某些通路的实时服务时，接<br />
入控制在每一个节点中都被激活，以作出一个本地的接受/拒绝决定。接入控制算法必须与<br />
服务模型一致，而且它在逻辑上是通信量控制的一部分。尽管接入控制仍然存在着开放研究<br />
问题，一个优先的切入点已经有了[JCSZ92]。<br />
&nbsp;&nbsp;&nbsp;&nbsp;接入控制有时会与策略或实施混淆在一起，策略与实施是网络中“边”上的每一分组功<br />
能，以确保主机不能违反它答应的通信量特征。我们认为策略是分组调度器的一项功能。<br />
&nbsp;&nbsp;&nbsp;&nbsp;除了确保达到QoS保证的要求，接入控制还将参与资源预留管理策略的实施。某些策略<br />
会对那些预留请求要求认证。最后接入控制还将在计费和管理报告中起重要作用。<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们实现框架的第四个也是最后一个组件是预留设置协议，它在终端主机和流所经过路<br />
径上的路由器中创建和维护特定流的状态是必要的。第五部分讨论了一个称为RSVP（预留<br />
协议）的预留设置协议[RSVP93a,RSVP93b]。在Internet中坚持只有一种预留协议将会是不<br />
可能的，但我们认为预留协议的多种选择会导致混乱。我们相信多种协议只有在支持不同的<br />
预留模型是才会存在。<br />
&nbsp;&nbsp;&nbsp;&nbsp;对服务模型的链路共享部分的设置需求远没有对资源预留的设置需求清楚。尽管我们期<br />
待大多数这方面的问题可以通过网络管理接口来解决，而且因此而不必把RSVP作为整体架<br />
构的一部分，但我们也可能需要RSVP在提供需求状态能起作用。<br />
&nbsp;&nbsp;&nbsp;&nbsp;为了声明其资源需求，应用必须用一个称为“流规约”的参数列表来指定想得到的<br />
QoS[Partridge92]。流规约由预留设置协议发送，传给接入控制以测试其可接受性，最终被<br />
用来确定分组调度机制的参数。<br />
&nbsp;&nbsp;&nbsp;&nbsp;图1展示了这些组件是怎样装进一个IP路由器中的，该路由器已经被扩展以提供综合<br />
服务。这个路由器具有两个主要的功能：在双向水平线下的路径转发，已及在水平线上的后<br />
台代码。<br />
&nbsp;&nbsp;&nbsp;&nbsp;由于路由器必须为每个分组执行路径转发，因此必须将其高度优化。事实上，在大多数<br />
商业路由器中，它的实现还包括硬件支持。路径转发被分成三个部分：输入驱动器、网络转<br />
发器和输出驱动器。网络转发器解释相应协议包的网络协议头，如TCP/IP的IP头,或OSI<br />
的CLNP头。网络转发器为每一个分组执行一个包相关的分类器，然后把该分组及它的类传<br />
给合适的输出驱动器。分类器必须全面而有效。为提高效率，应为资源分类和路由查找采用<br />
一个公共机制。<br />
&nbsp;&nbsp;&nbsp;&nbsp;输出驱动器实现了分组调度器。（分层主义者会注意到输出驱动器现在有两个不同的部<br />
分：与具体机制高度无关的分组调度器，以及只关心硬件细部分的实际I/O驱动。评估器置<br />
于两者之间某处。我们只是注意到这个事实，并不意味着将其提升为一个原则）。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_____________________________________________________________<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;|<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;|<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;|<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;|<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;|<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;|<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;_V________&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<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;|<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;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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 />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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 />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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 />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|=============================================================|<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;|<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;=&gt;&nbsp;o&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<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;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;====&gt;&nbsp;|&nbsp;&nbsp;分类器&nbsp;&nbsp;|&nbsp;=====&gt;&nbsp;&nbsp;&nbsp;调&nbsp;度&nbsp;器&nbsp;&nbsp;&nbsp;&nbsp;|===&gt;|_|_|_|&nbsp;===&gt;<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;|<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;=&gt;&nbsp;o&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;输&nbsp;出&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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 />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;驱&nbsp;动&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;转&nbsp;&nbsp;发&nbsp;&nbsp;器&nbsp;&nbsp;&nbsp;&nbsp;&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 />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|________|__________________|_________________________________|<br />
<br />
图1:&nbsp;路由器参考实现模型<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;后台代码被简单的装入路由器的内存中，而且由一个通用CPU执行。这些后台的程序创<br />
建控制路径转发的数据结构。路由代理实现一个特定的路由协议，而且建立一个路由数据库。<br />
路由设置协议实现这个协议以建立资源预留，见第五部分。如果接入控制同意一个新的请求，<br />
分类器和分组调度器数据库会作出相应的改变以实现要求的QoS。最后，每个路由器都支持<br />
网络管理代理。这个代理必须能够修改分类器和分组调度器数据库以设置控制链路共享以及<br />
设置接入控制策略。<br />
&nbsp;&nbsp;&nbsp;&nbsp;主机的实现框架基本上与路由器的相似，只是多了一些应用程序。主机应用程序产生和<br />
接收数据，而不是转发数据。应用程序的一个流在需要实施QoS时必须激活一个本地预留设<br />
置代理。应用程序接口的最佳方法还有待决定。例如，可能存在一个明确的网络资源设置<br />
API，也可能设置只是作为操作系统调度功能的一部分被不明确的激活。主机的IP输出路径<br />
可能不需要分类器，因此分组的类分配可以由相应流的本地I/O控制结构来指定。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在路由器中，综合服务改变路径转发以及后台功能。对取决于硬件加速性能的路径转发<br />
的改变将会是更困难和更昂贵的。为大量不同的策略需求和未来环境选择一个通用而且能修<br />
改的通信量控制机制集将是最重要的，以达到高效的实现。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
3.&nbsp;综合服务模型<br />
&nbsp;&nbsp;&nbsp;&nbsp;应用程序激活置入网络服务接口的服务模型来定义它们可以请求的服务集。尽管下层网<br />
络技术和上层应用包将会发展，但对这种服务接口兼容性需求的要求会是相对稳定的（或者，<br />
更准确的说是扩展的；我们确实希望在将来增加新服务，但我们也希望改变现有服务是困难<br />
的）。由于其持续性的影响，所以应在基本服务需求的基础上而不是参考任何特定网络来设<br />
计服务模型。<br />
我们现在简单的描叙一个Internet核心服务集的提案；所提议的这个核心服务模型的更完<br />
全描叙见[SCZ93a,&nbsp;SCZ93b]。该核心服务模型提出了那些与分组传输时间有最直接关系的服<br />
务。我们把其他的服务（如路由选择、安全或流同步）留给别的标准化组织。一个服务模型<br />
包含一个服务承诺集；网络对相应的服务请求承诺某种传送服务。这些服务承诺可以根据提<br />
出请求的实体而划分为：单个流实体或集合实体（流类）。对单个流作出的服务承诺的目标<br />
是提供合理的应用性能，因此而被应用的环境改造需求所驱动；这些与服务质量有关的服务<br />
承诺被传送给一个单一的流。对集合实体作出的服务承诺被资源共享或经济、需求所驱动；<br />
这些与汇聚资源有关的服务承诺对多种实体有效。<br />
在本部分中我们先探讨单个流的服务需求，并且提议一个相应的服务集。然后，我们讨论服<br />
务需求和资源共享服务。最后，我们总结一些关于分组丢弃的评论。<br />
&nbsp;&nbsp;&nbsp;<br />
3.1.&nbsp;服务质量需求<br />
&nbsp;&nbsp;&nbsp;&nbsp;核心服务模型主要关注分组传输时间。每一分组延迟是网络所作出的服务质量承诺中的<br />
主要指标。我们提出更严格的假设，就是我们作出的量化服务承诺的唯一指标就是延迟的最<br />
大值和最小值。<br />
应用性能依赖低延迟服务的程度变化很大，我们可以根据其依赖程度而将应用定性的分成几<br />
个级别。有一类应用在确定的时间内需要每一分组的数据，如果数据到时不能到达，则这些<br />
数据就完全没用了；我们称这类应用为实时应用。另外一类应用总是会等待数据的到达；我<br />
们称其为“弹性”应用。我们现在分别地考虑这两个类的延迟需求。<br />
<br />
3.1.1.实时应用<br />
&nbsp;&nbsp;&nbsp;&nbsp;这种实时应用的一个重要的类，“回放”应用，将是我们在后面的讨论中明确考虑的唯<br />
一实时应用。在一个回放应用中，原端取得一些信号，将其分组然后将这些分组通过网络传<br />
输。网络不可避免的对这些传送分组引入了某种延迟变化。接收方将这些数据分组解开，然<br />
后试图忠实的还原这些信号。这是通过缓冲输入数据然后根据原发送时间的某个固定延迟偏<br />
移来还原信号；术语“回放点”是指原发送时间的固定延迟偏移时间点。任何在其回放点之<br />
前到达的数据都可以被用来重构这个信号；在回放点之后到达的数据对于重构实时数据来说<br />
根本没有了。<br />
&nbsp;&nbsp;&nbsp;&nbsp;为了给延迟偏移选择一个合理的值，应用需要某种指定其分组可承受的最大延迟的“先<br />
验”特性。这种“先验”特性可能是网络提供的对延迟范围的一种量化服务承诺；也可能是<br />
通过观察已经到达分组而得到的延迟经验值；应用需要知道它期望的是何种延迟，但这种期<br />
望值不需要在流的整个持续时间内都保持恒定。<br />
&nbsp;&nbsp;&nbsp;&nbsp;一个回放应用的性能可由两种不同的尺度来衡量：反应时间和可信度。某些回放应用，<br />
特别是那些在链接两端包括交互的应用，如电话呼叫，对反应时间特别敏感；其它的回放应<br />
用，如传输电影或讲稿，则不需要。相似的，应用对丢包的可信度要求可以说有一个很大的<br />
范围。我们将考虑两种在某种程度上人为地分开的类：要求一个绝对的可靠回放的不可容忍<br />
的应用，以及能容忍一些丟包的可容忍的应用。我们希望大多数的音频和视频应用都是可容<br />
忍的，但我们也察觉到也有一些其它的应用如电路模拟是不可容忍的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;延迟以两种方式影响回放应用的性能。首先，由对未来分组延迟预测决定的延迟偏移值<br />
决定了应用的反应时间。其次，单个分组延迟由于超过其延迟偏移值而降低回放的可信度；<br />
应用因此而可以改变延迟偏移值以回放后面的分组（这会引起失真），或者简单的将迟到分<br />
组丢弃（这会产生一个不完全的信号）。对迟到分组的两种不同处理方式导致了对不完全信<br />
号和失真信号之间的选择，而最优的选择将取决于具体的应用，但重要的一点是迟到分组确<br />
实降低了可信度。<br />
&nbsp;&nbsp;&nbsp;&nbsp;不可容忍的应用必须使用一个固定的延迟偏移值，因为延迟偏移值的任何变化都将导致<br />
回放的某种失真。对一个给定分布的延迟，这个固定延迟偏移值要大于最大绝对延迟值，以<br />
避免分组迟到的可能性。这种应用只有在给定每个分组的完全可靠的最大延迟上限时才能恰<br />
当的设置其延迟偏移值值。我们称具有完全可靠延迟上限的服务为“保证服务”，并且提议<br />
它为不可容忍的回放应用的合适服务模型。<br />
&nbsp;&nbsp;&nbsp;&nbsp;相反，可容忍的应用不需要把他们的延迟偏移量设置得比最大绝对延迟更大，因为他们<br />
可以容忍某些迟到分组。而且，他们试图以最近实际的分组延迟经验值来改变他们的延迟偏<br />
移量以减少其反应时间，而不是使用一个单一的固定延迟偏移量。我们称按这种方式改变其<br />
延迟偏移量的应用为“自适应的”回放应用。<br />
&nbsp;&nbsp;&nbsp;&nbsp;对于可容忍服务我们提议一个称为“可预测服务”的服务模型，该模型支持一个相对可<br />
靠的，但不是完全可靠的延迟限制。这个限制，相对保证服务的限制而言，不是根据其它流<br />
行为的最坏情况而假设。相反，这个限制可能是根据其它流行为的适当保守的预测而计算的。<br />
如果网络出错，限制被突破，则应用性能可能受到影响，但根据这种限制花费较低的假设，<br />
用户会愿意容忍这种服务中断。而且由于大量可容忍应用是自适应的，我们认为这种可预测<br />
服务也提供“最大值最小化”服务，即它试图把过去的最大延迟最小化。这种服务并不试图<br />
最小化每一分组延迟，而是试图把其放入延迟分布中。<br />
&nbsp;&nbsp;&nbsp;&nbsp;很明显，在其它条件都一样的情况下，应用都会选择绝对可靠限制而不是相对可靠限制。<br />
那我们要不要提供可预测限制呢？关键是要考虑效率；当服务需求从完全可靠降低到相当可<br />
靠限制时，相应增加了网络的可持续利用资源，因此可预测服务一般要比保证服务开销低。<br />
可预测服务类基于这样一种假设，就是稍微降低可容忍服务的性能，但整个效率却获得很大<br />
的提高。<br />
&nbsp;&nbsp;&nbsp;&nbsp;为了提供一个延迟限制，从原端过来的通信量在本质上应该是可被区分的，而且必须有<br />
某种接入控制算法来确保一个请求流在实际上获得（资源）提供。我们整个体系结构的一个<br />
基本要素就是通信量特征和接入控制对这些实时延迟限制服务都是必须的。因此我们假设应<br />
用数据的产生过程是它的一种本质属性，不受网络的影响。然而有很多音频和视频应用可以<br />
调整其编码模式，因而可以根据可用的网络服务来改变其数据产生过程。这种编码模式的改<br />
变是对可信度（指编码模式本身，而不是指回放过程）和流的带宽需求的折衷。这种“速率<br />
自适应的”回放应用有一个优点，就是它们不仅可以通过重设回放点，而且可以通过调整其<br />
通信模式来适用当前的网络条件。对于速率自适应应用，用于服务承诺的通信量特征是不可<br />
变的。因此我们通过允许网络通报（或者通过丢弃分组的不明确的方式，或者明确地对分组<br />
进行控制）速率自适应应用改变其通信特征来增加限制模型。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
3.1.2.弹性应用<br />
&nbsp;&nbsp;&nbsp;&nbsp;尽管实时应用并不等待迟到数据的到来，弹性应用却总是等待数据的到来。这并不是指<br />
这些应用对延迟不作要求，相反的是分组延迟的较大变化将会极大的损害应用性能。而且，<br />
关键是应用立即使用达到数据，而不是将其为后面的某个时间缓冲起来，所以总是选择等待<br />
数据的输入而不是在没有数据时进行处理。由于分组一到达就可以立即使用，因此这些应用<br />
并不需要任何先验的服务特性来使其运行。一般来讲，对于给定的一个分组延迟分布，弹性<br />
应用的性能似乎更依赖于平均延迟，而不是延迟分布的细节。可以考虑的几种弹性应用有：<br />
突发性交互（Telnet，X，NFS），交互式大批量传输（FTP），以及异步大批量传输（电子邮<br />
件，FAX）。这些弹性应用的延迟需求从突发性交互的严格要求到异步大批量传输的宽松要求，<br />
而交互式大批量传输介于两者之间。<br />
&nbsp;&nbsp;&nbsp;&nbsp;弹性应用的一个合适的服务模型就是提供“尽可能的”或ASAP服务。（为了与过去的用<br />
法兼容，我们将使用术语尽力而为的服务来之ASAP服务。）我们还提议提供几个尽力而为的<br />
服务类以表现不同弹性应用的相关延迟敏感性。这种服务模型允许比交互式大批量传输应用<br />
具有更低延迟的突发交互式应用，而交互式大批量传输延迟相应的比异步大批量传输延迟要<br />
低。相对于实时服务模型，使用这种服务的应用并不遵循接入控制。<br />
把应用分成可容忍回放应用、不可容忍回放应用和弹性应用的分类法既不精确，也不完备，<br />
只是用来对配置核心服务模型提供指导。相应的核心服务模型是根据它是否能够充分的满足<br />
应用的整体需求来判断的，而不是根据下层分类法来判断。特别地，并不是所有地实时应用<br />
都是回放应用；例如，你可以想象一个可视化应用，它只不过在分组到达时显示每个分组的<br />
编码图像。然而，非回放应用仍然可以使用保证或者可预测实时服务模型，尽管这些服务对<br />
它们的需求不是特别明确的讲究。相似的是，回放应用并不能被完全的分为容忍或者不容忍，<br />
而是更像一个整体；同时提供保证和可预测服务允许应用能根据自己的需求就可信度、反应<br />
时间以及开销之间找到一个折衷。除了这种明显的不足外，我们希望这种分类法既能描叙现<br />
在的应用，也能描叙将来的应用，从而使我们的核心服务描叙能充分地满足所有应用的需求。<br />
<br />
3.2.&nbsp;资源共享需求和服务模型<br />
&nbsp;&nbsp;&nbsp;&nbsp;这是考虑服务质量承诺的最后一部分；这些承诺规定网络如何必须为单个流分配资源。<br />
这种资源分配通常使基于一个每一流的基础，既每一个流分别请求接入网络，然而并不提出<br />
任何流聚合时引起的策略问题。为了提出这些策略问题，我们现在讨论资源共享服务承诺。<br />
在前面我们集中于单个流的服务质量承诺，并把它当成唯一的利益量。在这里，我们假定资<br />
源共享的基本利益量时单个链路上的聚合带宽。因此，服务模型的这个组件，被称为“链路<br />
共享”，提出了如何根据某些指定部分的集合而在不同集合性实体中共享一个链路的汇聚带<br />
宽。有几个例子通常被用来解释在集合性实体之间的链路共享需求。<br />
&nbsp;&nbsp;&nbsp;&nbsp;多实体链路共享――可以被几个组织、政府部门或者其它的实体一起购买和使用的链<br />
路。他们可能希望在链路未超载时能确保以一种控制的方式共享，也许是按照各个实体的投<br />
资份额来进行的。同时，他们可能希望当链路未载时任何一个实体都可以使用所有的空闲带<br />
宽。<br />
&nbsp;&nbsp;&nbsp;&nbsp;多协议链路共享――在一个多协议Internet中，可能要求防止一个协议族(DECnet,&nbsp;IP,&nbsp;<br />
IPX,OSI,&nbsp;SNA,&nbsp;etc.)使链路超载，而其它的协议族被排除在外。由于不同协议族可能有不<br />
同的拥塞检测和响应方法，而且其中某些方法可能比其它方法更具有“侵略性”，因此这一<br />
点是重要的。这可能导致一种情形，就是在拥塞时一个协议比另一协议回退得快，因得不到<br />
带宽而结束。为了纠正这一点，可能有需要在路由器中进行明确的控制。另外，人们可能希<br />
望这种控制仅在超载时才使用，虽然一个空闲的链路可以按任何比例而被使用。<br />
&nbsp;&nbsp;&nbsp;&nbsp;多服务共享――在一个协议族如IP中，管理者可能希望对分配给多种服务类的带宽部<br />
分进行限制。例如，管理者可能希望对某些链路部分的实时通信量数量进行限制，以避免抢<br />
占弹性通信量如FTP的链路部分。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在一般条件下，链路共享服务模型根据某些指定的比例来共享汇聚带宽。我们可以将这<br />
个链路共享服务模型扩展为一个分级版。例如，可以将一条链路分给多个组织使用，每条链<br />
路都分给多个协议使用，每条链路都被分给多个服务使用。在这里共享由一个树来定义，该<br />
树的每一个叶子节点就是一链路部分。<br />
&nbsp;&nbsp;&nbsp;&nbsp;按比例分配访问的即时链路共享的一个理想化可改变模型是可改变共享模型（在[DKS89]<br />
中介绍，[DKS89]中作了进一步的研究，而且已经被通用化为层次情况），在这个模型中每一<br />
时刻有效带宽都被活动实体按指定的比例来共享资源。可改变模型展示了期望的策略行为，<br />
但是，这当然只是不现实的理想化。因此我们提议实际的服务模型应尽可能的接近这个理想<br />
可改变模型的带宽共享。要求分组按指定顺序发送一匹配那些可改变模型是不必要的，因此<br />
我们假定单个流的所有没一分组延迟需求细节都是通过服务质量承诺提出，而且，传输的链<br />
路共享服务的满意度可能将很少的依赖可改变链路共享模型，对使用这个模型的调度的微小<br />
偏离将不在区分。<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们前面讨论了接入控制，这种控制是用来确保实时服务承诺得以达成。相似的，接入<br />
控制对确保链路共享承诺得以达成也是必须的。对每一个实体，接入控制必须保留累计的保<br />
证，而且预测通信量一避免其超过指定的链路共享比例。<br />
<br />
3.3.&nbsp;分组丢弃<br />
&nbsp;&nbsp;&nbsp;到目前为止，我们一直简单地假设一个流内的所有分组都同样的重要。但是，在很多音<br />
频和视频流中，某些分组比其它分组更有价值。因此我们提议给服务模型增加一个“抢占式”<br />
分组服务，由此可以将一个流中的某些分组标记为抢先的。当网络对达到它的量化服务承诺<br />
有危险时，它可以对某些分组进行“抢占式选择”，然后将其丢弃（而不只是将其延迟，因<br />
为那将导致无序的问题）。通过丢弃这些分组，路由器可以减少其它分组的延迟。<br />
&nbsp;&nbsp;&nbsp;&nbsp;而且可以定义一个不遵从接入控制的分组类。在上面描叙的情形中仅在网络量化服务承<br />
诺有被损害的危险时才把分组丢弃，而期望是优先的分组几乎总是被传送，因此应将它们包<br />
括在接入控制所描叙的通信量中。但是我们可以将抢占性扩展到极端的情形，既“可牺牲的”<br />
分组（术语可牺牲的被用来表示抢占性的一种极端程度），希望很多这种可牺牲的分组可以<br />
不被传送。可以将可牺牲的分组排除在接入控制所描叙的通信量中；例如，从接入控制的角<br />
度来看，这些分组度不是流的一部分，因此对传送它们没有承诺。<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
3.4.&nbsp;使用反馈<br />
服务中另外一个重要的问题是使用反馈模型，也被称为“计费”，用来防止滥用网络资源。<br />
上面描叙的链路共享服务可以用来提供对使用的强制管理限制。然而，网络访问的一个更自<br />
由的市场模型将需要用户在预留他们的网络资源时的反压力。这是一个充满争议的问题，我<br />
们不准备在这个时候对其多作评论。<br />
<br />
3.5.&nbsp;预留模型<br />
&nbsp;&nbsp;&nbsp;&nbsp;“预留模型”描叙了应用是如何与QoS层对话的。这个简单模型就是在应用请求一个特<br />
定的QoS时网络或者接受或者拒绝它。通常情况下都比这更加复杂。很多应用将可以从一个<br />
QoS级别范围内，或者更一般地说，从一个流规约的多维空间的某个区域内的任何地方获得<br />
可接受的服务。<br />
&nbsp;&nbsp;&nbsp;&nbsp;例如，网络可能同意一个更低的资源级别而不是简单的拒绝请求，然后通知应用获得了<br />
哪一种QoS承诺。一个更复杂的例子就是“双向”预留模型，在这个模式中，一个“提供的”<br />
流规约由每一个发送者Si通过多播分布树广播到所有的接收者Sj。通路上的每一个路由器<br />
记录这些值并且有可能调整这些值以反映有效的容量。接收者获得这些提供，产生相应的“请<br />
求”流规约，然后沿着相同的路由器把它们回播给发送者。在每一个部分点上，都必须协调<br />
提供和请求流规约以创建一个预留，而且还传递一个已修改的合适的请求流规约。这种双向<br />
模式允许扩充的特性如在路径上每一跳的延迟分布[Tenet90,&nbsp;ST2-90]。进一步的工作是必<br />
须的，以定义预留模型中需要的有相应复杂性级别的一般性数量。<br />
<br />
4.&nbsp;通信量控制机制<br />
&nbsp;&nbsp;&nbsp;&nbsp;我们首先简单介绍可能的通信量控制机制，然后在4.2节中采用了这些机制的一个子集<br />
以支持我们所提议的各种服务。<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.1.&nbsp;基本功能<br />
&nbsp;&nbsp;&nbsp;&nbsp;在分组转发路径中的每一个路由器都确实有一个可以使用的有限的行为集。给定一个特<br />
定的分组，路由器必须为其选择一个路由；另外路由器可以将其转发或者丢弃，还可能由于<br />
其它等待发送的分组而将其重新排序。路由器也可能保留这个分组，即使这时链路是空闲的。<br />
这些都是我们必须改变的要求行为的构件。<br />
&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.1.1.分组调度<br />
&nbsp;&nbsp;&nbsp;&nbsp;分组调度的基本功能是对输出队列进行重排序。人们已写了很多关于管理输出队列的可<br />
能方式及由此产生的行为的论文。可能最简单的方法是一个分级模式，在这个模式中分组按<br />
优先级排序，高优先级的分组总是先被转发。这使得某些分组比其它的分组具有绝对的优先<br />
权；如果高优先级分组足够多的话，低优先级类的分组可能被完全阻止发送。<br />
&nbsp;&nbsp;&nbsp;&nbsp;一个可供选择的调度模式是循环或某些给予不同分组类访问链路部分的变量。有一个被<br />
称为加权公平队列或WFQ的变量，以用来演示如何将一条链路的所有带宽分成特定的部分。<br />
&nbsp;&nbsp;&nbsp;&nbsp;还有更复杂的队列管理模式，其中大多数都包括观察单个分组服务目标，如传输期限，<br />
然后根据这些准则来对分组进行排序。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.1.2.分组丢弃<br />
&nbsp;&nbsp;&nbsp;&nbsp;对分组丢弃的控制和对它们的调度一样重要。最明显的是，路由器在它的缓冲区完全满<br />
了时必须丢弃分组。然而，事实上这并不决定哪个分组将被丢弃。如果简单的将到达分组丢<br />
弃，则可能产生不想要的行为。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在目前的Internet环境中，TCP运作于提供尽力而为服务的IP之上，分组丢弃被TCP<br />
认为是一个拥塞信号而减少它在网络上的负载。选择丢弃一个分组就是选择一个原端来扼<br />
杀。不需要考虑任何特定的算法，这个简单的关系就意味着路由器必须实现某种特定的丢弃<br />
控制以改善拥塞控制。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在实时服务环境中，丟包与预期服务质量完成的关系更加直接。如果建立了一个队列，<br />
丢弃一个分组就可以降低该队列中后面的所有分组的延迟。丢弃一个可以使多个成功。实现<br />
者的问题是决定服务目标何时会受到损害。他们不能把队列长度作为分组在队列中时间长短<br />
的衡量。如果是在一个分级模式中，低优先级的分组可能被不确定的先丢弃，尽管一个短队<br />
列中可能有更旧的分组存在。虽然可以用实际的时间标志来测量等待时间，但复杂度将是不<br />
可接受的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;某些简单的丟包模式如把所有缓冲池合并成一个全局单一的缓冲池，如果该池已满，则<br />
丢弃到达分组，这会使WFQ调度模式失败。因此，丟包和调度必须合并起来。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.1.3.分组分类<br />
&nbsp;&nbsp;&nbsp;&nbsp;上述关于调度和丟包的讨论都假设分组已被分成某些可用一种特定方法处理的流或分<br />
组序列。这种处理方法的基础是分类本身。现在的路由器根据目标地址来选择路由。对于分<br />
组必须得到的服务类的选择仅有目标地址是不够的；还需要更多的信息。<br />
&nbsp;&nbsp;&nbsp;&nbsp;一种方法是放弃IP数据报模型，而采取虚电路模型，在该模型中一条电路用特定服务<br />
属性来设置，而分组则携带电路标识符。这是ATM的方法和协议，如ST-II&nbsp;[ST2-90]。另<br />
外一个模型，则对IP每这么多敌意，它允许分类器查看分组的更多域，如原端地址、协议<br />
号以及端口域。因此，视频流可以通过一个UDP头中特定的一种端口域而被识别，或者一个<br />
特定的流可以通过查看其原端和目的端的端口号来识别。甚至有可能查看分组的更深层次，<br />
如在测试应用层的域来选择分层编码视频流的一个子集。<br />
&nbsp;&nbsp;&nbsp;&nbsp;分类器实现的问题是复杂性和处理开销。目前的经验认为对有效算法的仔细实现可导致<br />
IP分组的有效分类。这个结果是非常重要的，因为它允许我们给一个已有的应用，如基于<br />
已有IP头的Telnet增加QoS支持，<br />
&nbsp;&nbsp;&nbsp;&nbsp;减少分类开销的一个方法是在Internet层分组头中提供一个“流标识符”域。这个流<br />
标识符可以是一个能够被储存的句柄，并用其对分组进行快速分类。关于这个概念有很多种<br />
不同的说法，对其工程化时要求选择一个最佳的设计。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.1.4.接入控制<br />
正如我们在介绍中所说的，实时服务依赖于路由器状态的设置以及对确定分组类作出的<br />
承诺。为了确保完成这些承诺，要求原端有明确的请求，以便在资源无效时拒绝该请求。对<br />
资源有效性的决定被称为接入控制。<br />
接入控制要求路由器能了解对它当前所有资源的需求。传统提议的方法多是记住过去请<br />
求的参数，然后基于每个服务的最坏可能限制来作计算。最近的一个提议，看来能提供更好<br />
的链路利用率，这是通过使路由器测量现有分组流的实际使用情况，然后用这些测量所得的<br />
信息作为允许新流的根据[JCSZ92]。这种方法会导致更高的超载风险，但可证明在利用带宽<br />
时要有效得多。注意对接入控制的需求是全局服务模型的一部分，而运行在每一个路由器上<br />
的具体算法却是局部性的。因此，供应商可以在开发和经营更好的接入控制算法方面竞争，<br />
这将导致更高的链路负载，更少的服务超载。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.2.机制的应用<br />
&nbsp;&nbsp;&nbsp;&nbsp;上面描叙的各种工具可以合并在一起来支持第三部分中讨论过的服务。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
保证延迟限制&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;Parekh&nbsp;[Parekh92]的一个理论性的结果表明，如果路由器实现一般WFQ调度原则，而<br />
且原端通信量在本质上可以被分类（例如，固定在一个令牌桶的某种限制内），则被讨论的<br />
通信量网络延迟有一个决对的上限。这个简单而有效的结果意味着不止是对一个交换，而且<br />
是对路由器的整个工作度有意义。这个结果指富有建设性的，即Parekh展示了导致限制的<br />
原端行为，而且说明了这种行为的最坏可能。这就是指在这些假设条件下他所计算的限制是<br />
所有可能结果中最好的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
链路共享&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;同一个WFQ可以提供控制链路共享。该服务目标在这里不是要限制延迟而是限制一个链<br />
路上的超载共享，尽管在有空间的情况下允许处理任何混合通信量。WFQ的这种用法在现在<br />
的商业路由器中就已使用了，而且用它来把通信量分割成类，这种分割是基于协议类型和应<br />
用等一类的事情。例如，可以为TCP、IPX和SNA分配单独的一份（资源），还能够确保网络<br />
控制通信量获得保证的链路共享。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
可预测实时服务<br />
这种服务实际上比保证服务还要微妙。它的目标是提供一种延迟限制，这个限制一方面要尽<br />
可能的低，另一方面要足够的稳定，以便接收方能够对它进行估计。WFQ机制导致一个保证<br />
限制，但不必是一个低的限制。事实上，把通信量混合在一个队列里，比将其如在WFQ中一<br />
样分开，会产生更低的限制，只是这些混合通信量要基本相似。（例如，混合从多个视频编<br />
码器来的通信量是可行的，但混合视频和FTP却是不行的。）&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;这意味着我们需要一个双重机制，第一重机制将通信量分成具有不同服务目标的类，然<br />
后第二重机制对第一重所分类的通信量进行调度，已达到其服务目标。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
4.3.&nbsp;一个例子：CSZ模式<br />
&nbsp;&nbsp;&nbsp;&nbsp;作为这个概念的一个证据，一个代码包已被实现了，它实现上面所讨论的服务。实际上<br />
它使用了多种基本工具，并与服务需求以一种特定的方式结合起来。我们描叙它工作的一般<br />
条件，并且建议如何可以实现服务。我们强调还有其它的方法来建构一个路由器以满足同样<br />
的服务需求，而且事实上现在已经使用其它的实现。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在顶层，CSZ代码把WFQ当作一个单独的机制来使用，以便将各种保证流，以及其它通<br />
信量分开。保证服务获得最高的优先级，当且仅当它需要这次访问来达到其最终期限要求。<br />
WFQ为每一个保证流提供单独的保证。<br />
&nbsp;&nbsp;&nbsp;&nbsp;可预测服务和尽力而为服务在优先级上是分开的。在可预测服务类中，使用一个更进一<br />
步的分级以提供具有不同延迟限制的子类。在每一个可预测服务子类中使用简单的FIFO排<br />
队来混合通信量，这看来会导致好的整体延迟行为。这种方法之所以有效，是因为顶层算法<br />
已将尽力而为通信量如FTP隔离开。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在尽力而为服务类中使用WFQ来提供链路共享。因为可能有对嵌套共享的需求，这种<br />
WFQ代码可以被递归的使用。在该代码中WFQ有两种不同的用法，一个是隔离保证服务类，<br />
另外一个是隔离链路的个部分。它们大体上是相似的，只是细节不同。<br />
&nbsp;&nbsp;&nbsp;&nbsp;在尽力而为服务磊地每一个链接上，优先级被用来允许更多的对时间敏感的弹性通信量<br />
优先于其它地弹性通信量，例如，允许交互式通信量优先于异步大批量传输。<br />
&nbsp;&nbsp;&nbsp;&nbsp;因此CSZ代码在一个交互方式中使用WFQ和分级来建构一个机制，以支持非常复杂的服<br />
务提供。关于这方面的讨论是相当简略的，很多明显的问题都没有触及到，如CSZ代码是如<br />
何是实时通信量适合于链路共享目标的。但其基本构件是相当简单的，而且非常有效。特别<br />
地，尽管分级被提议为实时服务的一个关键，但WFQ在两种模式中可能是更通用而且更有效<br />
的。是WFQ，而不是分级，支持保证服务和链路共享。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
5.&nbsp;预留设置协议<br />
&nbsp;&nbsp;&nbsp;&nbsp;在设计一个预留设置协议时要达到多个需求。首先它在根本上要被设计成能用于一个多<br />
播环境，而且必须适用异源服务需求。它在方式上应提供灵活的控制，以使预留能在多播传<br />
输树上的每个分支都能共享预留。应将它设计成基于在现有设置中添加或删除一个发送者和<br />
/或接收者等动作的基础上。它必须是健壮的，而且能扩展到大的多播组。最后，它必须提<br />
供高级资源预留，以及由此而产生的优先权。已设计出一个达到这些需求的预留设置协议<br />
RSVP[RSVP93a,&nbsp;RSVP93b]。本部分概述RSVP的设计。<br />
&nbsp;&nbsp;&nbsp;<br />
5.1.RSVP&nbsp;概述<br />
&nbsp;&nbsp;&nbsp;&nbsp;图2&nbsp;说明具有多个原端、多个目的端的一个特定共享的分布式应用的数据传送。箭头<br />
表示数据从发送方S1和S2流向接收方R1、R2和R3，云代表由多播路由协议创建的分配网<br />
格。多播分配复制从每一个发送方Si来的没一数据分组，然后发送给每一个接收方Rj。我<br />
们把从S1到R1的单播当成一个特例，而且称这种多播分配网格为一次会话。会话是根据接<br />
收方的普通IP（多播）目的地址来定义的。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<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;接收方<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;_____________________<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;===&gt;&nbsp;R1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S1&nbsp;===&gt;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;多&nbsp;播&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)<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;===&gt;&nbsp;R2<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;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S2&nbsp;===&gt;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)<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;===&gt;&nbsp;R3<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;(_____________________)<br />
<br />
图2&nbsp;&nbsp;&nbsp;多播分布式会话<br />
<br />
5.1.1.流规约和过滤器规约<br />
&nbsp;&nbsp;&nbsp;&nbsp;一般来讲，一个RSVP预留请求指定在一次特定会话中所有分组或它的一个子集要预留<br />
的资源数量。这种资源数量是由流规约来指定的，而获得这些资源的分组子集则由过滤器规<br />
约来指定。如果接入控制获得通过，流规约将被用来设置分组调度器中的资源类，而过滤器<br />
规约将在分组分类器中实例化，以把适当的分组映射为这个类。选择一个特定类的分类器状<br />
态子集在RSVP文档中是指一个（分组）“过滤器”。<br />
&nbsp;&nbsp;&nbsp;&nbsp;这个RSVP协议机制提供一个非常一般化的工具，用来创建和维护通过多播传输路径上<br />
的网格的分布式预留状态。这些机制通常把流规约和过滤器规约当成不透明的二进制数据，<br />
把它们传给本地通信量控制机器来解释。当然，应用中的服务模型必须指定如何对流规约和<br />
过滤器规约进行编码。<br />
<br />
5.1.2.&nbsp;预留类型<br />
RSVP提供几种不同的预留“类型”，由这些类型来决定汇聚在路由器中的多个接收者的资源<br />
请求方式。这些类型允许更有效地预留资源以达到应用的需求。目前有三种预留类型，“通<br />
配符”、“固定过滤器”以及“动态过滤器”。一个通配符预留使用一个不指定特定原端的过<br />
滤器规约，因此所有发往相应目的端的分组可能使用一个预留资源的公共池。这允许在一个<br />
组的所有分布式路径上作出单一的资源分配。通配符预留类型在支持视频会议方面是非常有<br />
效的，这时至少有一个小数量的原端同时起作用，而且可能共享资源分配。<br />
其它两种类型使用过滤器规约来选择原端。一个接收者可能希望接收来自一个固定的原端集<br />
的数据，或者相反的，它可能希望网络能通过动态的更改过滤器规约来在不同原端之间切换。<br />
动态预留确实允许一个接收者修改其原端而不需要附加的接入控制；但是这需要有充足的可<br />
供分配的资源以处理当所有接收者从不同原端接收输入时的最坏情况。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
5.1.3.&nbsp;接收方初始化<br />
&nbsp;&nbsp;&nbsp;&nbsp;一个重要的问题是发送方或接收方是否负责预留的初始化。发送方知道他能发送的通信<br />
量流的质量，而接收方知道他要（或可以）接收的流。也许最明显的选择就是让发送方初始<br />
化预留。但是这不容易扩展到大的动态多播传送树以及异源接收方。<br />
&nbsp;&nbsp;&nbsp;&nbsp;这两个扩展问题通过由接收方来负责初始化预留而被解决。接收方初始化预留可以轻易<br />
地处理异源接收；每一个接收者简单地请求一个适合自己的预留，然后网络通过RSVP来决<br />
定（“合并”）来自不同接收者的不同的预留请求。&nbsp;接收方初始化与IP多播也是一致的，这<br />
是在一个由接收者参加而不明确地创建的多播组中。尽管接收方初始化是多播会话的自然选<br />
择，但它对单播会话可能会要差一些，因此发送方可能是逻辑上的会话发起者。但是，我们<br />
希望每一个实时应用都将具有更高级别的信令和控制协议，而且这种协议可以被用来通知接<br />
收方初始化一个预留（而且也许表明将使用流规约）。为了简单性和经济性，一个设置协议<br />
应只支持一个方向的初始化，而接收方初始化对我们而言是一个明显的胜者。<br />
&nbsp;&nbsp;&nbsp;&nbsp;RSVP使用预留的接收方初始化[RSVP93b]。假定接收方可以通过一个更高层机制来了解<br />
发送方提供的流规约（“频带外的”），由此它可以产生它自己希望的流规约并把它传给发送<br />
方，以便在路径上的每一个路由器上作出预留。<br />
<br />
5.1.4．软状态<br />
&nbsp;&nbsp;&nbsp;&nbsp;预留设置协议有两种可能的不同类型，“硬状态”（HS）方法（也称为“面向连接的”）<br />
和“软状态”方法（也称为“无连接的”）。多播分布在两种中多是通过使用路径上的每一个<br />
路由器的流规约状态来执行的。在HS方法下，这种状态用一种通过路由器见合作的充分确<br />
定的方式来创建和删除的。主机一旦请求一次会话，“网络”负责创建必要的状态，后来取<br />
消它。ST-II&nbsp;是HS方法的一个例子[ST2-90]。由于HS会话状态的管理是完全确定的，因此<br />
HS设置协议必须是可靠的，还要有承认和重发。为了在一次失败后完成确定地清除状态，<br />
必须有某种机制来检测错误，例如，一个“上/下”协议。预留失败的上游路由器（相对原<br />
端而言）负责在一条替换的路由上的路由器中重建必要的状态。<br />
&nbsp;&nbsp;&nbsp;&nbsp;采取SS方法的RSVP，把预留状态当作安装的缓冲信息，而且由终端主机定期刷新。未<br />
用的状态被路由器中止。如果路由改变了，刷新信息自动地沿着新路由安装必要的状态。选<br />
择SS方法来获得简单性和健壮性，这已经在无连接协议如IP中得到证明了[Clark88]。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
5.2.&nbsp;路由选择与预留<br />
&nbsp;&nbsp;&nbsp;&nbsp;在资源预留设置和路由选择之间有一个基本的交互过程，因为预留需要安装数据分组路<br />
由上的流状态。如果而且当一个路由改变时，必须有某种机制来设置新路由上的预留。<br />
&nbsp;&nbsp;&nbsp;&nbsp;有人认为预留设置需要路由设置是必要的，例如，强迫接受一个虚电路网络层。但是我<br />
们的目标是简单地扩展Internet体系结构，而不是替换它。基本的无连接网络层[Clark88]<br />
已经获得高度成功，因此我们将保留它作为体系结构的基础。我们提议对现在的Internet<br />
纯数据报转发机制作某种程度的修改以适应“IS”。<br />
&nbsp;&nbsp;&nbsp;&nbsp;预留设置协议如RSVP面临着四个路由问题。<br />
1.	找到一个支持资源预留的路由。<br />
&nbsp;&nbsp;&nbsp;这是简单的“服务类型”路由选择，是一个在某些现代的路由选择协议中已经可用的设<br />
备。<br />
2.&nbsp;找到一个有足够的未预留容量给一个新流的路由。<br />
&nbsp;&nbsp;&nbsp;在ARPANET上的早期试验说明在一个每一分组基础上进行基于载荷的动态路由选择而没<br />
有稳定性问题是困难的。然而，如果基于载荷的路由选择仅在预留设置时间内执行，则稳定<br />
性将不成问题。在查找一个具有足够容量的路由时有两种不同方法可供采用。可以修改路由<br />
选择协议以使它们与通信量控制机制交接，从而路由计算可以考虑最近平均载荷。另外，也<br />
可以（重）设计路由选择协议以提供多种可供选择的路由，而预留可以轮流地尝试各个路由。<br />
2.	对路由失败的适应<br />
&nbsp;&nbsp;&nbsp;当某些站点或链路失败，适应性的路由选择寻找一个替换的路径。定期刷新的RSVP消息<br />
将自动在新路径上请求一个预留。当然，如果新路径上没有足够的有效容量，这种预留可能<br />
会失败。这是一个供应和网络工程的问题，路由选择或设置协议不能解决。在新路径上建立<br />
预留状态有一个时间问题。端到端健壮的刷新机制受限于上层的频率，这在实时服务中当一<br />
个旧的路由中断后和选择一个新路由之前会产生一个间隙。在RSVP工程化时实现全局的刷<br />
新机制，而在本地实现一个修复机制，使用来自路由选择机制的路由改变提示。<br />
3.	对路由改变的适应（没有失败情况下）<br />
&nbsp;&nbsp;&nbsp;&nbsp;路由改变即使在受影响路径上没有失败时也有可能发生。尽管RSVP可以使用(3)中描述<br />
的那些相同的修复技术，这里有一个QoS保证的健壮性问题。如果接入控制在新路由上失败<br />
时，用户将发现服务不必要地而且任意地降级，尽管这时原来的路由仍然有效。为避免这种<br />
问题，已经建议了一个称为“路由钉牢”的机制。这将修改路由选择协议地实现以及它与分<br />
类器地接口，以便将资源预留有关地路由“钉牢”。路由选择协议不能改变一个仍然有效的<br />
被钉牢的路由。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;虽然最终将有可能能把路由和预留设置问题合在一起，但是我们对这样作还缺乏足够的<br />
了解。而且，预留协议要能与Internet中正在使用的多种不同的路由选择协议共存。因此，<br />
目前设计的RSVP不作修改就可以与任何当代路由选择协议协同工作。这只是一个短期的折<br />
衷，因为这在创建最佳的，或者甚至任何实时会话时会导致偶然的失败，或者在路由改变时<br />
偶然性的服务降级。我们希望未来一代的路由选择协议去掉这种折衷，通过包含与RSVP联<br />
合在一起的钩子和机制，解决(1)到(4)所列的问题。这些协议将支持路由钉牢，通知RSVP<br />
激发本地修复，以及选择支持“IS”而且有足够容量的路由。<br />
&nbsp;&nbsp;&nbsp;&nbsp;最后一个与路由选择有关的问题时关于移动主机的。我们猜想移动性路由的改变与其它<br />
路由改变在本质上没有区别，因此有(3)和(4)中所提到的机制就已经足够了。需要更多的研<br />
究和试验来证明或者反驳这种猜想。<br />
<br />
6.&nbsp;致谢<br />
&nbsp;&nbsp;&nbsp;很多Internet研究者都对本备忘录中所描述的工作作出了贡献的。我们要特别感谢<br />
Steve&nbsp;Casner,&nbsp;Steve&nbsp;Deering,&nbsp;Deborah&nbsp;Estrin,&nbsp;Sally&nbsp;Floyd,&nbsp;Shai&nbsp;Herzog,&nbsp;Van&nbsp;<br />
Jacobson,Sugih&nbsp;Jamin,&nbsp;Craig&nbsp;Partridge,&nbsp;John&nbsp;Wroclawski,&nbsp;和&nbsp;Lixia&nbsp;Zhang。这个<br />
Internet综合服务方法最初由Internet研究任务组的端到端组组织和讨论，我们感谢该组<br />
所有成员的有趣的（有时是热心的）讨论。<br />
参考文献：<br />
[CerfKahn74]&nbsp;&nbsp;Cerf,&nbsp;V.,&nbsp;and&nbsp;R.&nbsp;Kahn,&nbsp;"A&nbsp;Protocol&nbsp;for&nbsp;Packet&nbsp;Network<br />
&nbsp;&nbsp;&nbsp;&nbsp;Intercommunication",&nbsp;IEEE&nbsp;Trans&nbsp;on&nbsp;Comm.,&nbsp;Vol.&nbsp;Com-22,&nbsp;No.&nbsp;5,&nbsp;May<br />
&nbsp;&nbsp;&nbsp;&nbsp;1974.<br />
<br />
[Clark88]&nbsp;&nbsp;Clark,&nbsp;D.,&nbsp;"The&nbsp;Design&nbsp;Philosophy&nbsp;of&nbsp;the&nbsp;DARPA&nbsp;Internet<br />
&nbsp;&nbsp;&nbsp;&nbsp;Protocols",&nbsp;ACM&nbsp;SIGCOMM&nbsp;'88,&nbsp;August&nbsp;1988.<br />
<br />
[CSZ92]&nbsp;&nbsp;Clark,&nbsp;D.,&nbsp;Shenker,&nbsp;S.,&nbsp;and&nbsp;L.&nbsp;Zhang,&nbsp;"Supporting&nbsp;Real-Time<br />
&nbsp;&nbsp;&nbsp;&nbsp;Applications&nbsp;in&nbsp;an&nbsp;Integrated&nbsp;Services&nbsp;Packet&nbsp;Network:&nbsp;Architecture<br />
&nbsp;&nbsp;&nbsp;&nbsp;and&nbsp;Mechanisms",&nbsp;Proc.&nbsp;SIGCOMM&nbsp;'92,&nbsp;Baltimore,&nbsp;MD,&nbsp;August&nbsp;1992.<br />
<br />
[DKS89]&nbsp;&nbsp;Demers,&nbsp;A.,&nbsp;Keshav,&nbsp;S.,&nbsp;and&nbsp;S.&nbsp;Shenker.&nbsp;&nbsp;"Analysis&nbsp;and<br />
&nbsp;&nbsp;&nbsp;&nbsp;Simulation&nbsp;of&nbsp;a&nbsp;Fair&nbsp;Queueing&nbsp;Algorithm",&nbsp;Journal&nbsp;of<br />
&nbsp;&nbsp;&nbsp;&nbsp;Internetworking:&nbsp;Research&nbsp;and&nbsp;Experience,&nbsp;1,&nbsp;pp.&nbsp;3-26,&nbsp;1990.&nbsp;&nbsp;Also<br />
&nbsp;&nbsp;&nbsp;&nbsp;in&nbsp;Proc.&nbsp;ACM&nbsp;SIGCOMM&nbsp;'89,&nbsp;pp&nbsp;3-12.<br />
<br />
[SCZ93a]&nbsp;&nbsp;Shenker,&nbsp;S.,&nbsp;Clark,&nbsp;D.,&nbsp;and&nbsp;L.&nbsp;Zhang,&nbsp;"A&nbsp;Scheduling&nbsp;Service<br />
&nbsp;&nbsp;&nbsp;&nbsp;Model&nbsp;and&nbsp;a&nbsp;Scheduling&nbsp;Architecture&nbsp;for&nbsp;an&nbsp;Integrated&nbsp;Services<br />
&nbsp;&nbsp;&nbsp;&nbsp;Packet&nbsp;Network",&nbsp;submitted&nbsp;to&nbsp;ACM/IEEE&nbsp;Trans.&nbsp;on&nbsp;Networking.<br />
<br />
[SCZ93b]&nbsp;&nbsp;Shenker,&nbsp;S.,&nbsp;Clark,&nbsp;D.,&nbsp;and&nbsp;L.&nbsp;Zhang,&nbsp;"A&nbsp;Service&nbsp;Model&nbsp;for&nbsp;the<br />
&nbsp;&nbsp;&nbsp;&nbsp;Integrated&nbsp;Services&nbsp;Internet",&nbsp;Work&nbsp;in&nbsp;Progress,&nbsp;October&nbsp;1993.<br />
<br />
[Floyd92]&nbsp;&nbsp;Floyd,&nbsp;S.,&nbsp;"Issues&nbsp;in&nbsp;Flexible&nbsp;Resource&nbsp;Management&nbsp;for<br />
&nbsp;&nbsp;&nbsp;&nbsp;Datagram&nbsp;Networks",&nbsp;Proceedings&nbsp;of&nbsp;the&nbsp;3rd&nbsp;Workshop&nbsp;on&nbsp;Very&nbsp;High<br />
&nbsp;&nbsp;&nbsp;&nbsp;Speed&nbsp;Networks,&nbsp;March&nbsp;1992.<br />
<br />
[Jacobson91]&nbsp;&nbsp;Jacobson,&nbsp;V.,&nbsp;"Private&nbsp;Communication",&nbsp;1991.<br />
<br />
[JCSZ92]&nbsp;&nbsp;Jamin,&nbsp;S.,&nbsp;Shenker,&nbsp;S.,&nbsp;Zhang,&nbsp;L.,&nbsp;and&nbsp;D.&nbsp;Clark,&nbsp;"An&nbsp;Admission<br />
&nbsp;&nbsp;&nbsp;&nbsp;Control&nbsp;Algorithm&nbsp;for&nbsp;Predictive&nbsp;Real-Time&nbsp;Service",&nbsp;Extended<br />
&nbsp;&nbsp;&nbsp;&nbsp;abstract,&nbsp;in&nbsp;Proc.&nbsp;Third&nbsp;International&nbsp;Workshop&nbsp;on&nbsp;Network&nbsp;and<br />
&nbsp;&nbsp;&nbsp;&nbsp;Operating&nbsp;System&nbsp;Support&nbsp;for&nbsp;Digital&nbsp;Audio&nbsp;and&nbsp;Video,&nbsp;San&nbsp;Diego,&nbsp;CA,<br />
&nbsp;&nbsp;&nbsp;&nbsp;Nov.&nbsp;1992,&nbsp;pp.&nbsp;&nbsp;73-91.<br />
<br />
[Parekh92]&nbsp;&nbsp;Parekh,&nbsp;A.,&nbsp;"A&nbsp;Generalized&nbsp;Processor&nbsp;Sharing&nbsp;Approach&nbsp;to<br />
&nbsp;&nbsp;&nbsp;&nbsp;Flow&nbsp;Control&nbsp;in&nbsp;Integrated&nbsp;Services&nbsp;Networks",&nbsp;Technical&nbsp;Report<br />
&nbsp;&nbsp;&nbsp;&nbsp;LIDS-TR-2089,&nbsp;Laboratory&nbsp;for&nbsp;Information&nbsp;and&nbsp;Decision&nbsp;Systems,<br />
&nbsp;&nbsp;&nbsp;&nbsp;Massachusetts&nbsp;Institute&nbsp;of&nbsp;Technology,&nbsp;1992.<br />
<br />
[Partridge92]&nbsp;&nbsp;Partridge,&nbsp;C.,&nbsp;"A&nbsp;Proposed&nbsp;Flow&nbsp;Specification",&nbsp;RFC&nbsp;1363,<br />
&nbsp;&nbsp;&nbsp;&nbsp;BBN,&nbsp;July&nbsp;1992.<br />
<br />
[RSVP93a]&nbsp;&nbsp;Zhang,&nbsp;L.,&nbsp;Deering,&nbsp;S.,&nbsp;Estrin,&nbsp;D.,&nbsp;Shenker,&nbsp;S.,&nbsp;and&nbsp;D.<br />
&nbsp;&nbsp;&nbsp;&nbsp;Zappala,&nbsp;"RSVP:&nbsp;A&nbsp;New&nbsp;Resource&nbsp;ReSerVation&nbsp;Protocol",&nbsp;Accepted&nbsp;for<br />
&nbsp;&nbsp;&nbsp;&nbsp;publication&nbsp;in&nbsp;IEEE&nbsp;Network,&nbsp;1993.<br />
<br />
[RSVP93b]&nbsp;&nbsp;Zhang,&nbsp;L.,&nbsp;Braden,&nbsp;R.,&nbsp;Estrin,&nbsp;D.,&nbsp;Herzog,&nbsp;S.,&nbsp;and&nbsp;S.&nbsp;Jamin,<br />
&nbsp;&nbsp;&nbsp;&nbsp;"Resource&nbsp;ReSerVation&nbsp;Protocol&nbsp;(RSVP)&nbsp;-&nbsp;Version&nbsp;1&nbsp;Functional<br />
&nbsp;&nbsp;&nbsp;&nbsp;Specification",&nbsp;Work&nbsp;in&nbsp;Progress,&nbsp;1993.<br />
<br />
[ST2-90]&nbsp;&nbsp;Topolcic,&nbsp;C.,&nbsp;"Experimental&nbsp;Internet&nbsp;Stream&nbsp;Protocol:&nbsp;Version<br />
&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;(ST-II)",&nbsp;RFC&nbsp;1190,&nbsp;BBN,&nbsp;October&nbsp;1990.<br />
<br />
[Tenet90]&nbsp;&nbsp;Ferrari,&nbsp;D.,&nbsp;and&nbsp;D.&nbsp;Verma,&nbsp;"A&nbsp;Scheme&nbsp;for&nbsp;Real-Time&nbsp;Channel<br />
&nbsp;&nbsp;&nbsp;&nbsp;Establishment&nbsp;in&nbsp;Wide-Area&nbsp;Networks",&nbsp;IEEE&nbsp;JSAC,&nbsp;Vol.&nbsp;8,&nbsp;No.&nbsp;3,&nbsp;pp<br />
&nbsp;&nbsp;&nbsp;&nbsp;368-379,&nbsp;April&nbsp;1990.<br />
<br />
<br />
安全考虑<br />
&nbsp;&nbsp;&nbsp;&nbsp;正如2.1节中所提到的，预留资源的能力引起对认证的需求，请求资源保证的用户和声<br />
称拥有使用那种保证权力的分组都需要认证。这些认证问题不在本备忘录中提出，但将作进<br />
一步研究。<br />
<br />
作者地址<br />
&nbsp;&nbsp;&nbsp;Bob&nbsp;Braden<br />
&nbsp;&nbsp;&nbsp;USC&nbsp;Information&nbsp;Sciences&nbsp;Institute<br />
&nbsp;&nbsp;&nbsp;4676&nbsp;Admiralty&nbsp;Way<br />
&nbsp;&nbsp;&nbsp;Marina&nbsp;del&nbsp;Rey,&nbsp;CA&nbsp;90292<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(310)&nbsp;822-1511<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;Braden@ISI.EDU<br />
<br />
&nbsp;&nbsp;&nbsp;David&nbsp;Clark<br />
&nbsp;&nbsp;&nbsp;MIT&nbsp;Laboratory&nbsp;for&nbsp;Computer&nbsp;Science<br />
&nbsp;&nbsp;&nbsp;545&nbsp;Technology&nbsp;Square<br />
&nbsp;&nbsp;&nbsp;Cambridge,&nbsp;MA&nbsp;02139-1986<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(617)&nbsp;253-6003<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;ddc@LCS.MIT.EDU<br />
<br />
&nbsp;&nbsp;&nbsp;Scott&nbsp;Shenker<br />
&nbsp;&nbsp;&nbsp;Xerox&nbsp;Palo&nbsp;Alto&nbsp;Research&nbsp;Center<br />
&nbsp;&nbsp;&nbsp;3333&nbsp;Coyote&nbsp;Hill&nbsp;Road<br />
&nbsp;&nbsp;&nbsp;Palo&nbsp;Alto,&nbsp;CA&nbsp;94304<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(415)&nbsp;812-4840<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;Shenker@PARC.XEROX.COM<br />
<br />
<br />
<br />
RFC1633——Integrated&nbsp;Services&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Architecture&nbsp;Internet:&nbsp;an&nbsp;Overview<br />
体系结构中的综合服务概述<br />
RFC文档中文翻译计划&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<br />