MPLS RSVP消息处理

RSVP消息处理

接到本地隧道修复通知后，通知头端流量通过可能的二次保护路径转发。然后，头部试图重新通过LSP。如果找不到替代路径，会发生什么？例如，将LSP这种情况发生在配置为故障链路的显式路径上。是拆除LSP或者让它保留在保护路径上，由当地的头部策略实施。假设该策略允许继续使用保护路径，下一个问题是：LSP能永远保持在保护路径上吗？原则上可以，但实际上要注意更多的细节。RSVP需要用Path和Resv消息定期刷新。除非这些消息继续正确生成和处理LSP加班。因此，链路失败后，需要通过备份隧道转发这些信息。

一旦发现受保护的链路故障，流量将从主LSP做好准备。如果转发状态已经提前安装，可以在转发引擎中完成，无需控制平面干预，实现流量的快速恢复。但事实并非如此。故障发生后，控制平面需要采取多种措施。

抑制LSP拆除

即使受保护LSP链路故障发生在头端或尾端IGP通知还必须抑制任何错误，以防止可用的本地保护LSP破坏当地保护的目的。

LSP头端通知

备份的目的是LSP头端查找LSP保护备用路径的流量，避免链路故障。PLR使用 Notify错误代码和 Tunnel Local Repaired”子代码的RSVP Path Error消息通知头端。

此外，记录路由对象还将使用一个新的标表示路径是本地修复的。但是，当头部通过时IGP为什么在发现故障时需要这些？因为依靠其他协议进行故障通知并不总是有效的。例如，当跨越多个时IGP区域或AS时，IGP通知无法到达头端。

新路径计算及信令

当头端收到切换备用路径的信息时，将重新计算LSP，避免故障链路，先通后断。这意味着需要当地的保护LSP总是以显式共享的形式发布，允许新路径和旧路径共享资源。新路径也可以在保护期间建立相同的链路，如明确指定的路径而不是动态的。如果通过故障链路或节点CSPF无法实施，本地修复将永远存在，旁路LSP它只被视为一跳。