Explore chapters and articles related to this topic
Software-Defined Networking
Published in Matthew N.O. Sadiku, Emerging Internet-Based Technologies, 2019
The idea of SDN came from Stanford University’s project, named OpenFlow in 2006 by Nick Mckeown, a professor of electrical and computer science. The term “software-defined networking” was first used by Open Networking Foundation (ONF), which is a nonprofit industry consortium founded in March 2011. It was formed to accelerate the development, standardization, and commercialization of SDN. The consortium consists of 69 members including IBM, Cisco, Juniper, HP, and Dell. The goal of ONF is to transform networking industry to software industry through SDN and promote standard development. ONF promotes the use of SDN and OpenFlow protocol. The OpenFlow is a standard interface between the control and data planes. OpenFlow 1.0 was released in December 2009. Major commercial switch vendors such as IBM, HP, and Cisco have launched switching products that support the OpenFlow protocol. Google has deployed SDN in its data centers across the globe.
Formal modeling and verification for SDN firewall application using pACSR
Published in Amir Hussain, Mirjana Ivanovic, Electronics, Communications and Networks IV, 2015
Miyoung Kang, Jin-Young Choi, Hee Hwan Kwak, Inhye Kang, Myung-Ki Shin, Jong-Hwa Yi
Our goal is to suggest one of the formal verification methods to assure safety and consistency of the SDN framework. SDN is a management technology that separates the network device control component from the data transfer component using openAPI, such as OpenFlow. Through the SDN controller that deals with the control component, forwarding and packet processing rules are decided and forwarding rules are transferred to the lower SDN switch. For example, various applications such as Security Policy, QoS Policy, and Firewall Policy in [Figure 1] can transfer the rules to the controller. Even if each independent application program does not cause any error, collisions can occur due to rule conflicts among SDN switches when various the application programs are executed in one controller. Since incorrectly written SDN applications can cause errors on the whole network, verification is necessary.
Cloud evolved packet core network architecture based on Software-Defined Networking (SDN)
Published in Lin Liu, Automotive, Mechanical and Electrical Engineering, 2017
Yaoyun Zhang, Zhan Xu, Zhigang Tian
SDN (Kobayashi, 2014) is a new network innovation architecture, it is an indispensable way to realise network virtualisation. It is the core of the separation of the data plane and control plane in a mobile core network. The control plane is detached from the hardware and centrally controlled through the network, making programming easier and thus optimising the network management. SDN (Zheng Yihua, 2013) can provide a standard interface to control network resource access and network traffic. OpenFlow interface protocol is one of them. OpenFlow (OF) protocol is the core technology of the SDN, which defines the control layer and the forwarding device of the communication protocol.
Load balancing for software-defined network: a review
Published in International Journal of Computers and Applications, 2022
Vivek Srivastava, Ravi Shankar Pandey
In [81], authors have proposed a mechanism for reducing the rate of the packet in the message at the controller side as ASIC which is a technique of loading the expensive functions onto hardwired engines for reducing the high packet rate at the controller side. OpenFlow protocol is used for implementing the Software-Defined Network concept and facilitates the greater control network flexibility using the open interface for packet forwarding at the centralized controller. They have argued that the hardwired approach for the forwarding packet in the message at the controller side is inadequate due to it reduces the amount of flexibility of OpenFlow. They have proposed the filtering mechanism for reducing the rate of the packet in messages. They have used the packet reducing the rate of header information which is recorded by the switches in advance. They have filtered out packets that have the same values as recorded previously. They have claimed that this approach reduces CUP loads at the switches side and only passes those packets in messages which are not already sending to the controller.
SDN in the home: A survey of home network solutions using Software Defined Networking
Published in Cogent Engineering, 2018
Abdalkrim M. Alshnta, Mohd Faizal Abdollah, Ahmed Al-Haiqi
OpenFlow is an early protocol specification that describes the communication between OpenFlow switches and an OpenFlow controller. Historically, the term SDN did not come into use until a year after OpenFlow made its appearance in 2008. The OpenFlow protocol defines the specific messages and message formats exchanged between controller (control plane) and device (data plane). The OpenFlow behaviour specifies how the device should react in various situations, and how it should respond to commands from the controller. The protocol defines two switch components:A flow table that resides on the switch and performs packet lookup. The fields in each packet are compared to the flow table looking for a match. If a match between the packet headers and any entry of the flow table was found, then an action would be taken by the switch, depending on the found match. If there is no match, then the traffic is sent to the controller.A secure channel by which the switch communicates with the external controller.
Performance analysis of SLTC-D2D handover mechanism in software-defined networks
Published in International Journal of Computers and Applications, 2019
Hima Bindu Valiveti, Trinatha Rao Polipalli
The EHSD architecture as shown in Figure 2 is decentralized network and a proxy server is appended which is capable of handling the mobility management and also has the ability to coordinate with the various radio access technologies. The proposed scheme mainly investigates on both D2D handover and D2D handover based on SDN principles. In an SDN, the control channel is segregated from the physical network but is placed analogous to the data plane. OpenFlow is used as the control protocol in SDN, which is one of the mostly used southbound interfaces that utilize the switches for routing purposes. Tunneling-based approach is also used alongside the switches as the switches alone do not support the existing Layer-2 and Layer-3 network equipment [15]. Using this hybrid approach, the switch-based networks can be deployed over the existing Internet Protocol (IP) network. SDN can be performed with control plane and forwarding plane elements, control plane elements consist of Mobility Management tools and run them on servers. Forwarding plane elements consists of Radio access nodes. By supporting this control and forward plane, effectively performed the Handover based on the Mobility Management Entity (MME) and also fine-grain traffic management using Evolved Packet Core (EPC). All the control plane and forwarding plane are interconnected with LAN switches. SDN controllers allow the switches or routers to forward the data packets. SDN consists of two entities such as controller and network entity. Open flow acts as an interface for communication between routers. One of the characteristics of SDN is ability to manage the mobility management functions. SDN signaling scheme is used to achieve the D2D communication-based principles. Figure 2 is the top level view of SDN indicating the Layer-2 and the Layer-3 activities. It is evident that the signaling information works independently from the data-plane activities. The logically centralized SDN Controller takes care of the signaling information and the network elements act as forwarding elements only. The MME present in the EPC is the controlling entity that procedures the signaling between the UE and the Network. The MME generates an UE ticket as soon as the UE is switched on and attaches it to the network. The MME also assigns a unique Temporary Mobile Subscriber Identity (TMSI) to the UE which identifies the UE ticket in the MME. This UE ticket is equipped with the information regarding user subscription which is downloaded from the home subscriber server. The local storing of subscribed information in the MME allows faster implementation of procedures like bearer establishment as it avoids the need to access the home subscriber server every time. Apart from that, the UE ticket also has information like list of bearers that are already established and also the terminal capabilities. This is how signaling is organized in LTE Networks which is applicable during D2D Communication [16].