在文档开始之前，我认为MPLS TE的信令协议是有必要知道的。
RSVP-TE
--协议本身比较成熟，已经规模应用。
--基于软状态，扩展性比较差。
CD-LDP
--协议比较新，不太成熟，基本没有应用。
--基于硬状态，扩展性比较好。
但是，最终还是市场来决定,RSVP因为先把茅坑占了，所以，一说到MPLS TE,大多数厂商都支持RSVP-TE.很少厂商支持CD-LDP协议。
貌似，RSVP-TE已经是一个业内的标准了。
所以学习MPLS TE有必要了解RSVP的运作。
RSVP的相关知识点有下面几点：
■R SVP基础
■RSVP分组
■RSVP操作
■现实世界中的RSVP.
RSVP协议类型是46,虽然把RSVP封装在UDP中是又可能的，但是MPLS TE从来不会把RSVP封装在UDP中。
RSVP是拿来做什么的？
我们都知道标签分发有几种方式：
MPLS LDP/TDP,这个是标准，用来分发mpls标签的协议。
RSVP,用于MPLS TE中的标签分发。
和LDP工作没有交集。
还有一个就是BGP对vrf路由的标签分发。
RSVP不是路由协议，任何路由决定都是IGP和CSPF做出的决定.（如果CSPF还有疑问，请参考
/351531/657115 , MPLS CSPF工作原理详解和相关实验），RSVP唯一的工作就是通告和维护网络中的保留资源。
MPLS TE中，RSVP在控制平面层保留带宽，所以没有对流量的转发平面上做任何控制。
RSVP有三种基本的功能：
■路径的建立和维护
■路径拆除
■错误通告。
RSVP的主要消息类型如下：一共有7类是主要应用。
关于RSVP信令的建立，简单说来，就2个步骤，原始节点向目的Router发送RSVP path消息，然后目的路由器收到path请求以后，向原始节点回复一个RESV.那么，一个TE隧道就建立成功了。
根据Eric Osborne CCIE 4122的著作MPLS TE流量工程中所描述的，这里我们来看一个RSVP是如何建立一条通路的。
下面就是一条路径建立的详细过程：
■在隧道首端完成CSPF的路径计算
■路径计算好了，首端节点向目的节点通过下一跳发送RSVP path请求。
■收到path请求的下游路由器会首先检查报文格式是否正确，然后检查path消息中的预留申请的带宽。
该过程叫准入控制。
■当准入控制成功以后，那么下游路由器会产生一个新的path请求，然后发送给通往目的路由节点的下一跳again。
直到发送到最后一个节点。
也就是MPLS TE隧道尾端的最后一个路由器。
■末节点路由器当收到了上游的path 请求以后会回复RSVP Resv消息进行回应。
也是一跳一跳的，逐跳反馈到原始节点。
这里再Resv报文中，不仅仅是对上游路由器的一个ACK回应，也包含了上游路由器沿TE LSP向尾端发送分组所用的标签。
说了那么多，来两个实际的例子：
在这里一共有10个步骤，在这个例子中，假设R1已经完成了CSPF路径的计算，并且知道它需要沿路径
R1->R2->R3->R5->R6->R7保留带宽。
第一步：R1向R2发送RSVP path请求，R2收到这个报文后，检查报文格式语法上是正确的，然后检查TE链路管理器，确定R1请求的带宽实际可用(实际上就是在R2上面进行比较ip rsvp bandwidth带宽，只要送过来的请求小于物理的rsvp 分配的带宽，就算通过.
第二步：R2向R3发送path，R3对path消息进行同样的验证。
第三步：R3向R5发送path，R5对path消息进行同样的验证。
第四步：R5向R6发送path，R6对path消息进行同样的验证。
第五步：R6向R7发送path，R7对path消息进行同样的验证。
第六步：R7因为是末节点，所以会返回一个显式空标签给R6.
第七步：R6发送一个Rsve给R5，分发标签为42.
第八步：R5向R3发送Rsve,分发标签100.
第九步：R3向R2发送Rsve,分发标签21.
第十步：R2向R1发送Rsve,分发标签18.
有了上面对于RSVP的说明，那么我们再进行逆向思维思考一下，根据这个原理，请求方发送rsvp path给下游路由器，下游路由器就要比较预留带宽和回应Rsve,进行标签的分发。
对应在设备的配置上面，至少应该做下面的事情：
在路径上的每台路由器接口上面，都应该把mpls ip, mpls ldp,ip rsvp bandwidth xxx,mpls traffic-eng tunnel都打开。
因为每个接口都要进行预留带宽的比较，如果没有配置如何进行比较呢？如果rsvp交互不成功，那么TE隧道如何能建立起来呢？
这就是为什么要再所有路由器上把相关流量工程的配置都加上去了。
对于mpls TE配置感兴趣的同学可以参考一下：
/351531/641039
MPLS TE 流量工程路径选择原理和配置模板for CISCO.
如果有了上面的原理概念以后，下面就是一个具体的信令交互图了.
如果从信令的交互的角度来讲，下面是我整合的信令交互的步骤：
这里如果认真阅读报文交互内容，我们会发现，R1发送RSVP path到R3的loopback 0，请求TE的建立。
然后R3逐一给R2，R2给R1进行RSVP的标签分配。
实际上RSVP分组我没有细看，报文格式比较复杂，而且种类繁多。
我只能暂时先坐一个原理性了解。
以后有空再慢慢深入。
到现在为止，详细的原理已经有一堆了，但是真正的实际动手实验还没有做。
下面有一些命令，至少，需要很熟悉的应用，才对得起已经学习的那么久的RSVP的原理：
show ip rsvp counters
show ip rsvp interface
show ip rsvp neighbor
show ip rsvp reservation
show ip rsvp counters,该命令显示了路由器启动时，在每一个接口上已经产生的RSVP消息类型的统计.
在这个命令里面我认为主要看path 和Resv报文的收发情况，就可以判断是否是TE的RSVP出了问题，如果发送了path,也收到了Resv，问题应该不会在RSVP上面至少。
还有一个命令，是关于RSVP接口的邻居：
也可以显示show ip rsvp neighbor detail进行深度排查，不过进行初步排查，只要x.x.x.x后面显示的是RSVP，那么邻居就没有问题。
这里有一个很重要的概念，RSVP是没有显式的邻居发现阶段，意思就是，如果两个直连的接口激活了RSVP，你show ip rsvp neighbor是没有邻居的，邻居的建立，是要他们相互看到对方的RSVP path和Resv消息以后才能建立邻居。
通过show ip rsvp interface,可以看到当前R3上面G3/0对于隧道分配的实际带宽是1024K,而预留带宽为4096K.
呵呵，最后一个命令，当隧道建立起来，如果有逻辑上的问题，可以用上面的命令进行故障排查。
逐跳进行检测。
总结：
我把上面的四个命令按照逻辑顺序做一个小的总结，如果MPLS TE隧道要正常的建立起来，那么首先按照RSVP的原理，show ip rsvp counters interface xxxx,应该可以看到发送的RSVP path和接收到的RSVP Resv是几乎相等的，否则光发不收，不发不收都不正常，需要沿链路检查所有接口下面的配置是否正确。
如果show ip rsvp counters正确，在看show ip rsvp neighbor也是应该有的，然后再来沿途检查预留带宽是否正常，用命令show ip rsvp interface检查，最后，隧道up起来以后，也可以看相关的show ip rsvp reservation检查逻辑上是否有问题。
最后，生成的路径应该在show mpls traffrac tunnel下面显示：
本文出自“hank--我,只关注原理” 博客，请务必保留此出处。
