CN113872799A - 管理节点的方法、节点和系统 - Google Patents

Abstract

本申请提供了一种管理节点的方法、节点和系统，应用于第一节点从网管设备脱管后，该方法包括：第一节点接收来自第二节点的第一请求信息，该第一节点根据该第一请求信息与该第二节点建立第一业务通道，该第一节点在该第一业务通道上接收业务配置信息，该业务配置信息是该网管设备发送给该第二节点的，该第一节点根据该业务配置信息进行业务配置。本申请提供的方法能够达到对脱管节点的故障定位和业务更新配置管理的目的。

Description

管理节点的方法、节点和系统

技术领域

本申请涉及通信技术领域，尤其涉及一种管理节点的方法、节点和系统。

背景技术

随着软件定义网络的网络规模的不断扩大，网络中存在越来越多的节点在网管系统的控制下运行，即网管设备对网络中的多个节点进行集中管理，使得网管在整个网络业务环境中的地位越来越高。

然而，如果某个节点一但脱离网管的管理，也就是在网管系统中，该节点不可见，简称脱管，会造成日常业务的开通停摆，影响网络运维工作的开展。

因此，如何对脱管节点进行管理，是亟待解决的问题。

发明内容

本申请提供一种管理节点的方法、节点和系统，能够达到对脱管节点的故障定位和业务更新配置管理的目的。

第一方面，提供了一种方法，该方法可以由第一节点执行，或者，也可以由配置于第一节点中的芯片或电路执行，本申请对此不作限定。该方法包括：第一节点接收来自第二节点的第一请求信息；该第一节点根据该第一请求信息与该第二节点建立第一业务通道；该第一节点在该第一业务通道上接收业务配置信息，该业务配置信息是该网管设备发送给该第二节点的；该第一节点根据该业务配置信息进行业务配置。

基于上述方案，当第一节点脱管后，通过建立第一节点与第二节点的代理关系，使用第二节点的管理通道与网管设备进行通讯，达到对第一节点故障定位和业务更新配置的目的。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点完成该业务配置后，该第一节点关闭该第一业务通道。

基于上述方案，通过第一节点在第一业务通道上接收网管设备发送的业务配置信息后，第一节点关闭第一业务通道，可以节约系统的传输资源。

结合第一方面，在第一方面的某些实现方式中，该业务配置信息包括业务更新配置信息时，该第一节点根据该业务配置信息进行业务配置，包括：该第一节点根据该业务更新配置信息更新该第一节点的业务。

结合第一方面，在第一方面的某些实现方式中，该业务配置信息包括故障修复配置信息时，该第一节点根据该业务配置信息进行业务配置，包括：该第一节点根据该故障修复配置信息修复该第一节点的故障。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点获取该第二节点的信息；该第一节点根据该第二节点的信息与该第二节点建立第二业务通道；该第一节点在该第二业务通道上向该第二节点发送故障原因信息，该故障原因信息用于该网管设备确定该故障修复配置信息。

基于上述方案，当第一节点脱管后，第一节点可以根据第二节点的信息，与第二节点建立第二业务通道，并通过该第二通道将故障原因信息发送给第二节点，通过第二节点发送给网管设备，是网管设备能够对第一节点的故障进行定位，并向第一节点发送故障修复配置信息，以使第一节点根据该故障修复配置信息修复该第一节点的故障。

结合第一方面，在第一方面的某些实现方式中，该第二节点的信息包括该第二节点的地址信息和端口信息。

第二方面，提供了一种节点，该节点包括：代理组件，接收来自第二节点的第一请求信息，并根据该第一请求信息与该第二节点建立第一业务通道，在该第一业务通道上接收业务配置信息，其中，该业务配置信息是该网管设备发送给该第二节点的；管理组件，用于根据该业务配置信息进行业务配置。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第二方面，在第二方面的某些实现方式中，该管理组件还用于：完成该业务配置后，关闭该第一业务通道。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第二方面，在第二方面的某些实现方式中，该管理组件具体用于：该业务配置信息包括业务更新配置信息时，该管理组件根据该业务更新配置信息更新该节点的业务。

结合第二方面，在第二方面的某些实现方式中，该管理组件具体用于：该业务配置信息包括故障修复配置信息时，该管理组件根据该故障修复配置信息修复该节点的故障。

结合第二方面，在第二方面的某些实现方式中，该代理组件还用于：获取该第二节点的信息，根据该第二节点的信息与该第二节点建立第二业务通道，以及在该第二业务通道上向该第二节点发送故障原因信息，该故障原因信息用于该网管设备确定该故障修复配置信息。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第二方面，在第二方面的某些实现方式中，该第二节点的信息包括该第二节点的地址信息和端口信息。

第三方面，提供了一种节点，该节点包括：收发模块，用于接收来自第二节点的第一请求信息，并在第一业务通道上接收业务配置信息，该业务配置信息是该网管设备发送给该第二节点的；处理模块，根据该第一请求信息与该第二节点建立该第一业务通道，并根据该业务配置信息进行业务配置。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第三方面，在第三方面的某些实现方式中，该处理模块还用于：完成该业务配置后，关闭该第一业务通道。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第三方面，在第三方面的某些实现方式中，该处理模块具体用于：该业务配置信息包括业务更新配置信息时，该处理模块根据该业务更新配置信息更新该第一节点的业务。

结合第三方面，在第三方面的某些实现方式中，该处理模块具体用于：该业务配置信息包括故障修复配置信息时，该处理模块根据该故障修复配置信息修复该第一节点的故障。

结合第三方面，在第三方面的某些实现方式中，该处理模块，还用于获取该第二节点的信息，并根据该第二节点的信息与该第二节点建立第二业务通道；该收发模块，还用于在该第二业务通道上向该第二节点发送故障原因信息，该故障原因信息用于该网管设备确定该故障修复配置信息。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第三方面，在第三方面的某些实现方式中，该第二节点的信息包括该第二节点的地址信息和端口信息。

第四方面，提供了一种管理节点的系统，该系统包括：第一节点，用于接收来自第二节点的第一请求信息，根据该第一请求信息与该第二节点建立第一业务通道，在第一业务通道上接收业务配置信息并根据该业务配置信息进行业务配置；第二节点，用于接收来自网管设备的配置信息，解析该配置信息得到该业务配置信息，病将该业务配置信息发送给该第一节点；该网管设备，用于向该第二节点发送配置信息。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第四方面，在第四方面的某些实现方式中，该第一节点完成该业务配置后，该第一节点关闭该第一业务通道。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第四方面，在第四方面的某些实现方式中，该业务配置信息包括业务更新配置信息时，该第一节点根据该业务配置信息进行业务配置，包括：该第一节点根据该业务更新配置信息更新该第一节点的业务。

结合第四方面，在第四方面的某些实现方式中，该业务配置信息包括故障修复配置信息时，该第一节点根据该业务配置信息进行业务配置，包括：该第一节点根据该故障修复配置信息修复该第一节点的故障。

结合第四方面，在第四方面的某些实现方式中，该第一节点，还用于获取该第二节点的信息，根据该第二节点的信息与该第二节点建立第二业务通道，并在该第二业务通道上向该第二节点发送故障原因信息；该第二节点，还用于接收该故障原因信息，并将该故障原因信息发送给该网管设备；该网管设备，还用于接收来自该第二节点的该故障原因信息并确定该故障修复配置信息。

基于上述方案的有益效果，可以参考第一方面的相应描述，为了简洁，本申请在此不再赘述。

结合第四方面，在第四方面的某些实现方式中，该第二节点的信息包括该第二节点的地址信息和端口信息。

第五方面，提供了一种节点，该节点用于执行上述第一方面提供的方法。具体地，该节点可以包括用于执行第一方面提供的方法的单元和/或模块，如处理模块和/或收发模块。

在一种实现方式中，该节点可以包括通信模块和处理模块，该通信模块可以是收发器，或，输入/输出接口；该处理模块可以是处理器。

在另一种实现方式中，该节点可以包括节点中的芯片、芯片系统或电路。该收发模块单元可以是该芯片、芯片系统或电路上的输入/输出接口、接口电路、输出电路、输入电路、管脚或相关电路等；该处理模块可以是处理器、处理电路或逻辑电路等。

基于上述方案的有益效果，可以参考第一方面相应描述，为了简洁，本申请在此不再赘述。

可选地，上述收发器可以为收发电路。可选地，上述输入/输出接口可以为输入/输出电路。

第六方面，提供一种节点，该节点包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第一方面提供的方法。

第七方面，本申请提供一种处理器，用于执行上述各方面提供的方法。在执行这些方法的过程中，上述方法中有关发送上述信息和获取/接收上述信息的过程，可以理解为由处理器输出上述信息的过程，以及处理器接收输入的上述信息的过程。在输出上述信息时，处理器将该上述信息输出给收发器，以便由收发器进行发射。该上述信息在由处理器输出之后，还可能需要进行其他的处理，然后才到达收发器。类似的，处理器接收输入的上述信息时，收发器获取/接收该上述信息，并将其输入处理器。更进一步的，在收发器收到该上述信息之后，该上述信息可能需要进行其他的处理，然后才输入处理器。

对于处理器所涉及的发射、发送和获取/接收等操作，如果没有特殊说明，或者，如果未与其在相关描述中的实际作用或者内在逻辑相抵触，则均可以更加一般性的理解为处理器输出和接收、输入等操作，而不是直接由射频电路和天线所进行的发射、发送和接收操作。

在实现过程中，上述处理器可以是专门用于执行这些方法的处理器，也可以是执行存储器中的计算机指令来执行这些方法的处理器，例如通用处理器。上述存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(Read Only Memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

第八方面，提供一种计算机可读存储介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述第一方面提供的方法。

第九方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面提供的方法。

第十方面，提供一种芯片，该芯片包括处理器与通信接口，该处理器通过该通信接口读取存储器上存储的指令，执行上述第一方面提供的方法。

可选地，作为一种实现方式，该芯片还可以包括存储器，该存储器中存储有指令，该处理器用于执行该存储器上存储的指令，当该指令被执行时，该处理器用于执行上述第一方面提供的方法。

附图说明

图1示出了本申请实施例提供的一种管理节点的方法100的流程示意图。

图2示出了本申请实施例提供的一种用于管理节点的系统以及节点结构示意图。

图3示出了本申请实施例提供的一种管理节点的方法300的流程示意图。

图4示出了本申请实施例提供的一种DHCP服务各阶段的流程示意图。

图5示出了本申请实施例提供的一种管理节点的方法的示意性框图。

图6示出了本申请实施例提供的一种管理节点的方法600的流程示意图。

图7示出了本申请实施例提供的一种管理节点的方法700的流程示意图。

图8示出了本申请实施例提供的一种节点的一例示意性框图。

图9示出了本申请实施例提供的一种节点的一例示意性框图。

图10示出了本申请实施例提供的一种节点的一例示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

为便于理解本申请实施例，首先对本申请中涉及的几个术语做简单说明。

节点(Node)是指网络中拥有唯一网络地址的设备，例如：工作站、服务器、终端设备、网络设备等，例如，可以是光线路终端(optical line terminal，OLT)作为网管设备管理的节点。

网管设备是网络管理设备的简称，通常是指一个服务器，该服务器对网络中的多个节点进行集中管理，所以也称为网管服务器。

管理通道是指传递管理信息的逻辑通道，由于网管通常要管理多个节点，并且许多节点不是直接与网管相连的，而是通过别的节点间接与网管相连，所以管理通道通常承载于某种协议上，如传输控制协议/互联网协议(transmission control protocol/internet protocol，TCP/IP)。

脱管是指某个节点不能被网管设备所管理的故障状态，可以表现为某个节点与网管设备之间的管理通道发生故障或者节点内部的管理模块本身发生故障。此时，网管设备无法与该节点通过管理通道建立通信，可以表现为网管设备对该节点发送消息，但这个节点没有任何响应。

本申请实施例提供的管理节点的方法，当某一节点脱管时，例如，可以是该节点无法通过其与网管设备之间的管理通道接收网管设备下发的管理信息等，此时，网管设备可以向第二节点发送业务配置信息，该第二节点通过解析该业务配置信息并确认该业务配置信息的内容是网管设备发送给脱管节点后，该第二节点请求与托管节点建立临时业务通道，并通过临时建立的业务通道向脱管节点发送网管设备的业务配置信息。

需要说明的是，网管设备可以采用多种方式判断某一节点是否脱管，例如：网管设备按照预置的时间周期向与其连接的通信网络中的每一节点发送链路状态的探测报文，如果在约定时间内某一节点没有反馈该探测报文，则认为该节点发生脱管。当然，本领域技术人员可以根据实际应用场景采用其他的脱管检测方式，对此，本申请实施例不做限定。

图1示出了本申请实施例提供的一种管理节点的方法100的流程示意图，如图1所示，该方法包括：

S101，第一节点接收来自第二节点的第一请求信息。

具体地，当第一节点脱管后，若网管设备需要向该脱管节点发送业务配置信息时，该网管设备利用第二节点向第一节点发送该业务配置信息。通常，第二节点会通过与网管设备连接的管理通道接收来自网管设备的管理信息，当第二节点通过管理模块解析管理信息，并确定收到的管理信息是网管设备发送给第一节点时，该第二节点向第一节点发送请求信息，请求与该第一节点建立业务通道。

需要说明的是，当前，由于网管设备管理下的节点之间虽然存在物理连接，例如，节点之间可以通过交换机进行物理连接，但节点之间并不存在能够转发数据等功能的业务通道。因此，当脱管节点想要收到网管设备发送的业务配置信息时，该第一节点需要先与第二节点建立业务通道。

应理解，该第二节点确定接收的来自网管设备的管理信息中包括第一节点的信息，例如，第一节点的IP地址以及第一节点的端口信息(例如：端口号)时，第二节点确认收到的管理信息中包括网管设备需要其发送给第一节点的业务配置信息。

即当第二节点通过解析来自网管设备的管理信息后确定该管理信息包括第一节点的业务配置信息时，第二节点利用该管理信息中的第一节点的信息向第一节点发起建立业务通道的请求信息。

需要说明的是，上述IP地址是节点的标识信息，用于标识不同的节点，端口信息是节点之间互相通信的端口，不同的业务场景对应不同的端口信息。此外，网管设备向第二节点发送的管理信息中还可以包括其他信息，本申请并不限定。

可选的，该业务配置信息可以包括业务更新配置信息和/或故障修复配置信息。

S102，第一节点根据第一请求信息与第二节点建立第一业务通道。

具体地，当第一节点收到第二节点发送的第一请求信息后，第一节点可以与第二节点建立第一业务通道，例如，可以采用谷歌远程过程调用(Google remote procedurecall，GRPC)协议的方式或其他协议的方式建立该第一业务通。

S103，第一节点在业务通道上接收业务配置信息。

具体地，当第一节点与第二节点之间的第一业务通道建立成功后，该第二节点通过该业务通道向第一节点发送来自网管设备的业务配置信息，第一节点通过该第一业务通道接收第二节点发送的业务配置信息。

在一种可实现的方式中，上述步骤101至步骤103可以通过节点内部创建的代理组件来实现，该代理组件可以包括客户端与服务端，其中客户端用于通过业务通道向其他节点的服务端发送信息，服务端用于接收来自其他节点的信息，例如请求信息等。该过程可以参考图2所示系统以及节点结构示意图，如图2所示，当第一节点脱管后，第二节点通过与网管设备的管理通道接收来自网管设备发送的管理信息，该第二节点通过本节点的第二管理组件解析管理信息后确定该管理信息中包括第一节点的信息，例如IP地址、端口信息等。随后，该第二节点的第二客户端向第一节点的第一服务端发送第一请求信息，该第一节点的第一服务端接收到第一请求信息后，通过预设的协议方式与第二节点建立业务通道。当业务通道建立成功后，该第二节点将需要发送给第一节点的业务配置信息发送给第一节点，第一节点收到后，通过第一节点的第一管理组件将收到的业务配置信息进行解析，第一节点根据解析后的业务配置信息的内容完成网管设备的业务配置和/或故障修复。

需要说明的是，上述“预设”可包括预先定义，例如，协议定义。其中，“预先定义”可以通过在设备中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。

S104，第一节点根据业务配置信息进行业务配置。

具体地，第一节点可以根据业务配置信息包括的内容进行相应的业务配置。

在一种具体的实现方式中，当该业务配置信息包括业务更新配置信息时，该第一节点可以根据该业务更新配置信息更新本节点的业务，例如，当第一节点的下游节点存在新的业务需求时，该第一节点可以根据收到的业务更新配置信息为其下游节点配置新的业务。或者，当该业务配置信息是故障修复配置信息时，该第一节点可以根据该故障修复信息修复本节点，并重新恢复与网管设备的连接。

该方法100具体地针对OLT设备来说，当前OLT设备内部包括一个管理组件，该管理组件是通过规定的标准协议向外通信，当管理组件与外界通信断开，例如管理通道断开，即OLT设备管理口与网络交换机之间的网络出现故障，或者OLT设备的本身的管理组件出现故障时，该OLT设备将无法受到网管设备的管理，即OLT设备发生脱管。因此，可以通过在该OLT设备内部创建的代理组件，实现两个设备之间的业务通道的创建。当其中一个OLT设备脱管时，可以通过另外一个设备来接收来自网管设备下发的业务配置信息等。

可选地，该第一业务通道可以是临时建立的通道，即当该第一节点根据业务配置信息完成节点处的业务更新和/或完成故障修复后，该第一节点可以关闭该第一业务通道，以节约传输网络的资源。

此外，需要强调的是，在本申请中，节点与网管设备通过管理通道下发和上报的管理信息进行通信。

当第一节点脱管后，网管设备可以通过向第二节点发送管理信息，该管理信息中携带网管设备需要发送给第一节点的业务配置信息以及第一节点的信息(例如，互联网协议(internet protocol，IP)地址以及第一节点的端口信息等)，此时，第二节点通过解析收到的管理信息确定该第一节点，并通过业务通道将管理信息中的业务配置信息发送给第一节点。

在本申请中，该业务配置信息可以包括业务更新配置信息和/故障修复配置信息。

基于上述方案，当第一节点脱管后，通过建立第一节点与第二节点的代理关系，使用第二节点的管理通道与网管设备进行通讯，达到对第一节点故障定位和业务更新配置的目的。图3示出了本申请提供的管理脱管节点的方法300的流程示意图。该方法用于第一节点脱管后，向网管设备上报故障原因，该方法300包括如下步骤：

S301，第一节点获取第二节点的信息。

当第一节点确认脱管后，第一节点选择一个邻居节点，即第二节点，并通过该第二节点向网管设备上报故障原因。

具体地，该第一节点确认脱管，可以是第一节点通过定时检测与网管设备之间的信道，例如，通过固定的时间间隔向网管设备发送请求信息，当未接收到网管设备的应答信息时，第一节点认为此时已经脱管。或者节点检测到自身管理组件出现故障，认为自身脱管。此时，第一节点获取第二节点的信息，该第二节点的信息可以是该第二节点的IP地址信息和/或端口信息，例如端口号等。

在一种可实现的方式中，第一节点通过邻居表获取第二节点的信息。

可选地，在第一节点获取第二节点的信息之前，该方法还包括第一节点获取邻居表。

接下来，对该第一节点获取邻居表的方式进行说明。

在本申请的实施例的方案中，第一节点获取邻居表，可以采用网管直接下发配置的方式。

由于网管设备可以用于管理各个节点，同时管理下游节点的分布以及网络结构。因此，当各个节点正常在线时，网管设备可以将连接在同一台交换机上的节点互相作为对方的邻居节点，并在这些节点与网管正常在线时，为这些节点配置邻居表。

在一种可实现的方式中，网管设备可以在各节点初次接入网络时，按照划分的规则统一为各节点下发各节点对应的邻居表，各个节点收到网管设备配置的邻居表后，将邻居表储存。或者，网管设备可以在节点正常在线时，按照一个较长的周期，定时为各节点下发此时网管设备重新生成的各个节点的邻居表。此外，还可以是，网管设备在确定第一节点脱管后，通过第二节点先向第一节点下发第一节点的邻居表，例如，在图1所示的方法100中，步骤103中的业务配置信息还可以包括网管设备为第一节点配置的邻居表。

需要说明的是，网管设备也可以按照区域划分或者其他方式，将某一些节点互为邻居节点。

应理解，网管设备管理下的节点的邻居表可以是相同的，即节点之间配置同一张包含所有节点IP和所有节点对应的端口号的邻居表。或者，这些节点之间配置的邻居表可以不同，此时，该邻居表可以仅包括某个节点的邻居节点的信息，例如IP地址和端口信息，而不包括该节点本身的IP地址和端口信息。

或者，在本申请的实施例的方案中，第一节点获取邻居表，可以采用动态主机配置协议(dynamic host configuration protocol，DHCP)服务的方式获取邻居表。该过程可以如图4所示的DHCP服务各阶段的流程示意图400，具体的，可以包括以下步骤：

S401，发现阶段。

发现阶段，即DHCP客户端寻找DHCP服务器(server)的阶段。具体地，第一节点作为DHCP客户端以广播方式在局域网内发起一个DHCP发现(discover)包/DHCP discover报文，目的是通过该DHCP discover包/DHCP discover报文发现能够提供IP的DHCP服务器。

S402，提供阶段。

提供阶段，即DHCP服务器提供IP地址的阶段。具体地，局域网内的DHCP服务器接收到第一节点发送的DHCP discover包/DHCP discover报文后，根据IP地址分配的优先次序从可用的地址池中选出一个IP地址，并向这个地址广播DHCP提供(offer)包/DHCP offer报文，该DHCP offer包/DHCP offer报文携带第一节点请求的IP地址。该DHCP offer包/DHCPoffer报文同时会发送给第一节点，目的在于告知第一节点，该选择出来的服务器能够向第一节点提供IP地址。

S403，选择阶段。

选择阶段，即DHCP客户端选择IP地址的阶段。如果有多台DHCP服务器向该第一节点发来DHCP offer包/DHCP offer报文，第一节点只接受第一个收到的DHCP offer包/DHCPoffer报文，然后以广播方式发送DHCP请求(request)包/DHCP request报文，把第一节点选择的服务器以及该服务器的地址通知给局域网内的所有的服务器。

S404，确认阶段。

确认阶段，即DHCP服务器确认IP地址的阶段。DHCP服务器收到第一节点发来的DHCP request包/DHCP request报文后，只有第一节点选择的服务器会进行如下操作：如果确认将IP地址分配给该第一节点，则返回DHCP确认字符(acknowledge character，ACK)包/DHCP acknowledge character报文，该DHCP ACK包/DHCP ACK报文中，除了包括第一节点的IP地之外，还可以携带邻居表的信息；否则返回DHCP否定应答(negativeacknowledgement，NACK)包/DHCP NACK报文，表明IP地址不能分配给该第一节点。

在一种可实现的方式中，可以通过该DHCP ACK包/DHCP ACK报文中的可选择(option)内容，携带该第一节点的邻居表。

其中，option内容如下：

option(xx)Neighbors table

Length:256

Neighbors IP:192.168.1.1:10001,192.168.1.2:10002,192.168.1.3:10003

应理解，该过程可以是第一节点确定脱管后，第一节点向DHCP服务其发起的获取邻居表的过程，也可以是第一节点未脱管时，向DHCP服务其发起的获取邻居表的过程，本申请对此不作限定。

需要说明的是，图4仅示出了第一节点，及脱管节点利用DHCP服务获取邻居表的交互流程，对于其他未脱管的节点而言，该过程同样适用，本申请不再赘述。

此外，在本申请的实施例的方案中，第一节点获取邻居表，还可以是获取预设在第一节点的邻居表。

应理解，该第一节点可以提前存储邻居表，该“预设”可包括预先定义，例如，协议定义。其中，“预先定义”可以通过在第一节点中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。

需要说明的是，该预设邻居表的方式对网管设备下的所有节点都可以适用，并不现定于脱管的节点。

S302，第一节点根据第二节点的信息建立第二业务通道。

具体地，当第一节点获取邻居表的信息后，第一节点可以任意选择邻居表中的任意一个节点作为第二节点，例如，通常选择邻居表中的第一个节点作为交互的第二节点来发起建链请求。即第一节点可以根据邻居表信息中的第二节点的地址，以及第二节点中可以用于和第一节点建立业务通道的端口信息，第一节点向该第二节点发送第二请求信息。

当第二节点收到该第一节点发送的第二请求信息后，第二节点可以根据该第二请求信息与第一节点建立第二业务通道，该第二业务通道用于向第二节点发送故障原因信息。

需要说明的是，该建立第二业务通道可以采用GRPC协议的方式或简单网络管理协议(simple network management protocol，SNMP)或其他协议的方式建立该第二业务通，本申请不做限定。

S303，第一节点在第二业务通道上向第二节点发送故障原因信息。

具体地，第一节点可将本节点的故障原因信息发送给第二节点，第二节点在收到第一节点发送的故障原因信息后，第二节点可以将该故障原因信息转换成管理消息，并通过第二节点与网管设备的管理通道上报给网管设备。

在一种可实现的方式中，上述步骤302至步骤303可以通过节点内部创建的代理组件来实现，该代理组件可以包括客户端与服务端，其中客户端用于通过业务通道向其他节点的服务端发送信息，服务端用于接收来自其他节点的信息，例如请求信息等。该过程可以参考图5系统以及节点结构示意图，如图5所示，当第一节点获取第二节点的信息后，第一节点的第一客户端向第二节点的服务端发送第二请求信息，该第二请求信息用于请求与第二节点建立第二业务通道。当第一节点通过预设的协议方式与第二业务通道建立完成后，第一节点的第一客户端向第二节点的第二服务端发送故障原因信息。第二节点的第二代理组件将收到的来自第一节点的故障原因信息转发给第二节点的第二管理组件，并由该第二管理组件生成管理信息，并发送给网管设备。

需要说明的是，上述“预设”可包括预先定义，例如，协议定义。其中，“预先定义”可以通过在设备中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。

可选地，该第一业务通道可以是临时建立的通道，即当该第一节点根据业务配置信息完成节点处的业务更新和/或完成故障修复后，该第一节点可以关闭该第一业务通道，以节约传输网络的资源。

基于上述方案，当第一节点脱管后，第一节点可以根据第二节点的信息，与第二节点建立第二业务通道，并通过该第二通道将故障原因信息发送给第二节点，通过第二节点发送给网管设备，是网管设备能够对第一节点的故障进行定位，并向第一节点发送故障修复配置信息，以使第一节点根据所述故障修复配置信息修复所述第一节点的故障。

在一种具体的实现方式中，图6示出了在各节点采用DHCP服务器获取邻居表的场景下，网管设备对第一节点进行管理的方法600的示意性流程图。该方法600可以包括如下的步骤：

S601，第一节点获取邻居表。

具体地，第一节点从DHCP服务器获取邻居表，该过程可以参考图4的描述，为了简便，在此不赘述。

S602，第一节点与第二节点建立第二业务通道。

具体地，第一节点根据获取的邻居表，从中选择出第二节点，并与第二节点建立第二业务通道。该建立第二业务通道的过程可以参照图3的步骤302的描述，以及图4中对应的相关描述，为了简便，此处不再赘述。

S603，第一节点向第二节点发送故障原因信息。

具体地，第一节点在于第二节点建立的第二业务通道上，将故障原因信息发送给第二节点。

S604，第二节点将故障原因信息转换为管理信息。

具体地，第二节点接收到第一节点发送的故障原因信息后，可以在第二节点的管理组件中将该故障原因信息转换管理信息。

S605，第二节点向网管设备发送管理信息。

具体地，该第二节点将步骤604生成的管理信息通过与网管设备的管理通道，发送给网管设备。该网管设备收到该管理信息后，可以通过解析该管理信息，确定第一节点的脱管原因。

S606，第一节点关闭第二业务通道。

可选地，第一节点可以在将故障原因信息发送给第二节点一段时候后，关闭与第二节点建立的业务通道。

基于上述方案，当第一节点脱管后，第一节点可以根据第二节点的信息，与第二节点建立第二业务通道，并通过该第二通道将故障原因信息发送给第二节点，通过第二节点发送给网管设备，是网管设备能够对第一节点的故障进行定位，并向第一节点发送故障修复配置信息，以使第一节点根据所述故障修复配置信息修复所述第一节点的故障。

当网管设备确定第一节点脱管的故障原因后，网管设备可以向该第一节点发起故障修复的过程，因此，该方法600还可以包括如下步骤：

S607，网管设备向第二节点发送包括故障修复配置信息的管理信息。

具体地，网管设备可以根据第一节点脱管的原因，向第二节点发送包括故障修复配置信息的管理信息。即网管设备可以根据邻居表确定第二节点为第一节点的邻居节点，并向该第二节点发送包括该故障修复配置信息的管理信息。

需要说明的是，该管理信息中还包括第一节点的IP地址信息、能够与第二节点建立第一业务通道的第一节点的端口信息等。

S608，第二节点与第一节点建立第一业务通道。

具体的，第二节点接收到网管设备发送的管理信息后，通过自身管理模块解析确定该管理信息中包括网管设备发送给第一节点的故障修复配置信息，同时该第二节点通过确定该管理信息中的第一节点的信息。例如IP信息以及端口等信息后，第二节点发起与第一节点建立第一业务通道的过程。该过程可以参考图1所示的方法100中的步骤101以及步骤102，为了说明的简便性，此处不再赘述。

S609，第二节点向第一节点发送故障修复配置信息。

具体地，第二节点将故障修复配置信息通过建立的第一业务通道发送给第一节点。

S610，第一节点根据故障修复配置信息修复故障。

具体地，第一节点根据接收到的来自第二节点的故障修复配置信息修复第一节点的故障。

S611，第一节点关闭第二业务通道。

可选地，第一节点可以在完成故障修复后，关闭与第二节点建立的第一业务通道，从而节约了系统的传输资源。

基于上述方案，当第一节点脱管后，通过建立第一节点与第二节点的代理关系，使用第二节点的管理通道与网管设备进行通讯，达到对第一节点故障定位目的。

在一种具体的实现方式中，图7示出了在各节点采用DHCP服务器获取邻居表的场景下，网管设备对第一节点进行管理的方法700的示意性流程图。该方法700可以包括如下的步骤：

S701，第一节点获取邻居表。

具体地，第一节点从DHCP服务器获取邻居表，该过程可以参考图4的描述，为了简便，在此不赘述。

S702，第一节点与第二节点建立第二业务通道。

具体地，第一节点根据获取的邻居表，从中选择出第二节点，并与第二节点建立第二业务通道。该建立第二业务通道的过程可以参照图3的步骤302的描述，以及图4中的相关描述，为了简便，此处不再赘述。

S703，第一节点向第二节点发送故障原因信息。

具体地，第一节点在于第二节点建立的第二业务通道上，将故障原因信息发送给第二节点。

S704，第二节点将故障原因信息转换为管理信息。

具体地，第二节点接收到第一节点发送的故障原因信息后，可以在第二节点的管理组件中将该故障原因信息转换管理信息。

S705，第二节点向网管设备发送管理信息。

具体地，该第二节点将步骤704生成的管理信息通过与网管设备的管理通道，发送给网管设备。该网管设备收到该管理信息后，可以通过解析该管理信息，确定第一节点的脱管原因。

S706，第一节点关闭第二业务通道。

可选地，第一节点可以在将故障原因信息发送给第二节点一段时候后，关闭与第二节点建立的业务通道。

基于上述方案，当第一节点脱管后，第一节点可以根据第二节点的信息，与第二节点建立第二业务通道，并通过该第二通道将故障原因信息发送给第二节点，通过第二节点发送给网管设备，是网管设备能够对第一节点的故障进行定位，并向第一节点发送故障修复配置信息，以使第一节点根据所述故障修复配置信息修复所述第一节点的故障。

当网管设备确定第一节点脱管的故障原因后，若第一节点的下游节点存在新的业务需求时，网管设备可以向该第一节点发起更新业务的过程，因此，该方法700还可以包括如下步骤：

S707，网管设备向第二节点发送业务更新配置信息。

具体地，网管设备可以根通过第二节点向第一节点发送故业务更新配置信息。即网管设备可以根据邻居表确定第二节点为第一节点的邻居节点，并向该第二节点发送业务更新配置信息。

需要说明的是，该业务更新配置信息中可以携带第一节点的IP地址信息以及能够与第二节点建立第一业务通道的端口信息。

S708，第二节点与第一节点建立第一业务通道。

具体的，第二节点接收到网管设备发送给第一节点的业务更新配置信息后，该第二节点通过自身管理模块解析该业务更新配置信息，确定其中的第一节点的信息。例如IP信息以及端口等信息后，第二节点发起与第一节点建立第一业务通道的过程。该过程可以参考图1所示的方法100中的步骤101以及步骤102，为了说明的简便性，此处不再赘述。

S709，第二节点向第一节点发送业务更新配置信息。

具体地，第二节点将业务更新配置信息通过建立的第一业务通道发送给第一节点。

S710，第一节点根据业务更新配置信息业务更新。

具体地，第一节点根据接收到的来自第二节点的业务更新配置信息进行业务更新。

S711，第一节点关闭第二业务通道。

可选地，第一节点可以在完成业务更新后，关闭与第二节点建立的第一业务通道，从而节约了系统的传输资源。

基于上述方案，当第一节点脱管后，通过建立第一节点与第二节点的代理关系，使用第二节点的管理通道与网管设备进行通讯，达到对第一节点业务更新配置目的。

以上，结合图1至图7详细说明了本申请实施例提供的方法。以下，结合图8至图10详细说明本申请实施例提供的节点。

图8是本申请实施例提供的节点的示意性框图。如图所示，该节点10可以包括处理模块11和收发模块12。

在一种可能的设计中，该节点10可对应于上文方法实施例中的第一节点或第二节点。

具体地，该节点10可对应于根据本申请实施例的方法100、方法200、方法300、方法400、方法500、方法600以及方法700中的第一节点，该节点10可以包括用于执行图1中的方法100或图2中的方法200图3中的方法300或图4中的方法400或图5中的方法500或图6中的方法600或图7中的方法700中的第一节点执行的方法的模块。并且，该节点10中的各单元和上述其他操作和/或功能分别为了实现图1中的方法100或图2中的方法200图3中的方法300或图4中的方法400或图5中的方法500或图6中的方法600或图7中的方法700的相应流程。

其中，当该节点10用于执行图1中的方法100时，处理模块11可用于执行方法100中的步骤102和步骤103，收发模块12可用于执行方法100中的步骤101。

当该节点10用于执行图3中的方法300时，处理模块11可用于执行方法300中的步骤301和步骤302，收发模块12可用于执行方法300中的步骤303。

当该节点10用于执行图4中的方法400时，收发模块12可用于执行方法400中的步骤401至步骤404。

当该节点10用于执行图6中的方法600时，处理模块11可用于执行方法600中的步骤601、步骤606、步骤610和步骤611，收发模块12可用于执行方法600中的步骤602、步骤603、步骤608、步骤609。

当该节点10用于执行图7中的方法700时，处理模块11可用于执行方法700中的步骤701、步骤706、步骤710和步骤711，收发模块12可用于执行方法700中的步骤702、步骤703、步骤708、步骤709。

图9是本申请实施例提供的节点的示意性框图。如图所示，该通信装置20可以包括管理组件21和代理组件22。

在一种可能的设计中，该通信装置20可对应于上文方法实施例中的第一节点或第二节点。

具体地，该节点20该可对应于上文方法实施例中的第一节点或第二节点。

具体地，该节点20可对应于根据本申请实施例的方法100、方法200、方法300、方法400、方法500、方法600以及方法700中的第一节点，该节点20可以包括用于执行图1中的方法100或图2中的方法200图3中的方法300或图4中的方法400或图5中的方法500或图6中的方法600或图7中的方法700中的第一节点执行的方法的组件。并且，该节点20中的各单元和上述其他操作和/或功能分别为了实现图1中的方法100或图2中的方法200图3中的方法300或图4中的方法400或图5中的方法500或图6中的方法600或图7中的方法700的相应流程。

其中，当该节点20用于执行图1中的方法100时，管理组件21可用于执行方法100中的步骤104，代理组件22可用于执行方法100中的步骤101至步骤103。

当该节点20用于执行图3中的方法300时，代理组件22可用于执行方法300中的步骤301至步骤303。

当该节点20用于执行图4中的方法400时，代理组件22可用于执行方法400中的步骤401至步骤404。

当该节点20用于执行图6中的方法600时，管理组件21可用于执行方法600中的步骤610，代理组件22可用于执行方法600中的步骤601、步骤602、步骤603、步骤606、步骤608、步骤609和步骤611。

当该节点20用于执行图7中的方法700时，管理组件21可用于执行方法700中的步骤710，代理组件22可用于执行方法700中的步骤701、步骤702、步骤703、步骤706、步骤708、步骤709和步骤711。

根据前述方法，图10为本申请实施例提供的节点30的示意图。

该节点30可以包括处理器31(即，处理模块的一例)和存储器32。该存储器32用于存储指令，该处理器31用于执行该存储器32存储的指令，以使该节点30实现图1中的方法100或图2中的方法200图3中的方法300或图4中的方法400或图5中的方法500或图6中的方法600或图7中的方法700中第一节点执行的步骤。

进一步地，该节点30还可以包括输入口33(即，收发模块的一例)和输出口34(即，收发模块的另一例)。进一步地，该处理器31、存储器32、输入口33和输出口34可以通过内部连接通路互相通信，传递控制和/或数据信号。该存储器32用于存储计算机程序，该处理器31可以用于从该存储器32中调用并运行该计算机程序，以控制输入口33接收信号，控制输出口34发送信号，完成上述方法第一节点的步骤。该存储器32可以集成在处理器31中，也可以与处理器31分开设置。

可选地，该输入口33可以为接收器，该输出口34可以为发送器。其中，接收器和发送器可以为相同或者不同的物理实体。为相同的物理实体时，可以统称为收发器。

可选地，若该节点30为芯片或电路，该输入口33为输入接口，该输出口34为输出接口。

作为一种实现方式，输入口33和输出口34的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器31可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。

作为另一种实现方式，可以考虑使用通用计算机的方式来实现本申请实施例提供的通信设备。即将实现处理器31、输入口33和输出口34功能的程序代码存储在存储器32中，通用处理器通过执行存储器32中的代码来实现处理器31、输入口33和输出口34的功能。

其中，节点30中各单元或单元可以用于执行上述方法中第一节点所执行的各动作或处理过程，这里，为了避免赘述，省略其详细说明。

该装置30所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。

应理解，本申请实施例中，该处理器可以为中央处理单元(central processingunit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-only memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的随机存取存储器(Random accessmemory，RAM)可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Souble data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct rambus RAM，DR RAM)。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (20)

1.一种管理节点的方法，应用于第一节点从网管设备脱管后，其特征在于，包括：

第一节点接收来自第二节点的第一请求信息；

所述第一节点根据所述第一请求信息与所述第二节点建立第一业务通道；

所述第一节点在所述第一业务通道上接收业务配置信息，所述业务配置信息是所述网管设备发送给所述第二节点的；

所述第一节点根据所述业务配置信息进行业务配置。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一节点完成所述业务配置后，所述第一节点关闭所述第一业务通道。

3.根据权利要求1或2所述的方法，其特征在于，

所述业务配置信息包括业务更新配置信息时，所述第一节点根据所述业务配置信息进行业务配置，包括：

所述第一节点根据所述业务更新配置信息更新所述第一节点的业务。

4.根据权利要求1或2所述的方法，其特征在于，

所述业务配置信息包括故障修复配置信息时，所述第一节点根据所述业务配置信息进行业务配置，包括：

所述第一节点根据所述故障修复配置信息修复所述第一节点的故障。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

所述第一节点获取所述第二节点的信息；

所述第一节点根据所述第二节点的信息与所述第二节点建立第二业务通道；

所述第一节点在所述第二业务通道上向所述第二节点发送故障原因信息，所述故障原因信息用于所述网管设备确定所述故障修复配置信息。

6.根据权利要求5中所述的方法，其特征在于，

所述第二节点的信息包括所述第二节点的地址信息和端口信息。

7.一种节点，其特征在于，包括：

代理组件，接收来自第二节点的第一请求信息，并根据所述第一请求信息与所述第二节点建立第一业务通道，在所述第一业务通道上接收业务配置信息，其中，所述业务配置信息是所述网管设备发送给所述第二节点的；

管理组件，用于根据所述业务配置信息进行业务配置。

8.根据权利要求7所述的节点，其特征在于，所述管理组件还用于：

完成所述业务配置后，关闭所述第一业务通道。

9.根据权利要求7或8所述的节点，其特征在于，所述管理组件具体用于：

所述业务配置信息包括业务更新配置信息时，所述管理组件根据所述业务更新配置信息更新所述节点的业务。

10.根据权利要求7或8所述的节点，其特征在于，所述管理组件具体用于：

所述业务配置信息包括故障修复配置信息时，所述管理组件根据所述故障修复配置信息修复所述节点的故障。

11.根据权利要求10所述的节点，其特征在于，所述代理组件还用于：

获取所述第二节点的信息，根据所述第二节点的信息与所述第二节点建立第二业务通道，以及在所述第二业务通道上向所述第二节点发送故障原因信息，所述故障原因信息用于所述网管设备确定所述故障修复配置信息。

12.根据权利要求11中所述的节点，其特征在于，

所述第二节点的信息包括所述第二节点的地址信息和端口信息。

13.一种节点，其特征在于，包括：

收发模块，用于接收来自第二节点的第一请求信息，并在第一业务通道上接收业务配置信息，所述业务配置信息是所述网管设备发送给所述第二节点的；

处理模块，根据所述第一请求信息与所述第二节点建立所述第一业务通道，并根据所述业务配置信息进行业务配置。

14.根据权利要求13所述的节点，其特征在于，所述处理模块还用于：

完成所述业务配置后，关闭所述第一业务通道。

15.根据权利要求13或14所述的节点，其特征在于，所述处理模块具体用于：

所述业务配置信息包括业务更新配置信息时，所述处理模块根据所述业务更新配置信息更新所述第一节点的业务。

16.根据权利要求13或14所述的节点，其特征在于，所述处理模块具体用于：

所述业务配置信息包括故障修复配置信息时，所述处理模块根据所述故障修复配置信息修复所述第一节点的故障。

17.根据权利要求16所述的节点，其特征在于，

所述处理模块，还用于获取所述第二节点的信息，并根据所述第二节点的信息与所述第二节点建立第二业务通道；

所述收发模块，还用于在所述第二业务通道上向所述第二节点发送故障原因信息，所述故障原因信息用于所述网管设备确定所述故障修复配置信息。

18.根据权利要求17所述的节点，其特征在于，

所述第二节点的信息包括所述第二节点的地址信息和端口信息。

19.一种管理节点的系统，其特征在于，包括：

第一节点，用于接收来自第二节点的第一请求信息，根据所述第一请求信息与所述第二节点建立第一业务通道，在第一业务通道上接收业务配置信息并根据所述业务配置信息进行业务配置；

第二节点，用于接收来自网管设备的配置信息，解析所述配置信息得到所述业务配置信息，病将所述业务配置信息发送给所述第一节点；

所述网管设备，用于向所述第二节点发送配置信息。

20.根据权利要求19所述的系统，其特征在于，

所述业务配置信息包括业务更新配置信息时，所述第一节点根据所述业务配置信息进行业务配置，包括：

所述第一节点根据所述业务更新配置信息更新所述第一节点的业务。

Images