CN112399452A - 版本配置方法、装置、设备、系统及存储介质 - Google Patents

Abstract

本申请公开了一种版本配置方法、装置、设备、系统及存储介质，以解决现有对待配置网元设备的版本配置受待配置网元设备空间限制，导致待配置网元设备可配置的版本受限，以及版本配置需要人工干预，导致配置效率低且容易出现误差的问题。本申请中，通过利用编排器将用户需求按照预先定义的业务类型集转换为对应的业务类型识别码，进而根据标识编排器自身的编排器识别码，以及标识控制器的控制器识别码和确定的业务类型识别码，生成与控制器进行通信的第一通信协议，并基于生成的第一通信协议，向控制器下发配置命令，从而使得控制器在接收到编排器下发的配置命令后，能够控制待配置网元设备自主从配置信息管理中心获取相应的配置信息进行版本配置。

Description

版本配置方法、装置、设备、系统及存储介质

技术领域

本申请实施例涉及通信领域，特别涉及一种版本配置方法、装置、设备、系统及存储介质。

背景技术

随着5G的广泛应用，对承载网提出越来越高的要求。除了大带宽、大连接、低时延的要求，运营商提出了更加精细化、智能化和自动化的要求。为了满足这些要求，就需要承载网中的各种网元设备，如路由器、交换机、光传送网（optical transport network，OTN）中涉及的传输节点等，根据用户需求不断进行版本更新。

但是，目前对网元设备进行版本更新时进行的版本配置，由于不同版本的配置信息均是预先存储在网元设备本地的，这就会受本地存储空间的限制，导致无法存储更多版本的配置信息。同时，目前对网元设备进行版本更新时进行的版本配置，需要人工干预，才能从本地存储空间中选择合适的配置信息进行版本配置，严重影响了配置效率。

发明内容

本申请实施例的目的在于提供一种版本配置方法、装置、设备、系统及存储介质，以解决上述技术问题。

为解决上述技术问题，本申请的实施例提供了一种版本配置方法，应用于版本配置系统中的编排器，所述版本配置系统还包括控制器、配置信息管理中心和待配置网元设备，所述版本配置方法包括：

接收用户需求，根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码，所述业务类型集包括各用户需求和各业务类型识别码的对应关系；

获取编排器识别码和所述控制器的控制器识别码；

根据所述编排器识别码、所述控制器识别码和所述业务类型识别码，生成与所述控制器进行通信的第一通信协议；

基于所述第一通信协议，向所述控制器下发配置命令，供所述控制器控制所述待配置网元设备从所述配置信息管理中心中获取配置信息进行版本配置。

为实现上述目的，本申请实施例还提供了一种版本配置方法，应用于版本配置系统中的控制器，所述版本配置系统还包括编排器、配置信息管理中心和待配置网元设备，所述版本配置方法包括：

接收所述编排器通过第一通信协议下发的配置命令，所述第一通信协议携带有用户需求对应的业务类型识别码；

从所述第一通信协议中提取所述业务类型识别码，并根据所述业务类型识别码确定对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

获取控制器识别码和所述配置信息管理中心的配置信息管理中心识别码；

根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议；

基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令，供所述配置信息管理中心确定是否存储有与所述版本识别码匹配的配置信息。

为实现上述目的，本申请实施例还提供了一种版本配置方法，应用于版本配置系统中的配置信息管理中心，所述版本配置系统还包括编排器、控制器和待配置网元设备，所述版本配置方法包括：

接收所述控制器通过第二通信协议下发的配置信息搜索命令，所述第二通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

从所述第二通信协议中提取所述版本识别码，并根据所述版本识别码对本地存储的配置信息进行遍历；

若遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心存储有与所述版本识别码匹配的配置信息作为搜索结果；

若未遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心未存储与所述版本识别码匹配的配置信息作为所述搜索结果；

基于所述第二通信协议，向所述控制器反馈所述搜索结果，供所述控制器向所述编排器作出配置失败的响应，或控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置。

为实现上述目的，本申请实施例还提供了一种版本配置方法，应用于版本配置系统中的待配置网元设备，所述版本配置系统还包括编排器、控制器和配置信息管理中心，所述版本配置方法包括：

接收所述控制器通过第三通信协议下发的配置命令，所述第三通信协议携带有进行版本配置所需的配置信息的版本识别码；

从所述第三通信协议中提取所述版本识别码；

获取存储有与所述版本识别码匹配的配置信息的所述配置信息管理中心的配置信息管理中心识别码；

根据所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第四通信协议；

基于所述第四通信协议，向所述配置信息管理中心下发配置信息获取命令，供所述配置信息管理中心基于所述第四通信协议反馈与所述版本识别码匹配的配置信息；

接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息；

根据所述配置信息进行版本配置。

为实现上述目的，本申请实施例还提供了一种版本配置装置，包括：

确定模块，用于接收用户需求，根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码，所述业务类型集包括各用户需求和各业务类型识别码的对应关系；

获取模块，用于获取编排器识别码和所述控制器的控制器识别码；

生成模块，用于根据所述编排器识别码、所述控制器识别码和所述业务类型识别码，生成与所述控制器进行通信的第一通信协议；

发送模块，用于基于所述第一通信协议，向所述控制器下发配置命令，供所述控制器控制所述待配置网元设备从所述配置信息管理中心中获取配置信息进行版本配置。

为实现上述目的，本申请实施例还提供了一种版本配置装置，包括：

接收模块，用于接收所述编排器通过第一通信协议下发的配置命令，所述第一通信协议携带有用户需求对应的业务类型识别码；

确定模块，用于从所述第一通信协议中提取所述业务类型识别码，并根据所述业务类型识别码确定对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

获取模块，用于获取控制器识别码和所述配置信息管理中心的配置信息管理中心识别码；

生成模块，用于根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议；

发送模块，用于基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令，供所述配置信息管理中心确定是否存储有与所述版本识别码匹配的配置信息。

为实现上述目的，本申请实施例还提供了一种版本配置装置，包括：

接收模块，用于接收所述控制器通过第二通信协议下发的配置信息搜索命令，所述第二通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

搜索模块，用于从所述第二通信协议中提取所述版本识别码，并根据所述版本识别码对本地存储的配置信息进行遍历；若遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心存储有与所述版本识别码匹配的配置信息作为搜索结果；若未遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心未存储与所述版本识别码匹配的配置信息作为所述搜索结果；

发送模块，用于基于所述第二通信协议，向所述控制器反馈所述搜索结果，供所述控制器向所述编排器作出配置失败的响应，或控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置。

为实现上述目的，本申请实施例还提供了一种版本配置装置，包括：

接收模块，用于接收所述控制器通过第三通信协议下发的配置命令，所述第三通信协议携带有进行版本配置所需的配置信息的版本识别码；

提取模块，用于从所述第三通信协议中提取所述版本识别码；

获取模块，用于获取存储有与所述版本识别码匹配的配置信息的所述配置信息管理中心的配置信息管理中心识别码；

生成模块，用于根据所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第四通信协议；

发送模块，用于基于所述第四通信协议，向所述配置信息管理中心下发配置信息获取命令，供所述配置信息管理中心基于所述第四通信协议反馈与所述版本识别码匹配的配置信息；

接收模块，还用于接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息；

配置模块，用于根据所述配置信息进行版本配置。

为实现上述目的，本申请实施例还提供了一种版本配置设备，包括：

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的应用于编排器的版本配置方法，或者应用于控制器的版本配置方法，或者应用于配置管理中心的配置管理方法，或者应用于待配置网元设备的版本配置方法。

为实现上述目的，本申请实施例还提供了一种版本配置系统，包括：编排器、控制器、配置信息管理中心和待配置网元设备；

所述编排器，用于执行如上所述的应用于编排器的版本配置方法；

所述控制器，用于执行如上所述的应用于控制器的版本配置方法；

所述配置信息管理中心，用于执行如上所述的应用于配置信息管理中心的版本配置方法；

所述待配置网元设备，用于执行如上所述的应用于待配置网元设备的版本配置方法。

为实现上述目的，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。所述计算机程序被处理器执行时实现上述所述的应用于编排器的版本配置方法，或者应用于控制器的版本配置方法，或者应用于配置管理中心的配置管理方法，或者应用于待配置网元设备的版本配置方法。

本申请提出的版本配置方法、装置、设备、系统及存储介质，通过利用编排器将用户需求按照预先定义的业务类型集转换为对应的业务类型识别码，进而根据标识编排器自身的编排器识别码，以及标识控制器的控制器识别码和确定的业务类型识别码，生成与控制器进行通信的第一通信协议，并基于生成的第一通信协议，向控制器下发配置命令，从而使得控制器在接收到编排器下发的配置命令后，能够控制待配置网元设备自主从配置信息管理中心获取相应的配置信息进行版本配置。由于整个版本配置流程中，仅需编排器、控制器、配置信息管理中心和待配置网元设备进行交互，便可以准确的定位版本配置需要用到的配置信息，根本无需人工干预，从而既做到了提升配置效率，又可以避免因为人工介入造成的人为误差。

除此之外，由于本申请提供的版本配置方案中，对待配置网元设备进行版本配置时所需的配置信息是单独存放在配置信息管理中心的，即不同版本对应的配置信息无需预先存储在每一待配置网元设备中，相同的版本的配置信息只需在配置信息管理中心存储一份即可，从而既可以减少预先在每一待配置网元设备部署不同版本的配置信息的人力，又可以方便后期运维人员对个版本的配置信息的更新维护。同时，通过将配置信息单独存放在配置信息管理中心，也使得对待配置网元设备的版本配置摆脱了待配置网元设备本地存储空间的限制，从而可以对待配置网元设备实现更多版本的配置，进而更好的满足各种用户需求。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。

图1是本申请第一实施例提供的版本配置系统的结构示意图；

图2是本申请第二实施例提供的应用于编排器的版本配置方法的流程图；

图3是本申请第三实施例提供的应用于控制器的版本配置方法的流程图；

图4是本申请第四实施例提供的应用于配置信息管理中心的版本配置方法的流程图；

图5是本申请第五实施例提供的应用于待配置网元设备的版本配置方法的流程图；

图6是本申请第六实施例提供的部署于编排器中的版本配置装置的结构示意图；

图7是本申请第七实施例提供的部署于控制器中的版本配置装置的结构示意图；

图8是本申请第八实施例提供的部署于配置信息管理中心的版本配置装置的结构示意图；

图9是本申请第九实施例提供的部署于待配置网元设备的版本配置装置的结构示意图；

图10是本申请第十实施例提供的版本配置设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本申请的第一实施例涉及一种版本配置系统，包括：编排器、控制器、配置信息管理中心和待配置网元设备。

其中，编排器主要用于将用户需求转换为控制器可以识别的业务需求，在本实施例中具体为标识业务类型唯一性的业务类型识别码，并基于标识编排器唯一性的编排器识别码、标识控制器唯一性的控制器识别码，以及转换得到的业务类型识别码生成与控制器进行通信的第一通信协议，然后基于生成的第一通信协议向控制器下发配置命令。

控制器主要用于基于与编排器之间的第一通信协议中携带的业务类型标识码、自身的控制器标识码，以及获取到的配置信息管理中心的识别码生成与配置信息管理中心进行通信的第二通信协议，进而基于第二通信协议与配置信息管理中心进行通信。

进一步地，控制器还会基于配置信息管理中心通过第二通信协议反馈的搜索结果，确定是基于第一通信协议告知编排器本次配置失败，还是基于控制器识别码、待配置网元设备的网元识别码和基于业务类型识别码确定的版本识别码生成与待配置网元设备进行通信的第三通信协议，并基于第三通信协议与待配置网元设备进行通信。

配置信息管理中心主要用于基于与控制器之间的第二通信协议中携带的版本识别码，对本地存储的配置信息进行遍历，进而确定本地是否存储了与版本识别码匹配的配置信息，并通过第二通信协议将遍历结果告知控制器。

进一步地，配置信息管理中心还会在接收到待配置网元设备基于第四通信协议下发的配置信息获取命令时，基于第四通信协议中携带的版本识别码定位对应的配置信息，并通过第四通信协议将获取的配置信息反馈给待配置网元设备。

待配置网元设备主要用于基于与控制器之间的第三通信协议中携带的版本识别码和存储有所述版本识别码对应的配置信息的配置信息管理中心的配置信息管理中心识别码，生成与配置信息管理中心进行通信的第四通信协议，即基于第四通信协议从配置信息管理中心获取所述版本识别码对应的配置信息。

此外，值得一提的是，在实际应用中，待配置网元设备可以包括多个。

相应地，为了便于对处于不同区域、不同集群的待配置网元设备进行版本配置，存储待配置网元设备进行版本配置所需的配置信息的配置信息管理中心也可以有多个。同理，直接与待配置网元设备进行通信的控制器也可以有多个。

可理解的，在实际应用中，配置信息管理中心、控制器的个数可以根据待配置网元设备所处的区域或者集群来确定。

比如，当前有A、B和C三个待配置网元设备集群，则版本配置系统中可以设置三个控制器和三个配置信息管理中心，即每一个待配置网元设备集群对应一个控制器和一个配置信息管理中心。

还比如，当有A、B和C三个待配置网元设备集群，其中集群A中有50个待配置网元设备，集群B中有100个待配置网元设备，集群C中有10个待配置网元设备，则版本配置系统中可以在三个控制器和三个配置信息管理中心，即每一个待配置网元设备集群对应一个控制器和一个配置信息管理中心，也可以设置两个控制器和两个配置信息管理中心，并设置其中一个控制器和一个配置信息管理中对应集群A和集群C，另一个控制器和配置信息管理中心单独对应集群B。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，本领域技术人员可以根据需要设置控制器和配置信息管理中心的数量。

此外，值得一提的是，为了使本实施例提供的版本配置系统具备容灾性，对应每一待配置网元设备集群或每一区域中的待配置网元设备的编排器、控制器和配置信息管理中心，至少各为两个，即版本配置系统中会存在一个主编排器、一个从编排器，一个主控制器，一个从控制器，一个主配置信息管理中心和一个从配置信息管理中心。同时，基于预设逻辑，在正常情况下仅启动主编排器、主控制器和主配置信息管理中心，在其中任意一个出现异常时，才将出现异常的设备负责的功能切换到对应的从设备，从而保证版本配置系统的正常运行。

此外，可理解的，在实际应用中，配置信息管理中心实质就是存储各种待配置网元设备的配置信息，如系统版本配置信息、功能版本配置信息、补丁版本配置信息的数据库。

待配置网元设备，可以是路由器、交换机、光传送网（optical transportnetwork，OTN）中涉及的传输节点。

为了便于理解和说明，本实施例以一个编排器、一个控制器、一个配置信息管理中心和一个待配置网元设备，具体为路由器为例，结合图1，对其所构成的版本配置系统进行版本配置的流程进行具体说明。

对于编排器：

当用户提交了一个用户需求给编排器，即编排器接收到用户需求时，将用户的原始请求转换成业务请求下发给对应的控制器。

可理解的，上述所说的原始请求，即为接收到的用户需求。

相应地，将原始请求转换成业务请求下发给对应的控制器，具体为：

（1）根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码。

具体的说，在本实施例中，所述业务类型集包括各种用户需求和各种业务类型识别码的对应关系。

可理解的，在实际应用中，预先定义的业务类型集中，除了包括用户需求和业务类型识别码，还可以包括业务类型识别码对应的业务类型，即在实际应用中，编排器通过根据预先的定义的业务类型集对接收到的用户需求进行分析，便可以确定当前用户需求对应的业务类型，进而找到标识当前业务类型的业务类型识别码。

关于上述所说的业务类型集，具体形式可以如表1所示：

表1 业务类型集

用户需求	业务类型	业务类型识别码
			用户需求1	业务类型1	123
用户需求2	业务类型2	234
			...	...	...

此外，值得一提的是，在实际应用中，一个用户需求除了会对应一个业务类型，进而对应一个业务类型识别码，即表1给出的情况，还可能存在一个用户需求对应多个业务类型，进而对应多个业务类型识别码，以及一个用户需求对应一个业务类型识别码，但是对应多个业务类型的情况。

比如说，当前路由器上运行的是4G业务对应的版本，当用户需要申请5G业务时，那么这种情况下就会触发版本搜索，当能搜索到版本时就会进行版本更新。这种情况下，用户需求就是5G业务申请，5G业务对应的业务类型识别码可以事先设定好，而这个标识5G业务的业务类型识别码下可能有多个业务类型，可以理解成业务功能，如分段路由（segmentrouting，SR）、网络遥感技术（Telemetry）、Bier组播、FlexE等。

还比如，当前路由器上运行的就是5G业务对应的版本，但是用户需求是一个5G新功能，当前路由器还不支持，假设信息配置管理中心有个补丁版本支持该功能，那么就可以通过上述方法加载该补丁版本，此时通过该用户需求就可以查到该5G功能的新业务类型的业务类型识别码。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

（2）获取编排器识别码和所述控制器的控制器识别码。

具体的说，本实施例中所说的编排器识别码即为能够标识编排器唯一性的标识信息。

相应地，所述控制器识别码即为能够标识控制器唯一性的标识信息。

可理解的，在实际应用中，上述所说的用于标识编排器唯一性的编排器识别码，以及标识控制器唯一性的控制器识别码，可以是技术人员根据预设规则，预先分配的，也可以是编排器和控制器在制备完成出厂时，厂家分配的标识信息，还可以是根据预先编译好的脚本，对每个接入网络的编排器和控制器分配的标识其唯一性的标识信息。

（3）根据所述编排器识别码、所述控制器识别码和所述业务类型识别码，生成与所述控制器进行通信的第一通信协议。

需要说明的，本实施例中版本配置系统中各功能实体之间建立的通信连接，依旧是基于传输控制协议（TCP，Transmission Control Protocol）/网际互连协议（IP，Internet Protocol）等现有协议的实现的，而本实施例中所说的各功能实体之间进行通信时所需的通信协议，实质是表示该通信协议中具体携带了哪些信息。

故而，上述所说的第一通信协议，实质是要表达基于上述三种识别码生成的通信协议，向控制器下发配置命令，是为了将上述三种识别码传输给接收该配置命令的控制器，即将上述三种识别码作为第一通信协议的头部文件，将配置命令作为传输的具体动作指令。

关于编排器识别码、控制器识别码和业务类型识别码这三者之间的关系，可以采用如下格式标识：<编排器ID，控制器ID，业务类型ID>。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

（4）基于所述第一通信协议，向所述控制器下发配置命令，供所述控制器控制所述待配置网元设备从所述配置信息管理中心中获取配置信息进行版本配置。

此外，值得一提的是，在实际应用中，为了避免对不合法以及无效用户需求的响应，编排器中负责与用户进行交互的模块，可以称之为需求输入模块，在监测到用户需求到达时，可以先对用户需求的合法性进行约束检查。

相应地，若通过检查，确定当前用户需求合法，才真正接收，以供后续处理使用进，即只有合法的用户需求才会被编排器接收；否则，直接拒绝当前用户需求。

关于上述所说的合法性检查，具体是指携带所述用户需求的原始请求的请求格式、采用的协议等是否符合编排器预预设要求。即，如果满足，则认为当前用户需求是合法的，否则为不合法的。

进一步地，由于编排器在将用户需求转换为控制器能够识别的业务需求，即确定用户需求对应的业务类型识别码时，是基于预先定义的业务类型集，因而为了避免对业务类型集中没有定义的用户需求进行分析处理，进而增加编排器资源的占用。在确定接收到的用户需求合法之后，根据预先定义的业务类型集，确定用户需求对应的业务类型识别码之前，还可以进一步判断用户需求是否为有效需求。

具体的，在实际应用中，对用户需求有效性的判断，可以根据预设的逻辑分析规则，判断用户需求是否为有效需求。

相应地，若通过判断，确定所述用户需求为有效需求，才执行上述根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码的操作。

关于上述所说的逻辑分析规则，可以是将事先定义好的业务类型定义为有效业务类型，或者无效业务类型；或者，只在逻辑分析规则中，定义有效业务类型，这样在基于逻辑分析规则进行判断时，只要当前用户需求对应的业务类型不在逻辑分析规则中，则认为当前用户需求为无效需求，反之则为有效需求。

此外，在实际应用中，可以将上述进行有效性检测的操作看作是由编排器内部的另一功能模块实现的，比如将进行有效性检测的模块称为需求分析模块。

进一步地，还可以将最终根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码的功能看作是由编排器内部的另一功能模块实现，比如业务类型模块。

基于上述描述可知，用户需求在到达编排器时，先由内部的需求输入模块进行合法性检查，在合法时再由内部的需求分析模块进行有效性分析，在有效时再由内部的业务类型模型根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码。

应当理解的是，上述功能模块的划分仅仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

对于控制器：

控制器根据编排器下发的业务请求，向配置信息管理中心下发配置信息适配请求，进而在配置信息管理中心中存在匹配的配置信息时，向待配置路由器下发配置命令，在配置信息管理中心不存在匹配的配置信息时，通知编排器本次版本配置请求失败。

可理解的，上述所说的业务请求，实质就是编排器通过第一通信协议携带的用户需求对应的业务类型识别码。

相应地，控制器中执行的版本配置流程，具体为：

（1）接收所述编排器通过第一通信协议下发的配置命令。

通过上述对编排器的描述可知，所述第一通信协议携带有用户需求对应的业务类型识别码，即业务类型ID。

（2）从所述第一通信协议中提取所述业务类型识别码，并根据所述业务类型识别码确定对所述待配置网元设备进行版本配置所需的配置信息的版本识别码。

具体的说，由于用户需求和业务类型识别码之间的关系是预先确定，同理与用户需求、业务类型识别码对应的版本的配置信息也是预先确定的，故而为了能够根据业务类型识别码快速定位对应的版本的配置信息，本实施例同样为配置信息分配了对应的版本识别码。

进而，在从第一通信协议中提取出业务类型识别码后，根据预设定义业务类型识别码与版本识别码之间的对应关系，便可以快速确定对待配置网元设备，如待配置路由进行版本配置所需的配置信息的版本识别码。

（3）获取控制器识别码和所述配置信息管理中心的配置信息管理中心识别码。

具体的说，本实施例中所说的控制器识别码即为能够标识控制器唯一性的标识信息。

相应地，所述配置信息管理中心识别码即为能够标识配置信息管理中心唯一性的标识信息。

可理解的，在实际应用中，上述所说的用于标识控制器唯一性的控制器识别码，以及标识配置信息管理中心唯一性的配置信息管理中心识别码，可以是技术人员根据预设规则，预先分配的，也可以是控制器在制备完成出厂时，厂家分配的标识信息，配置信息管理中心构建时，根据预设规则配置的，还可以是根据预先编译好的脚本，对每个接入网络的控制器和配置信息管理中心分配的标识其唯一性的标识信息。

（4）根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议。

由于本实施例中版本配置系统中各功能实体之间建立的通信连接，依旧是基于传输控制协议（Transmission Control Protocol，TCP）/网际互连协议（Internet Protocol，IP）等现有协议的实现的，而本实施例中所说的各功能实体之间进行通信时所需的通信协议，实质是表示该通信协议中具体携带了哪些信息。

故而，上述所说的第二通信协议，实质是要表达基于上述三种识别码生成的通信协议，向配置信息管理中心下发配置信息搜索命令，是为了将上述三种识别码传输给接收该配置信息搜索命令的配置信息管理中心，即将上述三种识别码作为第二通信协议的头部文件，将配置信息搜索命令作为传输的具体动作指令。

关于控制器识别码、配置信息管理中心识别码和版本识别码这三者之间的关系，可以采用如下格式标识：<控制器ID，配置信息管理中心ID，版本ID>。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

（5）基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令，供所述配置信息管理中心确定是否存储有与所述版本识别码匹配的配置信息。

（6）接收所述配置管理中心通过所述第二通信协议反馈的搜索结果。

相应地，若所述搜索结果为所述配置信息管理中心未存储与所述版本识别码匹配的配置信息，则基于所述第一通信协议，向所述编排器作出配置失败的响应；若所述搜索结果为所述配置信息管理中心存储有与所述版本识别码匹配的配置信息，则获取所述待配置网元设备的网元识别码。

可理解的，本实施例中所说的待配置网元设备的网元识别码即为能够标识网元设备唯一性的标识信息。

同样，在实际应用中，上述所说的用于标识待配置网元设备唯一性的网元识别码，可以是技术人员根据预设规则，预先分配的，也可以是待配置网元设备在制备完成出厂时，厂家分配的标识信息，还可以是根据预先编译好的脚本，对每个接入网络的待配置网元设备分配的标识其唯一性的标识信息。

（7）根据所述控制器识别码、所述网元识别码和所述版本识别码，生成与所述待配置网元设备进行通信的第三通信协议。

由于本实施例中版本配置系统中各功能实体之间建立的通信连接，依旧是基于传输控制协议（Transmission Control Protocol，TCP）/网际互连协议（Internet Protocol，IP）等现有协议的实现的，而本实施例中所说的各功能实体之间进行通信时所需的通信协议，实质是表示该通信协议中具体携带了哪些信息。

故而，上述所说的第三通信协议，实质是要表达基于上述三种识别码生成的通信协议，向待配置网元设备，即图1中的待配置路由器下配置命令，是为了将上述三种识别码传输给接收该配置命令的待配置路由器，即将上述三种识别码作为第三通信协议的头部文件，将配置命令作为传输的具体动作指令。

关于控制器识别码、网元识别码和版本识别码这三者之间的关系，可以采用如下格式标识：<控制器ID，网元ID，版本ID>。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

（8）基于所述第三通信协议，向所述待配置网元设备下发配置命令，供所述待配置网元设备从所述配置信息管理中心获取所述版本识别码对应的配置信息进行版本配置。

此外，值得一提的是，在实际应用中，为了避免对不合法以及无效业务需求（业务类型识别码对应的业务类型）的响应，控制器中负责与编排器进行交互的模块，可以称之为业务类型输入模块，在监测到编排器通过第一通信协议下发的配置命令到达时，可以先对第一通信协议中携带的业务类型识别码对应的业务类型的合法性进行约束检查。

相应地，若通过检查，确定业务类型合法，才真正接收，以供后续处理使用进，即只有合法的业务类型才会被控制器接收；否则，直接拒绝。

进一步地，为了保证来业务类型即合法，又有效。在确定业务类型合法后，根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议之前，还可以进一步判断业务类型是否有效。

具体的，在实际应用中，对业务类型有效性的判断，同样可以根据预设的逻辑分析规则进行判断。

相应地，若通过判断确定业务类型有效，才执行上述根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议的操作。

关于控制器执行的合法性和有效性的判断，与编排器执行的合法性和有效性的判断类似，此处不再赘述。

此外，关于控制器进行合法性和有效性判断所依据的规则，本领域技术人可以根据需要进行设置，本实施例对此不作限制。

对于配置信息管理中心，其主要用于保存待配置网元设备，如图1中的待配置路由器的所有可以配置的版本，及这些版本对应的配置信息。

同时，配置信息管理中心支持对每一版本的配置信息的增、删、改查功能，并支持控制器的配置信息搜索需求和待配置网元设备对配置信息的下载需求。

此外，为了便于配置信息管理中心中搜索到控制器所要求搜索的版本识别码对应的配置信息，以及方便待配置网元设备从配置信息管理中心中获取到版本识别码对应的配置信息，配置信息管理中心中存储的版本，及这些版本对应的配置信息是按照与控制器和待配置网元设备约定的方式进行存储的。

为了便于理解配置信息管理中心，在版本配置过程中执行的操作，以下具体说明：

（1）接收所述控制器通过第二通信协议下发的配置信息搜索命令，所述第二通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码。

（2）从所述第二通信协议中提取所述版本识别码，根据所述版本识别码对本地存储的配置信息进行遍历，并根据遍历结果生成搜索结果。

比如说，若遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心存储有与所述版本识别码匹配的配置信息作为搜索结果。

相应地，若未遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心未存储与所述版本识别码匹配的配置信息作为所述搜索结果。

（3）基于所述第二通信协议，向所述控制器反馈所述搜索结果，供所述控制器向所述编排器作出配置失败的响应，或控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置。

具体的说，若反馈的搜索结果为所述配置信息管理中心存储有与所述版本识别码匹配的配置信息，则控制器会控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置；反之，控制器会向所述编排器作出配置失败的响应。

（4）接收所述待配置网元设备通过第四通信协议下发的配置信息获取命令，所述第四通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码。

需要说明的是，本实施例中所说的第四通信协议，具体是由待配置网元设备，根据存储有需要获取的配置信息的配置信息管理中心的配置信息管理中心识别码和需要获取的配置信息对应的版本识别码生成的。

与上述提到的第一、第二、第三通信协议类似，其格式为：<配置信息管理中心ID，版本ID>。

（5）基于所述第四通信协议，向所述待配置网元设备反馈与所述版本识别码匹配的配置信息，供所述待配置网元设备进行版本配置。

对于待配置网元设备，本实施例具体指图1中的待配置路由器：

待配置路由器接收所述控制器通过第三通信协议下发的配置命令时，通过与配置信息管理中心进行交互完成配置信息的下载，并根据下载的配置信息完成本次版本配置。

（1）接收所述控制器通过第三通信协议下发的配置命令，所述第三通信协议携带有进行版本配置所需的配置信息的版本识别码。

（2）从所述第三通信协议中提取所述版本识别码。

（3）获取存储有与所述版本识别码匹配的配置信息的所述配置信息管理中心的配置信息管理中心识别码。

（4）根据所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第四通信协议。

（5）基于所述第四通信协议，向所述配置信息管理中心下发配置信息获取命令，供所述配置信息管理中心基于所述第四通信协议反馈与所述版本识别码匹配的配置信息。

（6）接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息。

（7）根据所述配置信息进行版本配置。

可理解的，在实际应用中，为了避免对相同版本进行重复配置，在执行（7）之前，可以先获取当前运行的当前版本信息；然后，判断所述当前版本信息与所述版本信息是否一致。

相应地，若不一致，则执行所述根据所述配置信息进行版本配置的操作；否则，基于所述第三通信协议，向所述控制器作出不需要进行版本配置的反馈。

（8）基于所述第三通信协议，向所述控制器反馈配置结果，如配置失败或配置成功。

此外，通过图1可以看出，在待配置网元设备为路由器时，路由器会包括主控板和若干个线卡。

故而，针对待配置网元设备为路由器时，路由器进行版本配置的过程具体为：

首先，将所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息，保存到主控板中。

然后，由所述主控板获取每一所述线卡的线卡识别码，进而根据所述版本识别码和每一所述线卡识别码，生成与对应的所述线卡进行通信的第五通信协议，并基于与每一所述线卡之间的所述第五通信协议，向每一所述线卡下发所述配置信息，供每一所述线卡根据所述配置信息进行版本配置。

通过上述描述可知，主控板与线卡之间所遵循的第五通信协议，具体为版本ID和线卡ID之间的关系，故而具体可以表示为<版本ID，线卡ID>的形式。

此外，值得一提的是，由于路由器芯片资源的限制，在实际应用中，通常可以预先根据不同业务类型制作不同大小和复杂度的版本，并存储在配置信息管理中心。控制器根据从编排器获取到的业务类型ID，从配置信息管理中心搜索可适配的版本的配置信息。但是，在实际搜索时，可能会搜索到多个版本。对于这种情况，可以对每个搜索到的版本进行打分，打分的原则基于版本用途和业务匹配度进行，匹配度越高的版本越接近用户需求，即最终反馈给路由器，进行版本配置时所需的配置信息是与最接近用户需求的。

此外，在实际应用中，为了使得版本配置更加符合实际使用需求，版本配置系统中涉及的编排器、控制器、配置信息管理中心和待配置网元设备中均设置有反馈机制，即当中间任何一个环节发生了拒绝动作，整个版本配置流程就会终止，本次操作便会取消，并最终通过编排器进行仲裁，向用户作出答复。

此外，关于上述涉及的第一、第二、第三、第四和第五，并不对通信协议本身构成限定，只是为了便于区分不同功能实体进行通信时所遵循的通信协议。

由此，完成了单个编排器、单个控制器、单个配置信息管理中心和单个待配置网元设备的版本配置系统进行版本配置的过程。

基于上述描述，对单个编排器、多个控制器、多个配置信息管理中心和多个待配置网元设备的版本配置系统进行版本配置的过程进行说明：

编排器根据用户需求，对所管辖的控制器集群下达指令，每一控制器根据管辖的待配置网元设备集群分别向对应的配置信息管理中心下发配置信息搜索命令，并对每一待配置网元设备下达配置命令，每一待配置网元设备从控制器指定的配置信息管理中心下载配置信息。

进一步地，考虑到网络的容灾要求，多个控制器之间，以及多个配置信息管理中心之间可以是负荷分担关系，也可以是主备关系。多个待配置网元设备一般都是独立的并行关系，由控制器整体控制。

此外，在实际应用中，待配置网元设备在进行版本配置时，为了实现业务保护，可以对进行版本配置的待配置网元设备进行隔离。

比如，控制器在确定配置信息管理中心存储有匹配的配置信息，即可以对待配置网元设备进行版本配置时，在向待配置网元设备下发配置命令后，可以进一步作出把整个待配置网元设备进行隔离，并重新计算拓扑，进行业务收敛。待版本配置完成后，控制器将隔离的待配置网元设备释放，并重新计算拓扑，进行业务收敛。

还比如，控制器在确定配置信息管理中心存储有匹配的配置信息，即可以对待配置网元设备进行版本配置时，在向待配置网元设备下发配置命令后，可以进一步作出仅将待配置网元设备中需要进行版本配置的单元进行隔离，并重新进行业务收敛。待版本配置完成后，控制器将待配置网元设备内部隔离的单元进行释放，并重新进行业务收敛。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，究竟采用何种方式对需要进行版本配置的待配置网元设备进行业务保护，具体可以按照业务影响最小的原则，一般优先选择仅隔离需要进行版本配置的单元的方式，当这种方式无法满足业务需求时，在选择隔离整个待配置网元设备的方式。

此外，值得一提的是，不论选择哪种方式，由于都涉及到流量路径的切换，因而需要把待配置的业务和流量切换到备份设备和备份链路上来达到业务保护的目的。待版本配置完成后，再将业务和流量切换到新单元上，以支持用户需求。

由此，本实施例提供的版本配置系统，通过利用编排器将用户需求按照预先定义的业务类型集转换为对应的业务类型识别码，进而根据标识编排器自身的编排器识别码，以及标识控制器的控制器识别码和确定的业务类型识别码，生成与控制器进行通信的第一通信协议，并基于生成的第一通信协议，向控制器下发配置命令，从而使得控制器在接收到编排器下发的配置命令后，能够控制待配置网元设备自主从配置信息管理中心获取相应的配置信息进行版本配置。由于整个版本配置流程中，仅需编排器、控制器、配置信息管理中心和待配置网元设备进行交互，便可以准确的定位版本配置需要用到的配置信息，根本无需人工干预，从而既做到了提升配置效率，又可以避免因为人工介入造成的人为误差。

除此之外，由于本申请提供的版本配置系统中，对待配置网元设备进行版本配置时所需的配置信息是单独存放在配置信息管理中心的，即不同版本对应的配置信息无需预先存储在每一待配置网元设备中，相同的版本的配置信息只需在配置信息管理中心存储一份即可，从而既可以减少预先在每一待配置网元设备部署不同版本的配置信息的人力，又可以方便后期运维人员对个版本的配置信息的更新维护。同时，通过将配置信息单独存放在配置信息管理中心，也使得对待配置网元设备的版本配置摆脱了待配置网元设备本地存储空间的限制，从而可以对待配置网元设备实现更多版本的配置，进而更好的满足各种用户需求。

本申请的第二实施例涉及一种版本配置方法，应用于版本配置系统中的编排器，所述版本配置系统还包括控制器、配置信息管理中心和待配置网元设备。

可理解的，在实际应用中，配置信息管理中心实质就是存储各种待配置网元设备的配置信息，如系统版本配置信息、功能版本配置信息、补丁版本配置信息的数据库。

相应地，所述待配置网元设备，可以是路由器、交换机、光传送网（opticaltransport network，OTN）中涉及的传输节点。

为了便于理解本实施例提供的版本配置方法，以下结合图2所示的流程图进行说明：

步骤201，接收用户需求，根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码。

其中，在本实施例中，所述业务类型集包括各用户需求和各业务类型识别码的对应关系。

此外，值得一提的是，在实际应用中，为了避免对不合法以及无效用户需求的响应，编排器中负责与用户进行交互的模块，可以称之为需求输入模块，在监测到用户需求到达时，可以先对用户需求的合法性进行约束检查。

相应地，若通过检查，确定当前用户需求合法，才真正接收，以供后续处理使用进，即只有合法的用户需求才会被编排器接收；否则，编排器直接拒绝所述用户需求。

关于上述所说的合法性检查，具体是指携带所述用户需求的原始请求的请求格式、采用的协议等是否符合编排器预预设要求。即，如果满足，则认为当前用户需求是合法的，否则为不合法的。

进一步地，由于编排器在将用户需求转换为控制器能够识别的业务需求，即确定用户需求对应的业务类型识别码时，是基于预先定义的业务类型集，因而为了避免对业务类型集中没有定义的用户需求进行分析处理，进而增加编排器资源的占用。在确定接收到的用户需求合法之后，根据预先定义的业务类型集，确定用户需求对应的业务类型识别码之前，还可以进一步判断用户需求是否为有效需求。

具体的，在实际应用中，对用户需求有效性的判断，可以根据预设的逻辑分析规则，判断用户需求是否为有效需求。

相应地，若通过判断，确定所述用户需求为有效需求，才执行上述根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码的操作。

关于上述所说的逻辑分析规则，可以是将事先定义好的业务类型定义为有效业务类型，或者无效业务类型；或者，只在逻辑分析规则中，定义有效业务类型，这样在基于逻辑分析规则进行判断时，只要当前用户需求对应的业务类型不在逻辑分析规则中，则认为当前用户需求为无效需求，反之则为有效需求。

此外，在实际应用中，可以将上述进行有效性检测的操作看作是由编排器内部的另一功能模块实现的，比如将进行有效性检测的模块称为需求分析模块。

进一步地，还可以将最终根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码的功能看作是由编排器内部的另一功能模块实现，比如业务类型模块。

基于上述描述可知，用户需求在到达编排器时，先由内部的需求输入模块进行合法性检查，在合法时再由内部的需求分析模块进行有效性分析，在有效时再由内部的业务类型模型根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码。

应当理解的是，上述功能模块的划分仅仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

步骤202，获取编排器识别码和所述控制器的控制器识别码。

步骤203，根据所述编排器识别码、所述控制器识别码和所述业务类型识别码，生成与所述控制器进行通信的第一通信协议。

步骤204，基于所述第一通信协议，向所述控制器下发配置命令，供所述控制器控制所述待配置网元设备从所述配置信息管理中心中获取配置信息进行版本配置。

通过上述描述不难发现，本实施例提供的版本配置方法，通过利用编排器将用户需求按照预先定义的业务类型集转换为对应的业务类型识别码，进而根据标识编排器自身的编排器识别码，以及标识控制器的控制器识别码和确定的业务类型识别码，生成与控制器进行通信的第一通信协议，并基于生成的第一通信协议，向控制器下发配置命令，从而使得控制器在接收到编排器下发的配置命令后，能够控制待配置网元设备自主从配置信息管理中心获取相应的配置信息进行版本配置。由于整个版本配置流程中，仅需编排器、控制器、配置信息管理中心和待配置网元设备进行交互，便可以准确的定位版本配置需要用到的配置信息，根本无需人工干预，从而既做到了提升配置效率，又可以避免因为人工介入造成的人为误差。

此外，不难发现，本实施例中提到的编排器、控制器、配置信息管理中心和待配置网元设备分别与第一实施例中涉及的编排器、控制器、配置信息管理中心和待配置网元设备对应，即本实施例可与第一实施例互相配合实施。故而，第一实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一实施例中。

本申请的第三实施例涉及一种版本配置方法，应用于版本配置系统中的控制器，所述版本配置系统还包括编排器、配置信息管理中心和待配置网元设备。

可理解的，在实际应用中，配置信息管理中心实质就是存储各种待配置网元设备的配置信息，如系统版本配置信息、功能版本配置信息、补丁版本配置信息的数据库。

相应地，所述待配置网元设备，可以是路由器、交换机、光传送网（opticaltransport network，OTN）中涉及的传输节点。

为了便于理解本实施例提供的版本配置方法，以下结合图3所示的流程图进行说明：

步骤301，接收所述编排器通过第一通信协议下发的配置命令，所述第一通信协议携带有用户需求对应的业务类型识别码。

步骤302，从所述第一通信协议中提取所述业务类型识别码，并根据所述业务类型识别码确定对所述待配置网元设备进行版本配置所需的配置信息的版本识别码。

步骤303，获取控制器识别码和所述配置信息管理中心的配置信息管理中心识别码。

步骤304，根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议。

步骤305，基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令，供所述配置信息管理中心确定是否存储有与所述版本识别码匹配的配置信息。

步骤306，接收所述配置管理中心通过所述第二通信协议反馈的搜索结果。

步骤307，判断所述搜索结果是否为所述配置信息管理中心存储有与所述版本识别码匹配的配置信息。

具体的说，若所述搜索结果为所述配置信息管理中心存储有与所述版本识别码匹配的配置信息则执行步骤308；否则，执行步骤311。

步骤308，获取所述待配置网元设备的网元识别码。

步骤309，根据所述控制器识别码、所述网元识别码和所述版本识别码，生成与所述待配置网元设备进行通信的第三通信协议。

步骤310，基于所述第三通信协议，向所述待配置网元设备下发配置命令，供所述待配置网元设备从所述配置信息管理中心获取所述版本识别码对应的配置信息进行版本配置。

步骤311，基于所述第一通信协议，向所述编排器作出配置失败的响应。

由此，本实施例提供的版本配置方法，控制器根据编排器下发的业务请求，向配置信息管理中心下发配置信息适配请求，进而在配置信息管理中心中存在匹配的配置信息时，向待配置路由器下发配置命令，在配置信息管理中心不存在匹配的配置信息时，通知编排器本次版本配置请求失败。由于整个版本配置流程中，仅需编排器、控制器、配置信息管理中心和待配置网元设备进行交互，便可以准确的定位版本配置需要用到的配置信息，根本无需人工干预，从而既做到了提升配置效率，又可以避免因为人工介入造成的人为误差。

除此之外，本实施例提供的版本配置方法，对待配置网元设备进行版本配置时所需的配置信息是单独存放在配置信息管理中心的，即不同版本对应的配置信息无需预先存储在每一待配置网元设备中，相同的版本的配置信息只需在配置信息管理中心存储一份即可，从而既可以减少预先在每一待配置网元设备部署不同版本的配置信息的人力，又可以方便后期运维人员对个版本的配置信息的更新维护。同时，通过将配置信息单独存放在配置信息管理中心，也使得对待配置网元设备的版本配置摆脱了待配置网元设备本地存储空间的限制，从而可以对待配置网元设备实现更多版本的配置，进而更好的满足各种用户需求。

此外，值得一提的是，在实际应用中，为了避免对不合法以及无效业务需求（业务类型识别码对应的业务类型）的响应，控制器中负责与编排器进行交互的模块，可以称之为业务类型输入模块，在监测到编排器通过第一通信协议下发的配置命令到达时，可以先对第一通信协议中携带的业务类型识别码对应的业务类型的合法性进行约束检查。

相应地，若通过检查，确定业务类型合法，才真正接收，以供后续处理使用进，即只有合法的业务类型才会被控制器接收；否则，直接拒绝。

进一步地，为了保证来业务类型即合法，又有效。在确定业务类型合法后，根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议之前，还可以进一步判断业务类型是否有效。

具体的，在实际应用中，对业务类型有效性的判断，同样可以根据预设的逻辑分析规则进行判断。

相应地，若通过判断确定业务类型有效，才执行上述根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议的操作。

关于控制器执行的合法性和有效性的判断，与编排器执行的合法性和有效性的判断类似，此处不再赘述。

此外，关于控制器进行合法性和有效性判断所依据的规则，本领域技术人可以根据需要进行设置，本实施例对此不作限制。

由此，控制器接收到编排器基于第一通信协议下发的配置命令后，在本地先对第一通信协议中携带的业务类型识别码对应的业务类型的合法性和有效性进行判断，使得版本配置流程更加合理。

此外，不难发现，本实施例中提到的编排器、控制器、配置信息管理中心和待配置网元设备分别与第一实施例中涉及的编排器、控制器、配置信息管理中心和待配置网元设备对应，即本实施例可与第一实施例互相配合实施。故而，第一实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一实施例中。

本申请的第四实施例涉及一种版本配置方法。

步骤401，接收所述控制器通过第二通信协议下发的配置信息搜索命令，所述第二通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码。

步骤402，从所述第二通信协议中提取所述版本识别码，根据所述版本识别码对本地存储的配置信息进行遍历，并根据遍历结果生成搜索结果。

步骤403，基于所述第二通信协议，向所述控制器反馈所述搜索结果，供所述控制器向所述编排器作出配置失败的响应，或控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置。

步骤404，接收所述待配置网元设备通过第四通信协议下发的配置信息获取命令，所述第四通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码。

步骤405，基于所述第四通信协议，向所述待配置网元设备反馈与所述版本识别码匹配的配置信息，供所述待配置网元设备进行版本配置。

由此，本实施例提供的版本配置方法，对待配置网元设备进行版本配置时所需的配置信息是单独存放在配置信息管理中心的，即不同版本对应的配置信息无需预先存储在每一待配置网元设备中，相同的版本的配置信息只需在配置信息管理中心存储一份即可，从而既可以减少预先在每一待配置网元设备部署不同版本的配置信息的人力，又可以方便后期运维人员对个版本的配置信息的更新维护。同时，通过将配置信息单独存放在配置信息管理中心，也使得对待配置网元设备的版本配置摆脱了待配置网元设备本地存储空间的限制，从而可以对待配置网元设备实现更多版本的配置，进而更好的满足各种用户需求。

此外，不难发现，本实施例中提到的编排器、控制器、配置信息管理中心和待配置网元设备分别与第一实施例中涉及的编排器、控制器、配置信息管理中心和待配置网元设备对应，即本实施例可与第一实施例互相配合实施。故而，第一实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一实施例中。

本申请的第五实施例涉及一种版本配置方法。

步骤501，接收所述控制器通过第三通信协议下发的配置命令，所述第三通信协议携带有进行版本配置所需的配置信息的版本识别码。

步骤502，从所述第三通信协议中提取所述版本识别码。

步骤503，获取存储有与所述版本识别码匹配的配置信息的所述配置信息管理中心的配置信息管理中心识别码。

步骤504，根据所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第四通信协议。

步骤505，基于所述第四通信协议，向所述配置信息管理中心下发配置信息获取命令，供所述配置信息管理中心基于所述第四通信协议反馈与所述版本识别码匹配的配置信息。

步骤506，接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息。

步骤507，根据所述配置信息进行版本配置。

具体的说，为了避免对相同版本进行重复配置，在执行步骤507之前，可以先获取当前运行的当前版本信息；然后，判断所述当前版本信息与所述版本信息是否一致。

相应地，若不一致，则执行所述根据所述配置信息进行版本配置的操作；否则，基于所述第三通信协议，向所述控制器作出不需要进行版本配置的反馈。

此外，为了使得编排器能够获知本次版本配置的情况，待配置网元设备在根据配置信息进行版本配置之后，可以基于第三通信协议向控制器反馈配置结果，比如配置成功或配置失败，进而使得控制器基于第一通信协议将反馈结果告知编排器。

此外，在实际应用中，待配置网元设备可以为路由器。

可理解的，通常情况下，路由器包括主控板和若干个线卡。

相应地，在所述接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息之后，会将所述配置信息保存到所述主控板；进而由所述主控板获取每一所述线卡的线卡识别码，根据所述版本识别码和每一所述线卡识别码，生成与对应的所述线卡进行通信的第五通信协议，并基于与每一所述线卡之间的所述第五通信协议，向每一所述线卡下发所述配置信息，供每一所述线卡根据所述配置信息进行版本配置。

由此，本实施例提供的版本配置方法，通过利用编排器将用户需求按照预先定义的业务类型集转换为对应的业务类型识别码，进而根据标识编排器自身的编排器识别码，以及标识控制器的控制器识别码和确定的业务类型识别码，生成与控制器进行通信的第一通信协议，并基于生成的第一通信协议，向控制器下发配置命令，从而使得控制器在接收到编排器下发的配置命令后，能够控制待配置网元设备自主从配置信息管理中心获取相应的配置信息进行版本配置。由于整个版本配置流程中，仅需编排器、控制器、配置信息管理中心和待配置网元设备进行交互，便可以准确的定位版本配置需要用到的配置信息，根本无需人工干预，从而既做到了提升配置效率，又可以避免因为人工介入造成的人为误差。

除此之外，对待配置网元设备进行版本配置时所需的配置信息是单独存放在配置信息管理中心的，即不同版本对应的配置信息无需预先存储在每一待配置网元设备中，相同的版本的配置信息只需在配置信息管理中心存储一份即可，从而既可以减少预先在每一待配置网元设备部署不同版本的配置信息的人力，又可以方便后期运维人员对个版本的配置信息的更新维护。同时，通过将配置信息单独存放在配置信息管理中心，也使得对待配置网元设备的版本配置摆脱了待配置网元设备本地存储空间的限制，从而可以对待配置网元设备实现更多版本的配置，进而更好的满足各种用户需求。

此外，不难发现，本实施例中提到的编排器、控制器、配置信息管理中心和待配置网元设备分别与第一实施例中涉及的编排器、控制器、配置信息管理中心和待配置网元设备对应，即本实施例可与第一实施例互相配合实施。故而，第一实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一实施例中。

此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本申请第六实施例涉及一种版本配置装置，如图6所示，包括：确定模块601、获取模块602、生成模块603和发送模块604。

其中，确定模块601，用于接收用户需求，根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码，所述业务类型集包括各用户需求和各业务类型识别码的对应关系；获取模块602，用于获取编排器识别码和所述控制器的控制器识别码；生成模块603，用于根据所述编排器识别码、所述控制器识别码和所述业务类型识别码，生成与所述控制器进行通信的第一通信协议；发送模块604，用于基于所述第一通信协议，向所述控制器下发配置命令，供所述控制器控制所述待配置网元设备从所述配置信息管理中心中获取配置信息进行版本配置。

此外，在另一个例子中，版本配置装置还包括需求输入模块。

具体的，需求输入模块，用于在确定模块601执行上述操作之前，对用户提交的用户需求的合法性进行约束检查。

相应地，若所述用户需求合法，则执行触发确定模块601执行上述操作；否则，拒绝所述用户需求。

此外，在另一个例子中，版本配置装置还包括需求分析模块。

具体的，需求分析模块，用于需求输入模块确定用户需求合法之后，确定模块601执行上述操作之前，根据预设的逻辑分析规则，判断所述用户需求是否为有效需求。

相应地，若所述用户需求为有效需求，则通知确定模块601执行据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码的操作。

不难发现，本实施例为与第二实施例相对应的装置实施例，本实施例可与第二实施例互相配合实施。第二实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第二实施例中。

本申请第七实施例涉及一种版本配置装置，如图7所示，包括：接收模块701、确定模块702、获取模块703、生成模块704和发送模块705。

其中，接收模块701，用于接收所述编排器通过第一通信协议下发的配置命令，所述第一通信协议携带有用户需求对应的业务类型识别码；确定模块702，用于从所述第一通信协议中提取所述业务类型识别码，并根据所述业务类型识别码确定对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；获取模块703，用于获取控制器识别码和所述配置信息管理中心的配置信息管理中心识别码；生成模块704，用于根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议；发送模块705，用于基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令，供所述配置信息管理中心确定是否存储有与所述版本识别码匹配的配置信息。

此外，在另一个例子中，接收模块701，还用于接收所述配置管理中心通过所述第二通信协议反馈的搜索结果。

相应地，若所述搜索结果为所述配置信息管理中心未存储与所述版本识别码匹配的配置信息，则基于所述第一通信协议，向所述编排器作出配置失败的响应；若所述搜索结果为所述配置信息管理中心存储有与所述版本识别码匹配的配置信息，则通知获取模块703获取所述待配置网元设备的网元识别码；生成模块704还用于根据所述控制器识别码、所述网元识别码和所述版本识别码，生成与所述待配置网元设备进行通信的第三通信协议；发送模块705还用于基于所述第三通信协议，向所述待配置网元设备下发配置命令，供所述待配置网元设备从所述配置信息管理中心获取所述版本识别码对应的配置信息进行版本配置。

此外，在另一个例子中，版本配置装置还包括业务类型输入模块。

具体的，业务类型输入模块，用于对所述第一通信协议中携带的所述业务类型识别码对应的业务类型的合法性进行约束检查。

相应地，若所述业务类型合法，则触发接收模块701执行所述接收所述编排器通过第一通信协议下发的配置命令的操作；否则，触发接收模块701执行基于所述第一通信协议，向所述编排器作出所述业务类型不合法的响应的操作。

此外，在另一个例子中，版本配置装置还包括业务类型分析模块。

具体的，业务类型分析模块，用于根据预设的逻辑分析规则，判断所述业务类型是否为有效业务类型。

相应地，若所述业务类型是有效业务类型，则触发生成模块704执行所述根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议的操作。

不难发现，本实施例为与第三实施例相对应的装置实施例，本实施例可与第三实施例互相配合实施。第三实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第三实施例中。

本申请第八实施例涉及一种版本配置装置，如图8所示，包括：接收模块801、搜索模块802和发送模块803。

其中，接收模块801，用于接收所述控制器通过第二通信协议下发的配置信息搜索命令，所述第二通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；搜索模块802，用于从所述第二通信协议中提取所述版本识别码，并根据所述版本识别码对本地存储的配置信息进行遍历；若遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心存储有与所述版本识别码匹配的配置信息作为搜索结果；若未遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心未存储与所述版本识别码匹配的配置信息作为所述搜索结果；发送模块803，用于基于所述第二通信协议，向所述控制器反馈所述搜索结果，供所述控制器向所述编排器作出配置失败的响应，或控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置。

此外，在另一个例子中，接收模块801，还用于接收所述待配置网元设备通过第四通信协议下发的配置信息获取命令，所述第四通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；发送模块803，还用于基于所述第四通信协议，向所述待配置网元设备反馈与所述版本识别码匹配的配置信息，供所述待配置网元设备进行版本配置。

不难发现，本实施例为与第四实施例相对应的装置实施例，本实施例可与第四实施例互相配合实施。第四实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第四实施例中。

本申请第九实施例涉及一种版本配置装置，如图9所示，包括：接收模块901、提取模块902、获取模块903、生成模块904、发送模块905和配置模块906。

其中，接收模块901，用于接收所述控制器通过第三通信协议下发的配置命令，所述第三通信协议携带有进行版本配置所需的配置信息的版本识别码；提取模块902，用于从所述第三通信协议中提取所述版本识别码；获取模块903，用于获取存储有与所述版本识别码匹配的配置信息的所述配置信息管理中心的配置信息管理中心识别码；生成模块904，用于根据所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第四通信协议；发送模块905，用于基于所述第四通信协议，向所述配置信息管理中心下发配置信息获取命令，供所述配置信息管理中心基于所述第四通信协议反馈与所述版本识别码匹配的配置信息；接收模块901，还用于接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息；配置模块906，用于根据所述配置信息进行版本配置。

此外，在另一个例子中，接收模块901，还用于基于所述第三通信协议，向所述控制器反馈配置结果，比如配置成功或配置失败。

此外，在另一个例子中，版本配置装置还包括配置信息检测模块。

具体的，获取模块903，用于获取当前运行的当前版本信息。

配置信息检测模块，用于判断所述当前版本信息与所述版本信息是否一致。

相应地，若不一致，则执行触发配置模块906执行根据所述配置信息进行版本配置的操作；否则，触发接收模块901执行基于所述第三通信协议，向所述控制器作出不需要进行版本配置的反馈的操作。

此外，在另一个例子中，待配置网元设备为路由器，所述路由器包括主控板和若干个线卡。

相应地，接收模块901在接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息之后，还会执行将所述配置信息保存到所述主控板的操作。

相应地，配置模块906，在根据所述配置信息进行版本配置时，具体为：

所述主控板获取每一所述线卡的线卡识别码；

所述主控板根据所述版本识别码和每一所述线卡识别码，生成与对应的所述线卡进行通信的第五通信协议；

所述主控板基于与每一所述线卡之间的所述第五通信协议，向每一所述线卡下发所述配置信息，供每一所述线卡根据所述配置信息进行版本配置。

不难发现，本实施例为与第五实施例相对应的装置实施例，本实施例可与第五实施例互相配合实施。第五实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第五实施例中。

值得一提的是，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施例中不存在其它的单元。

本申请的第十实施例涉及一种版本配置设备，如图10所示，包括：包括至少一个处理器1001；以及，与至少一个处理器1001通信连接的存储器1002；其中，存储器1002存储有可被至少一个处理器1001执行的指令，指令被至少一个处理器1001执行，以使至少一个处理器1001能够执行上述方法实施例所描述的版本配置方法。

需要说明的是，在实际应用中，本实施例中所说的版本配置设备，可能是编排器、控制器、配置信息管理中心和待配置网元设备中的任意一种。

故而，上述所说的版本配置设备中的处理器1001能够执行上述方法实施例所描述的版本配置方法，具体为：

在所述版本配置设备为编排器时，内部的处理器1001执行的为应用于编排器的版本配置方法，即上述第二实施例所描述的版本配置方法。

相应地，在所述版本配置设备为控制器时，内部的处理器1001执行的为应用于控制器的版本配置方法，即上述第三实施例所描述的版本配置方法。

相应地，在所述版本配置设备为配置信息管理中心时，内部的处理器1001执行的为应用于配置信息管理中心的版本配置方法，即上述第四实施例所描述的版本配置方法。

相应地，在所述版本配置设备为待配置网元设备时，内部的处理器1001执行的为应用于待配置网元设备的版本配置方法，即上述第五实施例所描述的版本配置方法。

此外，可理解的，在实际应用中，存储器1002和处理器1001采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器1001和存储器1002的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1001处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器1001。

处理器1001负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1002可以被用于存储处理器1001在执行操作时所使用的数据。

本申请的第十一实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例所描述的版本配置方法。

同理，由于在实际应用中，本实施例中所说的版本配置设备，可能是编排器、控制器、配置信息管理中心和待配置网元设备中的任意一种。

故而，在实际应用中，本实施例中所说的计算机存储介质涉及适应于上述四种版本配置设备的计算机可读存储介质。

相应地，上述所说的计算机程序被处理器执行时实现上述方法实施例所描述的版本配置方法，具体为：

在所述版本配置设备为编排器时，部署于编排器内的计算机程序被内部的处理器执行时，具体实现的是应用于编排器的版本配置方法，即上述第二实施例所描述的版本配置方法。

相应地，在所述版本配置设备为控制器时，部署于控制器内的计算机程序被内部的处理器执行时，具体实现的是应用于控制器的版本配置方法，即上述第三实施例所描述的版本配置方法。

相应地，在所述版本配置设备为配置信息管理中心时，部署于配置信息管理中心内的计算机程序被内部的处理器执行时，具体实现的是应用于配置信息管理中心的版本配置方法，即上述第四实施例所描述的版本配置方法。

相应地，在所述版本配置设备为待配置网元设备时，部署于待配置网元设备内的计算机程序被内部的处理器执行时，具体实现的是应用于待配置网元设备的版本配置方法，即上述第五实施例所描述的版本配置方法。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (16)

1.一种版本配置方法，其特征在于，应用于版本配置系统中的编排器，所述版本配置系统还包括控制器、配置信息管理中心和待配置网元设备，所述版本配置方法包括：

接收用户需求，根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码，所述业务类型集包括各用户需求和各业务类型识别码的对应关系；

获取编排器识别码和所述控制器的控制器识别码；

根据所述编排器识别码、所述控制器识别码和所述业务类型识别码，生成与所述控制器进行通信的第一通信协议；

基于所述第一通信协议，向所述控制器下发配置命令，供所述控制器控制所述待配置网元设备从所述配置信息管理中心中获取配置信息进行版本配置。

2.根据权利要求1所述的方法，其特征在于，在所述接收用户需求之前，所述方法还包括：

对所述用户需求的合法性进行约束检查；

若所述用户需求合法，则执行所述接收所述用户需求的步骤；

否则，拒绝所述用户需求。

3.根据权利要求2所述的方法，其特征在于，在所述根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码之前，所述方法还包括：

根据预设的逻辑分析规则，判断所述用户需求是否为有效需求；

若所述用户需求为有效需求，则执行所述根据预先定义的业务类型集，确定所述用户需求对应的业务类型识别码的步骤。

4.一种版本配置方法，其特征在于，应用于版本配置系统中的控制器，所述版本配置系统还包括编排器、配置信息管理中心和待配置网元设备，所述版本配置方法包括：

接收所述编排器通过第一通信协议下发的配置命令，所述第一通信协议携带有用户需求对应的业务类型识别码；

从所述第一通信协议中提取所述业务类型识别码，并根据所述业务类型识别码确定对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

获取控制器识别码和所述配置信息管理中心的配置信息管理中心识别码；

根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议；

基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令，供所述配置信息管理中心确定是否存储有与所述版本识别码匹配的配置信息。

5.根据权利要求4所述的方法，其特征在于，在所述基于所述第二通信协议，向所述配置信息管理中心下发配置信息搜索命令之后，所述方法还包括：

接收所述配置管理中心通过所述第二通信协议反馈的搜索结果；

若所述搜索结果为所述配置信息管理中心未存储与所述版本识别码匹配的配置信息，则基于所述第一通信协议，向所述编排器作出配置失败的响应；

若所述搜索结果为所述配置信息管理中心存储有与所述版本识别码匹配的配置信息，则获取所述待配置网元设备的网元识别码；

根据所述控制器识别码、所述网元识别码和所述版本识别码，生成与所述待配置网元设备进行通信的第三通信协议；

基于所述第三通信协议，向所述待配置网元设备下发配置命令，供所述待配置网元设备从所述配置信息管理中心获取所述版本识别码对应的配置信息进行版本配置。

6.根据权利要求4所述的方法，其特征在于，在所述接收所述编排器通过第一通信协议下发的配置命令之前，所述方法还包括：

对所述第一通信协议中携带的所述业务类型识别码对应的业务类型的合法性进行约束检查；

若所述业务类型合法，则执行所述接收所述编排器通过第一通信协议下发的配置命令的步骤；

否则，基于所述第一通信协议，向所述编排器作出所述业务类型不合法的响应。

7.根据权利要求6所述的方法，其特征在于，在所述根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议之前，所述方法还包括：

根据预设的逻辑分析规则，判断所述业务类型是否为有效业务类型；

若是，则执行所述根据所述控制器识别码、所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第二通信协议的步骤。

8.一种版本配置方法，其特征在于，应用于版本配置系统中的配置信息管理中心，所述版本配置系统还包括编排器、控制器和待配置网元设备，所述版本配置方法包括：

接收所述控制器通过第二通信协议下发的配置信息搜索命令，所述第二通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

从所述第二通信协议中提取所述版本识别码，并根据所述版本识别码对本地存储的配置信息进行遍历；

若遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心存储有与所述版本识别码匹配的配置信息作为搜索结果；

若未遍历到与所述版本识别码匹配的配置信息，则将所述配置信息管理中心未存储与所述版本识别码匹配的配置信息作为所述搜索结果；

基于所述第二通信协议，向所述控制器反馈所述搜索结果，供所述控制器向所述编排器作出配置失败的响应，或控制所述待配置网元设备从所述配置信息管理中心中获取与所述版本识别码匹配的配置信息进行版本配置。

9.根据权利要求8所述的方法，其特征在于，在所述基于所述第二通信协议，向所述控制器反馈所述搜索结果之后，所述方法还包括：

接收所述待配置网元设备通过第四通信协议下发的配置信息获取命令，所述第四通信协议携带有对所述待配置网元设备进行版本配置所需的配置信息的版本识别码；

基于所述第四通信协议，向所述待配置网元设备反馈与所述版本识别码匹配的配置信息，供所述待配置网元设备进行版本配置。

10.一种版本配置方法，其特征在于，应用于版本配置系统中的待配置网元设备，所述版本配置系统还包括编排器、控制器和配置信息管理中心，所述版本配置方法包括：

接收所述控制器通过第三通信协议下发的配置命令，所述第三通信协议携带有进行版本配置所需的配置信息的版本识别码；

从所述第三通信协议中提取所述版本识别码；

获取存储有与所述版本识别码匹配的配置信息的所述配置信息管理中心的配置信息管理中心识别码；

根据所述配置信息管理中心识别码和所述版本识别码，生成与所述配置信息管理中心进行通信的第四通信协议；

基于所述第四通信协议，向所述配置信息管理中心下发配置信息获取命令，供所述配置信息管理中心基于所述第四通信协议反馈与所述版本识别码匹配的配置信息；

接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息；

根据所述配置信息进行版本配置。

11.根据权利要求10所述的方法，其特征在于，在所述根据所述配置信息进行版本配置之后，所述方法还包括：

基于所述第三通信协议，向所述控制器反馈配置结果。

12.根据权利要求10所述的方法，其特征在于，在所述根据所述配置信息进行版本配置之前，所述方法还包括：

获取当前运行的当前版本信息；

判断所述当前版本信息与所述版本信息是否一致；

若不一致，则执行所述根据所述配置信息进行版本配置的步骤；

否则，基于所述第三通信协议，向所述控制器作出不需要进行版本配置的反馈。

13.根据权利要求10所述的方法，其特征在于，所述待配置网元设备为路由器，所述路由器包括主控板和若干个线卡；

在所述接收所述配置信息管理中心通过所述第四通信协议反馈的与所述版本识别码匹配的配置信息之后，所述方法还包括：

将所述配置信息保存到所述主控板；

所述根据所述配置信息进行版本配置，包括：

所述主控板获取每一所述线卡的线卡识别码；

所述主控板根据所述版本识别码和每一所述线卡识别码，生成与对应的所述线卡进行通信的第五通信协议；

所述主控板基于与每一所述线卡之间的所述第五通信协议，向每一所述线卡下发所述配置信息，供每一所述线卡根据所述配置信息进行版本配置。

14.一种版本配置设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至3任一所述的版本配置方法，或者权利要求4至7任一项所述的版本配置方法，或者8和9任一项所述的版本配置方法，或者10至13任一项所述的版本配置方法。

15.一种版本配置系统，其特征在于，所述版本配置系统包括：编排器、控制器、配置信息管理中心和待配置网元设备；

所述编排器，用于执行如权利要求1至3任一所述的版本配置方法；

所述控制器，用于执行如权利要求4至7任一项所述的版本配置方法；

所述配置信息管理中心，用于执行如权利要求8和9任一项所述的版本配置方法；

所述待配置网元设备，用于执行如权利要求10至13任一项所述的版本配置方法。

16.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至3任一所述的版本配置方法，或者权利要求4至7任一项所述的版本配置方法，或者8和9任一项所述的版本配置方法，或者10至13任一项所述的版本配置方法。

Images