rfc1633.txt

RFC规范的翻译稿

型并不意味着就需要一个分组调度或接入控制的简单实现。尽管已开发出满足我们服务模型
的特定分组调度或接入控制机制，但很可能还会有其它的机制满足这个服务模型。后面介绍
的参考实现框架，允许在没有一个简单设计情况下讨论有关实现的问题。
    基于上述考虑，我们相信为了提供必要的服务，一个包括在路由器中增加流状态以及一
个明确的设置机制的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.实时应用
    这种实时应用的一个重要的类，“回放”应用，将是我们在后面的讨论中明确考虑的唯
一实时应用。在一个回放应用中，原端取得一些信号，将其分组然后将这些分组通过网络传
输。网络不可避免的对这些传送分组引入了某种延迟变化。接收方将这些数据分组解开，然
后试图忠实的还原这些信号。这是通过缓冲输入数据然后根据原发送时间的某个固定延迟偏
移来还原信号；术语“回放点”是指原发送时间的固定延迟偏移时间点。任何在其回放点之
前到达的数据都可以被用来重构这个信号；在回放点之后到达的数据对于重构实时数据来说
根本没有了。
    为了给延迟偏移选择一个合理的值，应用需要某种指定其分组可承受的最大延迟的“先
验”特性。这种“先验”特性可能是网络提供的对延迟范围的一种量化服务承诺；也可能是
通过观察已经到达分组而得到的延迟经验值；应用需要知道它期望的是何种延迟，但这种期
望值不需要在流的整个持续时间内都保持恒定。
    一个回放应用的性能可由两种不同的尺度来衡量：反应时间和可信度。某些回放应用，