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

协议──基于TCP/IP的QoS解决方案1引言互联网的惊人发展使人们不得不对它重新布局和规划，其中一个急需解决的问题就是如何使互联网能够提供服务质量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实现最强大的工具。2RSVP协议RSVP协议是一种可以提供音频、视频、数据等混合服务的互联网络综合服务（IIS)[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的主机路由器应用程序RSVP进程策略控制接纳控制包分类器包调度器路由进程RSVP进程策略控制接纳控制包分类器包调度器RSVPDATA图一、主机和路由器中的RSVP通信模型分类。包调度器或其他和链路层相关的机制用来获取所请求的QoS。（图一所示的QoS流量控制机制原型由ISWG[IntegratedServicesWorkingGroup]定义）。在资源申请建立的过程中，RSVP请求被传送到两个本地模块：接纳控制模块和策略控制模块。由接纳控制模块决定该节点是否有足够的资源可以满足该RSVP请求。策略控制机制决定用户是否有权限申请这类服务。如果通过了这两个模块的检测，那么RSVP请求的QoS参数就会输入到包分类器中，再由链路层接口（如包调度器）来获得申请的服务质量。如果任一模块的检测没有通过，那么提出该RSVP请求的应用程序进程将会得到一个错误的返回。由于大的多点组播群体及它所生成的的广播树拓扑结构常常是动态改变的，RSVP假设在RSVP协议流经的路由器和主机也能够动态调节RSVP状态和流量控制的状态。为了实现这个假设，由RSVP在路由器或主机端建立了一种称为“软状态”的状态，它的工作原理是在单位时间内由RSVP驻留进程沿资源申请路径发出刷新消息维持路由器或主机中的资源保留状态，而一定的时间内没有收到刷新消息的路由器就认为原有的资源保留状态“过期”。RSVP协议具有下列特性：1.RSVP可以在点对点传播和多点组播的网络通信应用中进行预留资源的申请，它可以动态调节资源的分配以满足多点组播中组内成员的动态改变，和路由状态改变的特殊需求。2.RSVP比较简单，例如它只为单向的数据流申请资源。3.RSVP是面向接受端的，由数据流的接受端进行资源申请并负责维护该数据流所申请的资源。4.RSVP在路由器和主机端维持“软”状态，解决了组群内成员的动态改变和路由的动态改变所带来的问题。5.RSVP并不是一种路由协议，它依赖于目前或将来出现的路由协议。6.RSVP本身并不处理流量控制和策略控制的参数，而仅把它们送往流量控制和策略控制模块。7.RSVP提供几种资源预留的模式供选择以适应不同的应用需求。8.RSVP对不支持它的路由器提供透明的操作。9.RSVP支持IPv4和IPv6。关于RSVP的其它特性和信息可以从[RSVP93]和[RFC1633]找到。3RSVP协议的数据流RSVP把一次“对话”定义为在特定的目标地址和传送协议上的数据流。RSVP的每次对话都是独立的。一次RSVP对话可以由一个三元组（目的地址，协议号，[协议端口]）来表示。这里的目的地址，也就是IP目的地址，既可以是多点组播地址，也可以是点对点传播地址。协议号就是IP协议号。可选的协议端口就是目的地址的端口号（例如一些协议上所定义的多路复用点），它可以直接利用UDP或TCP的端口，或是其他协议中类似的域、甚至是应用层信息来定义。虽然RSVP是基于可扩展性提出和设计的，但是目前还是只能支持TCP/UDP的协议端口，不过值得注意的是，由于不同的广播地址一般对应不同的对话连接，所以如果是广播地址的话，一般不必包含协议端口。而单一接受端有多个点对点传播对话同时存在，这时必须使用协议端口。图二说明了单个RSVP进程中的数据包流动情况（假定为互联网上的多点组播通讯），箭头表示了数据从发送端S1、S2流向接受端R1、R2、R3。中间的云代表了在分布环境下多点组播路由。分布环境下的多点组播传送将任一发送端Si送出的数据送往每一个接受端Rj，而分布环境下的点对点传播只有一个接受端，每一个发送端是网上唯一标识的主机，而接受端可以通过协议端口的区分功能接受多个发送端的数据。对点对点传播传送来说，一个接受端地址可以被多个发送端所共享，RSVP可以处理这类“多对一”的传送模式。4资源保留模式基本的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端口号。发送端接受端S1R1S2R2R3分布环境下的组播路由图二、分布环境下的组播RSVP对话协议在数据包接受端发起资源申请请求，并上行传送到发送端。注意：在文章中将使用“上行”和“下行”、“上一跳”和“下一跳”、“入接口”和“出接口”来表示数据流的流向。在每一个中间节点，一个资源申请请求将会导致两个操作：1.在连接点上进行资源的保留。RSVP进程将请求传送给接纳控制和策略控制，如果有一个控制进程返回错误，那么请求将被拒绝，错误信息被送到提出该申请的应用中。如果两个控制进程都返回正确消息，就在包分类器中设置参数定义能够使用该服务质量的数据报筛选规格，并由它来和正确的链路层进行通讯获取流规格所定义的服务质量。具体的RSVP请求细节和接口板上所使用的链路层协议有着密切的关系。ISSLL工作组正在制定标准化的规范来把服务质量请求映射到链路层协议中去。对于简单的专用线上的数据传送，服务质量的获取是由链路层的包调度器实现的。如果链路层协议有自己的特定的服务质量的管理机制，那么RSVP进程必须和它进行协商来获取所需的服务质量。注意：虽然服务质量的请求发生在“下行”的接受端处，它的实现却是在进入链路层的界面上，例如“上行