MPLS TE之CSPF與RSVP

此篇梳理MPLS TE的路徑計算組件以及信令協議。在IOS環境下，其實主要也就是CSPF與RSVP。之因此放在一塊兒講，其實就是在CSPF計算完成路徑以後，RSVP要負責搭建LSP。二者前後邏輯明顯。

CSPF

CSPF Constrained Shortest Path First是帶有附加條件的SPF算法。
其多出來的約束條件爲：
管理權重---TE metric
可用帶寬---這個是鏈路的即時帶寬，而非僅僅是咱們ip rsvp bandwidth宣告的那個數值
鏈路屬性

CSPF不是爲了發現到全部目的地路由器最佳路徑而設計的，而是僅僅爲了到達LSP隧道的終點。即咱們在定義MPLS TE tunnel時，那個tunnel destination。

TE Metric
在選擇LSP tunnel的過程當中，缺省使用IGP metric來決策，一旦使用了TE metric，IGP metric就會失效。
TE metric是配置在隧道出方向的物理接口上。
全局方式下使用
mpls traffic-eng path-selection metric te

顯示路徑 explicit path
顯示路徑就是有一系列節點構成，相鄰的節點能夠有如下關係

1. stric ： 兩個節點必須直連
2. loose： 兩個節點不須要必定直連，能夠在當中有路由器
   經過next-address/exclude 命令來控制LSP tunnel通過或不通過此節點。

interface tunnel 10
tunnel mpls traffic-eng path-option 10 explicit name CCIE
ip explicit-path name CCIE enable
next-address loose 150.1.1.33

interface tunnel 20
tunnel mpls traffic-eng path-optio 20 explicit name JNCIE
ip explicit-path name JNCIE enable
next-address strict 150.1.33.133

總結：創建mpls TE tunnel的目的，在於選擇一條從源到目的而且知足約束條件的最佳路徑，而非最短路徑。

TE 的信令協議
通常MPLS TE在組件LSP的協議方面，通常都是用RSVP。像CR-LDP這種協議由於用的較少因此不在討論範圍內了。
RSVP本來是個QoS使用的協議，但做爲集成QoS模型，擴展性實在較差，因此直接被丟棄。只能做爲MPLS TE的一種組件LSP的信令協議來使用。

RSVP的三種功能
1 路徑的創建和維護
2 路徑的拆除
3 路徑的通告

RSVP幾個消息類型
Path： 用來創建和維護保留LSP
Resv： 相應Path消息，用來創建和維護LSP。
PathTear： 結構與Path類似，用於刪除LSP時使用
Resv：對應於PathTear，相應PathTear，確認刪除LSP
PathErr：接收到錯誤的Path消息發送
ResvErr：接收到錯誤的Resv消息後發送

一個重點就是RSVP組件的LSP，永遠是單向的！因此通常的TCP會話有可能通過的是不一樣的路徑。這在大型骨幹網絡裏常常可能出現不對稱路由問題。

前文提到RSVP原本只是個QoS時使用的協議，在MPLS TE中，須要對其進行擴展，才能更好的支持TE。一下即是擴展的功能：

1. 支持DoD Downstream on Demand 方式的標籤發放
2. 支持爲顯示的LSP tunnel分配網絡資源
3. 支持對已創建的LSP tunnel改變屬性，採用make before break的方式
4. 支持LSP tunnel通過的每一個節點，能夠用來防止環路
5. 支持對LSP tunnel進行診斷

RSVP TE報文中包含的對象
Label Request：Path message中
Label： Resv message中
Explicit Path：存在Path消息中
Record Route：存在於Path和Resv message中
Session Attribute： 存在Path message中，含有重要的標誌位

1. 0x01 但願獲得fast-reroute功能
2. 0x02 但願進行標籤記錄
3. 0x04 但願獲得SE類型
   Sender template：存在於path message中，含有隧道發送者地址，LSP ID
   Session：包含有隧道終點地址，tunnel ID

如下就是PATH和Reserve message的兩個抓包截圖。

路徑的維護與路徑創建過程相似，因此RSVP被稱爲soft-state協議，每30秒，tunnel首端發送path給下游鄰居。同時，下游鄰居每30秒向上遊發送reserve協議。注意：path與reserve message是獨立異步發送的。