RSVP协议基于TCP IP的QoS解决方案.docVIP

RSVP协议──基于TCP/IP的QoS解决方案 引言 互联网的惊人发展使人们不得不对它重新布局和规划，其中一个急需解决的问题就是如何使互联网能够提供服务质量QoS（Quality of Service），这是由于QoS是网络上新兴应用（包括IP电话、视频点播、视频会议等）赖以存在的基础。离开了QoS的保障，这些应用以及“三网合一”的构想就根本无法实现。 现在，我们通常利用互联网来收发电子邮件、浏览WWW信息、获取共享软件或是和朋友在网上聊天。QoS对于这些应用并不产生很大的影响，这使得我们大都没有意识到它的重要性。但是，我们常常听到的那些对未来的描绘：远程教室、远程医疗、点播电视、互联网电话、虚拟现实，这些应用离开了QoS的保障是不可想象的，可能打过IP电话的朋友知道：只有在深夜极少人使用网络的时候才能够保证听到对方流畅的声音。而象点播电视这些需要向用户收费的应用如果没有网络服务质量的保障，谁敢把可能是断断续续的图象送到用户手中呢？ QoS的实现牵涉到了网络体系结构中的多个层面，如应用层：需要有一套标准的调用机制来保障应用获得所需的QoS，以及在没有足够资源的情况下返回相应的信息使应用作出正确的判断（等待、降低规格或是放弃）。传送层：QoS资源申请界面，这一层接受应用的申请，并通过点对点的传播或是多点组播的方式来申请网络上的资源。网络及以下各层：指的是路由器或那些拥有网络资源的设备，由他们来允许或否决相应的申请。 在本文中，详细介绍了一种基于TCP/IP的服务质量预留协议RSVP（Resource Reservation Protocol），它是一个传送层协议，由它来申请网络资源。由于它基于互联网标准协议TCP/IP，所以可以很好地同原有的应用和系统兼容，最快最有效地把QoS引入到网络中来。 在RSVP出现之前，ATM（Asynchronous Transfer Mode）在网络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协议是一种可以提供音频、视频、数据等混合服务的互联网络综合服务（IIS Internet Integrated service ) [RSVP97,RFC1633]。通过它，主机端可以向网络申请特定的QoS，为特定的应用程序提供有保障的数据流服务。同时RSVP在数据流经过的各个路由器节点上对资源进行预留，并维持该状态直到应用程序释放这些资源。 RSVP对资源的申请是单向的，所以RSVP在申请资源的过程中发送端和接受端是逻辑上完全不同的两个部分。（虽然发送端和接受端可以运行在同一个进程下）。RSVP工作在IPv4或IPv6上，处于?OSI七层协议中的传送层，但是，RSVP并不处理传送层的数据，从本质上看，RSVP更象是网络控制协议，如ICMP（Internet Control Message Protocol），IGMP（Internet Group Management Protocol）或是路由协议。和路由协议及管理协议的实现相同，RSVP的实现通常在后台执行，而不是出现在数据传送的路径上（图一）。 RSVP本身并不是路由协议，RSVP是和现在或是将来出现的点对点传播和多点组播协议一起工作的。RSVP进程通过本地的路由数据库来获取路由信息，如在多点组播过程中，主机端送出IGMP报文来加入一个多点组播的组群，然后送出RSVP报文在组群的传送路径上保留网络资源，路由协议决定报文的走向，而RSVP仅关心这些报文在它将走的路径上能否获得满意的服务质量。 为了适应可能出现的大规模组群、动态组群、异类接受端的可能，RSVP采取由接受端发起服务质量（QoS）申请的策略。QoS请求从接受端的应用程序出发交给本地的RSVP驻留进程，再由该RSVP驻留进程将该请求递交给沿数据传送的反向路径（接受端至发送端）上的各个节点（路由器或是主机）进行资源的申请。所以，RSVP协议在资源保留上花费