[发明专利]一种招呼会话重建方法及系统

说明书

技术领域

本发明涉及网络通信技术领域，尤其涉及一种招呼（hello）会话重建方法及系统。

背景技术

多协议标签交换（Multiprotocol Label Switching，MPLS）是一种利用标签（label）进行高速、高效数据转发的技术；其中，多协议是指MPLS支持多种网络层协议，标签交换是指对报文附上标签，根据标签进行转发。

在MPLS网络中，要传送的数据要带上被称为标签（label）的定长字段，数据从源到目的地是通过标签在MPLS网络中进行选路。

其中，标签交换路由器（Label Switching Router，LSR）指的是构成MPLS网络的路由器。流量工程(Traffic Engineering，TE)指的是运用MPLS技术对流量进行管理、控制，将用户的业务数据流映射到物理拓扑/链路上的一项任务。

下面介绍一些资源预留协议平滑重启（Resource Reservation ProtocolGraceful Restart，RSVP GR）的相关概念：

平滑重启重启器（GR restarter）：负责对重启前对RSVP的转发表项和带宽资源信息进行实时备份，重启后对这些信息进行恢复。

平滑重启帮助器（GR helper）：负责帮助GR restarter恢复转发表项，不涉及重启等问题。

通常hello会话通过两个接口进行建立，现有建立hello会话的LSR分为主动类型和被动类型，其中，当存在以建立hello会话的接口作为出接口的标记交换路径（Label Switching Path，LSP）时，判定该LSR为主动类型，主动类型的LSR既可以发送hello请求（REQ）报文，也可以发送hello应答（ACK）报文，可以通过主动发送hello REQ报文主动触发hello会话；当不存在以建立hello会话接口作为出接口的LSP时，判断该LSR为被动类型，被动类型的LSR只能发送hello ACK报文，被动接收hello REQ报文。

如此，根据hello会话中上述的情况得知有如下应用场景：

场景一：当建立hello会话的两端都不存在以该接口作为出接口的LSP时，无法建立hello会话；场景二：当一端存在以该接口作为出接口的LSP，另一端接口不存在以该接口作为出接口的LSP时，存在以该接口作为出接口的LSP的一端为主动端，不存在以该接口作为出接口的LSP的一端为被动端；场景三：当两端都存在以该接口作为出接口的LSP时，两端同时发送hello REQ消息，此时主动端和被动端的确定取决于两端接收到hello REQ消息的先后顺序，先接收到hello REQ消息的一端设置为被动端，后接收到hello REQ消息的一端则为主动端。

TE GR中的hello会话，需要在节点故障之后以及控制面恢复之前恢复hello会话。若使用如上所述的hello会话的处理方案，应用于上述场景，则会存在如下问题，下面结合图1进行说明，图1中，R2为需要重启的GR restarter，R1和R3为可以作为GR helper的上/下游节点，即R2的邻居节点。

场景一：在R2重启前，R2和R3不存在以该接口作为出接口的LSP，此时无法建立hello会话，因此，在R2重启时，由于RSVP协议面没有LSP需要进行恢复，因此没有必要建立TE GR hello会话，因此这种场景下不会出现问题；

场景二：在R2发生重启前，R2存在以该接口作为出接口的LSP，R2将作为hello会话的主动端，R3不存在以该接口作为出接口的LSP，只能作为hello会话的被动端。当R2发生重启，R2的控制面信息将消失，R3作为TE LSP的下游节点，与R2相连的接口也不存在以该接口作为出接口的LSP；此时，若使用上述hello会话建立的方案，将无法建立hello会话，那么R3将无法作为TE GR的helper端检测到R2的重启，进而无法协助R2进行TE协议面的恢复；

场景三：当R4->R1还存在TE隧道tunnel2时，R2和R3相连的接口都存在以该接口作为出接口的LSP，根据上述建立hello会话的过程，两端之间建立hello会话，主动端和被动端的选取取决于两端接收到hello REQ消息的先后顺序，如此，会出现以下两种情况：