資源預(yù)留協(xié)議,什么是資源預(yù)留協(xié)議

資源預(yù)留協(xié)議,什么是資源預(yù)留協(xié)議

資源預(yù)留協(xié)議（RSVP）是一種用于互聯(lián)網(wǎng)上質(zhì)量整合服務(wù)的協(xié)議。 RSVP 允許主機在網(wǎng)絡(luò)上請求特殊服務(wù)質(zhì)量用于特殊應(yīng)用程序數(shù)據(jù)流的傳輸。路由器也使用 RSVP 發(fā)送服務(wù)質(zhì)量（QOS）請求給所有結(jié)點（沿著流路徑）并建立和維持這種狀態(tài)以提供請求服務(wù)。通常 RSVP 請求將會引起每個節(jié)點數(shù)據(jù)路徑上的資源預(yù)留?！　?RSVP 只在單方向上進行資源請求，因此，盡管相同的應(yīng)用程序，同時可能既擔(dān)當(dāng)發(fā)送者也擔(dān)當(dāng)接受者，但 RSVP 對發(fā)送者與接受者在邏輯上是有區(qū)別的。RSVP 運行在 IPV4 或 IPV6 上層，占據(jù)協(xié)議棧中傳輸協(xié)議的空間。RSVP 不傳輸應(yīng)用數(shù)據(jù)，但支持因特網(wǎng)控制協(xié)議，如 ICMP、IGMP 或者路由選擇協(xié)議。正如路由選擇和管理類協(xié)議的實施一樣，RSVP 的運行也是在后臺執(zhí)行，而并非在數(shù)據(jù)轉(zhuǎn)發(fā)路徑上。 　　 RSVP 本質(zhì)上并不屬于路由選擇協(xié)議， RSVP 的設(shè)計目標是與當(dāng)前和未來的單播（unicast）和組播（multicast）路由選擇協(xié)議同時運行。 RSVP 進程參照本地路由選擇數(shù)據(jù)庫以獲得傳送路徑。以組播為例，主機發(fā)送 IGMP 信息以加入組播組，然后沿著組播組傳送路徑，發(fā)送 RSVP 信息以預(yù)留資源。路由選擇協(xié)議決定數(shù)據(jù)包轉(zhuǎn)發(fā)到哪。 RSVP 只考慮根據(jù)路由選擇所轉(zhuǎn)發(fā)的數(shù)據(jù)包的 QOS 。為了有效適應(yīng)大型組、動態(tài)組成員以及不同機種的接收端需求，通過 RSVP ，接收端可以請求一個特定的 QOS[RSVP93] 。 QOS 請求從接收端主機應(yīng)用程序被傳送至本地 RSVP 進程，然后 RSVP 協(xié)議沿著相反的數(shù)據(jù)路徑，將此請求傳送到所有節(jié)點（路由器和主機），但是只到達接收端數(shù)據(jù)路徑加入到組播分配樹中時的路由器。所以， RSVP 預(yù)留開銷是和接受端的數(shù)量成對數(shù)關(guān)系而非線性關(guān)系。 協(xié)議結(jié)構(gòu)

?Version ― 協(xié)議版本號，當(dāng)前為1。

?Flags ― 還沒有定義標志位。

?Message Type ― 可能值有：1 Path，2 Resv，3 PathErr，4 ResvErr，5 PathTear，6 ResvTear，7 ResvConf。

?RSVP Checksum ― 用于信息差錯的校驗和。

?Send TTL ― 信息發(fā)送時的 IP TTL 值。

?RSVP Length ― RSVP 信息二進制形式下的總長，包括通用頭和可變長對象。

RSVP基本特點

RSVP是Resource ReSerVation Protocol的縮寫，原來的研究背景是會議應(yīng)用，現(xiàn)被IETF集成服務(wù)工作組認為是集成服務(wù) 中通用的資源預(yù)留解決方案。RSVP本身不是一個路由選擇協(xié)議，它僅僅被用來沿著所選定 的路由預(yù)留資源。其預(yù)留建立在流的基礎(chǔ)上，流由IPv4的地址字段或IPv6的流標識來指定 ，路由器根據(jù)為該流建立的預(yù)留來調(diào)度分組的轉(zhuǎn)發(fā)。

作為一個新的信令協(xié)議，RSVP有以下基本特點：

預(yù)留請求由是接收方發(fā)起，由接收方根據(jù)自身系統(tǒng)的特定環(huán)境和接收愿望指定不同的資源 預(yù)留。這種接收方起動的模式原則上允許系統(tǒng)的異構(gòu)性。既支持單點投遞的資源預(yù)留，也支持多點間的群組通信資源預(yù)留，并且它的過濾機制允許預(yù)留的資源可以被多個發(fā)送者共享或?qū)ν粋€發(fā)送者的預(yù)留進行合并。它既可以用于主機，也可以用于路由器。資源預(yù)留的建立在轉(zhuǎn)發(fā)數(shù)據(jù)之前完成，其資源預(yù)留是單向的。 用軟狀態(tài)指示預(yù)留的存在狀態(tài)，周期性地被刷新，從而支持動態(tài)的成員和路由變化。 RSVP在端系統(tǒng)和路由器上的開銷通常與接收方數(shù)目的對數(shù)成正比。RSVP傳輸維護通信量控制以及策略控制的參數(shù)對RSVP來說是不透明的。RSVP支持幾種預(yù)留模式（或風(fēng)格），以適應(yīng)各種應(yīng)用，同時對不支持RSVP的路由器提供旁路作用。

RSVP協(xié)議機制

一個RSVP會話被定義成三元組：(DestAddress, ProtocolId [, DstPort])。 其中 DestAddress表示所傳送數(shù)據(jù)分組的目的IP 地址； ProtocolId 表示 IP 協(xié)議標識；DstPort是一個選項，表示通用目的端口，如被 UDP/TCP 目的端口域定義。

RSVP的流描述由流規(guī)范"Flowspec" 和過濾規(guī)范 "Filterspec"組成。流規(guī)范說明流所需的QoS，設(shè)置在結(jié)點分組調(diào)度或其它鏈路層機制的參數(shù)，包括服務(wù)類別和兩個參數(shù)集。一個是"Rspec"，定義流所需的QoS對網(wǎng)絡(luò)資源的預(yù)留；另一個是"Tspec" ，定義相關(guān)的數(shù)據(jù)流特性。這些參數(shù)定義不是RSVP本身的工作，由IEFT其它研究組負責(zé)。

過濾規(guī)范定義特定的流，它們是一些數(shù)據(jù)分組集合，接收在同一個流規(guī)范里定義的QoS。通常，過濾規(guī)范與發(fā)送方地址相關(guān)，有嚴格的格式，如：發(fā)送方IP地址和可選的UDP/TCP 端口號。流規(guī)范和過濾規(guī)范通過相應(yīng)的RSVP消息傳遞。

為了在結(jié)點上建立合適的預(yù)留，必須根據(jù)一定的接入策略和目前網(wǎng)絡(luò)的接入能力來決定是否接收該預(yù)留請求。策略控制是回答這個用戶是否允許使用該資源，而接入控制是回答是否有足夠的可利用資源滿足該請求。通常，RSVP要求在網(wǎng)絡(luò)的邊緣、來自多個發(fā)送方的數(shù)據(jù)匯聚點和上游的通信量可能大于下游預(yù)留量的分支點進行策略控制。由于Internet上不同的管理域可能有不同的預(yù)留策略，RSVP可以在相應(yīng)的消息中傳遞策略數(shù)據(jù)，而對數(shù)據(jù)的處理不屬于RSVP本身的功能。

RSVP靠兩個時間參數(shù)來維護軟狀態(tài)（路徑狀態(tài)和預(yù)留狀態(tài)），一是刷新周期R，另一個是本地狀態(tài)的生命期L。每隔R時間間隔，發(fā)送方和接收方要發(fā)送相應(yīng)的刷新消息，且R也決定了L的大小。

在每個中間結(jié)點，一個預(yù)留請求將觸發(fā)兩個動作：對鏈路產(chǎn)生一個預(yù)留和向上游轉(zhuǎn)發(fā)請求。在路徑上的結(jié)點可能支持RSVP或某種服務(wù)類別，也可能不支持，它們通過標志位標明，這被稱為帶廣告的一次通過"One Pass With Advertising" (OPWA)。這個機制可以被接收方用來構(gòu)造、調(diào)整一個合適的預(yù)留請求。

RSVP功能規(guī)范

RSVP通過結(jié)合目的地址、運輸層協(xié)議類型和目的端口號標識一個通信會話，每個RSVP操作僅僅申請一個特殊的會話分組，每個RSVP消息必須包括它所申請的會話細節(jié)。在路由器和主機上要分類出屬于同一個流的數(shù)據(jù)分組，并根據(jù)為該流制定的預(yù)留來處理。RSVP僅僅幫助路由器和主機建立軟狀態(tài)，而資源和通信量管理則在很大程度上取決于系統(tǒng)所支持的服務(wù)類別。

目前RSVP支持IETF的兩類服務(wù)：確保服務(wù)GS（Guaranteed Service）和負載控制服務(wù)CS（Controlled-load Service）。GS確保數(shù)據(jù)報在確定的時間內(nèi)到達接收端，并且當(dāng)網(wǎng)絡(luò)負載過重時，不被從隊列中溢出。它要求應(yīng)用指定通信量參數(shù)（如帶寬、端端延遲等），常用于需要嚴格保證無丟失、準確達到的實時傳輸應(yīng)用上。CS很象輕度載荷下的Internet盡力而為BE（Best Effort）服務(wù)。它與BE的主要區(qū)別在于當(dāng)網(wǎng)絡(luò)負載加重時，CS流不會明顯的惡化，相反，BE流會有很大的延遲或丟失的可能。

RSVP會話通過Tspec說明流的通信量。Tspec包括：平均速率，峰值速率，最大突發(fā)尺寸。 對于GS來說，通信量應(yīng)該被整形，以符合Tspec；而對于CS來說，在源端不強制整形，違規(guī)的分組允許通過一致性檢查點。目前RSVP不建議在一個群組通信中各接收方使用異種服務(wù)，但參數(shù)可以不同。

RSVP把沿發(fā)送方到接收方傳遞路徑上的結(jié)點稱為“下一跳”，反方向的結(jié)點稱為“上一跳”，它們是相對于一次連接而定義的。

RSVP有三種預(yù)留過濾風(fēng)格：固定過濾FF（Fixed Filter），通配過濾WF（Wildcard Filter），共享過濾SE（Shared Explicit）。這三種風(fēng)格定義了不同的過濾合并機制，即要將每個路由器接口上收到的預(yù)留量按某種規(guī)則選取最大的，然后再向發(fā)送方向的上一跳路由器轉(zhuǎn)發(fā)。

設(shè)RS表示預(yù)留過濾說明，F(xiàn)litestyle表示過濾風(fēng)格，預(yù)留說明定義為：

RS::=Flitestyle（Fliterspec{Flowspec}）；Flitestyle::=FF|WF|SE

FF風(fēng)格明確選擇了發(fā)送方，即Fliterspec指示唯一的發(fā)送方標識。每個路由器的輸入接口，根據(jù)在其上收到的所有FF風(fēng)格的Fliterspec，把對同一Fliterspec預(yù)留的Flowspec最大值定為該接口收到的有效預(yù)留量。在輸出端口上向上一跳轉(zhuǎn)發(fā)的有效預(yù)留量是路由器上包含該發(fā)送方的最大FF預(yù)留量。

WF風(fēng)格不指定發(fā)送方，即Fliterspec是一個通配符*。每個路由器的輸入接口，將該接口上收到的所有WF風(fēng)格的最大預(yù)留量定為該接口收到的有效預(yù)留量。向每個上一跳轉(zhuǎn)發(fā)的有效預(yù)留量是路由器上所有輸入接口的最大WF預(yù)留量。

SE風(fēng)格指定一組發(fā)送方，即Fliterspec是一個發(fā)送方標識集合。每個路由器的輸入接口，根據(jù)該接口上收到的所有SE風(fēng)格的Fliterspec，取在Fliterspec并集上的最大預(yù)留量為該接口收到的有效預(yù)留量。向上一跳轉(zhuǎn)發(fā)的有效預(yù)留量是路由器上包含該發(fā)送方的最大SE預(yù)留量。過濾合并只能在同樣的預(yù)留風(fēng)格中進行，其中SE和WF可用于群組通信的預(yù)留。

在請求預(yù)留時，一旦發(fā)生下面兩種“預(yù)留殺手問題”之一，要盡量滿足可能的預(yù)留。一種是如果已存在一個預(yù)留Q0，當(dāng)一個新的預(yù)留Q1可能在與Q0合并后，不能通過上游某個結(jié)點的接入控制，那么，應(yīng)當(dāng)保留對Q0的預(yù)留，將Q1請求掛起。另一種是一個較大的請求Q1， 盡管在某些結(jié)點上未能通過接入控制，但還是堅持要預(yù)留，此時如果有一個較小的預(yù)留請求Q0發(fā)生了，且通過了路徑上所有結(jié)點的接入控制，系統(tǒng)應(yīng)當(dāng)為Q0建立預(yù)留。

RSVP消息

RSVP有兩類消息：PATH和RESV。PATH類從源到目的，RESV類從目的到源，它們與一個特殊的數(shù)據(jù)流相關(guān)聯(lián)，并被封裝在IP或UDP數(shù)據(jù)報中。PATH類消息包含：Path, PathTear, ResvErr, ResvConf4種消息，RESV消息包含 Resv, ResvTear, PathErr3種消息。其中 Path和 Resv是主要的消息。

Path消息包含上一跳地址（為回送Resv消息而設(shè)）；發(fā)送方模板（由發(fā)送方IP地址和發(fā)送端口組成）；發(fā)送方通信量說明（即Tspec）；與QoS類別相關(guān)的廣播選項。在傳輸途中，被RSVP使能的路由器截獲后，該路由器上為這個RSVP流建立路徑軟狀態(tài)（包含上一跳和下一跳的地址和通信量特征），并修改Path消息的有關(guān)參數(shù)，再向下一跳轉(zhuǎn)發(fā)。到達接收方后，若接收方想為其產(chǎn)生一個資源預(yù)留，則回答一個Resv消息。

Resv消息用三種預(yù)留風(fēng)格之一指示預(yù)留請求，還包含下一跳地址（為返回確認或失敗消息而設(shè)）。當(dāng)被途中RSVP使能的路由器截獲時，如有可利用的資源，就在路由器上建立一個預(yù)留軟狀態(tài)，經(jīng)過過濾合并后，繼續(xù)向上游轉(zhuǎn)發(fā)。否則，產(chǎn)生一個ResvError消息，表示預(yù)留失敗，送給接收方，導(dǎo)致下游各路由器刪除已建立的預(yù)留軟狀態(tài)，同時終止轉(zhuǎn)發(fā)Resv消息。一旦Resv消息到達發(fā)送方，意味著一個端到端的資源預(yù)留被成功建立。

RSVP接口

RSVP在網(wǎng)絡(luò)和端系統(tǒng)上都要相應(yīng)的接口來支持不同控制和處理功能，同時必須考慮到網(wǎng)絡(luò)的各組成元素，其資源的能力是多樣化的－從高速網(wǎng)絡(luò)鏈路和快速工作站到經(jīng)由窄帶鏈路連接的低端個人計算機，要通過適當(dāng)?shù)臄?shù)據(jù)流過濾支持異構(gòu)系統(tǒng)的集成服務(wù)。在中繼系統(tǒng)上要在UDP或IP包頭中指示RSVP協(xié)議類型，然后安裝一系列處理RSVP消息的程序，支持軟狀態(tài)的建立，并根據(jù)預(yù)留和數(shù)據(jù)之間的聯(lián)系，在數(shù)據(jù)傳輸時執(zhí)行預(yù)留。在端系統(tǒng)的主機上，要建立一個RSVP應(yīng)用程序接口（RAPI）庫，一個用戶級的RSVP守護進程，和位于內(nèi)核的QoS管理器。需要預(yù)留資源的應(yīng)用通過RAPI與RSVP守護進程交互，RSVP守護進程負責(zé)將RAPI調(diào)用轉(zhuǎn)換成RSVP信令消息和本地資源管理功能調(diào)用，本地資源管理通過QoS管理器完成。QoS管理器負責(zé)建立、改變、刪除預(yù)留的控制信息。

RSVP 在路由器上的接口要為傳遞RSVP消息選擇路由、建立狀態(tài)并與相應(yīng)的通信量控制（流分類、接入控制和分組調(diào)度）交互信息。RSVP和通信量控制的接口分與IP層、網(wǎng)絡(luò)層和鏈路層驅(qū)動器的接口。對于有效的QoS鏈路層，如ATM，路由器負責(zé)與鏈路層協(xié)商，以保證鏈路層安裝合適的QoS。這種向鏈路層映射QoS是與媒體相關(guān)的，近來，IETF的專門工作組正在定義映射的機制；對于無效的QoS鏈路層，如租用線路，映射到鏈路層的QoS不是十分重要，因為傳輸能力完全由路由器的分組調(diào)度所操縱。

在主機端的接口，負責(zé)與應(yīng)用連接和進行相應(yīng)的通信量控制。 應(yīng)用和RSVP的接口要完成會話注冊、定義發(fā)送者、預(yù)留請求和預(yù)留釋放操作。