基本介紹
資源預留協定,RSVP設計目標,訊息,路徑訊息,預留訊息,拆除訊息,差錯訊息,證實訊息,RSVP資源預留模式,操作過程,其他特點,
資源預留協定
通常 RSVP 請求將會引起每個節點數據路徑上的資源預留。
RSVP 只在單方向上進行資源請求，因此，儘管相同的應用程式，同時可能既擔當傳送者也擔當接受者，但 RSVP 對傳送者與接受者在邏輯上是有區別的。 RSVP 運行在 IPV4 或 IPV6 上層，占據協定棧中傳輸協定的空間。 RSVP 不傳輸套用數據，但支持網際網路控制協定，如 ICMP、IGMP 或者路由選擇協定。正如路由選擇和管理類協定的實施一樣， RSVP 的運行也是在後台執行，而並非在數據轉發路徑上。
RFC2205對RSVP的特徵做出以下的描述：
（2）單向預留；
（3）接收者發起預留；
（4）維護Internet中的軟狀態。
RSVP設計目標
RSVP 本質上並不屬於路由選擇協定， RSVP 的設計目標是與當前和未來的單播（unicast）和組播（multicast）路由選擇協定同時運行。 RSVP 進程參照本地路由選擇資料庫以獲得傳送路徑。以組播為例，主機傳送 IGMP 信息以加入組播組，然後沿著組播組傳送路徑，傳送 RSVP 信息以預留資源。路由選擇協定決定數據包轉發到哪。 RSVP 只考慮根據路由選擇所轉發的數據包的 QOS 。為了有效適應大型組、動態組成員以及不同機種的接收端需求，通過 RSVP ，接收端可以請求一個特定的 QOS[RSVP93] 。 QOS 請求從接收端主機應用程式被傳送至本地 RSVP 進程，然後 RSVP 協定沿著相反的數據路徑，將此請求傳送到所有節點（路由器和主機），但是只到達接收端數據路徑加入到組播分配樹中時的路由器。所以， RSVP 預留開銷是和接受端的數量成對數關係而非線性關係。
RSVP是由接收者提出資源預留申請的，這種申請是單向的，也就是說為從主機a到主機b的數據流預留的資源，對於從主機b到主機a的數據流是不起作用的。因為在當前的internet中，雙向的路由是不對稱的：從主機a到主機b的路徑並不一定是從主機b到主機a的路徑的反向；另外一個，兩個方向的數據傳輸特徵和對應申請預留的資源也未必相同。
訊息
有以下幾種主要的訊息：
路徑訊息
路徑訊息被沿著數據路徑從傳送方主機傳送，並記錄路徑上每個節點的的路徑狀態。
路徑狀態包括先前節點的IP位址和一些數據對象：
sender template（傳送方模板）是用於描述傳送方數據格式
sender tspec（數據流的話務描述特徵）是用於描述數據流傳輸特徵
adspec攜帶廣告數據
預留訊息
預留訊息(resv)是由接收方沿著反向路徑傳送到傳送方。在每個節點上，預留訊息的IP目的地址將會改成反向路徑上下一節點的地址，同時IP源地址將會改成反向路徑上前一節點的地址。預留訊息包括流量說明(flowspec)數據對象，這個數據對象上用於確定流需要的資源。
拆除訊息
拆除訊息（Teardown）的作用是立刻刪除預留的鏈路或狀態。雖然沒有必要顯式地（Explicitly）刪除一個原有的預留資源，IETF仍然建議所有的終端主機在套用結束時應該立即傳送Teardown訊息進行資源的顯示釋放。
Teardown訊息有兩種類型：路徑拆除（PathTear）訊息和預留請求拆除（ResvTear）訊息。PathTear訊息沿數據流的路由方向傳遞，刪除沿途中的鏈路狀態以及與其相關的所有預留鏈路的狀態。ResvTear訊息沿數據流路由的反方向傳遞，刪除沿途中的資源預留狀態。
差錯訊息
差錯訊息（Errors）訊息有；兩種類型：路徑差錯（PathErr）和預留請求差錯（ResvErr）。
PathErr用來報告在處理Path訊息中產生的錯誤。當網路中的幾點在處理Path訊息中產生的錯誤時，就會產生一個PathErr訊息傳送到傳送方。PathErr訊息在經過的網路結點時不改變包中的任何狀態。
ResvErr訊息用來報告在處理Resv訊息中產生的錯誤。當網路中的結點在處理Resv訊息中產生的錯誤時，就會產生一個ResvErr訊息傳送到接收方。它的轉發依靠預留狀態中保存的下一跳結點的地址。它在每一個結點上進行轉發時，分組的IP目的地址就是下一跳的IP位址。這一點與ResvErr訊息的轉發有所不同。
證實訊息
證實訊息ResvConf是用來確認資源預留請求的。它是一個可選的功能；當Resv訊息中帶有RESV_CONFIRM參數值時才會要求返回確認的訊息。
RSVP資源預留模式
RSVP中的資源預留請求通過流描述符來表示，包括“流規範（Flowspec）”和“過濾器規範（Filter spec）”。其中，Flowspec描述符所希望得到的QoS保證，它用來設定相應網路結點中分組調度部件或者鏈路層機制的參數；而Filter spec 用來設定分組流分類器的參數。Flowerspec一般由服務類型（Service Class）和參數“Rspec”、“Tspec”組成。“Rspec”用來定義所希望的QoS服務，而“Tspec”用來描述數據流。“Rspec”與“Tspec”的格式和內容對RSVP是透明的，它由IntServ的服務類型來描述。
RSVP資源預留訊息由接收方發起並一次向上游傳送，上游在這裡是從接收方到傳送方的方向。在途徑的每一個結點上，資源預留請求會觸發下面的兩個動作：
（1）在鏈路上進行資源預留
每一個結點上的RSVP進程（RSVP Process）都會將 請求資源預留的訊息傳遞給接納控制部件（Admission Control）和策略控制部件（Policy Control）。只要這兩個部件中任何一個在檢測是否可接納時失敗，那么資源資源預留請求就會被拒絕；同時，RSVP進程產生一個錯誤訊息傳送給接收方。如果二者都能成功，結點就會同時對分組流分類器進行相應的設定，從而在實際數據流傳輸時能夠將這個預留的數據分組從進入路由器中的所有分組中挑選出來，進而為它提供QoS保證。
（2）向上游結點轉發資源預留請求
操作過程
一個需要按特定服務質量傳送數據流的RSVP主機將會傳輸一個RSVP路徑訊息，這個路徑訊息將會沿單播或組播路由通過路由協定預先建立的路徑傳輸。如果路徑訊息到達一個不理解RSVP的路由器，將會將這個訊息轉發並不對其內容進行分析而且不會為這個流進行資源預留。
當目的路由器接收到路徑訊息，它將會：
按照請求的參數進行資源預留。對此，許可控制和策略控制處理請求參數並通知分組分類以便正確處理選定的數據分組，或者和上層協商如何進行分組處理。
向上游轉發請求（朝著傳送方方向）。在每個節點上，預留訊息的流量說明（flowspec）可以由前向節點更改。（例如：在多播流資源預留時，預留請求就可以被合併）
路徑上的每個節點都可以接收或者拒絕請求。
其他特點
錯誤報告——當一個節點偵聽到一個錯誤，則會使用錯誤編碼產生一個錯誤訊息，並按相反的路逕往上游傳送直到源節點。
RSVP流信息：兩種診斷信息允許網路管理者通過特定的流對RSVP狀態信息進行請求。
診斷設備：這是規劃的擴展部分，它使用戶能夠收集沿路徑上的RSVP狀態的信息。詳見RFC2745 - RSVP Diagnostic Messages
RSVP是IntServ模型用於資源預留控制的一種協定，它本身並不是一個路由協定，而是Internet控制協定的一種，因此它的運行必須依賴於現有的路由協定提供的路由信息。RSVP工作在UDP和IP協定層之上，既支持IPV4，也支持IPV6，它也可以透明地通過不支持資源預留的路由器，但是只有當預留資源路徑上的所有節點都支持RSVP協定時，才能進行有效的資源預留。
RSVP提供了不同的資源預留類型來適應多種不同的套用，它不僅可以為單播，也可以為組播進行資源預留，在組播套用中，它能根據組播成員與路由器的變化進行動態調整。
RSVP的資源預留是由接收方發起的單項操作，它只保證了從傳送者到接受者的單向資源預留，並不保證從接收者到傳送者的資源，因此RSVP提供的QoS服務只限於從傳送者到接收者的路徑上。
