基于web的集成服务资源预见协议模型

基于web的集成服务资源预见协议模型

0端到端流qosresource目前，关于网络基础设施的改进有两种观点。一个是积极网络，另一个是现有ip技术的附加。前者提出可编程网络的概念,试图实现用户定制网络服务;后者仍然遵循IP网络“简单核心、复杂边缘”的设计原理,增补一些旨在提高网络服务质量(QoS)的协议和算法。它们分别源于两种思路,一是资源预留,二是优先权。前者主要针对单个流的特征类型来描述QoS,后者则通过聚集流的特征类型来描述QoS。由此可以看出,一个是要求端系统和中间结点共同参与的控制,另一个则将改进集中在核心网络。现有的关于提高网络QoS的服务模型及相关协议包括:·基于资源预留的集成服务/资源预留协议模型(IntegratedServices/ResourcereSerVationProtocol,IntServ/RSVP);·基于优先权机制的区分服务模型(DifferentedServices,DiffServ);·从流量工程角度提出的多协议标记交换(MultiProtocolLabelSwitching,MPLS);·在IEEE802网络上提供分类和优先权功能的子网带宽管理(SubnetBandwidthManagement,SBM)。从网络体系结构的观点来看,它们并不是孤立存在的,而是自顶向下结合在一起,作为实现端到端的流QoS管理的一个组成部分。资源预留作为一种根据应用通信量和服务质量请求,在网络上预先保留一定的资源(带宽、缓冲区等),是避免网络由于突发通信量而造成对某些重要应用的传输影响的一种机制。但要充分发挥其效率,必须与相关的路由机制、调度策略相结合。1interv的实现框架以IP技术为特征的Internet,用数据报表达了最小的网络通信服务。对于商业应用来说,网关不能直接了解到整个发送序列的存在,它被迫孤立地处理每一个报文分组。因此,资源管理和记帐必须在每个分组上独立操作。同时由于中继结点中不保存会话的状态信息,给不同类型的通信量保证提供不同QoS带来了困难,因此,需要补充新的协议和控制机制。集成服务作为Internet体系结构的扩充,由集成服务模型和参考实现框架两个基本元素组成。IntServ模型包括两类面向实时通信量的服务:确保服务和可预测服务,它们在受控的共享链路中加以集成。即在原来Internet的尽力服务(Best-EffortService,B-ES)的基础上,增加确保服务(GuaranteedService,GS)和负载受控服务(Controlled-LoadService,C-LS)。假设网络资源是可以显式管理的,那么,资源预留和接入控制就是实现这种服务的关键。服务模型包括一系列服务提交,服务提交由派生的服务实体分类,他们与单个流的QoS或混合流的可利用资源聚集相关。混合流的服务提交要求网络必须在各个流之间合理地分配资源,资源的分配是通过逐个流协商的。对于单个流来说,IntServ模型的核心涉及到分组传输时间,即量化的服务提交被绑定在最大和最小延迟上,可以用优先权机制来进行延迟补偿。但对混合流来说,认为影响质量的主要因素是带宽。因此,如果共享的资源是在单个流上带宽的汇聚,也称为链路共享,就要解决如何在一条链路的各种混合的传输实体中共享总带宽。IntServ的参考实现框架包括分组调度、接入控制、流分类和预留建立协议四部分。在集成服务中,路由器必须根据服务模型为每个流提供相应的QoS,而这种功能称为流量控制(trafficcontrol)。它由接入控制、流分类和分组调度三个组件配合完成。其路由器参考实现模型如图1所示。资源建立协议的作用是为了在端系统和路由器上沿数据流经的路径,生成并保持流规范的状态(包括根据服务提交预留的资源)。RSVP是目前IntServ指定的资源预留协议。2rsvp的总体状态变迁模型RSVP是由接收方起始的预留建立协议,但在RSVP规范中并没有定义发送方和接收方,这就使人们难以弄清究竟谁是发送方?谁是接收方?在面向连接的数据传输里有C/S和Peer-to-Peer两种模式。Web浏览是典型的C/S模式,通常,Server是数据源,Client是数据的访问者,单任务的发起是由Client首先请求的,此时,不能认为Client是发送方;而FTP是典型的Peer-to-Peer模式,对数据传送来说,发送和接收是不确定的。同样,对于计算机会议来说,参加者既可能是发送方,也可能是接收方。于是预留的建立时间和起始过程取决于对发送方和接收方的定义。我们认为要根据应用的模式来确定发送方和接收方,这个工作由驻留在主机的应用程序接口(API)负责。定义1在C/S模式下,数据的提供者(Server)称为发送方,数据的接收者(Client)称为接收方。定义2在计算机会议和其他Peer-to-Peer模式下,连接的发起者(或会议的发起者)称为发送方,被连接对象称为接收方。这意味着在Client/Server模式下,当Client请求与服务器连接时,并不开始预留建立,而是在Server准备发送数据以前,开始预留的会话过程,再由Client提出预留请求。在定义2中,由于数据的发送和接收随时可以变换角色,若是双工通信,一对连接在建立时的预留,应该满足最大的一次通信量;若是单工通信,建立连接后,每个发送方和接收方应该定义各自的预留(两次预留)。定义3沿发送方到接收方的后继结点,称为“下一跳”结点,反方向的后继结点,称为“上一跳”结点。RSVP作为一个资源预留建立协议,整个过程可分以下几个阶段:初始化、预留请求和预留建立。根据每个阶段执行的操作和进入的相应状态,我们构造了RSVP总体状态变迁模型,如图2所示。各种状态和事件的含义如下:(1)“初始”态发送方通过RSVP的应用程序接口,调用一个RSVP会话建立,如果成功,返回一个会话标识,然后定义发送者。发送者的定义包括会话标识、源地址、源端口以及路径消息所需的对象,并引起路径消息的发送(事件1),进入“建链”态。(2)“建链”态路径消息沿某一路由传递,在经过的结点上设置路径软状态和刷新计时器,并将本结点地址填入路径消息上一跳地址字段,同时根据结点和链路的情况更新广播规范(ADSPEC)的相应字段。当路径消息处理或链路出错时,向发送方报告路径错误消息(事件3),回到“初始”态;否则,把更新后的路径消息向下一跳转发(事件2),直到送到接收方,建立了一条路径,进入“准备”态。(3)“准备”态接收方守护进程收到路径消息后(可能来自不同发送方),根据其中ADSPEC对象,了解路径上的QoS特性(如路径上的全部结点是否都支持发送方建议的服务类型,以及带宽和延迟等参数),再比较发送方通信量描述(SENDER_TSPEC)的最大分组长度(m)和ADSPEC的path-mtu。如果m≤path-mtu,并且所有结点都支持某种服务,接收方可以根据自身的情况确定资源预留参数(风格、FLOWSPEC等);否则,全局预留可能失败,可以放弃或尝试预留。如果决定预留,则调用预留定义,按所建路径反向传递预留(resv)消息(事件4),进入“请求”态;否则,调用预留释放,发送预留拆除(ResvTear)消息(事件5),进入“放弃”态。(4)“请求”态在中继结点上对来自各个接收方的预留请求进行合并,建立预留软状态和刷新计时器,并沿路径向上一跳结点转发更新后的预留请求。如果预留请求到达发送方(事件10),进入“成功”态。如果在某个结点预留处理出错或资源不足,向下游发送预留错误(ResvErr)消息,若Resv消息要求回送预留确认(ResvConf)消息,则不论预留状态是否建立,都要回送(ResvConf)消息(事件6),进入“挂起”态。(5)“挂起”态暂停转发失败的预留请求,等待其他连接释放资源或与接收方进行QoS协商,降低预留要求。若接收方同意协商,重新定义预留,更新Resv消息(事件7),再次进入“请求”态;否则,可利用刷新消息(事件8)维持软状态的生命期,等待其他连接释放资源。一旦接收方放弃预留请求,或刷新超时,可向上游发送ResvTear消息(事件9),进入“放弃”态。(6)“放弃”态删除结点上的预留软状态,并发向下游发送路径拆除(PathTear)消息(事件15),进入“拆链”态。(7)“成功”态成功的在源和目的端建立资源预留,可以开始进行数据传送,并周期地发送路径和Resv刷新消息(事件11),进入预留“保持”态。如果刷新超时(事件13),则进入“拆链”态。(8)“保持”态若刷新消息的各个字段与结点中的路径和预留软状态一致,则不修改;否则,更新相应的软状态,并重置软状态刷新计时器。在刷新周期内收到刷新消息(事件12),仍处于“保持”态。当数据传送完毕,由发送方发出PathTear消息(事件14),或刷新超时(事件13),进入“拆链”态。(9)“拆链”态释放预留的资源,删除路径上各结点的路径软状态。3服务参数的提交和映射3.1资源预留retervationv也是一种重要的单次预留在建立状态变迁模型的过程中,我们发现用RSVP来建立资源预留,由于故障可能发生在任何时刻,而不同状态下的故障处理,在很大程度上受应用对QoS控制要求的程度和状态本身所处的地位的影响。因此,路径上物理故障的处理尤为复杂和困难。如果按RSVP规范提出的解决办法,在成功建立预留以前发生链路或结点故障,将通过传递刷新的路径和预留消息来重建,而已建立的部分路径和预留,将因为刷新超时而自然删除;而处于“成功”态和“保持”态的路径故障由IP解决,根据故障持续时间决定是否建立新的预留。这样的结果,使系统开销的差别相当大,因此必须研究在什么情况下有必要重建预留,在什么情况下放弃预留。为了解决上述问题,首先定义用户或应用的QoS请求,通过以下五元组(服务合约)来描述:定义4service_agreement=(flow_spec,service_commit,adaptation,reservation_type,cost)。其中,flow_spec用来说明用户或应用的通信量特性和性能参数;service_commit描述服务类型的约定;adaptation指定在执行服务合约期间,当服务质量可能降低时所采取的动作;reservation_type指明资源预留的类型;cost说明用户对所需服务愿意承受的费用。定义5服务合约五元组中各元素的数据结构:structflow_spec{intflow_id;//流标识intmedia_type;//媒体类型intframe_size;//帧长度(bit)intframe_rate;//帧的平均速率(pbs)intburst;//突发长度(bit)intpeak_rate;//峰值速率(pbs)intdelay;//延迟要求(ms)floatloss;//允许的丢失率intjitter;//延迟变化(ms)}enumservice_class{guaranteed,controlled_load,best_effort}structclass_parameter{service_classclass;//确保服务、负载受控服务和尽量服务之一intslack;//松弛度}structsevice_commit{class_parameterthroughput;class_parameterloss;class_parameterdelay;class_parameterjitter;}enumevent{loss,jitter,throughput,delay,disconnect};enumaction{renegotiate,indication,disconnect_flow,no_action}structadaptation{eventevent_object;//指示QoS在某些性能上的下降actionaction_object;//采取的调整措施flow_spec*new_flow;//形成新的流特性}enumannounce{immediate,negotiated,advanced}structreservation_type{announcereserv;//指出预留是立即预留、协商,还是提前预留timestart;//预留的开始时间timeend;//预留的结束时间}intcost;//用户愿意接受的代价首先通过应用程序接口的API,用定义4给出的服务合约,说明用户或应用对网络服务质量的要求。其中reservation_type和cost可用于有关策略方面的考虑,而flow_spec,service_commit,adaptation则用于QoS路由选择的不同阶段。如service_commit用于决定采用路由计算方式(默认路由、预计算、请求计算);将flow_spec中的速率、延迟、丢失率和抖动参数映射成相应的路由选择尺度和预留值;用adaptation中的参数来进行路由维护。在缺乏各种应用的流模型条件下,可以将静态标准作为flow_spec中的参数,如数字语音要求速率=56kbps,丢失率=1%,延迟=100ms,抖动=10ms;视频会议的速率=360kbps,丢失率=2%,延迟=150ms,抖动=20ms等。对要求较高的网络服务质量,应采用面向连接的服务,这样,在建立连接的过程中完成QoS建立。所以上述服务合约适用于会话层。对于QoS路由而言,层间的QoS变换(或映射)主要是将上层应用对网络传输的要求(如带宽和延迟等),转换成合适的路径或链路的路由计算尺度。这种转换在运输层实现,若上层没有一套会话层服务合约映射机制,则可借助于资源预留协议在QoS协商期间确定流量特性来获得。3.2对网络性能的基本要求链路层的网络大致可以分为三类:(1)NO_QoS:不支持任何QoS控制机制;(2)STD_QoS:支持接纳控制和调度,但不提供通信量整形功能,如支持优先权队列机制;(3)HIGH_QoS:支持接纳控制和通信量整形,ATM是典型的这类接口。ATM定义了六种QoS参数:·可忍受的速率(sustainablerate),即每秒钟最小的信元数;·峰值速率(peakrate),即一个突发所产生的每秒信元数;·最大突发长度(maximumburstlength),即最大突发的持续长度;·信元丢失率(celllossratio),即一个应用所能接受的最大的信元丢失率;·最大端到端延迟(maximumend-to-end-delay),即每个信元受限的等待时间;·最大信元延迟变化,即抖动(maximumcelldelayvariation(jitter)):最大的两个信元端-端延迟之差。相应地,ATM还定义了五种类别(class)的通信量服务:·未规定的比特速率(UnspecifiedBitRate,UBR);·可利用的比特速率(AvailableBitRate,ABR);·非实时变化的比特速率(Nonreal-timeVariableBitRate,Nrt-VBR);·实时可变的比特速率(Real-timeVariableBitRate,Nrt-VBR);·恒定的比特速率(ConstantBitRate,CBR)。它们对网络性能的要求如表1所示。基于IP的集成服务定义的三种服务类型,比较它们各自的服务特性后,给出了表1所列的大致映射关系。至于对第二类STD_QoS的链路层网络,可在实际应用中参考IEEE802.1p给出的优先级,实现对不同服务类型的接纳和调度。3.3《语境下》qos路由请求在RSVP中,由接收方发送的Resv消息给出接收方的预留请求,主要信息由流描述(flowspec)对象承载。提交flowspec对象时,确保服务(GS)只指定了预留的带宽值R和对延迟的松弛值S;而负载受控服务(C-LS),则不对带宽进行定量地预定。尽量服务(B-ES)是无须说明的默认服务。因此,在定义1给出的Client/Server模式下,接收方可在请求数据时提供所需的服务类型。这可以在RSVP应用程序接口中发送一个预请求消息Pre_Resv,告诉发送方自己所需的服务类型。定义6Pre_Resv∷=<Server地址/端口,Client地址/端口,服务类型,[URL],[价格]>与集成服务给定的标识相一致,GS=5,C-LS=2。若不发预请求消息,则认为无须特殊的QoS支持,RSVP守护进程不作任何处理,按传统的尽量服务处理。“URL”用于Client/Server模式下,由接收方指定所要访问的文件路径,为可选项。“价格”即为定义4中出现的用户愿意支付的服务代价,也为可选项,在没有与之对应的计费策略时,暂且不考虑。对于定义2中在计算机会议模式下的QoS路由请求,因为会议是可以预知的,可由会议的发起者提前通知网络,对预知的必须参加会议的各方通过“提前预约”方式的资源预留请求,获得对路由的基本要求,预先计算好一个多点投递(multicast)树,并在会议生命期内保留所需的资源。引入预请求消息,有两个好处:(1)仍然遵循RSVP“接收方启动”预留请求的方案,适应接收能力的异构性,且接收方一般都知道得到的数据的基本情形(正文、图形或声音等),也了解自己网络的基本传输能力,是否想预留,可在请求连接时就确定,不必等路径消息来了再确定;(2)接收方预留要考虑路径消息中TSPEC和ADSPEC对象传递通信量特性和路径状态,这说明路由选择的好坏,直接影响到预留是否成功。如果接收方希望GS,则路由选择程序应该根据TSPEC的通信量特性寻找一条满足要求的路由。如果满足要求的路由存在,至少路径资源等于可能预留的最大值;若无满足要求的路由存在,路径消息实际上已经沿着最接近要求的路径到达接收方,接收方可以按照收到的ADSPEC,决定是否继续进行本次传送或降低预留量。事实上,由于C-LS并没有定量的确定服务质量,预留消息的主要内容就是TSPEC和服务类型说明,完全可从预请求和路径消息得到,无须等到路径消息到达后再决定,因此预留状态可以在传递路径消息时一并完成,省略Resev消息的开销。4-4-so阶段在中继结点对路径消息的处理步骤示于图3。在目前的RSVP实现中,还没有考虑图3中用虚框表示的部分,每刷新一次都将调用路由查询模块,对于支持集成服务的网络,无疑增加了系统的开销。因为既然已经有接纳控制机制保证确保服务(GS)/负载受控服务不受/少受突发流量的影响,且路由表若是采用支持QoS路由分类预计算算法而得,在首次路径消息通过时,找到满足该消息中携带的通信量规范要求的下一跳链路,所以,在路由表目未发生改变的情况下,没有必要重新查找路由。通常,有两种可能重新计算路由:一是预计算路由的周期到,二是有请求计算事件发生(不满足某个确保服务的通信量或某链路发生故障)。为了减少路由更新给RSVP软状态的建立和刷新带来额外的开销,需要对RSVP在以下两方面进行必要的改进:(1)在原来PSB中增加一个状态标志位PSBF_RBAR_NOTIFY,作为unicast路由选择时进行改变的标志。首先,我们给出原来PSB的定义:structsender{structsenderps_next;/*nestPSBforsamesession*/SENDER_TEMPLATE*ps_temp1;/*Sendertemplate*/SENDER_TSPEC*ps_tspec;/*SenderTspec*/RSVP_HOPps_rsvp_phop;/*Previoushop*/ADSPECps_adspec;/*OPWAAdspec*/ADSPECps_newadspec;/*UpdatedAdspec*/u_charps_ip_ttl;/*IPTTLfromPathmsg*/u_charps_unused1;u_charps_originvif;/*OriginvififsenderisAPI*/charps_in_if;/*IncInterfacefromrouting*/bitmapps_outif_list;/*bitmap(outInterface_list*/u_charps_flags;#definePSBF_NonRSVP0×01/*Non-Rsvphopexperienced*/#definePSBF_E-Police0×04/*Entrypolicingforsender*/#definePSBF_LocalOnly0×08/*CanonlymatchlocalResv*/#definePSBF_UDP0×10/*ThissenderneedUDPencaps*/#definePSBF_Prefr_need0×20/*(Path)RefreshNeeded*/#definePSBF_Rrefr_need0×40/*(Resv)RefreshNeeded*/#definePSBF_InScope0×80/*Usedtoformunionofscopes*/u_charps_unused;u_charps_rsrr_flags;/*RSRRflags(由路由查询模块填写)*/#definePSBF_RSRR_NOTIFY0(01/*RSRRNotificationflag(multicast路由改变)*/u_int32_tps_ttd;/*Time-todieforthestate*/Fobject*ps_UnkObjList;/*List:unknownobjectstofwd*/Fobject*ps_Fropolicy;/*POLICY-DATAobjectptr*/structsender*ps_1stphop;/*PtrtofirstsenderforPHOP*/FLOWSPEC*ps_resv_spec;/*LastResvrefreshflowspectothissender/phop*/FLOWSPEC*ps_BSB_Qb;/*Blockadeflowspec*/Intps_BSB_Tb;/*BlockadeTimer=#Rcycles*/}PSB;注意划线部分的变量,在原模块中,当发现multicst路由改变时,将ps_rsrr_flags置位成PSBF_RSRR_NOTIFY。为尽量少改动原有程序,我们新增一个定义:#definePSBF_RBAR_NOTIFY0×02,并启用ps_unused变量,初始化时,置ps_unused=PSBF_RBAR_NOTIFY。这样,只要在调用路由查询模块前判断ps_unused是否等于PSBF_RBAR_NOTIFY,若等于,表示路由已发生变化,需要查找新路由;否则,不用查找,直接使用原来的输出接口ps_outif_