資源預留協議,什么是資源預留協議

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

?Version ― 協議版本號，當前為1。

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

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

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

?Send TTL ― 信息發送時的 IP TTL 值。

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

RSVP基本特點

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

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

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

RSVP協議機制

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

RSVP的流描述由流規范"Flowspec" 和過濾規范 "Filterspec"組成。流規范說明流所需的QoS，設置在結點分組調度或其它鏈路層機制的參數，包括服務類別和兩個參數集。一個是"Rspec"，定義流所需的QoS對網絡資源的預留；另一個是"Tspec" ，定義相關的數據流特性。這些參數定義不是RSVP本身的工作，由IEFT其它研究組負責。

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

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

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

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

RSVP功能規范

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

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

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

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

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

設RS表示預留過濾說明，Flitestyle表示過濾風格，預留說明定義為：

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

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

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

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

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

RSVP消息

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

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

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

RSVP接口

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

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

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