Software Defined Network (SDN) is a new network innovation architecture that builds an open and programmable network architecture by decoupling network control from network forwarding. SDN abstracts the network to shield the underlying complexity and provides simple, efficient configuration and management for the upper layer. Among them, the SDN in a narrow sense refers to a network of the southbound interface based on the OpenFlow protocol, while the SDN in a broad sense refers to all the networks with that concept.
The Open Networking Foundation (ONF) proposes and advocates an SDN network based on the OpenFlow protocol. FIG. 1 is a schematic diagram of an architecture of the SDN proposed by the ONF in the existing technology. As shown in FIG. 1, the SDN generally includes an application layer, a control layer and an infrastructure layer. Herein, the upper layer is the application layer, including various services and applications; and the control layer in the middle is mainly responsible for dealing with orchestration of data plane resource, maintenance of network topology and state information, etc.; and the lowest layer is the infrastructure layer and mainly responsible for data processing, forwarding and status collection. The interface between the control layer and the infrastructure layer is called the southbound interface which uses the OpenFlow protocol defined by ONF. The interface between the application layer and the control layer is called the northbound interface, which generally uses the Hypertext Transfer Protocol (HTTP) of the Representational State Transfer (REST) Application Program Interface (API) at present.
ONF also proposes a concept of multi-layer SDN, that is, there is more than one layer, i.e. multiple layers, for the SDN controller. Herein, it can be simply understood as single-domain SDN controller and multi-domain SDN controller. Of course, the multi-domain SDN controller may also have an upper SDN controller.
For the SDN controller, the Optical Internetworking Forum (OIF) proposes the northbound interface, that is, an interface definition framework for the REST API, which includes a call request application program interface (Call Request API), a connection request application program interface (Connection Request API), a directory services application program interface (Directory Services API), a path computation application program interface (Path Computation API), a topology database application program interface (Topology DB API), and so on. Among them, the interfaces use a JavaScript Object Notation (JSON) format to represent the attributes and values of the interfaces. In the OIF, the northbound interface defines only an attribute necessary for basic path computation.
In an architecture of the SDN in the existing technology, the SDN controller includes modules for path computation, topology abstraction, flow table management, link discovery, and so on. For the SDN controller, its advantage is flexible and open control, and a routing algorithm in the SDN controller directly determines to a great extent whether a final established service path meets the requirement of users. At present, there is no customized capability in routing algorithm part of the SDN controller, and algorithms implemented by different manufacturers are different. In general, some default routing algorithms can deal with the basic requirements, but when a requirement for path computation of an application (APP) is various and special, multiple fixed common routing algorithms can not meet the requirements of users. In response to that situation, service providers need to provide a way for the APP to customizing a routing algorithm, such that the APP can select a desired routing algorithm, and the routing algorithm can increase, update continuously to cope with customized requirements of the SDN for service path computation. From the view of current SDN standard and part of commercialized systems, the routing algorithm part is still closed and not open, thus greatly restricting the requirements of the users for the service path.
On the other hand, for the SDN network, the original routing algorithms need to be improved for large-scale networking. At present, some manufacturers have proposed an intelligent flow engine built in the SDN controller, which combines technologies, such as graph theory, linear programming and matrix compression etc. to reduce a global optimization computation time for an SDN large-scale network. It can be expected that an equipment manufacturer will introduce a corresponding private routing algorithm for the SDN network, into the SDN controller later. However, considering the introduction of SDN multi-domain controller, it involves coordination of multiple SDN single-domain controllers for path computation by an SDN multi-domain controller, since different SDN single-domain controllers may be provided by different manufacturers, there is a case where routing algorithms of different manufacturers are not compatible with each other. The higher the degree of privatization is, the more difficult the interworking is. That is especially obvious for the SDN network, due to the openness of the SDN, more SDN controllers from different manufacturers will be networked in a hybrid mode, interworking capability and compatibility problems will directly affect actual service processing capability of the SDN network.
USPTO Backgrounds
USPTO Backgrounds