Intserv和RSVP

(2)包含着共性数据流的特征和需求信息的RSVP初始化信息分组在到达预定接收端的过程中，被传输路径上各节点的性能信息修正，形成路径描述表。例如，共性数据流的某个要求是传输节点必须具有1KB的最大可传输单位(MTU),那么沿途的每个路由器都要给出声明，表明它是否有1KB的MTU或是否愿为该共性数据流提供1KB的MTU。

(3)初始化信息到达接收端后，RSVP就将路径描述表送给应用程序，应用程序可以根据要求来选择合理的路由。一旦接收端应用程序整理出它的需求，它就将其回送给RSVP。

(4)RSVP将接收端的需求逆着所选路径传给发送端，并沿途取得路由器的属性信息。

(5)发送端的RSVP进程接收到信息后，就通知发送程序已开通一条可用路由，并指明该路由的特性。

(6)当发送端初始化信息中的信息流特征描述与接收端要求的属性相匹配时，路由器确认该路由可用并记录该路由属性。尽管Intserv的过程有些复杂，但毫无疑问，保存特定信息流的网络特征还是值得的——至少从个人应用的角度讲应是如此。不难想像，通过Intserv过程，网络上的任何设备可在任何时间，为它们所进行的任何操作向网络申请确定的服务级别，或者在只需要网络提供尽最大努力的服务时不提出任何请求。然而Intserv也有其局限性。其一表现为它更多地依赖于Internet的发展规模，而非协议的设计。尽管服务器发送成百上千的RSVP请求并不困难，但由于它要处理同时连在其上的所有用户，因此，网络核心部分的路由器就要有能力保存所有同时经过的信息流的状态信息。这些状态信息就不仅关系到一台服务器和连在其上的用户，而且关系到许多服务器和这些服务器所带的所有用户。因此，位于信息交换密集处的路由器就要同时跟踪百万条交互信息，并为这些交互信息的传输分组分配路由。

            因此，RSVP也像其他全局性协议那样有其缺陷，即：即使通信流量并不大，它对节点却可能有较大影响，因为节点需要分配进程资源和存储单元来管理通信流量，记录状态信息。主干线上的路由器光是进行简单的分配路由和存储网络可达性信息（运行选路协议）的工作就够大了，还不包括对进程状态信息的管理，这种管理只会增加路由器间的时延。当Internet网络规模增大，速度提高时，需要管理的流量状态信息也相应增加。阻碍RSVP广泛应用的另一个原因是ISP间不易达成共识。ISP若允许RSVP信息流注册和传送，就要支持同样的QoS控制功能，为给定信息流提供合适的服务等级和足够的存储容量。ISP可能不愿接受这些条件，而使合作失败。

            由于上述原因，许多人认为Intserv和RSVP仅在边缘路由上有价值。例如，某个特定ISP的所提供的个人VoIP呼叫业务或由单一ISP提供的IP电话业务和其他实时性业务（只要ISP是处于一种管理认证模式下）。显然，Intserv不适合支持大规模VoIP业务和其他Internet上的实时业务。