思科CCIE網絡工程師技術解析RSVP資源預留協議-ielab，Internet網中存在着大量的中間節點。如果用戶使用無連接協議來傳輸數據流，則該數據流的各個數據報在通過中間節點轉發時可能會產生兩個問題，一是各個數據報的轉發路徑不同，並非順序到達目的端，有些數據報可能會延遲到達；二是數據報在中間節點排隊等待轉發時，其排隊時間是不確定的，並且中間節點因資源缺乏而發生擁塞時，將會採取丟包策略來疏導交通，這對於端到端通信來說將意味着傳輸延遲和延遲抖動。這些對多媒體通信來說都是不利的，嚴重影響端到端多媒體通信的服務質量。解決這個問題的基本方法是端點和中間節點要密切合作，基於無連接協議，爲特定的數據流建立固定的傳輸路徑，併爲其保留系統資源，將傳輸延遲限制在指定的範圍內，從而保證了端到端多媒體通信的服務質量。IETF提出的RSVP(Resource Reservation Protocol)則是基於上述方法。
通常RSVP請求將會引起每個節點數據路徑上的資源預留。
RSVP只在單方向上進行資源請求，因此，儘管相同的應用程序，同時可能既擔當發送者也擔當接受者，但 RSVP 對發送者與接受者在邏輯上是有區別的。 RSVP 運行在 IPV4 或 IPV6 上層，佔據協議棧中傳輸協議的空間。RSVP不傳輸應用數據，但支持因特網控制協議，如 ICMP、IGMP 或者路由選擇協議。正如路由選擇和管理類協議的實施一樣，RSVP的運行也是在後臺執行，而並非在數據轉發路徑上。
RSVP本質上並不屬於路由選擇協議，RSVP協議的設計目標是與當前和未來的單播（unicast）和組播（multicast）路由選擇協議同時運行。RSVP進程參照本地路由選擇數據庫以獲得傳送路徑。以組播爲例，主機發送 IGMP 信息以加入組播組，然後沿着組播組傳送路徑，發送RSVP信息以預留資源。路由選擇協議決定數據包轉發到哪。RSVP只考慮根據路由選擇所轉發的數據包的QOS。爲了有效適應大型組、動態組成員以及不同機種的接收端需求，通過RSVP，接收端可以請求一個特定的QOS。
QOS請求從接收端主機應用程序被傳送至本地RSVP進程，然後RSVP協議沿着相反的數據路徑，將此請求傳送到所有節點（路由器和主機），但是隻到達接收端數據路徑加入到組播分配樹中時的路由器。所以，RSVP預留開銷是和接受端的數量成對數關係而非線性關係。
由於RSVP報文必須向上遊傳播，經過所有中間路由器，最終到達所有的發送主機。然而路由選擇協議缺少反向路由信息，因此RSVP引入了path報文。作爲發送者參加多播組的所有主機都要發出path報文，經由分發樹傳輸到所有的多播終點。
RSVP協議資源預留過程
1、發送數據的源端確定發送數據流所需的帶寬、延遲和延遲抖動等指標，並將其包含在PATH分組中發給接收端。
2、在網絡中的某一路由器接收到PATH分組時，它將PATH分組中的路徑狀態信息存儲起來，該路徑狀態信息描述了PATH分組上的上一級源地址(即發來該分組的上一跳路由器地址)。
3、當接收端收到PATH分組之後，它沿着與PATH分組中獲取的源路徑相反的方向方式一個RESV分組。該RESV分組包含爲數據流進行資源預留所需要描述的流量和性能期望等QoS信息。
4、當某一路由器接收到一個RESV分組時，它通過接納控制來決定是否有足夠的資源滿足QoS請求。如果有，就進行帶寬和緩衝區空間的預留，並且存儲一些與數據流相關的特定信息，然後將RESV分組轉發給下一個路由器;如果路由器必須拒絕該請求，則它返回給接收端一個錯誤信息。
RSVP資源預留消息由接收方發起並一次向上遊傳送，上游在這裏是從接收方到發送方的方向。在途徑的每一個結點上，資源預留請求會觸發下面的兩個動作：
1、在鏈路上進行資源預留
每一個結點上的RSVP進程（RSVP Process）都會將 請求資源預留的消息傳遞給接納控制部件（Admission Control）和策略控制部件（Policy Control）。只要這兩個部件中任何一個在檢測是否可接納時失敗，那麼資源資源預留請求就會被拒絕；同時，RSVP進程產生一個錯誤消息發送給接收方。如果二者都能成功，結點就會同時對分組流分類器進行相應的設置，從而在實際數據流傳輸時能夠將這個預留的數據分組從進入路由器中的所有分組中挑選出來，進而爲它提供QoS保證。
2、向上遊結點轉發資源預留請求 思科CCIE網絡工程師技術解析RSVP資源預留協議-ielab