RSVP协议基于TCPIP的QoS解决方案

.zRSVP协议──基于TCP/IP的QoS解决方案引言互联网的惊人开展使人们不得不对它重新布局和规划，其中一个急需解决的问题就是如何使互联网能够提供效劳质量QoS〔QualityofService〕，这是由于QoS是网络上新兴应用〔包括IP、视频点播、视频会议等〕赖以存在的根底。离开了QoS的保障，这些应用以及“三网合一〞的设想就根本无法实现。现在，我们通常利用互联网来收发电子、浏览信息、获取共享软件或是和朋友在网上聊天。QoS对于这些应用并不产生很大的影响，这使得我们大都没有意识到它的重要性。但是，我们常常听到的那些对未来的描绘：远程教室、远程医疗、点播电视、互联网、虚拟现实，这些应用离开了QoS的保障是不可想象的，可能打过IP的朋友知道：只有在深夜极少人使用网络的时候才能够保证听到对方流畅的声音。而象点播电视这些需要向用户收费的应用如果没有网络效劳质量的保障，谁敢把可能是断断续续的图象送到用户手中呢.QoS的实现牵涉到了网络体系构造中的多个层面，如应用层：需要有一套标准的调用机制来保障应用获得所需的QoS，以及在没有足够资源的情况下返回相应的信息使应用作出正确的判断〔等待、降低规格或是放弃〕。传送层：QoS资源申请界面，这一层承受应用的申请，并通过点对点的传播或是多点组播的方式来申请网络上的资源。网络及以下各层：指的是路由器或那些拥有网络资源的设备，由他们来允许或否决相应的申请。在本文中，详细介绍了一种基于TCP/IP的效劳质量预留协议RSVP〔ResourceReservationProtocol〕，它是一个传送层协议，由它来申请网络资源。由于它基于互联网标准协议TCP/IP，所以可以很好地同原有的应用和系统兼容，最快最有效地把QoS引入到网络中来。在RSVP出现之前，ATM〔AsynchronousTransferMode〕在网络QoS解决方案中最具有竞争力。在它的QoS效劳体系中定义了各种类别的效劳等级，有CBR〔恒定比特率〕、VBR〔可变比特率〕、ABR〔可用比特率〕、UBR〔不定比特率〕，每一种效劳等级针对特定的应用类别，而在每一类中又可以通过参数的定义来获取不同的效劳质量。从本质上，ATM在QoS上是成熟的，它对QoS概念的推广和初步实现起了推动的作用，但是ATM的缺陷在于它是建立在基于ATM信元的ATM协议上的，而网络现有的应用程序绝大局部是基于TCP/IP的，在原有的应用中实现基于ATM的QoS需要修改大量源码，在这种情况下，ATM并没有获得编程人员的广泛支持。而在本文中提到的RSVP基于TCP/IP，对编程人员来说只要在增加一些根本的函数库的根底上修改原有的函数调用方式就可以获得QoS的效劳，这就保护了原有的软件投资。这就使得RSVP协议成为互联网上QoS实现最强大的工具。RSVP协议RSVP协议是一种可以提供音频、视频、数据等混合效劳的互联网络综合效劳〔IISInternetIntegratedservice)[RSVP97,RFC1633]。通过它，主机端可以向网络申请特定的QoS，为特定的应用程序提供有保障的数据流效劳。同时RSVP在数据流经过的各个路由器节点上对资源进展预留，并维持该状态直到应用程序释放这些资源。RSVP对资源的申请是单向的，所以RSVP在申请资源的过程中发送端和承受端是逻辑上完全不同的两个局部。〔虽然发送端和承受端可以运行在同一个进程下〕。RSVP工作在IPv4或IPv6上，处于

OSI七层协议中的传送层，但是，RSVP并不处理传送层的数据，从本质上看，RSVP更象是网络控制协议，如ICMP〔InternetControlMessageProtocol〕，IGMP〔InternetGroupManagementProtocol〕或是路由协议。和路由协议及管理协议的实现一样，RSVP的实现通常在后台执行，而不是出现在数据传送的路径上〔图一〕。RSVP本身并不是路由协议，RSVP是和现在或是将来出现的点对点传播和多点组播协议一起工作的。RSVP进程通过本地的路由数据库来获取路由信息，如在多点组播过程中，主机端送出IGMP报文来参加一个多点组播的组群，然后送出RSVP报文在组群的传送路径上保存网络资源，路由协议决定报文的走向，而RSVP仅关心这些报文在它将走的路径上能否获得满意的效劳质量。为了适应可能出现的大规模组群、动态组群、异类承受端的可能，RSVP采取由承受端发起效劳质量〔QoS〕申请的策略。QoS请求从承受端的应用程序出发交给本地的RSVP驻留进程，再由该RSVP驻留进程将该请求递交给沿数据传送的反向路径〔承受端至发送端〕上的各个节点〔路由器或是主机〕进展资源的申请。所以，RSVP协议在资源保存上花费一般是呈对数而不是线形幅度增长。QoS是由一组特定的称为流量控制的机制来实现的。这些机制包含了1、包分类器。2、接纳控制。3、包调度器或是其他与链路层相关的机制。其中包分类器决定每个包的QoS的分类。包调度器或其他和链路层相关的机制用来获取所请求的QoS。〔图一所示的QoS流量控制机制原型由ISWG[IntegratedServicesWorkingGroup]定义〕。在资源申请建立的过程中，RSVP请求被传送到两个本地模块：接纳控制模块和策略控制模块。由接纳控制模块决定该节点是否有足够的资源可以满足该RSVP请求。策略控制机制决定用户是否有权限申请这类效劳。如果通过了这两个模块的检测，则RSVP请求的QoS参数就会输入到包分类器中，再由链路层接口〔如包调度器〕来获得申请的效劳质量。如果任一模块的检测没有通过，则提出该RSVP请求的应用程序进程将会得到一个错误的返回。由于大的多点组播群体及它所生成的的播送树拓扑构造常常是动态改变的，RSVP假设在RSVP协议流经的路由器和主机也能够动态调节RSVP状态和流量控制的状态。为了实现这个假设，由RSVP在路由器或主机端建立了一种称为“软状态〞的状态，它的工作原理是在单位时间内由RSVP驻留进程沿资源申请路径发出刷新消息维持路由器或主机中的资源保存状态，而一定的时间内没有收到刷新消息的路由器就认为原有的资源保存状态“过期〞。RSVP协议具有以下特性：RSVP可以在点对点传播和多点组播的网络通信应用中进展预留资源的申请，它可以动态调节资源的分配以满足多点组播中组内成员的动态改变，和路由状态改变的特殊需求。RSVP比拟简单，例如它只为单向的数据流申请资源。RSVP是面向承受端的，由数据流的承受端进展资源申请并负责维护该数据流所申请的资源。RSVP在路由器和主机端维持“软〞状态，解决了组群内成员的动态改变和路由的动态改变所带来的问题。RSVP并不是一种路由协议，它依赖于目前或将来出现的路由协议。RSVP本身并不处理流量控制和策略控制的参数，而仅把它们送往流量控制和策略控制模块。RSVP提供几种资源预留的模式供选择以适应不同的应用需求。RSVP对不支持它的路由器提供透明的操作。RSVP支持IPv4和IPv6。关于RSVP的其它特性和信息可以从[RSVP93]和[RFC1633]找到。RSVP协议的数据流RSVP把一次“对话〞定义为在特定的目标地址和传送协议上的数据流。RSVP的每次对话都是独立的。一次RSVP对话可以由一个三元组〔目的地址，协议号，[协议端口]〕来表示。这里的目的地址，也就是IP目的地址，既可以是多点组播地址，也可以是点对点传播地址。协议号就是IP协议号。可选的协议端口就是目的地址的端口号〔例如一些协议上所定义的多路复用点〕，它可以直接利用UDP或TCP的端口，或是其他协议中类似的域、甚至是应用层信息来定义。虽然RSVP是基于可扩展性提出和设计的，但是目前还是只能支持TCP/UDP的协议端口，不过值得注意的是，由于不同的播送地址一般对应不同的对话连接，所以如果是播送地址的话，一般不必包含协议端口。而单一承受端有多个点对点传播对话同时存在，这时必须使用协议端口。图二说明了单个RSVP进程中的数据包流动情况〔假定为互联网上的多点组播通讯〕，箭头表示了数据从发送端S1、S2流向承受端R1、R2、R3。中间的云代表了在分布环境下多点组播路由。分布环境下的多点组播传送将任一发送端Si送出的数据送往每一个承受端Rj，而分布环境下的点对点传播只有一个承受端，每一个发送端是网上唯一标识的主机，而承受端可以通过协议端口的区分功能承受多个发送端的数据。对点对点传播传送来说，一个承受端地址可以被多个发送端所共享，RSVP可以处理这类“多对一〞的传送模式。资源保存模式根本的RSVP资源保存请求中包含一对域：“流规格域〞和“筛选规格域〞，这一对域也被称为“流描述〞。其中流规格域用来指定资源请求中的效劳质量请求，筛选规格域同对话的规格说明一起定义了数据报是否能够承受流规格指定的效劳质量。流规格用来设定节点中的包调度器或是其他链路层相应机制中的一系列参数。如果一个对话中的数据报不符合筛选规格，则它就不能以效劳质量的模式进展传送，而是由网络以BE〔BestEffort〕模式传送。在资源申请中的流规格说明中通常包含着效劳等级和两个数字化的参量：Tspec和Rspec。Rspec〔R代表保存Reserve〕用来定义需要保存的效劳质量；Tspec〔T代表流量Traffic〕用来描述数据流。Tspec和Rspec参数的具体内容由ISWG〔IntegratedServicesWorkingGroup)进展规格定义[RFC2210]，RSVP对这些内容不做任何处理。筛选规格的具体格式同TCP/IP的版本有关〔Ipv4或Ipv6〕。通常情况下，筛选规格用来选择对话中的数据报的一个子集，选择方式可以是通过发送端的一些特征常量：如发送端IP地址，源端口等，当然原则上可以选择任何协议的任何域来进展筛选。例如，可以用应用层协议中的域来区分不同的视频压缩流的不同压缩层面。不过，处于简单化的目的，目前RSVP中筛选格式的定义仅仅局限于发送端的IP域和可选的UDP/TCP端口号。RSVP协议在数据包承受端发起资源申请请求，并上行传送到发送端。注意：在文章中将使用“上行〞和“下行〞、“上一跳〞和“下一跳〞、“入接口〞和“出接口〞来表示数据流的流向。在每一个中间节点，一个资源申请请求将会导致两个操作：在连接点上进展资源的保存。

RSVP进程将请求传送给接纳控制和策略控制，如果有一个控制进程返回错误，则请求将被拒绝，错误信息被送到提出该申请的应用中。如果两个控制进程都返回正确消息，就在包分类器中设置参数定义能够使用该效劳质量的数据报筛选规格，并由它来和正确的链路层进展通讯获取流规格所定义的效劳质量。具体的RSVP请求细节和接口板上所使用的链路层协议有着密切的关系。ISSLL工作组正在制定标准化的规*来把效劳质量请求映射到链路层协议中去。对于简单的专用线上的数据传送，效劳质量的获取是由链路层的包调度器实现的。如果链路层协议有自己的特定的效劳质量的管理机制，则RSVP进程必须和它进展协商来获取所需的效劳质量。注意：虽然效劳质量的请求发生在“下行〞的承受端处，它的实现却是在进入链路层的界面上，例如“上行〞终点处的逻辑层或物理层。“上行〞传递效劳质量的请求。效劳质量的请求由承受端进展传播送往相应的发送端。从发送端到承受端的整个传播路径称为该效劳质量请求的“*围〞。“上行〞的效劳质量请求和“下行〞的由发送端送往承受端的请求是不完全一样的，有两个原因：1。流量控制机制可能对流规*进展修改。2。更为重要的是，不同“播送树〞中的“下行〞分支节点中的效劳质量保存在“上行“过程中会进展合并。当承受端进展效劳质量请求的同时，它也可以进展请求一个确认信息来了解是否该请求已经在网络上被设定了。一个已设定的请求就是在上行的*节点的所拥有的预留资源容量大于或等于该请求所需的资源容量。在那个节点上，该请求就被合并入该节点中而不必再向前传递，这时，节点就可以发送资源保存确认信息返回承受端。注意：这个收到确实认只是表示很大的可能性，而不是保证。根本的RSVP请求是“单向〞的：承受端发出“上行〞资源预留请求，每个中间节点或是承受该请求或是拒绝，这样的方式使得承受端无法了解最终端到端系统的情况。所以，RSVP提供一种增强的RSVP“单向〞效劳OPWA〔OnePassWithAdvertisements〕。通过OPWA，RSVP控制报文沿着数据路径“下行〞搜集那些端到端相关信息，然后把搜集到的信息〔Advertisments〕交给承受端或是承受端的应用程序。这些信息将被用来构建或动态调整效劳质量请求。保存类型包含一系列保存选项设置的资源保存请求被称为保存类型。资源保存请求选项中定义了如何对待对话中不同发送端的不同的资源保存请求，如为每一个“上行〞的资源保存请求申请特定的唯一的保存资源；或是为不同的发送端申请共享的资源使它们同时使用这段资源。另一个选项定义了选择发送端的方式：可以是分别列出所涉及的发送端，或是利用通配符来选择对话中的所有发送端。在前一种情况下，筛选规格说明必须完全符合其中的每个发送端，而在后一种情况下则不需要考虑规格说明。发送端选择保存方式独占共享分别列出Fi*FilterStyle〔FF类型〕Share-E*plicit〔SE类型〕通配附〔未定义〕WildCard-Filter〔WF类型〕图三、资源保存的属性和类型目前定义了以下几种类型〔见图三〕：WF类型

WF类型具有的特性是：共享式的保存模式和通配符式的发送端选择模式。因此，WF类型的保存模式创立单一的保存资源供所有的“上传〞数据流使用。这个保存资源被认为是一个共享的资源，它的大小是所有承受端申请资源的最大值，而和发送端的数量无关。WF类型的保存将通知所有的发送端，当出现新的发送端时，这个值将自动提供应它。我们把WF类型的资源保存申请记作：WF〔*{Q}〕其中*代表通配附，Q代表流规格。FF类型FF类型具有的特性是：独占的保存模式和分别列出的发送端选择模式。因此，根本的FF类型的为每个发送端创立唯一的保存资源。而不和其他发送端共享。我们把一个根本FF类型的资源保存申请记作：FF〔S{Q}〕其中S代表所选的发送端，Q代表流规格。这两个符号代表了一个流描述。RSVP允许多个FF类型的资源保存同时进展，记为：FF〔S1{Q1}，S2{Q2}，……〕这样一个对话的资源保存的总数量为Q1，Q2，Q3……的总和。SE类型SE类型具有的特性是：共享的保存模式和分别列出的发送端选择模式。因此，SE类型的保存模式创立单一的保存资源供所有的“上传〞数据流使用。但和WF不同的是，它允许以分别列出的方式来选择可以使用该保存资源的的发送端。我们把一个具有Q的流描述和S1，S2，S3，……发送端的SE类型的资源保存记作：SE〔〔S1，S2，S3，……〕{Q}〕共享的保存方式，象WF或SE类型，适合于那些基于播送并且播送的发送端不太可能同时发送数据的应用程序。象分组音频就是一个非常适合这种类型的应用：由于很少有人会在会谈时同时说话，每个承受端可以为发送端申请一个WF或SE类型的双倍带宽保存〔允许*些超载情况〕，另外，为每个发送端创立唯一的保存资源则十分适合于视频信号。RSVP规定，不允许共享保存模式和独占保存模式进展合并，这是因为这两种模式在根本上是不兼容的。同时，发送端的分别列出和通配附这两种模式也是不可以合并的，因为这样的合并会产生一些新的特殊的处理过程。所以，WF、FF、SE这三种模式是互不兼容的。我们可能会发现，似乎可以利用SE保存模式来完成WF保存模式，这只需在应用端发起WF申请时，由RSVP进程列出所有的发送端来创立一个等价的SE保存模式申请。然而，SE模式在每个节点的包分类器中列出了每个发送端，而WF模式仅仅需要指出“这是一个通配附模式〞就可以了。所以在发送端数目巨大的时候，很显然WF模式在效率上大大超过SE模式，因为这个原因，这两个模式在协议中同时存在，而不用SE模式来仿真WF。合并流规格携带着所有经过路径的“最大〞流规格的保存信息继续被发送到上一跳的节点上，我们说这个信息已经是被合并后的信息〔章节5。1中说明了这个过程〕，在这个新的节点上，我们同样要将它和下一跳传来的其它保存信息进展合并，再次得出一个当前节点上合并后的“最大的流规格〞。由于流规格对于RSVP协议而言是“模糊〞的，用来比拟和计算流规格的过程必须定义在RSVP以外，如何定义这些过程在ISWG的文档中有详细说明，而RSVP进程只需调用这些过程来完成合并操作。注意到流规格通常是多维的：它同时包含Tspec和Rspec，而且每个Tspec和Rspec也可能是多维的，所以对它们的比拟是有严格规*的。例如：如果一个请求是高带宽的而另一个希望是低延时的，就不能从这两个申请中挑选出一个大的来作为合并后的结果，而是需要产生一个新的流规格，这个规格必须大于其中任何一个申请，从数学角度上，这就是求一个最低的上边界〔LUBLeastUpperBound〕，在*些情况下可能需要求的是比任何一个流规格小的值，称为最高的下边界〔GLBGreatestLowerBound〕。下面是用来计算接口上有效流规格的几个步骤〔详见RFC2210〕:有效的流规格是在出接口上定义的，考虑到链路层的处理，需要把下几个节点的有效流规格进展合并，也就是计算这些节点有效流规格的LUB。注意对流规格的合并是和链路层介质相关的，而如何进展合并是由效劳模型定义的〔见RFC2210〕。合并的结果是一个数对〔Re,Resv_Te〕，其中Re是有效的Rspec，而Resv_Te是有效的Tspec。使用一个效劳相关的过程对Path_Te进展计算，把从前节点中得到的路径信息中的Tspecs进展总和计算。把〔Re,Resv_Te〕和Path_Te交给流量控制，由它通过一个效劳相关的过程来计算Path_Te和Resv_Te的最小值。“软〞状态RSVP使用一种“软状态〞的方式来管理和维护路由器和主机中的资源保存状态和路径状态，“软状态〞是由保存信息和路径信息定期创立和刷新，如果在去除时间到期前没有适