複製鏈接
請複製以下鏈接發送給好友

資源預留協議

鎖定
資源預留協議(Resource ReSerVation Protocol;RSVP)是一種用於互聯網上質量整合服務的協議。RSVP 允許主機在網絡上請求特殊服務質量用於特殊應用程序數據流的傳輸。路由器也使用 RSVP 發送服務質量(QOS)請求給所有結點(沿着流路徑)並建立和維持這種狀態以提供請求服務。
中文名
資源預留協議
外文名
Resource ReSerVation Protocol;RSVP
性    質
互聯網上質量整合服務的協議
RSVP設計目標
單播組播選擇協議同時運行

資源預留協議資源預留協議

通常 RSVP 請求將會引起每個節點數據路徑上的資源預留。
RSVP 只在單方向上進行資源請求,因此,儘管相同的應用程序,同時可能既擔當發送者也擔當接受者,但 RSVP 對發送者與接受者在邏輯上是有區別的。 RSVP 運行在 IPV4 或 IPV6 上層,佔據協議棧中傳輸協議的空間。 RSVP 不傳輸應用數據,但支持因特網控制協議,如 ICMP、IGMP 或者路由選擇協議。正如路由選擇和管理類協議的實施一樣, RSVP 的運行也是在後台執行,而並非在數據轉發路徑上。 [1] 
RFC2205對RSVP的特徵做出以下的描述:
(1)支持單播組播
(2)單向預留;
(3)接收者發起預留;
(4)維護Internet中的軟狀態。

資源預留協議RSVP設計目標

RSVP 本質上並不屬於路由選擇協議, RSVP 的設計目標是與當前和未來的單播(unicast)和組播(multicast)路由選擇協議同時運行。 RSVP 進程參照本地路由選擇數據庫以獲得傳送路徑。以組播為例,主機發送 IGMP 信息以加入組播組,然後沿着組播組傳送路徑,發送 RSVP 信息以預留資源。路由選擇協議決定數據包轉發到哪。 RSVP 只考慮根據路由選擇所轉發的數據包的 QOS 。為了有效適應大型組、動態組成員以及不同機種的接收端需求,通過 RSVP ,接收端可以請求一個特定的 QOS[RSVP93] 。 QOS 請求從接收端主機應用程序被傳送至本地 RSVP 進程,然後 RSVP 協議沿着相反的數據路徑,將此請求傳送到所有節點(路由器和主機),但是隻到達接收端數據路徑加入到組播分配樹中時的路由器。所以, RSVP 預留開銷是和接受端的數量成對數關係而非線性關係。 [2] 
RSVP是由接收者提出資源預留申請的,這種申請是單向的,也就是説為從主機a到主機b的數據流預留的資源,對於從主機b到主機a的數據流是不起作用的。因為在當前的internet中,雙向的路由是不對稱的:從主機a到主機b的路徑並不一定是從主機b到主機a的路徑的反向;另外一個,兩個方向的數據傳輸特徵和對應申請預留的資源也未必相同。
RSVP標準[RFC 2205]沒有定義網絡向數據流提供預約帶寬的方法,它只是一個允許應用預約必要鏈路帶寬的協議。一旦某預約付諸實施,英特網中的路由器就實際向數據流提供預約的帶寬

資源預留協議消息

有以下幾種主要的消息: [1] 

資源預留協議路徑消息

路徑消息被沿着數據路徑從發送方主機發送,並記錄路徑上每個節點的的路徑狀態。
路徑狀態包括先前節點的IP地址和一些數據對象
sender template(發送方模板)是用於描述發送方數據格式
sender tspec(數據流的話務描述特徵)是用於描述數據流傳輸特徵
adspec攜帶廣告數據

資源預留協議預留消息

預留消息(resv)是由接收方沿着反向路徑發送到發送方。在每個節點上,預留消息的IP目的地址將會改成反向路徑上下一節點的地址,同時IP源地址將會改成反向路徑上前一節點的地址。預留消息包括流量説明(flowspec)數據對象,這個數據對象上用於確定流需要的資源。
RSVP消息的數據對象可以被按任何順序進行傳輸。RSVP消息和其數據對象的所有列表可以在RFC 2205中看到。

資源預留協議拆除消息

拆除消息(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資源預留消息由接收方發起並一次向上遊傳送,上游在這裏是從接收方到發送方的方向。在途徑的每一個結點上,資源預留請求會觸發下面的兩個動作: [2] 
(1)在鏈路上進行資源預留
每一個結點上的RSVP進程(RSVP Process)都會將 請求資源預留的消息傳遞給接納控制部件(Admission Control)和策略控制部件(Policy Control)。只要這兩個部件中任何一個在檢測是否可接納時失敗,那麼資源資源預留請求就會被拒絕;同時,RSVP進程產生一個錯誤消息發送給接收方。如果二者都能成功,結點就會同時對分組流分類器進行相應的設置,從而在實際數據流傳輸時能夠將這個預留的數據分組從進入路由器中的所有分組中挑選出來,進而為它提供QoS保證。
(2)向上遊結點轉發資源預留請求

資源預留協議操作過程

一個需要按特定服務質量發送數據流的RSVP主機將會傳輸一個RSVP路徑消息,這個路徑消息將會沿單播組播路由通過路由協議預先建立的路徑傳輸。如果路徑消息到達一個不理解RSVP的路由器,將會將這個消息轉發並不對其內容進行分析而且不會為這個流進行資源預留。
當目的路由器接收到路徑消息,它將會: [2] 
按照請求的參數進行資源預留。對此,許可控制和策略控制處理請求參數並通知分組分類以便正確處理選定的數據分組,或者和上層協商如何進行分組處理。
向上遊轉發請求(朝着發送方方向)。在每個節點上,預留消息的流量説明(flowspec)可以由前向節點更改。(例如:在多播流資源預留時,預留請求就可以被合併)
路徑上的每個節點都可以接收或者拒絕請求。

資源預留協議其他特點

加密技術——往RSVP消息中添加信息摘要,這是通過一個信息摘要算法(一般是MD5)將消息內容和一個共享密鑰結合。密鑰可以通過2個消息類型被分配和確認:完整的挑戰要求和完整的挑戰響應。
錯誤報告——當一個節點偵聽到一個錯誤,則會使用錯誤編碼產生一個錯誤消息,並按相反的路徑往上游發送直到源節點。
RSVP流信息:兩種診斷信息允許網絡管理者通過特定的流對RSVP狀態信息進行請求。
診斷設備:這是規劃的擴展部分,它使用户能夠收集沿路徑上的RSVP狀態的信息。詳見RFC2745 - RSVP Diagnostic Messages
RSVP是IntServ模型用於資源預留控制的一種協議,它本身並不是一個路由協議,而是Internet控制協議的一種,因此它的運行必須依賴於現有的路由協議提供的路由信息。RSVP工作在UDP和IP協議層之上,既支持IPV4,也支持IPV6,它也可以透明地通過不支持資源預留的路由器,但是隻有當預留資源路徑上的所有節點都支持RSVP協議時,才能進行有效的資源預留。 [1] 
RSVP提供了不同的資源預留類型來適應多種不同的應用,它不僅可以為單播,也可以為組播進行資源預留,在組播應用中,它能根據組播成員與路由器的變化進行動態調整。
RSVP的資源預留是由接收方發起的單項操作,它只保證了從發送者到接受者的單向資源預留,並不保證從接收者到發送者的資源,因此RSVP提供的QoS服務只限於從發送者到接收者的路徑上。
參考資料