移动 IP上的QoS 保证
作者：丰勇 李方伟 发布日期：200201
(重庆邮电学院 重庆 400065)
摘 要 本文首先分析了基本QoS协议在移动IP上存在的问题并讨论其解决办法，在此基础上介绍了一种在移动IP上提供端到端的QoS机制。
关键词 移动IP 服务质量 资源预留协议
1 引言
随着移动通信技术和因特网技术的迅猛发展以及因特网信息资源的日益丰富，人们不再满足在固定地点从Internet检索、传输信息，希望在任何时候、任何地点都能方便地访问Internet。因特网工程任务组IETF（Internet Engineering Task Force）为了迎合这种需求，制定了移动IP（Mobile IP）协议，它是传统Internet的有效延伸和扩展。Mobile IP是一种在全球Internet上提供移动功能的方案，使节点在切换链路时仍可保持正在进行的通信。它提供了一种IP路由机制，使移动节点以一个永久的IP地址连接到任何链路上。Mobile IP的可扩展性使其可以在整个Internet上应用。
传统的IP网络只有一种服务类型，即尽力而为的（Best Effort）服务模型。当新的Internet应用，如多媒体数据传输之类的实时应用出现时，“尽力而为”服务就不能很好地适应，传输延迟、抖动和包丢失极大地影响了实时应用的效果。这就要求网络提供一定的服务质量（QoS），使得某些应用获得非缺省的服务,这就是QoS协议要做的事情。在移动环境下，由于无线网络拓扑和资源是动态变化和不可预测地，并且其资源有限，有效带宽不可预测，差错率高，从而在移动IP上提供QoS将是一个非常棘手的问题。
2 在移动 IP上应用RSVP
目前在IP网络上实现QoS有很多种技术，资源预留协议(RSVP)就是其中主要的一种。RSVP可以提供最高等级的QoS，但RSVP是为传统IP网络设计的，在移动IP上应用还存在着一些问题。
2.1 资源预留协议
RSVP（资源预留协议）被主机用来为应用程序向网络请求特定的资源需求，也被路由器用来在数据流传输的网络通路上建立并维持一些资源预留状态从而提供所要求的服务。RSVP是最复杂的QoS技术。在协议栈中，RSVP运行在IP层之上，占据传输层位置。但RSVP本身并不传输任何高层的数据，它只是一个因特网控制协议，类似于ICMP、IGMP或路由协议。RSVP不是一个路由协议，它需要与现有的路由协议一起工作，从本地路由协议那里获得路由，RSVP只和在这些路由上传输的数据流获得的QoS相关。为了有效地适应多种接收者要求，RSVP让接收者负责申请特定的QoS。
RSVP的工作过程如图1所示。发送方发送包括业务类别（Tspec）的PATH信息(放在路由包后)到接收方，每一RSVP路由器存放PATH信息和前一级源地址。接收方发送预留请求(RESV)信息（包含业务类别（Tspec），请求类别（Rspec）和过滤类别（filter spec））。 RSVP路由器按源路由接收RSEV信息，使用录入控制鉴别请求并分配所需的资源，并进行相应的确认，当发送者和接收者结束对话时，将拆除预留。
图 1 RSVP建立预留的过程
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，为了简单起见，设路由器R为发送方。M和Bsa之间已经建立了激活（Active）资源预留。因为M有可能移动到BSa周围任一基站，所以在建立了Bsa和M之间的激活（Active）资源预留后，也要为Bsa和BSb，BSc，BSd等之间建立被动（Passive）资源预留，同时在这些基站预留一个接口，以便M
图3 Mobile RSVP的工作过程
移动到这个基站时能快速获得预留的资源。这些被动（Passive）预留的资源在移动节点M没有用到时，可以被其他的用户使用，避免了资源的浪费。同时一旦移动节点M移动到了这个基站，其他用户必须让出这些资源给移动节点M使用。图3（b）显示了当M移动到BSf时，Bsa和BSf之间的被动（Passive）资源预留被激活，同时M也通过BSf预留的那个接口激活了和BSf之间的链接。利用这种机制可以很好地解决移动节点快速切换链路时在移动节点和基站之间获得QoS保证。
3 移动IP上端到端的QoS
RSVP性能好,但扩展性较差。因为其工作方式是基于每个流的，这就需要保存大量的与分组队列数成正比的状态信息；此外，RSVP的有效实施必须依赖于分组所经过的路径上的每个路由器。在骨干网上，业务流的数目可能会很大，同时它还要求路由器的转发速率很高，这使得RSVP 难于在移动IP上实现端到端的QoS。为了解决这一问题我们先介绍另外一种基本QoS协议――区分服务协议(Diffserv)。
3.1 区分服务协议
Diffserv（区分服务协议）通过汇聚(Aggregate) 和每一跳行为PHB(Per Hop Behavior) 的方式来提供一定程度上的QoS保证。汇聚的含义在于路由器可以把QoS 需求相近的各业务流看成一个大类，以减少调度算法所处理的队列数；PHB的含义在于逐跳的转发方式，每个PHB对应一种转发方式或QoS要求。
Diffserv的协议机制体现在DS字节。Diffserv定义了一个新的IP头格式来进行服务区分，称为DS字段，在IPv4中采用TOS（Type of Service）字段，在IPv6中采用Traffic Class字节来分类，IP头被划分为6bit的区分服务码点(DSCP)和2bit的未用字段。每一个分组将按不同业务的服务质量来给定一转发对待，并定义了一个基本的转发对待(PHB)集。
Diffserv目前主要有两种服务类型，加速转发和确保转发。加速转发（EF）规定最小时延和抖动，提供高水平的汇聚QoS。超过流文件（Traffic Profile）的流被抛弃。确保转发（AF），不符合AF流文件的流将不被转发、缓存或降低服务质量转发。
DiffServ 简化了信令，对业务流的分类颗粒度较粗，在移动环境下对实时业务的支持上还存在着一定的缺陷。但Diffserv扩展性强，可以把Diffserv作为RSVP的一个很好的补充。
图4 RSVP和Diffserv结合实现端到端的QoS
3.2 端到端的QoS保证
RSVP和Diffserv在Mobile IP 上提供QoS时，各有优点和局限。我们可以将RSVP和Diffserv结合起来提供端到端QoS。骨干路由器采用Diffserv，主机可以进行RSVP请求，在骨干接入点的边界路由器把它映射到DS字节，而在骨干网输出点路由器又把它复原为RSVP并送至最终目标，如图4所示。
4 结束语
本文描述了对一些基本QoS协议的改进，介绍了一种在移动 IP上提供端到端的 QoS机制。这些改进方案和端到端QoS体系结构中的一些协议还不是非常完善，而且还要考虑诸如今后对组播支持、网络安全和移动IP中快速切换、平滑切换这样的问题，这些问题还要进一步研究。
参考文献
1 RFC2746.RSVP Operation Over IP Tunnels
2 Indu M,Sivalingam K M.Architecture and experimental results for quality of service in mobile networks using RSVP and CBQ,in ACM/Baltzer Wireless Networks Journal,2000,6(3):221～234
3 Rexhepi V,Karagiannis G,Heijenk G,A framework for QoS & mobility in the Internet next generation.In,Proceedings EUNICE 2000,Sixth EUNICE Open European Summer School,University of Twente,Enschede,the Netherlands,2000,9:13～15
QoS over Mobile IP
Feng Yong Li Fangwei
（Chongqing University of Post & Telecom,Chongqing 400065）
Abstract This paper first analyzes the problem of basic QoS protocols over mobile IP and discuss the solutions for the problem,Last,we introduce a end-to-end QoS architectural framework over mobile IP.
Key words mobile IP，QoS，RSVP
（收稿日期：2001-10-16）
作者：丰勇 李方伟 发布日期：200201
(重庆邮电学院 重庆 400065)
摘 要 本文首先分析了基本QoS协议在移动IP上存在的问题并讨论其解决办法，在此基础上介绍了一种在移动IP上提供端到端的QoS机制。
关键词 移动IP 服务质量 资源预留协议
1 引言
随着移动通信技术和因特网技术的迅猛发展以及因特网信息资源的日益丰富，人们不再满足在固定地点从Internet检索、传输信息，希望在任何时候、任何地点都能方便地访问Internet。因特网工程任务组IETF（Internet Engineering Task Force）为了迎合这种需求，制定了移动IP（Mobile IP）协议，它是传统Internet的有效延伸和扩展。Mobile IP是一种在全球Internet上提供移动功能的方案，使节点在切换链路时仍可保持正在进行的通信。它提供了一种IP路由机制，使移动节点以一个永久的IP地址连接到任何链路上。Mobile IP的可扩展性使其可以在整个Internet上应用。
传统的IP网络只有一种服务类型，即尽力而为的（Best Effort）服务模型。当新的Internet应用，如多媒体数据传输之类的实时应用出现时，“尽力而为”服务就不能很好地适应，传输延迟、抖动和包丢失极大地影响了实时应用的效果。这就要求网络提供一定的服务质量（QoS），使得某些应用获得非缺省的服务,这就是QoS协议要做的事情。在移动环境下，由于无线网络拓扑和资源是动态变化和不可预测地，并且其资源有限，有效带宽不可预测，差错率高，从而在移动IP上提供QoS将是一个非常棘手的问题。
2 在移动 IP上应用RSVP
目前在IP网络上实现QoS有很多种技术，资源预留协议(RSVP)就是其中主要的一种。RSVP可以提供最高等级的QoS，但RSVP是为传统IP网络设计的，在移动IP上应用还存在着一些问题。
2.1 资源预留协议
RSVP（资源预留协议）被主机用来为应用程序向网络请求特定的资源需求，也被路由器用来在数据流传输的网络通路上建立并维持一些资源预留状态从而提供所要求的服务。RSVP是最复杂的QoS技术。在协议栈中，RSVP运行在IP层之上，占据传输层位置。但RSVP本身并不传输任何高层的数据，它只是一个因特网控制协议，类似于ICMP、IGMP或路由协议。RSVP不是一个路由协议，它需要与现有的路由协议一起工作，从本地路由协议那里获得路由，RSVP只和在这些路由上传输的数据流获得的QoS相关。为了有效地适应多种接收者要求，RSVP让接收者负责申请特定的QoS。
RSVP的工作过程如图1所示。发送方发送包括业务类别（Tspec）的PATH信息(放在路由包后)到接收方，每一RSVP路由器存放PATH信息和前一级源地址。接收方发送预留请求(RESV)信息（包含业务类别（Tspec），请求类别（Rspec）和过滤类别（filter spec））。 RSVP路由器按源路由接收RSEV信息，使用录入控制鉴别请求并分配所需的资源，并进行相应的确认，当发送者和接收者结束对话时，将拆除预留。
图 1 RSVP建立预留的过程
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，为了简单起见，设路由器R为发送方。M和Bsa之间已经建立了激活（Active）资源预留。因为M有可能移动到BSa周围任一基站，所以在建立了Bsa和M之间的激活（Active）资源预留后，也要为Bsa和BSb，BSc，BSd等之间建立被动（Passive）资源预留，同时在这些基站预留一个接口，以便M
图3 Mobile RSVP的工作过程
移动到这个基站时能快速获得预留的资源。这些被动（Passive）预留的资源在移动节点M没有用到时，可以被其他的用户使用，避免了资源的浪费。同时一旦移动节点M移动到了这个基站，其他用户必须让出这些资源给移动节点M使用。图3（b）显示了当M移动到BSf时，Bsa和BSf之间的被动（Passive）资源预留被激活，同时M也通过BSf预留的那个接口激活了和BSf之间的链接。利用这种机制可以很好地解决移动节点快速切换链路时在移动节点和基站之间获得QoS保证。
3 移动IP上端到端的QoS
RSVP性能好,但扩展性较差。因为其工作方式是基于每个流的，这就需要保存大量的与分组队列数成正比的状态信息；此外，RSVP的有效实施必须依赖于分组所经过的路径上的每个路由器。在骨干网上，业务流的数目可能会很大，同时它还要求路由器的转发速率很高，这使得RSVP 难于在移动IP上实现端到端的QoS。为了解决这一问题我们先介绍另外一种基本QoS协议――区分服务协议(Diffserv)。
3.1 区分服务协议
Diffserv（区分服务协议）通过汇聚(Aggregate) 和每一跳行为PHB(Per Hop Behavior) 的方式来提供一定程度上的QoS保证。汇聚的含义在于路由器可以把QoS 需求相近的各业务流看成一个大类，以减少调度算法所处理的队列数；PHB的含义在于逐跳的转发方式，每个PHB对应一种转发方式或QoS要求。
Diffserv的协议机制体现在DS字节。Diffserv定义了一个新的IP头格式来进行服务区分，称为DS字段，在IPv4中采用TOS（Type of Service）字段，在IPv6中采用Traffic Class字节来分类，IP头被划分为6bit的区分服务码点(DSCP)和2bit的未用字段。每一个分组将按不同业务的服务质量来给定一转发对待，并定义了一个基本的转发对待(PHB)集。
Diffserv目前主要有两种服务类型，加速转发和确保转发。加速转发（EF）规定最小时延和抖动，提供高水平的汇聚QoS。超过流文件（Traffic Profile）的流被抛弃。确保转发（AF），不符合AF流文件的流将不被转发、缓存或降低服务质量转发。
DiffServ 简化了信令，对业务流的分类颗粒度较粗，在移动环境下对实时业务的支持上还存在着一定的缺陷。但Diffserv扩展性强，可以把Diffserv作为RSVP的一个很好的补充。
图4 RSVP和Diffserv结合实现端到端的QoS
3.2 端到端的QoS保证
RSVP和Diffserv在Mobile IP 上提供QoS时，各有优点和局限。我们可以将RSVP和Diffserv结合起来提供端到端QoS。骨干路由器采用Diffserv，主机可以进行RSVP请求，在骨干接入点的边界路由器把它映射到DS字节，而在骨干网输出点路由器又把它复原为RSVP并送至最终目标，如图4所示。
4 结束语
本文描述了对一些基本QoS协议的改进，介绍了一种在移动 IP上提供端到端的 QoS机制。这些改进方案和端到端QoS体系结构中的一些协议还不是非常完善，而且还要考虑诸如今后对组播支持、网络安全和移动IP中快速切换、平滑切换这样的问题，这些问题还要进一步研究。
参考文献
1 RFC2746.RSVP Operation Over IP Tunnels
2 Indu M,Sivalingam K M.Architecture and experimental results for quality of service in mobile networks using RSVP and CBQ,in ACM/Baltzer Wireless Networks Journal,2000,6(3):221～234
3 Rexhepi V,Karagiannis G,Heijenk G,A framework for QoS & mobility in the Internet next generation.In,Proceedings EUNICE 2000,Sixth EUNICE Open European Summer School,University of Twente,Enschede,the Netherlands,2000,9:13～15
QoS over Mobile IP
Feng Yong Li Fangwei
（Chongqing University of Post & Telecom,Chongqing 400065）
Abstract This paper first analyzes the problem of basic QoS protocols over mobile IP and discuss the solutions for the problem,Last,we introduce a end-to-end QoS architectural framework over mobile IP.
Key words mobile IP，QoS，RSVP
（收稿日期：2001-10-16）
