The Challenge of Binding the SDN Evolution

Featured article by Jeanne Ziobro, Product Manager, Opengear

According to research from Ericsson, we’re on pace for 50 billion connected devices by 2020. Underpinning this Internet of Things ecosystem will be a sea of fixed and wireless networks that require the flexibility to deal with a huge diversity of use cases, network resiliency demands, and operating models. And yet the IoT represents just one of many applications that Software Defined Networking may well be called upon to address (and at the moment, the technology is still very much in an early stage of adoption).

SDN takes the control plane, data plane, and management plane that are traditionally created in firmware and implements them in software. The result enables programmatic access and, as a result, makes network administration much more flexible. In essence, the software now becomes more vital than the proprietary hardware. In complement, Network Function Virtualisation (NFV) takes many of the network functions such as routers, firewalls, and content delivery networks and turns them into virtualised building blocks that can connect to build complex services. On top of this foundation, networks can build an entire orchestration layer that can potentially automate network reconfigure based on factors such as bandwidth demands, security issues, hardware failure, or other triggers.

But Software-Defined does not necessarily mean open, and challenges remain. There are several powerful groups that are helping to promote interoperability and baseline standards. For example, the ETSI Network Functions Virtualisation Industry Specification Group (NFV ISG) was founded in 2012 and has grown from a handful of telecom providers to over 72 companies and industry leaders. Another is OpenFlow, which since its 1.1 version launch in 2011 has gained broad vendor support that includes networking products from Cisco, HP, Brocade, Juniper, Big Switch, VMware and Extreme Networks (among dozens of others that have committed to support the standard).

Although OpenFlow is gaining traction, it is still only a protocol and doesn’t actually dictate how an SDN deployment should be designed. By its very nature, the move to software provides flexibility – but this does not necessarily equate to a more effective network when compared to the current networking topologies. In reality, each of the main vendors in this space has chosen a different path, and true seamless interoperability of SDN technologies remains a ways off.

From the management perspective, SDN does not have a built-in method for out-of-band accessibility. In reality, the routers, switches and other network elements are still relying on the built–in console servers reached through out-of-band (OOB) serial and out-of-band Ethernet ports. The reason is simple: at a hardware level things still fail and “lock-up,” leaving devices unresponsive and requiring either a manual or (more likely) automated reboot and possibly a settings roll-back to the “last known good” configuration. As such, many SDN roll-outs are also investing in OOB tools to provide an extra level of resiliency and connectivity that serves the current non-SDN infrastructure and through to the subsequent generations.

“Smart” OOB adds extra intelligence by including features such as 3G/4G cellular failover, environmental monitoring, proactive fault diagnostics and automation based on predefined policies or through examining the state of connected devices. These Smart systems also integrate into single-plane-of-glass network management systems, such as Nagios or SolarWinds. The reason Smart OOB is so effective alongside SDN is that replacing the serial ports and console connections is not on the roadmap for SDN vendors. In fact, it’s one of the few things that they all have in common.

Jeanne Ziobro is a Product Manager at Opengear, a company that builds remote infrastructure management solutions for enterprises.