移动IP上的QoS保证 作者:丰勇李方伟发布日期:200201 (重庆邮电学院重庆40065) 摘要本文首先分析了基本QS协议在移动P上存在的问题并讨论其解决办法,在此基础 上介绍了一种在移动IP上提供端到端的QoS机制 关键词移动IP服务质量资源预留协议 引言 随着移动通信技术和因特网技术的迅猛发展以及因特网信息资源的日益丰富,人们不再 满足在固定地点从 Internet检索、传输信息,希望在任何时候、任何地点都能方便地访问 nternet o因特网工程任务组正TF( Internet Engineering Task Force)为了迎合这种需求,制定 了移动IP( Mobile ip)协议,它是传统 Internet的有效延伸和扩展。 Mobile ip是一种在全球 Internet上提供移动功能的方案,使节点在切换链路时仍可保持正在进行的通信。它提供了 种P路由机制,使移动节点以一个永久的IP地址连接到任何链路上。 Mobile ip的可扩展性 使其可以在整个 Internet上应用。 传统的IP网络只有一种服务类型,即尽力而为的( Best effort)服务模型。当新的 Internet 应用,如多媒体数据传输之类的实时应用出现时,“尽力而为服务就不能很好地适应,传输 延迟、抖动和包丢失极大地影响了实时应用的效果。这就要求网络提供一定的服务质量 (QoS),使得某些应用获得非缺省的服务,这就是QoS协议要做的事情。在移动环境下,由 于无线网络拓扑和资源是动态变化和不可预测地,并且其资源有限,有效带宽不可预测,差 错率高,从而在移动P上提供QoS将是一个非常棘手的问题 2在移动IP上应用RsⅤP 日前在IP网络上实现QoS有很多种技术,资源预留协议(RSVP就是其中主要的一种 RSVP可以提供最高等级的QoS,但RSVP是为传统IP网络设计的,在移动IP上应用还存 在着一些问题 2.1资源预留协议 RSVP(资源预留协议)被主机用来为应用程序向网络请求特定的资源需求,也被路由器 用来在数据流传输的网络通路上建立并维持一些资源预留状态从而提供所要求的服务。 RSVP是最复杂的QoS技术。在协议栈中,RSVP运行在P层之上,占据传输层位置。但 RSVP本身并不传输任何高层的数据,它只是一个因特网控制协议,类似于ICMP、IGMP或 路由协议。RSVP不是一个路由协议,它需要与现有的路由协议一起工作,从本地路由协议 那里获得路由,RSVP只和在这些路由上传输的数据流获得的QoS相关。为了有效地适应多 种接收者要求,RSVP让接收者负责申请特定的QoS。 RSVP的工作过程如图1所示。发送方发送包括业务类别( Tspec)的PATH信息(放在路 由包后)到接收方,每一RSVP路由器存放PATH信息和前一级源地址。接收方发送预留请求 RESV)信息(包含业务类别( Tspec),请求类别( Rspec)和过滤类别( filter spec)。RSⅤP 路由器按源路由接收RSEV信息,使用录入控制鉴别请求并分配所需的资源,并进行相应的 确认,当发送者和接收者结束对话时,将拆除预留。 图1RSVP建立预留的过程
移动 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 建立预留的过程
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，为了简单起见，设路
由器R为发送方。M和B之间已经建立了激活( 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性能好,但扩展性较差。因为其工作方式是基于每个流的,这就需要保存大量的 与分组队列数成正比的状态信息:此外,RVP的有效实施必须依赖于分组所经过的路径上 的每个路由器。在骨干网上,业务流的数目可能会很大,同时它还要求路由器的转发速率很 高,这使得RSVP难于在移动IP上实现端到端的QoS。为了解决这一问题我们先介绍另外 种基本QoS协议一一区分服务协议 Diffserv)a 3.1区分服务协议 Diffserv(区分服务协议)通过汇聚( Aggregate)和每一跳行为 PHB(Per Hop Behavior)的 方式来提供一定程度上的QoS保证。汇聚的含义在于路由器可以把QS需求相近的各业务 流看成一个大类,以减少调度算法所处理的队列数;PHB的含义在于逐跳的转发方式,每个 PHB对应一种转发方式或QoS要求。 Diffserv的协议机制体现在DS字节。 Diffserv定义了一个新的P头格式来进行服务区分, 称为DS字段,在IP4中采用TOS( Type of Service)字段,在IP6中采用Tca字 节来分类,IP头被划分为6bt的区分服务码点(DSCP和2bt的未用字段。每一个分组将按不 同业务的服务质量来给定一转发对待,并定义了一个基本的转发对待(PHB集。 Diffserv目前主要有两种服务类型,加速转发和确保转发。加速转发(EF)规定最小时延和 抖动,提供高水平的汇聚QoS。超过流文件( Traffic Profile)的流被抛弃。确保转发(AF) 不符合AF流文件的流将不被转发、缓存或降低服务质量转发 Diffserv简化了信令,对业务流的分类颗粒度较粗,在移动环境下对实时业务的支持上还存 在着一定的缺陷。但 Diffserv扩展性强,可以把 Diffserv作为RSVP的一个很好的补充 图4RSVP和 Diffserv结合实现端到端的QoS 32端到端的QoS保证 RSVP和 Diffserv在 Mobile ip上提供QoS时,各有优点和局限。我们可以将RSVP和 Diffserv结合起来提供端到端QoS。骨干路由器采用 Diffserv,主机可以进行RSVP请求,在
由器 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协议的改进,介绍了一种在移动P上提供端到端的QoS机 制。这些改进方案和端到端QoS体系结构中的一些协议还不是非常完善,而且还要考虑诸如 今后对组播支持、网络安全和移动IP中快速切换、平滑切换这样的问题,这些问题还要进 步研究。 参考文献 I 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): 221234 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 Fangw 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 Key words mobile IP, QoS, RSVP (收稿日期:2001-10-16)
骨干接入点的边界路由器把它映射到 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）