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.
Here are some abbreviations that will be used throughout the rest of the text.
|Border Gateway Protocol
|Internet of Things
|Link state advertisement
|Long term evolution
|Multi-access edge computing
|Network function virtualization
|OpenFlow Discovery protocol
|Open Network Operating System
|Open shortest path first
|Path Computation element
|Software defined networking
|Simple Network Management Protocol
|Yet Another Next Generation
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:
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 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:
Though the above diagram indicates SDN-based management for a data center type of topology, the concept can be extended to wider domains. The devices performing OpenFlow communication with the SDN controller can be IoT devices.
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:
To support the above scenarios, SDN controllers like ONOS have multiple SB protocols like NetConf, RESTCONF, and SNMP, which are used to convey statistics or status from devices to the ONOS core.
At the northbound side, REST or RESTCONF can be used to convey the same, to the application layer. The Application layer can convey its decisions (in terms of re-computed paths or new configurations to be passed) to the devices using OpenFlow, NetConf, RESTCONF etc.
The diagram demonstrates the use case where ONOS is used locally in a wireless sensor network. Based on the remaining power in a node and the states of other nodes, the SDN controller can trigger a sleep mode for that node.
Other than the network config sub-system shown above, ONOS supports other subsystems like Dynamic config subsystem (which uses YANG modeling) and dynamic configuration brigade, which can be used to seamlessly bring up/down and configure devices from different vendors for load balancing and power management techniques.
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:
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.
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.
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.
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.