[转帖]下一代互联网关键技术IP QoS(2)

lcc_lin

在此过程中，我们注意到，和电信网络中的呼叫建立过程相反，RSVP是由接收端驱动的资源预留。其目的是考虑在组播的情况下，以接收端驱动，可以适应组播群成员的动态增减，以及各接收端要求不同QoS的异质请求情况。当通信结束或者一方退出会话后预留的资源可以由超时机制释放。RSVP还定义了显式的释放机制，通过PathTear由启动点沿下游方向传送至接收端，通知沿途各路由器释放资源。ResvTear则反向传送，功能相似。它们可由端系统发出，也可由路由器在状态超时时发送出。至此，业务流的传输路径已经建立起来了，数据流可以进行发送了。<br>RSVP可以看作是配置业务处理的机制，综合服务则是在RSVP信令基础上够用以提供端到端QoS保证的体系结构。IntServ设定网络设备支持业务的处理机制，保证每一个业务流严格独立于其他业务流的服务，并设定提供特定量化资源的服务。<br>从以上讨论可以看出，IntServ/RSVP服务模型对传统Internet体系结构的扩展主要包括在路由器中保存业务流状态信息以及明确的状态建立机制。这种模型在路由器中所保存的业务流状态信息是软状态信息，由于软状态信息在路由器发生错误时容易通过RSVP信令刷新而隐含地拆除并在另外路由器中重建业务流状态信息，而硬状态信息（hard state）需要明确地拆除状态信息，因而保持了网络体系结构的鲁棒性（robustness）。同时，由于这种模型有效地集成了各种实时应用和非实时应用，因而保持了网络的效率。另外，由于兼容了传统网络体系结构和协议栈，因此能对网络进行有效的管理。<br>
IntServ/RSVP的缺陷<br>从理论上讲IntServ/RSVP模型完全可以保证为IP网络提供QoS保障。但随后在一些网上的实验表明这种服务模型有很明显的局限性，这些问题主要表现在：这不仅表现在扩展性差上，更大的问题是它要求核心路由器必须保持经过它的每一个单个数据流的状态，而核心路由器是不能这么做的。另一个大问题是这种方法因此，尽管主要的路由器生产商和主机都支持RSVP,它也被广泛接受，但是它始终没有成为主流，原因是ISP们不愿意采用它，很少有大型网络采用它。近来，人们认识到RSVP的出路在于与区分服务配合工作，相辅相成。<br>
<br>
可扩展性差：可扩展性是IntServ/RSVP模型最致命的一个问题，其基于流的资源预留、调度处理以及缓冲区管理，有利于提供QoS保证，但状态信息随业务流数量的增长而增长，沿途的路由器要为每个数据流都维持一个"软状态"，而路由器的存储器容量有限,可以保存的软状态信息都是有限的，在一个运营商规模的网络中几乎不可能实现这一要求。 <br>
对路由器的要求过高，网络中所有的路由器都必须支持RSVP信令协议，接入控制程序，分类器以及调度器。 <br>
RSVP中引入每流状态（per-flow state）的概念，对于数据通信和实时应用通信而言，IP网络同时扮演了面向无连接和面向连接网络的两个不同角色，提供两种功能,这与其简化设计原则相抵触。 <br>
资源预留不适用于短时流，比如Web流等，而在因特网中Web流量超过了50％。 <br>
IntServ/RSVP还存在着资源预留和路由协议之间的矛盾。如图2所示，从路由角度来看它是一条好的路径，但从资源预留来看，由于没有足够的资源可以预留，不能为数据流建立起一条路径，因此这一进程只能停留在这里，等待上层超时拆除这个应用进程，再重新建立路径。<br>
<IMG SRC=../leadbbsfile/fileType/gif.gif border=0 onLoad="javascript:if(this.width>570)this.width=570;" onMouseover="javascript:if(this.width>570)this.width=570;" align=absmiddle>此主题相关图片<br>
<IMG SRC=../leadbbsfile/upload/2004/07/18/533893593750.gif border=0 alt=按此在新窗口浏览图片 onclick="javascript:window.open(this.src);" onLoad="javascript:if(this.width>570)this.width=570;" onMouseover="javascript:if(this.width>570)this.width=570;" style="cursor:hand" align=absmiddle><br>
<br>
因此，要实现IntServ的QoS保证是很困难的，它需要基于流的、复杂的资源预留、接纳控制、QoS路由和调度机制。在诸如互联网这种复杂的、大规模的网络中，链路状态是不确定的，有效地预留带宽资源非常困难。而且资源预留本身就与IP网络的最大特点"无连接"相冲突。更重要地问题就是IntServ面临地可扩展性（scalability）问题和鲁棒性（rubustness）问题，这主要是因为在分布式网络环境中，很难维持动态的、可复制的传输流状态一致性。<br>早期的IntServ是面向单流的，在路由器配置和使用多域分类准则，这给路由器尤其是主干网络核心路由器带来了巨大负荷。为了增加IntServ的扩展性，近期RSVP已经开始支持流聚集，即将沿相同业务流传输路径流聚合成宏流（macro-flow），按宏流来预留资源。这虽然减轻了核心路由器的一些负担，但IntServ本身的体系结构已经决定了其高复杂性，而且由于路径数是边界节点数的平方，宏流数仍然很庞大。<br>由于IntServ/RSVP体系存在着诸多问题，一种新的体系结构便应运而生，这就是区分服务体系结构(Differentiated Services，DiffServ)。<br>
<br>