資源預留協議
| 資源預留協議 |
|
中文名: 資源預留協議 外文名: Resource ReSerVation Protocol；RSVP 性 質: [[互聯網[[上質量整合服務的協議 RSVP設計目標: 單播和組播選擇協議同時運行 |
資源預留協議（Resource ReSerVation Protocol；RSVP）是一種用於互聯網上質量整合服務的協議。RSVP 允許主機在網絡上請求特殊服務質量用於特殊應用程序數據流的傳輸。路由器也使用 RSVP 發送服務質量（QOS）請求給所有結點（沿着流路徑）並建立和維持這種狀態以提供請求服務。
目錄
資源預留協議,什麼是資源預留協議
資源預留協議(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建立預留。[1]
資源預留協議
通常 RSVP 請求將會引起每個節點數據路徑上的資源預留。
RSVP 只在單方向上進行資源請求，因此，儘管相同的應用程序，同時可能既擔當發送者也擔當接受者，但 RSVP 對發送者與接受者在邏輯上是有區別的。 RSVP 運行在 IPV4 或 IPV6 上層，占據協議棧中傳輸協議的空間。 RSVP 不傳輸應用數據，但支持因特網控制協議，如 ICMP、IGMP 或者路由選擇協議。正如路由選擇和管理類協議的實施一樣， RSVP 的運行也是在後台執行，而並非在數據轉發路徑上。
RFC2205對RSVP的特徵做出以下的描述：
（1）支持單播與組播；
（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的路徑的反向；另外一個，兩個方向的數據傳輸特徵和對應申請預留的資源也未必相同。
RSVP標準[RFC 2205]沒有定義網絡向數據流提供預約帶寬的方法，它只是一個允許應用預約必要鏈路帶寬的協議。一旦某預約付諸實施，英特網中的路由器就實際向數據流提供預約的帶寬。
消息
有以下幾種主要的消息：
路徑消息
路徑消息被沿着數據路徑從發送方主機發送，並記錄路徑上每個節點的的路徑狀態。
路徑狀態包括先前節點的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資源預留消息由接收方發起並一次向上游傳送，上游在這裡是從接收方到發送方的方向。在途徑的每一個結點上，資源預留請求會觸發下面的兩個動作：
（1）在鏈路上進行資源預留
每一個結點上的RSVP進程（RSVP Process）都會將 請求資源預留的消息傳遞給接納控制部件（Admission Control）和策略控制部件（Policy Control）。只要這兩個部件中任何一個在檢測是否可接納時失敗，那麼資源資源預留請求就會被拒絕；同時，RSVP進程產生一個錯誤消息發送給接收方。如果二者都能成功，結點就會同時對分組流分類器進行相應的設置，從而在實際數據流傳輸時能夠將這個預留的數據分組從進入路由器中的所有分組中挑選出來，進而為它提供QoS保證。
（2）向上游結點轉發資源預留請求
操作過程
一個需要按特定服務質量發送數據流的RSVP主機將會傳輸一個RSVP路徑消息，這個路徑消息將會沿單播或組播路由通過路由協議預先建立的路徑傳輸。如果路徑消息到達一個不理解RSVP的路由器，將會將這個消息轉發並不對其內容進行分析而且不會為這個流進行資源預留。
當目的路由器接收到路徑消息，它將會：
按照請求的參數進行資源預留。對此，許可控制和策略控制處理請求參數並通知分組分類以便正確處理選定的數據分組，或者和上層協商如何進行分組處理。
向上游轉發請求（朝着發送方方向）。在每個節點上，預留消息的流量說明（flowspec）可以由前向節點更改。（例如：在多播流資源預留時，預留請求就可以被合併）
路徑上的每個節點都可以接收或者拒絕請求。
其他特點
加密技術——往RSVP消息中添加信息摘要，這是通過一個信息摘要算法（一般是MD5）將消息內容和一個共享密鑰結合。密鑰可以通過2個消息類型被分配和確認：完整的挑戰要求和完整的挑戰響應。
錯誤報告——當一個節點偵聽到一個錯誤，則會使用錯誤編碼產生一個錯誤消息，並按相反的路徑往上游發送直到源節點。
RSVP流信息：兩種診斷信息允許網絡管理者通過特定的流對RSVP狀態信息進行請求。
診斷設備：這是規劃的擴展部分，它使用戶能夠收集沿路徑上的RSVP狀態的信息。詳見RFC2745 - RSVP Diagnostic Messages
RSVP是IntServ模型用於資源預留控制的一種協議，它本身並不是一個路由協議，而是Internet控制協議的一種，因此它的運行必須依賴於現有的路由協議提供的路由信息。RSVP工作在UDP和IP協議層之上，既支持IPV4，也支持IPV6，它也可以透明地通過不支持資源預留的路由器，但是只有當預留資源路徑上的所有節點都支持RSVP協議時，才能進行有效的資源預留。
RSVP提供了不同的資源預留類型來適應多種不同的應用，它不僅可以為單播，也可以為組播進行資源預留，在組播應用中，它能根據組播成員與路由器的變化進行動態調整。
RSVP的資源預留是由接收方發起的單項操作，它只保證了從發送者到接受者的單向資源預留，並不保證從接收者到發送者的資源，因此RSVP提供的QoS服務只限於從發送者到接收者的路徑上。