WO2018219322A1 - 设备管理方法、装置、处理器以及存储介质 - Google Patents

设备管理方法、装置、处理器以及存储介质 Download PDF

Info

Publication number
WO2018219322A1
WO2018219322A1 PCT/CN2018/089240 CN2018089240W WO2018219322A1 WO 2018219322 A1 WO2018219322 A1 WO 2018219322A1 CN 2018089240 W CN2018089240 W CN 2018089240W WO 2018219322 A1 WO2018219322 A1 WO 2018219322A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
deployed
sdn controller
mapping table
driving
Prior art date
Application number
PCT/CN2018/089240
Other languages
English (en)
French (fr)
Inventor
陈尔严
马小飞
陈文博
单伯晓
丁建武
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2018219322A1 publication Critical patent/WO2018219322A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/30—Routing of multiclass traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • the present disclosure relates to the field of communication technologies, for example, to a device management method, apparatus, processor, and storage medium.
  • NETCONF Network Configuration protocol
  • RRC Request For Comments
  • SNMP Simple Network Management Protocol
  • the management software can use the NETCONF protocol to write configuration data to the device or retrieve data from the device. All data is encoded in Extensible Markup Language (XML), using remote procedure calls (RPCs) through secure, connection-oriented protocols such as Secure Sockets Layer (SSL) or Transport Layer Security. ) mode transmission.
  • XML Extensible Markup Language
  • RPCs remote procedure calls
  • SSL Secure Sockets Layer
  • Transport Layer Security Transport Layer Security
  • the NETCONF protocol defines multiple data stores, or multiple sets of configuration data.
  • the running configuration data store contains configuration information that the current device is using.
  • Some devices also store boot configuration data, where the boot configuration data includes configuration data when the device is first booted, but the configuration data when the device is first booted is separate from the running configuration data.
  • the device In addition to configuration data, the device also stores state data and information, such as packet statistics, and other data collected by devices running.
  • state data and information such as packet statistics, and other data collected by devices running.
  • the control software can read these status data and information, but it cannot be written.
  • Candidate configuration data storage is an optional device capability. If the candidate configuration data store is enabled, the controller can be used to update the running data store and modify device operations based on the set of configuration data it contains.
  • This set of “features” includes information such as the NETCONF protocol version support list, whether the candidate data is candidate configuration data, and whether there is a way to modify the running data store.
  • the “features” are defined in the NETCONF RFC, and developers can add additional “features” by following the specification format described in the RFC.
  • the command set of the NETCONF protocol consists of a series of commands for reading, modifying device configuration data, and reading status data. Commands communicate through RPCs and respond with a Remote Procedure Call (RPC) reply. An RPC reply is required to respond to an RPC to return.
  • RPC Remote Procedure Call
  • a configuration operation consists of a series of RPCs, each with its corresponding RPC reply.
  • the selected transport protocol shall ensure that the RPCs are delivered to the device in the order in which they were sent, and the RPC responses are received in the order in which the RPCs are initiated.
  • the device can also issue a notification to inform some events on the controller device.
  • SDN Software Defined Network
  • Open and programmable network architecture to achieve flexible control of network traffic, making the network more intelligent as a pipeline.
  • the SDN shields the difference between the underlying physical forwarding devices through the standard southbound interface to implement resource virtualization.
  • the flexible northbound interface is opened for upper-layer services to perform network configuration and call network resources as needed.
  • network resources can be presented to business application developers in the same way as other types of virtualized resources, and the developer does not need to spend a lot of overhead on the underlying network devices to perform additional adaptation work. Helps rapid innovation in business applications.
  • An embodiment of the present application provides a device management method, apparatus, device, and storage medium, to at least solve the related art, when a controller in a SDN network manages different vendors' devices, and writes and configures a driver for each device, thereby causing control.
  • the cumbersome management process of the device is not limited to, but not limited to, Bluetooth, Wi-Fi, Wi-Fi, Wi-Fi, Wi-Fi, Wi-Fi, Wi-Fi, Wi-Fi network, and Wi-Fi network.
  • a device management method including: a software-defined network SDN controller receiving a service deployment request, where the service deployment request carries a service to be deployed and a route for performing the service to be deployed.
  • the SDN controller obtains a device driver entry corresponding to the to-be-deployed service in a preset service mapping table, where the device driver entry is used in the device driver table to indicate the SDN controller An entry of the attribute information of the managed routing device; the SDN controller acquires the device driving message according to the device driving entry corresponding to the to-be-deployed service, and sends the obtained device driving message to perform the The routing device of the service to be deployed, wherein the device-driven packet carries the content of the implementation of the routing device that performs the service to be deployed.
  • a device management apparatus including: a receiving module, configured to receive a service deployment request, where the service deployment request carries a service to be deployed and a service to be deployed a routing device, configured to obtain, in a preset service mapping table, a device driver entry corresponding to the to-be-deployed service, where the device driver entry is used in the device driver table to indicate the SDN control
  • the YANG model attribute information of the routing device managed by the device the sending module is configured to obtain the device driving message according to the device driving entry corresponding to the service to be deployed, and send the obtained device driving message to The routing device that performs the service to be deployed, where the device-driven packet carries the content of the implementation of the routing device that performs the service to be deployed.
  • a storage medium comprising a stored program, wherein the program is executed to perform the method described in any of the above embodiments.
  • a processor configured to execute a program, wherein the program is executed to perform the method described in any of the above embodiments.
  • the technical solution of the present application solves the problem that when the controller manages different vendors' devices in the SDN network, the driver is written and configured for each device, and the management process of the controller is cumbersome.
  • the SDN controller does not need to be used by different vendors.
  • the routing device can write the corresponding driver to manage the routing devices of different vendors, which simplifies the management process of the controller.
  • FIG. 1 is a flowchart of a device management method according to an embodiment of the present application
  • FIG. 2 is a schematic flowchart of a method for managing different devices based on NETCONF in a software-defined network according to an embodiment of the present application
  • FIG. 3 is a service example topology diagram of a method for managing different devices based on NETCONF in a software-defined network according to an embodiment of the present application;
  • FIG. 4 is a schematic diagram of a device driver table creation process of a device driver table management module in an example of the embodiment of the present application
  • FIG. 5 is a schematic diagram of a service mapping table creation process when an SDN controller delivers service data as a whole in an example of the embodiment of the present application;
  • FIG. 6 is a schematic diagram of a service mapping table creation process when an SDN controller sends a service according to a southbound interface in an example of the embodiment of the present application;
  • FIG. 7 is a flowchart of dynamically generating and delivering a NETCONF message by the NETCONF message dynamic generation module in the example of the embodiment of the present application by using the service data to retrieve the corresponding service mapping table and the device driver table;
  • FIG. 8 is a structural diagram of a device management apparatus according to an embodiment of the present application.
  • the technical solution in this application file can be applied to an SDN network.
  • the interface of the device when NETCONF is used as the southbound interface, the interface of the device may have a complicated definition according to the requirements of RFC6020, and the nodes in the data model of the tree structure may have different type definitions, but finally are issued.
  • the packets sent to the device are all string messages in XML format. Therefore, the NETCONF southbound interface of the controller can be channelized, that is, the content of the NETCONF interface is not perceived, the content of the message is changed to be defined by the device YANG model, and the correspondence between the controller service data and the YANG model dynamically generates a driver report.
  • the NETCONF southbound interface of the controller can be channelized, that is, the content of the NETCONF interface is not perceived, the content of the message is changed to be defined by the device YANG model, and the correspondence between the controller service data and the YANG model dynamically generates a driver report.
  • FIG. 1 is a flowchart of a device management method according to an embodiment of the present application. As shown in FIG. 1 , the process includes the following steps:
  • the software-defined network SDN controller receives a service deployment request, where the service deployment request carries a routing device to be deployed and a service to be deployed.
  • the SDN controller acquires a device driver entry corresponding to the to-be-deployed service in a preset service mapping table, where the service mapping table stores each service and device driver table in the current SDN network.
  • the device driver entry is an entry in the device driver table for indicating attribute information of the routing device managed by the SDN controller.
  • the device driver entry is a device definition. A subset of the driver interface.
  • the SDN controller obtains a device driving packet according to the device driving entry corresponding to the service to be deployed, and sends the obtained device driving packet to a routing device that performs the service to be deployed.
  • the device-driven message carries the content of the implementation of the routing device that performs the service to be deployed.
  • a service mapping table in which the correspondence between all services and device driver entries is stored is pre-established in the SDN network, and the device model and version information of the routing device in the SDN network are recorded in the device driver table where the device driver entry is located. And other attribute information.
  • the SDN receives the service deployment request input by the user, and the service deployment request carries the routing device to be deployed and the device to be deployed, and the device driver entry corresponding to the service to be deployed is queried in the preset service mapping table.
  • a device driver packet is created according to the device driver entry, and the device driver packet is sent to the routing device that performs the service to be deployed.
  • the above technical solution solves the problem that when the controller manages different vendors' devices in the SDN network, the driver is written and configured for each device, which leads to the cumbersome management process of the controller, and the SDN controller does not need to be a routing device of different vendors.
  • the SDN controller does not need to be a routing device of different vendors.
  • the SDN controller acquires the device driver entry corresponding to the service to be deployed in the preset service mapping table, and includes: the identifier corresponding to the service to be deployed in the service deployment request by the SDN controller Obtaining, by the preset service mapping table, a device driver entry corresponding to the identifier information, where the SDN controller allocates one identifier information for each service in the current SDN network, where the identifier information Used to uniquely identify each type of business.
  • the SDN controller establishes the service mapping table by using at least one of the following manners before the SDN controller acquires the device driver entry corresponding to the to-be-deployed service in the preset service mapping table.
  • the SDN controller establishes a first service mapping table for each service in the current SDN network; the SDN controller establishes a second service mapping table according to the southbound interface definition of the SDN controller.
  • the SDN controller manages the first service mapping table according to the following device information: device manufacturer The device model, the version information of the device, and the operation type of the service; after the SDN controller establishes the second service mapping table according to the southbound interface definition of the SDN controller, the SDN controller follows the following devices: The information management is performed by the second service mapping table: a device manufacturer, a device model, a version information of the device, and an identifier of the southbound interface of the SDN controller.
  • the SDN controller obtains the device driver entry corresponding to the to-be-deployed service in the preset service mapping table, and the SDN controller selects according to the delivery mode of the to-be-deployed service.
  • the service mapping table corresponding to the delivery mode the SDN controller acquires a device driver entry corresponding to the service to be deployed in the service mapping table corresponding to the delivery mode.
  • the delivery mode that is to be delivered by the service to be deployed is corresponding to the first service mapping table, and the delivery mode that is delivered by the southbound interface corresponds to the second service mapping table.
  • the SDN controller acquires the device driver packet according to the device driver entry corresponding to the service to be deployed, and the SDN controller creates a device driver model according to the device driver entry;
  • the device driver model obtains the device driver message.
  • the device driver table further includes: a driving message node composition relationship of each routing device (ie, a YANG model node composition relationship), wherein the driving message node composition relationship is indicated by at least the following information: : node name, node data organization form, parent node, data tree root node, and the depth of the node in the data tree.
  • a driving message node composition relationship of each routing device ie, a YANG model node composition relationship
  • the driving message node composition relationship is indicated by at least the following information: : node name, node data organization form, parent node, data tree root node, and the depth of the node in the data tree.
  • the SDN controller creates a device driver model according to the device driver entry, and the SDN controller creates at least one relationship according to the device driver entry and the driving message node composition relationship.
  • the device drives a tree node corresponding to the entry; the data tree composed of the at least one tree node is used as the device driving model.
  • the SDN controller sends the obtained device-driven packet to the routing device that performs the service to be deployed, and the SDN controller performs the routing with the to-be-deployed service.
  • the NETCONF session between the devices completes the capability notification of the routing device that performs the service to be deployed; the SDN controller sends the device driver packet to the execution according to the capability reported by the routing device A routing device that deploys services.
  • the device-driven message when the service mapping table includes an attribute field of a specified service, the device-driven message carries an attribute field of the specified service obtained from the service mapping table.
  • the SDN controller updates at least the following An item: the service mapping table and the device driver table in which the device driver entry is located.
  • the embodiment of the present application overcomes the problem and defect that the controller develops an independent driver module for each new type of device and performs cumbersome adaptation when using NETCONF as a southbound interface to manage devices of different vendors, and provides an SDN controller according to the SDN controller.
  • the function implementation and the device YANG model correspond to dynamically generate the driver message adapted to the device, and send it to the network device to form the forwarding surface information or complete the operation of the device to implement the same SDN controller to manage devices of different vendors.
  • An embodiment of the present application provides a method for managing different devices based on NETCONF in a software-defined network.
  • the method may be implemented by using a module that executes the method, where the module includes: a service configuration management module, a NETCONF standard channel module, and a device driver.
  • the module includes: a service configuration management module, a NETCONF standard channel module, and a device driver.
  • the service configuration management module receives the service deployment request of the user through the northbound interface, and after a series of calculations, forms a service data model including the forwarding plane information.
  • the device driver table management module Before the forwarding surface information and configuration information are sent to the corresponding device through the NETCONF standard channel module, the device driver table management module firstly drives all the NETCONF-enabled device driver models in the network (generally the YANG file or XML format that meets the requirements of RFC6020).
  • the files collectively referred to as the device YANG model, are parsed to form the corresponding device driver table.
  • the SDN controller manages these driver tables by device vendor, device model, and device version.
  • the SDN controller establishes a service mapping table through the service mapping module to represent a mapping relationship between the service data model and the device driver table.
  • the NETCONF packet dynamic generation module obtains the forwarding information and configuration information of the service
  • the NETCONF packet is dynamically generated according to the service mapping table and the device driver table, and then the NETCONF standard channel module sends the packet to the device to complete the network device. Deployment of services or operations on devices.
  • the device driver table management module of the SDN controller is configured to parse the device YANG model to form a device driver table of the device, and the device driver table includes the following parts: NETCONF protocol version information supported by the device, and device YANG The composition relationship between nodes in the model and the dependencies between device modules.
  • the NETCONF standard channel module is used to establish basic information about the NETCONF channel of the device.
  • the composition relationship of the nodes in the equipment YANG model includes: the name of the node in the device YANG model, the information of the parent node, and the hierarchy of the tree structure to which it belongs. Based on this information, the tree structure of the device YANG model can be restored.
  • the dependencies between device modules include: the order of the device modules, additional elements, or special processing when performing certain operations (such as creating, deleting, and updating) on the service.
  • the device module refers to the software module and is set to A module that writes specific code.
  • the service mapping module manages the correspondence between the controller's business data model and the device YANG model, that is, the controller's data definition corresponds to the node definition of the device YANG model.
  • each service attribute is assigned a globally unique identifier, and one or more entries of the device driver table corresponding to the identifier can be retrieved through the identifier.
  • this correspondence has integrity requirements and there is no order requirement. The integrity requirement means that each service data item definition on the controller requires one or more entries in the table to represent the mapping relationship with the device YANG model node.
  • the NETCONF standard channel module negotiates the NETCONF session with the device to be managed based on the NETCONF support information of the device in the device driver table.
  • the controller acts as the client and the device acts as the server.
  • the NETCONF message dynamic generation module is that the controller obtains the corresponding information of the device driver table by retrieving the service mapping table according to the service information, forms a driving message conforming to the device data model, and uses the NETCONF session established by the NETCONF standard channel module to drive the report. The message is sent to the device to complete the forwarding of the forwarding information or the operation information.
  • FIG. 2 is a schematic flowchart of a method for managing different devices based on NETCONF in a software-defined network according to an embodiment of the present application. As shown in FIG. 2, multiple modules in the method are configured to perform the following steps:
  • the SDN controller parses all the device YANG models through the device driver table management module, and uses the device manufacturer, device model, and version information as key values, and establishes a series of driver tables for the device according to the module division of the device.
  • the device driver table includes version information and capability information of the supported NETCONF, and the controller can establish a NETCONF channel with the device according to the information, and obtain the capability of device notification, protocol operation type, and data storage support information, etc., NETCONF standard
  • the channel module can determine some parameters in the RPC interface according to these parameters.
  • the device driver table also includes the composition relationship of each node in the device YANG model, including: node name, node data organization form (such as leaf, list, or leaf-list), Information such as the parent node, the data tree root node, and the depth of the node in the data tree.
  • node name node name
  • node data organization form such as leaf, list, or leaf-list
  • Information such as the parent node, the data tree root node, and the depth of the node in the data tree.
  • the controller needs to assign a globally unique identifier to each service attribute in the service data model of the controller. Through the identifier, one or more entries identifying the device driver table corresponding to the device may be retrieved from the service mapping table.
  • the service mapping module establishes a service mapping table for the entire service or according to its own southbound interface definition.
  • the entire service can be delivered to the device at one time through this table.
  • the controller needs to manage these tables according to the device manufacturer, device model, version information, and operation type, and establish dependencies between device modules by operation type in the mapping table.
  • the service attribute included in the interface can be sent to the device through the table.
  • the controller needs to manage these tables by device vendor, device model, version information, and the unique identity of the southbound interface.
  • the southbound interface involves multiple modules of the device, it is also necessary to establish dependencies between the device-related modules in the mapping table.
  • the service mapping table also supports the automatic creation of partial driver messages according to the difference in device implementation.
  • the function set of different devices is different, and the data model definition of the controller may also be quite different.
  • the device part definition may not find the corresponding attribute in the controller data model, but the field is created on the device. Required attributes, which can be met by the automatic creation of the mapping table.
  • the controller also needs to establish a mapping table of the correspondence between the controller enumeration type and the device enumeration type, and these mapping tables are also managed according to the device manufacturer, device model, and version information.
  • the service configuration management module receives the service deployment request of the user through the northbound interface, and after a series of calculations, forms a service data model including the forwarding plane information and the configuration information; and then, according to the requirements of the service deployment, the service is delivered or passed through the entire service.
  • the specific southbound interface completes the delivery of part of the information.
  • the NETCONF packet dynamic generation module retrieves the corresponding mapping table according to the vendor, device model, and version information, and creates a corresponding device driver entry through the entries in the mapping table.
  • the NETCONF packet dynamic generation module retrieves the corresponding mapping table according to the vendor, device model, and version information, and creates a corresponding device driver entry through the entries in the mapping table.
  • each driver table entry all the associated upper nodes in the tree model of the node are created in an iterative manner according to the composition relationship of the node, and the association of the node is created according to the association relationship. Nodes and their corresponding tree structures. When the root node of the tree structure is created, this iteration process ends and one or more data trees conforming to the device YANG model are obtained.
  • mapping process for each entry in the mapping table is iterated as described above. However, when the node to be created already exists, it is not repeated.
  • Delete such as "delete” or “remove” operation of "edit-config” in the protocol operation type, in order to avoid deleting all nodes of the device model Perform a merge on the deleted node: when a node in the tree data and the parent node of the node have a delete operation, if the node is not used to identify the unique identifier of the service, the node is from the tree data Deleted in the model.
  • the tree structure model is converted into a corresponding XML format driven message.
  • the NETCONF standard channel module of the controller acts as a client to establish a NETCONF session and complete capability notification with the device to be operated.
  • the controller can then select the protocol operation type (eg "edit-config") and the configuration data storage method (eg “candidate” (optional) or “running") according to the capabilities of the device notification.
  • the driver packet is sent to the corresponding device to complete the required operation or form a forwarding plane for the data.
  • the driver table and the service mapping table are updated according to the latest version of the device YANG model; the management of the new device can be realized by re-processing according to the above steps.
  • FIG. 3 is a service example topology diagram of a method for managing different devices based on NETCONF in a software-defined network according to an embodiment of the present application.
  • the user passes the same network device “Node1” (Node 1) and “Node2”. (Node 2), connect three LANs that are not connected to each other into a virtual private network (VPN) that can communicate with each other.
  • VPN virtual private network
  • the interface "Gei-1" and the interface “Gei-2" of the network device “Nodel” are respectively set to connect to the network "network-a” (network a) and “network-b” (network b), and the network device “Node2"
  • the interface "Gei-3” is set to connect to the network "network-c” (network c).
  • the SDN controller manages two devices through the NETCONF mode, wherein the SDN controller acts as a NETCONF client and the device acts as a NETCONF server.
  • the following is a VPN service data model in the SDN controller in the example of the embodiment of the present application, that is, a data model for the VPN in the SDN controller, where "node-name" (node name) is used to represent the network device, and the remaining attribute definitions All are related to the business.
  • the YANG model of the VRF module and the YANG model of the interface module are model definitions of two related modules in the YANG model definition of the network device used, and the two modules are VRF modules and interface modules.
  • the YANG model of the network device also includes other modules, such as Quality of Service (QOS), tunnels, etc., but has nothing to do with the functions of the present example, and therefore does not need to be embodied in the code.
  • QOS Quality of Service
  • Table 1 is the controller service data table, as shown in Table 1. The process of delivering the data to the device will be described below in accordance with the method described in the embodiment of the present application (as shown in FIG. 2).
  • the YANG model of the device that imports the required model refers to the YANG model that does not need to import all the devices, but can be implemented according to the function of the controller, and only imports the related device YANG model, and some related nodes of one of the modules YANG model. .
  • the structure of the imported node is complete, and no isolated nodes are present.
  • the device driver table creation process of the device driver table management module mainly includes the following steps:
  • S701 The controller acquires (or identifies) the manufacturer, model, and version information of the device as a management key by configuring or actively identifying, initializes the management module, and establishes a corresponding device driver table;
  • the YANG model of the controller parsing device generally refers to the YANG file corresponding to the externally exposed operation interface of the device complying with the requirements of RFC6020, and the corresponding YANG file is defined according to the module defined by the device.
  • the content of the parsing is mainly the name of the node in the YANG file and the organization of the node data (such as leaf, list, or leaf-list). Resolution tools can be automated through tools to increase efficiency.
  • S703 According to the function implementation of the controller, import the YANG model of the required module and the related node information in the model. That is, it is not necessary to import the YANG model of the device, but it can be implemented according to the function of the controller, and only the related device YANG model, and some related nodes of one of the module YANG models are imported. When only some of the related nodes of one of the module YANG models are imported, the structure of the imported node is complete, and no isolated nodes are present. After filtering out the module and node information that is not related to the required function, the remaining YANG model still meets the requirements of RFC6020.
  • S704 Generate a composition relationship between the corresponding device driver table nodes: the controller stores the module name, the node name, the node data organization form, and the parent node information of the parsed device YANG model into the corresponding device driver table. .
  • the formed device driver table is as shown in Table 2.
  • Table 2 is the device driver table according to the first example (excluding version information and capability information supporting NETCONF, etc.), wherein, due to VRF The "function-a" (function a) and "function-b" (function b) in the model are independent of this function, so there is no need to import it into the driver table.
  • FIG. 5 is a schematic diagram of a service mapping table creation process when an SDN controller delivers service data as a whole in an example of the embodiment of the present application.
  • the service mapping of the service in the overall manner is performed in the embodiment of the present application.
  • the service is delivered in a holistic manner. It is a way to store all the attribute definitions and operation types of the service into the service mapping table.
  • the management key value of the table is a combination of the operation type and the management key value of the device driver table of the corresponding device.
  • the NETCONF packet dynamic generation module will generate the driver packets of all modules according to the table and send them to the device at one time.
  • the implementation method mainly includes the following steps:
  • S801 The controller initializes the service mapping management module and establishes a corresponding service mapping table (the overall mapping table) by using the device manufacturer, model, version information, and operation type as key values.
  • S802 The controller allocates a globally unique identifier to all the attribute definitions of the service, and stores the service mapping table according to the operation type. Each entry in the service mapping table corresponds to one or more device driver entries.
  • S803 The controller establishes a dependency relationship between the modules according to the operation type for the device driver table. This dependency determines the order in which the packets are sent between different modules and within the module.
  • S804 Set the automatically created node in the mapping table according to the implementation manner and characteristics of the device. These nodes belong to the implementation of the device, and no controller attribute field corresponds to it, but it is also the content carried in the driver message.
  • the controller creates a mapping table between the enumerated type defined in the device YANG model and the enumerated type defined by the controller, and the mapping table is managed by using the device manufacturer, model, and version information as key values.
  • the "create” operation is taken as an example.
  • the formed service mapping table and the enumeration type mapping table are shown in Table 3.
  • Table 3 is based on the second example.
  • the business mapping table in which the attributes in the mapping table are not required in sequence, but there is an integrity requirement, that is, all the attributes of the business are included.
  • the configuration of the interface module is delivered after the configuration of the VRF module.
  • the device interface module supports multiple Internet Protocol IP address configurations, and automatically creates a "primary-or-secondly" (primary or secondary) node and sets it to the "primary” type according to the implementation requirements of the device.
  • the controller "rt-type" node and its corresponding device node are enumerated types, so they are enumerated type-converted.
  • Table 4 is an enumeration type mapping table according to example two.
  • FIG. 6 is a schematic diagram of a service mapping table creation process when an SDN controller sends a service according to a southbound interface in an example of the embodiment of the present application
  • FIG. 6 is a schematic diagram of a device sent by a single southbound interface in the embodiment of the present application.
  • Schematic diagram of the business mapping table creation process It is delivered in a single southbound interface.
  • the related service attribute definitions in the interface are stored in the service mapping table, and relationships corresponding to the device driver table entries are established for these attributes.
  • the management key value of the table is a combination of the management key value of the device driver table of the corresponding device and the unique identifier of the southbound interface.
  • the NETCONF packet dynamic generation module generates a driver packet of the relevant module according to the table, and sends it to the device at one time.
  • the implementation method mainly includes the following steps:
  • S901 The controller allocates a globally unique identifier for each southbound interface.
  • S902 The controller initializes the service mapping management module and establishes a corresponding service mapping table by using the device manufacturer, model, version information, and the southbound interface identifier as key values.
  • S903 Add a mapping relationship between the service attribute and the device driver entry included in the mapping table in the mapping table: the controller creates an entry for all parameters in the mapping table of the southbound interface, and each entry corresponds to One or more device driver entries.
  • S904 The controller establishes a dependency relationship between the modules for the device driver table involved in the southbound interface. This dependency determines the order in which the packets are sent between different modules and within the module.
  • S905 Set an automatically created node in the driver table involved in the southbound interface according to the implementation manner and characteristics of the device. These nodes belong to the implementation of the device, and no interface parameters correspond to them, but they are also carried in the drive message.
  • the controller creates a mapping table between the enumerated type defined in the device YANG model and the enumerated type defined by the controller; the mapping table is managed by the manufacturer, model, and version information of the device as management key values.
  • the controller has a southbound interface "add-ac” (access control address) for connecting the private network to the VPN, its parameters include "vpn-name” (virtual private network name) in addition to the device identifier. , "ac-name” (access control name), "ip-address” (Internet Protocol address), "ip-mask” (subnet mask).
  • the formed service mapping table is as shown in Table 5, and Table 5 is the service mapping table of the southbound interface according to the third example.
  • the attributes in the service mapping table of the southbound interface are not required in sequence, but have integrity requirements, that is, all parameters of the interface must be included.
  • the device interface module supports multiple IP address configurations. According to the implementation requirements of the device, the "primary-or-secondly" (primary or secondary) node is automatically created and set to the "primary” type. Since the enumerated type data is not processed, there is no need to create an enumerated type mapping table here.
  • FIG. 7 is a flowchart of dynamically generating and delivering a NETCONF message by the NETCONF packet dynamic generation module in the example of the embodiment of the present application by using the service data to retrieve the corresponding service mapping table and the device driver table, as shown in FIG.
  • the NETCONF packet dynamic generation module sends the forwarding plane information and configuration information corresponding to the service data to the processing flow of the device.
  • the module dynamically generates and delivers a flow chart of the NETCONF message by retrieving the corresponding service mapping table and the device driver table by using the service data to be delivered.
  • the implementation method mainly includes the following steps:
  • the controller receives the service request through the northbound interface, and performs calculations in the controller to form information about the configuration and forwarding plane that needs to be sent to the device.
  • S1002 The controller locates the corresponding service mapping table according to the manner in which the service is delivered. Then, according to the service data that needs to be delivered, the corresponding mapping entry is retrieved from the mapping table one by one. When the mapping entry exists, S1003 is performed; when the mapping entry is not retrieved, the mapping entry processing is completed, and S1007 needs to be executed. .
  • S1003 The controller creates a device driver model according to the entry of the device driver table corresponding to the mapping entry.
  • each driver table entry it is necessary to create all the upper nodes associated with the tree model in the iterative manner according to the composition relationship of the nodes; when creating the root node to the tree structure At this point, the iteration process ends and a data tree conforming to the device driver model is obtained.
  • the driver table entry that needs to be created already exists you do not need to create it repeatedly, and continue to process it according to the original process.
  • S1004 When the controller creates a driver table entry, it determines whether the entry has dependencies on other modules, or has an automatically created driver entry. When the condition is not met, go to S1002 to continue processing the next mapping entry; when the condition is met, execute S1005.
  • the controller also creates an iterator-dependent device driver model in an iterative manner and adds it to the device model that was previously created.
  • S1006 The controller also creates the nodes (or modules) to be automatically created by the device in an iterative manner and adds them to the device model that has been created before. Then go to S1002 to continue.
  • S1007 The controller converts the already created device driver model into a NETCONF driver message in XML format in combination with the dependency between the device modules. The dependencies between device modules are reflected in the order of the messages.
  • the controller sends the driver message of the complete XML format to the device through the NETCONF standard channel module.
  • the NETCONF standard channel module acts as the client and the device acts as the server.
  • the service configuration in Table 1 is sent to the driver message of the device "Node1".
  • the following is the driving message of the VRF module that is finally formed to the device in the example of the embodiment of the present application:
  • the above two drive messages can be combined and only the NETCONF delivery interface is called once.
  • the controller can flexibly manage devices of different manufacturers, and can not write specific drive interfaces for devices of different manufacturers, or can manage their respective devices without using different controllers.
  • the same function the implementation scheme of different vendors' equipment is different. If there is special treatment on the device function, it may affect the controller, and the controller considers the coupling relationship with the device.
  • the decoupling between the controller and the device function can be realized, and the coupling between the device and the controller can be solved by processing the device driver table dependency relationship, thereby maintaining the stability of the controller frame. Since the type of the newly added management device does not need to modify the implementation code of the controller, the online upgrade of the device can be easily implemented without restarting the controller, thereby ensuring the stability of the network.
  • the device driver table can be dynamically adjusted according to actual needs, and only the service-related functions are imported, and some temporarily unnecessary device interfaces can be not converted into the driver table to reduce the processing pressure of the controller.
  • the technical solution of the present application can be embodied in the form of a software product stored in a storage medium (such as Read-Only Memory (ROM) / Random Access Memory (Random).
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • disk disk
  • optical disk a plurality of instructions are included to enable a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method described in each embodiment of the present application.
  • a device management device is also provided, which is used to implement the foregoing embodiments, and details are not described herein.
  • the term "module” can implement a combination of software and hardware for a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 8 is a structural diagram of a device management apparatus according to an embodiment of the present application. As shown in FIG. 8, the apparatus includes:
  • the receiving module 132 is configured to receive a service deployment request, where the service deployment request carries a routing device to be deployed and a service to be deployed.
  • the obtaining module 134 is connected to the receiving module 132, and is configured to obtain, in a preset service mapping table, a device driving entry corresponding to the service to be deployed, where the device driving entry is used in the device driving table.
  • the sending module 136 is connected to the obtaining module 134, and is configured to obtain the device driving packet according to the device driving entry corresponding to the service to be deployed, and send the obtained device driving packet to the execution of the to-be-deployed service.
  • the routing device wherein the device driving message carries content that belongs to the implementation of the routing device that performs the service to be deployed.
  • the obtaining module 134 is configured to obtain, according to the identification information corresponding to the service to be deployed in the service deployment request, the device driver entry corresponding to the identifier information from the preset service mapping table, where SDN The controller assigns a unique identification information to each service in the current SDN network.
  • the obtaining module 134 is further configured to establish, by using at least one of the following manners, before the SDN controller acquires the device driver entry corresponding to the to-be-deployed service in the preset service mapping table.
  • the service mapping table is configured to establish a first service mapping table for each service in the current SDN network; and establish a second service mapping table according to the southbound interface definition of the SDN controller.
  • the obtaining module 134 is further configured to: after establishing the first service mapping table for each service in the current SDN network, managing the first service mapping table according to the following device information: device manufacturer, device Model, version information of the device, and the type of operation of the service;
  • the obtaining module 134 is further configured to: after establishing the second service mapping table according to the southbound interface definition of the SDN controller, managing the second service mapping table according to the following device information: device manufacturer, device model, device Version information, and the identity of the southbound interface of the SDN controller.
  • the acquiring module is configured to: the SDN controller selects a service mapping table corresponding to the delivery mode according to the delivery manner of the service to be deployed;
  • the SDN controller acquires a device driver entry corresponding to the to-be-deployed service in the service mapping table corresponding to the delivery mode.
  • the service mapping table corresponding to the delivery mode includes:
  • the delivery mode that is to be delivered by the service to be deployed is corresponding to the first service mapping table.
  • the delivery mode delivered by the southbound interface corresponds to the second service mapping table.
  • the sending module 136 is configured to create a device driving model according to the device driving table item, and acquire the device driving message according to the created device driving model.
  • the device driver table further includes: a driving message node composition relationship of each routing device, where the driving message composition relationship is indicated by at least the following information: a node name, a node data organization form, a parent The node, the data tree root node, and the depth of the node in the data tree.
  • the sending module 136 is further configured to: create at least one tree node corresponding to the device driving table entry according to the device driving table item and the driving message composition relationship; and the at least one tree A data tree composed of shaped nodes serves as the device driving model.
  • the sending module 136 is configured to complete, by using a NETCONF session with the routing device that performs the service to be deployed, a capability notification of the routing device that performs the service to be deployed; The module 136 is further configured to send the device-driven message to the routing device that performs the service to be deployed according to the capability in the capability notification.
  • the device-driven message when the service mapping table includes an attribute field of a specified service, the device-driven message carries an attribute field of the specified service obtained from the service mapping table.
  • the acquiring module 134 updates the following. At least one item: the service mapping table and a device driver table in which the device driver entry is located.
  • each of the foregoing modules may be implemented by software or hardware.
  • the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or each of the above modules They are located in different processors in any combination.
  • a storage medium comprising a stored program, wherein the program is executed to perform the method described in any of the above embodiments.
  • processor being arranged to run a program, wherein the program is executed to perform the method described in any of the above embodiments.
  • each of the above-described modules or steps of the present application can be implemented by a general-purpose computing device, which can be centralized on a single computing device or distributed over a network of multiple computing devices.
  • they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into one or more integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module.
  • the device management method, device, processor and storage medium provided by the disclosure solve the problem that when the controller manages devices of different vendors in the SDN network, the driver is written and configured for each device, thereby causing the management process of the controller to be cumbersome.
  • the problem is that the SDN controller can not write corresponding drivers for devices of different vendors, can manage routing devices of different vendors, and simplify the management process of the controller.

Abstract

本文公开了一种设备管理方法包括：SDN接收到用户输入的业务部署请求，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备，在预设业务映射表中查询与待部署业务对应的设备驱动表项，依据该设备驱动表项创建设备驱动报文，将设备驱动报文发送至执行所述待部署业务的路由设备上。还公开了一种设备管理装置、一种处理器以及存储介质。

Description

设备管理方法、装置、处理器以及存储介质 技术领域
本公开涉及通信技术领域，例如，涉及一种设备管理方法、装置、处理器以及存储介质。
背景技术
网络配置(NETCONF)协议，由请求评议(Request For Comments，RFC)6241定义，用以替代命令行界面(command line interface，CLI)、简单网络管理协议(Simple Network Management Protocol，SNMP)以及其它专有配置机制。
管理软件可以使用NETCONF协议将配置数据写入设备，也可以从设备中检索数据。所有数据用可扩展标记语言(Extensible Markup Language，XML)编码，通过安全套接层(Secure Sockets Layer，SSL)或传输层安全这类安全、面向连接的协议，使用远程过程调用(remote procedure calls，RPCs)方式传输。
NETCONF协议定义了多个数据存储，或多套配置数据。正在运行的配置数据存储包含当前设备正在使用的配置信息。一些设备还储存启动配置数据，其中，该启动配置数据中包含设备第一次启动时的配置数据，但是，设备第一次启动时的配置数据和运行中的配置数据是分离的。
除了配置数据，设备还储存状态数据和信息，如包统计数据、运行中设备收集的其他数据。控制软件可以读取这些状态数据和信息，但是不能写入。
候选配置数据存储是一个可选的设备性能。如果启用候选配置数据存储，根据它包含的一组配置数据，控制器能用来更新正在运行的数据存储，以及修改设备操作。
一旦NETCONF会话开始，控制器和设备就会交换一组“特性”。这组“特性”包括一些信息，如NETCONF协议版本支持列表、备选数据是否为候选配置数据、是否存在运行中的数据存储可修改的方式。除此之外，“特性”在NETCONF RFC中定义，开发人员可以通过遵循RFC中描述的规范格式添加额 外的“特性”。
NETCONF协议的命令集由读取、修改设备配置数据、以及读取状态数据的一系列命令组成。命令通过RPCs进行沟通，并以远程过程调用(Remote Procedure Call，RPC)回复来应答。一个RPC回复要响应一个RPC才能返回。一个配置操作由一系列RPC组成，每个RPC都有与其对应的RPC回复。
所选择的传输协议要保证RPC按发送顺序传递给设备，而且RPC回复要按照发起RPC的顺序被接收。除了从控制器向设备发送命令，设备也可以发出通知来告知控制器设备上的一些事件。
软件定义网络(Software Defined Network，SDN)，是一种新型网络架构，是网络虚拟化的一种实现方式，其主要核心思想是要通过将网络设备的信令控制面与数据转发面分离，构建开放可编程的网络体系结构，来实现网络流量的灵活控制，使网络作为管道变得更加智能。
因此，随着SDN技术的部署和推广，其推动业务创新已经是业界不争的事实，它可以被广泛地应用在云数据中心、宽带传输网络、移动网络等多种场景中。随着越来越多的业务应用被研发，网络用户能够便捷地通过SDN北向接口调用底层网络能力，按需使用网络资源。
SDN通过标准的南向接口屏蔽了底层物理转发设备的差异，来实现资源的虚拟化，同时开放了灵活的北向接口供上层业务按需进行网络配置并调用网络资源。这样，网络资源可以和其他类型的虚拟化资源一样，以抽象的资源能力的面貌统一呈现给业务应用开发者，开发者无需针对底层网络设备的差异耗费大量开销从事额外的适配工作，这有助于业务应用的快速创新。
但是，在实际应用中，网络应用场景比许多预期要复杂得多。不同厂商的设备不论硬件上还是软件上，都具有较大的差异。所支持的南向协议也有所不同(当前可以用于SDN南向协议的有：开源流表(OpenFlow)协议、NETCONF协议、边界网关协议(Border Gateway Protocol，BGP)、开放虚拟交换机数据库(Open Virtual Switch Database，OVSDB)、可扩展通讯和表示协议(Extensible Messaging and Presence Protocol，XMPP)以及面向传输的多协议标签交换(Multi-Protocol Label Switching-Transport Profile，MPLS-TP)等)，且上述中没有任何一种可以满足全部要求。另外，还存在SDN网络和传统网络的混合工作、 每种SDN控制器所实现的功能不同等问题。这些问题或差异的存在使得由一款控制器管理不同厂商的设备存在较大困难。实际应用中，在没有形成标准的南向接口之前，大多数情况下，不同设备商的设备只能由其自己开发的控制器进行管理。由一款控制器管理不同厂商的设备存在较大的困难。如果要由一款控制器管理不同厂商的设备，必须在控制器上为不同的设备编写专门的驱动模块。这使得管理新设备时，必须相应地去修改控制器。当控制器管理的设备类型较多时，也会增加控制器的运行负担。如果要升级设备功能，即使控制器的功能没有变化，也得相应地升级驱动模块，增加了不小的维护成本和风险。
因此，在SDN网络中由一款控制器管理不同厂商的设备时，需要为每一种设备编写和配置驱动，从而导致控制器的管理过程繁琐。
发明内容
本申请实施例提供了一种设备管理方法、装置、设备以及存储介质，以至少解决相关技术中在SDN网络中控制器管理不同厂商设备时，为每一种设备编写和配置驱动，进而导致控制器的管理过程繁琐的问题。
根据本申请的一个实施例，提供了一种设备管理方法，包括：软件定义网络SDN控制器接收业务部署请求，其中，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备；所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，其中，所述设备驱动表项为设备驱动表里用于指示所述SDN控制器所管理的路由设备的属性信息的表项；所述SDN控制器依据所述待部署业务对应的设备驱动表项获取设备驱动报文，并将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，其中，所述设备驱动报文携带属于所述执行所述待部署业务的路由设备的实现的内容。
根据本申请的另一个实施例，还提供了一种设备管理装置，包括：接收模块，设置为接收业务部署请求，其中，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备；获取模块，设置为在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，其中，所述设备驱动表项为设备驱动表里用于指示所述SDN控制器所管理的路由设备的YANG模型属性信息的表项；发送模块，设置为依据所述待部署业务对应的设备驱动表项获取设备驱动报文，并将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备， 其中，所述设备驱动报文携带属于所述执行所述待部署业务的路由设备的实现的内容。
根据本申请的又一个实施例，还提供了一种存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行上述任一项实施例中所述的方法。
根据本申请的再一个实施例，还提供了一种处理器，所述处理器设置为运行程序，其中，所述程序运行时执行上述任一项实施例中所述的方法。
通过本申请的技术方案，解决了在SDN网络中控制器管理不同厂商设备时，为每一种设备编写和配置驱动，进而导致控制器的管理过程繁琐的问题，SDN控制器不用为不同厂商的路由设备编写对应的驱动就可以管理不同厂商的路由设备，简化了控制器的管理过程。
附图说明
图1是根据本申请实施例的一种设备管理方法的流程图；
图2是本申请实施例提供的一种软件定义网络中基于NETCONF管理不同设备的方法的流程示意图；
图3是本申请实施例提供的一种软件定义网络中基于NETCONF管理不同设备的方法的业务实例拓扑图；
图4是本申请实施例示例中设备驱动表管理模块的设备驱动表创建流程示意图；
图5是本申请实施例示例中SDN控制器将业务数据整体下发时的业务映射表创建流程示意图；
图6是本申请实施例示例中SDN控制器按南向接口下发业务时的业务映射表创建流程示意图；
图7是本申请实施例示例中NETCONF报文动态生成模块以业务数据通过检索对应的业务映射表和设备驱动表动态生成和下发NETCONF报文的流程图；
图8是根据本申请实施例的一种设备管理装置的结构图。
具体实施方式
实施例一
本申请文件中的技术方案可以应用于SDN网络。
在一实施例中，以NETCONF作为南向接口时，按照RFC6020的要求，设备的接口虽然会有着复杂的定义，其树形结构的数据模型中的节点可以有不同的类型定义，但是最终下发给设备的报文都是XML格式的字符串报文。因此可以考虑将控制器的NETCONF南向接口通道化，即不用感知设备NETCONF接口的内容，报文的内容改为由设备YANG模型定义，控制器业务数据与该YANG模型的对应关系动态生成驱动报文，来达到控制器与设备实现的解耦，实现一款控制器管理不同厂商的设备的目的。
在本实施例中提供了一种运行于SDN网络的设备管理方法，图1是根据本申请实施例的一种设备管理方法的流程图，如图1所示，该流程包括如下步骤：
S102，软件定义网络SDN控制器接收业务部署请求，其中，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备。
S104，所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，其中，所述业务映射表存储有当前SDN网络中的每种业务与设备驱动表项的对应关系，所述设备驱动表项为设备驱动表里用于指示所述SDN控制器所管理的路由设备的属性信息的表项；一实施例中，所述设备驱动表项是设备定义的驱动接口的子集。
S106，所述SDN控制器依据所述待部署业务对应的设备驱动表项获取设备驱动报文，并将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，其中，所述设备驱动报文携带属于所述执行所述待部署业务的路由设备的实现的内容。
通过上述步骤，在SDN网络中预先建立存储有所有业务与设备驱动表项对应关系的业务映射表，设备驱动表项所在的设备驱动表中记录有SDN网络中的路由设备的设备型号和版本信息等属性信息。SDN接收到用户输入的业务部署请求，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备，在预设业务映射表中查询与待部署业务对应的设备驱动表项，依据该设备驱动表项创建设备驱动报文，将设备驱动报文发送至执行所述待部署业务的路由设备上。采用上述技术方案，解决了在SDN网络中控制器管理不同厂商设备 时，为每一种设备编写和配置驱动，进而导致控制器的管理过程繁琐的问题，SDN控制器不用为不同厂商的路由设备配置对应的驱动就可以管理不同厂商的路由设备，简化了控制器的管理过程。
一实施例中，所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，包括：所述SDN控制器根据业务部署请求中待部署业务对应的标识信息，从预设的业务映射表中获取与所述标识信息对应的设备驱动表项，其中，所述SDN控制器为当前SDN网络中每种业务均分配一个标识信息，其中，所述标识信息用于对每种业务进行唯一标识。
一实施例中，所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项之前，所述SDN控制器通过以下至少一种方式建立所述业务映射表：所述SDN控制器为当前SDN网络中的每种业务建立第一业务映射表；所述SDN控制器按照所述SDN控制器的南向接口定义建立第二业务映射表。
一实施例中，在所述SDN控制器为当前SDN网络中的每种业务建立所述第一业务映射表之后，所述SDN控制器按照以下设备信息管理所述第一业务映射表：设备厂商，设备型号，设备的版本信息，以及业务的操作类型；在所述SDN控制器按照所述SDN控制器的南向接口定义建立所述第二业务映射表之后，所述SDN控制器按照以下设备信息管理所述第二业务映射表：设备厂商，设备型号，设备的版本信息，以及所述SDN控制器的南向接口的标识。
一实施例中，所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，包括：所述SDN控制器根据所述待部署业务的下发方式选择与所述下发方式对应的业务映射表，所述SDN控制器在所述与所述下发方式对应的业务映射表中获取与所述待部署业务对应的设备驱动表项。其中，所述待部署业务整体下发的下发方式对应于所述第一业务映射表；通过南向接口下发的下发方式对应于所述第二业务映射表。
一实施例中，所述SDN控制器依据所述待部署业务对应的设备驱动表项获取设备驱动报文，包括：所述SDN控制器依据所述设备驱动表项创建设备驱动模型；根据创建的所述设备驱动模型获取所述设备驱动报文。
一实施例中，所述设备驱动表中还包括：每个路由设备的驱动报文节点组 成关系(即：YANG模型节点组成关系)，其中，至少通过以下信息指示所述驱动报文节点组成关系：节点名称、节点数据组织形式、父节点、数据树根节点、以及节点在所述数据树中的深度。
一实施例中，所述SDN控制器依据所述设备驱动表项创建设备驱动模型，包括：所述SDN控制器依据所述设备驱动表项和所述驱动报文节点组成关系，创建至少一个与所述设备驱动表项对应的树形节点；将所述至少一个树形节点组成的数据树作为所述设备驱动模型。
一实施例中，所述SDN控制器将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，包括：所述SDN控制器通过与所述执行所述待部署业务的路由设备之间的NETCONF会话完成所述执行所述待部署业务的路由设备的能力通告；所述SDN控制器依据所述路由设备上报的能力将所述设备驱动报文发送至所述执行所述待部署业务的路由设备。
一实施例中，在所述业务映射表中包括有指定业务的属性字段的情况下，所述设备驱动报文中携带有从所述业务映射表获取的所述指定业务的属性字段。
一实施例中，在所述执行所述待部署业务的路由设备更新版本后，或者在所述执行所述待部署业务的路由设备替换为其他路由设备后，所述SDN控制器更新下述至少一项：所述业务映射表和所述设备驱动表项所在的设备驱动表。
本申请实施例克服控制器在使用NETCONF作为南向接口管理不同厂商的设备时，为每一种新增类型设备开发独立驱动模块和进行繁琐适配的问题和缺陷，提供一种根据SDN控制器的功能实现和设备YANG模型的对应关系，动态生成适应该设备的驱动报文，下发到网络设备以形成转发面信息或完成对设备的操作，来实现同一款SDN控制器管理不同厂商的设备的方法。
本申请实施例提供一种软件定义网络中基于NETCONF管理不同设备的方法，该方法可以通过以下执行方法的模块来实现，执行该方法的模块包括：业务配置管理模块、NETCONF标准通道模块、设备驱动表管理模块、业务映射模块、以及NETCONF报文动态生成模块。
业务配置管理模块通过北向接口接收用户的业务部署请求，在经过一系列计算后，形成包含转发面信息的业务数据模型。在通过NETCONF标准通道模块将转发面信息和配置信息下发给对应的设备之前，设备驱动表管理模块先将 网络中所有支持NETCONF的设备驱动模型(一般是符合RFC6020的要求的YANG文件或者XML格式文件，后面统称为设备YANG模型)解析形成对应的设备驱动表。SDN控制器按设备厂商、设备型号、以及设备版本来管理这些驱动表。然后，SDN控制器通过业务映射模块来建立业务映射表，来表示业务数据模型与设备驱动表的映射关系。NETCONF报文动态生成模块在获取业务的转发面信息和配置信息后，根据业务映射表和设备驱动表动态产生NETCONF报文，再通过NETCONF标准通道模块将报文下发到设备，完成在网络设备上的部署业务或者对设备的操作。
在一实施例中，SDN控制器的设备驱动表管理模块设置为将设备YANG模型解析形成该设备的设备驱动表，该设备驱动表包含下面几部分内容：设备支持的NETCONF协议版本信息、设备YANG模型中节点之间的组成关系以及设备模块之间的依赖关系等。
其中，设备支持的NETCONF协议版本信息等和NETCONF会话建立过程中设备通告的能力(Capabilities)、对标准“协议操作(Protocol Operations)”类型的支持情况、以及对数据存储的支持情况等信息，是NETCONF标准通道模块用来建立与设备的NETCONF通道的基础信息。设备YANG模型中节点的组成关系包括：设备YANG模型中节点的名称、父节点信息、以及所属树形结构的层次等信息。可以根据这些信息还原出设备YANG模型的树形结构。
设备模块之间的依赖关系包括：对业务进行某种操作(如创建、删除、更新)时，该设备模块之间的先后顺序、附加要素或者特殊处理等，设备模块是指软件模块，设置为编写特定代码的模块。
业务映射模块管理的是控制器的业务数据模型和设备YANG模型的对应关系，即控制器的数据定义对应到设备YANG模型的节点定义。控制器的业务数据模型中，每种业务属性都会被分配一个全局唯一标识，通过这个标识可以检索到标识对应的设备驱动表的一个或者多个表项。业务映射表中，这个对应关系有完整性要求，没有先后顺序要求。其中，完整性要求是指控制器上每种业务数据项的定义都要求表中有一个或者多个表项来表示与设备YANG模型节点的映射关系。
NETCONF标准通道模块根据设备驱动表中的设备对NETCONF支持信息， 协商建立起与所要管理设备的NETCONF会话。其中，控制器作为客户端，设备作为服务端。
NETCONF报文动态生成模块是控制器根据业务信息，通过检索业务映射表获得设备驱动表的对应信息，形成符合设备数据模型的驱动报文，并通过NETCONF标准通道模块建立的NETCONF会话，将驱动报文发送给设备，完成转发面信息或者操作信息的下发。
图2是根据本申请实施例提供的一种软件定义网络中基于NETCONF管理不同设备的方法的流程示意图，如图2所示，该方法中的多个模块设置为执行以下步骤：
第一步：
SDN控制器通过设备驱动表管理模块解析所有的设备YANG模型，以设备厂商、设备型号、以及版本信息作为键值，按照设备的模块划分，建立起该设备的一系列驱动表。
该设备驱动表包含所支持NETCONF的版本信息和能力信息等，控制器可以根据这些信息与该设备建立NETCONF通道，并获得设备通告的能力、协议操作类型、以及数据存储的支持信息等，NETCONF标准通道模块可以根据这些参数自行决定RPC接口中的一些参数。
该设备驱动表还包含设备YANG模型中每个节点的组成关系，包括：节点名称、节点数据组织形式(如leaf(叶节点)、list(列表)、或者leaf-list(叶节点列表))、父节点、数据树根节点、以及该节点在数据树中的深度等信息。
第二步：
控制器需要为控制器的业务数据模型中的每种业务属性都分配一个全局唯一标识，通过这个标识可以从业务映射表中检索到标识对应的设备驱动表的一个或者多个表项。
业务映射模块为整个业务，或者按照自己的南向接口定义建立业务映射表。
对于整个业务的映射表，是指可以通过这个表将整个业务一次性下发到设备。控制器需要按设备厂商、设备型号、版本信息以及操作类型来管理这些表，并且在映射表中按操作类型建立设备模块间的依赖关系。
而对于南向接口对应的映射表，是指可以通过这个表将该接口包含的业务属性下发到设备。控制器需要按设备厂商、设备型号、版本信息以及南向接口的唯一标识来管理这些表。当南向接口涉及到设备多个模块时，也需要在映射表中建立设备相关模块间的依赖关系。
业务映射表还支持按照设备实现的差异，自动创建出部分驱动报文。不同设备的功能集有所不同，和控制器的数据模型定义也可能有着较大差异，设备部分定义可能在控制器数据模型中找不到对应的属性，但是该字段又是设备上创建该业务的必选属性，这种情况可以通过映射表的自动创建功能来满足要求。
控制器还需要建立控制器枚举类型与设备枚举类型的对应关系的映射表，这些映射表也按设备厂商、设备型号、以及版本信息来进行管理。
第三步：
业务配置管理模块通过北向接口接收用户的业务部署请求，在经过一系列计算后，形成包含转发面信息和配置信息的业务数据模型；然后根据业务部署的要求，选择是以整个业务下发或者通过特定南向接口完成部分信息的下发。
第四步：
SDN控制器在部署整个业务或者调用南向接口时，NETCONF报文动态生成模块按厂商、设备型号、以及版本等信息检索到对应的映射表，通过映射表中条目创建对应的设备驱动表目。在创建每一个驱动表条目时，都以迭代方式，根据节点的组成关系，创建出该节点所处树形模型中的所有与之有关联的上层节点，并根据关联关系创建出该节点的关联节点及其对应的树形结构。当创建到该树形结构的根节点时，这次迭代处理结束，并得到一个或者多个符合设备YANG模型的数据树。
映射表中每个条目的映射处理，都会按上面描述进行迭代处理。但是，当所要创建的节点已经存在时，则不再重复创建。
当操作类型为删除(如协议操作类型中为“edit-config”(编辑配置)的“delete”(删除)或者“remove”(移除)操作)时，为了避免对设备模型的所有节点进行删除，对删除的节点进行一次合并：当树形数据中的一个节点和该节点的父节点都有删除操作时，在该节点不用于识别业务的唯一标识的情况下，将该节 点从树形数据模型中删除。
当形成完整的树形数据模型后，将该树形结构模型转换成对应的XML格式的驱动报文。
第五步：
在设备驱动报文创建完成后，控制器的NETCONF标准通道模块作为客户端与所要操作设备建立NETCONF会话和完成能力通告。然后可以根据设备通告的能力，控制器选择协议操作类型(如：“edit-config”)和配置数据的存储方式(如：“candidate”(备选)或者“running”(运行))等参数，将驱动报文下发给对应的设备，完成所需的操作或者形成数据的转发面。
第六步：
当设备的版本更新或者替换成其它设备时，按最新版本的设备YANG模型更新驱动表和业务映射表；重新按上面的步骤处理即可实现对该新设备的管理。
图3是本申请实施例提供的一种软件定义网络中基于NETCONF管理不同设备的方法的业务实例拓扑图，如图3所示，用户通过同款网络设备“Node1”(节点1)和“Node2”(节点2)，将三个本来不连通的局域网连接成一个可以互通的虚拟私有网络(Virtual Private Network，VPN)。其中，网络设备“Nodel”的接口“Gei-1”和接口“Gei-2”分别设置为连接网络“network-a”(网络a)和“network-b”(网络b)，网络设备“Node2”的接口“Gei-3”设置为连接网络“network-c”(网络c)。SDN控制器通过NETCONF方式管理两个设备，其中，SDN控制器作为NETCONF客户端，设备作为NETCONF服务端。
以下是本申请实施例示例中SDN控制器中VPN业务数据模型，即：SDN控制器中用于该VPN的数据模型，其中“node-name”(节点名称)用于表示网络设备，其余属性定义都是和业务相关。
Figure PCTCN2018089240-appb-000001
Figure PCTCN2018089240-appb-000002
以下是本申请实施例示例中设备的VRF模块的YANG模型：
Figure PCTCN2018089240-appb-000003
Figure PCTCN2018089240-appb-000004
以下是本申请实施例示例中设备的接口模块的YANG模型：
Figure PCTCN2018089240-appb-000005
Figure PCTCN2018089240-appb-000006
VRF模块的YANG模型和接口模块的YANG模型是所用网络设备的YANG模型定义中的两个相关模块的模型定义，这两个模块是VRF模块和接口模块。网络设备的YANG模型还包括其它模块，如服务质量(Quality of Service，QOS)、隧道等，但是与本次所举例功能无关，因此不需要在代码体现。
控制器经过计算后，形成的需要下发给设备的数据，表1是控制器业务数据表，如表1所示。下面按本申请实施例所述的方法(如图2所示)，对将这些数据下发给设备的过程进行说明。
表1
Figure PCTCN2018089240-appb-000007
Figure PCTCN2018089240-appb-000008
实例一
图4是本申请实施例示例中设备驱动表管理模块的设备驱动表创建流程示意图。其中，在导入所需模型的设备YANG模型是指不需要全部导入设备的YANG模型，而是可以根据控制器的功能实现，只导入相关的设备YANG模型，以及其中一个模块YANG模型的部分相关节点。当只导入其中一个模块YANG模型的部分相关节点时，则导入节点的结构完整，不要出现孤立的节点。
如图4所示，设备驱动表管理模块的设备驱动表创建流程主要包括以下几个步骤：
S701：控制器通过配置或者主动识别的方式获取(或识别)设备的厂商、型号、以及版本信息为管理键值，初始化管理模块和建立起对应的设备驱动表；
S702：控制器解析设备的YANG模型，该模型通常是指设备符合RFC6020要求的对外暴露的操作接口对应的YANG文件，并且会按设备定义的模块，定义出对应的YANG文件。解析的内容主要是YANG文件中节点的名称和节点数据组织形式(如leaf、list、或者leaf-list)等信息。解析工具可以通过工具自动 完成，以提高效率。
S703：根据控制器的功能实现，导入所需模块的YANG模型和模型中相关的节点信息。即：不需要全部导入设备的YANG模型，而是可以根据控制器的功能实现，只导入相关的设备YANG模型，以及其中一个模块YANG模型的部分相关节点。当只导入其中一个模块YANG模型的部分相关节点时，则导入节点的结构完整，不要出现孤立的节点。在过滤掉和要求功能无关的模块和节点信息后，剩余的YANG模型仍然符合RFC6020的规则要求。
S704：生成对应的设备驱动表节点间的组成关系：控制器将解析好的设备YANG模型的模块名称、节点名称、节点数据组织形式、以及父节点等信息存入到对应的设备驱动表中去。按照本实施例的步骤执行完成后，所形成的设备驱动表如表2所示，表2是根据实例一的设备驱动表(不包含支持NETCONF的版本信息和能力信息等)，其中，由于VRF模型中的“function-a”(功能a)和“function-b”(功能b)和本次功能无关，因此不需要导入该驱动表中。
表2
Figure PCTCN2018089240-appb-000009
Figure PCTCN2018089240-appb-000010
实例二
图5是本申请实施例示例中SDN控制器将业务数据整体下发时的业务映射表创建流程示意图，如图5所示，为本申请实施例的业务以整体方式下发设备时的业务映射表创建流程示意图。业务以整体方式下发，是将业务所有属性定义和操作类型一起存入到业务映射表的方式。该表的管理键值为操作类型和对应设备的设备驱动表的管理键值的组合。NETCONF报文动态生成模块会根据该表形成所有模块的驱动报文，一次性下发给设备。其实现方法主要包括以下几个步骤：
S801：控制器以设备的厂商、型号、版本信息以及操作类型为键值，初始化业务映射管理模块和建立起对应的业务映射表(整体映射表)。
S802：控制器为该业务所有的属性定义都分配一个全局唯一标识，按操作类型分别存入业务映射表；业务映射表中的每一个表项都对应一个或多个设备驱动表项。
S803：控制器按操作类型为设备驱动表建立模块间的依赖关系。该依赖关系决定着不同模块间、以及模块内部驱动报文的下发顺序。
S804：根据设备的实现方式和特性，在映射表中设置自动创建的节点。这些节点属于设备的实现，没有控制器属性字段与之对应，但是又是驱动报文中 携带的内容。
S805：控制器创建设备YANG模型中定义的枚举类型与控制器定义的枚举类型之间的映射表，该映射表以设备的厂商、型号、以及版本信息为键值进行管理。
按照本实施例的步骤执行完成后，以“创建”操作为例，在相同的管理简直下，所形成的业务映射表和枚举类型映射表如表3所示，表3是根据实例二的业务映射表，其中，映射表中的属性没有先后顺序要求，但是有完整性要求，即业务的所有属性都要包含在里面。接口模块的配置在VRF模块的配置之后下发。设备接口模块支持多个互联网协议IP地址配置，根据设备的实现要求，自动创建“primary-or-secondly”(初级或次级)节点，并设置为“primary”(初级)类型。控制器“rt-type”(路由类型)节点和其对应的设备节点都是枚举类型，因此对其进行枚举类型转换。
表3
Figure PCTCN2018089240-appb-000011
表4是根据实例二的枚举类型映射表。
表4
Figure PCTCN2018089240-appb-000012
实例三
图6是本申请实施例示例中SDN控制器按南向接口下发业务时的业务映射表创建流程示意图，图6所示，为本申请实施例的以单个南向接口方式下发设备时的业务映射表创建流程示意图。以单个南向接口方式下发，是将该接口中相关的业务属性定义存入到业务映射表、并为这些属性建立与设备驱动表的表项建立对应的关系。该表的管理键值为对应设备的设备驱动表的管理键值和该南向接口唯一标识的组合。NETCONF报文动态生成模块会根据该表形成相关模块的驱动报文，一次性下发给设备。其实现方法主要包括以下几个步骤：
S901：控制器为每个南向接口分配一个全局唯一的标识。
S902：制器以设备的厂商、型号、版本信息以及该南向接口标识为键值，初始化业务映射管理模块和建立起对应的业务映射表。
S903：在映射表中增加该接口所包含的业务属性与设备驱动表项的映射关系：控制器在该南向接口的映射表中，为所有的参数都创建表项，每一个表项都对应一个或多个设备驱动表项。
S904：控制器为该南向接口所涉及的设备驱动表建立模块间的依赖关系。该依赖关系决定着不同模块间、以及模块内部驱动报文的下发顺序。
S905：根据设备的实现方式和特性，在该南向接口所涉及的驱动表中设置自动创建的节点。这些节点属于设备的实现，没有接口参数与之对应，但是又是驱动报文中的携带的内容。
S906：控制器创建设备YANG模型中定义的枚举类型与控制器定义的枚举类型之间的映射表；该映射表以设备的厂商、型号、以及版本信息为管理键值 进行管理。
如果控制器有个用于将私有网络连接入该VPN的南向接口“add-ac”(接入控制地址)，其参数除了设备标识外，还包括“vpn-name”(虚拟私有网络名称)、“ac-name”(接入控制名称)、“ip-address”(互联网协议地址)、“ip-mask”(子网掩码)。那么按照本实施例的步骤执行完成后，在相同的管理键值下，所形成的业务映射表如表5所示，表5是根据实例三的南向接口的业务映射表。南向接口的业务映射表中的属性没有先后顺序要求，但是有完整性要求，即接口的所有参数都要包含在里面。由于该南向接口的参数只涉及到设备的接口模块，因此没有模块间的依赖关系。设备接口模块支持多个IP地址配置，根据设备的实现要求，自动创建“primary-or-secondly”(初级或次级)节点，并设置为“primary”(初级)类型。由于不处理枚举类型数据，因此此处不需要创建枚举类型映射表。
表5
Figure PCTCN2018089240-appb-000013
实例四
图7是本申请实施例示例中NETCONF报文动态生成模块以业务数据通过检索对应的业务映射表和设备驱动表动态生成和下发NETCONF报文的流程图，如图7所示，为申请实施例的NETCONF报文动态生成模块在将业务数据对应 的转发面信息和配置信息下发给设备的处理流程。本模块以所要下发的业务数据，通过检索对应的业务映射表和设备驱动表动态生成和下发NETCONF报文的流程图。其实现方法主要包括以下几个步骤：
S1001：控制器通过北向接口接收业务请求，在控制器内部完成计算、形成需要下发给设备的配置和转发面的信息。
S1002：控制器根据业务下发的方式定位到对应的业务映射表。然后根据所需要下发的业务数据逐一从该映射表检索出对应的映射条目，当映射条目存在时，则执行S1003；当检索不到映射条目时，则表示映射条目处理完成，需要去执行S1007。
S1003：控制器根据映射条目对应的设备驱动表的表项，创建设备驱动模型。在创建每一个驱动表条目时，都需要以迭代方式，根据节点的组成关系创建出该节点所处树形模型中的所有与之有关联的上层节点；当创建到该树形结构的根节点时，这次迭代处理结束，并得到一个符合设备驱动模型的数据树。当需要创建的驱动表条目已经存在，则不需要重复创建，并继续按原有流程处理下去。
S1004：控制器创建驱动表条目时，判断该条目是否与其他模块有依赖关系，或者有自动创建的驱动条目。当不符合条件时，则转到S1002，继续处理下一个映射条目；当符合条件时，则执行S1005。
S1005：控制器同样以迭代方式创建依赖模块的设备驱动模型，并加入到之前已经创建的设备模型中。
S1006：控制器同样以迭代方式创建设备要自动创建的节点(或模块)，并加入到之前已经创建的设备模型中。然后转到S1002继续执行。
S1007：控制器结合设备模块间的依赖关系，将已经创建完整的设备驱动模型转换成XML格式的NETCONF驱动报文。设备模块间的依赖关系由报文的先后顺序来体现。
S1008：控制器通过NETCONF标准通道模块，将已经创建完整的XML格式的驱动报文下发给设备。其中，NETCONF标准通道模块作为客户端，而设备作为服务端。
按照本实施例的步骤执行完成后，以“创建”操作为例，将表1中的业务配置下发给设备“Nodel”的驱动报文。以下是本申请实施例示例中最终形成的下发给设备的VRF模块的驱动报文：
Figure PCTCN2018089240-appb-000014
以下是本申请实施例示例中最终形成的下发给设备的接口模块的驱动报文：
Figure PCTCN2018089240-appb-000015
Figure PCTCN2018089240-appb-000016
上述两个驱动报文可以组合在一起，只调用一次NETCONF下发接口。
采用上述技术方案，控制器可以很灵活地管理起不同厂商的设备，而可以不为不同厂商的设备编写特定的驱动接口，或者可以不用不同的控制器来管理各自的设备。同一种功能，不同厂商设备的实现方案是不同的，如果设备功能实现上有特殊处理，则可能会对控制器造成影响，及控制器考虑与设备的耦合关系。而采用本方法，可以实现控制器与设备功能的解耦，设备与控制器的耦合可以通过对设备驱动表依赖关系的处理解决掉，从而保持控制器架的稳定。由于新增管理设备的类型不需要再修改控制器的实现代码，因此可以很容易地实现设备的在线升级，而不需要重启控制器，从而保证网络的稳定。在管理不同设备时，由于不需要设备进行改动，如果传统网络中的设备已经支持NETCONF，那么就很容易将传统网络升级到SDN网络或者实现共管，降低网络维护成本。可以根据实际需要，动态地调整设备驱动表，只导入业务相关的功能，而一些暂时不需要的设备接口可以不转换到驱动表中，以减轻控制器的处理压力。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器(Read-Only Memory，ROM)/随机存取存储器(Random Access Memory，RAM)、磁碟、光盘)中，包括多个指令用以使得一台终端设 备(可以是手机，计算机，服务器，或者网络设备等)执行本申请每个实施例所述的方法。
实施例二
在本实施例中还提供了一种设备管理装置，该装置用于实现上述实施例，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
根据本申请的另一个实施例，还提供了一种设备管理装置，图8是根据本申请实施例的一种设备管理装置的结构图，如图8所示，该装置包括：
接收模块132，设置为接收业务部署请求，其中，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备；
获取模块134，连接至所述接收模块132，设置为在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，其中，所述设备驱动表项为设备驱动表里用于指示所述SDN控制器所管理的路由设备的属性信息的表项；
发送模块136，连接至所述获取模块134，设置为依据所述待部署业务对应的设备驱动表项获取设备驱动报文，并将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，其中，所述设备驱动报文携带属于所述执行所述待部署业务的路由设备的实现的内容。
一实施例中，所述获取模块134是设置为根据业务部署请求中待部署业务对应的标识信息，从预设的业务映射表中获取与所述标识信息对应的设备驱动表项，其中，SDN控制器为当前SDN网络中每种业务均分配一个唯一的标识信息。
一实施例中，所述获取模块134还设置为在所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项之前，通过以下至少一种方式建立所述业务映射表：为当前SDN网络中的每种业务建立第一业务映射表；和按照所述SDN控制器的南向接口定义建立第二业务映射表。
一实施例中，所述获取模块134还设置为在为当前SDN网络中的每种业务 建立所述第一业务映射表之后，按照以下设备信息管理所述第一业务映射表：设备厂商，设备型号，设备的版本信息，以及业务的操作类型；
所述获取模块134还设置为在按照所述SDN控制器的南向接口定义建立所述第二业务映射表之后，按照以下设备信息管理所述第二业务映射表：设备厂商，设备型号，设备的版本信息，以及所述SDN控制器的南向接口的标识。
一实施例中，所述获取模块是设置为所述SDN控制器根据所述待部署业务的下发方式选择与所述下发方式对应的业务映射表；
所述SDN控制器在所述与所述下发方式对应的业务映射表中获取与所述待部署业务对应的设备驱动表项。
其中，所述与所述下发方式对应的业务映射表，包括：
所述待部署业务整体下发的下发方式对应于所述第一业务映射表；
通过南向接口下发的下发方式对应于所述第二业务映射表。
一实施例中，所述发送模块136是设置为依据所述设备驱动表项创建设备驱动模型；根据创建的所述设备驱动模型获取所述设备驱动报文。
一实施例中，所述设备驱动表中还包括：每个路由设备的驱动报文节点组成关系，其中，至少通过以下信息指示所述驱动报文组成关系：节点名称、节点数据组织形式、父节点、数据树根节点、以及节点在所述数据树中的深度。
一实施例中，所述发送模块136还设置为依据所述设备驱动表项和所述驱动报文组成关系创建至少一个与所述设备驱动表项对应的树形节点；将所述至少一个树形节点组成的数据树作为所述设备驱动模型。
一实施例中，所述发送模块136是设置为通过与所述执行所述待部署业务的路由设备之间的NETCONF会话完成所述执行所述待部署业务的路由设备的能力通告；所述发送模块136还设置为依据所述能力通告中的能力将所述设备驱动报文发送至所述执行所述待部署业务的路由设备。
一实施例中，在所述业务映射表中包括有指定业务的属性字段的情况下，所述设备驱动报文中携带有从所述业务映射表获取的所述指定业务的属性字段。
一实施例中，在所述执行所述待部署业务的路由设备更新版本后，或者， 在所述执行所述待部署业务的路由设备替换为其他路由设备后，所述获取模块134更新下述至少一项：所述业务映射表和所述设备驱动表项所在的设备驱动表。
在一实施例中，上述每个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述每个模块以任意组合的形式分别位于不同的处理器中。
实施例三
根据本申请的另一个实施例，还提供了一种存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行上述任一项实施例中所述的方法。
实施例四
根据本申请的另一个实施例，还提供了一种处理器，所述处理器设置为运行程序，其中，所述程序运行时执行上述任一项实施例中所述的方法。
本领域的技术人员应该明白，上述的本申请的每个模块或每个步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，一实施例中，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在部分情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成一个或多个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。
工业实用性
本公开提供的设备管理方法、装置、处理器以及存储介质，解决了在SDN网络中控制器管理不同厂商的设备时，为每一种设备编写和配置驱动，进而导致控制器的管理过程繁琐的问题，SDN控制器可以不用为不同厂商的设备编写对应的驱动，可以管理不同厂商的路由设备，简化了控制器的管理过程。

Claims (15)

  1. 一种设备管理方法，包括：
    软件定义网络SDN控制器接收业务部署请求，其中，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备；
    所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，其中，所述设备驱动表项为设备驱动表里用于指示所述SDN控制器所管理的路由设备的属性信息的表项；
    所述SDN控制器依据所述待部署业务对应的设备驱动表项获取设备驱动报文，并将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，其中，所述设备驱动报文携带属于所述执行所述待部署业务的路由设备的实现的内容。
  2. 根据权利要求1所述的方法，其中，所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，包括：
    所述SDN控制器根据业务部署请求中待部署业务对应的标识信息，从预设的业务映射表中获取与所述标识信息对应的设备驱动表项，其中，所述SDN控制器为当前SDN网络中每种业务均分配一个唯一的标识信息，。
  3. 根据权利要求1所述的方法，还包括：在所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项之前，所述SDN控制器通过以下至少一种方式建立所述业务映射表：
    所述SDN控制器为当前SDN网络中的每种业务建立第一业务映射表；
    所述SDN控制器按照所述SDN控制器的南向接口定义建立第二业务映射表。
  4. 根据权利要求3所述的方法，还包括：
    在所述SDN控制器为当前SDN网络中的每种业务建立所述第一业务映射表之后，所述SDN控制器按照以下设备信息管理所述第一业务映射表：设备厂商，设备型号，设备的版本信息，以及业务的操作类型；
    在所述SDN控制器按照所述SDN控制器的南向接口定义建立所述第二业务映射表之后，所述SDN控制器按照以下设备信息管理所述第二业务映射表： 设备厂商，设备型号，设备的版本信息，以及所述SDN控制器的南向接口的标识。
  5. 根据权利要求3或4所述的方法，其中，所述SDN控制器在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，包括：
    所述SDN控制器根据所述待部署业务的下发方式选择与所述下发方式对应的业务映射表；
    所述SDN控制器在所述与所述下发方式对应的业务映射表中获取与所述待部署业务对应的设备驱动表项。
  6. 根据权利要求5所述的方法，其中，所述与所述下发方式对应的业务映射表，包括：所述待部署业务整体下发的下发方式对应于所述第一业务映射表；
    通过南向接口下发的下发方式对应于所述第二业务映射表。
  7. 根据权利要求1-6任一项所述的方法，其中，所述SDN控制器依据所述待部署业务对应的设备驱动表项获取设备驱动报文，包括：
    所述SDN控制器依据所述设备驱动表项创建设备驱动模型；
    根据创建的所述设备驱动模型获取所述设备驱动报文。
  8. 根据权利要求7所述的方法，其中，所述设备驱动表中还包括：每个路由设备的驱动报文节点组成关系，其中，至少通过以下信息指示所述驱动报文节点组成关系：节点名称、节点数据组织形式、父节点、数据树根节点、以及节点在所述数据树中的深度。
  9. 根据权利要求8所述的方法，其中，所述SDN控制器依据所述设备驱动表项创建设备驱动模型，包括：
    所述SDN控制器依据所述设备驱动表项和所述驱动报文节点组成关系，创建至少一个与所述设备驱动表项对应的树形节点；
    将所述至少一个树形节点组成的数据树作为所述设备驱动模型。
  10. 根据权利要求1-9任一项所述的方法，其中，所述SDN控制器将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，包括：
    所述SDN控制器通过与所述执行所述待部署业务的路由设备之间的网络配 置NETCONF会话完成所述执行所述待部署业务的路由设备的能力通告；
    所述SDN控制器依据所述能力通告中的能力将所述设备驱动报文发送至所述执行所述待部署业务的路由设备。
  11. 根据权利要求1-10任一项所述的方法，还包括：在所述业务映射表中包括有指定业务的属性字段的情况下，所述设备驱动报文中携带有从所述业务映射表获取的所述指定业务的属性字段。
  12. 根据权利要求1-11任一项所述的方法，还包括：
    在所述执行所述待部署业务的路由设备更新版本后，或者在所述执行所述待部署业务的路由设备替换为其他路由设备后，所述SDN控制器更新下述至少一项：所述业务映射表和所述设备驱动表项所在的设备驱动表。
  13. 一种设备管理装置，包括：
    接收模块，设置为接收业务部署请求，其中，所述业务部署请求中携带有待部署业务和执行所述待部署业务的路由设备；
    获取模块，设置为在预设的业务映射表中获取与所述待部署业务对应的设备驱动表项，其中，所述设备驱动表项为设备驱动表里用于指示SDN控制器所管理的路由设备的属性信息的表项；
    发送模块，设置为依据所述待部署业务对应的设备驱动表项获取设备驱动报文，并将获取的所述设备驱动报文发送至执行所述待部署业务的路由设备，其中，所述设备驱动报文携带属于所述执行所述待部署业务的路由设备的实现的内容。
  14. 一种存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至12任一项中所述的方法。
  15. 一种处理器，所述处理器设置为运行程序，其中，所述程序运行时执行上述权利要求1至12任一项中所述的方法。
PCT/CN2018/089240 2017-05-31 2018-05-31 设备管理方法、装置、处理器以及存储介质 WO2018219322A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710399206.X 2017-05-31
CN201710399206.XA CN108989066B (zh) 2017-05-31 2017-05-31 设备管理方法及装置

Publications (1)

Publication Number Publication Date
WO2018219322A1 true WO2018219322A1 (zh) 2018-12-06

Family

ID=64455166

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/089240 WO2018219322A1 (zh) 2017-05-31 2018-05-31 设备管理方法、装置、处理器以及存储介质

Country Status (2)

Country Link
CN (1) CN108989066B (zh)
WO (1) WO2018219322A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113014411A (zh) * 2019-12-20 2021-06-22 华为技术有限公司 管理网络设备的方法、设备和系统
CN113609130A (zh) * 2021-07-30 2021-11-05 中电金信软件有限公司 获取网关接入数据的方法、装置、电子设备及存储介质
US20220231909A1 (en) * 2019-06-21 2022-07-21 Nippon Telegraph And Telephone Corporation Plug-in generation device, controller, plug-in generation method, and plug-in generation program
CN115065594A (zh) * 2022-06-08 2022-09-16 亚信科技（中国）有限公司 数据配置方法、装置、设备、可读存储介质及程序产品
EP4187814A4 (en) * 2020-07-23 2023-12-27 ZTE Corporation DATA PROCESSING METHOD AND DEVICE

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109885339A (zh) * 2018-12-29 2019-06-14 航天信息股份有限公司 税控设备驱动控制方法及装置
CN111832273A (zh) * 2019-04-10 2020-10-27 中兴通讯股份有限公司 目的报文的确定方法及装置、存储介质、电子装置
CN112241276B (zh) * 2019-07-19 2022-04-22 华为技术有限公司 一种设备的升级方法及装置
CN112737805B (zh) * 2019-10-28 2024-04-12 华为技术有限公司 一种配置方法、相关装置和系统
CN111092765B (zh) * 2019-12-19 2022-11-08 迈普通信技术股份有限公司 智能驱动方法、系统、电子设备及可读存储介质
CN112671556B (zh) * 2020-12-04 2023-06-02 珠海格力电器股份有限公司 路由器的配置方法和装置、存储介质、电子装置
CN112399452B (zh) * 2021-01-21 2021-06-22 中兴通讯股份有限公司 版本配置方法、装置、设备、系统及存储介质
CN114205205A (zh) * 2022-02-15 2022-03-18 北京华环电子股份有限公司 一种兼容不同yang模型的南向接口实现方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150163314A1 (en) * 2013-12-05 2015-06-11 Huawei Technologies Co., Ltd. Control Method, Control Device, and Process in Software Defined Network
CN105227342A (zh) * 2014-06-27 2016-01-06 瞻博网络公司 用于网络服务域中的服务规划和配置的图形数据库
CN106330504A (zh) * 2015-06-29 2017-01-11 华为技术有限公司 一种实现应用的方法及业务控制器

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104753746B (zh) * 2013-12-30 2018-04-27 华为技术有限公司 一种接入设备的方法及控制服务器
CN104753709B (zh) * 2013-12-30 2018-04-27 华为技术有限公司 一种设备管理的方法及控制服务器
CN104753713B (zh) * 2013-12-31 2019-02-05 华为技术有限公司 一种sdn部署业务的方法和sdn控制器
FI20145041L (fi) * 2014-01-17 2015-07-18 Tellabs Oy Verkkoelementti ja kontrolleri verkkoelementin hallitsemiseksi
CN105722124A (zh) * 2014-12-01 2016-06-29 中兴通讯股份有限公司 配置rru设备的方法以及rru设备、中间设备
CN105610714B (zh) * 2016-02-04 2019-04-23 广州海格通信集团股份有限公司 Sdn网络的控制方法和装置以及sdn控制器

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150163314A1 (en) * 2013-12-05 2015-06-11 Huawei Technologies Co., Ltd. Control Method, Control Device, and Process in Software Defined Network
CN105227342A (zh) * 2014-06-27 2016-01-06 瞻博网络公司 用于网络服务域中的服务规划和配置的图形数据库
CN106330504A (zh) * 2015-06-29 2017-01-11 华为技术有限公司 一种实现应用的方法及业务控制器

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220231909A1 (en) * 2019-06-21 2022-07-21 Nippon Telegraph And Telephone Corporation Plug-in generation device, controller, plug-in generation method, and plug-in generation program
CN113014411A (zh) * 2019-12-20 2021-06-22 华为技术有限公司 管理网络设备的方法、设备和系统
CN113014411B (zh) * 2019-12-20 2022-11-22 华为技术有限公司 管理网络设备的方法、设备和系统
EP4187814A4 (en) * 2020-07-23 2023-12-27 ZTE Corporation DATA PROCESSING METHOD AND DEVICE
CN113609130A (zh) * 2021-07-30 2021-11-05 中电金信软件有限公司 获取网关接入数据的方法、装置、电子设备及存储介质
CN113609130B (zh) * 2021-07-30 2023-06-13 中电金信软件有限公司 获取网关接入数据的方法、装置、电子设备及存储介质
CN115065594A (zh) * 2022-06-08 2022-09-16 亚信科技（中国）有限公司 数据配置方法、装置、设备、可读存储介质及程序产品
CN115065594B (zh) * 2022-06-08 2024-03-26 亚信科技（中国）有限公司 数据配置方法、装置、设备、可读存储介质及程序产品

Also Published As

Publication number Publication date
CN108989066A (zh) 2018-12-11
CN108989066B (zh) 2022-12-20

Similar Documents

Publication Publication Date Title
WO2018219322A1 (zh) 设备管理方法、装置、处理器以及存储介质
US10693762B2 (en) Data driven orchestrated network using a light weight distributed SDN controller
US11677619B2 (en) Selectable declarative requirement levels
US11611487B2 (en) Model driven process for automated deployment of domain 2.0 virtualized services and applications on cloud infrastructure
CN109104318B (zh) 用于实现集群自适应部署的方法
CN110383765B (zh) 使用图形模型的计算机基础结构的配置、遥测和分析
US11429369B2 (en) Distributed upgrade in virtualized computing environments
US9710762B2 (en) Dynamic logging
EP2849064B1 (en) Method and apparatus for network virtualization
US10826768B2 (en) Controlled node configuration
CN112311606B (zh) 一种用于构建虚实解耦仿真网络的方法
TW201928699A (zh) 雲端服務管理方法
EP3905598A1 (en) Message processing method and apparatus, control plane device, and computer storage medium
CN110784333B (zh) 跨网络服务的有关网络配置协议装置的并发事务
US10176005B2 (en) Environment virtualization
US10942785B2 (en) Integration of software applications with infrastructure
TW202121869A (zh) 虛擬網路功能的管理系統和管理方法
US11582099B1 (en) Predictive pipeline analytics for a network management system
CN111416732B (zh) 一种sdn中网络设备扩容自动配置业务的方法及装置
US9578090B1 (en) Methods for provisioning application delivery service and devices thereof
WO2020009014A1 (ja) 管理装置およびネットワーク管理方法
US20240007364A1 (en) Method, Apparatus, and System for Deploying Service
Kanada A node plug-in architecture for evolving network virtualization nodes
US20230094033A1 (en) Decentralized software upgrade image distribution for network device upgrades
WO2019154121A1 (zh) 参数配置的处理方法、装置、存储介质及处理器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18810035

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18810035

Country of ref document: EP

Kind code of ref document: A1