SDN and NFV are delivering a more agile and future-proof network for service providers and enterprise
Cloud service providers and large enterprises need more responsive networks, and these are being offered by the new technologies of SDN (software defined networking) and NFV (network functions virtualization). Among the benefits offered by these two developments are the ability to place applications dynamically in data centers, to implement microservice architecture and microsegmentation, to deal with traffic congestion and quality of service (QoS) demands dynamically, to improve network utilization, and to provide network functions in an agile manner. Between them they can allow lower operational expenditure (opex) and more innovation, as well as automation and simplicity.
SDN is often described as separating the control and data plane of a network. The control plane consists of the “signalling” functions of the network which make decisions about where traffic is sent, while the data plane is the underlying network that routes traffic to the correct destination. SDN defines protocols and standards so that these two can be decoupled - wprl which is being done within a number of mostly open source projects (see ”SDN and NFV projects”, below
This allows for greater simplicity in building and managing networks. SDN controllers and managers run on servers, handling control plane tasks. They integrate “upwards” with higher-level service management functions, and “downwards” to manage multiple kinds of network equipment, including branded devices and “white label” original device manufacturer (ODM) equipment.
Network functions virtualization (NFV) virtualizes network node functions so they can be put together as building blocks. This can be implemented on top of an SDN network or other architecture. The idea of NFV emerged from the telecommunications industry in 2012, and more than 38 telecoms players have signed up to the European Telecommunications Standards Institute Network Functions Virtualization Industry Specific Group (ETSI NFV ISG).
By the end of 2014, 34 NFV ISG proof-of-concept deployments had already been demonstrated or were in progress. These address a variety of NFV elements, including architectural frameworks for compute, hypervisor and network domains, service management and orchestration, security and trust, resilience and service quality metrics.
Participants include AT&T, NTT Com, BT, Telefónica, Orange and Deutsche Telekom. The next two years will see the focus move beyond requirements and towards industry transformation as telcos and service providers introduce NFV technology into live networks, with key topics including interoperability, operations and collaboration with other industry groups, including open source consortia.
The potential use cases of NFV are wide-ranging. Cloud radio-access networks (C-RAN) are being deployed by China Telecom to replace cellular base station hardware with centralized, cloud-based software functions.
Other examples of virtualized network functions (VNFs) include virtual CPE (customer premises equipment) which allow service providers to deliver services with less hardware placed on the user’s premises. BT has earmarked these as substitutes for devices such as firewalls, load balancers, WAN optimization appliances and other dedicated devices in locations that previously had to be serviced by on-site engineers.
LTE-based mobile networks operate with the evolved packet core (EPC) standard, which lends itself to virtualization, so that now most mobile operators are operating a virtual EPC as a VNF.
Solving Layer 2 problems
German cloud engineering and consultancy company CloudSeeds is one example, having started with SDN-enabled data center infrastructure from its inception in 2012, when founder Kevin Fibich realized that any requirement to scale its infrastructure as a service (IaaS) hosting business beyond a certain size would create problems within the Layer 2 part of the network.
“We can use SDN in a dynamic fashion. If a customer needs distributed, denial-of-service (DDoS) protection, we can switch it on without impacting service uptimes”
Kevin Fibich, CloudSeeds
“We saw that SDN would be a great help because it allowed us to build a pure Layer 3 network,” he says. “We had worked with the open shortest path first (OSPF) routing protocol and border gateway protocol (BGP) for years, and knew how flexible and scalable networks could be without Layer 2 problems. SDN gave us a scalable infrastructure that could just grow [with the business].” CloudSeeds also wanted to automate its application delivery using standardized hardware and software infrastructure and support backup and disaster recovery services by building virtual networks that span multiple, geographically distant data centers.
A survey of US enterprises, published in February 2015 by research company IHS, suggests that the top SDN use cases in support of capex and opex savings are based on the same imperatives: automated application provisioning and disaster recovery, alongside hybrid clouds designed to span on-premise and hosted data center architecture.
After testing rival vendor equipment, the IaaS provider installed Juniper’s Contrail Networking automation solution for cloud SDN. Contrail Networking is developed by Juniper and a larger community of developers and users like CloudSeeds in the OpenContrail open source project. On the Layer 3 switching underlay fabric, Contrail Networking orchestrates each tenant’s private virtual overlay networks and creates NFV-style service chains for smaller virtual firewalls for CloudSeeds’ customers. While this overlay solution supports a multi-vendor Layer 3 underlay, CloudSeeds also used Juniper’s QFX5100 Ethernet switch in a high-performance data center fabric, alongside the Juniper SRX1400 Service Gateway Firewall and Juniper’s MX80 3D Universal Edge Router for diverse wide area network (WAN) connectivity options. Having worked with Juniper Networks in the past, the CloudSeeds technical team liked the vendor’s approach to open APIs and software management features that allowed it to install the Puppet configuration management system software agent directly onto switches running the Junos operating system, so the entire physical underlay architecture could be provisioned using their usual automation tooling.
“We had APIs where we could directly configure devices without having to do workarounds,” explains Fibich. “The configuration is completely versioned, which is a really great thing because, when we start to automate network device configuration, it has this history of pre-configuration, where we can see what the automation process did, what configuration changes were applied, and if something went wrong, why it did so.”
Implementing on the fly
Now CloudSeeds is experimenting further with SDN to see how it can be used to implement security applications such as firewalls or anti-virus on the fly without needing to make changes to the underlying network.
“Another interesting feature is the service chaining concept. We are seeing how we can use SDN in a dynamic fashion so that if a customer needs distributed, denial-of-service (DDoS) protection, for example, we are able to put that in the system and switch it on without impacting service uptimes,” he says.
The fact that CloudSeeds is a startup is significant: the company was able to build its data center architecture from scratch, without having to think about any legacy server, storage or network equipment integration. Few other SDN/ NFV deployments, whether enterprise or telco, have that luxury, and in most cases the complexity involved in configuring, managing and maintaining virtual and physical network hardware and software within the same network still causes apprehension among potential customers.
Clifford Grossner, research director for data center, cloud and SDN at IHS, points out that none of these issues are new, however, and that the slow pace of adoption is inevitable given the relative immaturity of SDN technology. While only six per cent of companies responding to the IHS survey expected to see their organizations engaged in live production SDN networks by the end of 2015, for example, that figure rises to 23 per cent by 2016 and 93 per cent by 2018.
“I don’t know of any technology – especially when you are talking about a network that is a complex animal – that would be any different. It takes time for everything to happen, because first versions are never mature, and you need to get to a point where people understand what they can do with it before it really starts to grow. And that can take years.”
SDN and NFV projects
The first protocol defined to link the control and data planes of an SDN architecture, OpenFlow allows compatible switches to be manipulated and managed directly. It is managed by the Open Networking Foundation (ONF), whose members include Facebook, Google, Juniper Networks, Microsoft and Verizon. OpenFlow version 1.1 was published in 2011; it is now on v1.4.
An open source project offering cloud networking automation, OpenContrail was seeded by Juniper Networks and is available under the Apache 2.0 license. It provides components for network virtualization including an SDN controller, virtual router, analytics engine and published northbound APIs. It is configured and exposes data through a REST API or its GUI.
Backed by the Linux Foundation, OpenDaylight is a collaborative, open source initiative with broad vendor support. It has released three versions of its standards-based SDN controller platform: hydrogen, helium and, in June 2015, lithium – a ‘carrier-grade’ iteration that adds support for OpenFlow, OpenStack Neutron, and new security, monitoring and automation features, alongside more APIs, service function chaining and NFV.
Open Network OS (ONOS)
The Open Networking Lab (ONLab), backed by the ONF, released the Open Network Operating System (ONOS) – an SDN/NFV-enabled open source switch/router OS designed for white box hardware in cloud service provider networks. The second version of ONOS, Blackbird, shipped in April 2015 with a ‘carrier-grade’ SDN tag affixed.
Project Floodlight is an open source Apache-licensed, Java-based OpenFlow SDN Controller, released by Big Switch Networks and managed by the ONF. It specifies a way to remotely control OpenFlow networking equipment.