网工扫盲篇：RSVP-TE 是什么？

RSVP-TE

RSVP-TE 概述

现在使用两种 QoS体系： IntServ （Integrated Service ，综合业务模型）和 DiffServ（Differentiated Service ，区分业务模型）。

RSVP （Resource Reservation Protocol ，资源预留协议） 是为 IntServ（Integrated Service ，综合业务模型） 而设计的， 用于在一条路径的各节点上进行资源预留。 RSVP工作在传输层，但不参与应用数据的传送，是一种 Internet 上的控制协议，类似于 ICMP。

简单来说， RSVP具有以下几个主要特点：

• 单向；
• 面向接收者，由接收者发起对资源预留的请求，并维护资源预留信息；
• 使用“软状态”（ soft state ）机制维护资源预留信息。

RSVP经扩展后可以支持 MPLS标签的分发， 并在传送标签绑定消息的同时携带资源预留信息，这种扩展后的 RSVP称为 RSVP-TE，作为一种信令协议用于在 MPLS TE中建立 LSP隧道。

RSVP-TE 基本概念

(1) 软状态

“软状态”是指在 RSVP-TE中，通过消息的定时刷新来维持节点上的资源预留状态。

资源预留状态包括由 Path 消息创建的路径状态（ path state ）和由 Resv 消息创建的预留状态（ reservation state ）。这两种状态分别由 Path 消息和 Resv 消息定时刷新。对于某个状态，如果连续没有收到刷新消息，这个状态将被删除。

(2) 资源预留类型

使用 RSVP-TE建立的 LSP都具有某种资源预留类型（ reservation style ），在建立 RSVP会话时，由接收者决定此会话使用哪种预留类型，从而决定可以使用哪些 LSP。

目前设备支持以下两种预留类型：

• FF（Fixed-Filter style ）：固定过滤器类型。为每个发送者单独预留资源，不能与同一会话中其他发送者共享资源。
• SE（Shared-Explicit style ）：共享显式类型。为同一个会话的发送者建立一个预留，可以共享资源。

由于目前同一会话不能同时存在多条 LSP，SE资源预留方式主要用于中断前建立（make-before-break ）。

make-before-break

make-before-break 是指一种可以在尽可能不丢失数据，也不占用额外带宽的前提下改变MPLS TE隧道属性的机制。

在图 1-1 中，假设需要建立一条 Router A到 Router D的路径，保留 30M带宽，开始建立的路径是 Router A →Router B →Router C →Router D 。

现在希望将带宽增大为 40M，Router A→Router B→Router C→Router D路径不能满足要求。而如果选择 Router A →Router E →Router C →Router D ，则 Router C →Router D 也存在带宽不够的问题。

采用 make-before-break 机制，新建立的路径在 Router C →Router D 可以共享原路径的带宽，新路径建立成功后， 流量转到新路径上， 之后拆除原路径， 从而有效地避免了流量中断。

RSVP-TE 消息类型

RSVP-TE使用 RSVP的消息类型，并进行了扩展。 RSVP使用以下消息类型：

• Path 消息：由发送者沿数据报文传输的方向向下游发送，在沿途所有节点上保存路径状态（ path state ）。
• Resv 消息：由接收者沿数据报文传输的方向逆向发送， 在沿途所有节点上进行资源预留，并创建和维护预留状态（ reservation state ）。
• PathTear 消息：此消息产生后马上向下游发送，并立即删除沿途节点的路径状态和相关的预留状态。
• ResvTear 消息：此消息产生后马上向上游发送，并立即删除沿途节点的预留状态。
• PathErr 消息：如果在处理 Path 消息的过程中发生了错误，就会向上游发送 PathErr 消息， PathErr 消息不影响沿途节点的状态，只是把错误报告给发送者。
• ResvErr 消息：如果在处理 Resv 消息的过程中发生了错误，或者由于抢占导致预留被破坏，就会向下游节点发送 ResvErr 消息。
• ResvConf 消息：该消息发往接收者，用于对预留消息进行确认。
• Hello 消息：在两个直连的 RSVP邻居之间建立和维持链路局部的邻居关系。RSVP的 TE扩展主要是在其 Path 消息和 Resv 消息中增加新的对象， 新增对象除了可以携带

标签绑定信息外，还可以携带对 LSR在沿途寻找路径时的限制信息，从而支持 CR-LSP的功能，并支持 FRR。

Path 消息新增的对象包括： LABEL_REQUEST 、EXPLICIT_ROUTE 、RECORD_ROUTE 和SESSION_ATTRIBUTE 。

Resv 消息新增的对象包括： LABEL和 RECORD_ROUTE 。

LABEL_REQUEST 对象包含在 Path 消息中，为 LSP请求标签绑定，该对象也保存在路径状态块 PSB （Path State Block ）中。接收到该对象的节点将分配的标签通过 Resv 消息中的 LABEL对象通知上游节点，从而完成标签的发布和传递。

建立 LSP隧道

图 1-2 是使用 RSVP建立 LSP隧道的示意图。

使用 RSVP建立 LSP隧道的过程可以简单描述为：

(1) Ingress LSR 产生携带标签请求信息的 Path 消息，沿着通过 CSPF计算出的路径逐跳发送给 Egress LSR ；

(2) Egress LSR 收到 Path 消息后，产生携带预留信息和标签的 Resv 消息，沿着 Path 消息发送的相反路径逐跳返回 Ingress LSR ，同时， Resv 消息在沿途的 LSR上进行资源预留；

(3) 当 Ingress LSR 收到 Resv 消息时， LSP建立成功。

采用 RSVP-TE建立的 LSP具有资源预留功能， 沿途的 LSR可以为该 LSP分配一定的资源， 使在此 LSP上传送的业务得到保证。

RSVP 刷新机制

RSVP通过 Refresh 消息来维护路径和预留状态， Refresh 消息不仅用于在 RSVP邻居节点进行状态同步，也用于恢复丢失的 RSVP消息。

Refresh 消息并不是一种新的消息，它是以前发布过的消息的再次传送， Refresh 消息中携带的主要信息和传送时使用的路径都与它要刷新的消息完全一致。只有 Path 消息和 Resv消息才可能是 Refresh 消息。

由于 Refresh 消息是定时发送的，当网络中的 RSVP会话比较多时， Refresh 消息会加重网络负载； 而对于时延敏感的应用， 当消息丢失时， 等待通过 Refresh 消息恢复的时间可能无法接受。简单地调整刷新间隔并不能同时解决这两类问题。

RFC 2961（RSVP Refresh Overhead Reduction Extensions ）定义了几种新的扩展机制，用于解决 Refresh 消息带来的上述问题。

(1) Message_ID 扩展

RSVP本身使用 Raw IP 发送消息，RFC 2961 中定义的 Message_ID 扩展机制增加了可以在 RSVP消息中携带的对象，其中， Message_ID 和 Message_ID_ACK对象用于 RSVP消息确认，从而提高 RSVP消息发送的可靠性。

在接口使能 Message_ID 机制后， 可以配置重传功能， 设定 RSVP消息的重传参数。 如果在重传初始时间间隔内 （假设为 Rf 秒），没有收到应答消息 ACK，经过（1＋Delta ）×Rf 秒后，将重传此消息。

(2) 摘要刷新扩展

摘要刷新 Srefresh （Summary Refresh ）可以不传送标准的 Path 或 Resv 消息，而仍能实现对 RSVP的状态刷新，从而可以减少网络上的 Refresh 消息流量，并加快节点对这类消息的处理速度。

摘要刷新扩展需要与 Message_ID 扩展配合使用。只有那些已经被包含 Message_ID 对象的Path 和 Resv 消息发布过的状态才能使用摘要刷新扩展机制刷新。

文章来源: blog.csdn.net，作者：wljslmz，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/weixin_43025343/article/details/119009717