| 在基于MPLS vpn 的政务外网中，Qos策略要支持差分服务（DiffServ）和集成服务（IntServ）
4 Diffserv 与Intserv相结合的端到端QoS提供机制
IP网络的QoS研究导致了两种截然不同体系结构的出现：Interv体系结构及其相应的信令协议RSVP，和Diffserv体系结构。但这两种IP网络的QoS标准都不能完全满足需要，如前所述它们各有自己的长处和局限。为了支持端到端的QoS，可考虑将Intserv、RSVP和Diffserv看作互相补充的技术，将其结合，互相协同，共同实现端到端的QoS提供机制。最终达到既能提供类似状态相关网络的强有力的服务，又能实现与状态无关网络近似的可扩展性和鲁棒性。目前，这两种技术的结合仍然是一个开放的研究课题。从应用的观点，这种结合将极大促进诸如IP电话、视频点播等多媒体应用以及各类非多媒体任务紧要应用的发展。
Intserv体系结构提供了一种在异类网络元素之上为应用提供端到端QoS的方法。一般来讲，网络元素可以是单独的节点（如路由器）或链路，更复杂的实体（比如ATM云或802.3网络）也可以从功能上视为网络元素。在这种意义下，DiffServ网络（或“网络云”）也可以视为更大的Intserv 网络中的一种网络元素。[注59]描述了一种在Diffserv网络之上实施Intserv的框架，描述了在Intserv体系结构下Diffserv网络支持端到端QoS的方法。
在该框架中，端到端的、定量的QoS是通过在含有一个或多个Diffserv区的端到端网络中应用Intserv模型来提供的。为了优化资源的分配和支持接纳控制，Diffserv区可以（但并不绝对要求）参加端到端的RSVP信令过程。从Intserv的角度看，网络中的Diffserv区被视为连接Intserv路由器和主机的虚链路。该框架的目标是实现Intserv区与Diffserv区无缝的相互操作，网络管理员可以自由选择网络中的哪个区作为Diffserv区。
4.1 Diffserv网络区支持Intserv/RSVP的意义
与Intserv/RSVP协同工作对于Diffserv网络区的意义主要在于以下三个方面：
（1）在Diffserv区实现基于资源的接纳控制
在Intserv网络中，量化的QoS应用使用显式信令RSVP从网络请求资源，网络作出接受或拒绝的响应，这称为“显式接纳控制”。显式接纳控制有利于网络资源的优化使用。而对于只提供聚集传输控制而无信令机制的Diffserv网络区，其接纳控制是以隐式的方式通过网络元素上的管制参数实现的。例如，Diffserv区入口的某个网络元素对EF DSCP只允许接受50Kbps的传输。隐式接纳控制能够在某种程度上对网络起到保护作用，但效率低。而且隐式接纳控制会破坏端到端显式接纳控制的有效性[注32]。如果在Diffserv网络中采用显式接纳控制（如利用RSVP），则能够保证对接纳的传输流实现资源预留（虽然以损害未被接纳的流为代价）。因此，为Diffserv网络区指定一个支持Intserv的接纳控制代理可以优化资源的使用，提高Diffserv区对于定量QoS应用的服务质量。
（2）在Diffserv区实现基于策略的接纳控制
在使用RSVP的网络区，资源请求可以被识别RSVP的网络元素截取，并按照策略数据库的策略进行检查。因为资源请求标识了其所代表的用户和应用，所以在进行接纳控制时，网络元素可以考虑基于每个用户或每个应用的策略。因此在Diffserv网络区采用RSVP 接纳控制代理，可以在决定资源分配时采用针对特定客户的策略，为特定的用户和应用有效地分配资源。否则，在没有RSVP信令的Diffserv网络区，策略典型地只能作用于发起传输的Diffserv客户网络，而不是客户网络中的某个传输发起用户或应用。
（3）传输识别及分类中的辅助作用
在Diffserv网络区内部，传输的资源分配基于每个IP分组头部标识的DSCP值，为此必须正确标记DSCP。这有两种实现机制：主机标记和路由器标记。主机标记要求主机知道网络如何翻译DSCP。这类信息可以配置于每个主机，但这加重了管理负担。一种较好的方案是：主机使用显式信令协议（如RSVP）通过询问网络来获取。[注60]对这种方案进行了描述。路由器标记要求必须在路由器配置MF分类准则。这可由主机操作系统通过请求动态完成、由手工配置或自动脚本静态完成。然而静态配置困难很大，一种更好的选择是允许主机操作系统代表用户和应用通过信令将分类准则发送给路由器，而RSVP正是理想的信令选择。
4.2 Diffserv网络区支持端到端Intserv的实现框架
在此框架中， Internet使用Intserv体系结构来为应用提供端到端的QoS。整个网络是Intserv节点（采用基于MF的分类和基于流的传输控制）和Diffserv区（采用聚集传输控制）的结合体。
该框架的参考网络如图4所示：
如图4所示，在支持Intserv的端到端网络中央含有一个Diffserv区，它包含许多连接的路由器，至少其中的一部分提供聚集传输控制。Diffserv区之外的区域（非区分服务区）也包含许多路由器和与之相连的主机，至少其中的一部分支持Intserv体系结构。为了简化，该参考网络只考虑一个QoS发送者Tx与一个QoS接收者Rx通过网络进行通信。邻近Diffserv区的边缘路由器（ER1， ER2）与Diffserv区内部的边界路由器（BR1， BR2）通过接口直接相连。
发送方和接收方主机都使用RSVP来传达主机应用的定量QoS请求。主机操作系统的QoS进程代表应用生成RSVP信令。RSVP消息在主机Tx和Rx之间端到端地传播以支持Diffserv区外部的RSVP预留，端到端的RSVP信令至少应被透明地传过Diffserv区。依赖于特定的实现，这些消息可能不会被Diffserv区的路由器处理，也可能被Diffserv区内的一些路由器甚至所有的路由器处理。
边界路由器ER1、ER2和BR1、BR2的功能都依赖于该框架的特定实现。在Diffserv网络区不识别RSVP的情况下，边界路由器ER1、ER2作为Diffserv区的接纳控制代理。它们处理来自Tx和Rx的信令消息，根据Diffserv网络区内部的资源信息和客户定义的策略来实施接纳控制。而Diffserv区内的边界路由器BR1、BR2只作为纯粹的Diffserv路由器，唯一的任务就是基于DSCP描述的服务级别和与客户协商的协议对传输实施聚集传输控制。在Diffserv网络区能够识别RSVP的情况下，边界路由器ER1、ER2根据当地的资源情况和客户定义的策略实施接纳控制，而边界路由器BR1、BR2参加RSVP信令过程并作为Diffserv网络区的接纳控制代理。
Diffserv网络区支持聚集传输控制，而不实现MF分类。依赖于该框架的特定实现，可能Diffserv区内部的一些路由器支持RSVP，则能够实现基于流的信令和接纳控制。如果Diffserv区的设备不支持RSVP，它们将透明地传递RSVP消息而不会对传输性能产生什么影响[注27]。
Diffserv区外部的网络包括Intserv主机和其他网络元素，如路由器和各种不同类型的网络（如802或ATM网络等）。这些网络元素可能支持Intserv，如果不支持，它们也应将RSVP消息不受妨碍地进行传送。另外，也不排除Diffserv网络区外边的路由器可以为通过它的传输子集提供聚集传输控制。
4.3 支持端到端Intserv的Diffserv网络区资源管理方案
在Diffserv网络上实施Intserv框架大体有两种基本的实现形式：
(1)网络中的Diffserv区以静态方式提供内部的资源管理，区内不含有能够识别RSVP的设备；
(2)网络中的Diffserv区以动态方式提供内部的资源管理，Diffserv区内部某些选定的设备参加RSVP信令过程。
具体而言，根据端到端Intserv传输流的需要，Diffserv网络区内的资源管理可以有多种实现方案：
4.3.1 静态资源管理方案
在此类方案中，Diffserv网络区的客户和网络所有者之间协商建立一个静态的契约——服务层描述SLS（Service Layer Specification），保证在每个标准的Diffserv服务级别上向客户提供应有的传输能力。Diffserv区和其外部的网络元素之间没有信令，它们之间的SLS协商是唯一的关于资源可利用性信息的交换形式。边界路由器ER1作为Diffserv网络区的接纳控制代理，配置了SLS所表示的信息。这种方案的缺点首先是灵活性差，不容易支持SLS的动态改变，因为SLS每次改变都需要重新配置ER1。另外，Diffserv网络区的资源也难于有效地利用，因为接纳控制无法充分反映Diffserv区中常受冲击的路径上的资源可利用性。
4.3.2 使用RSVP的动态资源管理方案
在此方案中，Diffserv网络区的边界路由器BR1支持RSVP，此外，在Diffserv网络区内的其它路由器也可能支持RSVP。但值得指出的是：虽然这些路由器参加某种形式的RSVP信令，但它们仍使用IP分组头部的DSCP值，对聚集传输流进行识别、分类和调度（聚集传输控制），而不象标准的Intserv/RSVP路由器使用基于流的MF分类准则。当一个新流要加入到行为聚集中时，就使用动态提供机制和显式信令进行接纳控制[注32]。此时，可以使用RSVP信令将流的描述和期望的DSCP传给Diffserv区的路由器。可以说，Diffserv区路由器的控制平面是RSVP而数据平面仍是Diffserv。这种方案既充分利用了RSVP信令的优越性，又保持了Diffserv的可扩展性。
在Diffserv网络区支持RSVP，接纳控制代理就是Diffserv网络中的一部分，可以通过RSVP将Diffserv网络区可用资源的改变通知给Diffserv网络外部的Intserv节点。这样不但可以提高Diffserv区内部资源使用的效率，而且提高了接纳控制的可信度。后者是由于接纳控制能够同常受冲击路径的资源可利用性建立联系，称为拓扑性（topology aware）的接纳控制。此方案的另一个好处就是可以根据Diffserv区外部的资源请求实现Diffserv网络区内部资源提供上的改变（如，给路由器中的EF队列分配更多或更少的带宽）。
在具体实现上，Diffserv网络区内部可以使用多种不同的机制来支持动态方案和拓扑性接纳控制。包括：聚集的RSVP方案、面向单个流的RSVP方案和使用带宽中介服务器（Bandwidth Broker，BB）等。
（1）聚集RSVP方案
许多草案都提出使用扩展RSVP的机制，即聚集RSVP[注27-31]。在Diffserv网络区的边界之间为聚集流预留资源，而不对来自Diffserv区以外节点的、面向单个流的RSVP请求进行接纳控制。聚集预留的量可以（或不必）动态地调整。这种方案的优点是：它为Diffserv网络区提供了动态的、拓扑性的接纳控制，而无须支持面向单个流的RSVP信令处理。由于每个区域都有可能选择其独特的管理资源机制，所以使用聚集RSVP进行资源管理的Diffserv网络区最适合于单一的行政管理区域。
（2）面向单个流的RSVP方案
在此方案中，Diffserv网络区内的路由器对发起于Diffserv区之外Intserv节点的、面向单个流的标准RSVP信令请求进行响应。这种方案同样具有（1）的优点，但不支持聚集RSVP。由于使用面向单个流的接纳控制，资源的使用具有更高的效率。然而，这种方案对于Diffserv网络区内的RSVP信令资源的需求量也比聚集RSVP方案大得多。
值得指出的是，在一个单独的Diffserv区内，面向单个流的RSVP与聚集RSVP并不相互排斥。可以在Diffserv区的边界使用面向单个流的RSVP，而只在Diffserv区内部的一些核心区使用聚集RSVP。
以上方案的具体实现中，网络管理员必须决定在Diffserv网络中参加RSVP信令的路由器数量。一种极端的情况是只有边界路由器参加RSVP信令，那么必须为Diffserv网络区提供过度的资源，或者必须仔细、静态地为Diffserv网络区有限的传输模式进行资源分配。另一种极端情况是Diffserv网络区的所有路由器都参加RSVP信令，则资源会被最优化使用，但信令处理的需求和相关的系统开销也会增加。前面讨论过的聚集RSVP就是一种以部分损害资源利用率来限制信令过程开销的方案。网络管理员须对此进行折衷考虑。
综上所述，在Diffserv网络区使用RSVP动态地提供资源的方案既充分利用了RSVP信令的优越性，又保持了Diffserv的可扩展性。因为Diffserv网络区内的路由器其控制平面是RSVP而数据平面仍是Diffserv。但事实上，既然采用了RSVP，就不可避免地引入了Intserv接纳控制的可扩展性和鲁棒性问题，目前这仍然是一个开放的研究课题。好的方案应该针对实际应用需求在资源利用的有效性与实现机制的复杂性之间进行折衷。
4.3.3 使用其他方式的动态资源管理方案
Diffserv网络区内部的边界路由器可以使用任何形式的RSVP信令、Boomerang协议[注61]或其它的定制协议与各Diffserv 区域的专用的集中管理实体——带宽中介服务器BB[注34]相互作用。BB含有资源可利用性和网络拓扑的充分的信息，负责记录本区域资源的占用情况，并据此对客户或相邻区域 BB的服务请求实施接纳控制。与传统的基于状态预留的网络所采用的分布式逐节点的接纳控制不同，BB以集中的方式在每个Diffserv区域或所有Diffserv区进行接纳控制[注62]。
一种实现方案可以只使用一个集中的BB来维护整个网络的拓扑和所有节点的状态，并基于BB实现接纳控制，删除了维护分布式预留状态的必要。这种完全集中式方案适合大多数传输流长期存在，建立和拆除事件不经常发生的情况。但是，如果需要支持精细粒度和动态流，就需要一种分布式的BB体系结构，对BB数据库进行复制或分割。目前分布式BB体系结构仍然是一个活跃的研究领域。我们可以设想这样一个体系结构：当一个BB接收到一个请求时，它基于自己的数据库，作出接收或拒绝的决定，而无须请求其他的BB。这避免了信令协议，但需要其他的协议来维护不同BB数据库之间的一致性。但实际上不可能获得非常好的一致性，这将导致竞争或资源破碎。至此问题转化为网络可扩展性和资源分割之间的一种基本的权衡：增加BB的数量可以使得方案具有更好的可扩展性，但同时增加了资源的破碎程度。目前， Diffserv控制路径上的接纳控制问题仍是一个开放问题，需要进一步解决。
4.4 Diffserv网络区支持端到端Intserv的研究展望
为了支持上述的集成框架，Diffserv网络区必须满足以下需求：
（1）必须能够在Diffserv网络区的边界路由器之间为标准的Intserv QoS服务提供支持，在Diffserv区内部使用标准的PHB来调用这些服务；
（2）必须在Diffserv区的边界节点执行适当的管理、控制（如包括整形或重标记）；
（3）Diffserv网络区必须基于资源可利用性，为其客户（非区分服务）网络提供接纳控制机制。
（4）Diffserv网络区必须至少能够透明地传递RSVP消息，以便在Diffserv区出口可以重新获取这些消息。Diffserv网络区可以（但并不绝对要求）对RSVP消息进行处理。
要满足上述需求，以下问题有待进一步研究：
（1）Intserv类型服务描述到Diffserv网络区提供的服务之间的映射[注63]；
（2）定义Diffserv网络区内使用聚集传输控制的网络元素在支持RSVP信令时所需的功能；
（3）定义在Diffserv网络区内有效、动态的资源提供机制（如聚集RSVP，隧道，MPLS等），以及BB如何将Diffserv区内的资源可利用性信息传递到边界路由器的定制协议等。
目前，实现Intserv与Diffserv的结合以提供端到端QoS仍然是一个开放的研究课题。在此方面已经提出了若干不同的研究方案和实现机制，典型的有：面向SCORE（Scalable Core）的”动态分组状态”DPS（Dynamic Packet State）方案[注62, 64]，在分组头部对传输流的状态进行编码，但存在实现上的困难；一种基于三种优先级别的带宽确保型服务（BGS）机制来提供端到端的QoS[注11]；文献[注65]提出了另外一种在Diffserv的网络云中结合RSVP协议提供资源预留和QoS保证的框架，其中Diffserv网络云的边界设备ED允许与RSVP协同工作，而其内部的路由器不识别RSVP消息，Diffserv网络的接纳控制在接纳控制服务器ACS的协助下完成，ED与ACS之间通过叫做“简单接纳控制协议”的client/server协议进行通信。
综上所述，Diffserv适合在网络主干实现QoS，端到端的IP QoS则需要实现Intserv与Diffserv的有机结合。而这必须以上述的基本框架为指导，综合考虑有效性与可扩展性，研究更好的实现方案及其算法和协议。目前，虽然基本框架和试验方案已经为研究提供了一定的基础，但要实现真正的端到端的QoS，还有很远的路要走。 |
