MPLS RSVP訊息處理——Vecloud

　　RSVP訊息處理

　　收到“本地隧道修復”通知後，通知頭端，流量是透過可能次優的保護路徑轉發。然後，頭端嘗試重新路由LSP。如果找不到替代路徑，會怎樣?例如，將LSP配置為故障鏈路的顯式路徑，則會發生這種情況。是拆除LSP還是讓其保留在保護路徑上，由頭端的本地策略實施。假設策略允許繼續使用保護路徑，下一個問題是：LSP可以永遠保持在保護路徑上嗎?原則上可以，但實際上必須注意更多細節。RSVP需要用Path和Resv訊息定期重新整理其狀態。除非繼續正確生成和處理這些訊息，否則LSP將超時。因此，鏈路失敗後，需要透過備份隧道轉發這些訊息。

　　一旦檢測到受保護的鏈路故障，流量就會從主LSP切到備。如果轉發狀態已提前安裝，則可在轉發引擎中完成，無需控制平面干預，實現快速恢復流量。但事實並非如此，故障發生後，控制平面上需要採取很多措施。

　　抑制LSP拆除

　　即使受保護LSP頭端或尾端收到鏈路故障的IGP通知，也必須抑制任何錯誤生成，防止本地保護可用時導致LSP斷開，破壞本地保護的目的。

　　LSP頭端通知

　　備份的目的是LSP頭端查詢LSP備用路徑時保護流量，從而避免鏈路故障。為此，PLR會透過使用“ Notify”錯誤程式碼和“ Tunnel Local Repaired”子程式碼的RSVP Path Error訊息通知頭端。

　　此外，記錄路由物件還會用一個新的標記，指示該路徑是本地修復的。但是，當頭端將透過IGP找出故障時，為什麼還需要這些?因為依賴於其它協議進行故障通知並不總是有效。例如，當跨越多個IGP區域或AS時，IGP通知不能到達頭端。

　　新路徑計算和信令

　　當頭端收到關於切換備用路徑的資訊，將重新計算LSP，避免出現故障的鏈路，並以先通後斷的方式進行。這意味需要本地保護的LSP總以“顯式共享”的形式發出，從而允許新路徑與舊路徑共享資源。新路徑也可能會在保護期間使用相同的鏈路建立，比如用明確指定路徑而非動態的方式。如果經過故障鏈路或節點，則CSPF無法執行，本地修復會一直存在，旁路LSP也只會被視為一跳。