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是独立异步发送的。