《端到端QoS网络设计（第2版）》一6.2 资源预留协议

本节书摘来自异步社区《端到端QoS网络设计（第2版）》一书中的第6章，第6.2节，作者【美】Tim Szigeti , 【加】Robert Barton , 【美】Christina Hattingh , 【美】Kenneth Briley，更多章节内容可以访问云栖社区“异步社区”公众号查看

6.2　资源预留协议

端到端QoS网络设计（第2版）
资源预留协议（RSVP）是一项可感知网络环境的技术（因此也称为“径内”AC工具），它可以在数据流获准进入网络之前，沿着数据流会途径的真正路径来分配带宽。因此，RSVP拥有双重功能：访问控制与带宽预留（或为某个数据流预留隧道的保障带宽）。其中第一项功能（准入控制）很容易扩展，而第二项功能（在数据流到达前预留带宽）则不容易扩展（至少无法在动辄上万数据流共存的网络汇聚骨干中进行扩展）。因此，人们常常在设计网络时，在网络边缘部署RSVP来作为一种AC工具（集成服务[IntServ]），同时在网络深处的节点使用更具扩展性的差分服务（DiffServ）工具来对汇聚流量进行分类、队列与带宽管理。

6.2.1　RSVP概述

RSVP是一个以流为单位（per-flow）发挥效用的协议，它会请求数据流路径中的每个节点为流量预留带宽。端点（或其他代表端点的网络设备）会发送单播的信令消息，以在数据流获准进入之前，为其预留带宽。图6-1所示为基本的RSVP操作。

通过图6-1可以看出：

• 在理想的情况下，数据流路径中每个启用了RSVP的路由器都会查看到这些消息，并根据接口的配置为指定数据流分配相应的带宽；
• 在更贴近现实的环境中，网络骨干内部那些没有RSVP功能的节点只会将消息转发给边缘节点进行查看；
• 当设备1向设备2发起一条会话时，它（或者距离作为代理的那台设备最近的路由器）会沿着与实际数据流最终将采取的路径相同的道路来发起RSVP预留消息；
• 若各处带宽均充足，预留就会成功，会话就会获准进入网络当中；

-如果设备3发起了一次会话，但路径中有些位置带宽不足，预留就会失败，会话就不会获准进入网络。

RSVP以及具体的操作方式在多个IETF（互联网工程任务组）RFC中均有记载，包括RFC 2205-2212、2747、2961、2998、3175、3209、3936、4420、4874、4874、5151、420、5711，读者可以在http://www.ietf.org/rfc.html查看这些文档。

6.2.2　RSVP代理

大多数终端设备，如电话与视频端点（独立设备以及移动设备、平板和电脑上的软件应用）并不支持RSVP协议栈。如需以RSVP协议为这些设备发起的会话提供AC机制，就需要让距离这些设备最近的路由器来充当代理，如图6-2所示。

（与端点设备同处于站点中的）路由器会使用RSVP代理配置，与Cisco统一通信管理器（CUCM）结合起来，在会话获准进入网络之前建立AC。在应用程序的层面上，CUCM拥有准入的最终决策权，但它会通过（启用了RSVP的）路由器所获得的网络状态，来辅助自己作出判断，这可以将（集中策略导向的应用级，centralized policy-oriented application-level）AC工具，以及（像RSVP这类）了解拓扑情况的协议，这两者的功能结合起来。

6.2.3　RSVP部署模型

RSVP有两种操作模型，如图6-3所示。

IntServ模型（集成服务模型）：这是传统的RSVP操作模型，但由于这种模型存在扩展性方面的缺陷，因此当前已经并不常用。

IntServ/DiffServ模型（集成服务/差分服务模型）：控制层面的操作与数据层面的操作相互独立。RSVP的操作仅限于AC功能，同时由DiffServ机制处理分类、标记、限速及调度操作。因此，IntServ/DiffServ模型扩展性极强，亦极为灵活。

如图6-3所示，在IntServ/DiffServ模型中，RSVP只用于执行AC（控制层面功能）；所有其他的QoS功能（包括分类、标记、限速、整形、队列与丢弃等）都由DiffServ策略进行处理，而后者都术语数据层面的功能。这种组合方式可以有效地扩展策略。

图6-3右侧的IntServ/DiffServ模型，是在可扩展的部署环境中以RSVP协议充当QoS AC机制的推荐模型。这种模型可以进一步分为两种设计方案，这两种设计将在下一节中进行详细介绍。

基本RSVP设计方案。

高级RSVP设计方案（具有应用ID功能）。

1．基本RSVP设计（IntServ服务/DiffServ服务模型）

在配置了IOS RSVP代理之后，管理员可以在接口配置模式下输入命令ip rsvp bandwidth来启用基本的RSVP功能，这条命令可以指定接口需要根据RSVP的请求而为其预留多少带宽（默认为预留链路带宽的75%）。

如果所有的优先级流量都启用了RSVP，那么命令ip rsvp bandwidth中指定的数值，以及LLQ（低优先级队列）命令priority就要匹配。但是，如果有些优先级流量没有启用RSVP，那么命令ip rsvp bandwidth中所指定的数值，与带外的呼叫AC机制所指定的数值之和，绝不能超过LLQ命令priority所指定的带宽。

在网络的WAN边界应该启用RSVP，包括WAN链路两端的路由器WAN接口，以及所有WAN拥塞点（包括不同速率的冗余链路）。而在高带宽的园区网中，RSVP的应用则并不普遍，因此园区网边缘（即终端设备连接到交换机而非路由器的环境）不会在这里进行讨论。

配置IntServ/DiffServ RSVP模型需要在接口下多添加两条命令，即ip rsvp resource provider none与ip rsvp data-packet classification none。这两条命令的作用是让RSVP不要去执行那些应当由DiffServ策略进行处理的数据层面的QoS操作。

例6-1所示为基本的IntServ/DiffServ RSVP配置。

例6-1　RSVP IntServ/DiffServ模型的配置

2．高级RSVP设计（IntServ服务/DiffServ服务模型）

RSVP本地策略提供了一种机制，可以根据应用的ID来控制资源预留的配额。管理员通过命令ip rsvp policy identity可以在应用ID与RSVP本地策略之间建立一个映射关系。RSVP本地策略身份（local policy identity）需要在全局进行定义，然后再在接口下调用实施。每个身份都可以定义一个策略定位标记（policy locator）来匹配应用ID。

为了让用户尽可能灵活地使用应用策略定位标记来匹配本地策略，RSVP本地策略命令可以使用UNIX格式的正则表达式作为应用ID的匹配标准。

CUCM可以为语音和视频流量设置RFC 2872应用ID，这个应用ID会成为集群范围内的服务参数（clusterwide service parameter）。在默认情况下，CUCM使用的应用ID为：语音流——AudioStream、视频流——VideoStream（同时代表视频流中的音频与视频成份）。因此，在全局配置模式下定义（与CUCM语音和视频流量的应用ID相匹配的）相应RSVP策略身份的命令（分别）为：

ip rsvp policy identity rsvp-voice policy-locator .AudioStream.

ip rsvp policy identity rsvp-video policy-locator .VideoStream.

接下来，需要通过命令ip rsvp policy local identity将基于应用ID的本地策略应用到接口上。例6-2显示了如何通过配置，来为语音和视频应用ID分配不同的本地策略。

例6-2　配置应用ID的RSVP本地策略

6.2.4　RSVP和LLQ

在使用RSVP IntServ/DiffServ模型的设计环境中，RSVP只会（通过命令ip rsvp bandwidth）执行AC功能，而由LLQ通过基于类的规则来控制队列算法（往往需使用差分服务代码点[DSCP]标记来实现）。图6-4显示了这种模型的工作方式。

部署了RSVP与LLQ的设备并不会控制以哪些带宽值来满足RSVP请求，它只会根据请求作出响应。因此，用哪个值来满足端点、应用或代理的RSVP请求对于不同的端点和应用而言，可能会存在相当大的差异（尤其是在一个会话中，对带宽的需求波动极大的视频流量）。

LLQ和基于类的队列（CBWFQ）代理只需如常配置，然后在接口上为它们分配带宽。不需要通过命令ip rsvp bandwidth来预留带宽；这条命令的作用是启用AC技术来判断哪些数据流应该获准，哪些数据流则应该拒绝。RSVP流量会根据LLQ规则分配到不同的队列。如果存在非RSVP的实时应用，可以使用命令priority来处理RSVP与非RSVP数据流，并确保非RSVP流会通过其他形式的AC来确保它们不会超额占用带宽。

如果为了针对不同的应用而更加精确地控制带宽的分配情况，而采取了RSVP与应用ID共用的设计方案，那么RSVP与LLQ之间的相互关系如图6-5所示。

总的来说，LLQ与RSVP还是会按照图6-4所示的方式协同工作，但RSVP流不仅会以ip rsvp bandwidth命令作为唯一的匹配标准，还会匹配包含了数据流应用ID的本地策略（也就是命令ip rsvp policy local identity中指定的带宽）。