eBook CTO’s guide to SDN, NFV and VNF

Tweet this

CTO’s guide to SDN, NFV and VNF

Networking and communications standards and methodologies are undergoing their greatest transition since the migration from analogue to digital. The shift is from function-specific, proprietary devices to software-enabled commodity hardware.

In the context of the modern transition, this eBook explains the three most popular terminologies today – SDN, NFV, and VNF. It addresses why the transition is happening and why it’s important for any individual or organisation that has responsibility for a network to understand and embrace this emerging opportunity.

The potential benefits, and some deployment and management solutions for software-enabled networking, are addressed throughout the eBook.

Canonical is involved in networking and data communicationsCanonical, the company behind Ubuntu, works closely with its networking and telecoms partners on all aspects of emerging networking technologies and modern data communications. We provide infrastructure and partner solutions to support SDN and NFV infrastructures We also offer unique performance and interoperability testing for clouds and VNFs.

What you will learn

Tweet this

CTO’s guide to SDN, NFV and VNF

Christopher WilderHead of Content, Canonical

Christopher Wilder has domain expertise in Cloud Computing and Infrastructure, the Internet of Things (IoT), Machine Learning and Business Analytics, Networking and Communications and Software Defined Infrastructure.

Chris is the co-author of the best-selling book, Influencing the Influencers, and is a frequent contributor to Forbes and TechTarget. He has also published multiple columns on enterprise applications in The New York Times, Boston Globe, CEO Magazine, and others. He serves on the board for TechTarget’s Cloud Advisory board, and is a trusted advisor for dozens of technology companies worldwide.

About the author

Tweet this

CTO’s guide to SDN, NFV and VNF

Executive overview

Economic benefits of software based networking

Why now?

The many meanings of SDN

Server virtualisation introduces SDN

Continuing to evolve SDN

SDN infrastructure layers

Network functions virtualisation – NFV

Contents

General purpose network hardware

Generic switch hardware and SDN on servers

Do I need a cloud for SDN and NFVi?

Ubuntu for hyperscale

Deploying and managing SDN and VNFs

Performance and Interoperability

Canonical, SDN and NFVi leadership

Conclusion

About Canonical

05

06

07

08

09

11

13

14

15

16

17

18

19

20

21

22

23

5

Tweet this

CTO’s guide to SDN, NFV and VNF

Network infrastructure is following the path of server hardware, which migrated from application- specific servers to virtual machines. We’re now migrating from function-specific network hardware to software-based virtual functions.

For organisations that already have virtual machines deployed, you’re already using SDN today. If you have a firewall or load balancing service running as a virtual machine, you’ve begun using NFV infrastructure, as well.

The premise of SDN and NFV technologies isn’t new, but within your organisation, their rapidly expanding use cases may be.

Operational expenditure can be dramatically reduced by the flexibility of software-based network infrastructure.

Software Defined Networking – SDN Software on commodity hardware that coexists with or replaces traditional, proprietary network hardware, like switches and routers.

Network Functions Virtualisation – NFV Generally refers to virtualising higher level network functions, as software, on commodity hardware. NFV infrastructure can run on top of traditional network hardware, SDN-based networks, or a combination of both.

Executive overview

Virtualised Network Functions – VNF The specific network function that is now a software service deployed on commodity hardware, for example firewalls, IP services – DHCP/DNS/load balancing, VoIP, IMS – message services, RANs, EPCs, and more.

6

Tweet this

CTO’s guide to SDN, NFV and VNF

Economic benefits of software-based networkingScaling and operatingSDN and NFV offer nearly infinite economies as of scale. Most of the issues with oversubscribing ports – not having enough, or undersubscribing ports – buying more than you need, are eliminated when software is introduced to replace physical, single-function devices. Time is money, and in a software-driven infrastructure, updates, upgrades and changes are all faster and much simpler.

The cost of commodity hardware is typically much lower than that of function specific network equipment. Support costs also decrease, from hardware maintenance cost to operational and vendor support.

DecouplingMoving network control out of proprietary hardware devices and into a software infrastructure, and migrating network functions from single purpose hardware to VNFs on commodity hardware, are both examples of decoupling the desired function from the hardware. Decoupling provides an agility that has never before been available to network operators.

For example, when you decouple system performance – data plane, from system configuration – control plane, a network upgrade from 4G to 5G can be done without system configuration migration or redefinition. You just change the VNFs that control the antennae. Similarly, an entirely new network infrastructure could be overlayed on an existing topology with SDN.

Beyond upgradesNew features and new network requirements are increasingly being made. In a traditional network approach, these capabilities either aren’t made available or require new hardware procurement, physical installation, and physical connection. With SDN and NFV infrastructures, new features and capabilities are deployed as software.

The same care must be taken when implementing new software features as with new hardware, so interoperability testing and architectural design are still critical. The time to implementation is dramatically reduced, though. Further in this eBook interoperability and performance testing are addressed as you read about OIL and V-PIL.

7

Tweet this

CTO’s guide to SDN, NFV and VNF

Why now?

EcosystemThe ecosystem of available SDN and NFV based solutions has grown and matured. New software and hardware technologies make commodity servers offer the same capabilities, performance, and sometimes even increased reliability.

EconomicsAs clouds and modern IT infrastructure continue their explosion of growth, the economics of traditional datacentre networking become less desirable and completely unaffordable for some organisations. SDN and NFV based infrastructure solutions offer both OPEX and CAPEX relief for organisations of all sizes.

HardwareAdvancements in commodity server hardware IO and chipsets bring performance levels to that of ASIC-based hardware – proprietary systems. Hardware features like DPDK and SR-IOV enable programmable data planes within servers that match the speeds of legacy function specific networking hardware.

SoftwareSDN and NFV both require an open, general purpose operating system, Linux, running on the commodity hardware that supports them. Ubuntu (and the Ubuntu kernel) are the platform that provides the reliability and scalability, both from technical and a financial perspective, that enables SDN and NFV infrastructure today.

The operating system is where technologies like DPDK and SR-IOV are enabled and managed.

IO Visor is another example of open source software that enables the Linux kernel and associated network software to have programmable and user-defined functions in realtime, without restarting systems.

These, and others, are technologies that a decision maker will consider when designing SDN and NFV based infrastructures.

8

Tweet this

CTO’s guide to SDN, NFV and VNF

The SDN conceptIt’s best to think of SDN as an umbrella term, not as a strictly defined idtea. It largely encompasses two main categories. There is overlay SDN, which is defined by software, and there is hardware based SDN, which focuses on separating the control of network hardware from the hardware itself.

The different implementations of SDN are not necessarily exclusive. In most cases, organisations will benefit from both overlay SDN technologies as well as hardware-based, underlay SDN solutions.

Other SDN approaches also exist, but the defining aspect of SDN is the change in focus away from the network hardware itself to the software that manages and operates it.

The many meanings of SDN

Overlay SDNAn overlay SDN allows any consumer of IT to create your own entire datacentre network on top of the existing infrastructure without modifying any underlying hardware. This is especially valuable in clouds where multiple tenants, be them individuals or business units, need network independence, isolation, and autonomy. Overlay SDN lets the underlying network or cloud operator offer network independence to its consumer.

Hardware / underlay SDNHardware-based SDN solutions alleviate many of the issues and constraints with traditional networking hardware. The management – control plane, of the hardware is separated from the physical hardware itself – the data plane. This means a generic network switch can have features and functions dynamically loaded in real time to change how it operates and what its capabilities are.

A single physical device can replace several, legacy network devices. This can reduce the need for port undersubscription and by programmatically adding functions to devices with open ports, reduces port oversubscription, as well, allowing better balance of traffic universally across generic network ports.

9

Tweet this

CTO’s guide to SDN, NFV and VNF

Traditional datacentre networkingBefore server virtualisation was commonplace, every server had a single operating system, typically a single application, and connected to one or many legacy switch ports.

Network control and data flow are all managed at an individual switch level. Further, every network component throughout the network infrastructure, from routers to advanced network services like load balancers, is locally and individually managed.

Two major issues are revealed:

1. The control of the network equipment is tied to each device

2. Network equipment capability is fairly inflexible

Server virtualisation introduces SDN

legacy switch

legacy switch

server

10

Tweet this

CTO’s guide to SDN, NFV and VNF

Virtual switches provide SDN to virtual machines – VMsThe advent of server virtualisation, for most organisations, was the initial introduction to software defined networking – SDN. As the diagram illustrates, multiple operating systems are running as virtual machines on a single server. Each of these virtual machines has software defined network adapters that connect to a software defined, virtualised network switch.

The control and data planes for these virtual machines are now managed at the server level on commodity hardware, but the rest of the network remains running traditional hardware.

virtual machine

virtual switch softwareserver

11

Tweet this

CTO’s guide to SDN, NFV and VNF

Server virtualisation datacentre networkingSince server virtualisation only provides SDN capabilities for the VMs contained on each individual server, the 2 major issues with traditional networking remain:

1. The control of the network equipment is still tied to each device

2. Network device capability remains fairly inflexible

Continuing to evolve SDN

serverload banalcer

virtual machine

virtual switch software

legacy router

legacy switch

server

virtual machine

virtual switch software

12

Tweet this

CTO’s guide to SDN, NFV and VNF

SDN for datacenter network infrastructure• Decrease capital and operational

expenditure

• Decouple the management – control plane, from the device itself – data plane, whereby centralising network control

• Tremendous increase in flexibility and deployment of programmable network infrastructure and network functions

server

virtual machine

virtual switch software

generic SDN switch

server

virtual machine

virtual switch software

VNF servers 1 to Many

router

load balancer

firewall

VPN

13

Tweet this

CTO’s guide to SDN, NFV and VNF

Commodity server SDNSince commodity servers can now serve as part of the network infrastructure, their SDN functionality is leveraged in different ways.

As illustrated on the page Server virtualisation introduces SDN, virtualisation of servers has made local, virtual switching a popular SDN implementation. Some virtual switches have control software that allows them to be managed centrally and decouple the control plan from the local host itself.

FAN networkingAnother local-to-server SDN solution is Fan Networking. Fan provides an IP address extension capability to Linux containers, like LXD, to increase density of workloads without sacrificing network performance or network addresses.

SDN infrastructure layers

SDN core and OpenStack NeutronCommodity servers also serve as SDN core nodes. These servers are not typical virtualisation hosts, but rather host specific software that enable SDN functionality for datacentre infrastructure. These could be control nodes, core gateways, routers, etc. Advanced SDN solutions like PLUMgrid ONS or Juniper Contrail use redundant and hierarchical servers to provide advanced networking and overlay networking capabilities.

OpenStack Neutron is an example of an SDN control node. Neutron uses plugins to communicate directly with SDN overlay solutions like ONS and Contrail to provide user-serviceable, independent network infrastructure to respective cloud tenants.

Commodity network hardware SDNThere is a growing ecosystem of generic network hardware. These are devices that look like traditional switches or routers, but are software-enabled by a 3rd-party. Ubuntu Core is a general purpose IoT operating system that you would install on generic network hardware, and then potentially make it a layer two or three switch, or advanced gateway or firewall, by installing additional network software as Snaps.

The Open Compute Project has specifications for networking that help define how generic network hardware should be designed and manufactured. Open Compute network hardware is like commodity servers, except there are more network ports and more focus on network throughput than general compute.

14

Tweet this

CTO’s guide to SDN, NFV and VNF

NFV infrastructure – NFViThe NFV concept is newer than SDN. While SDN focuses on network hardware and the separation of the data and control planes, NFV refers more to application and network specific functions. NFV infrastructure defines all of the components, software and hardware, that enable NFV for a given solution or organisation.

Virtualised Network Functions – VNFVNF refers to the functions that are being virtualised in an NFV infrastructure. Like SDN, this means that functions that used to be delivered by proprietary, stand-alone devices, are now being written as software that runs on Linux (like Ubuntu) on industry standard, commodity hardware.

Network functions virtualisation – NFV

NFV deployment and architectureNFV infrastructure can be deployed using traditional network switching infrastructure, or with SDN, or a combination of the two. At present, combined SDN/NFV/traditional infrastructure is most common, although the components of the network core that support NFV are most often SDN-based.

Ubuntu

legacy router

open compute SDN switch

open compute SDN switch

Ubuntu

UbuntuCore

Ubuntu

Ubuntu

virtual switch software

virtual switch software

UbuntuCore

15

Tweet this

CTO’s guide to SDN, NFV and VNF

Open Compute Project (OCP)The OCP provides specifications and design documents for servers, racks, and, of course, network switches. The designs naturally create standards for the industry to follow.

The network hardware from OCP has dedicated chips for passing data, and more ports than a typical commodity server, but offers commodity processors and memory subsystems that run standard Linux operating systems like Ubuntu Core. The functionality of the hardware is enabled by software from industry network vendors. The management of the software is not integrated to the hardware at all, and is generally centralised on control nodes wherenetwork administrators can centrally configure, monitor, reconfigure, update, and even upgrade the infrastructure.

General purpose network hardware

Ubuntu Core“Snappy” Ubuntu Core is a general purpose IoT operating system. It is a lightweight, transactional-based OS, making it ideal for running OCP switches. Ubuntu Core is based on the concept of “Snaps”. A Snap is an independently contained, isolated application.

Snaps install from a web store interface, providing network operators a revenue or organisational chargeback opportunity. There are Snaps available that enable layer 2 switching, firewalls, routers, gateways, and more network functionality. They provide a software-modular approach to network hardware. If a device requires additional or less – decommissioned, functionality, it’s easily achieved by adding or removing a Snap.

Since both Ubuntu Core and the Snaps it installs are transactional, automatic roll-back occurs if there’s a problem. The inherently isolated nature of a Snap also means that there is the highest level of security.

Ubuntu Core on OCP hardware• Revenue or chargeback opportunity

• Highest availability

• Isolation and security

• Versatile functional

• No-touch field upgrades

16

Tweet this

CTO’s guide to SDN, NFV and VNF

Generic switch hardwareGeneric switching hardware bridges the gap between SDN and NFV on commodity servers and traditional switches. Generic switches provide similar port capacity and ASIC throughput to that of a traditional switch with the management and deployment benefits of SDN. They can also run some VNFs like firewalls and load balancers to further increase their value.

Generic switch hardware and SDN on servers

Commodity server hardwareServers have physically limited port count, restricted by total network adapter ports. But internal connections – ports, become virtual – unlimited, and functions are only bound by physical hardware constraints – CPU, memory, throughput. They offer all of SDN and can run any VNF available.

You need bothCommodity servers provide great flexibility and performance, but they need a top of rack or centralised switch to efficiently communicate. Traditional switching could achieve the goal but modern, SDN-based switches extend dynamic network management and configuration beyond the reach of commodity servers and traditional switches.

open compute SDN switch open compute SDN switch Ubuntu Ubuntu

Ubuntu Core

UbuntuCore SDN

softwareSDN

software

17

Tweet this

CTO’s guide to SDN, NFV and VNF

Modern infrastructureWhile the simple answer is no, you don’t absolutely need a cloud to use SDN or NFV technologies, you probably already have a cloud or are working on a cloud initiative. In general, SDN and NFV infrastructure run as microservices, and those microservices are best served by clouds, like Ubuntu OpenStack.

Do I need a cloud for SDN and NFVi?

Cloud benefitsA well-designed cloud gives you rapid scaling, dynamic deployment, and workload bursting beyond your premises. It can also allow departmental, development and operational self-service. All of these capabilities can be employed by SDN and NFV infrastructure solutions.

Realising the economic and technical benefits of a cloud requires standardisation and repeatability. Juju, discussed later in this eBook, helps an organisation achieve those goals.

18

Tweet this

CTO’s guide to SDN, NFV and VNF

The platformAs the Why Now? page of this eBook suggests, Ubuntu is the platform of choice for SDN and NFV infrastructure. Ubuntu is the basis for Ubuntu OpenStack and for hyperscale cloud computing.

More than 65% of large OpenStack clouds run on Ubuntu. Ubuntu hosts more OpenStack cloud workloads than all other operating systems combined.

The growing ecosystem of SDN and VNF software is built for deployment on Ubuntu.

Ubuntu for hyperscale

Scalable financial model that eliminates the cost-prohibitive pain points of starting small and growing big. Ubuntu Advantage for OpenStack, which provides premium support from Canonical, is priced with the economical understanding of a hyperscale datacentre.

Scalable architecture from the kernel to the tools used to manage applications on Ubuntu, when features are implemented, they’re all done with cloud scalability in mind. Technologies like the LXD container hypervisor and FAN networking increase density of services on physical servers. They also both have scalable management interfaces, to support hundreds of server nodes as your cloud grows.

Scalable services include offerings like BootStack, a managed, hosted Ubuntu OpenStack offering. BootStack scales to hundreds of nodes, and includes OpenStack training options, and optional SLAs. There is also the option to completely transfer management and control of your BootStack environment to your own qualified, operations staff.

19

Tweet this

CTO’s guide to SDN, NFV and VNF

Design and deployThe migration from single purpose physical assets to virtualised and software assets creates the need for a tool to design, deploy and manage the SDN and VNF infrastructure.

Juju is an application modeling and deployment tool. It uses the concept of Charms to make the components of an SDN or VNFs intelligent. By distilling the intelligence into each individual component, design and deployment are simplified and standardised. Instead of relying on teams of consultants to customise and deploy each component, Juju can package multiple Charms into bundles that can be deployed with consistency across multiple regions and architectures.

Deploying and managing SDN and VNFs

Modify and updateSeldom does a modern SDN or VNF deployment remain static. Since the bundles that Juju deploys are built from individually intelligent Charms, it makes it relatively easy to interchange or update specific components. It also makes it easy to roll back to a previous bundle if things don’t go as planned.

Modifications and updates can be accomplished without the need for expensive consultants, complex static scripts, or total redeployment of the solution.

20

Tweet this

CTO’s guide to SDN, NFV and VNF

CompatibilitySDN offers tremendous benefits in flexible configuration options and improved methods of data routing. It’s important that applications work well in various SDN environments. Canonical’s OpenStack Interoperability Lab – OIL is able to run continuous integration testing against multiple different SDN solutions with various different workloads utilising their networking paths. OIL ensures that modern big data, analytics, and other cloud-based solutions are compatible with modern network infrastructure.

Performance and Interoperability

Performing wellBeyond interoperability, Canonical has benchmarking capabilities that allow you to understand where your solution, SDN, NFV, or just a regular application, runs best. Canonical’s Automated Benchmarking Service – CABS is capable of running the exact same workload across multiple different clouds, including your own, and reporting back relative performance. Since SDN and NFV infrastructure can stretch beyond your datacenter, into a public or external private cloud, it can be important to have performance baselines across multiple locations and solutions.

VNF performance – V-PILV-PIL is the VNF Performance and Interoperability Lab. It is another performance testing solution, but focused solely on VNFs. Typically, many VNFs work together in a service chain. Since many VNFs are latency and throughput sensitive, the VNF Performance Interoperability Lab is able to automate test cases of service chained VNFs and compare the results against a functionally similar service chain that utilises different VNFs.

V-PIL takes the guesswork out of deciding on which VNF to use for a specific function, from both an interoperability and a performance perspective.

21

Tweet this

CTO’s guide to SDN, NFV and VNF

Emerging standardsMany networking standards are derived from the telecommunications industry. Canonical has been an early adopter and supporter of emerging telecoms standards, including OSM and OPNFV.

OSMCanonical is a founding member of Open Source MANO – OSM. It is a reference architecture for management and orchestration of NFV infrastructure based on ETSI standards and open source solutions. Along with Ubuntu and Ubuntu OpenStack, Canonical’s modeling and application deployment tool, Juju, are all part of the initial OSM reference architecture.

Canonical, SDN and NFVi leadership

Juju as a generic VNF managerJuju plays a vital role as a generic VNF manager for OSM. It enables the use of multiple VNFs without disparate VNF management solutions. Since it’s a generic modeling tool, it can also model and deploy the OpenStack infrastructure, as well as additional services on top, like big data processing, analytics, container management, and more.

OPNFVCanonical also supports OPNFV, the Open Platform for NFV. The project’s goals are to provide consistency and interoperability between NFV vendors. As discussed on the Performance and interoperability page of this eBook, Canonical is also aligned with OPNFV’s goals.

Canonical ecosystemWorking with networking leaders, like Cisco, Juniper, PLUMgrid, Telefonica, and dozens more, Canonical’s rapidly deployable ecosystem of solutions is unequaled.

The unique ability of Juju to quickly model, deploy, and integrate all the components of a complex SDN or NFV infrastructure comes from Juju’s use of Charms. Charms give an application the intelligence to both ask for the resources it needs, as well as offer the resources it provides, and automatically connect it to other Charmed applications. Using the Juju Charms approach, an entire OpenStack cloud, SDN overlay solution, or NFV infrastructure, can be deployed in less than an hour.

22

Tweet this

CTO’s guide to SDN, NFV and VNF

Natural evolutionThe industry transition from single function, proprietary devices, to commodity, software defined infrastructure is a natural one. Economics have driven it, technological advancements have enabled it.

It will become impossible to remain competitive without SDN and NFV infrastructure. Every organisation will have to transition. IT departments for non-technical organisations, telecoms operators, and cloud service providers will all benefit from software based network infrastructure. Even cloud-based businesses already use SDN overlays every day.

Conclusion

ExperienceCanonical has been the infrastructure for the modern network of some of the world’s largest telecommunications providers. The Ubuntu family of solutions, Ubuntu, Ubuntu OpenStack, and Ubuntu Core, provide an economical, stable, and secure platform for next generation, software defined networks and network functions. From Canonical’s Charm Partner Program, enabling the largest SDN/VNF ecosystem available, to a commitment to standards, like OSM and OPNFV, the long term, demonstrated investment is clear.

Customers, Network veterans, and startups, all choose open systems, standards, and interoperability. Canonical does, too.

To learn more, visit

Ubuntu OpenStack

Scalable clouds and infrastructure

Ubuntu Core Contact us

CTO’s guide to SDN, NFV and VNF23

Tweet this

At Canonical, we are passionate about the potential of open source software to transform business. For over a decade, we have supported the development of Ubuntu and promoted its adoption in the enterprise.

By providing custom engineering, support contracts and training, we help clients in the telecoms and IT services industries to cut costs, improve efficiency and tighten security with Ubuntu and OpenStack. We work with hardware manufacturers like HP, Dell and Intel, to ensure the software we create can be delivered on the world’s most popular devices. And we contribute thousands of man-hours every year to projects like OpenStack, to ensure that the world’s best open source software continues to fulfil its potential.

About Canonical