对比文件名称：2008-08-14_US2008192762A_发明申请_US20080192762A1 GRACEFUL RESTART FOR USE IN NODES EMPLOYING LABEL SWITCHED PATH SIGNALING PROTOCOLS
目标专利名称：1087快速重新路由条件下的RSVP-TE完美重启CN102598599B
本次调用的模型名称：（未提供，此处省略）
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 与不紧邻所述网络单元的远程节点建立HELLO会话 <br> **《隐含公开》** | 对比文件摘要部分及第[0151]段描述了RSVP-TE完美重启中使用Hello消息和RESTART_CAP对象来通告重启能力。例如，第[0151]段记载：“The RESTART_CAP objection is used to indicate to a peer node(s) the Graceful Restart capability... This object may be carried in RSVP Hello messages...”。对比文件第[0170]-[0176]段讨论了快速重路由(FRR)与完美重启(GR)的结合使用。其中第[0171]段指出，当LSR检测到与邻居控制平面的通信中断时，应激活RSVP-TE完美重启。然而，对比文件通篇强调的是在直接连接的邻居（紧邻节点）之间通过Hello消息建立会话以支持完美重启，并未明确提及与“不紧邻”的远程节点建立Hello会话。但是，在第[0170]-[0176]段关于FRR与GR结合的上下文中，本领域技术人员可以合理推断，当FRR被激活，业务通过旁路隧道传输时，保护路径的端点（如PLR和MP节点）可能不再是物理上的紧邻节点。为了在这种FRR场景下仍能应用对比文件所教导的RSVP-TE完美重启机制，其前提必然是需要在这些逻辑上相邻但物理上不紧邻的节点之间建立某种用于交换重启能力的通信。虽然对比文件未明确定义“不紧邻节点的Hello会话”，但其在FRR场景下应用GR的教导，为建立这种会话提供了动机和可能性，使得本领域技术人员能够推断出该技术方案。因此，该特征被隐含公开。 | |
| **技术特征B：** 以基于在所述HELLO会话期间交换的HELLO消息确定所述远程节点是否重启 <br> **《直接公开》** | 对比文件第[0158]段描述了重启节点在重启完成后，通过Hello消息向对等节点通告其恢复时间(Recovery Time)。第[0163]段描述了邻居节点如何检测到与重启节点的RSVP通信中断（即节点down）。第[0164]段进一步说明，邻居节点在检测到通信中断后，会等待一段时间（重启时间），并尝试重新建立RSVP通信。如果通信在时间内恢复，且重启节点通告的恢复时间不为零（表明其保留了转发状态），则邻居节点会采取后续的GR操作。引用内容：“When a node detects that its communication with a peer node's control component went down... the node should wait certain amount of time... While waiting, the node should try to re-establish RSVP communication with the peer node... If ... the restarting node's control component restarted within the time and was able to preserve its MPLS forwarding state... as indicated by a non-zero Recovery Time carried in the RESTART_CAP object of the RSVP Hellos received from the neighbor...”。 | 目标专利中的“确定所述远程节点是否重启”功能，在对比文件中通过一套完整的机制实现：首先，邻居节点通过Hello消息或其它方式检测到与对等节点的通信中断（隐含了节点可能发生重启）；随后，在重新建立通信后，通过接收重启节点发送的Hello消息中携带的RESTART_CAP对象里的Recovery Time字段来确认节点是否已完成重启并保留了转发状态。对比文件明确教导了利用Hello会话及其交换的消息（特别是携带RESTART_CAP对象的Hello消息）来判断对等节点是否已重启以及重启后的状态。因此，该技术特征被直接公开。 |
| **技术特征C：** 以便保留并恢复所述网络单元与所述远程节点之间一个或多个受保护标签切换路径(LSP)的状态信息 <br> **《直接公开》** | 对比文件摘要和发明内容部分（§2. SUMMARY OF THE INVENTION）明确阐述了本发明的目的。例如，第[0036]段记载：“The present avoids purging label-based forwarding information in the event that the control component ... of one node in a path is restarting, provided that the node is capable of preserving its label-based forwarding information across the restart ...”。第[0037]段记载：“...having the restarting node and its peers preserve and use “stale” (not updated) forwarding information for a limited time.” 第[0070]段有类似的描述。在RSVP部分，第[0155]段描述：“... the restarting node is willing to retain its MPLS forwarding state that it preserved across the restart of its control component.” 第[0158]段也描述了重启节点在重启后保留MPLS转发状态。 | 目标专利中特征C的目的“保留并恢复受保护LSP的状态信息”，与对比文件的核心发明目的完全一致。对比文件通篇都在教导如何在控制平面重启时，通过让重启节点及其邻居保留并使用“陈旧”的标签转发信息（即LSP状态信息），来最小化对LSP上数据流的影响，并在重启完成后恢复或刷新这些状态信息。这直接对应于保留并恢复LSP状态信息。因此，该技术特征被直接公开。 |
| **技术特征D：** 为了鉴于所述远程节点的重启而在所述网络单元内执行重启过程的目的 <br> **《直接公开》** | 对比文件第[0036]段、第[0070]段等均描述了其机制是为了在控制平面重启时最小化影响。特别是在RSVP部分，第[0158]段描述了节点在自身控制平面重启完成后，检查是否保留了转发状态，并根据情况启动定时器，标记陈旧条目，通告恢复时间等一系列操作，这本身就是重启节点内部执行的重启过程。第[0159]段描述了重启节点接收Path消息并处理以恢复状态的过程。引用内容：“After a node has completed the restart of its control plane, it should check whether it was able to preserve its MPLS forwarding state... If ... the restarting node has preserved its forwarding state, then it starts its internal timer... and marks all the MPLS forwarding state entries as “stale”.” | 目标专利的特征D描述了在本地网络单元内执行重启过程的目的。对比文件详细记载了节点在自身重启后，为了利用GR机制，在内部执行的一系列操作，包括检查状态保留情况、启动转发状态保持定时器、标记陈旧状态、以及在接收到对等节点的标签绑定时进行状态匹配和刷新。这一系列操作构成了节点内部的“重启过程”，其目的正是为了与远程节点的GR机制相配合，实现状态的平滑恢复。因此，该特征被直接公开。 |
| **技术特征E：** 响应于不紧邻所述网络单元的所述远程节点的配置和自动发现之一，在所述受保护LSP的链路/节点故障之前与所述远程节点建立HELLO会话，包括与远程节点交换HELLO消息 <br> **《隐含公开》** | 对比文件第[0150]段指出，如果节点能在控制平面重启时保留MPLS转发状态，那么不扰动经过该节点的LSP是期望的，并描述了RSVP-TE GR方法。第[0151]段描述了使用RESTART_CAP对象在RSVP Hello消息中指示GR能力。第[0170]-[0171]段讨论了FRR和GR的结合，并设定了在接口up但控制平面通信中断时激活GR的条件。此外，对比文件第[0124]-[0126]段描述了LDP协议中通过Initialization消息通告GR能力，这个过程发生在任何重启之前。对于RSVP，第[0156]段描述了支持GR的Hello消息格式：“<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO> [<RESTART_CAP> ]”。 | 对比文件教导了节点通常在正常运行期间（即任何故障或重启之前）通过Hello消息交换RESTART_CAP对象来通告其GR能力，这构成了在故障前建立Hello会话的基础。虽然对比文件没有明确指出这种会话可以建立在“不紧邻”的节点之间，但结合其关于FRR场景下应用GR的教导（§4.3.4最后部分），本领域技术人员可以合理推断，为了在FRR保护路径的端点（逻辑邻居）间实现GR，必须在故障发生前（或至少在GR需要前）通过某种方式发现并建立与这些逻辑邻居的会话。对比文件提及的静态配置LSP或通过信令协议自动发现邻居是建立会话的常规前提。因此，在故障前通过配置或自动发现与远程（逻辑）节点建立用于GR的Hello会话，是从对比文件FRR与GR结合的方案中可合理推断出的技术方案。因此，该特征被隐含公开。 |
| **技术特征F：** 其中每个HELLO消息在要使用因特网协议(IP)转发协议路由所述HELLO消息的情况下包含值大于1的生存时间(TTL) <br> **《未公开》** | 经过全面检索对比文件全文，未发现任何关于修改或设置HELLO消息的IP生存时间（TTL）值的描述。对比文件中所有关于HELLO消息的讨论，均基于标准RSVP协议（如RFC 3209）中紧邻节点间交换的设定，其默认TTL值为1。 | 对比文件的整个技术方案建立在标准的RSVP-TE和LDP等协议之上，这些协议中HELLO消息的TTL值默认为1，用于紧邻节点间的通信。对比文件没有任何文字或暗示表明需要、或已经将HELLO消息的TTL值修改为大于1，以使其能够穿越多跳到达非紧邻节点。由于该特征是目标专利解决非紧邻节点通信问题的关键技术手段之一，而对比文件完全没有涉及，因此本领域技术人员无法从对比文件中直接且毫无疑义地得出该技术特征，也无法通过合理推断得出。该特征未被公开。 |
| **技术特征G：** 其中每个HELLO消息在要经由在本地节点与远程节点之间建立的旁路隧道转发所述HELLO消息的情况下包含为1的TTL值 <br> **《未公开》** | 与特征F的论述相同，经过全面检索对比文件全文，未发现任何关于修改或设置HELLO消息的IP生存时间（TTL）值的描述，无论是设置为大于1还是保持为1。更未提及在何种转发路径（如旁路隧道）下应如何设置TTL值。 | 对比文件完全没有涉及HELLO消息TTL值的设置问题。目标专利中根据HELLO消息的转发方式（IP转发或隧道转发）来区别设置TTL值的技术手段，在对比文件中既无文字记载，也无任何技术启示。本领域技术人员无法从对比文件中获得该技术方案。因此，该特征未被公开。 |
| **技术特征H：** 响应于所述受保护LSP的链路故障和节点故障中的至少一个，根据快速重新路由(FRR)方案将网络业务切换到保护路径上 <br> **《直接公开》** | 对比文件第[0170]-[0176]段讨论了FRR与GR的结合。第[0175]段明确列出了在不同情况下应采取的行动。其中最后一条明确指出：“If the interface to a neighbor goes down, the LSR should activate fast reroute.” 引用内容：“If the interface to a neighbor goes down, the LSR should activate fast reroute.” 此外，第[0032]段也提到了链路或接口down时进行重路由的技术，并引用了一个关于快速重路由的专利申请。 | 目标专利的特征H描述了在受保护LSP发生链路或节点故障时，根据FRR方案将业务切换到保护路径。对比文件第[0175]段明确教导了当通往邻居的接口down（即发生链路故障）时，LSR应激活快速重路由。激活快速重路由本身就包含了将受影响业务切换到预先建立的保护路径（旁路隧道）上的含义。这与目标专利的该特征在作用和操作上完全一致。因此，该技术特征被直接公开。 |
| **技术特征I：** 如果在所述受保护LSP的链路/节点故障之前尚未建立所述HELLO会话，则与不紧邻所述网络单元的所述远程节点建立所述HELLO会话，包括与远程节点交换HELLO消息 <br> **《隐含公开》** | 对比文件第[0170]-[0176]段讨论了FRR和GR的关系。第[0171]-[0173]段描述了在接口up但控制平面通信中断（即邻居可能重启）的情况下，应激活RSVP-TE GR。虽然这些段落描述的场景是节点检测到通信中断，而非目标专利中明确指出的“在故障之后建立会话”，但对比文件在FRR上下文中应用GR的教导，为本领域技术人员提供了动机：即在FRR切换后，保护路径上的端点（如PLR和MP节点）之间可能尚未建立GR所需的Hello会话，为了在此场景下仍能实现GR，必须在FRR事件发生后，在这些端点之间建立通信。 | 对比文件教导了将FRR和GR结合使用，并规定了在不同故障条件下应激活哪种机制（FRR或GR）。其逻辑是，当物理链路故障时激活FRR，当控制平面通信故障时激活GR。然而，在实际网络场景中，一个物理链路/节点故障会同时触发FRR的业务切换，并可能导致控制平面通信中断。为了在FRR的保护路径上也能实现GR，即使故障前尚未建立会话，也需要在故障后建立。对比文件虽然未明确写出这一时序和操作，但其将FRR和GR作为互补机制进行论述的整体方案，使得本领域技术人员在面对“FRR已生效但GR会话尚未建立”这一具体问题时，能够合理且自然地推断出需要在FRR切换后建立GR会话以完善保护机制。因此，该特征被隐含公开。 |
| **技术特征J：** 其中每个HELLO消息在要基于IP转发协议路由所述HELLO消息的情况下包含值大于1的TTL <br> **《未公开》** | 与特征F的论述相同。经过全面检索对比文件全文，未发现任何关于修改或设置HELLO消息的IP生存时间（TTL）值的描述。 | 对比文件完全没有涉及HELLO消息TTL值的设置问题。该特征与特征F在技术内容上等同，均为根据IP转发方式设置TTL大于1。基于同样的理由，该特征在对比文件中既无直接记载，也无技术启示。因此，该特征未被公开。 |
| **技术特征K：** 其中每个HELLO在要经由所述旁路隧道转发所述HELLO消息的情况下包含为1的TTL值 <br> **《未公开》** | 与特征G的论述相同。经过全面检索对比文件全文，未发现任何关于修改或设置HELLO消息的IP生存时间（TTL）值的描述。 | 对比文件完全没有涉及HELLO消息TTL值的设置问题。该特征与特征G在技术内容上等同，均为根据隧道转发方式设置TTL为1。基于同样的理由，该特征在对比文件中既无直接记载，也无技术启示。因此，该特征未被公开。 |
| **技术特征L：** 响应于基于在所述HELLO会话期间交换的所述HELLO消息所述远程节点的重启，根据资源预留协议(RSVP)业务工程(TE)完美重启(RSVP-TE GR)机制执行重启过程，以便预留并恢复所述受保护LSP的LSP状态信息 <br> **《直接公开》** | 对比文件§4.3.4节（从第[0149]段开始）详细描述了RSVP-TE GR方法。第[0158]段描述了重启节点在重启后，通过发送携带RESTART_CAP对象（内含Recovery Time）的Hello消息来开始GR过程。第[0164]-[0166]段描述了邻居节点在接收到重启节点的Hello消息后，通过Path消息中的RECOVER_LABEL对象将标签绑定发回给重启节点，以帮助重启节点恢复状态。引用内容：“If ... the restarting node's control component restarted within the time and was able to preserve its MPLS forwarding state... For each LSP that traverses the peer node for which the restarting peer node is the next hop, the node places the outgoing label ... in the RECOVER_LABEL object of the path message that the peer node sends to the restarting peer node.” 第[0159]段描述了重启节点接收Path消息并匹配、刷新其陈旧转发状态的过程。 | 目标专利的特征L描述了一个完整的RSVP-TE GR流程：基于Hello消息得知远程节点重启，然后执行GR过程以恢复LSP状态。对比文件的RSVP部分详细且明确地公开了这一流程：邻居节点通过Hello消息中的RESTART_CAP对象得知重启节点的状态和能力后，通过向重启节点发送包含RECOVER_LABEL对象的Path消息来协助其恢复LSP状态；重启节点则利用收到的信息匹配并刷新其本地保留的陈旧转发状态，从而完成LSP状态信息的恢复。这一系列操作完全符合“根据RSVP-TE GR机制执行重启过程，以便预留并恢复所述受保护LSP的LSP状态信息”的描述。因此，该技术特征被直接公开。 |
| **技术特征M：** 其中所述HELLO消息的所述TTL值被设置成至少等于或大于所述网络单元与所述远程节点之间的中间节点数量 <br> **《未公开》** | 与特征F的论述相同。经过全面检索对比文件全文，未发现任何关于修改或设置HELLO消息的IP生存时间（TTL）值的描述，更未发现将TTL值与中间节点数量进行关联的任何教导或暗示。 | 对比文件完全没有涉及HELLO消息TTL值的设置问题。将TTL值设置为至少等于或大于中间节点数量，是目标专利为确保HELLO消息不被中间节点丢弃而采取的具体计算方式。对比文件中没有任何关于此计算方式或设置原则的文字记载或技术启示。本领域技术人员无法从对比文件中得到该技术方案。因此，该特征未被公开。 |
| **技术特征N：** 使得任何所述中间节点都不丢弃所述HELLO消息 <br> **《未公开》** | 与特征F的论述相同。经过全面检索对比文件全文，未发现任何关于如何防止中间节点丢弃HELLO消息的技术手段的描述。这是目标专利为解决非紧邻节点通信问题而提出的技术效果。 | 特征N是特征M中TTL值设置方式所达到的技术效果。由于对比文件既未公开特征M中具体的TTL值设置方式，也未公开需要进行多跳HELLO消息传输，因此其自然也不会公开“使得任何中间节点都不丢弃HELLO消息”这一技术效果及其实现手段。该特征在对比文件中无任何体现。因此，该特征未被公开。 |
| **技术特征O：** 其中所述网络单元是所述受保护LSP的本地修复点(PLR)节点 <br> **《直接公开》** | 对比文件第[0170]-[0176]段讨论了FRR与GR的结合，其中隐含了FRR的保护路径存在端点。虽然未直接使用PLR这一缩写，但第[0032]段引用的专利（US 09/354,640）是关于连接导向网络中的快速重路由方法和装置，其中必然涉及本地修复点。结合对比文件在FRR场景下讨论GR，本领域技术人员可以毫无疑义地确认，执行GR的节点之一就是FRR机制中的PLR节点。引用内容：“...in the event of a control component restart... The may be applied in accordance with the following conditions... If the interface to a neighbor goes down, the LSR should activate fast reroute.”。 | 在FRR设施保护场景中，激活快速重路由并执行业务切换的节点即为本地修复点（PLR）。对比文件在讨论FRR与GR结合时，明确提到了在接口down时激活FRR的节点，该节点即为PLR。因此，将执行GR的网络单元具体化为PLR节点，是从对比文件对FRR场景的描述中可以直接且毫无疑义地确定的技术内容。因此，该技术特征被直接公开。 |
| **技术特征P：** 所述远程节点是所述受保护LSP的合并点(MP)节点；并且中在所述PLR节点与所述MP节点之间的所述保护路径中存在至少一个中间节点 <br> **《直接公开》** | 对比文件第[0170]-[0176]段讨论了FRR与GR的结合。第[0175]段描述了接口down时激活FRR，这暗示了业务被切换到一条保护路径上。这条保护路径的终点，即业务被合并回原LSP或离开保护路径的节点，就是合并点（MP）。同样，虽然对比文件未明确写出“MP”缩写，但保护路径的端点（对端）即为MP节点。关于中间节点，图1和图2明确展示了标签交换路径（LSP）中存在多个中间LSR。在FRR场景下，保护路径（旁路隧道）穿越多个节点到达MP是常见情况。引用内容：“FIG. 1 illustrates a label-switched path 110 across a network... a label-switched path 110 is defined by the concatenation of one or more label-switched hops...”。 | 在FRR机制中，与PLR节点相对应的保护路径另一端的节点即为合并点（MP）。对比文件在FRR上下文中讨论GR，自然涉及了这对节点。同时，对比文件的图1和图2及其说明清晰地表明，LSP和穿越网络的路径通常由一跳或多跳（即至少一个中间节点）组成。将GR应用于FRR场景，意味着GR的通信需要发生在PLR和MP之间，而它们之间很可能存在中间节点。这是一个隐含在FRR基本概念和对比文件网络拓扑图中的事实，本领域技术人员能毫无疑义地确定。因此，该技术特征被直接公开。 |
| **技术特征Q：** 其中当所述FRR方案在所述保护路径上生效时，建立所述HELLO消息会话并执行所述重启过程 <br> **《隐含公开》** | 对比文件第[0170]-[0176]段专门一节讨论“Fast Reroute and Graceful Restart”。第[0171]-[0173]段描述了当接口up但控制平面通信中断时，应激活GR。第[0175]段描述了当接口down时，应激活FRR。这些条件说明了FRR和GR是互补的，并在不同故障场景下被触发。引用内容：“The RSVP-TE graceful restart of the present invention can be used to complement fast reroute techniques that are designed to protect traffic during failures.”。 | 对比文件明确指出RSVP-TE GR可用于补充FRR技术。虽然其给出的激活规则是“接口down激活FRR，控制平面中断激活GR”，但在复杂的网络故障（如节点故障）中，FRR的业务切换和GR的控制平面恢复很可能是接续发生的。例如，一个节点故障可能导致其相连的接口down，触发上游PLR节点激活FRR；同时，该节点本身或下游MP节点的控制平面也可能受影响而重启。在这种FRR已经生效（业务在保护路径上）的情况下，执行GR过程以恢复控制平面状态是完全符合对比文件“用GR补充FRR”的教导的。本领域技术人员可以合理地推断出，在FRR生效期间，为了实现对受保护LSP的更全面保护，需要在保护路径的端点上建立GR会话并执行重启过程。因此，该特征被隐含公开。 |
| **技术特征R：** 其中在无需将所述远程节点静态地配置为相邻节点的情况下所述网络单元建立所述HELLO会话 <br> **《隐含公开》** | 对比文件第[0023]段描述了LDP通过IGP自动发现邻居的机制。对于RSVP，其本身可通过路径消息（Path message）的传递来发现下游节点。在对比文件RSVP GR部分，第[0159]段描述了节点通过接收Path消息来触发状态恢复过程，这表明节点能够动态地通过信令协议感知到对等节点的存在，而无需静态配置。引用内容：“When a restarting node receives a Path message from an (upstream) peer...”。 | 对比文件教导的RSVP和LDP等协议本身具备动态邻居发现机制。在FRR与GR结合的场景中，MP节点能够通过接收受保护LSP的Path消息来发现PLR节点为其逻辑邻居。这种基于信令协议的动态发现过程，意味着建立Hello会话的双方可以自动获知对方的存在，而无需依赖于管理员手动静态配置相邻关系。因此，虽然对比文件未明确说“无需静态配置”，但从其依赖标准协议动态发现邻居的技术方案中，本领域技术人员可以合理地推断出建立会话的过程排除了对静态配置的强制依赖。因此，该特征被隐含公开。 |
<<<b>>>
<<<c>>>
<<<d>>>
<<<h>>>
<<<l>>>
<<<o>>>
<<<p>>>
<<<e>>>
<<<i>>>
<<<q>>>
<<<r>>>