revolution in existing network under the influence of software defined network · 2018-03-27 ·...

Proceedings of the 11th INDIACom; INDIACom-2017; IEEE Conference ID: 40353

2017 4th International Conference on “Computing for Sustainable Global Development”, 01st - 03rd March, 2017

Bharati Vidyapeeth's Institute of Computer Applications and Management (BVICAM), New Delhi (INDIA)

Revolution in Existing Network under the

Influence of Software Defined Network

Saleh Asadollahi

Department of Computer Science

Saurashtra University

Rajkot, India

Email ID: [email protected]

Bhargavi Goswami

Department of Computer Science

Garden City College, Bangalore University

Bangalore, India

Email ID: [email protected]

Abstract— In the world of digitization, more than one unit per

person is connected to the network and internet is growing with

the speed of light. To meet up the demands, traditional

architecture is finding itself short on joining the ends. On account

of adaptability, we are compromising with complexity and

flexibility. In the era of globalization, human is covering large

distance in short time. Network demands dynamism in the

behavior which is difficult to meet by traditionally implemented

configurations and policies. In addition to this, vertically

integrated design of traditional networking devices is acting up

on conventional network, resisting it to changes, load balancing

and response to errors. The only ray of light visible at this point

of time is Software Defined Networks, which can bring solution

to the restrictions of traditional architectural shortcomings.

Modulating the problems into smaller pieces, software defined

networks will centralize the control of network making the

network evolve with flexibility. In this paper we presented a

comprehensive review upon Software Defined Networks where

we started with introduction followed by details about traditional

network architecture. Further we included detailed working of

SDN giving brief differences with traditional networks. In this

paper, clear analysis is provided for its layered approach,

southbound and northbound APIs. We have stated clear

limitations of SDN in this paper.

Keywords — Software Defined Network; OpenFlow; Open

Network Foundation; Northbound Interface; Southbound

Interface

I. INTRODUCTION

Internet plays an important role in our life and connects almost everything with each other. It is explicit that extent of internet is increasing, big data centers which are corollary of traveling user’s data through internet network are growing and explosion of cloud now days have made very complex conventional networks [1]. Obstacle in design, implement high level policy, keep security high, enhance the performance are more painful with today’s network architecture. Software Defined Networking (SDN) [2] approach engaged by big company such as Google, Microsoft, Yahoo, Facebook and so on; introduced new architecture that decoupled control plane from data plan and dramatically diminished the intricacy in network

configuration and made management easy. The aim of SDN is to provide “programmable networks” [3] that enable development of software to control the phenomenon of network instead of configuration of predefined devices. Paper is organized in the following manner: In Section II, architecture of traditional network devices is explained with its limitations. As a solution, SDN approached proposal details are provided in Section III. Section IV explains details of SDN Implementation. Section V provides limitations of SDN followed by Conclusion and References.

II. TRADITIONAL NETWORK DEVICE ARCHITECTURE

Computer networks are a combination of lots of networking devices like switches, routers, firewalls and so on which, are implemented with many complex protocols. Current network device’s architecture is vertically integrated where, switch plays an important role. Functions of switches are segregated into three discrete categories (Control plane, Data plane and Management plane) which are bundled inside of devices vertically. A aspect of the explained architecture is exhibited in figure 1.

Fig. 1. Traditional network device architecture

Copy Right © INDIACom-2017; ISSN 0973-7529; ISBN 978-93-80544-24-3 1012



In traditional networking node, Data plan (hardware)

comprise of 1) Diverse set of ports that are responsible for receipt and forwarding the packets and 2) Forwarding table which are built by control plane that handles the vast majority of packets. Depending to the incoming data packet header information, data plane look up into forwarding table and make decision on where to send packet that are entering the networking device. In case, there is no information available into the table or they may carry control protocol information, are sent to the control plan. In the brain of the network switches, processing of different control protocol is going on depending on configuration and its type. Control plan keeps current information in forwarding table, where data plan can handle data traffic without intervention of control plan. The third plane is management plane, as shown in figure 2, is used by administrator to use some form of network management system to communicate to management plan of the switch, generally used to configure and monitor the device. It is notable that each category is able to communicate horizontally with peer elements residing adjacent to each other in a same segment [4].

Fig. 2. Interconnection of plan internally and externally

As illustrated in figure 3, these planes exist and execute in tightly coupled architecture, which makes it complex and bring some difficulty at certain point.

Fig. 3. Router components in traditional device

Administrator needs to configure each individual networking device separately, to implement high level policy by using lower layer controls and often vendor-specific configuration commands are used, to respond to a wide range

of the networking events. Moreover, at any moment a utility is supplemented, the equipment have to be individually configured one by one by experienced engineers.

Hardware and software are vertically integrated and it is not possible for new software or protocol to be able to leverage in accordance with currently implemented hardware capabilities. This may happen because of incompatible hardware or the lack of programmability of current network devices that all together hampers innovation. As a result, new proposal cannot execute through current devices.

Additionally, current network architecture does not provide a global view that allows routers to choose a path for a flow of data according to its own individual perspective. Figure 4 illustrate current network composition. Bundled control plane along with data plane inside of network devices reduces flexibility and persistence of mobility. Nowadays, all services are implemented virtually and its movement is easy, without any attachment to hardware or specific software in huge data centers.

Fig. 4. Traditional network

Mentioned problems made challenge researchers to dig into this scenario and approached to propose new concept called Software Defined Networking to change the

infrastructure of current devices.


Revolution in Existing Network under the Influence of Software Defined Network

Fig. 5. Router component in SDN

III. SOFTWARE DEFINED NETWORKING AS AN APPROACHED

PROPOSAL

Software Defined Networking is an approached networking pattern that duplicate control plane from underling router and switches to centralized one as shown in figure 6. Migration of the brain (control plane) of the switches into accessible and logically centralized controller provides an abstraction between the underlying infrastructure and applications point view, reduces the complexity as described in figure 2 in comparison of figure 5 [5].

As a result, convoluted control plane intelligence is then held on a centralized controller that understands the complete topology of the network. It is notable that logically centralized programmatic model does not presuppose to be only logical but may also be a physical centralized system.

The basic desire of reducing these convolutions of devices is to make network nodes to be just a simple packet forwarding devices (having only data plane). Now control plan uses all its logic, decides what is to be done, send commands to the data plan and as a whole, intuit the data plane to conduce proper decision. This solution promises better decision making by control plan by seeing the status of all routers and switches (global view) before deciding the best path.

Fig. 6. SDN network

The fact remains, implementation of the policies for data handling as software modules rather than fixing them in hardware makes hardware (data plan) and software (control plan) grow independently. Therefore, allowing innovations in software by network researchers and network professionals’ by easy implementation on control plan.

By breaking the tradition, network administrators obtained extra control over the network traffic and its management. Therefore, administrators can use network resources optimally and efficiently, hence improve the performance of the network. This approached introduces inexpensive infrastructure which promise more flexibility in choosing the hardware and software for its clients.

Hence, SDN by separating the data plan and control plan accomplish more flexible, cost effective, simplifying policy

and configuration, in addition to programmable and innovative network architecture.

IV. SDN IMPLEMENTATION

SDN by aggregating open source, software-based technology with networking hardware, defines how a networking and computing system can be built that clearly disassociate the networking stack’s control layer and the data layer.

As it is shown in figure 7, SDN architecture consist of tree layer, application plan (application layer), control plan (control layer) and data plane (data layer). We describe the element of SDN in the rest of this section in brief.

Fig. 7. Software Defined Networking high-level architecture

A. Applications layer:

As illustrated in figure 7, the application layer inhabit on top of the control layer. Application layer has programs that dwell an array of network operation tools that communicate expected behaviors and needed resources with the SDN Controller via application programming interface (APIs). Additionally, by collecting information from controller, application layer will develop and abstracted view of the network such that it enables decision making and supports actual management. Generally large data centers uses applications of this type such as analytics, business decision making, network management. For example, to recognize suspicious networking activities, an analytics application may be built for security enhancement.

B. Control layer:

The key component that separates the SDN from classical networking technologies is the intermediate part of the SDN called Control Layer. They are also famous as Controllers. Its




main job is to relay the obtained directions and demands of Application Layer of SDN to the concerned networking components. In the similar fashion, controllers communicate back to SDN applications all the extracted information about hardware equipments providing applications the abstract view of networks, statistics and events happening around. Better data flow in addition to assisting dynamic forwarding decision is provided by a centralized control point of Control Layer providing fine control and broader view to entire network. Controllers also simplifies alterations to forwarding algorithms by providing centralized control over complete network from single spot.

In this part, authors tried number of SDN controllers and experimented with them. We have described each one of them in brief.

NOX [6] became open source controller in 2008, developed by Nicira and organized by Stanford university. It is a multithreaded, C++/python controller platform.

POX [7] open source, single threaded, python based controller. It is renewed to improve the performance of original Python NOX.

OpenDaylight [8] open source, java based controller, created by Linux foundation, it is Modular, pluggable, and flexible controller platform. It uses web based GUI.

ONOS [9] is open source, java based, multi-threaded, it is created by Linux Foundation too. It is known for High-availability, scalability and performance, Strong abstractions and simplicity. Again, uses same, web based GUI.

Floodlight [10] open source and java based controller, it is multi-threaded, organized by Big Switch Network, it is used for enterprise networks and Apache licensed. Provides Web GUI.

Rya [11] Python based controller, it created by NIT Labs, it is Component based, supporting components development in other languages and Most Supported On Linux Platform.

Beacon [12] java based, organized by Stanford university, open source, single- threaded, support both event-based and threaded operation, provide Web GUI.

C. SDN Networking Devices:

A group of data plane resources that are managed as a single entity are also known as network elements. SDN switches have one or more data table and flow rule instruction are utilized to perform activities upon the approaching packets such as to drop packet, forward to specific ports, forward to the controller and many such operations. In this architecture end device could be a router, switch or even firewall depending on network topology configured [14].

D. Southbound APIs:

SDN controller uses southbound APIs to deal with forwarding layer, relay information and dynamically make change in infrastructure devices such as the switches and

routers. Very first standard of SDN is known as OpenFlow [13]. It is the most commonly used protocol of the original southbound API. It was defined as the communication protocol in SDN scenario that enables the SDN controller (brain) to interact with forwarding devices such as switch and router. Despite the wrong notion prevailing in some of the researchers that OpenFlow and SDN are identical, OpenFlow has a wider scope than SDN. Origin of OpenFlow is at Stanford University, OpenFlow is choice of numerous venders for implementation of SDN strategies. However, OpenFlow cannot be equated with SDN and is not the only way to implement SDN. Other options prevail in market such as NETCONF (standardized by IETF) [15], Opflex[17] which is implemented by Cisco and OF-Config [16] provided by ONF - Open Network Foundation, etc are some of the examples of Southbound APIs managing equipments of networks. The aim is to develop a "common language" of communication between programmable switches. This is served by OpenFlow that becomes a mediator between controllers and switches. OpenFlow educate controllers regarding existing traffic flows and communicate with switch teaching it how to perform flow forwarding.

E. Northbound APIs:

To communicate business logic, policies enforced over top layers at application layer to the controllers, Northbound APIs are used by Software Defined Networks. Answer to the question how does it help the administrators of network is by aiding service deployment by programming the shape to network traffic. The influential protocol widely implemented as interface of northbound operations by majority of controllers is know as REST-Representational State Transfer [18] that supports a huge number of applications, currently.

V. SDN LIMITATINIONS

A. Scalability and Reliability:

Data plane switches are connected and depends to a single controller which decides and installs the rules on switches. This controller may logically or physically be centralized or distributed so that it can interface with data plan. By increasing the number of end nodes, as well as traffic passing between these planes, scalability and reliability have became the biggest concern, where the circumstances of network bottleneck may arise for the controllers and may fails at last. Split or fully distributed control planes are kind of solutions introduced to manipulate themselves by problem such as concurrence and immeasurable control objects during configuration and management [19].

B. Security:

SDN security requirements may differ from Traditional networks based on its characteristics [20]. Physical implementation directly impress the safety of this approach, where as centralized controller may idolize by single passage attacker, wherever it can be wished by large number of passage in distributed control domain. Another threat arises


Revolution in Existing Network under the Influence of Software Defined Network

because of existential characteristic of SDN that provide programmatic access to client controller plane or applications entities where administrators may introduce unintentionally the vulnerability of coding loopholes which may affect the centralized control widely affecting the distributed controllers completely of partially.

C. Interoperability:

The good news about the interpretability is, all the newly manufactured devices are SDN ready, so, for newly developed network infrastructure, implementation of SDN is candid. Another approach exist for the legacy networks willing to transit to SDN for the support of business and networking dual support demanded by them. Companies and industries including majority of the networking ambience intended to shift to SDN has needs a period of transition and have to start with interoperable devices with hybrid networking infrastructure.

To provide solution of interoperability between classical and SDN supported networking equipments to operate together, vendors may bring assembling as solution providing backward compatibility with MPLS, VPN and existing IP supported control planes to reduce risk of sudden change in technology resulting to sudden breakdown and service cease in addition to huge investment [21,22].

D. Performance:

The colossal concert for existing networks is the Performance. In presence of all the assured services of interoperability, security, scalability and what not, the biggest concern of the corporate is the performance which is adversely affecting the service and goodwill as a whole.

The reason for latency observed in SDN is the architectural physics of separation of control plan with data plan [21]. It was observed that in tiny networks, latency is considerably high then how will it affect the elephant size networks? It may come up to unacceptable level of delay for the current service providers. Situation may go worst in presence of high response time by controllers and lack of throughput influencing network adversely with poor performance and issues with scalability.

The solution to address the performance issues in continuously growing network is to enhance more intelligence to data and control planes [22]. Another approach is moving towards distributed control plan which may reduce the risk of degraded performance but, it is against the centralized concept of SDN. As of now, moving away from the goal of SDN of providing centralized control is something like moving towards the concept of classical scenario of distribution. Virtualization if implemented may avoid performance degradation neglecting risk of potential failures.

VI. CONCLUSION

At the end, we would like the readers of this paper to consider software defined network as a solution to long

standing problems of conventional networks. Key aspects of decoupling, dynamic programming and controlling the network logically through the centralized brain creates large opportunity for researchers to explore more about it. This paper is written to throw light upon how the next generation of researchers will change their notion towards network as a field of programming rather than the world of configurations.

VII. FUTURE SCOPE

Limitations stated in the paper with the base of explained implementation open a lot of doors to bring solution to stagnant growth of data communication in the area of SDN. Researchers can work upon the parameters of Scalability, performance, interoperability and security to improvise the performance of SDN, an emerging technology in the area of networks that will change the face of communication in near future. Implementation of SDN over MININET Simulation is under progress by the researchers.

REFERENCES

[1] T. Benson, A. Akella, and D. Maltz, “Unraveling the complexity of network management,” in Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation, ser. NSDI’09, Berkeley, CA, USA, 2009, pp. 335–348.

[2] N. Mckeown, “How SDN will Shape Networking,” October 2011.[Online]. Available: https://www.youtube.com/watch?v=c9-K5O_qYgA

[3] A. T. Campbell et al., “A survey of programmable networks,” ACM SIGCOMM Comput. Commun. Rev., vol. 29, no. 2, pp. 7–23, Apr. 1999

[4] Y. Jin, Y. Wen, G. Shi, G. Wang, and A. Vasilakos, “CoDaaS: An experimental cloud-centric content delivery platform for usergenerated contents,” in Proc. Int. Conf. Comput. Netw. Commun., 2012, pp. 934–938.

[5] M.K. Shin, K.H. Nam, H. J. Kim, "Software-Defined Networking (SDN): A Reference Architecture and Open APIs," In Proceedings of International Conference on ICT Convergence (ICTC), pp.360–361, Oct. 2012.

[6] NOX detailed implementation, available online: http://www.noxrepo.org

[7] POX detailed implementation, available online: http://www.noxrepo.org

[8] Opendaylight, available online: http://www.opendaylight.org

[9] Ola Salman, Imad H. Elhajj, Ayman Kayssi, Ali Chehab ”SDN Controllers: A Comparative Study”. Mediterranean Electrotechnical Conference MELECON 2016, Limassol, Cyprus, 2016.

[10] Floodlight detailed implementation, available online: http://floodlight.openflowhub.org

[11] Rya detailed implementation, available online: http://ryu.readthedocs.io/en/latest/getting_started.html#what-s-ryu

[12] D. Erickson, The beacon openflow controller, in: Proceedings of ACM on Hot Topics in Software Defined Networking(HotSDN) Hong Kong, China, 2013.

[13] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation in campus networks,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, pp. 69–74, Mar. 2008

[14] K. Greene, “MIT Tech Review 10 Breakthrough Technologies: Software-defined Networking,” http://www2.technologyreview.com/article/412194/tr10-sof tware-defined-networking/, 2009.

[15] 2008R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman, “Network Configuration Protocol (NETCONF),” RFC 6241 (Proposed Standard), Internet Engineering Task Force, Jun. 2011.


http://www.noxrepo.org/

http://www.noxrepo.org/



[16] ONF, “OpenFlow management and configuration protocol (OF-Config

1.1.1),” March 2014. [Online]. Available: https://www.opennetworking.org/images/stories/downloads /sdnresources/onf-specifications/openflow-config/of-config-1-1-1.pdf

[17] M. Smith, M. Dvorkin, Y. Laribi, V. Pandey, P. Garg, and N. Weidenbacher, “OpFlex Control Protocol,” Internet Draft, Internet Engineering Task Force, April 2014

[18] L. Richardson and S. Ruby, RESTful web services. O’Reilly Media, Inc.

[19] ONF, “Services: Security”, https://www.opennetworking.org/technical-communities/ar eas/services/1918-security

[20] S.Sezer et al. “Are We Ready for SDN? Implementation Challenges for Software Defined Netwoks”, IEEE Commnications Magazine, July 2013, pp 36-43

[21] K. Gao, C. Gu, Q. Xiang, Y. Yang, J. Bi, Q. Xiang, "FAST: A Simple Programming Abstraction for Complex State-Dependent SDN Programming", Sigcomm-2016. ISBN 978-1-4503-4193-6/16/0 DOI: http://dx.doi.org/10.1145/2934872.2960424

[22] J. Yang, C. Hu, P. Zheng, R. Wang, P. Zhang, X. Guan, "Rethinking the Design of OpenFlow Switch Counters", SIGCOMM ’16, August 22–26, 2016, Florianopolis, Brazil 2016 ACM. ISBN 978-1-4503-4193-6/16/08, DOI: http://dx.doi.org/10.1145/2934872.2959062


revolution in existing network under the influence of software defined network · 2018-03-27 ·...

Documents