Software-Defined Networking in Mobile—The Basics

-January 29, 2014

Software-defined networking (SDN) is not a new concept. It’s been around arguably since the notion of decoupling hardware from software. This basic concept is now becoming more specific and leading to a more detailed understanding, the concept of separating the network’s control functions from a user’s data-forwarding functions.

The original concept was born in the early 2000’s, at the International Telecommunications Society (ITS). Since then, Stanford University and the Open Networking Foundation (ONF) have been promoting this idea of SDN with a cleaner separation of the control and the data planes, and apply it to multiple types of networks.

Why do we need SDN? What value does it provide? If SDN solves a problem with today’s networks, how would you define that problem? What’s wrong with the architecture our networks have built on for the past two decades?

Our current Internet architecture has distributed network intelligence. Each device is independent and autonomous and Internet principles are mainly applied to establish peer-to-peer or client-server sessions. The network itself is basically a distributed entity that connects diverse devices, such as IP routers and computer terminals. This obviously requires a very detailed interaction between devices to ensure its correct operation.

These detailed interactions make networks hard to manage and difficult to evolve. SDN, a response to these challenges, decouples the control of the devices and the data-forwarding functions they perform. By achieving that, most of the network devices only take care of the data-forwarding plane--their only job becomes sending packets, which is simple and straight forward. The actual decision and policy routing happens in a control plane that is decoupled and, for that reason, it can be centralized in a single network controller making it easy to make changes to the whole network configuration, upgrade it, implement new services, define new network architectures, etc., without touching the hardware and actual network deployment. 

 

The SDN model relies on a three-layer approach. At the top, we have the application layered over the middle layer, the control plane, which in turn is built on top of the data-forwarding plane. The data-forwarding plane consists of agents performing both hardware and software packet forwarding. The control plane resides on a single entity, normally an SDN controller, and on top of it are SDN applications, which allow different ways to program the controller. This forms a new logical network to define a new service, to enhance bandwidth, and provide all of the services that could be offered today or in the future.

To communicate between these three layers, two interfaces are defined. On top of the controller, the northbound interface, connects the application to the controller; and below the controller is the southbound interface, connecting the controller and data-forwarding devices. One clear example we have for a southbound interface is the OpenFlow protocol, first defined at Stanford University and is now specified and enhanced by the ONF.

In this SDN scheme, the device, the lower layer, becomes a very simple, almost generic type of hardware with a strong processor, several data ports, etc. In the software structure of the device we have an abstraction layer, defining flow tables and the interface to the southbound/OpenFlow protocol. This abstraction allows the controller to send instructions, such as a data-forwarding policies or flow tables, and allows the “generic” hardware and software to very simply apply instructions for forwarding user data packets.

There’s some criticism of SDN, focused mainly around the notion that it represents too much change for the network; that the SDN controller is a single point of failure; that the SDN controller cannot scale because it relies on a single controller; or that packet operations are too complex and cannot be performed efficiently. In fact, however, there’s significant evidence that none of these criticisms are actually true.

SDN architectures are seeing more and more deployments and they are proving to be a very dynamic way to evolve, manage, and also reduce, from the operator’s point of view, network CAPEX and OPEX. Given that hardware and software become almost a generic type of device. It is easier and more cost effective to maintain and deploy new services. It also dramatically expands the possibilities in terms of what type of business could be defined as an “operator” completely changing the playing field.

So far, SDN has primarily been implemented in operators’ core networks and data center backhauls, based mainly on cable, wire, and optical components. However, wireless is a highly important element of access networks, and very little work has been done so far in the wireless part of the SDN world. Some efforts have begun in standards groups, which is where we normally see activity concentrated in the earliest stages of an emerging technology.

In the IEEE 802 group, there are a number of very successful access technologies defined. For instance, everyone is familiar with IEEE 802.11 WLAN (or Wi-Fi), as most mobile phones, tablets, game consoles and consumer electronics use it to interconnect between each other or to the Internet. Also, several residential, academic and commercial networks use IEEE 802.3 Ethernet cables and fibers to connect devices. Clearly, it’s important to make sure that whatever evolution happens in the wireless IEEE 802 family of technologies takes into

Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES