Techies at Mobile World Congress Getting Coffee

I recently sat down for an interesting one-on-one talk with Andrew McLachlan, VP of Engineering at Inocybe Technologies, during Mobile World Congress 2018 in Barcelona, Spain. It was a pleasure to discuss ‘network evolution’ and get his viewpoint on how operators are following the software-centric approach to service delivery within the scope of software-defined networking (SDN) and network functions virtualization (NFV) to enhance their networks, today.

Tania: In a nutshell, what is it about SDN that makes it so appealing?

Andrew: SDN is changing the way we manage and design networks. With the help of SDN, both network design and management have become a lot easier and much more innovative. SDN can be described as having two main functions: it separates the control plane – which decides how traffic is handled, from the data plane - whose elements such as routers and switches are responsible for directing and forwarding the traffic. It also merges the control plane so that it can control multiple elements at the same time. The control of all these elements comes from a well-defined API.

Tania: From an engineering perspective, where is SDN going from here?

Andrew:When looking at the future of SDN, perhaps it's useful to go back in time and consider what the original problems were, that we looked to SDN to address. A fundamental issue was always how organizations needed to accelerate service creation and turn-up. One aspect of the problem belonged to customer-facing activities such as the “service” configuration. At that time, there was no easy way to separate the network control plane into infrastructure and service, or, for the underlying infrastructure to be abstracted from the applications. This made network management tasks such as controlling router behavior / config extremely difficult.

Out of those situations came the massive operational support system (OSS) overhead. In examining what service providers spent on OpEx, their OSS costs never really ended, and only increased with each new service. Plus, they had to buy the physical devices such as routers/switches as a one-time cost plus any ongoing costs for maintenance and support.

What programmatic interfaces and modeling languages help us achieve is a more common interface to devices and their functions. YANG, for example, is the data modeling language used to describe the functionality on the device. It’s relatively easy to learn and can efficiently support the definition of operations on a device via remote procedure calls (RPCs).

Initially the emergence of the OpenFlow protocol made network control directly programmable. However, as an implementation it took some time for the code base to mature, mostly due to not learning from past implementations of hardware switching. The philosophy back then was, “Why should we buy expensive hardware? Can’t we just build a switch out of commodity hardware?”

True. You can do that, but initial implementation did not take into account a lot of the “why” when switching software and hardware had arrived at the standards and implementations of current platforms. In an operational world, traffic can’t simply just be thrown away and/or be given ‘another shot’, while processing a flow of action from a remote SDN controller. Local control planes exist for good reason.

Over the last few years, we have seen NETCONF become a go-to protocol for providing a programmatic configuration interface. This has enabled non-network developers using device models to create applications to drive network services. We have seen a radical shift in the skills needed to operate networks and build services, away from CLI toolkit and into a web developer area.

Another pivotal point has been ‘commodity hardware’ which has greatly impacted the landscape of IT infrastructure. Equipment is now more affordable and, in using open source and open standards, has increased IT/OSS compatibility.

As a result, a new breed of hardware manufacturers has emerged. They are using commodity hardware to maximize their savings and reap the benefits of an open source approach and further enable SDN.

With organizations now virtualizing their networks, it is really only in using a combination of SDN, commodity hardware and open-source that the cost model can change to support the scale now needed for service deployment.

Control of the infrastructure, and the desire for a web-centric language, is where we find SDN Controllers being deployed.

OpenDaylight (ODL) has emerged as the dominant controller in the market. It has the largest developer community and with the ever-increasing number of plugins available, can be easily positioned for a wide range of functions.

For me, one of the key technologies in OpenDaylight is that of auto code generation. This makes it an easy choice for deployment and development. Being model-driven, OpenDaylight is a platform by which, when given models, can autogenerate all the code needed for a developer to interface with devices/services via REST and JAVA.

Connecting a compatible NETCONF device to ODL will allow for automatic ingestion of the device models on the device, into ODL. Essentially, the device’s feature set is then self-describing, beginning with ODL, then in runtime, and finally generating all the code needed.

The time and cost savings are considerable when compared to a traditional OSS stack, where code has to be written all the way down the stack from the OSS to the device’s individual interface; CLI interpretation, for example.

Tania: When it comes to service providers and enterprises, where are we now?

Andrew: Certainly around controllers and defining modeling languages such as Tosca and YANG, we have reached a production-ready deployable technology for SDN. I believe that in order to move forward in NFV and SDN programming tools, there should be a fundamental rethink as to what services we want to carry forward. It is potentially unwise to take complex legacy services in their entirety and migrate them to a fully virtualized environment. History teaches us that this is rarely successful. Perhaps part of SDN’s role is to enable us to move faster from legacy.

With the drastic increase in available bandwidth, whether fixed or wireless, customers are able to consume applications of all types in a very disaggregated way, compared to previous models. Services have for the most part become OTT, and not embedded in the lower layers of the infrastructure.

Complex vertical OSS integration, which was always the long tail for deployment, is making way for today’s rapid deployment cycles and perhaps more importantly, rapid decommissioning. The trend that we are seeing is that many services come and go extremely quickly and it’s just not possible to scale up and down rapidly enough when they are physically attached to the infrastructure.

This is where SDN shines - by enabling rapid change. Coupling SDN with flexible and programmable hardware, we now have some very powerful tools to help us move forward as an industry.

Inocybe is thrilled to announce our recent partnership with Kontron to bring to the service provider and enterprise communities, newly integrated open networking switches designed to work seamlessly with an OpenSwitch-based NOS that is controlled by an OpenDaylight SDN controller.

The feedback was extremely positive during Mobile World Congress as the integration done by Inocybe between OpenSwitch and OpenDaylight has enabled a faster path to a modern application development environment, where non-network engineers can write network apps in their preferred language (for example, Python) without requiring expertise with Java. This integration also enables the end user to have a single, common interface that is model-driven and enables them to manage both physical and virtual switches through a single switch NOS. As we move forward, we are working with Kontron to continue to develop a more complete portfolio to simplify NFVi and white box deployments for our customers.

What successes or challenges have you faced with software defined networking? Is the path to ‘open’ switching one you see in your future deployments?