WO2021104103A1 - 网络控制器框架和数据处理方法 - Google Patents

网络控制器框架和数据处理方法 Download PDF

Info

Publication number
WO2021104103A1
WO2021104103A1 PCT/CN2020/129319 CN2020129319W WO2021104103A1 WO 2021104103 A1 WO2021104103 A1 WO 2021104103A1 CN 2020129319 W CN2020129319 W CN 2020129319W WO 2021104103 A1 WO2021104103 A1 WO 2021104103A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
service
data
model
northbound
Prior art date
Application number
PCT/CN2020/129319
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 WO2021104103A1 publication Critical patent/WO2021104103A1/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/12—Discovery or management of network topologies
    • 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
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • 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/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • 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/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • This application relates to the technical field of communication networks, for example, to a network controller and a data processing method.
  • SDN Software Defined Network
  • the network can be defined and controlled in the form of software programming.
  • the control plane and data plane in SDN can evolve independently, which helps to solve the problem of network rigidity. Improving the programmability of the network has greatly promoted the development of the next-generation Internet.
  • mainstream controller frameworks mainly include OpenDaylight and Open Network Operating System (ONOS).
  • the mainstream controller framework integrates the northbound adaptation module, the core function module and the southbound protocol stack.
  • the multiple modules of this controller framework have a large degree of coupling and serious interdependence, which is not conducive to the full version upgrade of the controller. , Extend the software development cycle, reduce the efficiency of software development, and weaken the performance of SDN.
  • This application provides a network controller framework and data processing method.
  • the embodiment of the present application provides a network controller framework, including:
  • a southbound controller, a core controller, and a northbound controller is connected to the core controller, is configured to be connected to a hardware communication device, and sends the topology data obtained from the hardware communication device to the The core controller, and, sending the service configuration information obtained from the core controller to the hardware communication device, and sending the service activation result obtained from the hardware communication device to the core controller;
  • the core controller is connected to the northbound controller, and is configured to abstract topology data obtained from the southbound controller as model data, upload the model data to the northbound controller, and
  • the service request obtained by the northbound controller and the topology data obtained from the southbound controller generate service configuration information, the service configuration information is delivered to the southbound controller, and the service configuration information is sent from the southbound controller.
  • the service activation result and the service configuration information obtained from the controller are abstracted into a service activation model, and the service activation model is uploaded to the northbound controller; the northbound controller is set to be connected to the upper-layer application, and all The model data sent by the core controller is uploaded to the upper application, and the service request obtained from the upper application is issued to the core controller, and the service activation model sent by the core controller Upload to the upper application.
  • the embodiment of the present application also provides a data processing method, which is applied to a southbound controller, and includes:
  • the embodiment of the present application also provides another data processing method, which is applied to the core controller, and the method includes:
  • the embodiment of the present application also provides another data processing method, which is applied to a northbound controller, and the method includes:
  • FIG. 1 is a schematic structural diagram of a network controller framework provided by an embodiment of this application.
  • Figure 2a is an example diagram of a network controller framework provided by an embodiment of the application.
  • FIG. 2b is an example diagram of another network controller framework provided by an embodiment of this application.
  • FIG. 2c is an example diagram of another network controller framework provided by an embodiment of this application.
  • FIG. 3 is a schematic structural diagram of another network controller framework provided by an embodiment of this application.
  • FIG. 4 is a schematic structural diagram of another network controller framework provided by an embodiment of this application.
  • FIG. 5 is a schematic structural diagram of another network controller framework provided by an embodiment of this application.
  • FIG. 6 is a schematic structural diagram of another network controller framework provided by an embodiment of this application.
  • FIG. 7 is a flow chart of the steps of a data processing method provided by an embodiment of the application.
  • FIG. 8 is a flow chart of the steps of another data processing method provided by an embodiment of the application.
  • FIG. 9 is a flow chart of the steps of another data processing method provided by an embodiment of the application.
  • FIG. 10 is a flowchart of steps of another data processing method provided by an embodiment of this application.
  • FIG. 11 is a flowchart of the steps of another data processing method provided by an embodiment of the application.
  • FIG. 12 is a flowchart of the steps of another data processing method provided by an embodiment of the application.
  • FIG. 13 is a flowchart of the steps of another data processing method provided by an embodiment of the application.
  • Figure 1 is a schematic structural diagram of a network controller framework provided by an embodiment of this application.
  • the embodiment of this application can be applied to SDN, and can connect hardware communication devices with upper-layer applications.
  • the network controller framework can be applied to network devices.
  • the network controller framework provided by the embodiment of the present application includes a southbound controller 10, a core controller 11 and a northbound controller 12.
  • the southbound controller 10 may be the controller responsible for communicating with hardware communication devices in SDN, and may exchange data with the hardware communication device; the northbound controller 12 may be the controller responsible for communicating with upper-layer applications in SDN.
  • the core controller 11 can be the controller responsible for core functions in the SDN, which can determine service configuration information and store topology data; the southbound controller 10, the core controller 11, and the northbound controller 12 It can be integrated in a device with data processing functions, and can exist in the form of software, hardware, and a combination of software and hardware. Referring to Fig. 2a, the southbound controller 10, the core controller 11, and the northbound controller 12 in the embodiment of the present application can be integrated in the same device 1 at the same time; refer to Fig.
  • the southbound controller in the embodiment of the present application 10 and the northbound controller 12 can be integrated in the device 2, and the core controller 11 is separately provided in the device 3.
  • the device 2 and the device 3 can be connected in a wired or wireless manner; see Figure 2c, the southbound in the embodiment of the present application
  • the controller 10, the core controller 11, and the northbound controller 12 may be provided in the device 4, the device 5, and the device 6, respectively, and multiple devices are connected in a wired or wireless manner.
  • the southbound controller 10 is respectively connected to the core controller 11 and the hardware communication device, and is configured to send topology data and service activation results obtained from the hardware communication device to the core controller 11, and from The service configuration information obtained by the core controller 11 is delivered to the hardware communication device.
  • the southbound controller 10 is connected to a hardware communication device in a wired or wireless manner.
  • the hardware communication device may be a device responsible for data exchange, and may include hardware devices such as switches.
  • the southbound controller 10 can monitor the hardware communication devices. When the link relationship between the hardware communication devices changes, the southbound controller 10 can obtain the link relationship as topology data.
  • the southbound controller 10 may send the topology data and service activation results obtained from the hardware communication device to the core controller 11, and the core controller 11 may process the topology data and service activation results.
  • the southbound controller 10 may also obtain service configuration information from the core controller 11.
  • the service configuration information may be the node for processing the service and the path for transmitting information determined according to the service request of the upper application.
  • the southbound controller 10 After receiving the service configuration information sent by the core controller 11, the service configuration information can be delivered to the hardware communication device, and the hardware communication device can complete the service configuration according to the service configuration information.
  • the core controller 11 is respectively connected to the southbound controller 10 and the northbound controller 12, and is configured to generate service configuration information according to the service request obtained from the northbound controller 12, and deliver the service configuration information To the southbound controller 10, the topology data and service activation results obtained from the southbound controller 10 are abstracted to generate model data and service activation models respectively, and they are uploaded to the northbound controller 12.
  • the core controller 11 can implement core functions in the SDN, and can generate service configuration information according to service requests and model data and service activation models respectively according to topology data and service activation results.
  • the core controller 11 can be connected to the southbound controller 10 and the northbound controller 12 in a wired or wireless manner, and the core controller 11 can obtain the topology data and service activation results sent by the southbound controller 10, which can be combined with the topology data and the northbound controller.
  • the service provisioning results respectively generate abstract model data and service provisioning models; the core controller 11 can obtain the service request issued by the northbound controller 12, where the service request can be the request information generated by the upper application according to the business needs, which can be controlled by the northbound
  • the device 12 sends the data packet to the core controller 11. After the core controller 11 obtains the service request, it can determine the forwarding path of the data packet according to the information in the service request and the topology data.
  • the northbound controller 12 is respectively connected to the core controller 11 and the upper-layer application, and is configured to issue service requests obtained from the upper-layer application to the core controller 11, and to transfer the core controller 11. Upload the sent model data to the upper application.
  • the northbound controller 12 can be connected to an upper-layer application through an application interface.
  • the connection between the northbound controller 12 and the upper-layer application can be a logical connection.
  • the upper-layer application can be located on the same device as the northbound controller 12, or It is located at a different device from the northbound controller 12.
  • the upper-layer application can send a service request to the northbound controller 12 in order to realize the service.
  • the service request may be the request information for the upper-layer application to call the hardware communication device.
  • the upper-layer application may send the service request to the northbound controller 12, and the upper-layer application may be Multiple, multiple upper-layer applications can all send service requests to the northbound controller 12.
  • the core controller 11 can upload the model data and the service activation model that are abstractly generated according to the topology data and the service activation result to the northbound controller 12, and the northbound controller 12 can upload the acquired model data, where the model data can be based on
  • the data generated by the topology data can include link models, port models, service opening models, etc.
  • the model data can be processed by upper-layer applications.
  • the southbound controller, the core controller, and the northbound controller work independently.
  • the southbound controller obtains the topology data of the hardware communication device, the service activation result, and sends the service configuration information to Hardware communication equipment
  • the northbound controller obtains the service request of the upper application and uploads the model data to the upper application.
  • the core controller abstracts the topology data and service activation result into model data and service activation model respectively, and determines the service configuration information according to the service request .
  • Multiple controllers jointly replace the SDN Zhongyuan controller, which reduces the coupling degree of the controller software, reduces the difficulty of software development, shortens the startup time of the controller, and improves the performance of SDN data processing.
  • Figure 3 is a schematic structural diagram of another network controller framework provided by an embodiment of this application.
  • the embodiment of this application illustrates the connection mode of each controller in the network controller framework.
  • Multiple controllers can use message middleware.
  • the southbound controller 10 may be connected to the core controller 11 through the message middleware 13
  • the northbound controller 12 may be connected to the core controller 11 through the message middleware 13 Core controller 11.
  • the message middleware 13 may be a communication channel for transmitting topology data, service activation results, and service requests, and may be remote procedure call (RPC) protocol middleware and data flow processing middleware, etc., message The middleware 13 connects the southbound controller 10 and the northbound controller 12 to the core controller 11 respectively, and topology data, service activation results, and service requests can be transferred among multiple controllers through the message middleware 13.
  • RPC remote procedure call
  • FIG. 4 is a schematic structural diagram of another network controller framework provided by an embodiment of the application.
  • the message middleware 13 includes a topology data transmission middleware 132 and a business information transmission middleware 131
  • the topology data transmission middleware 132 includes at least two data exchange queues
  • the first data exchange queue 1321 is configured to send the topology data from the southbound controller 10 to the core controller 11, and
  • the second data exchange queue 1322 is configured to send the model data from the core controller 11 to the northbound controller 12
  • the service information transmission middleware 131 includes at least two message transmission channels
  • the first The message transmission channel is configured to send the service request from the northbound controller 12 to the core controller 11 and send the service activation model from the core controller 11 to the northbound controller 12, and second The message transmission channel is set to send the service configuration information from the core controller 11 to the southbound controller 10 and send the service activation result from the southbound controller 10 to the core controller 11 .
  • the topology data transmission middleware 132 may be a middleware that transmits topology data, and can transmit topology data from the south controller 10 to the core controller 11 and transfer model data from the core controller 11 to the north controller.
  • the topological data transmission middleware 132 may be a streaming data processing platform, for example, it may be a Kafka streaming processing platform.
  • the topology data transmission middleware 132 may include two data exchange queues. One data exchange queue may be set to transmit topology data from the southbound controller 10 to the core controller 11, and the other data exchange queue may be set to transmit model data from the core.
  • the controller 11 transmits to the northbound controller 12, where the model data may be topology data that has undergone abstraction processing, and the model data may include link models, ports, and service provisioning models.
  • the topological data transmission middleware 132 may include a first data exchange queue 1321 and a second data exchange queue 1322.
  • the southbound controller 10 may send the acquired topology data to the first data exchange queue 1321
  • the core controller 11 may send the acquired model data to the second data exchange queue 1322
  • the core controller 11 may send the acquired model data from the first data exchange queue 1322.
  • the topology data is obtained from the data exchange queue 1321
  • the northbound controller 12 can obtain the model data from the second data exchange queue 1322
  • the topology data is sent to the data exchange queue and the data obtained from the data exchange queue does not affect each other.
  • the controller 10, the core controller 11, and the northbound control 12 can perform the functions of sending data and acquiring data, respectively.
  • the service information transmission middleware 131 may include at least two message transmission channels.
  • the message transmission channel may be an RPC protocol framework that can transmit request information, service activation results, and service configuration information.
  • the service information transmission middleware 131 may include the first message The transmission channel and the second message transmission channel respectively perform information transmission between the southbound controller 10 and the core controller 11 and between the core controller 11 and the northbound controller 12.
  • the business information transmission middleware 131 may include frameworks such as Thrift, Dubbo, Spring Cloud, and Google RPC (gRPC).
  • the Kafka server is started in the initial state to receive messages, and the southbound controller 10 acts as a Kafka message producer to communicate with the acquired hardware
  • the topology data of the device is reported to the Kafka server through the topic as the topology.
  • the core controller 11 subscribes to the corresponding topic to receive the message reported by the southbound controller 10, and abstracts the topology data into the database after internal model abstraction; at the same time, performs the internal abstract model storage operation
  • Monitoring when the topology database changes are monitored, the data after the internal model abstraction is sent to the Kafka server through another topic.
  • the core server 11 is the producer of Kafka, so the core server 11 is responsible for the whole topology reporting process.
  • the southbound controller 10 is a consumer, and the northbound controller 12 is a producer.
  • the northbound controller 12 subscribes the abstracted model data of the core controller 11 to the Kafka server.
  • the northbound controller 12 acts as a consumer of Kafka messages. When the northbound controller 12 receives the message, it performs the northbound model conversion and storage in the library. Different requirements are converted to northbound models, and at the same time, they are reported to upper-level applications in the form of notifications.
  • the business information transmission middleware as the gRPC framework as an example, after the topological data report is completed, when the business request of the upper application reaches the northbound controller 12, it is converted and processed by the corresponding adaptation module of the northbound controller 12, and then passed through the gRPC framework
  • the initialized channel sends a service request to a core controller 11, where there can be multiple core controllers 11, the network address and port of the core controller can be specified when the channel is initialized, and the service request passes through the serialization framework protocol buffer (Protocol Buffers, protobuf) are transmitted to the core controller 11.
  • the service request In the core controller 11, the service request is deserialized.
  • the core controller 11 internally calls the calculation module interface to return to the optimal path, and finally establishes the business on the calculated optimal path.
  • the core modules such as business and calculation path use internal Abstract model data for data interaction.
  • the related configuration of the service establishment will be sent to the southbound controller 10 through gRPC, and the southbound controller 10 will send the related configuration of the service establishment to the hardware communication device to establish the service through the southbound protocol.
  • the hardware communication device can feed back the service activation result of the established service to the southbound controller 10.
  • the south controller 10 can feed back to the northbound controller 12 through the core controller 11, and the northbound controller 12 can send the service activation result to Upper application.
  • FIG. 5 is a schematic structural diagram of another network controller framework provided by an embodiment of the application.
  • the southbound controller 10 in the embodiment of the present application may include a protocol management plug-in 101 and a topology data storage module 102, and the northbound controller 12 It may include a northbound application interface 121 and a model data storage module 122.
  • the core controller 11 includes a path calculation module 111, a service module 112, a model abstraction module 113, and a data storage module 114.
  • the southbound controller 10 includes: a protocol management plug-in 101 and a topology data storage module 102; wherein the protocol management plug-in 101 is configured to implement at least one communication protocol of the hardware communication device; the topology data storage module 102. Set to store the topology data obtained from the hardware communication device.
  • the protocol management plug-in 101 can exchange data with the hardware communication device through the stored communication protocol, and the protocol management plug-in 101 can be set with multiple communication protocols, including Openflow, Network Configuration (NETCONF), One or more of the Open Virtual Switch Data Base (OVSDB) and other protocols, the topology data storage module 102 can store the topology data of the hardware communication device obtained by the southbound controller 10, and the stored topology data It can include the current status and link information of the hardware communication device.
  • NETCONF Openflow, Network Configuration
  • OVSDB Open Virtual Switch Data Base
  • the topology data storage module 102 can store the topology data of the hardware communication device obtained by the southbound controller 10, and the stored topology data It can include the current status and link information of the hardware communication device.
  • the northbound controller 12 includes: a northbound application interface 121 and a model data storage module 122; the northbound application interface 121 is set to implement at least one application interface of the upper layer application; the model data storage module 122 is set to The model data obtained from the core controller 11 is stored.
  • the northbound application interface 121 may be an interface for data exchange with upper-layer applications.
  • the northbound application interface 121 may have multiple application interface types, including application interfaces such as Transport Application Programming Interface (TAPI).
  • TAPI Transport Application Programming Interface
  • the northbound controller 12 can perform data exchange according to upper-layer applications corresponding to different application interfaces.
  • the model data storage module 122 may store the model data uploaded by the core controller 11, and the model data may be persistent storage in this application.
  • the core controller 11 includes a path calculation module 111, a service module 112, a model abstraction module 113, and a data storage module 114;
  • the path calculation module 111 is configured to determine communication path information according to the topology data and the service request;
  • the service module 112 is configured to assemble the communication path information into data messages corresponding to the southbound controller 10 and the northbound controller 12;
  • the model abstraction module 113 is configured to assemble the southbound
  • the topology data and service activation results uploaded by the controller 10 are respectively abstracted as model data and service activation models;
  • the data storage module 114 is configured to store the model data.
  • the path calculation module 111 may use the acquired topology data to perform path calculation on the calling port in the service request, and return the optimal path calculation result as the communication path information.
  • the path calculation module 111 may use the Dijkstra algorithm or the Floyd algorithm. Algorithm implementation.
  • the service module 112 assembles the communication path information into a data message corresponding to the southbound controller 10 and the northbound controller 12, wherein, due to different ports called by the service request, data corresponding to different protocols can be generated Message.
  • the model abstraction module 113 can store data forwarding models in advance, and can abstract topology data and service provisioning results into model data and service provisioning models respectively according to the pre-stored data forwarding model, where the model data can be represented under the corresponding forwarding model The way the hardware communication device forwards data.
  • the core controller 11 may also include a data storage module 114, which may store model data.
  • the network controller framework includes at least one core controller.
  • FIG. 6 is a schematic structural diagram of another network controller framework provided by an embodiment of the application.
  • multiple core controllers may form a core controller cluster, and the core controller cluster contains multiple distributions.
  • Core controller each core controller provides the core ability to deal with network equipment, including the function of calculation module, business module, model abstraction module and data storage module.
  • the core controller cluster realizes load balancing and increases concurrency.
  • the core controller cluster can be connected to the northbound controller and the southbound controller by binding network addresses or ports.
  • the southbound controller, the core controller, and the northbound controller jointly implement the software-defined network control function, and each controller is implemented independently, reducing the SDN function module
  • the degree of coupling between them facilitates software version upgrades, reduces the controller software development cycle, and can enhance the communication performance of SDN.
  • FIG. 7 is a step flow chart of a data processing method provided by an embodiment of the application.
  • the embodiment of the application can be applied to SDN, and can connect hardware communication devices with upper-layer applications.
  • the network controller framework can be applied to network devices. Referring to Fig. 1, the data processing method provided by the embodiment of the present application includes:
  • Step 201 The southbound controller obtains topology data, uploads the topology data from the southbound controller to the core controller, and the core controller abstracts the topology data into model data, and the model data is transferred from the core controller. The controller sends to the northbound controller.
  • the southbound controller may be connected to the hardware communication device in a wired or wireless manner.
  • the hardware communication device may be a device responsible for data exchange, and may include hardware devices such as switches.
  • the southbound controller can monitor the hardware communication devices, and when it is determined that the link relationship between the hardware communication devices changes, the southbound controller can obtain the link relationship as topology data.
  • the southbound controller can send the topology data obtained from the hardware communication device to the core controller, and the core controller can process the topology data, and the topology data can be abstracted into model data in the core controller.
  • the model data can be uploaded to the northbound controller.
  • Step 202 The northbound controller obtains a service request, and sends the service request from the northbound controller to the core controller.
  • the core controller determines service configuration information according to the topology data. Configuration information is sent from the core controller to the southbound controller.
  • the northbound controller can be connected to the upper application through an application interface.
  • the connection between the northbound controller and the upper application can be a logical connection.
  • the upper application and the northbound controller can be located on the same device or in a different device.
  • the upper-layer application can send a service request to the northbound controller to realize the service.
  • the service request can be the request information for the upper-layer application to call the hardware communication device.
  • the upper-layer application can send the service request to the northbound controller, and the northbound controller can send the service to the northbound controller.
  • the northbound controller can send the service request to the core controller, the core controller can determine to process the service request according to the service request and determine the service configuration information of the establishment service according to the topology data, and the core controller can determine the service configuration information for the service.
  • the configuration information is sent to the southbound controller, and the southbound controller can forward the service configuration information to each hardware communication device to implement service functions.
  • Step 203 The southbound controller obtains the service activation result, and sends the service activation result to the core controller, and the core controller abstracts the service activation result and the service configuration information into a service activation model ,
  • the service provisioning model is sent from the core controller to the northbound controller.
  • the southbound controller After the southbound controller sends the service configuration information to each hardware communication device, after each hardware communication device establishes a service according to the service configuration information, it can feed back the service activation result of the established service to the southbound controller.
  • the opening result may include establishment success and establishment failure.
  • the southbound controller can monitor each hardware communication device to obtain the service activation result. After obtaining the service activation result, the southbound controller can send the service activation result to the core controller, which can be configured by the core controller according to the service.
  • the information and service activation results are constructed into a service activation model, where the service activation model can be the service activation result and corresponding service configuration information stored in a data structure in a preset form, and the core controller can send the generated service activation model to the northbound controller ,
  • the northbound controller can transform the service provisioning model into the corresponding data structure form according to the corresponding interface of the upper-layer application, and the transformed service provisioning model can be sent from the northbound controller to the upper-layer application.
  • the southbound controller obtains the topology data of the hardware communication device and sends the service configuration information to the hardware communication device
  • the northbound controller obtains the service request of the upper application and uploads the model data to the upper application
  • the core controller abstracts the topology data and service activation results into model data and service activation models respectively, and determines service configuration information according to service requests.
  • Multiple controllers replace the SDN Central Plains controller, which reduces the degree of controller software coupling and reduces The difficulty of software development can shorten the startup time of the controller and improve the performance of SDN data processing.
  • FIG. 8 is a step flow chart of another data processing method provided by an embodiment of the application.
  • the embodiment of the application describes the topological data processing in the data processing method.
  • the data processing method of the embodiment of the application includes:
  • Step 311 The southbound controller obtains the topology data through at least one communication protocol.
  • the southbound controller can communicate with the hardware communication device through the communication protocol, and can obtain the topology information of the hardware communication device.
  • the topology information can include the current status information of the hardware communication device and the device link information, and the communication protocol can be related to the hardware communication device.
  • the communication protocol of the communication device includes at least one of the Openflow, NETCONF, and OVSDB communication protocols.
  • Step 312 The southbound controller stores the acquired topology data.
  • the southbound controller may persistently store the acquired topology data of the hardware communication device.
  • Step 313 The southbound controller sends the topology data to a first data exchange queue, and the core controller obtains the topology data from the first data exchange queue.
  • the first data exchange queue may be a server set to perform topology data exchange, and the topology data may be sent from the southbound controller to the core controller, and the first data exchange queue may be a topic in the stream processing platform queue.
  • the southbound controller can send topology data to the first data exchange queue, and the core controller can directly obtain the topology data from the first data exchange queue.
  • the southbound controller and the core controller can independently perform data sending and receiving processes, reducing The degree of coupling between the southbound controller and the core controller is described.
  • Step 314 The core controller abstracts the topology data into model data.
  • the core controller converts the topology data into model data representing the data forwarding model, and the model data can represent the way in which each hardware communication device forwards the data.
  • the core controller abstracts the topology data into model data according to a preset model; the core controller stores the model data.
  • the core controller may preset and store different preset models
  • the preset model may be a data forwarding model, which can reflect different data forwarding methods of hardware communication equipment
  • the core controller converts topology data according to the preset model It is model data, which can be stored persistently.
  • Step 315 The core controller sends the model data to a second data exchange queue, and the northbound controller obtains the model data from the second data exchange queue.
  • the second data exchange queue may be a server set to perform model data exchange, and the model data may be sent from the core controller to the northbound controller, and the second data exchange queue may be a topic queue in the stream processing platform .
  • the core controller can send the model data to the second data exchange queue, and the northbound controller can directly obtain the model data from the second data exchange queue.
  • the core controller and the northbound controller can independently send and receive data, which reduces the northbound The degree of coupling between the controller and the core controller.
  • Step 316 The northbound controller uploads the model data through at least one application interface.
  • the northbound controller can have multiple application interface types, including application interfaces such as TAPI.
  • the northbound controller can upload model data to the corresponding upper application according to different application interfaces.
  • Step 317 The northbound controller stores the acquired model data.
  • the northbound controller may also persistently store the model data obtained from the core controller.
  • the technical solution of the embodiment of the present application obtains and stores topology data through the southbound controller, the southbound controller sends the topology data to the first data exchange queue, the core controller obtains the topology data from the first data exchange queue, and the core controller
  • the topology data is abstracted as model data.
  • the core controller sends the model data to the second data exchange queue.
  • the northbound controller obtains the model data from the second data exchange queue.
  • the northbound controller uses the application interface to upload the model data to realize the topology data in The flow between multiple controllers, based on the data exchange queue, reduces the degree of coupling between multiple controllers, and each controller can be upgraded differentially, ensuring that the SDN network function is not affected by the controller upgrade.
  • FIG. 9 is a step flow chart of another data processing method provided by an embodiment of the application.
  • the embodiment of the application describes the processing of a business request in the data processing method.
  • the data processing method of the embodiment of the application includes:
  • Step 321 The northbound controller obtains the service request through at least one application interface.
  • the northbound controller can use different application interfaces for data exchange with different upper-layer applications.
  • the upper-layer application calls the hardware communication device to complete the business requirements, it can use the application interface to
  • the service request is sent to the northbound controller, where the service request may include calling the port and network address of the hardware communication device.
  • Step 322 The northbound controller sends the service request to the core controller through the first message transmission channel.
  • the information interaction between the northbound controller and the core controller can be through the first message transmission channel, where the first message channel can be frameworks such as Thrift, Dubbo, Spring Cloud, and gRPC, which can send business requests from the northbound controller to Core controller.
  • first message channel can be frameworks such as Thrift, Dubbo, Spring Cloud, and gRPC, which can send business requests from the northbound controller to Core controller.
  • Step 323 The core controller determines service configuration information according to the topology data.
  • the core controller can obtain the topology data of the hardware communication device according to the service request, can determine the data transmission path and the data message type according to the topology data, and can correspond to the path and the data message type as the service request Business configuration information.
  • Step 324 The core controller sends the service configuration information to the southbound controller through a second message transmission channel.
  • the service configuration information can be sent from the core controller to the southbound controller through the second message transmission channel.
  • Step 325 The southbound controller issues the service configuration information through at least one communication protocol.
  • the southbound controller is connected to the hardware communication device through a communication protocol.
  • the service configuration information can be formatted according to the communication protocol corresponding to each hardware communication device, and the format can be converted.
  • the subsequent service configuration information is sent to the hardware communication device, and the communication protocol may include one or more of Openflow, NETCONF, OVSDB and other protocols.
  • the technical solution of the embodiment of the present application obtains the service request through the northbound controller application interface, the northbound controller transmits the service request to the core controller through the first message transmission channel, and the core controller determines the service configuration information according to the service request and topology data, The core controller sends the service configuration information to the southbound controller through the second message transmission channel, and the southbound controller sends the corresponding service configuration information to the hardware communication device according to the communication protocol, realizing rapid response to service requests and improving The processing speed of service requests enhances the performance of the SDN network.
  • the core controller determines the communication path information based on the information such as the port of the service request and the information such as each port and the topology data; the core controller assembles according to the information such as the communication path Data message.
  • the core controller can obtain information such as the port called by the upper application according to the service request, and can determine the shortest or optimal data transmission path corresponding to the service request as the communication path information according to the port information and the corresponding topology data, and then perform Package.
  • FIG. 10 is a step flow chart of another data processing method provided by an embodiment of the application.
  • the embodiment of the application describes the processing of service provisioning results in the data processing method.
  • the data processing method of the embodiment of the application includes:
  • Step 331 The southbound controller obtains the service activation result through at least one communication protocol.
  • the hardware communication device reports the service activation result according to whether the establishment of the service is successful, and the southbound controller uses different communication protocols to obtain the service activation result of the corresponding hardware communication device according to different hardware communication devices.
  • Step 332 The southbound controller sends the service activation result to the core controller through a second message transmission channel.
  • the southbound controller is connected to the core controller through the second message transmission channel, and after obtaining the service activation result, the southbound controller may send the service activation result to the core controller through the second message transmission channel .
  • Step 333 The core controller determines a service activation model according to the service activation result and the service configuration information.
  • the service activation model may be a service activation result stored according to a preset data structure.
  • the service activation model can be used by upper-layer applications.
  • the core controller processes the service activation result and service configuration information to generate a service activation model with a preset data structure.
  • Step 334 The core controller sends the service activation model to the northbound controller through the first message transmission channel.
  • the core controller can send the service provisioning model to the northbound controller, and the service provisioning model can be sent through the first message transmission channel, which can reduce the degree of coupling between the core controller and the northbound controller.
  • Step 335 The northbound controller uploads the service activation model through at least one application interface.
  • the northbound controller determines the corresponding application interface according to the type of the upper-layer application, and can send the service provisioning model from the northbound controller to the upper-layer application through the application interface.
  • Step 336 The northbound controller stores the acquired service provisioning model.
  • the northbound controller can persistently store the service provisioning model.
  • the southbound controller obtains the service activation results uploaded by different hardware communication devices through different communication protocols, and the southbound controller sends the service activation results to the core controller through the second message transmission channel, and the core controller Abstract business provisioning results and business configuration information as a business provisioning model, and transmit the business provisioning model to the northbound controller through the first message transmission channel between the core controller and the northbound controller, and the northbound controller sends the business provisioning model to the upper layer application.
  • the message transmission queue realizes the transmission of service activation results and service activation models among multiple controllers, which realizes rapid feedback of service activation results, reduces the coupling degree between multiple controllers, and realizes the differential upgrade of each controller version , Can enhance the performance of SDN network.
  • Fig. 11 is a flow chart of the steps of another data processing method provided by an embodiment of the application; when the southbound controller is in a separate communication control device, referring to Fig. 11, a data processing method includes:
  • Step 401 Obtain topology data of the hardware communication device, and send the topology data to the core controller.
  • step 401 includes: obtaining topology data of a hardware communication device through a preset communication protocol; sending the topology data to a data exchange queue so that the core controller obtains the data from the data exchange queue. Topological data.
  • Step 402 Obtain the service configuration information issued by the core controller, and issue the service configuration information to the hardware communication device.
  • step 402 includes: acquiring the service configuration information delivered by the core controller from the message transmission channel; and delivering the service configuration information to the hardware communication device based on a preset communication protocol.
  • Step 403 Obtain the service activation result uploaded by the hardware communication device, and send the service activation result to the core controller.
  • step 403 includes: obtaining the service activation result uploaded by the hardware communication device through a preset communication protocol; and uploading the service activation result to the core controller through a message transmission channel.
  • it further includes storing the acquired topology data.
  • Fig. 12 is a flow chart of the steps of another data processing method provided by an embodiment of the application; when the core controller is in a separate communication control device, referring to Fig. 12, a data processing method includes:
  • Step 411 Abstract the topology data uploaded by the southbound controller as model data, and upload the model data to the northbound controller.
  • step 411 includes: converting the data structure of the topology data according to a preset abstract model to generate model data;
  • the exchange queue obtains the model data.
  • Step 412 Obtain the service request issued by the northbound controller, determine service configuration information according to the service request and the topology data, and deliver the service configuration information to the southbound controller.
  • step 412 includes: obtaining a service request issued by the northbound controller through a message transmission channel; determining service configuration information according to the service request and the topology data; transmitting the service configuration information through a message The channel is issued to the southbound controller.
  • Step 413 Obtain the service activation result uploaded by the southbound controller, abstract the service activation result and the service configuration information into a service activation model, and upload the service activation model to the northbound controller.
  • step 413 includes: obtaining the service activation result uploaded by the southbound controller through the message transmission channel; converting the service activation result and the service configuration information according to a preset data structure to generate a service activation model ; Upload the service activation model to the northbound controller through a message transmission channel.
  • it further includes storing the service provisioning model and the model data.
  • Fig. 13 is a flow chart of the steps of another data processing method provided by an embodiment of the application; when the core controller is in a separate communication control device, referring to Fig. 13, a data processing method includes:
  • Step 421 Obtain model data uploaded by the core controller, and upload the model data to the upper application.
  • step 421 includes: obtaining model data sent by the core controller in the data exchange queue; uploading the model data to the upper application through a preset application interface.
  • Step 422 Obtain the service request issued by the upper-layer application, and send the service request to the core controller.
  • step 422 includes: obtaining the service request issued by the upper-layer application through a preset application interface; and issuing the service request to the core controller through a message transmission channel.
  • Step 423 Obtain the service activation model uploaded by the core controller, and upload the service activation model to the upper application.
  • step 423 includes: obtaining the service activation model uploaded by the core controller through the message transmission channel; uploading the service activation model to the upper application through a preset application interface.
  • it further includes storing the acquired service provisioning model.
  • the various embodiments of the present application can be implemented in hardware or dedicated circuits, software, logic or any combination thereof.
  • some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, although the present application is not limited thereto.
  • Computer program instructions can be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or written in any combination of one or more programming languages Source code or object code.
  • ISA Instruction Set Architecture
  • the block diagram of any logic flow in the drawings of the present application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions.
  • the computer program can be stored on the memory.
  • the memory can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as but not limited to read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), optical Memory devices and systems (Digital Video Disc (DVD) or Compact Disk (CD)), etc.
  • Computer-readable media may include non-transitory storage media.
  • the data processor can be any type suitable for the local technical environment, such as but not limited to general-purpose computers, special-purpose computers, microprocessors, digital signal processors (Digital Signal Processing, DSP), application specific integrated circuits (ASICs) ), programmable logic devices (Field-Programmable Gate Array, FPGA), and processors based on multi-core processor architecture.
  • DSP Digital Signal Processing
  • ASICs application specific integrated circuits
  • FPGA Field-Programmable Gate Array
  • FPGA Field-Programmable Gate Array

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本文公开一种网络控制器框架和数据处理方法。该框架包括：南向控制器、核心控制器和北向控制器；南向控制器设置为将从硬件通信设备获取的拓扑数据和业务开通结果发送到核心控制器，将从核心控制器获取的业务配置信息下发到硬件通信设备；核心控制器设置为将拓扑数据抽象为模型数据，将模型数据上传到北向控制器，根据从北向控制器获取到的业务请求和拓扑数据生成业务配置信息，将业务配置信息下发到南向控制器，将业务开通结果和业务配置信息抽象为业务开通模型，将业务开通模型上传到北向控制器；北向控制器设置为将模型数据和业务开通模型上传到上层应用，将从所述上层应用获取到的业务请求下发到核心控制器。

Description

网络控制器框架和数据处理方法
本申请要求在2019年11月25日提交中国专利局、申请号为201911165476.X的中国专利申请的优先权，该申请的全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信网络技术领域，例如涉及一种网络控制器和数据处理方法。
背景技术
软件定义网络(Software Defined Network，SDN)为一种新的网络范型，可通过软件编程的形式定义和控制网络，SDN中的控制平面和数据平面可以独立演化，有助于解决网络僵化问题，提升网络的可编程能力，极大地推动了下一代互联网的发展。
随着SDN的发展，主流控制器框架主要有OpenDaylight和开源网络操作系统(Open Network Operating System，ONOS)等。主流控制器框架将北向适配模块、核心功能模块和南向协议栈集中在一起，这种控制器框架的多个模块间的耦合程度较大，相互依赖严重，不利于控制器的全版本升级，延长了软件开发周期，降低了软件开发效率，削弱了SDN的性能。
发明内容
本申请提供了一种网络控制器框架和数据处理方法。
本申请实施例提供一种网络控制器框架，包括：
南向控制器、核心控制器和北向控制器；所述南向控制器与所述核心控制器连接，设置为与硬件通信设备连接，将从所述硬件通信设备获取的拓扑数据发送到所述核心控制器，以及，将从所述核心控制器获取的业务配置信息下发到所述硬件通信设备，以及，将从所述硬件通信设备获取的业务开通结果发送到所述核心控制器；所述核心控制器与所述北向控制器连接，设置为将从所述南向控制器获取到的拓扑数据抽象为模型数据，将所述模型数据上传到所述北向控制器，以及，根据从所述北向控制器获取到的业务请求和从所述南向控制器获取到的拓扑数据生成业务配置信息，将所述业务配置信息下发到所述南向控制器，以及，将从所述南向控制器获取到的业务开通结果和所述业务配置信息抽象为业务开通模型，将所述业务开通模型上传到所述北向控制器；所述北向控制器，设置为与上层应用连接，将所述核心控制器发送的模型数据上传到 所述上层应用，以及，将从所述上层应用获取到的业务请求下发到所述核心控制器，以及，将所述核心控制器发送的业务开通模型上传到所述上层应用。
本申请实施例还提供一种数据处理方法，应用于南向控制器，包括：
获取硬件通信设备的拓扑数据，将所述拓扑数据发送到核心控制器；获取所述核心控制器下发的业务配置信息，并将所述业务配置信息下发到所述硬件通信设备；获取所述硬件通信设备上传的业务开通结果，将所述业务开通结果发送到所述核心控制器。
本申请实施例还提供另一种数据处理方法，应用于核心控制器，该方法包括：
将南向控制器上传的拓扑数据抽象为模型数据，并将所述模型数据上传到北向控制器；获取所述北向控制器下发的业务请求，根据所述业务请求和所述拓扑数据确定业务配置信息，将所述业务配置信息下发到所述南向控制器；获取所述南向控制器上传的业务开通结果，将所述业务开通结果和所述业务配置信息抽象为业务开通模型，将所述业务开通模型上传到所述北向控制器。
本申请实施例还提供另一种数据处理方法，应用于北向控制器，该方法包括：
获取核心控制器上传的模型数据，并将所述模型数据上传到上层应用；获取所述上层应用下发的业务请求，并将所述业务请求发送到所述核心控制器；获取所述核心控制器上传的业务开通模型，并将所述业务开通模型上传到所述上层应用。
附图说明
图1为本申请实施例提供的一种网络控制器框架的结构示意图；
图2a为本申请实施例提供的一种网络控制器框架示例图；
图2b为本申请实施例提供的另一种网络控制器框架示例图；
图2c为本申请实施例提供的另一种网络控制器框架示例图；
图3为本申请实施例提供的另一种网络控制器框架的结构示意图；
图4为本申请实施例提供的另一种网络控制器框架的结构示意图；
图5为本申请实施例提供的另一种网络控制器框架的结构示意图；
图6为本申请实施例提供的另一种网络控制器框架的结构示意图；
图7为本申请实施例提供的一种数据处理方法的步骤流程图；
图8为本申请实施例提供的另一种数据处理方法的步骤流程图；
图9为本申请实施例提供的另一种数据处理方法的步骤流程图；
图10为本申请实施例提供的另一种数据处理方法的步骤流程图；
图11为本申请实施例提供的另一种数据处理方法的步骤流程图；
图12为本申请实施例提供的另一种数据处理方法的步骤流程图；
图13为本申请实施例提供的另一种数据处理方法的步骤流程图。
具体实施方式
下文中将结合附图对本申请的实施例进行说明。
图1为本申请实施例提供的一种网络控制器框架的结构示意图，本申请实施例可适用于SDN中，可连接硬件通信设备与上层应用，该网络控制器框架可以应用在网络设备中，参见图1，本申请实施例提供的网络控制器框架包括南向控制器10、核心控制器11和北向控制器12。
本申请实施例中，南向控制器10可以是在SDN中负责与硬件通信设备通信的控制器，可以与硬件通信设备进行数据交换；北向控制器12可以是SDN中负责与上层应用通信的控制器，可以与上层应用进行数据交换；核心控制器11可以是SDN中负责核心功能的控制器，可以确定业务配置信息和存储拓扑数据；南向控制器10、核心控制器11和北向控制器12可以是集成在具有数据处理功能的设备中，可以为软件形式、硬件形式和软硬结合形式存在。参见图2a，本申请实施例中的南向控制器10、核心控制器11和北向控制器12可以同时集成在一相同的设备1中；参见图2b，本申请实施例中的南向控制器10和北向控制器12可以集成在设备2中，而将核心控制器11单独设置在设备3中，设备2和设备3可以通过有线方式或者无线方式连接；参见图2c，本申请实施例中南向控制器10、核心控制器11和北向控制器12可以分别设置在设备4、设备5和设备6中，多个设备之间通过有线方式或者无线方式连接。
该南向控制器10分别与所述核心控制器11和硬件通信设备相连，设置为将从所述硬件通信设备获取的拓扑数据和业务开通结果发送到所述核心控制器11，以及，将从所述核心控制器11获取的业务配置信息下发到所述硬件通信设备。
本申请实施例中，南向控制器10通过有线方式或者无线方式连接到硬件通信设备，硬件通信设备可以是负责数据交换的设备，可以包括交换机等硬件设备。南向控制器10可以对硬件通信设备进行监测，硬件通信设备间的链接关系发生变化时，南向控制器10可以获取该链接关系作为拓扑数据。南向控制器10 可以将从硬件通信设备中获取到的拓扑数据和业务开通结果发送到核心控制器11，可以由核心控制器11对拓扑数据和业务开通结果进行处理。本申请中南向控制器10还可从核心控制器11中获取到业务配置信息，业务配置信息可以是根据上层应用的业务请求确定的处理业务的节点和传输信息的路径等，南向控制器10接收核心控制器11发送的业务配置信息后，可以将该业务配置信息下发到硬件通信设备，可以由硬件通信设备根据该业务配置信息完成业务配置。
所述核心控制器11分别与所述南向控制器10和北向控制器12连接，设置为根据从所述北向控制器12获取到的业务请求生成业务配置信息，将所述业务配置信息下发到所述南向控制器10，以及，将从所述南向控制器10获取到的拓扑数据和业务开通结果分别抽象生成模型数据和业务开通模型，将它们上传到所述北向控制器12。
一种实施方式中，核心控制器11可以实现SDN中的核心功能，可以根据业务请求生成业务配置信息和根据拓扑数据和业务开通结果分别生成模型数据和业务开通模型。核心控制器11可以与南向控制器10和北向控制器12通过有线方式或者无线方式连接，核心控制器11可以获取到南向控制器10发送的拓扑数据和业务开通结果，可以由拓扑数据和业务开通结果分别生成抽象的模型数据和业务开通模型；核心控制器11可以获取北向控制器12下发的业务请求，其中，业务请求可以是上层应用根据业务需要生成的请求信息，可以由北向控制器12发送到核心控制器11，核心控制器11在获取到业务请求后，可以根据业务请求中的信息以及拓扑数据确定数据包的转发路径。
所述北向控制器12分别与所述核心控制器11和上层应用相连，设置为将从所述上层应用获取到的业务请求下发到所述核心控制器11，以及，将所述核心控制器11发送的所述模型数据上传到所述上层应用。
一种实施方式中，北向控制器12可以通过应用接口与上层应用连接，北向控制器12与上层应用的连接可以是逻辑意义上的连接，上层应用可以和北向控制器12位于相同设备，也可以与北向控制器12位于不同设备。上层应用为实现业务可以向北向控制器12发送业务请求，其中，业务请求可以是上层应用调用硬件通信设备的请求信息，可以由上层应用将该业务请求发送到北向控制器12，上层应用可以为多个，多个上层应用均可以将业务请求发送到北向控制器12。核心控制器11可以将根据拓扑数据和业务开通结果分别抽象生成的模型数据和业务开通模型上传到北向控制器12，北向控制器12可以将获取到的模型数据上传，其中，模型数据可以是根据拓扑数据生成的数据，可以包括链路模型、端口模型和业务开通模型等，模型数据可以被上层应用处理。
本申请实施例提供的网络控制器框架，南向控制器、核心控制器和北向控 制器分别独立工作，南向控制器获取硬件通信设备的拓扑数据、业务开通结果和将业务配置信息下发到硬件通信设备，北向控制器获取上层应用的业务请求及将模型数据上传到上层应用，核心控制器将拓扑数据和业务开通结果分别抽象成模型数据和业务开通模型，以及根据业务请求确定业务配置信息，多个控制器共同替代SDN中原控制器，降低了控制器软件的耦合程度，降低了软件开发难度，可缩短控制器启动时间，可提高SDN数据处理性能。
图3为本申请实施例提供的另一种网络控制器框架的结构示意图，本申请实施例对网络控制器框架中每个控制器的连接方式进行了说明，多个控制器可以通过消息中间件进行连接，参见图3，所述南向控制器10可以通过所述消息中间件13连接到所述核心控制器11，以及所述北向控制器12可以通过所述消息中间件13连接到所述核心控制器11。
本申请实施例中，消息中间件13可以是传输拓扑数据、业务开通结果和业务请求的通讯信道，可以为远程过程调用(Remote Procedure Call，RPC)协议中间件和数据流处理中间件等，消息中间件13分别将南向控制器10和北向控制器12连接到核心控制器11，拓扑数据、业务开通结果和业务请求可以经过消息中间件13在多个控制器间传递。
一种实施方式中，图4为本申请实施例提供的另一种网络控制器框架的结构示意图，参见图4，所述消息中间件13包括拓扑数据传输中间件132和业务信息传输中间件131；其中，所述拓扑数据传输中间件132包括至少两个数据交换队列，第一数据交换队列1321设置为将所述拓扑数据从所述南向控制器10发送到所述核心控制器11，以及，第二数据交换队列1322设置为将所述模型数据从所述核心控制器11发送到所述北向控制器12；所述业务信息传输中间件131包括至少两个消息传输通道，所述第一消息传输通道设置为将所述业务请求从所述北向控制器12发送到所述核心控制器11和将业务开通模型从所述核心控制器11发送到所述北向控制器12，以及，第二消息传输通道设置为将所述业务配置信息从所述核心控制器11发送到所述南向控制器10和将所述业务开通结果从所述南向控制器10发送到所述核心控制器11。
本申请实施例中，拓扑数据传输中间件132可以是传输拓扑数据的中间件，可以将拓扑数据从南向控制器10传输到核心控制器11和将模型数据从核心控制器11传输到北向控制器12，拓扑数据传输中间件132可以为流数据处理平台，例如，可以是卡夫卡流处理平台。拓扑数据传输中间件132可以包括两个数据交换队列，一个数据交换队列可以设置为将拓扑数据从南向控制器10传输到核心控制器11，另一个数据交换队列可以设置为将模型数据从核心控制器11传输到北向控制器12，其中，模型数据可以是经过抽象化处理的拓扑数据，模型数 据可以包括链路模型、端口和业务开通模型。
在一种实施方式中，拓扑数据传输中间件132可以包括第一数据交换队列1321和第二数据交换队列1322。南向控制器10可以将获取到的拓扑数据发送到第一数据交换队列1321中，核心控制器11可以将获取到的模型数据发送到第二数据交换队列1322，核心控制器11可以从第一数据交换队列中1321中获取拓扑数据，北向控制器12可以从第二数据交换队列中1322中获取模型数据，将拓扑数据发送到数据交换队列和从数据交换队列中获取数据互不影响，南向控制器10、核心控制器11和北向控制12可以分别执行发送数据和获取数据的功能。业务信息传输中间件131可以包括至少两个消息传输通道，消息传输通道可以为RPC协议框架，可以传递请求信息、业务开通结果和业务配置信息，其中，业务信息传输中间件131可以包括第一消息传输通道和第二消息传输通道，分别进行南向控制器10和核心控制器11之间的信息传输以及核心控制器11和北向控制器12之间的信息传输。业务信息传输中间件131可以包括Thrift、Dubbo、Spring Cloud和谷歌RPC(google RPC，gRPC)等框架。
示例性的，以拓扑数据传输中间件132为Kafka流数据处理平台为例，初始状态启动Kafka的服务端来接收消息，南向控制器10作为卡夫卡消息的生产者，将获取的硬件通信设备的拓扑数据作为拓扑通过主题上报至Kafka服务端。核心控制器11此时作为消息的消费者，订阅相应的主题来接收南向控制器10上报的消息，并将拓扑数据进行内部模型抽象后存入数据库中；同时对内部抽象模型存库操作进行监听，当监听到拓扑数据库的变化，就通过另一个主题向Kafka服务端发送内部模型抽象后的数据，此时核心服务器11作为Kafka的生产者，故在整个拓扑上报的过程中核心服务器11对于南向控制器10为消费者，对于北向控制器12为生成者。北向控制器12向Kafka服务端订阅核心控制器11抽象后的模型数据，北向控制器12作为Kafka消息的消费者，当北向控制器12接收到消息后，进行北向模型转换并存库，这里可以根据不同的需求进行差异化的北向模型转换，同时以通知的形式向上层应用上报。此外，以业务信息传输中间件为gRPC框架为例，在拓扑数据上报完成后，当上层应用的业务请求到达北向控制器12，经北向控制器12相应适配模块转换处理后，然后通过gRPC框架初始化的通道将业务请求下发至一个核心控制器11，其中，核心控制器11可以为多个，核心控制器的网络地址和端口可以在初始化通道时指定，业务请求通过序列化框架协议缓冲区(Protocol Buffers，protobuf)传输到核心控制器11上。在核心控制器11中将业务请求进行反序列化，核心控制器11内部调用算路模块接口返回最优路径，最后在计算的最优路径上建立业务，业务和算路等核心模块均使用内部抽象的模型数据进行数据交互。业务建立的相关配置会通过gRPC发送到南向控制器10上，南向控制器10通过南向协议将业务建立的 相关配置下发至硬件通信设备建立业务。硬件通信设备可以将建立业务的业务开通结果反馈回南向控制器10，可以由南向控制器10经过核心控制器11反馈到北向控制器12，可以由北向控制器12将业务开通结果发送到上层应用。
图5为本申请实施例提供的另一种网络控制器框架的结构示意图，参见图5，本申请实施例中南向控制器10可以包括协议管理插件101和拓扑数据存储模块102，北向控制器12可以包括北向应用接口121和模型数据存储模块122，核心控制器11包括算路模块111、业务模块112、模型抽象模块113和数据存储模块114。
所述南向控制器10包括：协议管理插件101和拓扑数据存储模块102；其中，所述协议管理插件101，设置为实现至少一种所述硬件通信设备的通讯协议；所述拓扑数据存储模块102，设置为将从所述硬件通信设备获取的所述拓扑数据存储。
一种实施方式中，协议管理插件101可以通过存储的通信协议与硬件通信设备进行数据交换，协议管理插件101中可以设置有多种通信协议，可以包括Openflow、网络配置(Network Configuration，NETCONF)、开放虚拟交换机数据库(Open Virtual Switch Data Base，OVSDB)等协议中的一种或者多种，拓扑数据存储模块102可以将南向控制器10获取到的硬件通信设备的拓扑数据存储，存储的拓扑数据可以包括硬件通信设备的当前状态和链路信息等。
所述北向控制器12包括：北向应用接口121和模型数据存储模块122；所述北向应用接口121，设置为实现至少一种所述上层应用的应用接口；所述模型数据存储模块122，设置为将从所述核心控制器11获取的模型数据存储。
一种实施方式中，北向应用接口121可以是与上层应用进行数据交换的接口，北向应用接口121可以具有多种应用接口类型，可以包括传输应用编程接口(Transport Application Programming Interface，TAPI)等应用接口，北向控制器12可以根据不同的应用接口对应的上层应用进行数据交换。模型数据存储模块122，可以将核心控制器11上传的模型数据存储，模型数据在本申请中可以是持久性存储。
所述核心控制器11包括算路模块111、业务模块112、模型抽象模块113和数据存储模块114；所述算路模块111，设置为根据所述拓扑数据和所述业务请求确定通信路径信息；所述业务模块112，设置为将所述通信路径信息组装成对应所述南向控制器10和所述北向控制器12的数据报文；所述模型抽象模块113，设置为将所述南向控制器10上传的所述拓扑数据和业务开通结果分别抽象为模型数据和业务开通模型；所述数据存储模块114，设置为存储所述模型数据。
一种实施方式中，算路模块111可以利用已获取的拓扑数据对业务请求中调用端口进行路径计算，返回最优算路结果作为通信路径信息，其中，算路模块111可以通过Dijkstra算法或者Floyd算法实现。所述业务模块112将所述通信路径信息组装成对应所述南向控制器10和所述北向控制器12的数据报文，其中，由于业务请求调用的端口不同，可以生成不同协议对应的数据报文。所述模型抽象模块113，可以预先存储数据转发模型，可以根据预先存储的数据转发模型将拓扑数据和业务开通结果分别抽象为模型数据和业务开通模型，其中，模型数据可以表征在对应转发模型下硬件通信设备转发数据的方式。此外，核心控制器11还可以包括数据存储模块114，可以存储模型数据。
本申请实施例中，网络控制器框架至少包括一个核心控制器。图6为本申请实施例提供的另一种网络控制器框架的结构示意图，参见图6，本申请实施例中可以有多个核心控制器组成核心控制器集群，核心控制器集群含有多个分布式核心控制器，每个核心控制器都提供了处理网络设备的核心能力，包括算路模块、业务模块、模型抽象模块和数据存储模块等功能，核心控制器集群实现了负载均衡，增加了并发访问情况下网络系统的稳定性，核心控制器集群可以通过绑定网络地址或者端口的方式连接到北向控制器和南向控制器。
本申请实施例所提供的网络控制器框架和数据处理方法，由南向控制器、核心控制器和北向控制器共同实现软件定义网络的控制功能，每个控制器独立实现，降低了SDN功能模块之间的耦合程度，便于进行软件版本升级，降低控制器软件开发周期，可增强SDN的通信性能。
图7为本申请实施例提供的一种数据处理方法的步骤流程图，本申请实施例可以适用于SDN中，可连接硬件通信设备与上层应用，该网络控制器框架可以应用在网络设备中，参见图1，本申请实施例提供的数据处理方法包括：
步骤201、南向控制器获取拓扑数据，将所述拓扑数据从所述南向控制器上传到核心控制器，核心控制器将所述拓扑数据抽象为模型数据，所述模型数据从所述核心控制器发送到所述北向控制器。
本申请实施例中，南向控制器可以通过有线方式或者无线方式连接到硬件通信设备，硬件通信设备可以是负责数据交换的设备，可以包括交换机等硬件设备。南向控制器可以对硬件通信设备进行监测，确定硬件通信设备间的链接关系发生变化时，南向控制器可以获取该链接关系作为拓扑数据。南向控制器可以将从硬件通信设备中获取到的拓扑数据发送到核心控制器，可以由核心控制器对拓扑数据进行处理，可以将拓扑数据在核心控制器中抽象为模型数据，核心控制器可以将模型数据上传到北向控制器。
步骤202、所述北向控制器获取业务请求，将所述业务请求从所述北向控制 器下发到所述核心控制器，所述核心控制器根据所述拓扑数据确定业务配置信息，所述业务配置信息从所述核心控制器发送到所述南向控制器。
北向控制器可以通过应用接口与上层应用连接，北向控制器与上层应用的连接可以是逻辑意义上的连接，上层应用和北向控制器可以位于相同设备，也可以与北向控制器位于不同设备。上层应用为实现业务可以向北向控制器发送业务请求，其中，业务请求可以是上层应用调用硬件通信设备的请求信息，可以由上层应用将该业务请求发送到北向控制器，北向控制器可以将业务请求发送核心控制器，北向控制器可以将业务请求下发到核心控制器，核心控制器根据业务请求可以确定处理业务请求及根据拓扑数据确定建立业务的业务配置信息，核心控制器可以将该业务配置信息发送到南向控制器，可以由南向控制器将该业务配置信息转发到每个硬件通信设备以实现业务功能。
步骤203、所述南向控制器获取业务开通结果，将所述业务开通结果发送到所述核心控制器，所述核心控制器将所述业务开通结果和所述业务配置信息抽象为业务开通模型，所述业务开通模型从所述核心控制器发送到所述北向控制器。
南向控制器将业务配置信息下发到每个硬件通信设备后，每个硬件通信设备在根据业务配置信息建立业务后，可以将建立业务的业务开通结果反馈到南向控制器，其中，业务开通结果可以包括建立成功和建立失败。南向控制器可以对每个硬件通信设备进行监测获取到业务开通结果，在获取到业务开通结果后可以由南向控制器将业务开通结果发送到核心控制器，可以由核心控制器根据业务配置信息和业务开通结果构建成业务开通模型，其中，业务开通模型可以为预设形式数据结构存储的业务开通结果和对应的业务配置信息，核心控制器可以将生成的业务开通模型发送到北向控制器，可以由北向控制器根据上层应用对应的接口将业务开通模型转化为对应的数据结构形式，可以将转化后的业务开通模型由北向控制器发送到上层应用。
本申请实施例的技术方案，通过南向控制器获取硬件通信设备的拓扑数据和将业务配置信息下发到硬件通信设备，北向控制器获取上层应用的业务请求及将模型数据上传到上层应用，核心控制器将拓扑数据和业务开通结果分别抽象成模型数据和业务开通模型，以及根据业务请求确定业务配置信息，多个控制器共同替代SDN中原控制器，降低了控制器软件耦合程度，降低了软件开发难度，可缩短控制器启动时间，可提高SDN数据处理性能。
图8为本申请实施例提供的另一种数据处理方法的步骤流程图，本申请实施例对数据处理方法中拓扑数据处理进行说明，参见图8，本申请实施例的数据处理方法包括：
步骤311、南向控制器通过至少一种通信协议获取所述拓扑数据。
南向控制器可以通过通信协议与硬件通信设备进行通信，可以获取到硬件通信设备的拓扑信息，其中，拓扑信息可以包括硬件通信设备的当前状态信息和设备链路信息，通信协议可以是与硬件通信设备通信的协议，包括Openflow、NETCONF、OVSDB通信协议中至少一种。
步骤312、所述南向控制器将获取到的所述拓扑数据存储。
南向控制器可以将获取到的硬件通信设备的拓扑数据持久化存储。
步骤313、所述南向控制器将所述拓扑数据发送到第一数据交换队列，所述核心控制器从所述第一数据交换队列获取所述拓扑数据。
本申请实施例中，第一数据交换队列可以是设置为进行拓扑数据交换的服务器，可以将拓扑数据从南向控制器发送到核心控制器，第一数据交换队列可以是流处理平台中的话题队列。南向控制器可以将拓扑数据发送到第一数据交换队列，核心控制器可以从第一数据交换队列直接获取该拓扑数据，南向控制器和核心控制器可以独立进行数据发送和接收过程，降低了南向控制器和核心控制器的耦合程度。
步骤314、所述核心控制器将所述拓扑数据抽象为模型数据。
核心控制器将拓扑数据转化为代表数据转发模型的模型数据，模型数据可以表示每个硬件通信设备转发数据的方式。
在一种实施方式中，核心控制器根据预设模型将所述拓扑数据抽象为模型数据；所述核心控制器将所述模型数据存储。
本申请实施例中，核心控制器可以预设存储有不同预设模型，预设模型可以是数据转发模型，可以反应不同的硬件通信设备数据转发方式，核心控制器根据预设模型将拓扑数据转化为模型数据，可以将该模型数据进行持久化存储。
步骤315、所述核心控制器将所述模型数据发送到第二数据交换队列，所述北向控制器从所述第二数据交换队列获取所述模型数据。
本申请实施例中，第二数据交换队列可以是设置为进行模型数据交换的服务器，可以将模型数据从核心控制器发送到北向控制器，第二数据交换队列可以是流处理平台中的话题队列。核心控制器可以将模型数据发送到第二数据交换队列，北向控制器可以从第二数据交换队列直接获取该模型数据，核心控制器和北向控制器可以独立进行数据发送和接收过程，降低了北向控制器和核心控制器的耦合程度。
步骤316、所述北向控制器通过至少一种应用接口上传所述模型数据。
北向控制器可以具有多种应用接口类型，可以包括TAPI等应用接口，北向控制器可以根据不同的应用接口将模型数据上传到对应的上层应用。
步骤317、所述北向控制器将获取到的所述模型数据存储。
在本申请实施例中，北向控制器还可以将从核心控制器获取到的模型数据持久化存储。
本申请实施例的技术方案，通过南向控制器获取拓扑数据并存储，南向控制器将拓扑数据发送到第一数据交换队列，核心控制器从第一数据交换队列获取拓扑数据，核心控制器将拓扑数据抽象为模型数据，核心控制器将模型数据发送到第二数据交换队列，北向控制器从第二数据交换队列获取模型数据，北向控制器使用应用接口上传模型数据，实现了拓扑数据在多个控制器间的流转，基于数据交换队列降低了多个控制器间的耦合程度，可以对每个控制器进行差分升级，保障了SDN网络功能不受控制器升级影响。
图9为本申请实施例提供的另一种数据处理方法的步骤流程图，本申请实施例对数据处理方法中业务请求处理进行说明，参见图9，本申请实施例的数据处理方法包括：
步骤321、北向控制器通过至少一种应用接口获取所述业务请求。
北向控制器与上层应用进行数据交换的应用接口可以有多种，北向控制器可以与不同上层应用采用不同的应用接口进行数据交换，上层应用调用硬件通信设备完成业务需求时，可以通过应用接口将业务请求发送到北向控制器，其中，业务请求可以包括调用硬件通信设备的端口和网络地址等。
步骤322、北向控制器通过第一消息传输通道将所述业务请求发送到所述核心控制器。
北向控制器与核心控制器之间的信息交互，可以通过第一消息传通道，其中，第一消息通道可以是Thrift、Dubbo、Spring Cloud和gRPC等框架，可以将业务请求从北向控制器发送到核心控制器。
步骤323、所述核心控制器根据所述拓扑数据确定业务配置信息。
本申请实施例中，核心控制器可以根据业务请求获取到硬件通信设备的拓扑数据，可以根据拓扑数据确定数据传输的路径和数据报文类型，可以将该路径和数据报文类型作为业务请求对应的业务配置信息。
步骤324、所述核心控制器通过第二消息传输通道将所述业务配置信息发送到所述南向控制器。
南向控制器与和核心控制器之间的信息交互，可以通过第二消息传通道将 业务配置信息从核心控制器发送到南向控制器。
步骤325、所述南向控制器通过至少一种通信协议下发所述业务配置信息。
本申请实施例中，南向控制器通过通信协议与硬件通信设备连接，在获取到业务配置信息后，可以根据每个硬件通信设备对应的通信协议将业务配置信息进行格式转化，可以将格式转化后的业务配置信息发送到硬件通信设备，通信协议可以包括Openflow、NETCONF、OVSDB等协议中的一种或者多种。
本申请实施例的技术方案，通过北向控制器应用接口获取业务请求，北向控制器通过第一消息传输通道将业务请求传输到核心控制器，核心控制器根据业务请求和拓扑数据确定业务配置信息，核心控制器将业务配置信息经过第二消息传输通道发送到南向控制器，由南向控制器根据通信协议将对应的业务配置信息下发到硬件通信设备，实现了业务请求的快速响应，提高业务请求的处理速度，增强了SDN网络的性能。
一种实施方式中，核心控制器基于所述业务请求的端口等信息，根据每个所述端口等信息和所述拓扑数据确定通信路径信息；所述核心控制器根据所述通信路径等信息组装数据报文。
核心控制器可以根据业务请求获取到上层应用调用的端口等信息，可以根据端口信息和对应的拓扑数据，确定业务请求中对应的最短或者最优数据传输路径作为通信路径信息，然后可以对其进行封装。
图10为本申请实施例提供的另一种数据处理方法的步骤流程图，本申请实施例对数据处理方法中业务开通结果处理进行说明，参见图9，本申请实施例的数据处理方法包括：
步骤331、南向控制器通过至少一种通信协议获取所述业务开通结果。
硬件通信设备根据建立业务是否成功的结果上报业务开通结果，南向控制器根据不同的硬件通信设备采用不同的通信协议获取到对应硬件通信设备的业务开通结果。
步骤332、所述南向控制器通过第二消息传输通道将所述业务开通结果发送到所述核心控制器。
本申请实施例中，南向控制器通过第二消息传输通道连接到核心控制器，南向控制器在获取到业务开通结果后，可以将业务开通结果通过第二消息传输通道发送到核心控制器。
步骤333、所述核心控制器根据所述业务开通结果和所述业务配置信息确定业务开通模型。
业务开通模型可以是根据预设数据结构存储的业务开通结果，业务开通模型可以被上层应用使用，核心控制器将业务开通结果和业务配置信息进行处理生成预设数据结构的业务开通模型。
步骤334、所述核心控制器通过第一消息传输通道将所述业务开通模型发送到所述北向控制器。
在本申请实施例中，核心控制器可以将业务开通模型发送到北向控制器，业务开通模型可以通过第一消息传输通道进行发送，可以降低核心控制器与北向控制器的耦合程度。
步骤335、所述北向控制器通过至少一种应用接口上传所述业务开通模型。
北向控制器根据上层应用的类型确定对应的应用接口，可以通过应用接口将业务开通模型从北向控制器发送到上层应用。
步骤336、所述北向控制器将获取到的所述业务开通模型存储。
北向控制器可以将业务开通模型持久化存储。
本申请实施例的技术方案，南向控制器通过不同通信协议获取不同硬件通信设备上传的业务开通结果，南向控制器通过第二消息传输通道将业务开通结果发送到核心控制器，核心控制器将业务开通结果和业务配置信息抽象为业务开通模型，通过核心控制器与北向控制器之间的第一消息传输通道将业务开通模型传输到北向控制器，北向控制器将业务开通模型发送到上层应用。通过消息传输队列实现业务开通结果和业务开通模型在多个控制器间的传输，实现了业务开通结果快速反馈，降低了多个控制器间的耦合程度，实现了每个控制器版本的差分升级，可增强SDN网络的性能。以上所述，仅为本申请的示例性实施例而已，并非用于限定本申请的保护范围。
图11为本申请实施例提供的另一种数据处理方法的步骤流程图；当南向控制器处于单独的通信控制设备中时，参见图11，一种数据处理方法包括：
步骤401、获取硬件通信设备的拓扑数据，将所述拓扑数据发送到核心控制器。
一种实施方式中，步骤401包括：通过预设通信协议获取硬件通信设备的拓扑数据；将所述拓扑数据发送到数据交换队列以使所述核心控制器从所述数据交换队列获取到所述拓扑数据。
步骤402、获取所述核心控制器下发的业务配置信息，并将所述业务配置信息下发到所述硬件通信设备。
一种实施方式中，步骤402包括：从消息传输通道获取所述核心控制器下 发的业务配置信息；将所述业务配置信息基于预设通信协议下发到所述硬件通信设备。
步骤403、获取所述硬件通信设备上传的业务开通结果，将所述业务开通结果发送到所述核心控制器。
一种实施方式中，步骤403包括:通过预设通信协议获取硬件通信设备上传的业务开通结果；将所述业务开通结果通过消息传输通道上传到所述核心控制器。
一种实施方式中，还包括存储获取到的所述拓扑数据。
图12为本申请实施例提供的另一种数据处理方法的步骤流程图；当核心控制器处于单独的通信控制设备中时，参见图12，一种数据处理方法包括：
步骤411、将南向控制器上传的拓扑数据抽象为模型数据，并将所述模型数据上传到北向控制器。
一种实施方式中，步骤411包括：根据预设的抽象模型转换所述拓扑数据的数据结构以生成模型数据；将所述模型数据发送到数据交换队列以使所述北向控制器从所述数据交换队列获取所述模型数据。
步骤412、获取所述北向控制器下发的业务请求，根据所述业务请求和所述拓扑数据确定业务配置信息，将所述业务配置信息下发到所述南向控制器。
一种实施方式中，步骤412包括：获取所述北向控制器通过消息传输通道下发的业务请求；根据所述业务请求和所述拓扑数据确定业务配置信息；将所述业务配置信息通过消息传输通道下发到所述南向控制器。
步骤413、获取所述南向控制器上传的业务开通结果，将所述业务开通结果和所述业务配置信息抽象为业务开通模型，将所述业务开通模型上传到所述北向控制器。
一种实施方式中，步骤413包括：获取所述南向控制器通过消息传输通道上传的业务开通结果；将所述业务开通结果和所述业务配置信息按照预设数据结构进行转换生成业务开通模型；将所述业务开通模型通过消息传输通道上传到所述北向控制器。
一种实施方式中，还包括存储所述业务开通模型和所述模型数据。
图13为本申请实施例提供的另一种数据处理方法的步骤流程图；当核心控制器处于单独的通信控制设备中时，参见图13，一种数据处理方法包括：
步骤421、获取核心控制器上传的模型数据，并将所述模型数据上传到上层应用。
一种实施方式中，步骤421包括：获取数据交换队列中所述核心控制器发送的模型数据；将所述模型数据通过预设应用接口上传到所述上层应用。
步骤422、获取所述上层应用下发的业务请求，并将所述业务请求发送到所述核心控制器。
一种实施方式中，步骤422包括：通过预设应用接口获取所述上层应用下发的业务请求；将所述业务请求通过消息传输通道下发到所述核心控制器。
步骤423、获取所述核心控制器上传的业务开通模型，并将所述业务开通模型上传到所述上层应用。
一种实施方式中，步骤423包括：获取所述核心控制器通过消息传输通道上传的业务开通模型；通过预设应用接口将所述业务开通模型上传到所述上层应用。
一种实施方式中，还包括将获取到的业务开通模型存储。
一般来说，本申请的多种实施例可以在硬件或专用电路、软件、逻辑或其任何组合中实现。例如，一些方面可以被实现在硬件中，而其它方面可以被实现在可以被控制器、微处理器或其它计算装置执行的固件或软件中，尽管本申请不限于此。
本申请的实施例可以通过移动装置的数据处理器执行计算机程序指令来实现，例如在处理器实体中，或者通过硬件，或者通过软件和硬件的组合。计算机程序指令可以是汇编指令、指令集架构(Instruction Set Architecture，ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码。
本申请附图中的任何逻辑流程的框图可以表示程序步骤，或者可以表示相互连接的逻辑电路、模块和功能，或者可以表示程序步骤与逻辑电路、模块和功能的组合。计算机程序可以存储在存储器上。存储器可以具有任何适合于本地技术环境的类型并且可以使用任何适合的数据存储技术实现，例如但不限于只读存储器(Read-Only Memory，ROM)、随机访问存储器(Random Access Memory，RAM)、光存储器装置和系统(数码多功能光碟(Digital Video Disc，DVD)或光盘(Compact Disk，CD))等。计算机可读介质可以包括非瞬时性存储介质。数据处理器可以是任何适合于本地技术环境的类型，例如但不限于通用计算机、专用计算机、微处理器、数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑器件(Field-Programmable Gate Array，FPGA)以及基于多核处理器架构的处理器。

Claims (19)

  1. 一种网络控制器框架，包括：南向控制器、核心控制器和北向控制器；
    所述南向控制器与所述核心控制器连接，设置为与硬件通信设备连接，将从所述硬件通信设备获取的拓扑数据发送到所述核心控制器，以及，将从所述核心控制器获取的业务配置信息下发到所述硬件通信设备，以及，将从所述硬件通信设备获取的业务开通结果发送到所述核心控制器；
    所述核心控制器与所述北向控制器连接，设置为将从所述南向控制器获取到的拓扑数据抽象为模型数据，将所述模型数据上传到所述北向控制器，以及，根据从所述北向控制器获取到的业务请求和从所述南向控制器获取到的拓扑数据生成业务配置信息，将所述业务配置信息下发到所述南向控制器，以及，将从所述南向控制器获取到的业务开通结果和所述业务配置信息抽象为业务开通模型，将所述业务开通模型上传到所述北向控制器；
    所述北向控制器，设置为与上层应用连接，将所述核心控制器发送的模型数据上传到所述上层应用，以及，将从所述上层应用获取到的业务请求下发到所述核心控制器，以及，将所述核心控制器发送的业务开通模型上传到所述上层应用。
  2. 根据权利要求1所述的网络控制器框架，还包括：消息中间件，所述南向控制器通过所述消息中间件与所述核心控制器连接，以及所述北向控制器通过所述消息中间件与所述核心控制器连接；
    所述消息中间件设置为在所述南向控制器、所述核心控制器和所述北向控制器之间传输数据。
  3. 根据权利要求2所述的网络控制器框架，其中，所述消息中间件包括拓扑数据传输中间件和业务信息传输中间件；
    所述拓扑数据传输中间件包括至少两个数据交换队列，所述至少两个数据交换队列中，第一数据交换队列设置为将所述拓扑数据从所述南向控制器发送到所述核心控制器，第二数据交换队列设置为将所述模型数据从所述核心控制器发送到所述北向控制器；
    所述业务信息传输中间件包括至少两个消息传输通道，所述至少两个消息传输通道中，第一消息传输通道设置为将所述业务请求从所述北向控制器发送到所述核心控制器和将所述业务开通模型从所述核心控制器发送到所述北向控制器，第二消息传输通道设置为将所述业务配置信息从所述核心控制器发送到所述南向控制器和将所述业务开通结果从所述南向控制器发送到所述核心控制器。
  4. 根据权利要求1所述的网络控制器框架，其中，所述南向控制器包括： 协议管理插件和拓扑数据存储模块；
    所述协议管理插件，设置为实现至少一种硬件通信设备的通讯协议，并与每种硬件通信设备进行数据交换；
    所述拓扑数据存储模块，设置为将从所述硬件通信设备获取的拓扑数据存储。
  5. 根据权利要求1所述的网络控制器框架，其中，所述北向控制器包括：北向应用接口和模型数据存储模块；
    所述北向应用接口，设置为实现至少一种上层应用的应用接口，并与每种上层应用进行数据交换；
    所述模型数据存储模块，设置为将从所述核心控制器获取的模型数据存储。
  6. 根据权利要求1所述的网络控制器框架，其中，所述核心控制器包括算路模块、业务模块、模型抽象模块和数据存储模块；
    所述算路模块，设置为根据所述拓扑数据和所述业务请求确定通信路径信息；
    所述业务模块，设置为将所述通信路径信息和业务信息组装成对应所述南向控制器的业务配置信息；
    所述模型抽象模块，设置为将所述南向控制器上传的拓扑数据抽象为模型数据，以及，将所述南向控制器上传的业务开通结果和所述业务配置信息抽象为业务开通模型；
    所述数据存储模块，设置为存储所述拓扑数据和所述模型数据。
  7. 根据权利要求1-6任一项所述的网络控制器框架，其中，所述网络控制器框架包括至少一个核心控制器。
  8. 一种数据处理方法，应用于南向控制器，包括：
    获取硬件通信设备的拓扑数据，将所述拓扑数据发送到核心控制器；
    获取所述核心控制器下发的业务配置信息，并将所述业务配置信息下发到所述硬件通信设备；
    获取所述硬件通信设备上传的业务开通结果，将所述业务开通结果发送到所述核心控制器。
  9. 根据权利要求8所述的方法，其中，所述获取硬件通信设备的拓扑数据，将所述拓扑数据发送到核心控制器，包括：
    通过预设通信协议获取所述硬件通信设备的拓扑数据；
    将所述拓扑数据发送到数据交换队列以使所述核心控制器从所述数据交换队列获取到所述拓扑数据。
  10. 根据权利要求8所述的方法，其中，所述获取所述核心控制器下发的业务配置信息，并将所述业务配置信息下发到所述硬件通信设备，包括：
    从消息传输通道获取所述核心控制器下发的业务配置信息；
    将所述业务配置信息基于预设通信协议下发到所述硬件通信设备。
  11. 根据权利要求8所述的方法，其中，所述获取所述硬件通信设备上传的业务开通结果，将所述业务开通结果发送到所述核心控制器，包括：
    通过预设通信协议获取所述硬件通信设备上传的业务开通结果；
    将所述业务开通结果通过消息传输通道上传到所述核心控制器。
  12. 一种数据处理方法，应用于核心控制器，包括：
    将南向控制器上传的拓扑数据抽象为模型数据，并将所述模型数据上传到北向控制器；
    获取所述北向控制器下发的业务请求，根据所述业务请求和所述拓扑数据确定业务配置信息，将所述业务配置信息下发到所述南向控制器；
    获取所述南向控制器上传的业务开通结果，将所述业务开通结果和所述业务配置信息抽象为业务开通模型，将所述业务开通模型上传到所述北向控制器。
  13. 根据权利要求12所述的方法，其中，所述将南向控制器上传的拓扑数据抽象为模型数据，并将所述模型数据上传到北向控制器，包括：
    根据预设的抽象模型转换所述拓扑数据的数据结构以生成所述模型数据；
    将所述模型数据发送到数据交换队列以使所述北向控制器从所述数据交换队列获取所述模型数据。
  14. 根据权利要求12所述的方法，其中，所述获取所述北向控制器下发的业务请求，根据所述业务请求和所述拓扑数据确定业务配置信息，将所述业务配置信息下发到所述南向控制器，包括：
    获取所述北向控制器通过消息传输通道下发的业务请求；
    根据所述业务请求和所述拓扑数据确定所述业务配置信息；
    将所述业务配置信息通过消息传输通道下发到所述南向控制器。
  15. 根据权利要求12所述的方法，其中，所述获取所述南向控制器上传的业务开通结果，将所述业务开通结果和所述业务配置信息抽象为业务开通模型， 将所述业务开通模型上传到所述北向控制器，包括：
    获取所述南向控制器通过消息传输通道上传的业务开通结果；
    将所述业务开通结果和所述业务配置信息按照预设数据结构进行转换生成所述业务开通模型；
    将所述业务开通模型通过消息传输通道上传到所述北向控制器。
  16. 一种数据处理方法，应用于北向控制器，包括：
    获取核心控制器上传的模型数据，并将所述模型数据上传到上层应用；
    获取所述上层应用下发的业务请求，并将所述业务请求发送到所述核心控制器；
    获取所述核心控制器上传的业务开通模型，并将所述业务开通模型上传到所述上层应用。
  17. 根据权利要求16所述的方法，其中，所述获取核心控制器上传的模型数据，并将所述模型数据上传到上层应用，包括：
    获取数据交换队列中所述核心控制器发送的模型数据；
    将所述模型数据通过预设应用接口上传到所述上层应用。
  18. 根据权利要求16所述的方法，其中，所述获取所述上层应用下发的业务请求，并将所述业务请求发送到所述核心控制器，包括：
    通过预设应用接口获取所述上层应用下发的业务请求；
    将所述业务请求通过消息传输通道下发到所述核心控制器。
  19. 根据权利要求16所述的方法，其中，所述获取所述核心控制器上传的业务开通模型，并将所述业务开通模型上传到所述上层应用，包括：
    获取所述核心控制器通过消息传输通道上传的业务开通模型；
    通过预设应用接口将所述业务开通模型上传到所述上层应用。
PCT/CN2020/129319 2019-11-25 2020-11-17 网络控制器框架和数据处理方法 WO2021104103A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911165476.XA CN112838940B (zh) 2019-11-25 2019-11-25 一种网络控制器框架和数据处理方法
CN201911165476.X 2019-11-25

Publications (1)

Publication Number Publication Date
WO2021104103A1 true WO2021104103A1 (zh) 2021-06-03

Family

ID=75922170

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/129319 WO2021104103A1 (zh) 2019-11-25 2020-11-17 网络控制器框架和数据处理方法

Country Status (2)

Country Link
CN (1) CN112838940B (zh)
WO (1) WO2021104103A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113938534A (zh) * 2021-09-16 2022-01-14 中国联合网络通信集团有限公司 协同方法及装置
CN114244743A (zh) * 2021-12-10 2022-03-25 北京天融信网络安全技术有限公司 一种资源池的数据包传输方法、装置、设备及介质
CN114500257A (zh) * 2021-12-09 2022-05-13 深信服科技股份有限公司 网络配置分发方法、装置、控制节点及存储介质
CN115604333A (zh) * 2022-10-12 2023-01-13 江苏赛融科技股份有限公司（Cn） 基于dubbo的分布式大数据分析服务调度方法及系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422280B (zh) * 2021-12-31 2023-11-07 深信服科技股份有限公司 网络部署方法、装置、节点及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103685033A (zh) * 2013-12-19 2014-03-26 武汉邮电科学研究院 Sdn架构中支持分组交换和电路交换的通用流表及方法
CN105282043A (zh) * 2014-06-20 2016-01-27 中国电信股份有限公司 全局网络负载均衡系统、设备和方法
CN106656846A (zh) * 2017-01-17 2017-05-10 大连理工大学 一种sdn体系架构中协调层的构建方法
US20170195255A1 (en) * 2015-12-31 2017-07-06 Fortinet, Inc. Packet routing using a software-defined networking (sdn) switch
CN106936857A (zh) * 2015-12-29 2017-07-07 中国电信股份有限公司 一种混合云的连接管理方法、sdn控制器及混合云系统
CN108712458A (zh) * 2018-03-30 2018-10-26 中国科学院信息工程研究所 支持内容控制的软件定义网络控制器

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101447891B (zh) * 2008-04-17 2011-09-21 中兴通讯股份有限公司 业务模型自适应系统及方法
CN105208585A (zh) * 2014-06-23 2015-12-30 中兴通讯股份有限公司 调度信息的配置、配置参数的处理方法及装置
CN106130796B (zh) * 2016-08-29 2018-05-29 广州西麦科技股份有限公司 Sdn网络拓扑流量可视化监控方法及控制终端
CN109257222B (zh) * 2018-09-27 2019-11-15 中国联合网络通信有限公司广东省分公司 一种基于业务编排器的城域网网络架构

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103685033A (zh) * 2013-12-19 2014-03-26 武汉邮电科学研究院 Sdn架构中支持分组交换和电路交换的通用流表及方法
CN105282043A (zh) * 2014-06-20 2016-01-27 中国电信股份有限公司 全局网络负载均衡系统、设备和方法
CN106936857A (zh) * 2015-12-29 2017-07-07 中国电信股份有限公司 一种混合云的连接管理方法、sdn控制器及混合云系统
US20170195255A1 (en) * 2015-12-31 2017-07-06 Fortinet, Inc. Packet routing using a software-defined networking (sdn) switch
CN106656846A (zh) * 2017-01-17 2017-05-10 大连理工大学 一种sdn体系架构中协调层的构建方法
CN108712458A (zh) * 2018-03-30 2018-10-26 中国科学院信息工程研究所 支持内容控制的软件定义网络控制器

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113938534A (zh) * 2021-09-16 2022-01-14 中国联合网络通信集团有限公司 协同方法及装置
CN113938534B (zh) * 2021-09-16 2023-05-12 中国联合网络通信集团有限公司 协同方法及装置
CN114500257A (zh) * 2021-12-09 2022-05-13 深信服科技股份有限公司 网络配置分发方法、装置、控制节点及存储介质
CN114244743A (zh) * 2021-12-10 2022-03-25 北京天融信网络安全技术有限公司 一种资源池的数据包传输方法、装置、设备及介质
CN114244743B (zh) * 2021-12-10 2022-10-21 北京天融信网络安全技术有限公司 一种资源池的数据包传输方法、装置、设备及介质
CN115604333A (zh) * 2022-10-12 2023-01-13 江苏赛融科技股份有限公司（Cn） 基于dubbo的分布式大数据分析服务调度方法及系统
CN115604333B (zh) * 2022-10-12 2023-09-12 江苏赛融科技股份有限公司 基于dubbo的分布式大数据分析服务调度方法及系统

Also Published As

Publication number Publication date
CN112838940B (zh) 2024-03-01
CN112838940A (zh) 2021-05-25

Similar Documents

Publication Publication Date Title
WO2021104103A1 (zh) 网络控制器框架和数据处理方法
JP3910613B2 (ja) ネットワーク接続ストレージｓｎｍｐシングル・システム・イメージ
US11689606B2 (en) Communication method, system and apparatus
WO2017092347A1 (zh) 一种分布式高速缓存系统中的客户端配置更新方法、设备及系统
US8355345B2 (en) Apparatus, system, and method for establishing point to point connections in FCOE
US20240064059A1 (en) Opc ua-based centralized user configuration method and system for time-sensitive network
US10609125B2 (en) Method and system for transmitting communication data
US10140121B2 (en) Sending a command with client information to allow any remote server to communicate directly with client
CN110636127B (zh) 一种各信息数据间的通信处理方法及系统
US8527661B1 (en) Gateway for connecting clients and servers utilizing remote direct memory access controls to separate data path from control path
US10862794B2 (en) Automated link aggregation group configuration system
WO2022032984A1 (zh) 一种mqtt协议仿真方法及仿真设备
US11991083B2 (en) Systems and methods for enhanced autonegotiation
CN107979640B (zh) 一种数据传输方法及装置
WO2018107433A1 (zh) 信息处理方法和装置
WO2021136199A1 (zh) 网络设备的监控方法、系统、路由设备和存储介质
WO2024027217A1 (zh) 一种虚拟化核心网的时间敏感实现方法及系统
CN112181681A (zh) 一种远程调用方法、装置、计算机设备及存储介质
WO2023071717A1 (zh) 一种运维操作方法、系统及网络设备
TW202103475A (zh) 終端設備管理方法、伺服器及終端設備
US20220052902A1 (en) Method for managing remote device through management device
US10560527B2 (en) Network service chains using hardware logic devices in an information handling system
WO2021103801A1 (zh) 信息处理方法及相关设备
WO2023035777A1 (zh) 网络配置方法、代理组件、控制器、电子设备和存储介质
US11570257B1 (en) Communication protocol, and a method thereof for accelerating artificial intelligence processing tasks

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: 20894740

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: 20894740

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO 23/02/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 20894740

Country of ref document: EP

Kind code of ref document: A1