Software Defined Networks

Faculty Article

Share

The explosion of mobile devices and content, server virtualization, and advent of cloud services are among the trends driving the networking industry to re-examine traditional network architectures. Many conventional networks are hierarchical, built with tiers of Ethernet switches arranged in a tree structure. This design made sense when client-server computing was dominant, but such a static architecture is ill-suited to the dynamic computing and storage needs of today’s enterprise data centers, campuses, and carrier environments. Some of the key computing trends driving the need for a new network paradigm include rise in cloud services, Big data handling, and changing traffic pattern for applications that commonly access geographically distributed databases and servers through public and private clouds require extremely flexible traffic management and access to bandwidth on demand. Further, users are increasingly employing mobile personal devices such as smartphones, tablets, and notebooks to access the corporate network. IT is under pressure to accommodate these personal devices in a fine-grained manner while protecting corporate data and intellectual property and meeting compliance mandates. In order to meet the networking requirements posed by evolving computing trends, network designers find themselves constrained by the limitations of current networks such as adding or moving devices and implementing network-wide policies that are complex, time-consuming, and primarily manual endeavors that risk service disruption, discouraging network changes, inability to scale, and vendor dependence. Hence, to meet the current trend of computation the Software-Defined Networking (SDN) comes as one of the solutions.

The key idea behind the SDN is to separate the forwarding data plane from the control plane while providing programmability on the control plane, as illustrated in Figure 1. SDN is an emerging architecture that is dynamic, manageable, cost-effective, and adaptable- making it ideal for high-bandwidth nature of today's applications that are dynamic. This architecture decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services. The OpenFlow protocol is a foundational element for building SDN solutions.

SDN architecture SDN architecture
The SDN architecture is:

Directly Programmable: Network control is directly programmable, as it is decoupled from forwarding functions.

Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.

Centrally Managed:Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.

Open standards-based and vendor-neutral: When implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.

Architectural Components

SDN Application

SDN Applications are programs that explicitly, directly, and programmatically communicate their network requirements and desired network behavior to the SDN Controller via a northbound interface (NBI). In addition they may consume an abstracted view of the network for their internal decision making purposes. An SDN Application consists of one SDN Application Logic and one or more NBI Drivers. SDN Applications may themselves expose another layer of abstracted network control, thus offering one or more higher-level NBIs through respective NBI agents. SDN Controller

The SDN Controller is a logically centralized entity in charge of translating the requirements from the SDN Application layer, down to the SDN Datapaths and providing the SDN Applications with an abstract view of the network (which may include statistics and events). An SDN Controller consists of one or more NBI Agents, the SDN Control Logic, and the Control to Data-Plane Interface (CDPI) driver. Definition as a logically centralized entity neither prescribes nor precludes implementation details such as the federation of multiple controllers, the hierarchical connection of controllers, communication interfaces between controllers, nor virtualization or slicing of network resources. SDN Datapath.

The SDN Datapath is a logical network device that exposes visibility and uncontested control over its advertised forwarding and data processing capabilities. The logical representation may encompass all or a subset of the physical substrate resources. An SDN Datapath comprises a CDPI agent and a set of one or more traffic forwarding engines and zero or more traffic processing functions. These engines and functions may include simple forwarding between the datapath's external interfaces or internal traffic processing or termination functions. One or more SDN Datapaths may be contained in a single (physical) network element—an integrated physical combination of communications resources, managed as a unit. An SDN Datapath may also be defined across multiple physical network elements. This logical definition neither prescribes nor precludes implementation details such as the logical to physical mapping, management of shared physical resources, virtualization or slicing of the SDN Datapath, interoperability with non-SDN networking, nor the data processing functionality, which can include OSI layer 4-7 functions.

SDN Control to Data-Plane Interface (CDPI)

The SDN CDPI is the interface defined between an SDN Controller and an SDN Datapath, which provides at least programmatic control of all forwarding operations, capabilities advertisement, statistics reporting, and event notification. One value of SDN lies in the expectation that the CDPI is implemented in an open, vendor-neutral and interoperable way.

SDN Northbound Interfaces (NBI)

SDN NBIs are interfaces between SDN Applications and SDN Controllers and typically provide abstract network views and enable direct expression of network behavior and requirements. This may occur at any level of abstraction (latitude) and across different sets of functionality (longitude). One value of SDN lies in the expectation that these interfaces are implemented in an open, vendor-neutral and interoperable way.

List of SDN Challenges given in below Figure.

SDN Challenges SDN Challenges

SDN deployment models

Proactive Vs Reactive: If flows arrive at a switch, a flow table lookup is performed. Depending on the flow table implementation this is done in a software or in hardware. In the case when no matching flow is found, a request to the controller for further instructions is sent. In reactive mode, the controller acts after these requests and creates and installs a rule in the flow table for the corresponding packet if necessary. In proactive mode, the controller populates flow table entries for all possible traffic matches possible for this switch in advance. This mode can be compared with typical routing table entries today, where all static entries are installed ahead in time. Following this, no request is sent to the controller since all incoming flows will find a matching entry. One major advantage in proactive mode is that all packets are forwarded in line rate (considering all flow table entries in TCAM), and no delay is added.

In addition, there exists a hybrid mode that follows the flexibility of a reactive mode for a set of traffic and the low-latency forwarding (proactive mode) for the rest of the traffic. SDN is becoming popular due to the interesting features it offers that unlock innovation in how we design and organize networks. However, there are still important challenges to be solved before realizing successful SDN.