基于web的集成服務(wù)資源預(yù)見(jiàn)協(xié)議模型

基于web的集成服務(wù)資源預(yù)見(jiàn)協(xié)議模型

0端到端流qosresource目前，關(guān)于網(wǎng)絡(luò)基礎(chǔ)設(shè)施的改進(jìn)有兩種觀點(diǎn)。一個(gè)是積極網(wǎng)絡(luò)，另一個(gè)是現(xiàn)有ip技術(shù)的附加。前者提出可編程網(wǎng)絡(luò)的概念,試圖實(shí)現(xiàn)用戶(hù)定制網(wǎng)絡(luò)服務(wù);后者仍然遵循IP網(wǎng)絡(luò)“簡(jiǎn)單核心、復(fù)雜邊緣”的設(shè)計(jì)原理,增補(bǔ)一些旨在提高網(wǎng)絡(luò)服務(wù)質(zhì)量(QoS)的協(xié)議和算法。它們分別源于兩種思路,一是資源預(yù)留,二是優(yōu)先權(quán)。前者主要針對(duì)單個(gè)流的特征類(lèi)型來(lái)描述QoS,后者則通過(guò)聚集流的特征類(lèi)型來(lái)描述QoS。由此可以看出,一個(gè)是要求端系統(tǒng)和中間結(jié)點(diǎn)共同參與的控制,另一個(gè)則將改進(jìn)集中在核心網(wǎng)絡(luò)?，F(xiàn)有的關(guān)于提高網(wǎng)絡(luò)QoS的服務(wù)模型及相關(guān)協(xié)議包括:·基于資源預(yù)留的集成服務(wù)/資源預(yù)留協(xié)議模型(IntegratedServices/ResourcereSerVationProtocol,IntServ/RSVP);·基于優(yōu)先權(quán)機(jī)制的區(qū)分服務(wù)模型(DifferentedServices,DiffServ);·從流量工程角度提出的多協(xié)議標(biāo)記交換(MultiProtocolLabelSwitching,MPLS);·在IEEE802網(wǎng)絡(luò)上提供分類(lèi)和優(yōu)先權(quán)功能的子網(wǎng)帶寬管理(SubnetBandwidthManagement,SBM)。從網(wǎng)絡(luò)體系結(jié)構(gòu)的觀點(diǎn)來(lái)看,它們并不是孤立存在的,而是自頂向下結(jié)合在一起,作為實(shí)現(xiàn)端到端的流QoS管理的一個(gè)組成部分。資源預(yù)留作為一種根據(jù)應(yīng)用通信量和服務(wù)質(zhì)量請(qǐng)求,在網(wǎng)絡(luò)上預(yù)先保留一定的資源(帶寬、緩沖區(qū)等),是避免網(wǎng)絡(luò)由于突發(fā)通信量而造成對(duì)某些重要應(yīng)用的傳輸影響的一種機(jī)制。但要充分發(fā)揮其效率,必須與相關(guān)的路由機(jī)制、調(diào)度策略相結(jié)合。1interv的實(shí)現(xiàn)框架以IP技術(shù)為特征的Internet,用數(shù)據(jù)報(bào)表達(dá)了最小的網(wǎng)絡(luò)通信服務(wù)。對(duì)于商業(yè)應(yīng)用來(lái)說(shuō),網(wǎng)關(guān)不能直接了解到整個(gè)發(fā)送序列的存在,它被迫孤立地處理每一個(gè)報(bào)文分組。因此,資源管理和記帳必須在每個(gè)分組上獨(dú)立操作。同時(shí)由于中繼結(jié)點(diǎn)中不保存會(huì)話的狀態(tài)信息,給不同類(lèi)型的通信量保證提供不同QoS帶來(lái)了困難,因此,需要補(bǔ)充新的協(xié)議和控制機(jī)制。集成服務(wù)作為Internet體系結(jié)構(gòu)的擴(kuò)充,由集成服務(wù)模型和參考實(shí)現(xiàn)框架兩個(gè)基本元素組成。IntServ模型包括兩類(lèi)面向?qū)崟r(shí)通信量的服務(wù):確保服務(wù)和可預(yù)測(cè)服務(wù),它們?cè)谑芸氐墓蚕礞溌分屑右约伞＜丛谠瓉?lái)Internet的盡力服務(wù)(Best-EffortService,B-ES)的基礎(chǔ)上,增加確保服務(wù)(GuaranteedService,GS)和負(fù)載受控服務(wù)(Controlled-LoadService,C-LS)。假設(shè)網(wǎng)絡(luò)資源是可以顯式管理的,那么,資源預(yù)留和接入控制就是實(shí)現(xiàn)這種服務(wù)的關(guān)鍵。服務(wù)模型包括一系列服務(wù)提交,服務(wù)提交由派生的服務(wù)實(shí)體分類(lèi),他們與單個(gè)流的QoS或混合流的可利用資源聚集相關(guān)?；旌狭鞯姆?wù)提交要求網(wǎng)絡(luò)必須在各個(gè)流之間合理地分配資源,資源的分配是通過(guò)逐個(gè)流協(xié)商的。對(duì)于單個(gè)流來(lái)說(shuō),IntServ模型的核心涉及到分組傳輸時(shí)間,即量化的服務(wù)提交被綁定在最大和最小延遲上,可以用優(yōu)先權(quán)機(jī)制來(lái)進(jìn)行延遲補(bǔ)償。但對(duì)混合流來(lái)說(shuō),認(rèn)為影響質(zhì)量的主要因素是帶寬。因此,如果共享的資源是在單個(gè)流上帶寬的匯聚,也稱(chēng)為鏈路共享,就要解決如何在一條鏈路的各種混合的傳輸實(shí)體中共享總帶寬。IntServ的參考實(shí)現(xiàn)框架包括分組調(diào)度、接入控制、流分類(lèi)和預(yù)留建立協(xié)議四部分。在集成服務(wù)中,路由器必須根據(jù)服務(wù)模型為每個(gè)流提供相應(yīng)的QoS,而這種功能稱(chēng)為流量控制(trafficcontrol)。它由接入控制、流分類(lèi)和分組調(diào)度三個(gè)組件配合完成。其路由器參考實(shí)現(xiàn)模型如圖1所示。資源建立協(xié)議的作用是為了在端系統(tǒng)和路由器上沿?cái)?shù)據(jù)流經(jīng)的路徑,生成并保持流規(guī)范的狀態(tài)(包括根據(jù)服務(wù)提交預(yù)留的資源)。RSVP是目前IntServ指定的資源預(yù)留協(xié)議。2rsvp的總體狀態(tài)變遷模型RSVP是由接收方起始的預(yù)留建立協(xié)議,但在RSVP規(guī)范中并沒(méi)有定義發(fā)送方和接收方,這就使人們難以弄清究竟誰(shuí)是發(fā)送方?誰(shuí)是接收方?在面向連接的數(shù)據(jù)傳輸里有C/S和Peer-to-Peer兩種模式。Web瀏覽是典型的C/S模式,通常,Server是數(shù)據(jù)源,Client是數(shù)據(jù)的訪問(wèn)者,單任務(wù)的發(fā)起是由Client首先請(qǐng)求的,此時(shí),不能認(rèn)為Client是發(fā)送方;而FTP是典型的Peer-to-Peer模式,對(duì)數(shù)據(jù)傳送來(lái)說(shuō),發(fā)送和接收是不確定的。同樣,對(duì)于計(jì)算機(jī)會(huì)議來(lái)說(shuō),參加者既可能是發(fā)送方,也可能是接收方。于是預(yù)留的建立時(shí)間和起始過(guò)程取決于對(duì)發(fā)送方和接收方的定義。我們認(rèn)為要根據(jù)應(yīng)用的模式來(lái)確定發(fā)送方和接收方,這個(gè)工作由駐留在主機(jī)的應(yīng)用程序接口(API)負(fù)責(zé)。定義1在C/S模式下,數(shù)據(jù)的提供者(Server)稱(chēng)為發(fā)送方,數(shù)據(jù)的接收者(Client)稱(chēng)為接收方。定義2在計(jì)算機(jī)會(huì)議和其他Peer-to-Peer模式下,連接的發(fā)起者(或會(huì)議的發(fā)起者)稱(chēng)為發(fā)送方,被連接對(duì)象稱(chēng)為接收方。這意味著在Client/Server模式下,當(dāng)Client請(qǐng)求與服務(wù)器連接時(shí),并不開(kāi)始預(yù)留建立,而是在Server準(zhǔn)備發(fā)送數(shù)據(jù)以前,開(kāi)始預(yù)留的會(huì)話過(guò)程,再由Client提出預(yù)留請(qǐng)求。在定義2中,由于數(shù)據(jù)的發(fā)送和接收隨時(shí)可以變換角色,若是雙工通信,一對(duì)連接在建立時(shí)的預(yù)留,應(yīng)該滿(mǎn)足最大的一次通信量;若是單工通信,建立連接后,每個(gè)發(fā)送方和接收方應(yīng)該定義各自的預(yù)留(兩次預(yù)留)。定義3沿發(fā)送方到接收方的后繼結(jié)點(diǎn),稱(chēng)為“下一跳”結(jié)點(diǎn),反方向的后繼結(jié)點(diǎn),稱(chēng)為“上一跳”結(jié)點(diǎn)。RSVP作為一個(gè)資源預(yù)留建立協(xié)議,整個(gè)過(guò)程可分以下幾個(gè)階段:初始化、預(yù)留請(qǐng)求和預(yù)留建立。根據(jù)每個(gè)階段執(zhí)行的操作和進(jìn)入的相應(yīng)狀態(tài),我們構(gòu)造了RSVP總體狀態(tài)變遷模型,如圖2所示。各種狀態(tài)和事件的含義如下:(1)“初始”態(tài)發(fā)送方通過(guò)RSVP的應(yīng)用程序接口,調(diào)用一個(gè)RSVP會(huì)話建立,如果成功,返回一個(gè)會(huì)話標(biāo)識(shí),然后定義發(fā)送者。發(fā)送者的定義包括會(huì)話標(biāo)識(shí)、源地址、源端口以及路徑消息所需的對(duì)象,并引起路徑消息的發(fā)送(事件1),進(jìn)入“建鏈”態(tài)。(2)“建鏈”態(tài)路徑消息沿某一路由傳遞,在經(jīng)過(guò)的結(jié)點(diǎn)上設(shè)置路徑軟狀態(tài)和刷新計(jì)時(shí)器,并將本結(jié)點(diǎn)地址填入路徑消息上一跳地址字段,同時(shí)根據(jù)結(jié)點(diǎn)和鏈路的情況更新廣播規(guī)范(ADSPEC)的相應(yīng)字段。當(dāng)路徑消息處理或鏈路出錯(cuò)時(shí),向發(fā)送方報(bào)告路徑錯(cuò)誤消息(事件3),回到“初始”態(tài);否則,把更新后的路徑消息向下一跳轉(zhuǎn)發(fā)(事件2),直到送到接收方,建立了一條路徑,進(jìn)入“準(zhǔn)備”態(tài)。(3)“準(zhǔn)備”態(tài)接收方守護(hù)進(jìn)程收到路徑消息后(可能來(lái)自不同發(fā)送方),根據(jù)其中ADSPEC對(duì)象,了解路徑上的QoS特性(如路徑上的全部結(jié)點(diǎn)是否都支持發(fā)送方建議的服務(wù)類(lèi)型,以及帶寬和延遲等參數(shù)),再比較發(fā)送方通信量描述(SENDER_TSPEC)的最大分組長(zhǎng)度(m)和ADSPEC的path-mtu。如果m≤path-mtu,并且所有結(jié)點(diǎn)都支持某種服務(wù),接收方可以根據(jù)自身的情況確定資源預(yù)留參數(shù)(風(fēng)格、FLOWSPEC等);否則,全局預(yù)留可能失敗,可以放棄或嘗試預(yù)留。如果決定預(yù)留,則調(diào)用預(yù)留定義,按所建路徑反向傳遞預(yù)留(resv)消息(事件4),進(jìn)入“請(qǐng)求”態(tài);否則,調(diào)用預(yù)留釋放,發(fā)送預(yù)留拆除(ResvTear)消息(事件5),進(jìn)入“放棄”態(tài)。(4)“請(qǐng)求”態(tài)在中繼結(jié)點(diǎn)上對(duì)來(lái)自各個(gè)接收方的預(yù)留請(qǐng)求進(jìn)行合并,建立預(yù)留軟狀態(tài)和刷新計(jì)時(shí)器,并沿路徑向上一跳結(jié)點(diǎn)轉(zhuǎn)發(fā)更新后的預(yù)留請(qǐng)求。如果預(yù)留請(qǐng)求到達(dá)發(fā)送方(事件10),進(jìn)入“成功”態(tài)。如果在某個(gè)結(jié)點(diǎn)預(yù)留處理出錯(cuò)或資源不足,向下游發(fā)送預(yù)留錯(cuò)誤(ResvErr)消息,若Resv消息要求回送預(yù)留確認(rèn)(ResvConf)消息,則不論預(yù)留狀態(tài)是否建立,都要回送(ResvConf)消息(事件6),進(jìn)入“掛起”態(tài)。(5)“掛起”態(tài)暫停轉(zhuǎn)發(fā)失敗的預(yù)留請(qǐng)求,等待其他連接釋放資源或與接收方進(jìn)行QoS協(xié)商,降低預(yù)留要求。若接收方同意協(xié)商,重新定義預(yù)留,更新Resv消息(事件7),再次進(jìn)入“請(qǐng)求”態(tài);否則,可利用刷新消息(事件8)維持軟狀態(tài)的生命期,等待其他連接釋放資源。一旦接收方放棄預(yù)留請(qǐng)求,或刷新超時(shí),可向上游發(fā)送ResvTear消息(事件9),進(jìn)入“放棄”態(tài)。(6)“放棄”態(tài)刪除結(jié)點(diǎn)上的預(yù)留軟狀態(tài),并發(fā)向下游發(fā)送路徑拆除(PathTear)消息(事件15),進(jìn)入“拆鏈”態(tài)。(7)“成功”態(tài)成功的在源和目的端建立資源預(yù)留,可以開(kāi)始進(jìn)行數(shù)據(jù)傳送,并周期地發(fā)送路徑和Resv刷新消息(事件11),進(jìn)入預(yù)留“保持”態(tài)。如果刷新超時(shí)(事件13),則進(jìn)入“拆鏈”態(tài)。(8)“保持”態(tài)若刷新消息的各個(gè)字段與結(jié)點(diǎn)中的路徑和預(yù)留軟狀態(tài)一致,則不修改;否則,更新相應(yīng)的軟狀態(tài),并重置軟狀態(tài)刷新計(jì)時(shí)器。在刷新周期內(nèi)收到刷新消息(事件12),仍處于“保持”態(tài)。當(dāng)數(shù)據(jù)傳送完畢,由發(fā)送方發(fā)出PathTear消息(事件14),或刷新超時(shí)(事件13),進(jìn)入“拆鏈”態(tài)。(9)“拆鏈”態(tài)釋放預(yù)留的資源,刪除路徑上各結(jié)點(diǎn)的路徑軟狀態(tài)。3服務(wù)參數(shù)的提交和映射3.1資源預(yù)留retervationv也是一種重要的單次預(yù)留在建立狀態(tài)變遷模型的過(guò)程中,我們發(fā)現(xiàn)用RSVP來(lái)建立資源預(yù)留,由于故障可能發(fā)生在任何時(shí)刻,而不同狀態(tài)下的故障處理,在很大程度上受應(yīng)用對(duì)QoS控制要求的程度和狀態(tài)本身所處的地位的影響。因此,路徑上物理故障的處理尤為復(fù)雜和困難。如果按RSVP規(guī)范提出的解決辦法,在成功建立預(yù)留以前發(fā)生鏈路或結(jié)點(diǎn)故障,將通過(guò)傳遞刷新的路徑和預(yù)留消息來(lái)重建,而已建立的部分路徑和預(yù)留,將因?yàn)樗⑿鲁瑫r(shí)而自然刪除;而處于“成功”態(tài)和“保持”態(tài)的路徑故障由IP解決,根據(jù)故障持續(xù)時(shí)間決定是否建立新的預(yù)留。這樣的結(jié)果,使系統(tǒng)開(kāi)銷(xiāo)的差別相當(dāng)大,因此必須研究在什么情況下有必要重建預(yù)留,在什么情況下放棄預(yù)留。為了解決上述問(wèn)題,首先定義用戶(hù)或應(yīng)用的QoS請(qǐng)求,通過(guò)以下五元組(服務(wù)合約)來(lái)描述:定義4service_agreement=(flow_spec,service_commit,adaptation,reservation_type,cost)。其中,flow_spec用來(lái)說(shuō)明用戶(hù)或應(yīng)用的通信量特性和性能參數(shù);service_commit描述服務(wù)類(lèi)型的約定;adaptation指定在執(zhí)行服務(wù)合約期間,當(dāng)服務(wù)質(zhì)量可能降低時(shí)所采取的動(dòng)作;reservation_type指明資源預(yù)留的類(lèi)型;cost說(shuō)明用戶(hù)對(duì)所需服務(wù)愿意承受的費(fèi)用。定義5服務(wù)合約五元組中各元素的數(shù)據(jù)結(jié)構(gòu):structflow_spec{intflow_id;//流標(biāo)識(shí)intmedia_type;//媒體類(lèi)型intframe_size;//幀長(zhǎng)度(bit)intframe_rate;//幀的平均速率(pbs)intburst;//突發(fā)長(zhǎng)度(bit)intpeak_rate;//峰值速率(pbs)intdelay;//延遲要求(ms)floatloss;//允許的丟失率intjitter;//延遲變化(ms)}enumservice_class{guaranteed,controlled_load,best_effort}structclass_parameter{service_classclass;//確保服務(wù)、負(fù)載受控服務(wù)和盡量服務(wù)之一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;//采取的調(diào)整措施flow_spec*new_flow;//形成新的流特性}enumannounce{immediate,negotiated,advanced}structreservation_type{announcereserv;//指出預(yù)留是立即預(yù)留、協(xié)商,還是提前預(yù)留timestart;//預(yù)留的開(kāi)始時(shí)間timeend;//預(yù)留的結(jié)束時(shí)間}intcost;//用戶(hù)愿意接受的代價(jià)首先通過(guò)應(yīng)用程序接口的API,用定義4給出的服務(wù)合約,說(shuō)明用戶(hù)或應(yīng)用對(duì)網(wǎng)絡(luò)服務(wù)質(zhì)量的要求。其中reservation_type和cost可用于有關(guān)策略方面的考慮,而flow_spec,service_commit,adaptation則用于QoS路由選擇的不同階段。如service_commit用于決定采用路由計(jì)算方式(默認(rèn)路由、預(yù)計(jì)算、請(qǐng)求計(jì)算);將flow_spec中的速率、延遲、丟失率和抖動(dòng)參數(shù)映射成相應(yīng)的路由選擇尺度和預(yù)留值;用adaptation中的參數(shù)來(lái)進(jìn)行路由維護(hù)。在缺乏各種應(yīng)用的流模型條件下,可以將靜態(tài)標(biāo)準(zhǔn)作為flow_spec中的參數(shù),如數(shù)字語(yǔ)音要求速率=56kbps,丟失率=1%,延遲=100ms,抖動(dòng)=10ms;視頻會(huì)議的速率=360kbps,丟失率=2%,延遲=150ms,抖動(dòng)=20ms等。對(duì)要求較高的網(wǎng)絡(luò)服務(wù)質(zhì)量,應(yīng)采用面向連接的服務(wù),這樣,在建立連接的過(guò)程中完成QoS建立。所以上述服務(wù)合約適用于會(huì)話層。對(duì)于QoS路由而言,層間的QoS變換(或映射)主要是將上層應(yīng)用對(duì)網(wǎng)絡(luò)傳輸?shù)囊?如帶寬和延遲等),轉(zhuǎn)換成合適的路徑或鏈路的路由計(jì)算尺度。這種轉(zhuǎn)換在運(yùn)輸層實(shí)現(xiàn),若上層沒(méi)有一套會(huì)話層服務(wù)合約映射機(jī)制,則可借助于資源預(yù)留協(xié)議在QoS協(xié)商期間確定流量特性來(lái)獲得。3.2對(duì)網(wǎng)絡(luò)性能的基本要求鏈路層的網(wǎng)絡(luò)大致可以分為三類(lèi):(1)NO_QoS:不支持任何QoS控制機(jī)制;(2)STD_QoS:支持接納控制和調(diào)度,但不提供通信量整形功能,如支持優(yōu)先權(quán)隊(duì)列機(jī)制;(3)HIGH_QoS:支持接納控制和通信量整形,ATM是典型的這類(lèi)接口。ATM定義了六種QoS參數(shù):·可忍受的速率(sustainablerate),即每秒鐘最小的信元數(shù);·峰值速率(peakrate),即一個(gè)突發(fā)所產(chǎn)生的每秒信元數(shù);·最大突發(fā)長(zhǎng)度(maximumburstlength),即最大突發(fā)的持續(xù)長(zhǎng)度;·信元丟失率(celllossratio),即一個(gè)應(yīng)用所能接受的最大的信元丟失率;·最大端到端延遲(maximumend-to-end-delay),即每個(gè)信元受限的等待時(shí)間;·最大信元延遲變化,即抖動(dòng)(maximumcelldelayvariation(jitter)):最大的兩個(gè)信元端-端延遲之差。相應(yīng)地,ATM還定義了五種類(lèi)別(class)的通信量服務(wù):·未規(guī)定的比特速率(UnspecifiedBitRate,UBR);·可利用的比特速率(AvailableBitRate,ABR);·非實(shí)時(shí)變化的比特速率(Nonreal-timeVariableBitRate,Nrt-VBR);·實(shí)時(shí)可變的比特速率(Real-timeVariableBitRate,Nrt-VBR);·恒定的比特速率(ConstantBitRate,CBR)。它們對(duì)網(wǎng)絡(luò)性能的要求如表1所示?；贗P的集成服務(wù)定義的三種服務(wù)類(lèi)型,比較它們各自的服務(wù)特性后,給出了表1所列的大致映射關(guān)系。至于對(duì)第二類(lèi)STD_QoS的鏈路層網(wǎng)絡(luò),可在實(shí)際應(yīng)用中參考IEEE802.1p給出的優(yōu)先級(jí),實(shí)現(xiàn)對(duì)不同服務(wù)類(lèi)型的接納和調(diào)度。3.3《語(yǔ)境下》qos路由請(qǐng)求在RSVP中,由接收方發(fā)送的Resv消息給出接收方的預(yù)留請(qǐng)求,主要信息由流描述(flowspec)對(duì)象承載。提交flowspec對(duì)象時(shí),確保服務(wù)(GS)只指定了預(yù)留的帶寬值R和對(duì)延遲的松弛值S;而負(fù)載受控服務(wù)(C-LS),則不對(duì)帶寬進(jìn)行定量地預(yù)定。盡量服務(wù)(B-ES)是無(wú)須說(shuō)明的默認(rèn)服務(wù)。因此,在定義1給出的Client/Server模式下,接收方可在請(qǐng)求數(shù)據(jù)時(shí)提供所需的服務(wù)類(lèi)型。這可以在RSVP應(yīng)用程序接口中發(fā)送一個(gè)預(yù)請(qǐng)求消息Pre_Resv,告訴發(fā)送方自己所需的服務(wù)類(lèi)型。定義6Pre_Resv∷=<Server地址/端口,Client地址/端口,服務(wù)類(lèi)型,[URL],[價(jià)格]>與集成服務(wù)給定的標(biāo)識(shí)相一致,GS=5,C-LS=2。若不發(fā)預(yù)請(qǐng)求消息,則認(rèn)為無(wú)須特殊的QoS支持,RSVP守護(hù)進(jìn)程不作任何處理,按傳統(tǒng)的盡量服務(wù)處理?！癠RL”用于Client/Server模式下,由接收方指定所要訪問(wèn)的文件路徑,為可選項(xiàng)?！皟r(jià)格”即為定義4中出現(xiàn)的用戶(hù)愿意支付的服務(wù)代價(jià),也為可選項(xiàng),在沒(méi)有與之對(duì)應(yīng)的計(jì)費(fèi)策略時(shí),暫且不考慮。對(duì)于定義2中在計(jì)算機(jī)會(huì)議模式下的QoS路由請(qǐng)求,因?yàn)闀?huì)議是可以預(yù)知的,可由會(huì)議的發(fā)起者提前通知網(wǎng)絡(luò),對(duì)預(yù)知的必須參加會(huì)議的各方通過(guò)“提前預(yù)約”方式的資源預(yù)留請(qǐng)求,獲得對(duì)路由的基本要求,預(yù)先計(jì)算好一個(gè)多點(diǎn)投遞(multicast)樹(shù),并在會(huì)議生命期內(nèi)保留所需的資源。引入預(yù)請(qǐng)求消息,有兩個(gè)好處:(1)仍然遵循RSVP“接收方啟動(dòng)”預(yù)留請(qǐng)求的方案,適應(yīng)接收能力的異構(gòu)性,且接收方一般都知道得到的數(shù)據(jù)的基本情形(正文、圖形或聲音等),也了解自己網(wǎng)絡(luò)的基本傳輸能力,是否想預(yù)留,可在請(qǐng)求連接時(shí)就確定,不必等路徑消息來(lái)了再確定;(2)接收方預(yù)留要考慮路徑消息中TSPEC和ADSPEC對(duì)象傳遞通信量特性和路徑狀態(tài),這說(shuō)明路由選擇的好壞,直接影響到預(yù)留是否成功。如果接收方希望GS,則路由選擇程序應(yīng)該根據(jù)TSPEC的通信量特性尋找一條滿(mǎn)足要求的路由。如果滿(mǎn)足要求的路由存在,至少路徑資源等于可能預(yù)留的最大值;若無(wú)滿(mǎn)足要求的路由存在,路徑消息實(shí)際上已經(jīng)沿著最接近要求的路徑到達(dá)接收方,接收方可以按照收到的ADSPEC,決定是否繼續(xù)進(jìn)行本次傳送或降低預(yù)留量。事實(shí)上,由于C-LS并沒(méi)有定量的確定服務(wù)質(zhì)量,預(yù)留消息的主要內(nèi)容就是TSPEC和服務(wù)類(lèi)型說(shuō)明,完全可從預(yù)請(qǐng)求和路徑消息得到,無(wú)須等到路徑消息到達(dá)后再?zèng)Q定,因此預(yù)留狀態(tài)可以在傳遞路徑消息時(shí)一并完成,省略Resev消息的開(kāi)銷(xiāo)。4-4-so階段在中繼結(jié)點(diǎn)對(duì)路徑消息的處理步驟示于圖3。在目前的RSVP實(shí)現(xiàn)中,還沒(méi)有考慮圖3中用虛框表示的部分,每刷新一次都將調(diào)用路由查詢(xún)模塊,對(duì)于支持集成服務(wù)的網(wǎng)絡(luò),無(wú)疑增加了系統(tǒng)的開(kāi)銷(xiāo)。因?yàn)榧热灰呀?jīng)有接納控制機(jī)制保證確保服務(wù)(GS)/負(fù)載受控服務(wù)不受/少受突發(fā)流量的影響,且路由表若是采用支持QoS路由分類(lèi)預(yù)計(jì)算算法而得,在首次路徑消息通過(guò)時(shí),找到滿(mǎn)足該消息中攜帶的通信量規(guī)范要求的下一跳鏈路,所以,在路由表目未發(fā)生改變的情況下,沒(méi)有必要重新查找路由。通常,有兩種可能重新計(jì)算路由:一是預(yù)計(jì)算路由的周期到,二是有請(qǐng)求計(jì)算事件發(fā)生(不滿(mǎn)足某個(gè)確保服務(wù)的通信量或某鏈路發(fā)生故障)。為了減少路由更新給RSVP軟狀態(tài)的建立和刷新帶來(lái)額外的開(kāi)銷(xiāo),需要對(duì)RSVP在以下兩方面進(jìn)行必要的改進(jìn):(1)在原來(lái)PSB中增加一個(gè)狀態(tài)標(biāo)志位PSBF_RBAR_NOTIFY,作為unicast路由選擇時(shí)進(jìn)行改變的標(biāo)志。首先,我們給出原來(lái)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(由路由查詢(xún)模塊填寫(xiě))*/#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;注意劃線部分的變量,在原模塊中,當(dāng)發(fā)現(xiàn)multicst路由改變時(shí),將ps_rsrr_flags置位成PSBF_RSRR_NOTIFY。為盡量少改動(dòng)原有程序,我們新增一個(gè)定義:#definePSBF_RBAR_NOTIFY0×02,并啟用ps_unused變量,初始化時(shí),置ps_unused=PSBF_RBAR_NOTIFY。這樣,只要在調(diào)用路由查詢(xún)模塊前判斷ps_unused是否等于PSBF_RBAR_NOTIFY,若等于,表示路由已發(fā)生變化,需要查找新路由;否則,不用查找,直接使用原來(lái)的輸出接口ps_outif_