Fault Tracking Framework for Software-Defined Networking (SDN)

Fault Tracking Framework for Software-Defined Networking (SDN)

Amitava Mukherjee (IBM India Private Limited, India), Rashid A. Saeed (Ministry of Higher Education and Scientific Research, Sudan), Sudip Dutta (IBM India Private Limited, India) and Mrinal K. Naskar (Jadavpur University, India)
DOI: 10.4018/978-1-5225-2023-8.ch011
OnDemand PDF Download:
List Price: $37.50


The emergence of software-defined networking (SDN) raises a set of fundamental questions, including architectural issues like whether control should be centralized or distributed, and whether control and data planes should be separated. Several open problems exist in SDN space, ranging from architectural questions that are fundamental to how networks scale and evolve to implementation issues such as how we build distributed “logically centralized” control planes. Moreover, since SDN is still in its early stage, there is an opportunity to make fault tracking framework a more integral part of the overall design process. Although SDN's goal is to simplify the management of networks, the challenge is that the SDN software stack itself is a complex distributed system, operating in asynchronous, heterogeneous, and failure-prone environments. In this chapter we will focus on three key areas: 1) SDN architecture, 2) scalable SDN systems to understand which pieces of control plane can be run logically centralized fashions, and 3) fault tracking framework to track down the failures in SDN.
Chapter Preview


The emergence of software-defined networking (SDN) brings out opportunities to both industry and academia to improve the functionalities in networking and cut down the cost of networking operation too. With this, SDN raises a set of fundamental questions, including architectural issues like whether control should be centralized or distributed, and whether control and data planes should be separated. “SDN starts from two simple ideas: generalize network hardware so it provides a standard collection of packet processing functions instead of a fixed set of narrow features, and decouple the software that controls the network from the devices that implement it. This design makes it possible to evolve the network without having to change the underlying hardware and enables expressing network algorithms in terms of appropriate abstractions for particular applications” (Casado, M.,2014). The SDN concepts are new and still under research, and standard development stage in academic while industries are working to develop product under trial, but not in position to commercialize them. From one perspective, it is visible from different initiatives how SDN is able to foster innovation in networks at a level that has not been seen in the last decade. On the other hand, industries are usually too concerned with time to market rather than providing conceptually elegant solutions (Wickboldt, J. A., 2015). Particularly, the majority of efforts are focused on providing solutions and services over SDN networks, whereas network management specifically fault management is not given much attention. However, as widely recognized, management must not be an afterthought (Schonwalder, J., et al., 2009).

The OpenFlow (ONF) was first introduced in March 2008, from the network research group of Stanford University and collaborators. The first time the concept of “network operating system (NOX)” appeared in this context was through the proposal of the NOX controller (Cisco, 2013). NOX provided a concept how to enable the development of software to control OpenFlow-based networks. The ONF is also responsible for the maintenance of OpenFlow standards, technical specifications of the OpenFlow Switch, and the conformance testing of SDN enabled devices. The architecture of SDN consists of three layers: the application layer, the control layer, and the infrastructure layer. The function of the two lower layers are called OpenFlow controller and OpenFlow Switch, corresponding to the control and data planes of traditional IP/MPLS network switches and routers. With the OpenFlow standard, the OpenFlow controller instructs the OpenFlow Switch to define the standard functional messages such as packet-received, send-packet-out, modify-forwarding-table, get-stats, etc. (Sun, S., 2015).

In addition to the ONF, the Internet Engineering Task Force (IETF), the International Telecommunications Union Telecommunication Standardization Sector (ITU-T), the European Telecommunications Standards Institute (ETSI), and the China Communications Standards Association (CCSA) have also started standardization work on SDN. IETF issued an RFC concerning the requirements and application issues relating to SDN from an operator’s perspective (IETF, 2014), while ITU-T has not published a formal recommendation since the project began in 2012. Table 1 summarizes the formally published SDN standards (Sun, S., 2015).

Table 1.
Current main standards for SDN
Standardization OrganizationMain Related Standards and ActivitiesFunctionality
ONFSoftware-Defined Networking: The New Norm for Networks (white paper) Interoperability Event Technical Paper v0.4/v1.0Definition and interoperability
ITUITU-T Resolution 77Standardization for SDN
IETFIETF RFC 7149Perspective
ETSINFV ISGUes cases and framework and requirements
CCSATC6 WG1Application scenarios and framework protocol

Sun, S., 2015.

Complete Chapter List

Search this Book: