22RSVP在 Mobile ip上应用存在的主要问题 (1) Mobile ip协议中,从发送方到移动节点的路径,如果没有采用路由优化的话,应包 含一条从移动节点的家乡代理到它的转交地址的隧道。隧道的引入给在MblP上应用 RSVP带来很大的麻烦。首先,在隧道中采用的是PinP封装,RVP消息对位于隧道中的 那些路由器来说是不可见的。这样就造成了不能在移动节点( Mobile node)的家乡代理(HA) 和外地代理(FA)之间资源预留。其次,隧道中的PiP封装,使位于隧道中的路由器不 能区分数据流,从而没法决定是否要对经过封装的数据包进行特殊处理,从而保证特定的 OoS (2)RSVP中,基于发送方所发送的 RSVP Path消息,接收方请求预留网络资源, 此时并不考虑网络本身的特性。在移动环境下,移动节点总在不断地改变它们的位置,这种 位置变化最快可以ls就发生一次。由于RSVP只在一条特定路径上预留资源,那么从发送方 到移动节点的路径经常发生变化也就意味着移动节点每次切换链路都要重新进行资源预留 怎样在移动节点每次切换链路时快速获得资源是在 Mobile ip上保证Qos的关键问题 23RSVP和 Mobile ip的结合 (1)在IP隧道中提供RSVP支持 在隧道中支持RSVP操作如图2所示我们把在发送者( sender)和接收者( Receiver)之 间的RSVP会话称为端到端的RSVP会话。从图2中我们可以看到,端到端的RSVP会话在 隧道入口路由器( Rentry)和隧道出口路由器(Rext)之间被映射成一个新的RSVP会话,我 们称这个新的RSVP会话为隧道RSVP会话。在这个新RSⅤP会话中, Rentry发送 Tunnel Path 消息Rext发送 Tunnel Resv消息以建立隧道中的资源预留。 Tunnel Path、 Tunnel Resv和端 到端 Path resv有着相同的结构,只是隧道中的RsVP消息的P头中源地址和目的地址改为 了隧道入口地址和隧道出口地址。在封装时端到端的Path消息加一个额外的会话关联项 ( SESSION ASSOC object),这个会话关联项包含了从隧道内的预留到隧道外的端到端的预 留之间的映射信息。这样就解决了位于隧道中间的路由器不能识别RSVP消息这个问题了 同时为了在隧道中识别不同的数据包,我们使用用户数据报协议(UDP)对数据包进行封装 也就是让隧道中不仅仅包含一个IP报头,还包括一个UDP报头,UDP报头的源端口可用来 区分进入隧道的数据包,目的端口设为一个特定的端口号。这样隧道出口路由器可以根据 UDP报头的目的端口识别封装的分组,而隧道中的路由器认为这是普通的UDP分组。这种 机制使得仅要在 Mobile ip中对家乡代理、外地代理和移动节点进行一些修改,就可以在隧 道应用RSVP协议 图2在隧道中RSⅤP操作 (2) Mobile RSVP 在移动环境下,资源预留的难点着重在移动节点和基站之间资源的有效预留和分配, Mobile rsvp的主要思想是在移动节点可能移动到的区域上预先设定一个被动资源预留 ( Passive reservation)。相对应,移动节点当前所在路径上的称为激活资源预留( Active reservation)。当移动节点切换到有被动资源预留的区域时,能很快获得目前应用业务所需的 资源。当移动节点不在有被动资源预留的区域时,这个被动资源预留可以供其他用户使用。 同时,在移动节点和基站之间使用CBQ( Class Based Queueing)机制调度无线链路资源共享。 Mobile rsvp的工作过程如图3所示,移动节点M位于基站BSa,为了简单起见,设路2.2 RSVP 在 Mobile IP 上应用存在的主要问题 （1）Mobile IP 协议中，从发送方到移动节点的路径，如果没有采用路由优化的话，应包 含一条从移动节点的家乡代理到它的转交地址的隧道。隧道的引入给在 Mobile IP 上应用 RSVP 带来很大的麻烦。首先，在隧道中采用的是 IP-in-IP 封装，RSVP 消息对位于隧道中的 那些路由器来说是不可见的。这样就造成了不能在移动节点（Mobile Node）的家乡代理（HA） 和外地代理（FA）之间资源预留。其次，隧道中的 IP-in-IP 封装，使位于隧道中的路由器不 能区分数据流，从而没法决定是否要对经过封装的数据包进行特殊处理，从而保证特定的 QoS。 （2） RSVP 中，基于发送方所发送的 RSVP Path 消息，接收方请求预留网络资源， 此时并不考虑网络本身的特性。在移动环境下，移动节点总在不断地改变它们的位置，这种 位置变化最快可以 1s 就发生一次。由于 RSVP 只在一条特定路径上预留资源，那么从发送方 到移动节点的路径经常发生变化也就意味着移动节点每次切换链路都要重新进行资源预留。 怎样在移动节点每次切换链路时快速获得资源是在 Mobile IP 上保证 QoS 的关键问题。 2.3 RSVP 和 Mobile IP 的结合 （1）在 IP 隧道中提供 RSVP 支持 在隧道中支持 RSVP 操作如图 2 所示,我们把在发送者（sender）和接收者（Receiver）之 间的 RSVP 会话称为端到端的 RSVP 会话。从图 2 中我们可以看到，端到端的 RSVP 会话在 隧道入口路由器(Rentry)和隧道出口路由器（Rexit）之间被映射成一个新的 RSVP 会话，我 们称这个新的 RSVP 会话为隧道 RSVP 会话。在这个新 RSVP 会话中，Rentry 发送 Tunnel Path 消息,Rexit 发送 Tunnel Resv 消息以建立隧道中的资源预留。 Tunnel Path、Tunnel Resv 和端 到端 Path Resv 有着相同的结构，只是隧道中的 RSVP 消息的 IP 头中源地址和目的地址改为 了隧道入口地址和隧道出口地址。在封装时端到端的 Path 消息加一个额外的会话关联项 （SESSION_ASSOC object），这个会话关联项包含了从隧道内的预留到隧道外的端到端的预 留之间的映射信息。这样就解决了位于隧道中间的路由器不能识别 RSVP 消息这个问题了。 同时为了在隧道中识别不同的数据包，我们使用用户数据报协议（UDP）对数据包进行封装， 也就是让隧道中不仅仅包含一个 IP 报头，还包括一个 UDP 报头，UDP 报头的源端口可用来 区分进入隧道的数据包，目的端口设为一个特定的端口号。这样隧道出口路由器可以根据 UDP 报头的目的端口识别封装的分组，而隧道中的路由器认为这是普通的 UDP 分组。这种 机制使得仅要在 Mobile IP 中对家乡代理、外地代理和移动节点进行一些修改，就可以在隧 道应用 RSVP 协议。 图 2 在隧道中 RSVP 操作 （2） Mobile RSVP 在移动环境下，资源预留的难点着重在移动节点和基站之间资源的有效预留和分配， Mobile RSVP 的主要思想是在移动节点可能移动到的区域上预先设定一个被动资源预留 （Passive reservation）。相对应，移动节点当前所在路径上的称为激活资源预留（Active reservation）。当移动节点切换到有被动资源预留的区域时，能很快获得目前应用业务所需的 资源。当移动节点不在有被动资源预留的区域时，这个被动资源预留可以供其他用户使用。 同时，在移动节点和基站之间使用 CBQ(Class Based Queueing)机制调度无线链路资源共享。 Mobile RSVP 的工作过程如图 3 所示，移动节点 M 位于基站 BSa，为了简单起见，设路