rfc1633.txt

RFC规范的翻译稿

4.1.2.分组丢弃
    对分组丢弃的控制和对它们的调度一样重要。最明显的是，路由器在它的缓冲区完全满
了时必须丢弃分组。然而，事实上这并不决定哪个分组将被丢弃。如果简单的将到达分组丢
弃，则可能产生不想要的行为。
    在目前的Internet环境中，TCP运作于提供尽力而为服务的IP之上，分组丢弃被TCP
认为是一个拥塞信号而减少它在网络上的负载。选择丢弃一个分组就是选择一个原端来扼
杀。不需要考虑任何特定的算法，这个简单的关系就意味着路由器必须实现某种特定的丢弃
控制以改善拥塞控制。
    在实时服务环境中，丟包与预期服务质量完成的关系更加直接。如果建立了一个队列，
丢弃一个分组就可以降低该队列中后面的所有分组的延迟。丢弃一个可以使多个成功。实现
者的问题是决定服务目标何时会受到损害。他们不能把队列长度作为分组在队列中时间长短
的衡量。如果是在一个分级模式中，低优先级的分组可能被不确定的先丢弃，尽管一个短队
列中可能有更旧的分组存在。虽然可以用实际的时间标志来测量等待时间，但复杂度将是不
可接受的。
    某些简单的丟包模式如把所有缓冲池合并成一个全局单一的缓冲池，如果该池已满，则
丢弃到达分组，这会使WFQ调度模式失败。因此，丟包和调度必须合并起来。
     
4.1.3.分组分类
    上述关于调度和丟包的讨论都假设分组已被分成某些可用一种特定方法处理的流或分
组序列。这种处理方法的基础是分类本身。现在的路由器根据目标地址来选择路由。对于分
组必须得到的服务类的选择仅有目标地址是不够的；还需要更多的信息。
    一种方法是放弃IP数据报模型，而采取虚电路模型，在该模型中一条电路用特定服务
属性来设置，而分组则携带电路标识符。这是ATM的方法和协议，如ST-II [ST2-90]。另
外一个模型，则对IP每这么多敌意，它允许分类器查看分组的更多域，如原端地址、协议
号以及端口域。因此，视频流可以通过一个UDP头中特定的一种端口域而被识别，或者一个
特定的流可以通过查看其原端和目的端的端口号来识别。甚至有可能查看分组的更深层次，
如在测试应用层的域来选择分层编码视频流的一个子集。
    分类器实现的问题是复杂性和处理开销。目前的经验认为对有效算法的仔细实现可导致
IP分组的有效分类。这个结果是非常重要的，因为它允许我们给一个已有的应用，如基于
已有IP头的Telnet增加QoS支持，
    减少分类开销的一个方法是在Internet层分组头中提供一个“流标识符”域。这个流
标识符可以是一个能够被储存的句柄，并用其对分组进行快速分类。关于这个概念有很多种
不同的说法，对其工程化时要求选择一个最佳的设计。
       
4.1.4.接入控制
正如我们在介绍中所说的，实时服务依赖于路由器状态的设置以及对确定分组类作出的
承诺。为了确保完成这些承诺，要求原端有明确的请求，以便在资源无效时拒绝该请求。对
资源有效性的决定被称为接入控制。
接入控制要求路由器能了解对它当前所有资源的需求。传统提议的方法多是记住过去请
求的参数，然后基于每个服务的最坏可能限制来作计算。最近的一个提议，看来能提供更好
的链路利用率，这是通过使路由器测量现有分组流的实际使用情况，然后用这些测量所得的
信息作为允许新流的根据[JCSZ92]。这种方法会导致更高的超载风险，但可证明在利用带宽
时要有效得多。注意对接入控制的需求是全局服务模型的一部分，而运行在每一个路由器上
的具体算法却是局部性的。因此，供应商可以在开发和经营更好的接入控制算法方面竞争，
这将导致更高的链路负载，更少的服务超载。
        
4.2.机制的应用
    上面描叙的各种工具可以合并在一起来支持第三部分中讨论过的服务。
     
保证延迟限制    
    Parekh [Parekh92]的一个理论性的结果表明，如果路由器实现一般WFQ调度原则，而
且原端通信量在本质上可以被分类（例如，固定在一个令牌桶的某种限制内），则被讨论的
通信量网络延迟有一个决对的上限。这个简单而有效的结果意味着不止是对一个交换，而且
是对路由器的整个工作度有意义。这个结果指富有建设性的，即Parekh展示了导致限制的
原端行为，而且说明了这种行为的最坏可能。这就是指在这些假设条件下他所计算的限制是
所有可能结果中最好的。
       
链路共享   
    同一个WFQ可以提供控制链路共享。该服务目标在这里不是要限制延迟而是限制一个链
路上的超载共享，尽管在有空间的情况下允许处理任何混合通信量。WFQ的这种用法在现在
的商业路由器中就已使用了，而且用它来把通信量分割成类，这种分割是基于协议类型和应
用等一类的事情。例如，可以为TCP、IPX和SNA分配单独的一份（资源），还能够确保网络
控制通信量获得保证的链路共享。
           
可预测实时服务
这种服务实际上比保证服务还要微妙。它的目标是提供一种延迟限制，这个限制一方面要尽
可能的低，另一方面要足够的稳定，以便接收方能够对它进行估计。WFQ机制导致一个保证
限制，但不必是一个低的限制。事实上，把通信量混合在一个队列里，比将其如在WFQ中一
样分开，会产生更低的限制，只是这些混合通信量要基本相似。（例如，混合从多个视频编
码器来的通信量是可行的，但混合视频和FTP却是不行的。）      
    这意味着我们需要一个双重机制，第一重机制将通信量分成具有不同服务目标的类，然
后第二重机制对第一重所分类的通信量进行调度，已达到其服务目标。
        
4.3. 一个例子：CSZ模式
    作为这个概念的一个证据，一个代码包已被实现了，它实现上面所讨论的服务。实际上
它使用了多种基本工具，并与服务需求以一种特定的方式结合起来。我们描叙它工作的一般
条件，并且建议如何可以实现服务。我们强调还有其它的方法来建构一个路由器以满足同样
的服务需求，而且事实上现在已经使用其它的实现。
    在顶层，CSZ代码把WFQ当作一个单独的机制来使用，以便将各种保证流，以及其它通
信量分开。保证服务获得最高的优先级，当且仅当它需要这次访问来达到其最终期限要求。
WFQ为每一个保证流提供单独的保证。
    可预测服务和尽力而为服务在优先级上是分开的。在可预测服务类中，使用一个更进一
步的分级以提供具有不同延迟限制的子类。在每一个可预测服务子类中使用简单的FIFO排
队来混合通信量，这看来会导致好的整体延迟行为。这种方法之所以有效，是因为顶层算法
已将尽力而为通信量如FTP隔离开。
    在尽力而为服务类中使用WFQ来提供链路共享。因为可能有对嵌套共享的需求，这种
WFQ代码可以被递归的使用。在该代码中WFQ有两种不同的用法，一个是隔离保证服务类，
另外一个是隔离链路的个部分。它们大体上是相似的，只是细节不同。
    在尽力而为服务磊地每一个链接上，优先级被用来允许更多的对时间敏感的弹性通信量
优先于其它地弹性通信量，例如，允许交互式通信量优先于异步大批量传输。
    因此CSZ代码在一个交互方式中使用WFQ和分级来建构一个机制，以支持非常复杂的服
务提供。关于这方面的讨论是相当简略的，很多明显的问题都没有触及到，如CSZ代码是如
何是实时通信量适合于链路共享目标的。但其基本构件是相当简单的，而且非常有效。特别
地，尽管分级被提议为实时服务的一个关键，但WFQ在两种模式中可能是更通用而且更有效
的。是WFQ，而不是分级，支持保证服务和链路共享。
     
5. 预留设置协议
    在设计一个预留设置协议时要达到多个需求。首先它在根本上要被设计成能用于一个多
播环境，而且必须适用异源服务需求。它在方式上应提供灵活的控制，以使预留能在多播传
输树上的每个分支都能共享预留。应将它设计成基于在现有设置中添加或删除一个发送者和
/或接收者等动作的基础上。它必须是健壮的，而且能扩展到大的多播组。最后，它必须提
供高级资源预留，以及由此而产生的优先权。已设计出一个达到这些需求的预留设置协议
RSVP[RSVP93a, RSVP93b]。本部分概述RSVP的设计。
   
5.1.RSVP 概述
    图2 说明具有多个原端、多个目的端的一个特定共享的分布式应用的数据传送。箭头
表示数据从发送方S1和S2流向接收方R1、R2和R3，云代表由多播路由协议创建的分配网
格。多播分配复制从每一个发送方Si来的没一数据分组，然后发送给每一个接收方Rj。我
们把从S1到R1的单播当成一个特例，而且称这种多播分配网格为一次会话。会话是根据接
收方的普通IP（多播）目的地址来定义的。
     
                发送方                              接收方
                             _____________________
                            (                     ) ===> R1
                    S1 ===> (        多 播        )
                            (                     ) ===> R2
                            (        分 配        )
                    S2 ===> (                     )
                            (                     ) ===> R3
                            (_____________________)

图2   多播分布式会话

5.1.1.流规约和过滤器规约
    一般来讲，一个RSVP预留请求指定在一次特定会话中所有分组或它的一个子集要预留
的资源数量。这种资源数量是由流规约来指定的，而获得这些资源的分组子集则由过滤器规
约来指定。如果接入控制获得通过，流规约将被用来设置分组调度器中的资源类，而过滤器
规约将在分组分类器中实例化，以把适当的分组映射为这个类。选择一个特定类的分类器状
态子集在RSVP文档中是指一个（分组）“过滤器”。
    这个RSVP协议机制提供一个非常一般化的工具，用来创建和维护通过多播传输路径上
的网格的分布式预留状态。这些机制通常把流规约和过滤器规约当成不透明的二进制数据，
把它们传给本地通信量控制机器来解释。当然，应用中的服务模型必须指定如何对流规约和
过滤器规约进行编码。

5.1.2. 预留类型
RSVP提供几种不同的预留“类型”，由这些类型来决定汇聚在路由器中的多个接收者的资源
请求方式。这些类型允许更有效地预留资源以达到应用的需求。目前有三种预留类型，“通
配符”、“固定过滤器”以及“动态过滤器”。一个通配符预留使用一个不指定特定原端的过
滤器规约，因此所有发往相应目的端的分组可能使用一个预留资源的公共池。这允许在一个
组的所有分布式路径上作出单一的资源分配。通配符预留类型在支持视频会议方面是非常有
效的，这时至少有一个小数量的原端同时起作用，而且可能共享资源分配。
其它两种类型使用过滤器规约来选择原端。一个接收者可能希望接收来自一个固定的原端集
的数据，或者相反的，它可能希望网络能通过动态的更改过滤器规约来在不同原端之间切换。
动态预留确实允许一个接收者修改其原端而不需要附加的接入控制；但是这需要有充足的可
供分配的资源以处理当所有接收者从不同原端接收输入时的最坏情况。
              
5.1.3. 接收方初始化
    一个重要的问题是发送方或接收方是否负责预留的初始化。发送方知道他能发送的通信
量流的质量，而接收方知道他要（或可以）接收的流。也许最明显的选择就是让发送方初始
化预留。但是这不容易扩展到大的动态多播传送树以及异源接收方。
    这两个扩展问题通过由接收方来负责初始化预留而被解决。接收方初始化预留可以轻易
地处理异源接收；每一个接收者简单地请求一个适合自己的预留，然后网络通过RSVP来决
定（“合并”）来自不同接收者的不同的预留请求。 接收方初始化与IP多播也是一致的，这
是在一个由接收者参加而不明确地创建的多播组中。尽管接收方初始化是多播会话的自然选
择，但它对单播会话可能会要差一些，因此发送方可能是逻辑上的会话发起者。但是，我们
希望每一个实时应用都将具有更高级别的信令和控制协议，而且这种协议可以被用来通知接
收方初始化一个预留（而且也许表明将使用流规约）。为了简单性和经济性，一个设置协议
应只支持一个方向的初始化，而接收方初始化对我们而言是一个明显的胜者。