思科ei CCIE网络工程师技术解析资源预留协议 -ielab

思科ei CCIE网络工程师技术解析资源预留协议 -ielabInternet网中存在着大量的中间节点。如果用户使用无连接协议来传输数据流，则该数据流的各个数据报在通过中间节点转发时可能会产生两个问题，一是各个数据报的转发路径不同，并非顺序到达目的端，有些数据报可能会延迟到达；二是数据报在中间节点排队等待转发时，其排队时间是不确定的，并且中间节点因资源缺乏而发生拥塞时，将会采取丢包策略来疏导交通，这对于端到端通信来说将意味着传输延迟和延迟抖动。这些对多媒体通信来说都是不利的，严重影响端到端多媒体通信的服务质量。解决这个问题的基本方法是端点和中间节点要密切合作，基于无连接协议，为特定的数据流建立固定的传输路径，并为其保留系统资源，将传输延迟限制在指定的范围内，从而保证了端到端多媒体通信的服务质量。IETF提出的RSVP(Resource Reservation Protocol)则是基于上述方法。

通常RSVP请求将会引起每个节点数据路径上的资源预留。

RSVP只在单方向上进行资源请求，因此，尽管相同的应用程序，同时可能既担当发送者也担当接受者，但 RSVP 对发送者与接受者在逻辑上是有区别的。 RSVP 运行在 IPV4 或 IPV6 上层，占据协议栈中传输协议的空间。RSVP不传输应用数据，但支持因特网控制协议，如 ICMP、IGMP 或者路由选择协议。正如路由选择和管理类协议的实施一样，RSVP的运行也是在后台执行，而并非在数据转发路径上。

RSVP本质上并不属于路由选择协议，RSVP协议的设计目标是与当前和未来的单播（unicast）和组播（multicast）路由选择协议同时运行。RSVP进程参照本地路由选择数据库以获得传送路径。以组播为例，主机发送 IGMP 信息以加入组播组，然后沿着组播组传送路径，发送RSVP信息以预留资源。路由选择协议决定数据包转发到哪。RSVP只考虑根据路由选择所转发的数据包的QOS。为了有效适应大型组、动态组成员以及不同机种的接收端需求，通过RSVP，接收端可以请求一个特定的QOS。

QOS请求从接收端主机应用程序被传送至本地RSVP进程，然后RSVP协议沿着相反的数据路径，将此请求传送到所有节点（路由器和主机），但是只到达接收端数据路径加入到组播分配树中时的路由器。所以，RSVP预留开销是和接受端的数量成对数关系而非线性关系。

由于RSVP报文必须向上游传播，经过所有中间路由器，最终到达所有的发送主机。然而路由选择协议缺少反向路由信息，因此RSVP引入了path报文。作为发送者参加多播组的所有主机都要发出path报文，经由分发树传输到所有的多播终点。

RSVP协议资源预留过程

　　1、发送数据的源端确定发送数据流所需的带宽、延迟和延迟抖动等指标，并将其包含在PATH分组中发给接收端。

　　2、在网络中的某一路由器接收到PATH分组时，它将PATH分组中的路径状态信息存储起来，该路径状态信息描述了PATH分组上的上一级源地址(即发来该分组的上一跳路由器地址)。

　　3、当接收端收到PATH分组之后，它沿着与PATH分组中获取的源路径相反的方向方式一个RESV分组。该RESV分组包含为数据流进行资源预留所需要描述的流量和性能期望等QoS信息。思科ei CCIE网络工程师技术解析资源预留协议 -ielab

　　4、当某一路由器接收到一个RESV分组时，它通过接纳控制来决定是否有足够的资源满足QoS请求。如果有，就进行带宽和缓冲区空间的预留，并且存储一些与数据流相关的特定信息，然后将RESV分组转发给下一个路由器;如果路由器必须拒绝该请求，则它返回给接收端一个错误信息。

RSVP资源预留消息由接收方发起并一次向上游传送，上游在这里是从接收方到发送方的方向。在途径的每一个结点上，资源预留请求会触发下面的两个动作：

1、在链路上进行资源预留

每一个结点上的RSVP进程（RSVP Process）都会将 请求资源预留的消息传递给接纳控制部件（Admission Control）和策略控制部件（Policy Control）。只要这两个部件中任何一个在检测是否可接纳时失败，那么资源资源预留请求就会被拒绝；同时，RSVP进程产生一个错误消息发送给接收方。如果二者都能成功，结点就会同时对分组流分类器进行相应的设置，从而在实际数据流传输时能够将这个预留的数据分组从进入路由器中的所有分组中挑选出来，进而为它提供QoS保证。

2、向上游结点转发资源预留请求思科ei CCIE网络工程师技术解析资源预留协议 -ielab