CROSS REFERENCE OF RELATED APPLICATION

This is a U.S. National Stage under 35 U.S.C 371 of the International Application PCT/CN2017/086510, filed May 30, 2017.

BACKGROUND OF THE PRESENT INVENTION

Field of Invention

The present invention relates to the technical field of network communications, and more particularly to a software-definable network service configuration method.

Description of Related Arts

Computer networks usually consist of a plurality of routers, and network middleware with various functions. In order to effectively manage the network, administrators formulate various policies based on the services carried by the current network, such as video, language, Web, and etc. Due to the lack of available tools, administrators need to manually convert these advanced policies into low-level configuration commands capable of being recognized by network devices. The task is challenging and extremely error-prone.

Another difficulty that can hardly be overcome by network practitioners and researchers is the “rigidity” of the Internet. The huge deployment scale of the Internet has made it a key infrastructure in the society. With the continuous expansion of deployment scale, the evolution and change of the Internet itself has become more and more difficult. The internet, which was designed to solve the basic interconnection problems decades ago, is becoming more and more powerless in the face of the various and ever-changing problems.

In the above background, the programmable network represented by IETF ForCES (Forwarding and Control Seperation, ForCES) is proposed as a means to promote network evolution. Software Defined Network (SDN) is a new form of programmable network that provides a new type of network architecture. By separating the forwarding and control planes in the network, SDN aims to simplify network management, support network innovation and evolution, and is expected to fundamentally solve the “rigid” problem of the Internet.

As mentioned above, the current Internet is “rigid”, and the root cause of this “rigid” phenomenon is the excessive coupling between the network control plane and the data plane. Each network device makes independent decisions on the data flowing through. In this kind of network environment, deploying a new service is undoubtedly not an easy task because the administrator needs to configure each device in the basic network. Of course, as an alternative solution to the “rigid” problem of the Internet, a large number of various network function boxes, such as firewalls, intrusion detection systems, and address converters, etc., can be placed on the basic interconnection part at the bottom of the network. For managers, the cost of management is too high and it is a last resort choice.

The fundamental goal of the separation of forwarding and control is to enable easy programming of the network data path. By separating the control and physical forwarding of the network equipment, centralized control within the entire network is realized. The so-called centralized control does not mean that there is only one physical controller in the network, but a logical centralized control. Obviously, this control method is good for deploying new network protocols and services. The global network view is conducive to network management and integration of various network function systems.

SUMMARY OF THE PRESENT INVENTION

In order to solve the technical problems, the present invention adopts a technical solution which comprises following steps of:

step (1) providing an application layer, a control layer and a data layer to constitute a network, wherein an entity of the control layer is a controller, and an entity of the data layer is a physical switch;

step (2) describing a required service through the application layer by a user, forming a service request and transferring the service request via a web service interface to the controller;

step (3) sending a first control message Msg-1 to all physical switches in the data layer in a broadcast mode by the controller to inquire capabilities of each of the physical switches;

wherein the first control message comprises 8 fields of: a message type (MsgType), a service ID (SrvID), a service description (SrvDesc), receiving node set (RecvSets), transmitting node sets (TransSets), a service support (SrvSupport), a service configuration result (ConfResult) and a service configuration cost (ConfCost); wherein a MsgType value of 0 represents query, a MsgType value of 1 represents reply, a MsgType value of 2 represents service installation and a MsgType value of 3 represents service;

wherein when querying capabilities of each of the physical switches, the MsgType in Msg-1 is set to 0, an initial value of the RecvSets is set to null; initial values of SrvSupport, ConfResult and ConfCost are all set to −1;

step (4) after receiving Msg-1, firstly checking whether the physical switches support services corresponding to SrvID by the physical switches; if the physical switches fail to support services corresponding to SrvID, a value of the SrvSupport is set to 1; if the physical switches are capable of supporting the services corresponding to SrvID, a value of the SrvSupport is set to 0;

step (5) the value of the SrvSupport set in the step (4) is written into a second control message (Msg-2) by the physical switches; wherein the value of MsgType is set to 1, other field values are identical to Msg-1; the Msg-2 is sent back to the controller in a unicast mode;

step (6) after receiving the Msg-2 by the controller, selecting the physical switches being capable of supporting the service corresponding to the SrvID; and constituting a virtual net vNet based on the service corresponding to the SrvID;

step (7) executing a user-defined path planning algorithm in the virtual net vNet to obtain optimal service deployment path (Path), so as to constitute service install nodes set (SrvInstallSets); wherein each element in the SrvInstallSets corresponds to a physical switch in the Path;

step (8) transmitting a third control massage (Msg-3) to each of the physical switches on the Path in a multicast mode by the controller; and starting an installing process of a service corresponding to the SrvID;

wherein a MsgType of the third control message (Msg-3) is set 2, a field of the RecvSets is set to SrvInstallSets; a field of the SrvSupport is set to 1, a field of the ConfResult is set to −1 and a field of the ConfCost is set to −1;

step (9) after receiving the third control message Msg-3, each of the physical switches executing following steps of:

step (9-1) determining whether the physical switches belong to the field of RecvSets in the Msg-3, if no, a value of the field of the ConfResult is set to 2, enter step (9-3); if yes, directly enter a step (9-2);

step (9-2) executing a service installing process by the physical switches, wherein if the installing process succeeds, the value of the field of the ConfCost is set to be an overhead of the current resource; while the value of the field of ConfResult is set to 0; if the installing process is failed, the value of the field of ConfResult is set to 1;

step (9-3) writing values of fields which are revised into a fourth control message (Msg-4) by the physical switches, wherein MsgType is set to 1, other fields are identical to the third control message Msg-3; transmitting the fourth control message Msg-4 back to the controller in a unicast mode;

step (10) traversing the control message Msg-4 transmitted back by each of the physical switches in the nodes set SrvInstallSets by the controller; wherein if the value of the field of the ConfResult of the fourth control message Msg-4 is 0, service configuration is successful; updating messages in the virtual net vNet according to the field of ConfCost; wherein if not all values of fields of the ConfResult of all of the control messages are 0, the service configuration is not successful; executing following steps;

step (10-1) constituting a fifth control message Msg-5 by the controller; setting the MsgType to 3; wherein other fields of the Msg-5 are identical to the fields of the Msg-3; wherein the fifth control messages Msg-5 are transmitted to each of the physical switches on the Path in a multicast mode;

step (10-2) uninstalling service corresponding to SrvID after receiving the Msg-5 by the physical switches;

finding out a physical switch corresponded to the fourth control message Msg-4 with a ConfResult field value of 1 by the controller and identifying the physical switch as unavailable in the vNet; entering the step (7).

Beneficial effects of the present invention are as follows. Service deployment in the conventional network is very complicated. Operator needs to plan the service path in advance, and then manually configure the policy for each node on the service path. The software-definable network service configuration method disclosed in the present invention is different from the conventional network. On the one hand, the control layer has a global network resource view to more easily plan service paths for service requests. On the other hand, the control layer adopts a centralized management of physical switch nodes in the data layer via a southbound interface, which makes it easier to automatically implement policy configuration in physical switch nodes.

