CN101442469A

CN101442469A - 下发配置数据的方法、系统及装置

Info

Publication number: CN101442469A
Application number: CNA2007101779304A
Authority: CN
Inventors: 冯瑞军; 刘涛; 吴兴耀; 张晨; 徐海东; 魏丽红
Original assignee: China Mobile Communications Group Co Ltd
Current assignee: China Mobile Communications Group Co Ltd
Priority date: 2007-11-22
Filing date: 2007-11-22
Publication date: 2009-05-27
Anticipated expiration: 2027-11-22
Also published as: CN101442469B

Abstract

本发明公开了一种下发配置数据的方法，该方法包括：将配置命令下发至执行虚拟专用网业务的设备，该配置命令中包含按照设定顺序排列的配置数据；所述设备接收所述配置数据，分别将该配置数据作为按照相同顺序排列的业务对应的设置参数。通过本发明，解决了设备差异化带来的网管数据模型差异化的问题，使配置管理过程更加简便。本发明还公开了一种下发配置数据的系统、一种配置服务器和一种执行VPN业务的设备。

Description

下发配置数据的方法、系统及装置

技术领域

本发明涉及通信领域的数据传输技术，尤其涉及一种下发配置数据的方法、系统及装置。

背景技术

基于运营商网络的虚拟专用网(Provider Provisioned Virtual PrivateNetwork，PP-VPN)的快速发展，使得以运营商网络为主体的虚拟专用网(VirtualPrivate Network，VPN)业务成为此领域内的发展方向。其主要的实现技术为3层多协议标签交换(Multi-Protocol Label Switch，MPLS)VPN，它遵循RFC2547标准，使用边界网关协议(Border Gateway Protocol，BGP)在提供者边界路由器(Provider′s edge router，PE)之间分发路由信息，使用MPLS技术在VPN站点之间传送数据，因而又称为BGP/MPLS VPN。

BGP/MPLS VPN业务快速发展的同时，由于运营商的承载网络中路由器设备的数量庞大、来源不统一(不同的设备提供商)和配置命令差异化等因素，都为BGP/MPLS VPN业务的配置管理带来在诸多的不便。

在目前的网络运营中，运营商的网络维护人员在承载网络中使用的是IETF定义的简单网络管理协议(Simple Network Management Protocol，SNMP)接口或命令行接口，来实现基本的网络管理操作。

对于SNMP接口而言，接口固有的业务管理能力无法满足业务统一配置下发的需求，原因如下：

(1)、由于配置操作过程中需要对相应的管理信息库(ManagementInformation Base，MIB)叶节点进行设置(Set)操作，而MIB叶节点又存在庞大的树形结构，因此，对MIB叶节点操作需要输入复杂的点数节点符号。

(2)、不同设备生产厂商使用的是自己定义的私有MIB，这更增加了统一、集中配置的难度。

(3)、SNMP无法直接使用分级的数据结构和类型；无法完成配置任务需要各种高层的管理操作，诸如下载、激活、回退和重载等；SNMP协议本身不支持事务机制，无法完成交互操作过程。

基于上述三个原因，使得在使用SNMP接口的过程中，需要进行大量的配置操作、过程复杂、很难实现集中配置；并且SNMP自身的缺陷，使得一些交互操作无法实现。

命令行接口可以完成SNMP无法完成的配置过程，并且也是目前业务配置的主要手段，以BGP/MPLS VPN业务配置为例，在配置过程中网络管理维护人员需要针对VPN业务传输路径中的各个PE路由器分别通过命令行接口进行相应的配置工作。由于不同厂商设备命令的差异以及配置命令的先后次序的严格要求，在VPN传输路径中多台路由器设备的重复性配置操作很可能造成配置的错误，从而凭空增添了网络维护的复杂度，同时影响业务的顺利开通和应用。

在相关配置管理技术中，IETF组织提出了基于可扩展标记语言(ExtensibleMarkup Language，XML)的用于配置管理的网络配置协议(Netconf)，参见RFC4741～RFC4744。目前规范中虽然对协议的指令集合以及承载方式提供了解决方案，但是在具体业务的配置方面仍存在以下的缺陷和问题：

(1)、缺乏相应的数据模型来描述配置数据，即没有针对VPN业务的配置数据的分层数据结构；

(2)、在目前网络运营中，多接口并存的环境下如何引入此管理接口保证多接口的适配实现对设备的配置数据下发，从运营商的角度来看其具体的应用方式和网络管理架构如何，也是一个悬而未决的问题。

(3)、Netconf协议虽然提供了配置撤销的原语操作，但是这种操作仅仅针对当前的配置设备。由于VPN业务配置过程中PE路由器的配置总是成对出现的，同时为了减少配置故障的发生概率，需要对VPN链路中成对出现的PE同时进行撤销操作，Netconf协议本身的配置撤销机制无法满足这种需求。

发明内容

本发明实施例提供一种下发配置数据的方法、系统及装置，以解决现有技术中存在的在基于VPN业务的下发配置数据过程较复杂的问题。

一种下发配置数据的方法，该方法包括：

将配置命令下发至执行虚拟专用网业务的设备，该配置命令中包含按照设定顺序排列的配置数据；

所述设备接收所述配置数据，分别将该配置数据作为按照相同顺序排列的业务对应的设置参数。

一种下发配置数据的系统，该系统包括：

配置服务器，用于下发配置命令，该配置命令中包含按照设定顺序排列的配置数据；

执行虚拟专用网业务的设备，用于接收所述配置服务器下发的所述配置数据，分别将该配置数据作为按照相同顺序排列的业务对应的设置参数。

一种配置服务器，所述配置服务器包括：

数据排列模块，用于将配置数据按照设定顺序排列；

配置命令下发模块，用于下发包含排列的所述配置数据的配置命令。

一种设备，用于执行虚拟专用网业务，所述设备包括：

接收模块，用于接收配置命令，该配置命令中包含按照设定顺序排列的配置数据；

配置模块，用于分别将接收到的配置数据作为按照相同顺序排列的业务对应的设置参数。

通过向执行VPN业务的设备下发按照设定顺序排列的配置数据，所述设备分别将该配置数据作为按照相同顺序排列的业务对应的设置参数的方法，解决了设备差异化带来的网管数据模型差异化的问题，使统一、集中配置过程更加简单，减少了配置过程可能出现的错误，使得用户体验较好。

附图说明

图1为本发明实施例一中下发配置数据的系统结构示意图；

图2为本发明实施例二中下发配置数据的方法步骤流程示意图；

图3为本发明实施例二中一种排列顺序的树形结构示意图；

图4为本发明实施例三中配置服务器的结构示意图；

图5为本发明实施例四中用于执行虚拟专用网业务的设备结构示意图。

具体实施方式

下面结合说明书附图详细描述本发明实施例。

如图1所示，为本发明实施例一中下发配置数据的系统结构示意图，从图中可以看出该系统包括配置服务器11和执行VPN业务的设备12，两个实体预先设定了下发的配置数据对应的业务的排列顺序，则这两个实体的操作包括：配置服务器11用于下发配置命令，该配置命令中包含按照设定顺序排列的配置数据；设备12用于接收所述配置服务器下发的所述配置数据，分别将该配置数据作为按照相同顺序排列的业务对应的设置参数，实现业务配置。

另外，所述配置服务器11还用于为执行的VPN业务分配标识，并利用所述配置命令将该标识下发至所述设备12。

后续地，所述配置服务器11用于下发撤销命令，该撤销命令中包含虚拟专用网业务的标识；则所述设备12用于将接收到的所述标识对应的虚拟专用网业务撤销。

进一步地，所述配置服务器11用于下发回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识；所述设备12用于确定所述标识对应的虚拟专用网业务，并将执行该业务时的配置数据回滚。

在本实施例中，配置服务器11向设备12下发的各种命令(包括配置命令、撤消命令和回滚命令)，都是通过系统中的Netconf配置下发接口13转发给所述设备12的。

若所述设备12不能直接解析通过Netconf配置下发接口下发的命令，则进一步地，所述系统还包括转换设备14，用于将所述配置服务器11通过Netconf配置下发接口13下发的命令转换为所述设备12能够解析的形式，并发送给所述设备12。

与实施例一对应的，本发明实施例二提出了一种下发配置数据的方法，如图2所示，该方法的主要步骤包括：

步骤201：为当前需要执行的VPN业务分配标识。

以执行BGP/MPLS VPN业务为例，在此步骤之前，已事先完成设备的各个物理接口配置，如接口的地址、速率等属性配置；业务承载网络的MPLS协议配置和IGP协议配置等。若设定所述设备为PE路由器，则PE与客户边界路由器(Customer′s edge router，CE)之间可以使用BGP路由协议。

在向设备下发配置数据之前，需要标识当前需要执行的VPN业务，以便于后续对配置数据的撤销或重复配置时能够准确地查找出当前的配置数据，因此，分配的VPN业务配置标识具有唯一的标识性。

除了对配置数据的标识，还需要对执行当前VPN业务的需要配置的设备进行标识，例如，需要配置的设备为PE_A和PE_B路由器对，则生成PE I和PE II两个设备标识，来表示执行当前VPN业务的设备是PE_A和PE_B路由器对。

另外，还可以记录配置数据下发的时间，可称之为配置时间，则在后续的配置数据撤销和配置数据回滚时，可以根据配置时间确定在时间下发的配置数据。

生成的VPN业务配置标识、执行VPN设备标识和配置时间存在对应关系，根据其中一个参数就可以确定其他两个参数。除了VPN业务配置标识和配置时间之外，用户还可以根据需要，在下发配置数据之前生成其他的参数，来作为当前VPN业务的标识。生成的各种参数信息可以保存在配置服务器中，也可以下发给设备。

步骤202：将配置命令下发至执行VPN业务的设备，该配置命令中包含按照设定顺序排列的配置数据。

在本发明实施例中，配置命令是通过Netconf配置下发接口下发至执行VPN业务的设备：PE_A和PE_B。为了将SNMP、命令行和Netconf配置接口统一，本实施例中可以采用XML作为配置数据的基本描述形式。将下发的配置数据和操作指令配置成XML形式的参数文件，由统一配置下发服务利用Netconf配置下发接口统一下发给执行VPN业务的设备，实现了配置数据下发的统一化和规范化，屏蔽了执行VPN业务的不同设备的差异化，避免了在利用命令行配置方式的过程中出现配置顺序易出错的问题。

配置命令中的配置数据的内容确定之后，其排列顺序可以根据用户需要预先设定。该设定的顺序可以以树形结构的形式保存在下发配置数据的实体和接收该配置数据的设备中。

所述配置命令中还可以同时携带为当前的VPN业务分配的标识。

步骤203：若设备未成功接收到所述配置命令，则执行步骤204，否则执行步骤206。

步骤204：设备返回配置失败响应消息，并撤销配置操作。

步骤205：将步骤201中生成的各种参数和配置失败响应消息保存。

步骤206：接收到所述配置命令的设备返回配置成功响应消息。

所述设备和下发配置命令的实体已事先确定好的每一个配置数据对应的业务的排列顺序，则设备提取出按照设定顺序排列好的配置数据时，也就确定了每一个执行VPN业务时对应的参数。

步骤207：将步骤201中生成的各种参数和配置成功响应消息保存。

在本实施例中，保存步骤205或步骤207中的信息的实体可以是生成该参数的实体和接收配置命令的设备(路由器对)，也可以是其他的数据存储实体。

在步骤202中，所述利用Netconf配置下发接口统一下发给执行VPN业务的设备的过程可能存在以下两种情况：

第一种情况：若执行VPN业务的设备支持Netconf配置方式，则Netconf配置下发接口可以直接与支持Netconf配置方式的设备相连，例如，若PE_A支持Netconf配置方式，则PE_A接收到配置命令中的配置数据后，能够正确地解析出配置数据，并将配置数据按照设定的顺序存储，完成配置数据下发过程。

第二种情况：支持命令行配置方式或SNMP配置方式的设备不能直接解析通过Netconf配置下发接口发送的配置数据，因此，在Netconf配置下发接口下发配置数据之后，需要将配置数据转换为执行VPN业务的设备能够解析的形式。例如：若PE_B支持命令行配置方式，则Netconf配置下发接口将包含配置数据的配置命令下发至PE_B之前，将配置数据转换为命令行接口能够解析的形式；若PE_B支持SNMP配置方式，则类似地将配置数据转换为SNMP接口能够解析的形式，然后再下发至PE_B。

除了上述下发配置数据的过程可以有多种情况之外，配置数据的排列顺序也可以有多种情况，下面根据说明书附图图3来描述本实施例中设置的一种排列顺序的树形结构，配置数据按照以下描述顺序排列。

如图3所示，业务配置节点是树形结构的根节点，其含义是指通过统一配置下发思想，来进行配置管理的业务。

树形结构的第二层是BGP/MPLS VPN业务配置管理的数据节点，其含义是为此类VPN业务配置相关的数据模型。此数据节点可以根据用户的需要配置相应的数据模型，不同的数据模型之间可以没有依赖关系，具体地，在XML建模中可以使用<choice>模型来连接。

另外，还可以根据用户需要在第二层的其他业务配置节点中添加若干个下层节点。

树形结构的第三层是进行BGP/MPLS VPN业务配置管理时需要下发的配置数据，配置数据也可以根据用户的需要确定，在本实施例中包括但不限于：VPN路由前转(VPN Routing & Forwarding，VRF)配置模型、接口绑定配置模型、多协议BGP(MBGP)配置模型和PE、CE之间的路由配置模型。在这一层中，各部分的配置模型之间存在依赖关系，因此，需要按照设定的顺序出现，例如：VRF配置模型需要首先完成，之后才能完成其他配置模型。具体地，在XML建模中可以使用<sequence>容器来连接本层。

每一个配置模型中包含若干个配置数据，下面具体针对第三层的配置模型，对其需要配置的数据及数据的顺序进行详细描述。

VRF配置模型：

在VRF配置模型中，可以包括但不限于三个相互依赖的配置数据元素，配置顺序依次为：VRF实例名称、路由区分(Route Distinguisher，RD)标识和路由目标(Route Target，RT)配置，其中，RT配置中包括RT名称和路由信息传递方向这两个具体的配置数据。由于在数据的配置过程中存在依赖关系，因此，VRF配置模型在XML建模中可以采用<sequence>容器来管理其中的配置数据。

VRF实例名称是对执行VPN业务的设备的VRF实例的配置，通过配置虚拟路由来实现网络上的路由隔离。一条VPN对应一个VRF实例，VRF实例名称这一配置数据可以指示设备生成一个VRF实例，例如：生成一个VRF实例名称：VPN_A。

RD标识是一个具有全局唯一性的标识，通过将RD标识作为IP地址前缀的扩展，使不唯一的IP地址转化为唯一的VPN_IP地址，用于在骨干网络上路由信息的分发，并且，一个VRF实例名称对应一个唯一的RD标识。

RT配置中的配置数据用于实现路由信息的分发，因此要为其分配RT名称，并确定路由信息的传递方向，例如，路由信息双向传递(both)。每一个VRF实例名称可以对应若干个的RT配置个数，如：1至16个RT配置，在XML建模中可以使用<maxOccurs>属性定义。

接口绑定配置模型：

在接口绑定配置模型中可以包括但不限于四个相互依赖的配置数据元素，配置顺序依次为：物理接口名称、VRF实例名称、IP地址和IP掩码。同样，由于配置过程存在依赖关系，接口绑定配置模型在XML建模中可以采用<sequence>容器来连接其子层，表征顺序关系。

物理接口名称可以指定需要绑定的物理接口完成VPN业务的路由输出，同时激活路由器的接口操作。

VRF实例名称指定与接口绑定的VRF实例，这里的VRF实例名称与VRF配置模型中VRF实例名称的实现参数一致，如：VPN_A。

IP地址和IP掩码用于完成对接口的IP地址配置。

MBGP配置模型：

在MBGP配置模型中包括但不限于两个配置数据结构：逻辑接口配置结构和BGP路由配置结构。由于配置过程存在依赖关系，MBGP配置模型在XML建模中可以采用<sequence>容器来连接其子层。

逻辑接口配置结构用于完成VPN业务所需要的逻辑接口的配置，其配置元素可以包括但不限于以下几个，其配置顺序依次为：逻辑接口名称、IP地址和IP掩码。具体的逻辑接口名称可以为：loopback0。

BGP路由配置结构用于实现所配置的设备(PE_A)与对端设备(PE_B)之间的路由信息交互，其配置元素包括但不限于以下几个，其配置顺序依次为：BGP进程标识、对端设备(PE_B)地址、自治系统(Autonomous System，AS)号码和逻辑接口名称。由于配置过程存在依赖关系，BGP路由配置结构在XML建模中可以采用<sequence>容器来连接其元素。

BGP进程标识用于指定对BGP特定进程的配置。通过对对端PE_B地址和AS号码的配置，完成对对端设备PE_B的指定。逻辑接口名称与逻辑接口配置结构中的逻辑接口名称相同。通过对端PE_B地址和逻辑接口名称可以指定与对端设备PE_B建立邻居时采用的具体逻辑接口，如为loopback0。通过对端PE_B地址可以在VPNv4视图下使能对端PE。

PE、CE之间的路由配置模型。

在PE、CE之间的路由配置模型中可以包括但不限于四个相互依赖的配置数据元素，配置顺序依次为：VRF实例名称、对端CE地址、AS号码和路由发布。由于配置过程存在依赖关系，PE、CE之间的路由配置模型在XML建模中可以采用<sequence>容器来连接其子元素。

VRF实例名称用于将指定的VPN实例与IP地址族进行关联，与VRF配置模型中的VRF实例名称相同，如VPN_A。对端CE地址和AS号码用于将对端的CE配置为VPN网络对等实体。路由发布用来确定路由信息的发布方式，如直接发布(direct)方式。

在本实施例中，是以PE和CE之间通过BGP进行路由通信为例，若是基于其他的路由方式，如ISIS、RIP、OSPF和静态路由，则可以调整图3中树形结构，通过数据模型的扩展来实现对其他路由方式的支持。

下面通过一个下发配置数据的实例，来描述本发明实施例中下发的配置数据的结构，设定下发的配置数据是按照图3中的内容下发的。

在本实施例中，设定是对PE_A和PE_B路由器进行配置，其他网元，如CE和P路由器不在本实施例的描述范围之内。在具体的配置过程中，PE_A和PE_B的配置过程类似，因此，下面仅针对PE_A进行配置。

在步骤201中，VPN业务配置标识、执行VPN设备标识和配置时间若以XML结构生成，则其结构为：

<VPN业务配置ID>

100001

</VPN业务配置ID>

<PEI标识>

172.1.1.1

</PEI标识>

<PEII标识>

172.2.1.1

</PEII标识>

<配置时间>

2007-10-1213:00

</配置时间>

在步骤202中，将包含配置数据的配置命令下发至PE_A路由器，该配置命令的结构可以如以下程序所示：

<rpc message-id＝＂101＂

xmlns＝＂urn:ietf:params:xml:ns:netconf:base:1.0＂>//在XML中建模用

netconf配置下发接口下发配置命令

<edit-config>

</target>

//开始BGP MPLS VPN业务配置数据

<业务配置>

<VRF配置模型>

<VRF实例名称>

VPN_A

</VRF实例名称>

<RD名称>

100:1

</RD名称>

<RT配置>

<RT名称>

101:1

</RT名称>

<路由信息传递方向>

Both

</路由信息传递方向>

</RT配置>

</VRF配置模型>

<接口绑定模型>

<物理接口名称>

gigabitethernet 1/0/0

</物理接口名称>

<VRF实例名称>

VPN_A

</VRF实例名称>

<IP地址>

10.1.1.1

</IP地址>

<IP掩码>

255.255.255.0

</IP掩码>

</接口绑定模型>

<MBGP配置模型>

<逻辑接口配置>

<逻辑接口地址>

Loopback0

</逻辑接口地址>

<IP地址>

1.1.1.1

</IP地址>

<IP掩码>

255.255.255.255

</IP掩码>

</逻辑接口配置>

<BGP路由配置>

<BGP进程标识>

100

</BGP进程标识>

<邻居地址>

<对端PE地址>

3.3.3.3

</对端PE地址>

<AS号码>

100

</AS号码>

</邻居地址>

<邻居绑定>

<对端PE地址>

3.3.3.3

</对端PE地址>

<逻辑接口名称>

Loopback0

</逻辑接口名称>

</邻居绑定>

</BGP路由配置>

</MBGP配置模型>

<PE、CE路由配置模型>

<VRF实例名称>

VPN_A

</VRF实例名称>

<对端CE地址>

10.1.1.2

</对端CE地址>

<AS号码>

65410

</AS号码>

<路由发布>

Direct

</路由发布>

</PE、CE路由配置模型>

</BGPMPLS VPN业务配置>

</业务配置>

</top>

</config>

</edit-config>

</rpc>

在步骤206中，所述配置成功响应消息的结构可以如下程序所示：

<rpc-reply message-id＝＂101＂

xmlns＝＂urn:ietf:params:xml:ns:netconf:base:1.0＂>

<ok/>

</rpc-reply>

在步骤204中，配置失败的情况可以有两种：

第一种情况：一个路由器返回配置失败响应消息，另一个路由器返回配置成功响应消息，如PE_A配置失败，PE_B配置成功。

第二种情况：两个路由器(PE_A和PE_B)同时配置失败响应消息。

针对第一种情况，根据配置命令中原语和参数的不同可以采取不同的方式撤销配置。如果配置命令中使用的是Netconf中的编辑配置(edit-config)原语，并且，错误选择(error-option)参数设置为错误回转(rollback-on-config)，则可以仅对PE_B执行撤销(delete-config)操作；如果配置命令中使用的是edit-config原语，但没有将error-option参数设置为rollback-on-config，或者使用其他的原语下发配置命令(如提交(commit)原语或复制(copy-config)原语)，则可以同时对PE_A和PE_B执行delete-config操作。

针对第二种情况，与第一种情况类似，若下发配置命令时没有将edit-config的error-option参数设置为rollback-on-config，或者使用其他的原语，则将同时对PE_A和PE_B执行delete-config操作，否则可以不作操作。

在步骤205中，将步骤201中生成的各种参数和配置失败响应消息生成告警信息，如告警日志后保存。

步骤204中的配置失败响应消息的结构可以为：

<rpc-reply xmlns＝＂urn:ietf:params:xml:ns:netconf:base:1.0＂>

<rpc-error>

<error-type>rpc</error-type>

<error-tag>missing-element</error-tag>

<error-severity>error</error-severity>

<error-info>

<bad-element>message-id</bad-element>

<bad-element>rpc</bad-element>

</error-info>

</rpc-error>

</rpc-reply>

在步骤207之后的某一时刻，若VPN业务的服务期满，或用户希望结束VPN业务时，在步骤208中撤销生成的此VPN链路，该撤销的过程主要包括以下步骤：

步骤A：将撤销命令(delete-config)下发给成功接收配置命令的设备(PE_A和PE_B)，该撤销命令中包含VPN业务的标识。

同样，撤销命令也可以通过Netconf配置下发接口下发给设备，若设备不能直接解析通过Netconf配置下发接口下发的撤消命令，则将该命令转换为设备能够解析的形式。

确定执行待撤销的VPN业务的设备标识，在本实施例中，标识为PE I和PE II，并向这两个标识对应的PE_A和PE_B下发包含VPN业务的标识的delete-config。从步骤201中可以看出，VPN业务的标识可以为VPN业务配置标识或配置时间。

步骤B：所述设备将所述VPN业务的标识对应的VPN链路撤销。

步骤C：记录VPN链路的撤销时间和描述信息，并将201中生成的各种参数、撤销时间和描述信息作为告警日志保存。

本实施例中所述的描述信息可以是对此条VPN链路的详细描述，该描述信息可以又网管维护人员根需要适当添加。

在步骤208之后的某一时刻，根据需要撤销VPN链路之后，步骤209还可以实现配置数据的回滚，例如，在t1时刻成功向PE_A和PE_B下发了VPN配置命令，在t2时刻撤销了该VPN链路。后续在t3时刻，若需要再次使用t1时刻的配置数据，则可以向PE_A和PE_B下发回滚命令，该回滚命令中包含在t1时刻配置的VPN业务对应的标识。PE_A和PE_B将保存的该标识对应的t1时刻的配置数据回滚，使t3时刻的数据与t1时刻相同。

回滚命令也可以通过Netconf配置下发接口下发给设备，若设备不能直接解析通过Netconf配置下发接口下发的回滚命令，则将该命令转换为设备能够解析的形式。

根据前面对本发明实施例中系统结构和方法步骤地描述，本发明实施例三还提供一种配置服务器，如图4所示，该配置服务器包括数据排列模块21和配置命令下发模块22，其中，数据排列模块21用于将配置数据按照设定顺序排列；配置命令下发模块22用于下发包含排列的所述配置数据的配置命令。

所述配置服务器还包括标识分配模块23，用于为执行的虚拟专用网业务分配标识，并利用所述配置命令下发模块将该标识下发。

所述配置服务器还包括撤销命令下发模块24，用于下发撤销命令，该撤销命令中包含虚拟专用网业务的标识，指示执行该业务的设备撤销所述标识对应的虚拟专用网业务。

所述配置服务器还包括回滚命令下发模块25，用于下发回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识指示已撤销该标识对应业务的设备将执行该业务时的配置数据回滚。

进一步地，所述配置服务器还包括Netconf配置下发接口26，用于将配置服务器中的命令转发，具体地，可以转发配置命令、撤消命令和回滚命令。

所述配置服务器的工作流程如下：

第一步：数据排列模块21将待下发的配置数据按照设定顺序排列；

第二步：配置命令下发模块22利用Netconf配置下发接口26将包含排列的所述配置数据的配置命令下发；

第三步：标识分配模块23为执行的虚拟专用网业务分配标识，并利用Netconf配置下发接口26将该标识下发；

第二步和第三步可以同时执行，标识可以通过配置命令下发。

第四步：在满足撤消条件或用户希望停止VPN业务时，撤销命令下发模块24利用Netconf配置下发接口26下发撤销命令，该撤销命令中包含虚拟专用网业务的标识，指示执行该业务的设备撤销所述标识对应的虚拟专用网业务；

第五步：若用户希望将撤消的VPN业务恢复时，回滚命令下发模块25利用Netconf配置下发接口26下发回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识指示已撤销该标识对应业务的设备将执行该业务时的配置数据回滚。

与实施例一和实施例二的系统合方法对应的，本发明实施例四还提供一种用于执行虚拟专用网业务的设备，如图5所示，该设备包括接收模块31和配置模块32，其中，接收模块31用于接收配置命令，该配置命令中包含按照设定顺序排列的配置数据；配置模块32用于分别将接收到的配置数据作为按照相同顺序排列的业务对应的设置参数。

所述接收模块31还用于接收为执行的虚拟专用网业务分配的标识。

若所述接收模块31还用于接收撤销命令，该撤销命令中包含虚拟专用网业务的标识；则所述设备还包括撤销模块33，用于将接收到的所述标识对应的虚拟专用网业务撤销。

若所述接收模块31还用于接收回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识；则所述设备还包括回滚模块34，用于确定所述标识对应的虚拟专用网业务，并将执行该业务时的配置数据回滚。

进一步地，发送至接收模块31的各种命令可能是设备无法解析的，因此，所述设备还包括转换模块35，用于将接收到的命令转换为自身能够解析的形式，并发送给所述接收模块31。

所述设备的工作流程包括如下步骤：

第一步：转换模块35将接收到的各种命令转换为设备能够解析的形式，并发送给接收模块31；

若配置命令本身就是设备能够解析的形式，则不需要此步。

第二步：接收模块31接收到配置命令，该配置命令中包含按照设定顺序排列的配置数据，则配置模块32分别将接收到的配置数据作为按照相同顺序排列的业务对应的设置参数；

第三步：接收模块31接收为执行的虚拟专用网业务分配的标识；

第二步和第三步可以同时执行，标识通过配置命令下发。

第四步：接收模块31接收撤销命令，该撤销命令中包含虚拟专用网业务的标识，则撤销模块33所述标识对应的虚拟专用网业务撤销；

第五步：接收模块31接收回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识，则回滚模块34确定所述标识对应的虚拟专用网业务，并将执行该业务时的配置数据回滚。

通过本发明实施例提供的方法、系统及装置，避免了由于路由器设备数量庞大、来自于不同的设备提供商和配置命令差异化造成的配置管理上的缺陷；利用Netconf配置下发接口，解决了下发配置的差异化和复杂化的问题；同时通过分层结构的数据模型及事物机制实现了各种高层管理操作，如撤销、回滚等。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1、一种下发配置数据的方法，其特征在于，该方法包括：

2、如权利要求1所述的方法，其特征在于，所述配置命令是通过网络配置协议Netconf配置下发接口下发至所述设备的。

3、如权利要求2所述的方法，其特征在于，若所述设备不能直接解析通过Netconf配置下发接口下发的配置数据，则将Netconf配置下发接口下发的配置数据转换为所述设备能够解析的形式。

4、如权利要求1所述的方法，其特征在于，所述方法还包括：

为执行的虚拟专用网业务分配标识，并利用所述配置命令将该标识下发至所述设备。

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

将撤销命令下发至执行虚拟专用网业务的所述设备，该撤销命令中包含虚拟专用网业务的标识；

所述设备将所述标识对应的虚拟专用网业务的配置撤销。

6、如权利要求5所述的方法，其特征在于，所述方法还包括：

将回滚命令下发至所述设备，该回滚命令中包含撤销的所述虚拟专用网业务的标识；

所述设备确定所述标识对应的虚拟专用网业务，并将执行该业务时的配置数据回滚。

7、一种下发配置数据的系统，其特征在于，该系统包括：

8、如权利要求7所述的系统，其特征在于，

所述配置服务器，用于为执行的虚拟专用网业务分配标识，并利用所述配置命令将该标识下发至所述设备。

9、如权利要求8所述的系统，其特征在于，

所述配置服务器，用于下发撤销命令，该撤销命令中包含虚拟专用网业务的标识；

所述设备，用于将接收到的所述标识对应的虚拟专用网业务撤销。

10、如权利要求8所述的系统，其特征在于，

所述配置服务器，用于下发回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识；

所述设备，用于确定所述标识对应的虚拟专用网业务，并将执行该业务时的配置数据回滚。

11、如权利要求7-10中任一所述的系统，其特征在于，所述设备还包括：

Netconf配置下发接口，用于将所述配置服务器下发的命令转发给所述设备。

12、如权利要求11所述的系统，其特征在于，若所述设备不能直接解析通过Netconf配置下发接口下发的命令，则所述系统还包括：

转换设备，用于将通过Netconf配置下发接口下发的命令转换为所述设备能够解析的形式，并发送给所述设备。

13、一种配置服务器，其特征在于，所述配置服务器包括：

数据排列模块，用于将配置数据按照设定顺序排列；

14、如权利要求13所述的配置服务器，其特征在于，所述配置服务器还包括：

标识分配模块，用于为执行的虚拟专用网业务分配标识，并利用所述配置命令下发模块将该标识下发。

15、如权利要求14所述的配置服务器，其特征在于，所述配置服务器还包括：

撤销命令下发模块，用于下发撤销命令，该撤销命令中包含虚拟专用网业务的标识，指示执行该业务的设备撤销所述标识对应的虚拟专用网业务。

16、如权利要求15所述的配置服务器，其特征在于，所述配置服务器还包括：

回滚命令下发模块，用于下发回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识指示已撤销该标识对应业务的设备将执行该业务时的配置数据回滚。

17、如权利要求13-16中任一所述的配置服务器，其特征在于，所述配置服务器还包括：

Netconf配置下发接口，用于将所述配置服务器下发的命令转发。

18、一种设备，用于执行虚拟专用网业务，其特征在于，所述设备包括：

19、如权利要求18所述的设备，其特征在于，所述接收模块，还用于接收为执行的虚拟专用网业务分配的标识。

20、如权利要求18所述的设备，其特征在于，

所述接收模块，还用于接收撤销命令，该撤销命令中包含虚拟专用网业务的标识；

所述设备还包括：

撤销模块，用于将接收到的所述标识对应的虚拟专用网业务撤销。

21、如权利要求20所述的设备，其特征在于，所述接收模块，还用于接收回滚命令，该回滚命令中包含撤销的所述虚拟专用网业务的标识；

所述设备还包括：

回滚模块，用于确定所述标识对应的虚拟专用网业务，并将执行该业务时的配置数据回滚。

22、如权利要求18-21任一所述的设备，其特征在于，所述设备还包括：

转换模块，用于将接收到的命令转换为自身能够解析的形式，并发送给所述接收模块。