Introduction to SDN

Introduction to SDN

The main idea behind SDN is to separate control and data plane and to make networks agile and flexible.

SDN is a trend that is gaining importance with established vendors such as Brocade, Cisco, HP, and VMware.

We can briefly see in the later sections about the different vendors.

Let's see the timelines of SDN.

• 1990 - 2000 -- Programmable functions in the network is introduced by Active networks to enable greater innovation.
• 2001 - 2007 -- Separation of control and data plane, which developed open interfaces between the control and data planes.
• 2007 - 2010 -- The OpenFlow API and network operating systems, developed ways to make control-data plane separation scalable and practical.

Network virtualization played an important role throughout the evolution of SDN

SDN Architecture

As we discussed earlier, the main purpose of SDN is to separate the data and control plane.

SDN architecture is built using a combination of software and hardware that separates the SDN control plane and the SDN data plane of the network.

• Infrastructure Layer: It consists of network devices. This layer will be the physical layer.
• Control Layer: Network Intelligence resides in the control layer. Control plane has the control logic for managing the network. In SDN,Controller is the brain of the network. It is the separate hardware that is hidden by Hardware abstraction layer(HAL). Flow entries of multiple devices will be manipulated by the controller.

SDN Operation

• In SDN, we have a central controller for the control plane. you can see the SDN controller, which is responsible for the control plane.
• In SDN, switches have a data plane and no control plane. The SDN controller feeds the switches' data plane with information from its control plane.

Advantages of Centralized Controller

A single device does the configuration of the entire network. This controller has the full access and observation of everything that is happening in our network.

Interfaces Used in SDN

The SDN controller uses two special interfaces:

• Northbound interface (NBI)
• Southbound interface (SBI)

Southbound Interface

To program the data plane, the SDN controller has to communicate with our network devices. This action is done through the southbound interface, which is a software interface, often an Application Programming Interface (API).

API

API: A software interface that allows an application to give access to other applications by using pre-defined functions and data structures.

Some popular southbound interfaces are:

• OpenFlow: It is the most popular SBI at the moment, and an open source protocol from the Open Networking Foundation. There are few network devices and SDN controllers that support OpenFlow.

Northbound Interface

• The northbound interface is utilized to access the SDN controller. It allows the administrator to access the SDN to configure it or to retrieve information from it.
• This could be done through a GUI. It also offers an API that allows other applications access to the SDN controller.

Multiple applications can access the SDN controller via API.

• A user will start using the GUI to obtain data about the network from the SDN controller. The GUI uses the API at the backend.
• To configure the network or to get information from the SDN controller, API can use scripts that are written in Java or Python.

REST API

• SDN controllers uses a REST API (Representational State Transfer)
• It uses HTTP messages to send and receive information between the SDN controller and application.
  • HTTP GET: Utilized when you wish to retrieve information.
  • HTTP POST/PUT: Utilized when you wish to upload or update data.
• When the SDN controller receives the "HTTP GET" request, it will reply with a "HTTP GET response" message with the information that was requested.

The information is delivered in a common data format. The two most used data formats are:

• JavaScript Object Notation (JSON )
• eXtensible Markup Language (XML)
• Cisco OpFlex: You can call it as the Cisco’s answer to OpenFlow. Cisco submitted the protocol to the Internet Engineering Task Force (IETF) standardization process in April 2014.

 

 

 

 

---