SDN-based Networks for Internet of Things (IoT): How ONOS helps

Introduction

Software-defined networking (SDN) is one of the key technologies driving the transformation of the next- generation networks. To begin with, SDN was just a mechanism to separate out control from data. The logic to control the network was moved to a centralized controller. This allowed the operators to program the network on demand from one point of control. Further, it allowed them to set rules/configurations across devices, from different vendors in a unified way, without manual intervention.

These flexibilities proved to be a huge improvement over traditional networking where provisioning/configuration was done on an individual basis and a single failure in the network could lead to huge downtimes.

The notion and scope of SDN applicability in networks have considerably transformed since then. Traditional networking using distributed routing protocols is focused on the needs of the basic network – route discovery, link failure recovery, etc.

However, these services by themselves don’t fulfill the requirements of emerging technologies like IoT and MEC – handling multi-vendor devices, heterogenous networks (Wi-Fi, Bluetooth, ZigBee, LTE), huge amounts of data, faster deployments, management of services, etc. SDN promises to deliver an agile and flexible network infrastructure to handle varying user demands and diverse network scenarios.

This document enlists some of the key use cases of SDN in emerging next generation networks and how popular SDN controllers like ONOS and ODL can be used to conceptualize these use cases.

Abbreviations

Here are some abbreviations that will be used throughout the rest of the text.

Programmable and Flexible Topology Management

IoT applications are drastically different from the legacy ones. IoT intends to connect billions of devices. Apart from the dimensionality challenge, complex operational issues also exist for IoT. These issues can be resolved by introducing a high level of automation in the delivery and operations of IoT applications. This is where SDN can facilitate the IoT domain. Following are some challenges/issues in IoT and how SDN programmability can help in these:

1. Massive device connectivity: IoT will comprise billions of multi-vendor devices, which might be deployed in a very uncoordinated manner. Adding routing/forwarding information pertaining to these devices will require the automatic discovery of these devices and dynamic route computation mechanisms across the network. SDN controller can be used to interface with switches in the forwarding planes to set the traffic flows across the network, for these devices.
2. Rapid changes in the network: IoT devices are constrained in terms of energy and CPU. They might often get pruned from the network due to low battery or CPU overloading. They also operate on various wireless technologies which might have considerable failure rates. In a nutshell, IoT networking infrastructure might have to handle rapid changes – thus needing a change in the routing/flow information on the network elements. SDN can handle such scenarios optimally by dynamic topology maintenance.
3. Handling scalability in the network: The recent applications and services are designed around the NFV principles, where network entities are instantiated or terminated on the fly. In IoT, this might mean pruning and grafting of IoT controllers (gateways) as needed. SDN can be used to determine the location of these controllers intelligently and update the flows of the connected devices accordingly.
4. Low Power Endpoints: IoT endpoints have very low computing power and need to manage battery drain issues. Hence, they cannot implement complex routing or network control protocols.

What is ONOS?

One of the most widely accepted SDN controllers for such purposes is ONOS. ONOS is the SDN network operating system with robust architectural features like high availability, scalability, modularity, and complete separation of protocol agnostic and protocol-specific representations of devices and links. ON.Lab, along with AT&T and NTT Communications, gave the first ONOS release in 2014.

ONOS provides applications with a number of high-level APIs, through which they can learn the state of the network and control the flow of traffic in the devices, based on the current network state.

ONOS Architecture

ONOS has a multi-layered architecture divided into – application, core and providers (Figure 1). ONOS core has multiple subsystems to dynamically support topology discovery (using OFDP) and path computations (based on discovered topology). The core conveys this information to the application layer for decision-making. ONOS provider layer supports standard SB protocols like OpenFlow to convey the selected path to the switches/devices across the network. This south-bound interface is used to discover new devices joining the network and communicating the updated paths computed at the upper layers of the ONOS stack. The diagram below indicates the logical flow of how ONOS manages the topology and path computations dynamically:

Load/Power Management or Failover Management to Support High Reliability

IoT networks comprise sensors/devices that are resource constrained in terms of CPU & energy, and hence may face starvation (depletion of batteries, overloading) very often. The wireless communication links used are also prone to failures, thus causing frequent changes in the network topology.

IoT networks thus mandate the need for load balancing schemes and fast recovery from failures, to meet the latency and reliability requirements. SDN can be used to handle these anomalies as well, in a self-healing manner.

The following examples indicate a few such cases:

1. “ehealth” services need to monitor the biometrics data. There might be a need to communicate with the nearest hospital or there might be a need to act on health emergencies urgently. Thus, these services require a highly reliable networking infrastructure – which supports intelligence to dynamically compute optimal routes to the nearest help. IoT network elements can pass notifications to the SDN controller indicating failure events (link failed, port down). The SDN controller can re-compute the optimal paths with faster convergence time. This self-healing capability is a pivotal functionality of SDN and, hence, will be taken in more detail towards the end of this article.
2. Smart-grids might face downtimes due to overloading – this usually has a cascading effect. In this case, the SDN controller can collect stats/meters indicating the network status (load) at various points in the network. The SDN controller can run energy efficiency algorithms to figure out less-loaded forwarding elements. It can then help in reducing energy consumption by turning off some intermediary forwarding switches or bringing down some ports in case of low loads and recomputing paths based on the latest topology. This strategy works well for such networks since these networks usually generate traffic in bursts.
3. Energy management in wireless sensor nodes can be managed using an SDN controller located locally in a Wireless sensor network (WSN). Instead of the sensor nodes themselves deciding when to go in sleep mode based on their remaining power, the SDN controller can be used for this purpose. SDN controller can consider other parameters also, like the power state of other nodes, to take a centralized decision. Hence, ensuring that putting a sensor node to sleep will not lead to any connectivity issues.
4. Meeting user’s expectations and achieving QoE targets is also critical for IoT. SDN facilitates this by collecting metrics at the SDN controller and comparing the reported quality with the expected quality, with respect to the real-time requirements of IoT services. In accordance, flow rates might be limited to meet the pragmatic needs of the aforesaid services.

Orchestration for end-to-end network slicing and multi-tenant support

To support the kind of service models for 5G and IoT, the networking infrastructure will need to divide a single physical network into multiple logical entities:

1. Different applications have different QoS requirements – For instance, health services require high privacy. Whereas, for VTX communication, low latency paths are needed. Such scenarios need to support application-aware routing – the paths between the same end-points might be different for different applications. For example, we could have a mission-critical real-time service, which needs to limit the total number of hops along any path along with a high-volume data service, which needs a minimum guaranteed bandwidth in each link; both of which need to share the same physical network. This can be conceptualized using network slicing. SDN can help realize network slicing all across, using virtual networks and setting up flows for these virtual networks on the forwarding elements.
2. Security needs of subscribers are handled using multi-tenancy. This can be handled by placing their IoT devices on different virtual networks and adding firewalls configured specifically for these devices. SDN assists in establishing end-to-end virtual networks, overlaid on the physical network, thus isolating these IoT devices.

Virtual networks can be realized in SDN controllers like ONOS by defining a custom application on the northbound side, which can use the underlying ONOS subsystems to program flows into the edge SDN switches – flows will mandate that the packets are encapsulated with an extra header containing VLAN Ids, these VLANs can represent traffic from different customers or from different services. Then, the traffic policies can be associated using these VLAN flows.

ONOS also supports Virtual Tenant Network (VTN) application to create virtual networks underneath.

Link Failure Handling: SDN vs. Traditional Networking

An inherent requirement in the networking world is to provide high reliability – network links are prone to failures. Thus, how soon the network recover from the failure is what makes the difference. This is defined by the convergence time of the network, i.e. time taken by the network to resume communication of nodes post link failures.

Traditional networking follows a distributed approach to handling link failures. Taking OSPF as an example, whenever a link goes down, the directly connected OSPF routers will generate a Link state advertisement (LSA) and flood it to all its neighbors – the failed link doesn’t appear in the LSA anymore.

Now, when the other routers receive this new LSA, they run ‘shortest path first (SPF)’ again to compute the new topology and accordingly update their tables – thus deleting routes containing the failed links. This kind of propagation of failure and re-computation of paths can lead to higher convergence times, specifically with increase in scale of topology.

OSPF does suggest some techniques for faster convergence, like fast failure detection, but most of OSPF operations are controlled by timers. These timers can be decreased to reduce the convergence time, but this can have an impact on the network load and CPU cost.

These kinds of routing protocols are not suitable for the low power and lossy networks that operate in IoT. For instance, on using OSPF in these networks, devices would be flooded with LSA – this would have a cascading effect since this would congest the low-rate Wireless sensor networks.

Also, the IoT devices are generally CPU, memory constrained- running SPF algorithm so frequently would consume excessive battery. With the exponential growth in the scale of network, these routing protocols would have a terrible effect on the performance front.

Software-defined networking can help in faster network recovery after link failures. Individual bi-directional OpenFlow message exchange between OpenVswitch (running on the SDN devices) and the OpenFlow controller on the SDN controller, leads to faster discovery of failure and communication of updated flows on the devices.

Taking reference of ONOS again, OpenFlow messages indicate “port status update” to the OF Controller running in ONOS. This update message triggers a “port down event” to the ONOS core. The ONOS core accordingly removes this link from the topology graph so that it maintains and recomputes the flows. It then uses individual OpenFlow connections with SDN devices to send these new flows, thus eliminating the need for flooding link failure info and computing paths on the devices themselves. This leads to faster convergence of network and energy saving on devices.

ONOS also supports a distributed architecture where multiple ONOS instances coordinate using ‘stores’ to share the topology information – thus sharing the link info update beyond the scope of local network.

Support for Legacy Routing Protocols in SDN

The above section clearly indicates the improvements of OpenFlow-based SDN architecture over traditional routing protocols (OSPF, BGP, etc). At the level of data centers, L2 configuration holds good and hence OpenFlow works well for these.

Even for the WAN environment, configurations can be done at L2 using VPNs. But for WAN scenarios operating at L3, SDN controllers will need legacy routing protocols. For e.g., BGP support in SDN controllers solves multiple purposes:  Seamless connectivity of an SDN network with the rest of the internet using BGP, and aggregating different SDN based ASs into BGP confederations.

ONOS supports Border Gateway Protocol with Link State Distribution extension (BGP LS) and OSPF as southbound plugins. Both can be used to collect the topology information of the network. This information can then be passed to ONOS applications like Path Computation Element (PCE), giving PCE visibility outside an AS.

ONOS effectively plays the role of a BGP speaker or an OSPF router to get this information from peers. An advantage of this feature is that it can be built on top of an existing network with little change.

Summary

Software-defined networking is bringing a paradigm shift in the way connectivity, reliability, and management requirements of devices is handled in the next generation networks.

Popular SDN controllers like ONOS or ODL have strong support for the various scenarios w.r.t these requirements. From using standard protocols like OpenFlow and RESTCONF to having matured sub-systems to handle ever-changing dynamics and complexities of the networks, SDN is the driving force towards a flexible networking infrastructure needed by emerging applications and services.