IP QoS的综合业务结构——Int-Serv

　　Int-SERV的三种业务

　　Int-Serv在RFC(Request for Comments)1633中进行了定义。RFC 1633将RSVP(资源预留协议)作为Int-Serv结构中的主要信令协议。该协议假定从接收方到发送方之间沿途的每个路由器都要为每一个要求QoS的数据流预留资源。该协议还建议使用端到端的信令。

　　Int-Serv使用一种类似ATM的SVC的方法，它在发送方和接收方之间用RSVP 作为每个流的信令。RSVP信息跨越整个网络，请求/预留资源。路径沿途的各路由器——包括核心路由器——必须为RSVP数据流维护软状态。

　　IP QoS的综合业务结构 (Int-Serv)定义了三种级别的业务：

　　有保证的业务(Guaranteed)——保证带宽，限制延迟，无丢包。

　　控制负载的业务(Controlled Load)——在一个负载较轻的网络中实现类似于尽力而为的业务。

　　尽力而为的业务(Best Effort)——类似当前Internet在多种负载环境(由轻到重)下提供的尽力而为的业务。

　　RSVP的工作原理

　　图1显示了RSVP的工作机理。首先，发送方应该向接收方发送一个RSVP信息。RSVP信息同其他IP包一样通过各个路由器到达目的站点；接收端接收到发送端发送的路径信息之后，由接收端逆向发起资源预留的过程；资源预留信息沿着原来信息包相反的方向对沿途的路由器逐个进行资源预留。

　　如图所示的例子，假设一个应用需要预留2Mbps的带宽，则资源预留信息逐个询问沿途的路由器，其现有资源是否可以完全满足该应用数据流的要求。如果资源预留信息成功地回到发送方，则发送方就可以成功地在这条已经预留资源的路径上发送应用数据了；否则，应用将无法进行。

　　Int-Serv的缺陷

　　可扩展性是Int-Serv结构最致命的一个问题，因为Int- Serv要求端到端的信令，这在一个实际运行的运营商网络中几乎无法实现。

　　其次，Int-Serv还有一个目前很难解决的问题，那就是资源预留和路由协议之间的矛盾。如图2所示，从路由协议角度来看它是一条好的路径；可从资源预留来看，路由器没有足够的资源可以预留，不能为应用数据流建立起一条路径，因此这一进程只能停留在这里，等待上层超时拆除这个应用进程，再重新建立路径。

　　第三，资源预留协议还要求沿途的每个路由器为每一个数据流都维持一个“软状态(Per-flow soft state)”。这无疑也限制了这种结构的可扩展性，因为每个路由器的内存有限，可以保存的软状态信息都是有限的，在一个运营商规模的网络中几乎不可能实现这一要求。

　　此外，如何为资源预留申请授权并确定优先权也是Int- Serv结构本身很难克服的问题。

　　除去上述这些具体的问题，单纯从Int-Serv结构的实质来看，资源预留本身就与IP网络的最大特点 “无连接”相冲突。在一个纯粹的IP网络中， Int-Serv是一个无连接的网络，它无需事先建立好一条链路，尔后再在上面传送数据，而是通过动态路由协议动态地根据网络拓扑的变化计算一条或者几条到达目的地的最短路径，将数据包发送出去。一个应用基本上可以不沿着同一条路径传送到目的地，这也是分组交换的特点。无连接的IP网络最大的优点就是不需要复杂的信令，只要网络有资源可以利用，因此人们通常将这种方式叫做“尽力而为”的传送方式。显然，这种方式的可扩展性很强，这大概也是在如此短的时间内Internet得以如此大发展的原因吧。

　　尽管这样，Int-Serv仍然有它的优点，它毕竟是目前在小规模范围内较易实现的一种解决方案。因此，目前业界普遍认为，Int-Serv极有可能会应用在企业网边缘，企业网中的用户数据流可在桌面用户一级进行管理。推动Int-Serv在桌面附近应用的一个重要因素是Microsoft在Windows 98、NT5.0中提供了RSVP和QoS功能。