CN111355658B - SDN cross-domain cooperation method based on distributed service framework - Google Patents
SDN cross-domain cooperation method based on distributed service framework Download PDFInfo
- Publication number
- CN111355658B CN111355658B CN202010128313.0A CN202010128313A CN111355658B CN 111355658 B CN111355658 B CN 111355658B CN 202010128313 A CN202010128313 A CN 202010128313A CN 111355658 B CN111355658 B CN 111355658B
- Authority
- CN
- China
- Prior art keywords
- sdn
- module
- agent
- domain
- task request
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- 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/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- 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/10—Protocols in which an application is distributed across nodes in the network
-
- 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/56—Provisioning of proxy services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses an SDN cross-domain cooperation method based on a distributed service framework, which comprises the steps of setting a distributed cross-domain cooperation module for realizing distributed application coordination service, and setting an agent module for an SDN controller in each SDN network, wherein the agent module is used for realizing communication between the SDN controller and the distributed cross-domain cooperation module; the upper layer application sends the task request to the agent module, if the task request is an intra-domain task request, the agent module sends the task request to the intra-domain controller for processing, if the task request is an extra-domain task request, the task request is forwarded to the agent module of the target domain through the distributed cross-domain cooperation module, then the agent module of the target domain sends the task request to the SDN controller of the target domain for processing, and a processing result is also fed back through the distributed cross-domain cooperation module. The invention introduces a distributed cross-domain cooperation module and an agent module, and solves the problem of cross-domain cooperation.
Description
Technical Field
The invention belongs to the technical field of SDN networks, and particularly relates to an SDN cross-domain cooperation method based on a distributed service framework.
Background
Software Defined Networking (SDN), as a new Network architecture separating a control plane and a data plane, has been applied in many fields in recent years due to its flexible, efficient and configurable characteristics and centralized control characteristics for underlying devices, compared to the conventional Network. In a conventional network, a network device represented by a router includes both a data plane and a control plane, which are tightly coupled, and the SDN decouples the control plane from the data plane and strips the control plane from the device, so that the network device of the data plane is only responsible for forwarding packets, and the control and management of the network are handled by a centralized controller.
SDN also has some natural deficiencies. A control plane in the SDN, which is centralized in logic, can collect resource state information of the whole network and maintain a global network view, which greatly simplifies the development of upper-layer applications, but also causes an excessive load on a central controller, which limits the scale of the network. The SDN under a single controller architecture completes management and control functions by one central controller, but is limited by factors such as a CPU, a memory, and a bandwidth, and the performance of the single controller itself has an upper limit, and as the network scale is continuously enlarged and data requests are continuously increased to cause an excessive load on the central controller, the central controller will have obvious performance degradation and an increase in processing delay of a control plane, and even cannot normally process the arriving requests.
Particularly, at present, no reasonable and widely-recognized east-west interface specification and standard between SDN controllers is provided in the industrial and academic circles, which makes it difficult for different types of SDN controllers to realize effective information interaction. Therefore, when the network scale is large and different network domains belong to different mechanisms, how to effectively realize the joint deployment of the cross-domain services becomes a difficult problem.
In a traditional IP network, cross-domain routing is mainly implemented by means of a Border Gateway Protocol (BGP), which has many limitations in terms of policy enforcement, scalability, complexity, etc. due to its fully distributed nature; for example, after changing the route, the control plane may take several minutes to converge, which is not acceptable in some scenarios where real-time requirements are high. For the SDN network, because the controller provides a centralized global control plane, which is significantly superior to the conventional IP network in terms of policy enforcement, security, complexity, and the like, compared with the BGP under the conventional IP network, the SDN providing the centralized control plane has natural advantages in terms of cross-domain routing, and the realization of cross-domain routing based on the SDN has great practical value.
The cross-domain collaboration under the SDN is essentially a distributed coordination problem, and the solutions proposed by researchers at home and abroad mainly include a flat system architecture, a layered system architecture, a hybrid system architecture and the like.
In a flat system architecture, all controllers are in the same level, all controllers grasp the information state of the whole network in real time, and the real-time synchronization of the network state is carried out through the information interaction among the controllers; the hierarchical architecture divides a network into mutually disjoint domains, and each SDN controller can only control network equipment in the domain to which the SDN controller belongs; the controllers in the domain are called local controllers, and in order to meet the cross-domain access requirement, a root controller is arranged in the global network and used for managing each local controller, and data of each local controller is gathered to form a global network view. The hybrid architecture is a combination of the above two approaches.
The flattening system structure has high requirements on synchronization, and in a scenario that the SDN is managed by different organizations, each organization may not want to expose internal information due to the consideration of factors such as security and privacy, and it is difficult to implement that all controllers grasp the information state of the whole network in real time; while the hierarchical architecture relaxes the requirement of synchronization, the root controller under the architecture faces performance bottleneck and single point of failure similar to the single controller architecture. The hybrid architecture solves its single point of failure problem by clustering the root controllers, but greatly increases the complexity of the system.
Disclosure of Invention
The invention aims to overcome the defects of the prior art, provides an SDN cross-domain cooperation method based on a distributed service framework, introduces a distributed cross-domain cooperation module and an agent module, and solves the problem of cross-domain cooperation.
In order to achieve the above object, the SDN cross-domain cooperation method based on the distributed service framework of the present invention includes the following steps:
s1: the method comprises the steps that a distributed cross-domain cooperation module for realizing distributed application coordination service is arranged, one or more SDN controllers are configured in each SDN, an agent module is correspondingly arranged for each SDN controller, and the agent module is used for realizing communication between the SDN controller and the distributed cross-domain cooperation module;
s2: a transaction registration path in a distributed cross-domain cooperation module is specified for each SDN in advance, a registration path in the distributed cross-domain cooperation module is specified for each agent module, when the agent module needs to be started, whether the corresponding registration path of the agent module in the distributed cross-domain cooperation module is occupied or not needs to be checked, if yes, the agent module is registered in the registration path by other SDN controllers in the current SDN, and the registration path needs to be released at the moment; if the registered path is not occupied, the agent module creates a corresponding registered path to indicate that the registered path is occupied; then detecting whether a transaction registration path of the SDN network exists in the distributed cross-domain cooperation module, if not, creating the transaction registration path, and creating a corresponding task request path and a task reply path, and if so, associating the task request path and the task reply path under the transaction registration path; finally, starting the rest part of the agent module;
after each agent module is started, monitoring a task request path of each agent module under a transaction registration path of the distributed cross-domain cooperation module;
s3: monitoring an upper-layer application in an SDN network to which a corresponding SDN controller belongs by each agent module, and assuming that a certain agent module agent _ a in the SDN network A receives a task request from the upper-layer application, firstly, carrying out validity judgment on the task request by the agent module agent _ a, if the task request is judged to be illegal, directly discarding the task request, and if the task request is judged to be legal, entering a step S4;
s4: the agent module agent _ a analyzes the received task request, judges whether a target domain of the task request is a current SDN network, namely an SDN network A, if so, enters a step S5, otherwise, enters a step S6;
s5: the agent module agent _ a converts the task request into a message format of an SDN controller in the SDN network A and sends the message format to the SDN controller, the SDN controller receives the task request and processes the task request, a processing result is fed back to the agent module agent _ a, and the agent module agent _ a forwards the processing result to upper-layer application;
s6: recording a target domain as an SDN (software defined network) B, registering a task request to a task request path corresponding to the SDN B in a distributed cross-domain cooperation module by an agent module agent _ a, and monitoring a task reply path corresponding to the SDN B in the distributed cross-domain cooperation module;
when monitoring that a new node is created under a task request path of the SDN network B in the distributed cross-domain cooperation module, namely a new task request comes, an agent module agent _ B in the SDN network B extracts the task request, converts the task request into a message format of an SDN controller in the SDN network B and sends the message format to the SDN controller, the SDN controller receives the task request and processes the task request, a processing result is fed back to the agent module agent _ B, and the agent module agent _ B writes the processing result into a corresponding task reply path of the SDN network B in the distributed cross-domain cooperation module;
and when the agent module agent _ a monitors that reply data of the SDN network B in a corresponding task reply path in the distributed cross-domain cooperation module arrives, extracting the processing result and forwarding the processing result to the upper layer application.
The SDN cross-domain cooperation method based on the distributed service framework is characterized in that a distributed cross-domain cooperation module for realizing distributed application coordination service is arranged, an agent module is arranged for an SDN controller in each SDN network, and the agent module is used for realizing communication between the SDN controller and the distributed cross-domain cooperation module; the upper layer application sends the task request to the agent module, if the task request is an intra-domain task request, the agent module sends the task request to the intra-domain controller for processing, if the task request is an extra-domain task request, the task request is forwarded to the agent module of the target domain through the distributed cross-domain cooperation module, then the agent module of the target domain sends the task request to the SDN controller of the target domain for processing, and a processing result is also fed back through the distributed cross-domain cooperation module.
The invention has the following beneficial effects:
1) the distributed cross-domain cooperation module is arranged to serve as a global data bus and a distributed registry to solve the problem of cross-domain data sharing;
2) according to the invention, the agent module is arranged for the SDN controller, so that direct access of external application to the SDN controller is shielded, the external application only needs to perform information interaction with the agent module, and cross-domain information interaction is completed by means of a cooperation mechanism of the distributed cross-domain cooperation module.
Drawings
Fig. 1 is a flowchart of a specific embodiment of an SDN cross-domain cooperation method based on a distributed service framework according to the present invention;
FIG. 2 is a flow diagram of the agent module initiation of the present invention;
FIG. 3 is a flowchart of the out-of-domain task request processing of the present invention;
figure 4 is a SDN network system architecture diagram in the present embodiment;
fig. 5 is an architecture diagram in an SDN network domain in the present embodiment.
Detailed Description
The following description of the embodiments of the present invention is provided in order to better understand the present invention for those skilled in the art with reference to the accompanying drawings. It is to be expressly noted that in the following description, a detailed description of known functions and designs will be omitted when it may obscure the subject matter of the present invention.
Examples
Fig. 1 is a flowchart of a specific embodiment of an SDN cross-domain cooperation method based on a distributed service framework according to the present invention. As shown in fig. 1, the SDN cross-domain cooperation method based on the distributed service framework of the present invention includes the specific steps of:
s101: setting a cross-domain cooperative network:
the method comprises the steps of setting a distributed cross-domain cooperation module for realizing distributed application coordination service, configuring one or more SDN controllers for each SDN network, and setting an Agent module (Agent) for each SDN controller for realizing communication between the SDN controller and the distributed cross-domain cooperation module.
According to the invention, the SDN controller is decoupled from an external distributed cross-domain cooperation set by arranging the proxy module. When a certain SDN network is provided with more than one SDN controller, the SDN controllers can form a controller cluster, and the agent modules can also form a cluster due to the one-to-one correspondence relationship between the agent modules and the SDN controllers, so that the problem of single-point failure can be avoided. The agent module can be generally divided into a front end and a back end, wherein the front end is responsible for receiving the application request, the back end is responsible for actual request processing, and data is transmitted between the front end and the back end in an inter-thread communication mode. The front-end module can deal with concurrent access of a plurality of applications, and the front-end module can maintain corresponding data for each upper-layer application connection without worrying about data pollution. And after the format of the message transmitted between the upper layer application and the agent module is defined, the interaction can be carried out.
The distributed cross-domain cooperation module actually replaces the role of a root controller in the traditional hierarchical system architecture, and each agent module registered to the distributed cross-domain cooperation module can acquire globally shared data. Different from the traditional SDN cross-domain method, the computing processes such as network virtualization and the like can be put on the proxy module and decoupled with lower-layer equipment, various distributed transactions can be conveniently realized, and the traditional SDN cross-domain method is not easy to realize.
In practical application, the distributed cross-domain cooperation module can be a cluster formed by a plurality of distributed cross-domain cooperation nodes, and the method can improve the throughput and avoid the problem of single point failure.
S102: the agent module starts:
a transaction registration path in the distributed cross-domain cooperation module is defined for each SDN network in advance, and a registration path in the distributed cross-domain cooperation module is defined for each agent module to be used by the agent module. Fig. 2 is a flow chart of the proxy module initiation in the present invention. As shown in fig. 2, when an agent module needs to be started, it is first required to check whether a registration path corresponding to the agent module in the distributed cross-domain cooperation module is occupied, and if so, it indicates that an agent module of another SDN controller is registered in the registration path in the current SDN network, and at this time, it is required to wait for the release of the registration path; if not, the agent module creates a corresponding registration path to indicate occupation. And then detecting whether a transaction registration path of the SDN network exists in the distributed cross-domain cooperation module, if not, creating the transaction registration path, creating a corresponding task request path and a corresponding task reply path, and if so, reading the task request path and the task reply path under the transaction registration path. The remaining part of the agent module is finally started, and generally speaking, the front-end module of the agent module needs to be started successively to receive the request of the upper-layer application and the back-end module needs to be started to really process the request.
After each agent module is started, monitoring a task request path and a task reply path of each agent module under a transaction registration path of the distributed cross-domain cooperation module so as to timely acquire the arrival and the forwarding data of the task request outside the domain.
S103: receiving a task request of an upper layer application:
each agent module monitors upper-layer application in the SDN network to which the corresponding SDN controller belongs, and supposing that a certain agent module agent _ a in the SDN network A receives a task request from the upper-layer application, firstly, the agent module agent _ a judges the legality of the task request, if the task request is judged to be illegal, the agent module agent _ a directly discards the task request, and if the task request is judged to be legal, the operation goes to step S104.
When the SDN network is configured with the SDN controller cluster, there are a plurality of proxy modules, so when processing a task request of an upper layer application, one proxy module may be selected to execute according to a preset policy, for example, a primary proxy module and a standby proxy module may be set and executed by the primary proxy module, or a load balancing policy may be adopted, so that the problem of single point failure may be avoided.
S104: the agent module agent _ a analyzes the received task request, and judges whether a target domain of the task request is a current SDN network, namely an SDN network A, if so, the step S105 is performed, otherwise, the step S106 is performed.
S105: and (3) intra-domain task request processing:
because the intra-domain task requests belonging to the same SDN network do not relate to external information, the agent module agent _ a converts the task requests into a message format of an SDN controller in the SDN network A and sends the message format to the SDN controller, the SDN controller receives the task requests and processes the task requests, processing results are fed back to the agent module agent _ a, and the agent module agent _ a forwards the processing results to an upper-layer application.
S106: and (3) processing the out-of-domain task request:
where the request involves cross-domain, fig. 3 is a flow diagram of the out-of-domain task request processing. As shown in fig. 3, the target domain is denoted as an SDN network B, the agent module agent _ a registers the task request to a corresponding path of the distributed cross-domain cooperation module, that is, registers to a task request path corresponding to the SDN network B in the distributed cross-domain cooperation module, and monitors a task reply path corresponding to the SDN network B in the distributed cross-domain cooperation module.
When the agent module agent _ B in the SDN network B monitors that a new node is created under a task request path of the SDN network B in the distributed cross-domain cooperation module, namely a new task request comes, the task request is extracted, the task request is converted into a message format of an SDN controller in the SDN network B and is sent to the SDN controller, the SDN controller receives the task request and then processes the task request, a processing result is fed back to the agent module agent _ B, and the agent module agent _ B writes the processing result into a corresponding task reply path of the SDN network B in the distributed cross-domain cooperation module.
And when the agent module agent _ a monitors that reply data of the SDN network B in a corresponding task reply path in the distributed cross-domain cooperation module arrives, extracting the processing result and forwarding the processing result to the upper layer application.
In order to better illustrate the invention, a detailed description of the invention is given using a specific example.
The distributed cross-domain collaboration module in this embodiment is implemented based on Zookeeper. The ZooKeeper is an open-source, mature and highly reliable distributed coordination service framework, is a software framework for providing a consistency service guarantee for distributed applications, and provides main functions including: distributed synchronization, configuration center, registry service, and the like. The architecture of the Zookeeper is similar to a file system, each znode in the Zookeeper is a path, and the znode can store data such as state information and configuration information. In this embodiment, a Zookeeper clustering mode is adopted, and for clustered Zookeeper, the following roles are mainly divided: leader, Follower, and Observer. In the Zookeeper cluster, the Leader node processes the write request and synchronizes the data changes to other role nodes in the cluster. Follower mainly handles read requests and participates in the election of a Leader, and when a Leader in the cluster hangs, a new Leader will be spawned from the rest of Follower. While the Observer does not participate in the election of the Leader although it also processes the read request, the role is mainly set to improve the throughput of the cluster read operation and not increase the cost of the Leader election. Leader and Follower are the necessary roles in the Zookeeper cluster, while the Observer is optional.
Fig. 4 is a system architecture diagram of the SDN network in the present embodiment. As shown in fig. 4, the SDN network system of this embodiment includes 3 SDN networks, that is, SDN Cluster1, SDN Cluster2, and SDN Cluster3, and the distributed cross-domain collaboration module includes 3 nodes, that is, node1, node2, and node 3.
Fig. 5 is an architecture diagram in an SDN network domain in the present embodiment. As shown in fig. 5, in the present embodiment, each SDN network is configured with 3 SDN controllers, and each SDN controller is configured with one Agent module Agent. In this embodiment, the agent module is placed in a separate host to operate, and certainly, the agent module may be set on a host corresponding to the SDN controller to operate. The agent module interacts with the upper layer application through the domain name. The upper layer application maps a domain name to the address of the proxy module using a domain name service, which may be based on the domain name service in the existing SDN network environment. The advantage of using the domain name service is that even when some Agent modules agents fail down, the upper layer applications can still access the available Agent modules agents through the domain name service. The Agent module Agent communicates with the SDN controller through a northbound REST interface of the controller.
Then registering the Agent module Agent to a registration center of the Zookeeper cluster, wherein the specific process is as follows:
when the agent module is started, whether a registration path of the agent module in a Zookeeper cluster registration center is occupied or not needs to be checked, if yes, the agent module indicates that the agent module of other SDN controllers in an SDN controller cluster of the SDN network is registered in the registration path, the release of the registration path needs to be waited, and if the agent module is not occupied, the agent module creates a corresponding registration path to indicate that the agent module is occupied. Then detecting whether a transaction registration path of the SDN network exists in the Zookeeper cluster registration center or not, if not, creating the transaction registration path, and creating a corresponding task request path and a task reply path, and if so, associating the task request path and the task reply path under the transaction registration path; finally the rest of the proxy module is started.
After the Agent module Agent is started, the upper layer application can start to send the request, and as for the intra-domain task request, the processing process is simple, and is not described in detail herein. The out-of-domain task request is illustrated next.
Suppose that an upper-layer application App1 in the SDN Cluster1 sends a task request to a proxy module agent _1 in the SDN Cluster1 through the domain name www.Agent1.com, where the task request is intended to obtain network topology information of the SDN Cluster2, and the specific processing procedure is as follows:
1) after receiving the task request and passing the validity verification, the agent module agent _1 determines that the destination domain of the task request is SDN Cluster 2. Therefore, the agent module agent _1 creates a request node, for example, "/Cluster 2_ reg/request/1234", to the Zookeeper Cluster and writes the task request information, where "1234" is the task request ID and is parsed from the task request message of the upper application App 1. In addition, a reply node is also created, for example, "/Cluster 2_ reg/response/1234", and then the agent module agent _1 of SDN Cluster1 listens to "/Cluster 2_ reg/response/1234" and waits for the processed data to arrive.
2) The agent module agent _2 in the SDN Cluster2 is constantly listening "/Cluster 2_ reg/request/", so that it can immediately monitor that a new request arrives, extract the request and convert the request into a REST request, delete "/Cluster 2_ reg/request/1234", send the REST request to the SDN controller in the SDN Cluster2, and send the processing result to the agent module agent _2 after the SDN controller completes processing. The agent module agent _2 uploads the processing result to the task reply path "/Cluster 2_ reg/response/1234".
3) And monitoring the arrival of a processing result by an agent module agent _1 in the SDN Cluster1, extracting the processing result data, deleting "/Cluster 2_ reg/response/1234", and finally forwarding the processing result data to an upper-layer application App 1.
Up to this point, the upper layer application App1 in SDN Cluster1 obtains the network topology data of the out-of-domain SDN Cluster 2. Similarly, the upper application App2 in the SDN Cluster2 may also obtain network topology data of the SDN Cluster1 by sending a task request to the domain name www.Agent2.com of the proxy module agent _ 2. For intra-domain task requests, the agent module would go directly to the intra-domain controller since no external network is involved. After both sides master the global network topology data, the application of each domain can send some cross-domain routing requests, then the Agent module Agent calculates the routing path and forms the corresponding REST request, and finally the north interface of the controller is used for issuing the flow table, thereby realizing the inter-domain communication.
Although illustrative embodiments of the present invention have been described above to facilitate the understanding of the present invention by those skilled in the art, it should be understood that the present invention is not limited to the scope of the embodiments, and various changes may be made apparent to those skilled in the art as long as they are within the spirit and scope of the present invention as defined and defined by the appended claims, and all matters of the invention which utilize the inventive concepts are protected.
Claims (2)
1. An SDN cross-domain cooperation method based on a distributed service framework is characterized by comprising the following steps:
s1: the method comprises the steps that a distributed cross-domain cooperation module for realizing distributed application coordination service is arranged, one or more SDN controllers are configured in each SDN, an agent module is correspondingly arranged for each SDN controller, and the agent module is used for realizing communication between the SDN controller and the distributed cross-domain cooperation module;
s2: a transaction registration path in a distributed cross-domain cooperation module is specified for each SDN in advance, a registration path in the distributed cross-domain cooperation module is specified for each agent module, when the agent module needs to be started, whether the corresponding registration path of the agent module in the distributed cross-domain cooperation module is occupied or not needs to be checked, if yes, the agent module is registered in the registration path by other SDN controllers in the current SDN, and the registration path needs to be released at the moment; if the registered path is not occupied, the agent module creates a corresponding registered path to indicate that the registered path is occupied; then detecting whether a transaction registration path of the SDN network exists in the distributed cross-domain cooperation module, if not, creating the transaction registration path, and creating a corresponding task request path and a task reply path, and if so, associating the task request path and the task reply path under the transaction registration path; finally, starting the rest part of the agent module;
after each agent module is started, monitoring a task request path and a task reply path of each agent module under a transaction registration path of the distributed cross-domain cooperation module so as to acquire the arrival and forwarding data of the task request outside the domain in time;
s3: monitoring upper-layer applications in the SDN network to which the corresponding SDN controller belongs by each agent module, firstly, judging the legality of a task request by a certain agent module agent _ a in the SDN network A after the certain agent module agent _ a receives the task request from the upper-layer applications, directly discarding the task request if the task request is judged to be illegal, and entering a step S4 if the task request is judged to be legal;
s4: the agent module agent _ a analyzes the received task request, judges whether a target domain of the task request is a current SDN network, namely an SDN network A, if so, enters a step S5, otherwise, enters a step S6;
s5: the agent module agent _ a converts the task request into a message format of an SDN controller in the SDN network A and sends the message format to the SDN controller, the SDN controller receives the task request and processes the task request, a processing result is fed back to the agent module agent _ a, and the agent module agent _ a forwards the processing result to upper-layer application;
s6: recording a target domain as an SDN (software defined network) B, registering a task request to a task request path corresponding to the SDN B in a distributed cross-domain cooperation module by an agent module agent _ a, and monitoring a task reply path corresponding to the SDN B in the distributed cross-domain cooperation module;
when monitoring that a new node is created under a task request path of the SDN network B in the distributed cross-domain cooperation module, namely a new task request comes, an agent module agent _ B in the SDN network B extracts the task request, converts the task request into a message format of an SDN controller in the SDN network B and sends the message format to the SDN controller, the SDN controller receives the task request and processes the task request, a processing result is fed back to the agent module agent _ B, and the agent module agent _ B writes the processing result into a corresponding task reply path of the SDN network B in the distributed cross-domain cooperation module;
and when the agent module agent _ a monitors that a processing result of the SDN network B in a corresponding task reply path in the distributed cross-domain cooperation module arrives, extracting the processing result and forwarding the processing result to an upper-layer application.
2. The SDN cross-domain collaboration method of claim 1, wherein the distributed cross-domain collaboration module is implemented based on Zookeeper and deployed in a Zookeeper cluster manner.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010128313.0A CN111355658B (en) | 2020-02-28 | 2020-02-28 | SDN cross-domain cooperation method based on distributed service framework |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010128313.0A CN111355658B (en) | 2020-02-28 | 2020-02-28 | SDN cross-domain cooperation method based on distributed service framework |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111355658A CN111355658A (en) | 2020-06-30 |
| CN111355658B true CN111355658B (en) | 2021-07-13 |
Family
ID=71197123
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010128313.0A Expired - Fee Related CN111355658B (en) | 2020-02-28 | 2020-02-28 | SDN cross-domain cooperation method based on distributed service framework |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111355658B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112565215A (en) * | 2020-11-25 | 2021-03-26 | 电信科学技术第十研究所有限公司 | REST application architecture and construction method based on distributed service agent |
| CN113382453B (en) * | 2021-08-12 | 2021-10-29 | 北京小鸟科技股份有限公司 | Cross-domain graph transmission method and system based on enhanced static routing calculation and source return |
| CN114448984B (en) * | 2021-12-27 | 2024-01-09 | 国家电网有限公司信息通信分公司 | Adaptation method of cross-platform universal SDN controller |
| CN115314356B (en) * | 2022-08-09 | 2023-11-24 | 中电云计算技术有限公司 | Cross-region distributed SDN control device and method based on OVN |
| CN117240774B (en) * | 2023-11-15 | 2024-01-23 | 云南省地矿测绘院有限公司 | Cross-domain intelligent SDN routing method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105915419A (en) * | 2015-11-25 | 2016-08-31 | 北京邮电大学 | Wireless access controller deployment method based on SDN (Software Defined Network) |
| CN108574627A (en) * | 2017-03-08 | 2018-09-25 | 国网信息通信产业集团有限公司 | A kind of more control domain collaborative management methods of SDN network and system |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104717098B (en) * | 2015-04-09 | 2017-12-29 | 北京邮电大学 | A kind of data processing method and device |
| CN105207995B (en) * | 2015-08-18 | 2019-06-07 | 上海斐讯数据通信技术有限公司 | A kind of VLAN dynamic registration method based on SDN |
| CN107872340B (en) * | 2016-09-27 | 2021-09-07 | 华为技术有限公司 | Single board registration method, single board and forwarding equipment |
| US10397124B2 (en) * | 2017-01-17 | 2019-08-27 | Argela Yazilim ve Bilisim Teknolojileri San. ve Tic. A.S. | System and method to prevent persistent full switch queues in software defined networks |
-
2020
- 2020-02-28 CN CN202010128313.0A patent/CN111355658B/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105915419A (en) * | 2015-11-25 | 2016-08-31 | 北京邮电大学 | Wireless access controller deployment method based on SDN (Software Defined Network) |
| CN108574627A (en) * | 2017-03-08 | 2018-09-25 | 国网信息通信产业集团有限公司 | A kind of more control domain collaborative management methods of SDN network and system |
Non-Patent Citations (2)
| Title |
|---|
| "A Multi-Domain SDN Scalability Architecture implementation based on the Coordinate Controller";Jianglong Wang等;《2016 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery》;20161231;全文 * |
| "基于组策略的SDN多粒度流量检测系统";杜瑞颖等;《计算机工程》;20170430;第43卷(第4期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111355658A (en) | 2020-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111355658B (en) | SDN cross-domain cooperation method based on distributed service framework | |
| EP2731313B1 (en) | Distributed cluster processing system and message processing method thereof | |
| US20080256239A1 (en) | Method and system for optimizing a network by independently scaling control segments and data flow | |
| US11153185B2 (en) | Network device snapshots | |
| JP2002508123A (en) | System and method for a multilayer network element | |
| US8848522B2 (en) | Telecommunications system and server apparatus | |
| JP2005502228A (en) | Data communication processing method, computing device, and computer-readable medium | |
| CN112202930B (en) | Method, POP and system for accessing mobile equipment to SD-WAN (secure digital-to-WAN) network | |
| JP2002271363A (en) | Network connection device | |
| CN109756474B (en) | Service cross-region calling method and device for power dispatching automation system | |
| WO2021249432A1 (en) | Network automation orchestration management method, entity, controller and electronic device | |
| CN105683929A (en) | Method and equipment for sensing router by database and memory | |
| EP3588859B1 (en) | Network device configuration versioning | |
| JP2022532731A (en) | Avoiding congestion in slice-based networks | |
| CN109547452A (en) | The method and system of TCP Transparent Proxy are realized on Linux bridge equipment | |
| CN112491984B (en) | Container editing engine cluster management system based on virtual network bridge | |
| CN112202940A (en) | Pod service mode for external exposure of kubernets | |
| CN108200199B (en) | Load balancing system and method in IPV4over IPV6 tunnel scene | |
| CN114143258B (en) | Service agent method based on Open vSwitch under Kubernetes environment | |
| CN101867521A (en) | Multilink accessing and flow load dispatching managing method | |
| Myrda et al. | Recommended approach to a NASPInet architecture | |
| JP2016048811A (en) | Network extension system, control device, and network extension method | |
| JP2017135545A (en) | Network management system, network management method, and program | |
| US10333792B2 (en) | Modular controller in software-defined networking environment and operating method thereof | |
| Liu et al. | Network Architecture Design of Big Data Real-Time Processing System |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20210713 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |