A software-defined network improves the network management and operation by physically separating the control of the network from the data path of the network [18]. This concept is radically different from the way networks currently operate. Networks today are distributed systems in which the devices share information to determine the best possible routes. These distributed systems can be slow to react to changes in network traffic, and routes may be sub-optimal because each router typically does not know the full topology; even protocols that share network-wide link state may not have knowledge of the full topology because of route aggregation [19]. The controller must be able to determine the current, global state. Using the current state, the controller can find globally optimal solutions to improve performance.
1. General Architecture
The Open Networking Foundation defines a three-layer SDN model as depicted in Figure 1 [20]. The infrastructure layer is the physical topology, which is composed of SDN-enabled switches and the links between them. The switches take flow rules as input from the controller and provide statistics about network traffic to the controller as an output. They are also the data forwarding devices that receive individual packets and then transmit these packets toward the intended destination.
Figure 1. The three layer SDN protocol architecture includes the infrastructure layer, the control layer, and the application layer, from [20]. OpenFlow
is the communication protocol between the control layer and the infrastructure layer.
The control layer develops the rules that are sent to the switches. The controller is programmable and uses the network traffic measurements to determine new routes. The controller is software that runs on a computer and communicates with the switches. The controller must be able to communicate with the switches using the OpenFlow communications protocol [21]. Examples of network services that are implemented by the controller include route determination, load-balancing, and topology discovery.
The control packets that are passed between the switches and the controller are separated from the data traffic. Typically, they are sent over a physically separate network called the control network. By having a physically separate control network potentially leads to a more secure implementation.
Network control is implemented via flow rules, which are sent to the switches from the controllers. Flow rules have two basics parts. The first part of the rule is the match, which defines which packets are processed by the rule. The second part of the rule is the action, which defines what action is taken. The flow rule matches various portions of the headers of packets that are received at the switches. The action portion of the rule tells the switch whether to change the header, drop the packet, route it out a specific port, flood the packet out all of the ports, or take some other action [20]. This ability to treat each device in a network individually provides a granularity of control that is unprecedented in traditional networks.
The interface from the application layer to the control layer, the northbound interface, has not been standardized. However, ONF has a working group actively exploring options to standardize this interface [22]. Examples of business applications are distributed denial of service (DDOS) protection, intrusion detection, and usage tracking for billing. Business applications allow an enterprise to choose which applications are required and to purchase those that are required.
In a typical SDN implementation, a single controller is communicating with multiple switches and possibly with other controllers of other domains, as shown in Figure 2. One of the drawbacks of centralization is the potential for a single point of failure for the network. Traditional networks detect a failed device and are able to recover due to the distributed nature of the system. To prevent a network failure due to a single device failure, multiple controllers must be implemented in the network. These controllers need to share information to ensure that there is a logically centralized network representation even though the controllers may be physically separated.
Figure 2. Typical SDNs are configured with multiple controllers to reduce the workload of any single controller or to reduce the impact of a loss of a
controller. 2. Operation of the Network
When a packet arrives at the SDN switch, the packet headers are checked against the match portion of the rules that the switch already installed in a flow table. If no match is found, the switch sends the packet to the controller via the OpenFlow interface. Next, the controller determines whether or not a new flow rule needs to be sent to the switch. Typically, the controller will create a new rule. The controller then determines the correct match and the correct action. The controller then sends a flow rule to the switch, which in turn installs this rule in the flow table as a flow entry. Subsequent packets, which match this flow entry, are acted upon correctly based on the newly installed rule. The controller is free to create, modify, and delete flow entries proactively and reactively.
A method to aid the controller in determining flow rules is to develop a graph theoretic model of the network and extract features based on that model. A network is modeled by graph theory as a single entity composed of a set of devices and the connections between these devices. Based on that model, matrix representations of the network can be developed and used for feature extraction. One of the goals of this work is to develop a scheme to extract network features and to control those features.