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 individual basis and a single failure in the network could lead to huge downtimes.
The notion and scope of SDN applicability in networks has considerably transformed since then. Traditional networking using distributed routing protocols are focussed on the needs of the basic network; route discovery, link failure recovery, etc. However, these services by themselves don’t fulfil the requirements of emerging technologies like IoT and MEC – handling multi-vendor devices, heterogenous networks (Wi-Fi, Bluetooth, ZigBee, LTE), huge amount 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, ODL can be used to conceptualize these use cases.
Here are some abbreviations that we will be using 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 controller for such purposes is ONOS. ONOS is the SDN network operating system with strong 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 through which they can 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 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 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 centre 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 of sensors/devices which 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 of 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. Following examples indicate few such cases:
To support the above scenarios, SDN controller 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. 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 below demonstrated 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 modelling) 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 programme flows into the edge SDN switches – flows will mandate that the packets are encapsulated with extra header containing VLAN Ids, these VLANs can represent traffic from different customers or from different services. The traffic policies can be associated using these VLAN flows then. ONOS also supports Virtual Tenant Network (VTN) application to create virtual networks underneath.
An inherent requirement in networking world is to provide high reliability – network links are prone to failures, how soon does 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 for 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 impact on the network load and on 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 “port down event” to the ONOS core. The ONOS core accordingly removes this link from the topology graph 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 of 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 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 solve multiple purposes: Seamless connectivity of an SDN network with the rest of the internet using BGP, aggregate 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) – this will give PCE visibility outside an AS. ONOS effectively plays the role of a BGP speaker or an OSPF router to get this information from the 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, 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.