RSVP的讲解（预留带宽 & 分配 MPLS TE标签）
1、RSVP 是什么样的一个协议
1.1、InterServ 信令协议（软协议：1.本身并不具备选路功能；2.协议本身不工作）
1.2、为某个应用预留它所需要的资源
r7(config)#ip rsvp sender-host 9.9.9.9 7.7.7.7 TCP 100 1000 100 1000（端口都配置 RSVP 前提下）
r9(config)#ip rsvp reservation-host 9.9.9.9 0.0.0.0 TCP 100 0 WF RATE 100 1000
r8#debug ip rsvp all（如果 r7 不对 r9 进行 TCP 请求触发，r8 将不回看到任何debug信息）
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: RSVP-POLICY - Path query
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: POLICY-LOCAL - query for
inbound Path message
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: POLICY-LOCAL -
no decision (can't find a matching policy)
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: POLICY-COPS - COPS query
for Path message
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: POLICY-COPS - no active
COPS server entry for this session. Ignoring
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: RSVP-POLICY - granting
default policy for Path
*Aug 22 02:07:01.515: RSVP: 7.7.7.7_1000->9.9.9.9_100[0.0.0.0]: RSVP-POLICY - received
decision for Path message
只要开启应用触发就可以看到 7.7.7.7 对 9.9.9.9 的 TCP 端口请求
RSVP本身不工作，需要网络应用去触发
Netmeeting / VoIP
MPLS TE
WFQ 对 RSVP 支持的必要性?
传统 RSVP 及扩展 RSVP 对 MPLS TE 的支持
Label Request
Label
ERO：记录的是 CBR 给 tunnel 计算出来的最短路径的每一个接口地址
RRO：记录的是 tunnel 经过的每个网络节点 tunnel 的 router-id 和这个网络节点给 tunnel 分配的标签（也可以用于控制环路避免）
Session attribute：attribute-flag ； Setup-Priority ； Hold-Priority
RSVP 为 TE 的资源保证出口方向有效
只要 TE 的接口功能开启，RSVP 默认情况下后台开启
RSVP 标签请求过程（类似于 MPLS Cell - mode 标签请求过程）
==================================================
在文档开始之前，我认为MPLS TE的信令协议是有必要知道的。
RSVP-TE
--协议本身比较成熟，已经规模应用。
--基于软状态，扩展性比较差。
CD-LDP
--协议比较新，不太成熟，基本没有应用。
--基于硬状态，扩展性比较好。
但是，最终还是市场来决定,RSVP因为先把茅坑占了，所以，一说到MPLS TE,大多数厂商都支持RSVP-TE.很少厂商支持CD-LDP协议。貌似，RSVP-TE已经是一个业内的标准了。所以学习MPLS TE有必要了解RSVP的运作。
RSVP的相关知识点有下面几点：
■RSVP基础
■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做出的决定.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犌肭笠院蠡峄馗碦SVP 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隧道如何能建立起来呢？
这就是为什么要再所有路由器上把相关流量工程的配置都加上去了。
如果有了上面的原理概念以后，下面就是一个具体的信令交互图了.
如果从信令的交互的角度来讲，下面是我整合的信令交互的步骤：
这里如果认真阅读报文交互内容，我们会发现，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下面显示：
