清华大学：《数据通信原理》课程教学资源（学习讲义）移动 IP上的QoS 保证.doc_大学文库

移动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 请求，在