数据配置的方法和装置与流程

1.本技术涉及光通信领域，并且更具体地，涉及一种数据配置的方法和装置。


背景技术：

2.网络配置协议(network configuration protocol，netconf)是一种网络管理协议。其中，网管设备上保存了网元设备的配置数据，网管设备可以通过netconf对网元设备进行配置和管理。
3.然而，当网元设备的配置数据发生变化时，可能存在网管设备保存的配置数据和网元设备的配置数据不一致的情况，进而影响正常的通信。
4.因此，如何保证网管设备和网元设备的配置数据的一致性，提升数据同步的效率和性能是亟待解决的问题。


技术实现要素：

5.本技术实施例提供一种数据配置的方法和装置，能够保证网管设备和网元设备的配置数据的一致性，提升数据同步的效率和性能。
6.第一方面，提供了一种数据配置的方法，包括：网管设备向网元设备发送网络配置协议netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，该配置获取请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；网管设备接收来自网元设备的netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
7.其中，该方法可以由网管设备执行，或者，也可以由用于网管设备的芯片或电路执行，本技术对此不作限定。为了便于描述，下面以由网管设备执行为例进行说明。
8.示例性的，netconf中的配置获取请求消息可以是《get-config》。
9.需要说明的是，本技术适用于网管设备通过netconf管理网元设备的场景。
10.根据本技术提供的方案，网管设备增广netconf中的配置获取请求消息，即新增配置变更标记叶子节点。例如，change-sn。即分别在配置获取请求消息和配置获取响应消息中携带配置变更标记，可以同步配置变化的数据。相比当前网管设备和网元设备之间收发和配置全部的数据，本技术技术方案通过较少的反馈量，能够减少信令开销和计算资源，提升网管设备与网络设备之间的配置数据的同步效率和性能，保证网管设备和网元设备的配置数据的一致性等。
11.结合第一方面，在第一方面的某些实现方式中，网管设备根据第二配置变更标记确定是否更新第一配置变更标记和第二配置数据，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
12.在该实现方式中，网管设备可以根据第二配置变更标记和本地配置变更标记(即第一配置变更标记)实现变更的配置数据的同步，减少计算资源和提升同步效率，最终保证
网管设备和网元设备的配置数据一致。
13.结合第一方面，在第一方面的某些实现方式中，网管设备根据第二配置变更标记确定是否更新第一配置变更标记和第二配置数据，包括：当第二配置变更标记与第一配置变更标记不同时，网管设备确定更新第一配置变更标记和第二配置数据。
14.在该实现方式中，网管设备可以根据较少反馈量(即，第二配置变更标记)同步配置变化的数据，实现与网元设备侧的配置数据一致。
15.结合第一方面，在第一方面的某些实现方式中，配置获取响应消息还包括第一配置数据，方法还包括：网管设备将第一配置变更标记更新为第二配置变更标记，以及将第二配置数据更新为第一配置数据。
16.在该实现方式中，网管设备在确定与网元设备侧的配置数据不同时，需要将本地配置变更标记和第一配置数据进行更新(同步变化的配置数据)，从而保证两侧设备的配置数据的一致性，可以通过较少的反馈量提升配置数据同步的效率。
17.结合第一方面，在第一方面的某些实现方式中，网管设备根据第二配置变更标记确定是否更新第一配置变更标记和第二配置数据，包括：当第二配置变更标记与第一配置变更标记相同时，网管设备确定不更新第一配置变更标记和第二配置数据。
18.在该实现方式中，网管设备可以根据配置变更标记相同确定与网元设备的配置数据一致，实现通过较少的反馈量提升配置数据同步的效率。
19.第二方面，提供了一种数据配置的方法，包括：网元设备接收来自网管设备的netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，该配置获取请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；网元设备向网管设备发送netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
20.其中，该方法可以由网元设备执行，或者，也可以由用于网元设备的芯片或电路执行，本技术对此不作限定。为了便于描述，下面以由网元设备执行为例进行说明。
21.根据本技术提供的方案，通过增广netconf中的配置获取请求消息，即新增配置变更标记叶子节点。例如，change-sn。在配置获取请求消息和配置获取响应消息中分别携带配置变更标记，可以同步配置变化的数据。相比当前网管设备和网元设备之间收发和配置全部的数据，本技术技术方案通过较少的反馈量，能够减少信令开销和计算资源，提升网管设备与网络设备之间的配置数据的同步效率和性能，保证网管设备和网元设备的配置数据的一致性等。
22.结合第二方面，在第二方面的某些实现方式中，网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据是否相同，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
23.在该实现方式中，网元设备可以根据第一配置变更标记和本地配置变更标记(即第二配置变更标记)确定两侧设备的配置数据是否一致。
24.结合第二方面，在第二方面的某些实现方式中，当网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据不同时，第二配置变更标记与第一配置变更标记不同，且配置获取响应消息还包括第一配置数据。
25.在该实现方式中，网元设备通过网管设备下发的第一配置变更标记和网元设备本地的第二配置变更标记不一致，可以确定两侧设备的配置数据不同。那么，网元设备反馈的配置获取响应消息中携带第二配置变更标记及其对应的第一配置数据，用于网管设备进行配置数据的同步以及配置变更标记的更新，通过较少的反馈量可以实现两侧设备配置数据的一致性。
26.结合第二方面，在第二方面的某些实现方式中，当网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据相同时，第二配置变更标记与第一配置变更标记相同。
27.在该实现方式中，网元设备通过网管设备下发的第一配置变更标记和网元设备本地的第二配置变更标记一致，可以确定两侧设备的配置数据相同。那么，网元设备反馈的配置获取响应消息中可以不携带配置数据，通过较少的反馈量可以实现两侧设备配置数据的一致性。
28.结合第一方面和第二方面，在某些实现方式中，第一配置变更标记和第二配置变更标记包括以下配置变更标记中的一种：配置变更流水号、信息摘要(message digest，md5)散列码、哈希校验码(hash)、循环冗余校验码(cyclic redundancy check，crc)、配置时间戳。
29.可选地，第一配置变更标记和第二配置变更标记是相同类型的配置变更标记。例如，第一配置变更标记是配置变更流水号
‘
123’。对应的，第二配置变更标记也可以是配置变更流水号
‘
123’或
‘
124’等。
30.结合第一方面和第二方面，在某些实现方式中，第一配置变更标记为数据库对应的全局配置变更标记，数据库包括多个数据配置表；或者，第一配置变更标记为第一数据配置表对应的配置变更标记，第一数据配置表属于数据库，数据库包括多个数据配置表，多个数据配置表与多个配置变更标记一一对应。
31.在该实现方式中，第一配置变更标记可以是数据库对应的全局配置变更标记，也可以是某一数据配置表对应的配置变更标记，本技术对此不作具体限定。
32.需要说明的是，当第一配置变更标记为全局配置变更标记，且第一配置变更标记与第二配置变更标记相同时，说明两侧设备的数据库中的数据相同，无需进一步执行数据配置表的数据查询和对齐。反之，当第一配置变更标记为全局配置变更标记，且第一配置变更标记与第二配置变更标记不同时，说明两侧设备的数据库中的数据不同，需要进一步执行数据配置表的数据查询和对齐。即网管设备向网元设备发送配置获取请求消息，用于请求获取数据表#1对应的配置数据#1，并根据配置获取响应消息进一步比较和对齐数据表#1中的配置数据，依次查询，直至所有的数据配置表的数据完成同步。
33.第三方面，提供了一种数据配置的装置，包括：收发单元，用于网管设备向网元设备发送netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，该配置获取请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；收发单元，还用于网管设备接收来自网元设备的netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
34.结合第三方面，在第三方面的某些实现方式中，该装置还包括：处理单元，用于网
管设备根据第二配置变更标记确定是否更新第一配置变更标记和第二配置数据，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
35.结合第三方面，在第三方面的某些实现方式中，处理单元，还用于当第二配置变更标记与第一配置变更标记不同时，网管设备确定更新第一配置变更标记和第二配置数据。
36.结合第三方面，在第三方面的某些实现方式中，配置获取响应消息还包括第一配置数据，处理单元，还用于：网管设备将第一配置变更标记更新为第二配置变更标记，以及将第二配置数据更新为第一配置数据。
37.结合第三方面，在第三方面的某些实现方式中，处理单元，还用于当第二配置变更标记与第一配置变更标记相同时，网管设备确定不更新第一配置变更标记和第二配置数据。
38.第四方面，提供了一种数据配置的装置，包括：收发单元，用于网元设备接收来自网管设备的netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，该配置获取请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；收发单元，还用于网元设备向网管设备发送netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
39.结合第四方面，在第四方面的某些实现方式中，处理单元，用于网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据是否相同，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
40.结合第四方面，在第四方面的某些实现方式中，当网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据不同时，第二配置变更标记与第一配置变更标记不同，且配置获取响应消息还包括第一配置数据。
41.结合第四方面，在第四方面的某些实现方式中，当网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据相同时，第二配置变更标记与第一配置变更标记相同。
42.结合第三方面和第四方面，在某些实现方式中，第一配置变更标记包括以下配置变更标记中的一种：配置变更流水号、信息摘要md5散列码、哈希校验码hash、循环冗余校验码crc、配置时间戳。
43.结合第三方面和第四方面，在某些实现方式中，第一配置变更标记为数据库对应的全局配置变更标记，数据库包括多个数据配置表；或者，第一配置变更标记为第一数据配置表对应的配置变更标记，第一数据配置表属于数据库，数据库包括多个数据配置表，多个数据配置表与多个配置变更标记一一对应。
44.第五方面，提供了一种通信装置，包括，处理器，可选地，还包括存储器，该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得网管设备执行上述第一方面或第一方面中任一种可能实现方式中的方法。
45.可选地，该处理器为一个或多个，该存储器为一个或多个。
46.可选地，该存储器可以与该处理器集成在一起，或者该存储器与处理器分离设置。
47.可选地，该网管设备还包括收发器，收发器具体可以为发射机(发射器)和接收机
(接收器)。
48.第六方面，提供了一种通信装置，包括，处理器，可选地，还包括存储器，该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得网元设备执行上述第二方面或第二方面中任一种可能实现方式中的方法。
49.可选地，该处理器为一个或多个，该存储器为一个或多个。
50.可选地，该存储器可以与该处理器集成在一起，或者该存储器与处理器分离设置。
51.可选地，该网元设备还包括收发器，收发器具体可以为发射机(发射器)和接收机(接收器)。
52.第七方面，提供了一种通信系统，包括：网管设备，用于执行上述第一方面或第一方面任一种可能实现方式中的方法；以及网元设备，用于执行上述第二方面或第二方面任一种可能实现方式中的方法。
53.第八方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序或代码，该计算机程序或代码在计算机上运行时，使得该计算机作为网管设备执行上述第一方面或第一方面任一种可能实现方式中的方法，或者使得该计算机作为网元设备执行上述第二方面或第二方面任一种可能实现方式中的方法。
54.第九方面，提供了一种芯片，包括至少一个处理器，该至少一个处理器与存储器耦合，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片的网管设备执行上述第一方面或第一方面任一种可能实现方式中的方法，或者使得安装有该芯片的网元设备执行上述第二方面或第二方面任一种可能实现方式中的方法。
55.其中，该芯片可以包括用于发送信息或数据的输入电路或者接口，以及用于接收信息或数据的输出电路或者接口。
56.第十方面，提供了一种计算机程序产品，该计算机程序产品包括计算机程序代码，当该计算机程序代码被网管设备运行时，使得该网管设备执行上述第一方面或第一方面任一种可能实现方式中的方法；或者，当该计算机程序代码被网元设备运行时，使得该网元设备执行上述第二方面或第二方面任一种可能实现方式中的方法。
附图说明
57.图1是适用本技术的通信系统的一例示意图。
58.图2是适用本技术的应用场景的一例示意图。
59.图3是适用本技术的数据配置的方法的一例示意图。
60.图4是适用本技术的数据配置的方法的另一例示意图。
61.图5是适用本技术的数据配置的方法的又一例示意图。
62.图6是适用本技术的数据配置的方法的又一例示意图。
63.图7是适用本技术的数据配置的装置的一例示意图。
64.图8是适用本技术的数据配置的装置的另一例示意图。
具体实施方式
65.下面将结合附图，对本技术实施例中的技术方案进行描述。
66.本技术实施例可以应用于光通信系统，该光通信网络包括但不限于：光传送网(optical transport network，otn)、光接入网(optical access network，oan)、同步数字体系(synchronous digital hierarchy，sdh)、无源光网络(passive optical network，pon)、以太网(ethernet)、或灵活以太网(flex ethernet，flexe)、波分复用(wavelength division multiplexing，wdm)网络等中的任意一种或多种的组合。
67.下面结合图1中所示的光通信网络，对本技术提供的数据配置的方法应用的通信系统进行示例性说明。其中，该光通信网络中可以包括多个网元设备以及控制器(例如，网管设备)。该多个网元设备如图1中所示的发送设备a、发送设备b、接收设备c和接收设备d等。当然，此处的四个网元设备仅仅是示例性说明，实际应用场景中可以包括更多或者更少的设备，本技术对此并不作限定。
68.其中，发送设备a和接收设备c之间通过光纤连接，发送设备b和接收设备d之间也通过光纤连接，光纤用于传输设备之间的数据。控制器(例如，网管设备)和光通信网络中的接收设备连接，从而获取接收设备接收到的光信号的具体信息，例如频率或相位等信息。
69.当然，控制器(例如，网管设备)也可以与光通信网络中的发送设备连接。本技术以下实施方式中，以控制器与接收设备连接为例进行示例性说明，对于控制器与发送设备之间的连接不作限定。并且，光通信网络中的网元，可以同时具备发送光信号和接收光信号的功能。因此，本技术实施例中的发送设备是指发送光信号的网元，接收设备是指接收光信号的网元。在实际应用场景中，发送设备也可以具备接收光信号的功能，接收设备也可以具备发送光信号的功能。
70.本技术提供的数据配置的方法可以由控制器(例如，网管设备)执行，例如，软件定义网络(software defined network，sdn)控制器或路径计算单元(path computation element，pce)等执行，也可以由光通信网络中的网元设备来执行，具体可以根据实际应用场景进行调整。
71.目前，协议标准在rfc6241中定义了网络配置协议netconf，它是一种基于xml的网络管理协议，为网络设备进行配置和管理提供了可编程的方法。
72.netconf提供了一个标准框架和一个标准远程过程调用协议(remote procedure call，rpc)方法的集合。网管设备可以通过《get-config》查询网元设备的配置数据，即《get-config》用于检索全部或部分指定的配置数据存储。另外，标准中还定义了《get-config》的子树过滤，xpath过滤，用于实现批量获取设备配置数据的方法。
73.应理解，netconf使用简单的基于rpc的机制来促进客户端和服务器之间的通信。客户端可以是作为网络管理器的一部分运行的脚本或应用程序，服务器则可以是一个网络设备等。
74.netconf功能协议栈分为四层，即安全传输(secure transport)层、消息(messages)层、操作(operations)层和内容(content)层。其中，安全传输层提供客户端和服务器之间的通信路径。消息层为编码rpc和通知提供了一个简单的、与传输无关的成帧机制。操作层定义了一组使用xml编码参数作为rpc方法调用的基本协议操作。内容层是唯一没有标准化的层，进而产生了一种新的建模语言(yet another next generation，yang)。
75.当前，网管设备(或控制器)可以通过netconf协议管理网元设备，网管设备上保存了网元设备的配置数据，当网元设备的配置数据变化时，可能存在网管保存的网元设备配置数据和设备侧的配置数据不一致的问题。
76.图2是适用本技术的应用场景的一例示意图。如图2所示，多个网管设备(例如，网管设备1和网管设备2)通过netconf协议共同管理多个网元设备(例如，网元设备1、网元设备2和网元设备n)。如果其中一个网管设备(例如，网管设备1)修改了该网元设备(中的一个或多个)的配置数据，那么其它网管设备(例如，网管设备2)保存的该网元设备(中的一个或多个)的配置数据和该网元设备(中的一个或多个)最新的配置数据是不一致的。为了保证正常通信，其他网管设备需要快速获取配置并进行数据同步。或者，当维护人员通过命令行界面(command line interface，cli)终端的配置接口变更了该网元设备(中的一个或多个)的数据配置时，多个网管设备保存的该网元设备(中的一个或多个)的配置数据和该网元设备(中的一个或多个)最新的配置数据是不一致的。为了保证正常通信，多个网管设备需要快速获取配置并进行数据同步。又或者，该网元设备(中的一个或多个)频繁上下线，在复位重启后其配置数据可能发生变化，那么，此时多个网管设备保存的该网元设备(中的一个或多个)的配置数据和该网元设备(中的一个或多个)最新的配置数据是不一致的。为了保证正常通信，多个网管设备需要快速确认转发器业务配置是否变更。
77.所以，网管设备需要定期或者在特定场景下(例如，网元设备重新上线时)通过netconf协议同步网元设备的配置数据，完成与网元设备的配置数据的对账。
78.当前，为了避免上述问题，有以下几种方案：
79.其一，网管设备需要和网元设备进行数据同步的时候，网管设备可以下发《get-config》报文，用于查询网元设备的配置数据。
80.示例性的，网管设备向网元设备发送用于查询配置数据的报文，如下所示：
[0081][0082]
然后，网元设备向网管设备发送查询配置数据的结果，如下所示：
[0083][0084][0085]
最后，网管设备将接收的查询结果和自身所存储的网元设备的配置数据进行对比后，可以确定知网管设备和网元设备的数据差异。基于此差异结果，网管设备可以按照预先配置的策略，更新网管设备存储的配置数据。或者，网管设备向网元设备下发《edit-config》指令，用于指示网元设备修改配置数据，进而达成网管设备和网元设备之间的配置数据一致性的目的。
[0086]
然而，在该实现方式中，通过netconf的《get-config》指令查询网元设备的配置数据，网管设备需要遍历查询网元设备的每一个配置表，由于网元设备的配置数据量非常大，因此网元设备需要返回大量的配置数据，导致两侧数据同步的效率非常低。而且，网管设备还需要对大量的配置数据进行对比获取数据差异，不可避免地消耗大量的计算资源。随着通信需求的不断增加，网管设备管理网元设备的规模越来越大，这将存在严重的性能问题，极大地增加了业务恢复时间。
[0087]
其二，网管设备需要和网元设备进行数据同步的时候，网管设备可以配置需要同步的配置数据表，并将配置数据表发送给网元设备。网元设备根据接收的配置数据表，收集配置数据并生成配置数据文件，然后通过sftp/ftp协议将配置数据文件发送给网管设备，网管设备再解析配置数据文件，获取两侧的配置差异，最后根据预先配置的策略进行处理，更新网管设备存储的配置数据。
[0088]
在该实现方式中，虽然减少了网管设备和网元设备之间的《get-config》指令交互，但是大量的数据配置的问题并没有解决，配置数据文件传输到网管设备后，网管设备依然需要花费较多的计算资源来对比数据，因此，依然存在性能差的问题。
[0089]
综上所述，本技术技术方案适用于网管设备通过netconf协议管理网元设备的场景，当网元设备的配置数据发生变化时，可能存在网管设备保存的配置数据和网元设备的配置数据不一致的情况，进而影响正常的通信。而且，大量配置数据的同步和计算将导致网管设备和网元设备的数据同步性能差的问题。
[0090]
有鉴于此，本技术提供了一种数据配置的方法和装置，通过同步配置变化的数据，减少《get-config》查询返回的配置数据量，保证网管设备和网元设备的配置数据的一致性的同时，提高数据配置和同步的性能，提升同步效率。
[0091]
为便于理解本技术实施例，首先对本技术中涉及的几个概念进行简单说明。
[0092]
1、网络管理系统(network management system，nms)：nms系统是一个操作维护中心，负责无线接入系统的设备故障诊断和操作维修、网络操作与网络管理，为网络管理与规划提供数据及统计。
[0093]
nms的管理对象可以包括网络中所有的实体，例如：网络设备、应用程序、服务器系统、路由器、交换机、辅助设备(例如，不间断电源(uninterruptible power system/uninterruptible power supply，ups))等，为网络系统管理员提供一个全系统的网络视图。nms为运营商提供了管理不同地域和不同设备供应商网络的途径。网络管理员通过nms对网络进行全面监控运行状态，可以更好地管理和维护网络。通过nms能够提高网络的可用性和可靠性，从而在整体上提高网络运行的效率，降低管理成本。
[0094]
2、(yet another next generation，yang)：是一种网络配置数据建模语言，它的目标是对netconf数据模型、操作进行建模，覆盖netconf协议的操作层和内容层，即用来建模由netconf协议、netconf远端过程调用(rpcs)、netconf通知(notification)操作的配置数据和状态数据。
[0095]
示例性的，标准《get-config》的yang模型定义如下：
[0096]
ietf-netconf.yang
[0097]
ietf-netconf-with-defaults.yang
[0098]
ietf-netconf-time.yang
[0099]
3、配置数据(configuration data)：将系统从其初始默认状态转换为当前状态所需的一组可写数据。
[0100]
4、表述性状态传递风格配置协议(representational state transfer configuration，restconf)：
[0101]
5、数据库(database，db)：是依照某种数据模型组织起来并存放二级存储器中的数据集合。这种数据集合具有如下特点：尽可能不重复，以最优方式为某个特定组织的多种应用服务，其数据结构独立于使用它的应用程序，对数据的增、删、改和检索由统一软件进行管理和控制。
[0102]
6、子树过滤(xml subtree filtering)：是一种允许应用程序选择特定xml子树的机制，以包含《rpc-reply》中的《get》或《get-config》操作。子树过滤器由零个或多个元素子树组成，表示过滤器选择标准。在子树内的每个容器级别，服务器对该兄弟节点集合进行
逻辑处理，以确定它的子树和根元素的路径是否包括在过滤器输出中。服务器在处理过程中不需要使用任何特定于数据模型的语义，从而实现简单而集中的实施策略。
[0103]
为了便于理解本技术实施例，作出以下几点说明：
[0104]
在本技术的各个实施例中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
[0105]
本技术中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b可以表示：单独存在a，同时存在a和b，单独存在b的情况。其中，a、b可以是单数或者复数。在本技术的文字描述中，字符“/”，一般表示前后关联对象是一种“或”的关系。
[0106]
在本技术中，“用于指示”可以包括用于直接指示和用于间接指示。当描述某一指示信息用于指示a时，可以包括该指示信息直接指示a或间接指示a，而并不代表该指示信息中一定携带有a。
[0107]
此外，具体的指示方式还可以是现有各种指示方式，例如但不限于，上述指示方式及其各种组合等。各种指示方式的具体细节可以参考现有技术，本文不再赘述。由上文所述可知，举例来说，当需要指示相同类型的多个信息时，可能会出现不同信息的指示方式不相同的情形。具体实现过程中，可以根据具体的需要选择所需的指示方式，本技术实施例对选择的指示方式不做限定，如此一来，本技术实施例涉及的指示方式应理解为涵盖可以使得待指示方获知待指示信息的各种方法。
[0108]
可以理解的是，在下文示出的实施例中“第一”、“第二”以及各种数字编号只是为了描述方便进行的区分，并不用来限制本技术实施例的范围。下文各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0109]
在本技术实施例中，“当
……
时”、“在
……
的情况下”、“若”以及“如果”等描述均指在某种客观情况下设备会做出相应的处理，并非是限定时间，且也不要求设备在实现时一定要有判断的动作，也不意味着存在其它限定。
[0110]
下面将结合附图详细说明本技术实施例提供的方法。
[0111]
图3是本技术实施例提供的一种数据配置的方法300的一例示意图，具体实现步骤包括：
[0112]
s310，网管设备向网元设备发送netconf中的配置获取请求消息。
[0113]
对应的，网元设备接收来自网管设备的netconf中的配置获取请求消息。
[0114]
其中，该配置获取请求消息携带第一配置变更标记，该配置获取请求消息用于请求获取网元设备存储的第一配置数据，该第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记。
[0115]
需要说明的是，本技术实施例主要适用于网管设备通过netconf管理网元设备的场景。
[0116]
示例性的，netconf中的配置获取请求消息可以是《get-config》。
[0117]
在本技术实施例中，该配置获取请求消息可以是在标准《get-config》请求消息的基础上增加第一配置变更标记进行扩展。也就是说，网管设备扩展标准的《get-config》的
yang模型定义，即在《get-config》报文中新增配置变更标记叶子节点。
[0118]
示例性的，扩展标准的《get-config》的yang模型定义如下：
[0119][0120][0121]
由上可知，在更新的yang模型中，《get-config》请求消息的输入input和输出output分别增加配置变更标记叶子节点，即将配置变更标记元素leaf change-sn添加到《get-config》中。相比当前网管设备和网元设备之间收发全部的配置数据，本技术技术方案通过较少的反馈量，即配置变更标记，能够减少信令开销和计算资源，提升网管设备与网络设备之间的配置数据的同步效率等。
[0122]
可选地，该第一配置变更标记可以是以下标记中的一种：配置变更流水号、信息摘要md5散列码、哈希校验码(hash)、循环冗余校验码crc校验码、配置时间戳等，本技术对此不作具体限定。
[0123]
对应的，网元设备反馈的响应消息中第二配置变更标记页可以是以下标记中的一种：配置变更流水号、信息摘要md5散列码、哈希校验码(hash)、循环冗余校验码crc校验码、配置时间戳等。
[0124]
需要说明的是，第一配置变更标记和第二配置变更标记是相同类型的配置变更标记。例如，第一配置变更标记是配置变更流水号
‘
123’。对应的，第二配置变更标记也可以是配置变更流水号
‘
123’或
‘
124’等。
[0125]
一种可能的实现方式，该第一配置变更标记为数据库对应的全局配置变更标记，该数据库包括多个数据配置表。
[0126]
另一种可能的实现方式，第一配置变更标记为第一数据配置表对应的配置变更标记，该第一数据配置表属于数据库，该数据库包括多个数据配置表，该多个数据配置表与多
个配置变更标记一一对应。
[0127]
示例性的，网管设备在发送netconf中的配置获取请求消息《get-config》之前，可以获取并保存网元设备的全局配置变更标记#1(例如，配置变更流水号)。
[0128]
以配置变更流水号为例，网元设备管理全局配置变更流水号，数据库对应1个全局配置变更流水号，即数据库可以包括多个数据配置表，多个数据配置表与多个配置变更流水号一一对应。按照数据配置表粒度，每个数据配置表对应1个配置变更流水号。当某个数据配置表的数据变更时，需要更新该数据配置表对应的配置变更流水号和整个数据库对应的全局配置变更流水号。
[0129]
需要说明的是，当第一配置变更标记为全局配置变更标记，且第一配置变更标记与第二配置变更标记相同时，说明两侧设备的数据库中的数据相同，无需进一步执行数据配置表的数据查询和对齐。反之，当第一配置变更标记为全局配置变更标记，且第一配置变更标记与第二配置变更标记不同时，说明两侧设备的数据库中的数据不同，需要进一步执行数据配置表的数据查询和对齐。即网管设备向网元设备发送配置获取请求消息，用于请求获取数据表#1对应的配置数据#1，并根据配置获取响应消息进一步比较和对齐数据表#1中的配置数据，依次查询，直至所有的数据配置表的数据完成同步。
[0130]
s320，网元设备向网管设备发送netconf中的配置获取响应消息。
[0131]
对应的，网管设备接收来自网元设备的netconf中的配置获取响应消息。
[0132]
其中，该配置获取响应消息包括第二配置变更标记，该第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
[0133]
作为示例而非限定，网元设备向网管设备发送netconf中的配置获取响应消息之前，网元设备可以根据第一配置变更标记和第二配置变更标记，确定第二配置数据和第一配置数据是否相同。
[0134]
需要说明的是，第二配置数据是在发送netconf中的配置获取请求消息《get-config》之前，网管设备已经保存的与第一配置变更标记对应的配置数据。
[0135]
示例性的，网元设备在接收到netconf中的配置获取请求消息《get-config》后，检查本地数据配置表对应的第一配置变更标记和接收的第二配置变更标记是否一致，进而确定网管设备的第二配置数据和网元设备的第一配置数据是否一致。
[0136]
具体地，如果网管设备下发的第一配置变更标记和网元设备本地存储的第一配置变更标记一致，表示网管设备存储的第二配置数据和网元设备存储的第一配置数据一致的，此时网元设备返回的响应消息中可以不携带配置数据；如果网管设备下发的第一配置变更标记和网元设备本地存储的第二配置变更标记不一致，表示网管设备存储的第二配置数据和网元设备存储的第一配置数据不一致，此时网元设备返回的响应消息中携带配置数据及其对应的配置变更标记，网管设备可以基于响应消息更新配置数据和配置变更标记。
[0137]
一种可能的实现方式，当网元设备根据第一配置变更标记和第二配置变更标记可以确定第二配置数据和第一配置数据相同时，那么说明第二配置变更标记和第一配置变更标记一致。那么，网元设备无需向网管设备发送第一配置数据。
[0138]
示例性的，网元设备本地存储的第二配置变更标记为
‘
123’，从网管设备接收的第一配置变更标记为
‘
123’，根据第一配置变更标记和第二配置变更标记相同可以确定第二配置数据和第一配置数据相同，网元设备可以反馈该配置变更标记
‘
123’，且不携带配置数
据。
[0139]
在该实现方式中，网元设备通过网管设备下发的第一配置变更标记和网元设备本地的第二配置变更标记一致，可以确定两侧设备的配置数据相同。那么，网元设备反馈的响应消息中可以不携带配置数据，通过较少的反馈量可以实现两侧设备配置数据的一致性。
[0140]
另一种可能的实现方式，当网元设备根据第一配置变更标记和第二配置变更标记可以确定第二配置数据和第一配置数据不相同时，那么说明第二配置变更标记和第一配置变更标记不一致。那么，网元设备向网管设备发送最新的配置数据(即，第一配置数据)，并返回与第一配置数据对应的配置变更标记(即，第二配置变更标记)。
[0141]
示例性的，网元设备本地存储的第二配置变更标记为
‘
123’，其对应的第一配置数据为
‘
data 1’，从网管设备接收的第一配置变更标记为
‘
124’，根据第一配置变更标记和第二配置变更标记不相同可以确定第二配置数据和第一配置数据不相同，网元设备可以反馈该第二配置变更标记
‘
123’，以及该配置变更标记对应的第一配置数据
‘
data 1’。
[0142]
在该实现方式中，网元设备通过网管设备下发的第一配置变更标记和网元设备本地的第二配置变更标记不一致，可以确定两侧设备的配置数据不同。那么，网元设备反馈的响应消息中携带第二配置变更标记及其对应的第一配置数据，用于网管设备进行配置数据的同步以及配置变更标记的更新，通过较少的反馈量可以实现两侧设备配置数据的一致性。
[0143]
作为示例而非限定，网管设备根据第二配置变更标记确定是否更新第二配置数据和第一配置变更标记。
[0144]
其中，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
[0145]
在该实现方式中，网管设备可以根据第二配置变更标记和本地配置变更标记(即第一配置变更标记)实现变更的配置数据的同步，减少计算资源和提升同步效率，最终保证网管设备和网元设备的配置数据一致。
[0146]
一种可能的实现方式，当第二配置变更标记与第一配置变更标记相同时，网管设备确定不更新第一配置变更标记和第二配置数据。
[0147]
示例性的，网管设备本地存储的第一配置变更标记为
‘
123’，从网元设备接收的第二配置变更标记为
‘
123’，且响应消息不包括配置数据，则说明第二配置数据和第一配置数据相同，网管设备也就无需进行配置数据同步。
[0148]
在该实现方式中，网管设备可以根据配置变更标记相同确定与网元设备的配置数据一致，实现通过较少的反馈量提升配置数据同步的效率。
[0149]
另一种可能的实现方式，当第二配置变更标记与第一配置变更标记不同时，网管设备确定更新第二配置数据和第一配置变更标记。
[0150]
具体地，网管设备将本地存储的第二配置数据更新为第一配置数据，并将本地存储的第一配置变更标记更新为第二配置变更标记。应理解，这里更新配置数据主要是指同步变化的配置数据。
[0151]
示例性的，网管设备本地存储的第一配置变更标记为
‘
124’，其对应的第二配置数据为
‘
data 2’，从网元设备接收的第二配置变更标记为
‘
123’，且响应消息携带第一配置数据为
‘
data 1’，根据第一配置变更标记和第二配置变更标记不相同可以确定第二配置数据和第一配置数据不相同，网管设备可以将第一配置变更标记更新为
‘
124’，并将第二配置数
据更新为第一配置数据
‘
data 1’，进而实现同步变化的配置数据，实现两侧设备的配置数据的一致性。
[0152]
在该实现方式中，网管设备在确定与网元设备侧的配置数据不同时，需要将本地配置变更标记和第一配置数据进行更新(同步变化的配置数据)，可以根据较少反馈量(即，第二配置变更标记)同步配置变化的数据，提升配置数据同步的效率，保证两侧设备的配置数据的一致性。
[0153]
需要说明的是，本技术实施例中，具体的更新第二配置数据和第一配置变更标记的方式可以参照现有流程，此处不再过多赘述。
[0154]
一种可能的实现方式，第一配置变更标记为数据库对应的全局配置变更标记，该数据库包括多个数据配置表。
[0155]
具体地，当网管设备在进行与网元设备的配置数据同步时，首先通过《get-config》查询整个数据库对应的全局配置变更流水号，如果全局配置变更流水号不变，说明网管设备的配置数据和网元设备的配置数据一致，即网管设备无需进行配置数据的同步；如果全局配置变更流水号发生变化，说明网管设备的配置数据和网元设备的配置数据不一致，即网管设备需要同步每一个数据配置表。
[0156]
示例性的，当网管设备同步网元设备的配置数据时，可以先下发查询全局配置变更标记#1，如果网元设备接收的全局配置变更标记#2和本地的全局配置变更标记#1一致，则可以说明网管设备和网元设备的配置数据一致，即网元设备可以不反馈配置数据，网管设备不需要同步网元设备的配置数据；如果网元设备接收的全局配置变更标记#2和本地的全局配置变更标记#1不一致，则网元设备需要反馈新的全局配置变更标记，网管设备需要针对全局配置变更标记对应的数据库中的每个数据配置表一一进行数据同步。
[0157]
即，网管设备重新下发《get-config》请求消息，并携带数据配置表#1对应的配置变更流水号，查询并同步网元设备的数据配置表#1对应的配置数据。在完成数据配置表#1的同步处理后，网管设备和网元设备之间继续进行下一个数据配置表对应的配置数据的同步。依次类推，直至将整个数据库对应的配置数据同步完毕即可。
[0158]
在该实现方式中，网元设备可以根据全局配置变更标记可以确定数据库中配置数据是否相同，并确定和反馈响应消息。网管设备则可以根据响应消息完成两侧设备的配置数据同步，同时可以减少信令开销和计算资源，提升配置数据的同步效率。
[0159]
另一种可能的实现方式，第一配置变更标记为第一数据配置表对应的配置变更标记，该第一数据配置表属于数据库，该数据库包括多个数据配置表，该多个数据配置表与多个配置变更标记一一对应。
[0160]
具体地，网管设备在同步某个数据配置表时，可以通过《get-config》携带该数据配置表对应的配置变更流水号，网元设备在接收《get-config》后，可以根据配置变更流水号确定对应的配置数据是否与网管设备的配置数据一致。如果确定两侧设备的配置数据一致，则向网管设备返回空数据包；如果确定两侧设备的配置数据不一致，则向网管设备发送配置变更流水号对应的配置数据。
[0161]
可选地，如果网管设备需要强制同步网元设备的配置数据，《get-config》请求消息中携带配置变更流水号，或者网管设备在第一次《get-config》请求消息中携带配置变更流水号
‘0’
，网元设备返回配置数据表对应的全部配置数据。
[0162]
综上所述，本技术提供的技术方案，网管设备增广《get-config》请求消息，即新增配置变更标记叶子节点。通过在请求消息和响应消息中分别携带配置变更标记，实现同步变化的配置数据。相比当前网管设备和网元设备之间收发和配置全部的数据，本技术技术方案通过较少的反馈量，能够减少信令开销和计算资源，提升网管设备与网络设备之间的配置数据同步的效率和性能，进而保证网管设备和网元设备的配置数据的一致性。
[0163]
图4是适用本技术的一种数据配置的方法400的一例的示意图。在该实现方式，通过查询网管设备和网元设备的全局配置变更流水号来确定两侧设备的数据库的配置数据是否一致，进而保证两侧设备配置数据的同步。如图4所示，具体实现步骤包括：
[0164]
s410，网管设备向网元设备发送《get-config》请求消息。
[0165]
对应的，网元设备接收来自网管设备的《get-config》请求消息。
[0166]
其中，该《get-config》请求消息用于请求获取网元设备的配置数据#1，该《get-config》请求消息携带全局配置变更流水号#1，该全局配置变更流水号#1是网管设备存储的与配置数据#1对应的配置变更流水号。
[0167]
在该实现方式中，该《get-config》请求消息携带全局配置变更流水号#1，因此可以不携带子树过滤条件。
[0168]
需要说明的是，网管设备在发送《get-config》请求消息之前，可以获取网元设备的全局配置变更流水号#1。
[0169]
应理解，网元设备管理全局配置变更流水号，数据库对应1个全局配置变更流水号，即数据库可以包括多个数据配置表，多个数据配置表与多个配置变更流水号一一对应。按照数据配置表粒度，每个数据配置表对应1个配置变更流水号。当某个数据配置表的数据变更时，需要更新该数据配置表对应的配置变更流水号和整个数据库对应的全局配置变更流水号。
[0170]
在本技术实施例中，《get-config》请求消息是在标准《get-config》请求消息的基础上增加全局配置变更流水号#1进行扩展，具体可参见方法300中的实现方式，此处不再过多赘述。
[0171]
示例性的，《get-config》请求消息的标识为"102"，其携带的全局配置变更流水号#1为"123"，网管设备的请求报文如下所示：
[0172][0173]
需要说明的是，以上配置变更标记为全局配置变更流水号仅是示例性说明，不应构成对本技术技术方案的任何限定。
[0174]
可选地，该《get-config》请求消息还可以携带以下配置变更标记中的一种：md5散
列码、哈希校验码、循环冗余校验码crc校验码、配置时间戳等，本技术对此不作具体限定。
[0175]
s420，网元设备根据全局配置变更流水号#1确定配置数据#2和配置数据#1是否一致。
[0176]
需要说明的是，配置数据#2是在发送《get-config》请求消息之前，网管设备已经保存的与全局配置变更流水号#1对应的配置数据。
[0177]
示例性的，网络设备在接收到《get-config》请求消息后，检查本地数据配置表对应的全局配置变更流水号#2和接收的全局配置变更流水号#1是否一致，进而确定网管设备的配置数据#2和网元设备的配置数据#1是否一致。
[0178]
s430，网元设备向网管设备发送《get-config》响应消息。
[0179]
对应的，网管设备接收来自网元设备的《get-config》响应消息。
[0180]
其中，该《get-config》响应消息携带配置变更流水号#2，该配置变更流水号#2是网元设备存储的与配置数据#1对应的配置变更流水号。
[0181]
一种可能的实现方式，当网元设备在步骤s420中确定网管设备的配置数据#2和网元设备的配置数据#1一致时，那么说明网元设备发送的全局配置变更流水号#2和网元设备接收的全局配置变更流水号#1相同，此时，网元设备返回数据为空。
[0182]
示例性的，《get-config》响应消息的标识为"103"，其携带的全局配置变更流水号#2为"123"，网元设备的响应报文如下所示：
[0183][0184][0185]
另一种可能的实现方式，当网元设备在步骤s420中确定网管设备的配置数据#2和网元设备的配置数据#1不一致时，那么说明网元设备发送的全局配置变更流水号#2和网元设备接收的全局配置变更流水号#1不同，此时，网元设备返回数据不为空，即《get-config》响应消息中还包括配置数据#1。
[0186]
示例性的，《get-config》响应消息的标识为"104"，其携带的全局配置变更流水号#2为"234"，网元设备的响应报文如下所示：
[0187][0188]
s440，网管设备根据《get-config》响应消息确定是否更新配置数据#2和全局配置变更流水号#1。
[0189]
其中，配置数据#2是网管设备存储的与全局配置变更流水号#1对应的配置数据。
[0190]
示例性的，网管设备确定《get-config》响应消息中的全局配置变更流水号#2与本地全局配置变更流水号#1是否一致。
[0191]
一种可能的实现方式，如果全局配置变更流水号没有发生变化，即在步骤s430中网元设备反馈的全局配置变更流水号#2与全局配置变更流水号#1一致。那么，网管设备无需同步该网元设备的配置数据，也就是说，网管设备无需更新配置数据#2；如果全局配置变更流水号发生变化，即在步骤s430中网元设备反馈的全局配置变更流水号#2与全局配置变更流水号#1不一致。那么，网管设备需要同步该网元设备的配置数据。即网管设备需将配置数据#2更新为配置数据#1。同时，将配置变更流水号#1更新为配置变更流水号#2。
[0192]
其中，针对全局配置变更流水号#2与全局配置变更流水号#1不一致的情况，网管设备需要重新向网元设备发送《get-config》请求消息，该《get-config》请求消息中携带数据配置表#1对应的配置变更流水号#11，用于查询网络设备存储的该数据配置表#1中的配置数据。应理解，数据配置表#1是全局配置变更流水号#1对应的数据库中的数据配置表。具体实现方式与上述类似，为了简洁，此处不再赘述。
[0193]
需要说明的是，本技术实施例中，更新配置数据#2和全局配置变更流水号#1的具
体实现方式可以参照现有流程，此处不再过多赘述。
[0194]
应理解，在完成上述数据配置表#1的同步处理后，网管设备和网元设备之间继续进行下一个数据配置表对应的配置数据的同步。具体实现方式类似，为了简洁此处不再赘述，直至数据库中所有的配置数据表完全同步即可。
[0195]
在该实现方式中，通过在请求消息和响应消息中携带全局变更流水号，实现同步配置变化的数据，通过减少反馈量降低信令开销和计算资源，提升同步效率和性能，保证网管设备和网元设备之间配置数据的一致性。
[0196]
图5是适用本技术的一种数据配置的方法500的一例的示意图。在该实现方式，通过查询网管设备和网元设备的配置变更流水号来确定两侧设备的数据库的配置数据是否一致，进而保证两侧设备配置数据的同步。如图5所示，具体实现步骤包括
[0197]
s510，网管设备向网元设备发送《get-config》请求消息。
[0198]
对应的，网元设备接收来自网管设备的《get-config》请求消息。
[0199]
其中，该《get-config》请求消息用于请求获取网元设备的配置数据#a，该《get-config》请求消息携带配置变更流水号#a和子树过滤条件，该配置变更流水号#a是网管设备存储的与配置数据#a对应的配置变更流水号。
[0200]
需要说明的是，网管设备在发送《get-config》请求消息之前，可以获取网元设备的全局配置变更流水号。例如，全局配置变更流水号中包括配置变更流水号#a。
[0201]
在本技术实施例中，《get-config》请求消息是在标准《get-config》请求消息的基础上增加配置变更流水号#a进行扩展，具体可参见方法300中的实现方式，此处不再过多赘述。
[0202]
示例性的，《get-config》请求消息的标识为"102"，其携带的配置变更流水号#a为"6"，网管设备的请求报文如下所示：
[0203][0204][0205]
需要说明的是，以上配置变更标记为配置变更流水号仅是示例性说明，不应构成对本技术技术方案的任何限定。
[0206]
可选地，该《get-config》请求消息还可以携带以下配置变更标记中的一种：md5散
列码、哈希校验码(hash)、循环冗余校验码crc校验码、配置时间戳等，本技术对此不作具体限定。
[0207]
s520，网元设备根据配置变更流水号#a确定配置数据#b和配置数据#a是否一致。
[0208]
需要说明的是，配置数据#b是在发送《get-config》请求消息之前，网管设备已经保存的与配置变更流水号#a对应的配置数据。
[0209]
示例性的，网络设备在接收到《get-config》请求消息后，检查本地数据配置表对应的配置变更流水号#a和接收的配置变更流水号#b是否一致，进而确定网管设备的配置数据#b和网元设备的配置数据#a是否一致。
[0210]
s530，网元设备向网管设备发送《get-config》响应消息。
[0211]
对应的，网管设备接收来自网元设备的《get-config》响应消息。
[0212]
其中，该《get-config》响应消息携带配置变更流水号#b，该配置变更流水号#b是网元设备存储的与配置数据#a对应的配置变更流水号。
[0213]
一种可能的实现方式，当网元设备在步骤s520中确定网管设备的配置数据#b和网元设备的配置数据#1一致时，那么说明网元设备发送的配置变更流水号#b和网元设备接收的配置变更流水号#a相同，此时，网元设备返回数据为空。
[0214]
示例性的，《get-config》响应消息的标识为"103"，其携带的配置变更流水号#b为"6"，网元设备的响应报文如下所示：
[0215][0216]
另一种可能的实现方式，当网元设备在步骤s520中确定网管设备的配置数据#b和网元设备的配置数据#a不一致时，那么说明网元设备发送的配置变更流水号#b和网元设备接收的配置变更流水号#a不同，此时，网元设备返回数据不为空，即《get-config》响应消息中还包括配置数据#a。
[0217]
示例性的，《get-config》响应消息的标识为"104"，其携带的配置变更流水号#b为"8"，网元设备的响应报文如下所示：
[0218]
[0219][0220]
s540，网管设备根据《get-config》响应消息确定是否更新配置数据#b和配置变更流水号#a。
[0221]
其中，配置数据#b是网管设备存储的与配置变更流水号#a对应的配置数据。
[0222]
示例性的，网管设备根据《get-config》响应消息中的配置变更流水号#b与本地配置变更流水号是否一致。
[0223]
一种可能的实现方式，如果配置变更流水号没有发生变化，即在步骤s530中网元设备反馈的配置变更流水号#b与配置变更流水号#a一致。那么，网管设备无需同步该网元设备的配置数据，也就是说，网管设备无需更新配置数据#b。
[0224]
另一种可能的实现方式，如果配置变更流水号发生变化，即在步骤s530中网元设备反馈的配置变更流水号#b与配置变更流水号#a不一致。那么，网管设备需要同步该网元设备的配置数据。即网管设备需将配置数据#b更新为配置数据#a。同时，将配置变更流水号#a更新为配置变更流水号#b。
[0225]
需要说明的是，本技术实施例中，更新配置数据#b和配置变更流水号#a的具体实现方式可以参照现有流程，此处不再过多赘述。应理解，该实现方式可以理解为在上述方法400中全局配置变更查询和同步的基础上，进一步针对数据库中的某一数据配置表的查询和同步的实现方式。在完成上述数据配置表的同步处理后，网管设备和网元设备之间继续进行下一个数据表同步。具体实现方式类似，为了简洁此处不再赘述，直至数据库的全部配置数据表完全同步即可。
[0226]
综上所述，通过在请求消息和响应消息中携带全局变更流水号，实现同步配置变化的数据，通过减少反馈量降低信令开销和计算资源，提升同步效率和性能，保证网管设备
和网元设备之间配置数据的一致性。
[0227]
图6是适用本技术的一种数据配置的方法600的一例的示意图。在该实现方式，通过查询网管设备和网元设备的配置变更流水号来确定两侧数据库的配置数据是否一致，进而保证配置数据的同步。如图6所示，具体实现步骤包括：
[0228]
s610，网管设备向网元设备发送《get-config》请求消息。
[0229]
对应的，网元设备接收来自网管设备的《get-config》请求消息。
[0230]
其中，该《get-config》请求消息用于请求获取网元设备的配置数据#a，该《get-config》请求消息携带配置变更流水号#a为0。
[0231]
需要说明的是，当网管设备的数据配置表对应的初始配置变更流水号为0，网管设备在发送第一次《get-config》请求消息时可以携带的配置变更流水号为0。
[0232]
可选地，如果网管设备需要强制同步网元设备的数据配置表中的配置数据，可以在《get-config》请求消息中携带配置变更流水号为0，或者《get-config》中可以不携带配置变更流水号，网元设备返回配置数据表的配置数据。
[0233]
需要说明的是，网管设备在发送《get-config》请求消息之前，可以获取网元设备的全局配置变更流水号。例如，全局配置变更流水号中包括配置变更流水号#a。
[0234]
在本技术实施例中，《get-config》请求消息是在标准《get-config》请求消息的基础上增加配置变更流水号#a进行扩展，具体可参见方法300中的实现方式，此处不再过多赘述。
[0235]
示例性的，《get-config》请求消息的标识为"102"，其携带的配置变更流水号#a为"0"，网管设备的请求报文如下所示：
[0236][0237]
需要说明的是，以上配置变更标记为配置变更流水号仅是示例性说明，不应构成对本技术技术方案的任何限定。
[0238]
可选地，该《get-config》请求消息还可以携带以下配置变更标记中的一种：md5散列码、哈希校验码(hash)、循环冗余校验码crc校验码、配置时间戳等，本技术对此不作具体限定。
[0239]
s620，网元设备根据配置变更流水号#a确定配置数据#b和配置数据#a是否一致。
[0240]
需要说明的是，配置数据#b是在发送《get-config》请求消息之前，网管设备已经保存的与配置变更流水号#a对应的配置数据。
[0241]
示例性的，网络设备在接收到《get-config》请求消息后，检查本地数据配置表对应的配置变更流水号#a和接收的配置变更流水号#b是否一致，进而确定网管设备的配置数据#b和网元设备的配置数据#a是否一致。
[0242]
s630，网元设备向网管设备发送《get-config》响应消息。
[0243]
对应的，网管设备接收来自网元设备的《get-config》响应消息。
[0244]
其中，该《get-config》响应消息携带配置变更流水号#b，该配置变更流水号#b是网元设备存储的与配置数据#a对应的配置变更流水号。
[0245]
一种可能的实现方式，当网元设备在步骤s620中确定网管设备的配置数据#b和网元设备的配置数据#a一致时，那么说明网元设备发送的配置变更流水号#b和网元设备接收的配置变更流水号#a相同，此时，网元设备返回数据为空。
[0246]
示例性的，《get-config》响应消息的标识为"103"，其携带的配置变更流水号#2为"123"，网元设备的响应报文如下所示：
[0247][0248]
另一种可能的实现方式，当网元设备在步骤s620中确定网管设备的配置数据#b和网元设备的配置数据#a不一致时，那么说明网元设备发送的配置变更流水号#b和网元设备接收的配置变更流水号#a不同，此时，网元设备返回数据不为空，即《get-config》响应消息中还包括配置数据#a。
[0249]
示例性的，《get-config》响应消息的标识为"104"，其携带的配置变更流水号#b为"6"，网元设备的响应报文如下所示：
[0250][0251][0252]
s640，网管设备根据《get-config》响应消息确定是否更新配置数据#b和配置变更流水号#a。
[0253]
其中，配置数据#b是网管设备存储的与配置变更流水号#a对应的配置数据。
[0254]
示例性的，网管设备确定《get-config》响应消息中的配置变更流水号#b与本地配置变更流水号是否一致。
[0255]
一种可能的实现方式，如果配置变更流水号没有发生变化，即在步骤s630中网元设备反馈的配置变更流水号#b与配置变更流水号#a一致。那么，网管设备无需同步该网元设备的配置数据，也就是说，网管设备无需更新配置数据#b。
[0256]
另一种可能的实现方式，如果配置变更流水号发生变化，即在步骤s630中网元设备反馈的配置变更流水号#b与配置变更流水号#a不一致。那么，网管设备需要同步该网元设备的配置数据。即网管设备需将配置数据#b更新为配置数据#a。同时，将配置变更流水号#a更新为配置变更流水号#b。
[0257]
需要说明的是，本技术实施例中，更新配置数据#b和配置变更流水号#a的具体实现方式可以参照现有流程，此处不再过多赘述。
[0258]
应理解，该实现方式可以理解为在上述方法400中全局配置变更查询和同步的基础上，进一步针对数据库中的某一数据配置表的查询和同步的实现方式。在完成上述数据
配置表的同步处理后，网管设备和网元设备之间继续进行下一个数据表同步。具体实现方式类似，为了简洁此处不再赘述，直至数据库的全部配置数据表完全同步即可。
[0259]
综上所述，通过在请求消息和响应消息中携带全局变更流水号，实现同步配置变化的数据，通过减少反馈量降低信令开销和计算资源，提升同步效率和性能，保证网管设备和网元设备之间配置数据的一致性。
[0260]
需要说明的是，本技术技术方案还适用于网管设备正常维护网元设备，以及新增业务配置表等场景，可以在不修改业务的yang模型的情况下，提升配置数据的查询效率和同步效率。
[0261]
还需要说明的是，本方案同样适用于在网管通过restconf/yang管理设备的场景，本方案也可以适用于中间代理设备通过netconf/yang，restconf/yang同步下级设备配置数据的场景。本技术对此不作具体限定。
[0262]
总之，本技术提供了一种数据配置方法和装置，网管设备增广《get-config》请求消息，即新增配置变更标记叶子节点。通过在请求消息和响应消息中分别携带配置变更标记，可以同步配置变化的数据。本技术技术方案通过较少的反馈量，能够减少信令开销和计算资源，提升网管设备与网络设备之间的配置数据的同步效率和性能，保证网管设备和网元设备的配置数据的一致性。
[0263]
上文结合图1至图6，详细描述了本技术数据配置的方法的实施例，下面将结合图7和图8，详细描述本技术数据配置的装置的实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
[0264]
图7是本技术实施例提供的数据配置的装置的一例示意图。如图7所示，该装置1000可以包括处理单元1100和收发单元1200。
[0265]
可选地，该装置1000可对应于上文方法实施例中的网管设备，例如，可以为网管设备，或者配置于网管设备中的部件(如电路、芯片或芯片系统等)。
[0266]
示例性的，收发单元1200，用于网管设备向网元设备发送网络配置协议netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；
[0267]
收发单元1200，用于网管设备接收来自网元设备的netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
[0268]
可选地，处理单元1100，用于网管设备根据第二配置变更标记确定是否更新第一配置变更标记和第二配置数据，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
[0269]
应理解，该装置1000可对应于根据本技术实施例的方法中的网管设备，该装置1000可以包括用于执行本技术实施例的方法中网管设备执行的方法的单元。并且，该装置1000中的各单元和上述其它操作和/或功能分别为了实现本技术实施例的方法的相应流程。
[0270]
还应理解，该装置1000为网管设备时，该装置1000中的收发单元1200可以通过收发器实现，例如可对应于图8中示出的装置2000中的收发器2020，该装置1000中的处理单元
1100可通过至少一个处理器实现，例如可对应于图8中示出的装置2000中的处理器2010。
[0271]
还应理解，该装置1000为配置于网管设备中的芯片或芯片系统时，该装置1000中的收发单元1200可以通过输入/输出接口、电路等实现，该装置1000中的处理单元1100可以通过该芯片或芯片系统上集成的处理器、微处理器或集成电路等实现。
[0272]
可选地，该装置1000可对应于上文方法实施例中的网元设备，例如，可以为网元设备，或者配置于网元设备中的部件(如电路、芯片或芯片系统等)。
[0273]
示例性的，收发单元1200，用于网元设备接收来自网管设备的网络配置协议netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；
[0274]
收发单元1200，还用于网元设备向网管设备发送netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
[0275]
可选地，处理单元1100，用于网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据是否相同，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
[0276]
应理解，该装置1000可对应于根据本技术实施例的方法中的网元设备，该装置1000可以包括用于执行本技术实施例的方法中网元设备执行的方法的单元。并且，该装置1000中的各单元和上述其它操作和/或功能分别为了实现本技术实施例的方法的相应流程。
[0277]
还应理解，该装置1000为网元设备时，该装置1000中的收发单元1200可以通过收发器实现，例如可对应于图8中示出的装置2000中的收发器2020，该装置1000中的处理单元1100可通过至少一个处理器实现，例如可对应于图8中示出的装置2000中的处理器2010。
[0278]
还应理解，该装置1000为配置于网元设备中的芯片或芯片系统时，该装置1000中的收发单元1200可以通过输入/输出接口、电路等实现，该装置1000中的处理单元1100可以通过该芯片或芯片系统上集成的处理器、微处理器或集成电路等实现。
[0279]
图8是本技术实施例提供的数据配置的装置的另一例示意图。如图8所示，该装置2000包括处理器2010、收发器2020和存储器2030。其中，处理器2010、收发器2020和存储器2030通过内部连接通路互相通信，该存储器2030用于存储指令，该处理器2010用于执行该存储器2030存储的指令，以控制该收发器2020发送信号和/或接收信号。
[0280]
应理解，该装置2000可以对应于上述方法实施例中的网管设备/网元设备，并且可以用于执行上述方法实施例中网管设备/网元设备执行的各个步骤和/或流程。可选地，该存储器2030可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。存储器2030可以是一个单独的器件，也可以集成在处理器2010中。该处理器2010可以用于执行存储器2030中存储的指令，并且当该处理器2010执行存储器中存储的指令时，该处理器2010用于执行上述与网管设备/网元设备对应的方法实施例的各个步骤和/或流程。
[0281]
可选地，该装置2000是前文实施例中的网管设备。
[0282]
示例性的，收发器2020，用于网管设备向网元设备发送网络配置协议netconf中的
配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；
[0283]
收发器2020，还用于网管设备接收来自网元设备的netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
[0284]
可选地，处理器2010，用于网管设备根据第二配置变更标记确定是否更新第一配置变更标记和第二配置数据，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
[0285]
可选地，该装置2000是前文实施例中的网元设备。
[0286]
示例性的，收发器2020，用于网元设备接收来自网管设备的网络配置协议netconf中的配置获取请求消息，该配置获取请求消息用于请求获取第一配置数据，请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；
[0287]
收发器2020，还用于网元设备向网管设备发送netconf中的配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。
[0288]
可选地，处理器2010，用于网元设备根据第一配置变更标记和第二配置变更标记确定第二配置数据与第一配置数据是否相同，第二配置数据是网管设备存储的与第一配置变更标记对应的配置数据。
[0289]
其中，收发器2020可以包括发射机和接收机。该处理器2010和存储器2030与收发器2020可以是集成在不同芯片上的器件。如，处理器2010和存储器2030可以集成在基带芯片中，收发器2020可以集成在射频芯片中。该处理器2010和存储器2030与收发器2020也可以是集成在同一个芯片上的器件。本技术对此不作限定。
[0290]
可选地，该装置2000是配置在网管设备/网元设备中的部件，如电路、芯片、芯片系统等。
[0291]
其中，收发器2020也可以是通信接口，如输入/输出接口、电路等。该收发器2020与处理器2010和存储器2020都可以集成在同一个芯片中，如集成在基带芯片中。
[0292]
应理解，本技术实施例中的具体的例子只是为了帮助本领域技术人员更好地理解本技术的技术方案，上述具体实现方式可以认为是本技术最优的实现方式，而非限制本技术实施例的范围。
[0293]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0294]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0295]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以
通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0296]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0297]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0298]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0299]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。

技术特征：
1.一种数据配置的方法，其特征在于，所述方法包括：网管设备向网元设备发送网络配置协议netconf中的配置获取请求消息，所述配置获取请求消息用于请求获取第一配置数据，所述配置获取请求消息包括第一配置变更标记，所述第一配置变更标记是所述网管设备存储的与所述第一配置数据对应的配置变更标记；所述网管设备接收来自所述网元设备的netconf中的配置获取响应消息，所述配置获取响应消息包括第二配置变更标记，所述第二配置变更标记是所述网元设备存储的与所述第一配置数据对应的配置变更标记。2.根据权利要求1所述的方法，其特征在于，所述方法还包括：所述网管设备根据所述第二配置变更标记确定是否更新所述第一配置变更标记和第二配置数据，所述第二配置数据是所述网管设备存储的与所述第一配置变更标记对应的配置数据。3.根据权利要求2所述的方法，其特征在于，所述网管设备根据所述第二配置变更标记确定是否更新所述第一配置变更标记和第二配置数据，包括：当所述第二配置变更标记与所述第一配置变更标记不同时，所述网管设备确定更新所述第一配置变更标记和所述第二配置数据。4.根据权利要求3所述的方法，其特征在于，所述配置获取响应消息还包括所述第一配置数据，所述方法还包括：所述网管设备将所述第一配置变更标记更新为所述第二配置变更标记，以及将所述第二配置数据更新为所述第一配置数据。5.根据权利要求2至4中任一项所述的方法，其特征在于，所述网管设备根据所述第二配置变更标记确定是否更新所述第一配置变更标记和第二配置数据，包括：当所述第二配置变更标记与所述第一配置变更标记相同时，所述网管设备确定不更新所述第一配置变更标记和所述第二配置数据。6.一种数据配置的方法，其特征在于，所述方法包括：网元设备接收来自网管设备的网络配置协议netconf中的配置获取请求消息，所述配置获取请求消息用于请求获取第一配置数据，所述配置获取请求消息包括第一配置变更标记，所述第一配置变更标记是所述网管设备存储的与所述第一配置数据对应的配置变更标记；所述网元设备向所述网管设备发送netconf中的配置获取响应消息，所述配置获取响应消息包括第二配置变更标记，所述第二配置变更标记是所述网元设备存储的与所述第一配置数据对应的配置变更标记。7.根据权利要求6所述的方法，其特征在于，所述方法还包括：所述网元设备根据所述第一配置变更标记和所述第二配置变更标记确定第二配置数据与所述第一配置数据是否相同，所述第二配置数据是所述网管设备存储的与所述第一配置变更标记对应的配置数据。8.根据权利要求7所述的方法，其特征在于，当所述网元设备根据所述第一配置变更标记和所述第二配置变更标记确定所述第二配置数据与所述第一配置数据不同时，所述第二配置变更标记与所述第一配置变更标记不同，且所述配置获取响应消息还包括所述第一配置数据。
9.根据权利要求7或8所述的方法，其特征在于，当所述网元设备根据所述第一配置变更标记和所述第二配置变更标记确定所述第二配置数据与所述第一配置数据相同时，所述第二配置变更标记与所述第一配置变更标记相同。10.一种数据配置的装置，其特征在于，包括：收发单元，用于网管设备向网元设备发送网络配置协议netconf中的配置获取请求消息，所述配置获取请求消息用于请求获取第一配置数据，所述配置获取请求消息包括第一配置变更标记，所述第一配置变更标记是所述网管设备存储的与所述第一配置数据对应的配置变更标记；所述收发单元，还用于所述网管设备接收来自所述网元设备的netconf中的配置获取响应消息，所述中的配置获取响应消息包括第二配置变更标记，所述第二配置变更标记是所述网元设备存储的与所述第一配置数据对应的配置变更标记。11.根据权利要求10所述的装置，其特征在于，还包括：处理单元，用于所述网管设备根据所述第二配置变更标记确定是否更新所述第一配置变更标记和第二配置数据，所述第二配置数据是所述网管设备存储的与所述第一配置变更标记对应的配置数据。12.根据权利要求11所述的装置，其特征在于，所述处理单元，还用于当所述第二配置变更标记与所述第一配置变更标记不同时，所述网管设备确定更新所述第一配置变更标记和所述第二配置数据。13.根据权利要求12所述的装置，其特征在于，所述配置获取响应消息还包括所述第一配置数据，所述处理单元，还用于：所述网管设备将所述第一配置变更标记更新为所述第二配置变更标记，以及将所述第二配置数据更新为所述第一配置数据。14.根据权利要求11至13中任一项所述的装置，其特征在于，所述处理单元，还用于当所述第二配置变更标记与所述第一配置变更标记相同时，所述网管设备确定不更新所述第一配置变更标记和所述第二配置数据。15.一种数据配置的装置，其特征在于，包括：收发单元，用于网元设备接收来自网管设备的网络配置协议netconf中的配置获取请求消息，所述配置获取请求消息用于请求获取第一配置数据，所述配置获取请求消息包括第一配置变更标记，所述第一配置变更标记是所述网管设备存储的与所述第一配置数据对应的配置变更标记；所述收发单元，还用于所述网元设备向所述网管设备发送netconf中的配置获取响应消息，所述中的配置获取响应消息包括第二配置变更标记，所述第二配置变更标记是所述网元设备存储的与所述第一配置数据对应的配置变更标记。16.根据权利要求15所述的装置，其特征在于，包括：处理单元，用于所述网元设备根据所述第一配置变更标记和所述第二配置变更标记确定第二配置数据与所述第一配置数据是否相同，所述第二配置数据是所述网管设备存储的与所述第一配置变更标记对应的配置数据。17.根据权利要求16所述的装置，其特征在于，
当所述网元设备根据所述第一配置变更标记和所述第二配置变更标记确定所述第二配置数据与所述第一配置数据不同时，所述第二配置变更标记与所述第一配置变更标记不同，且所述配置获取响应消息还包括所述第一配置数据。18.根据权利要求16所述的装置，其特征在于，当所述网元设备根据所述第一配置变更标记和所述第二配置变更标记确定所述第二配置数据与所述第一配置数据相同时，所述第二配置变更标记与所述第一配置变更标记相同。19.一种通信装置，其特征在于，包括：处理器和接口电路，所述接口电路用于接收来自所述通信装置之外的其它通信装置的信号并传输至所述处理器或将来自所述处理器的信号发送给所述通信装置之外的其它通信装置，所述处理器通过逻辑电路或执行代码指令用于所述通信装置作为网管设备实现如权利要求1至5中任一项所述的方法，以及用于所述通信装置作为网元设备实现如权利要求6至9中任一项所述的方法。20.一种通信系统，其特征在于，包括：如权利要求10至18中任一项或19所述的通信装置。

技术总结
本申请实施例提供了一种数据配置的方法，包括：网管设备发送网络配置协议Netconf中的配置获取请求消息，用于请求获取第一配置数据，该配置获取请求消息包括第一配置变更标记，第一配置变更标记是网管设备存储的与第一配置数据对应的配置变更标记；网管设备接收配置获取响应消息，该配置获取响应消息包括第二配置变更标记，第二配置变更标记是网元设备存储的与第一配置数据对应的配置变更标记。该方法在配置获取请求消息中新增配置变更标记叶子节点，即分别在配置获取请求消息和配置获取响应消息中携带配置变更标记，以实现同步配置变化的数据。通过较少的反馈量，能够减少信令开销和计算资源，提升网管设备与网络设备之间的同步效率等。的同步效率等。的同步效率等。


技术研发人员：史曙光
受保护的技术使用者：华为技术有限公司
技术研发日：2022.01.30
技术公布日：2023/8/9