Defining Software Defined Networking – InApps Technology 2022

Thomas S. Kuhn, in his highly-influential work ‘The Structure of Scientific Revolutions’, defines the term paradigm as “universally recognized scientific achievements that, for a time, provide model problems and solutions for a community of researchers. Going by this, categorizing Software Defined Networking (SDN) as a “new networking paradigm’ may not be an overstatement. Referring again to Kuhn’s words, SDN is also sufficiently open-ended to leave all sorts of problems for the redefined group of practitioners to resolve”.

SDN has been defined by different researchers in different terms, and the one which is more general and inclusive one is provided by Brandon Heller [1] is as follows:

“SDN is about refactoring of the relationship between network devices and the software that controls them.”

The term network device is used to include: gateways, routers, network bridges, switches, hubs, protocol converters, proxy servers, firewalls, network address translators, multiplexers, network interface controllers, modems, terminal adapters, line drivers, wireless access points, etc.

 Every single network device typically has to perform three distinct activities, which are mapped correspondingly to three different planes of the network: data, control and management, as depicted in Figure 1.

The data plane is responsible for processing the transit traffic, which decides what to do with packets arriving on an ingress interface. It is also termed as forwarding plane, as it mainly refers to a forwarding table to decide proper egress interface. From the perspective of packets the data plane usually handle end-station/user-generated packets that are always forwarded by network devices to other end-station devices.

The control plane is concerned with collecting, processing and managing the network information in order to decide the forwarding behavior. It typically includes various tables and suite of protocols that work on these tables. Hence, control plane handles network device generated/received packets that are used for the creation and operation of the network itself. Typical protocols that run at control plane are routing, interface state management, connectivity management, adjacent device discovery, topology or reachability information exchange and service provisioning.

The management plane is used to interact, or monitor, with the device, in order to manage the network. The management plane also runs its own suite of protocols (such as SNMP), apart from supporting configurations of interfaces, network (IP subnets) and control-plane protocols. In a traditional network device, the data-plane activities are carried out by dedicated hardware (or ‘high-speed code’), while the control plane operations are handled by the device CPU.

 Figure 1 Planes of Network Elements

 Considering the above description of planes, SDN eliminates the complex and static nature of legacy distributed network architectures by using the ‘’standards-based software abstraction’’ between the network control plane and underlying data forwarding plane.

As nicely described by Scott Shenker:SDN is about achieving Forwarding, State Distribution and Specification abstractions at network control planes” [2]. From the realization perspective, an SDN is any network that gives us the flexibility to choose between points on the implementation design axes:  centralized to distributed, micro-flow to aggregated-flow, reactive to proactive, virtual to physical, and fully-consistent to eventually-consistent [1]. That is, SDN adds flexibility to control-plane implementation choices. As a result, the network devices perform solely packet forwarding (the data plane), and these devices are programmed via an open and standard interface (e.g., OpenFlow [3]).

 In summary, SDN is about clear separation of the data and control planes of the network devices, and about having sufficient abstraction at the control plane to support the provision of novel services in the network.

SDN Architecture

Figure 2 depicts the SDN architecture. As shown in the figure, there are three different tiers:

• Application Tier: Encompasses solutions that focus on the expansion of network services. These solutions are mainly software applications that communicate with the controller.
• Control Plane Tier:  Includes a logically-centralized SDN controller, which maintains a global view of the network. It also takes requests through clearly defined APIs from application layer and performs consolidated management and monitoring of network devices via standard protocols.
• Infrastructure or Data-plane Tier: Involves the physical network equipment, including Ethernet switches and routers. Provides programmable and high speed hardware and software, which is compliant with industry standards.

Figure 2 SDN Architecture

At the bottom layer, the physical network consists of the hardware forwarding devices which store the forwarding information base (FIB) state of the network data plane (e.g., TCAM Entries and configured port speeds), as well as associated meta-data including packet, flow, and port counters. The devices of the physical network may be grouped into one or more separate controller domains, where each domain has at least one physical controller. OpenFlow plane interface or standards-based protocols, typically termed as `southbound protocols’,  define the control communications between the controller platform and data plane devices such as physical and virtual switches and routers. There are various southbound protocols such as OpenFlow, PCEP, SNMP, OVSDB, etc.

The control-plane tier is the core of the SDN, and is realized by the controllers of each domain, which collect the physical network state distributed across every control domain. This component is sometimes called the “Network Operating System” (NOS), as it enables the SDN to present an abstraction of the physical network state to an instance of the control application (running in Application Layer), in the form of a global network view.

Northbound open APIs refer to the software interfaces between the software modules of the controller and the SDN applications. These interfaces are published and open to customers, partners, and the open source community for development. The application and orchestration tools may utilize these APIs to interact with the SDN Controller.

Application layer covers an array of applications to meet different customer demands such as network automation, flexibility and programmability, etc. Some of the domains of SDN applications include traffic engineering, network virtualization, network monitoring and analysis, network service discovery, access control, etc. The control logic for each application instance may be run as a separate process directly on the controller hardware within each domain.

SDN Controllers

In a typical SDN, the network intelligence is logically centralized in controllers (software-based), which enables the control logic to be designed and operated on a global network view, as a centralized application, rather than a distributed system [1]. A program running on a logically-centralized controller manages the network directly by configuring the packet-handling mechanisms in the underlying network devices. The packet processing rules are installed on network devices to realize various tasks of managing a network, ranging from routing and traffic monitoring to access control and server load balancing.

The separation of control and data plane, a decoupled system, has been compared to an operating system, in which the controller provides a programmatic interface to the network that can be used to implement management tasks and offer new functionalities [4]. Considering architecture in Figure 2, we can see that the SDN controller acts as a key element, both in terms of southbound and northbound interactions. There are various open-source and commercial controllers in the market.  However, our focus in the current and future articles would be open-source controllers.  Some of the open-source controllers are NOX [5], Maestro [6], Beacon [7], SNAC [8], Helios [9] and Trema [10], Jaxon [11], Floodlight [12], POX [13],  Ryu [14], MUL [15] and OpenDayLight [16]. In our succeeding articles, we’ll make an attempt to understand Trema, Nox, Floodlight, RYU and ODL in detail.

References

1. D. Levin, A. Wundsam, B. Heller, N. Handigol, and A. Feldmann. Logically centralized?: state distribution trade os in software defined networks. In Proceedings of the first workshop on Hot topics in software defined networks, HotSDN ’12, pages 1-6, New York, NY, USA, 2012. ACM.
2. B. Raghavan, M. Casado, T. Koponen, S. Ratnasamy, A. Ghodsi, and S. Shenker. Software defined Internet architecture: decoupling architecture from infrastructure. In Proceedings of the 11th ACM Workshop on Hot Topics in Networks, HotNets XI, pages 43-48, New York, NY, USA, 2012. ACM.
3. N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2):69-74, 2008.
4. B. Nunes, Marc Mendonca, Xuan-Nam Nguyen, K. Obraczka, Thierry Turletti,”A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks”, IEEE Communications Surveys and Tutorials.
5. N. Gude, T. Koponen, J. Pettit, B. Pfa, M. Casado, N. McKeown,and S. Shenker. Nox: towards an operating system for networks. ACM SIGCOMM Computer Communication Review, 38(3):105-110, 2008.
6. Z. Cai, A. Cox, and T. Ng. Maestro: A system for scalable openflow control. Technical Report TR10 08, Rice University, December 2010.
7. Beacon. https://openflow.stanford.edu/display/Beacon/Home.
8. Simple Network Access Control (SNAC). http://www.openflow.org/wp/snac/.
9. Floodlight, an open SDN controller. http://floodlight.openflowhub.org/.
10. Helios by nec. http://www.nec.com/.
11. Trema openflow controller framework. https://github.com/trema/trema.
12. Jaxon:java based openflow controller. http://jaxon.onuos.org/.
13. Pox. http://www.noxrepo.org/pox/about_pox/
14. Ryu. http://osrg.github.com/ryu/.
15. Mul. http://sourceforge.net/p/mul/wiki/Home/.
16. OpenDaylight : ”Open Daylight Website”. http://www.opendaylight.org Retrieved 2014-04-14

Sridhar received his Ph.D degree in computer science from National University of Singapore, in 2007, his M.Tech. degree in computer science from KREC, Suratkal, India, in 2000, and his B.E. degree in instrumentation and electronics from SIT, Tumkur, Bangalore University, India, in August 1997. He worked as Research lead at SRM Research Institute, India, Post-doctoral fellow at Microsoft Innovation Center, Politecnico Di Torino, Turin, Italy, and as a research fellow at Institute for Infocomm Research (I2R) Singapore. He has worked on various development and deployment projects involving ZigBee, WiFi and WiMax. Sridhar is currently working as Group Technical Specialist with NEC Technologies India Limited. Sridhar’s research interests are mainly in the domain of next-generation wired and wireless networking, such as OpenFlow, software defined networking, software defined radio based systems for cognitive networks, Hotspot 2.0 and the Internet of Things.

Feature image via Flickr Creative Commons.