Software Defined Networking | Encyclopedia MDPI

Software Defined Networking: Comparison

Please note this is a comparison between Version 1 by __ Imran and Version 2 by Karina Chen.

Software Defined Networking(SDN)has recently received much attention to address some of the enduring networking challenges. SDN’s concept is based on ideas of generalization network hardware and decoupling the network controls software from the implementation devices . SDN is a new intelligent architecture for network programmability. SDN’s main idea is to separate the control plane from the network devices, enabling the data control from a central and external software entity called an SDN controller. The Open Networking Foundation (ONF) is a non-profit consortium dedicated to the development, standardization, and commercialization of SDN for the transport and IP network layer.

SDN
machine learning
IoT
SDN leveraging ML
IoT leveraging SDN

1. Introduction

Figure 1 presents SDN layered architecture, consisting of ^[1] four planes: data plane, management plane, control plane and application plane. The Data plane presents a forwarding table that forwards the incoming packets to a network device. Management plane provides intelligent provisioning and orchestration systems for entire network management. The control plane is also termed as the brain of the networks that control different types of data planes using SBIs and protocols. The application plane defines the layer on different northbound applications that exist, which can help out SDN perform and solve future challenges of 5G, as this plane brings innovation, openness, and flexibility for the network vendors. SDN architecture provides dynamicity, network flexibility, and management capabilities. Research studies suggest SDN is the most reliable and promising for separating strategic network computation and data forwarding.

2 presents SDN layered architecture, consisting of [17] four planes: data plane, management plane, control plane and application plane. The Data plane presents a forwarding table that forwards the incoming packets to a network device. Management plane provides intelligent provisioning and orchestration systems for entire network management. The control plane is also termed as the brain of the networks that control different types of data planes using SBIs and protocols. The application plane defines the layer on different northbound applications that exist, which can help out SDN perform and solve future challenges of 5G, as this plane brings innovation, openness, and flexibility for the network vendors. SDN architecture provides dynamicity, network flexibility, and management capabilities. Research studies suggest SDN is the most reliable and promising for separating strategic network computation and data forwarding.

Figure 12. SDN Architecture.

Several northbound interfaces (NBIs) between the control plane and applications were introduced to provide high-level abstractions to the applications that reside on the control plane and in the form of various network-level services. OpenFlow ^[2] is a significant addition to the southbound interfaces (SBIs) that enable the network to be managed efficiently. Nevertheless, SDN can not be limited to OpenFlow as other less conventional protocols exist such as ForCES ^[3], NETCONF ^[4], OVSDB ^[5], Pollex ^[6], LISP ^[7], and OpenState ^[8]. OpenFlow deports all the intelligence to a centralized entity called SDN controller, which enables the separation of the control plane from the forwarding plane. There are three SDN functions in the panorama of OpenFlow, status reporting for each device connection, slicing, and flow-based forwarding. OpenFlow-based interconnection device matches the packets against a flow table inside the forwarding plane. FlowVisor controller is responsible for handling the flows, decisions, and publishing of the policies.

Several northbound interfaces (NBIs) between the control plane and applications were introduced to provide high-level abstractions to the applications that reside on the control plane and in the form of various network-level services. OpenFlow [18] is a significant addition to the southbound interfaces (SBIs) that enable the network to be managed efficiently. Nevertheless, SDN can not be limited to OpenFlow as other less conventional protocols exist such as ForCES [19], NETCONF [20], OVSDB [21], Pollex [22], LISP [23], and OpenState [24]. OpenFlow deports all the intelligence to a centralized entity called SDN controller, which enables the separation of the control plane from the forwarding plane. There are three SDN functions in the panorama of OpenFlow, status reporting for each device connection, slicing, and flow-based forwarding. OpenFlow-based interconnection device matches the packets against a flow table inside the forwarding plane. FlowVisor controller is responsible for handling the flows, decisions, and publishing of the policies.

2. OpenFlow

OpenFlow provides an interface-based communication among the infrastructure and control layer based on open networking Foundation (ONF) ^[9][10]. Moreover, it provisions a way for controlling switches regardless of source code disclosure by the vendors. In summary, Openflow provides a way to directly access and manipulate the forward plan of switches and routers ^[11]. Furthermore, it grants access towards the flowable and provides instructions to the switches on managing and direct traffic of the network. It allows the network managers to alter the network flow in a short time span ^[12]. According to studies, there are two main categories of OpenFlow-based switches: OpenFlow-only and OpenFlow-hybrid. OpenFlow support is limited to OpenFlow operations, while the hybrid version supports operations and normal Ethernet switches ^[13].

OpenFlow provides an interface-based communication among the infrastructure and control layer based on open networking Foundation (ONF) [25,26]. Moreover, it provisions a way for controlling switches regardless of source code disclosure by the vendors. In summary, Openflow provides a way to directly access and manipulate the forward plan of switches and routers [27]. Furthermore, it grants access towards the flowable and provides instructions to the switches on managing and direct traffic of the network. It allows the network managers to alter the network flow in a short time span [28]. According to studies, there are two main categories of OpenFlow-based switches: OpenFlow-only and OpenFlow-hybrid. OpenFlow support is limited to OpenFlow operations, while the hybrid version supports operations and normal Ethernet switches [29].

The OpenFlow controllers are responsible for managing the OpenFlow switches based on a secure channel protocol called OpenFlow protocol. One or more flow tables are contained within a switch for performing a forwarding operation and packet tracing. A flow table includes a flow entry; each entry possesses header fields, specific counters, and actions. The purpose of a header field is to match up against packets with information related to VLAN, ID, source and destination ports and IP address, etc. There are counters for keeping information about the number of packets their sizes. Action provides information associated to processing and matching packets; Their forwarding action is also specified, such as being sent to the controller or a port or sometimes dropped ^[14][15][16]. OpenFlow channel provides an interface for connecting the switches and controllers. Using this interface, the switches are being managed and configured by the controller; additionally, the events are received, and packets are sent through the switches. Various messages are sent using this channel, including asynchronous messages that involve messages for updating the controller regarding the network event and state change. The second type is controller-to-switch messages; these messages are for managing and inspection of switch states. Lastly, symmetric messages are initiated by the switch or the controller and are sent unsolicited ^[17][18][19]. OpenFlow controller is responsible for managing, allocating, and updating instructions and policies to the networking devices. It can decide how to handle packets with invalid flow entries and control the switch flow table. OpenFlow switch can establish communication with one or more controllers. A multiple-controller architecture can increase network reliability if a switch fails. OpenFlow starts operations when the switch is connected to all its configured controllers simultaneously, whereas related messages are only sent to the next switch ^{[20][21][22][23]}.

The OpenFlow controllers are responsible for managing the OpenFlow switches based on a secure channel protocol called OpenFlow protocol. One or more flow tables are contained within a switch for performing a forwarding operation and packet tracing. A flow table includes a flow entry; each entry possesses header fields, specific counters, and actions. The purpose of a header field is to match up against packets with information related to VLAN, ID, source and destination ports and IP address, etc. There are counters for keeping information about the number of packets their sizes. Action provides information associated to processing and matching packets; Their forwarding action is also specified, such as being sent to the controller or a port or sometimes dropped [30,31,32]. OpenFlow channel provides an interface for connecting the switches and controllers. Using this interface, the switches are being managed and configured by the controller; additionally, the events are received, and packets are sent through the switches. Various messages are sent using this channel, including asynchronous messages that involve messages for updating the controller regarding the network event and state change. The second type is controller-to-switch messages; these messages are for managing and inspection of switch states. Lastly, symmetric messages are initiated by the switch or the controller and are sent unsolicited [33,34,35]. OpenFlow controller is responsible for managing, allocating, and updating instructions and policies to the networking devices. It can decide how to handle packets with invalid flow entries and control the switch flow table. OpenFlow switch can establish communication with one or more controllers. A multiple-controller architecture can increase network reliability if a switch fails. OpenFlow starts operations when the switch is connected to all its configured controllers simultaneously, whereas related messages are only sent to the next switch [36,37,38,39].

3. Data Plane

The Data plane resides at the bottom layer of SDN architecture, consisting of forwarding devices such as routers and switches, whether virtual or physical. Virtual switches are software-based switches that run on a common operating system (OS), examples of virtual switches are Open vSwitch ^[24], Pantou ^[25], and Indigo ^[26]. Physical switches are hardware-based switches, implemented either on open network hardware such as NetFPGA ^[27], or on a merchant switch from networking hardware vendors. ServerSwitch ^[28] and switchBlade ^[29] are two examples of NetFPGA-based physical switches. Hardware vendors design their’s merchant switches with the support of SDN protocols, for example virtual switches are more flexible and have complete feature support for SDN protocols. Physical switches have a high rate of flow forwarding as compared to virtual switches. Both are used to forward, drop, and modify packets using the control plane logic.

The Data plane resides at the bottom layer of SDN architecture, consisting of forwarding devices such as routers and switches, whether virtual or physical. Virtual switches are software-based switches that run on a common operating system (OS), examples of virtual switches are Open vSwitch [40], Pantou [41], and Indigo [42]. Physical switches are hardware-based switches, implemented either on open network hardware such as NetFPGA [43], or on a merchant switch from networking hardware vendors. ServerSwitch [44] and switchBlade [45] are two examples of NetFPGA-based physical switches. Hardware vendors design their’s merchant switches with the support of SDN protocols, for example virtual switches are more flexible and have complete feature support for SDN protocols. Physical switches have a high rate of flow forwarding as compared to virtual switches. Both are used to forward, drop, and modify packets using the control plane logic.

4. Control Plane

In SDN, the control plane acts as the brain that performs a set of actions; for example, it applies flow rules to handle the received ethernet frames that decide the traffic destination ports. SDN controller program network resources, control communication between applications and forwarding devices. SDN controller translates application plane requirements into policies and distributes these custom policies into forwarding devices. Control plane functionalities include network topology storage, configuration of devices, notification of state information, and shortest path routing. Some of the SDN controller architectures proposed in literature are NOX ^[30], Floodlight ^[31], POX ^[32], OpenDayLight ^[33], Ryu ^[34], and Beacon ^[35]. SDN controller has three interfaces for communication: southbound, eastbound westbound. Control data plane interfaces (CDPIs) are interfaces between the data and control plane. CDPIs are also called SBIs, used for forwarding devices to exchange control policies and network state information with the control plane of an SDN controller. SBIs allow programmatic-based control of all device capabilities such as event notifications, advertisements, statistic reports, and forwarding operations. NBIs are exploited by applications to get an abstract view of the network to facilitate automation, analyze specific network behaviors, and analyze network requirements. Eastbound interfaces (EBIs) and westbound interfaces (WBIs) are used in the multi-controller SDN solutions. In multi-controller SDN networks, the exchange of information is important between controllers to provide a global network view to the applications. Examples of distributed control architectures are HyperFlow ^[36] and Onix ^[37]. EBIs and WBIs are private and cannot communicate with each other. SDN communication-interfaces ^[38], distributed-control plane (CIDC) ^[39], and east-west bridge ^[40] are some proposals for communication between different SDN controllers.

In SDN, the control plane acts as the brain that performs a set of actions; for example, it applies flow rules to handle the received ethernet frames that decide the traffic destination ports. SDN controller program network resources, control communication between applications and forwarding devices. SDN controller translates application plane requirements into policies and distributes these custom policies into forwarding devices. Control plane functionalities include network topology storage, configuration of devices, notification of state information, and shortest path routing. Some of the SDN controller architectures proposed in literature are NOX [46], Floodlight [47], POX [48], OpenDayLight [49], Ryu [50], and Beacon [51]. SDN controller has three interfaces for communication: southbound, eastbound westbound. Control data plane interfaces (CDPIs) are interfaces between the data and control plane. CDPIs are also called SBIs, used for forwarding devices to exchange control policies and network state information with the control plane of an SDN controller. SBIs allow programmatic-based control of all device capabilities such as event notifications, advertisements, statistic reports, and forwarding operations. NBIs are exploited by applications to get an abstract view of the network to facilitate automation, analyze specific network behaviors, and analyze network requirements. Eastbound interfaces (EBIs) and westbound interfaces (WBIs) are used in the multi-controller SDN solutions. In multi-controller SDN networks, the exchange of information is important between controllers to provide a global network view to the applications. Examples of distributed control architectures are HyperFlow [52] and Onix [53]. EBIs and WBIs are private and cannot communicate with each other. SDN communication-interfaces [54], distributed-control plane (CIDC) [55], and east-west bridge [56] are some proposals for communication between different SDN controllers.

5. Application Plane

The top layer in the SDN is called the application plane, consisting of business applications. Business applications provide management and optimization of business services. These applications implement the control logic based on the network state information received from controller NBIs to modify the network behavior. In the study, ^[41] the solutions of SDN for traffic engineering are discussed. In paper ^[42], a security-based survey study is conducted. Yan et al. ^[43] proposed analysis of distributed denial of service (DDoS) attacks in SDN networks in a cloud computing environment. A survey on fault management issues in SDN and its solutions is presented in ^[44]. SDN is deployed in real-time scenarios including transport network, wireless networks ^[45][46], optical networks ^[47], wide area networks (WAN) ^[48], IoT, EC ^[49], and cloud computing ^[50].

The top layer in the SDN is called the application plane, consisting of business applications. Business applications provide management and optimization of business services. These applications implement the control logic based on the network state information received from controller NBIs to modify the network behavior. In the study, [57] the solutions of SDN for traffic engineering are discussed. In paper [58], a security-based survey study is conducted. Yan et al. [59] proposed analysis of distributed denial of service (DDoS) attacks in SDN networks in a cloud computing environment. A survey on fault management issues in SDN and its solutions is presented in [60]. SDN is deployed in real-time scenarios including transport network, wireless networks [61,62], optical networks [63], wide area networks (WAN) [64], IoT, EC [65], and cloud computing [66].

6. P4 (Programming Protocol-Independent Packet Processors)

P4 is a programming language to access the hardware without the knowledge of the architecture of hardware. P4 is used to modify the packet-forwarding mechanisms of the SDN switches ^[51]. Initially, P4 was used to write software programs and program hardware switches. Hardware resources including network interface cards, networking appliances, FPGA, and ASIC. P4 is used to set the custom headers and dynamic parsing of headers from the packet ^[52]. P4 provides the custom match and action tables and other constructs such as counters, registers, etc. This makes the P4 language entirely protocol-free. If a definite protocol is used in the network, it is easy to reconstruct the P4 program for new header field maintenance. Other P4 features include configurations, making new P4 applications reusable if needed rather than purchasing new networking devices. Furthermore, the P4 is free from any target device specifications and characteristics. Nonetheless, P4 is dependent upon the design of a device. The P4 application written for a distinct architecture is deployable beyond all destination devices with the same architectural design ^[53]. The P4 program is specially created for the data planes layer; however, the destination device may hold both the control and data planes. P4 is also used in literature for defining the interfaces between the control and data plane partially, but it cannot manage the control plane’s functionality.

P4 is a programming language to access the hardware without the knowledge of the architecture of hardware. P4 is used to modify the packet-forwarding mechanisms of the SDN switches [67]. Initially, P4 was used to write software programs and program hardware switches. Hardware resources including network interface cards, networking appliances, FPGA, and ASIC. P4 is used to set the custom headers and dynamic parsing of headers from the packet [68]. P4 provides the custom match and action tables and other constructs such as counters, registers, etc. This makes the P4 language entirely protocol-free. If a definite protocol is used in the network, it is easy to reconstruct the P4 program for new header field maintenance. Other P4 features include configurations, making new P4 applications reusable if needed rather than purchasing new networking devices. Furthermore, the P4 is free from any target device specifications and characteristics. Nonetheless, P4 is dependent upon the design of a device. The P4 application written for a distinct architecture is deployable beyond all destination devices with the same architectural design [69]. The P4 program is specially created for the data planes layer; however, the destination device may hold both the control and data planes. P4 is also used in literature for defining the interfaces between the control and data plane partially, but it cannot manage the control plane’s functionality.