SDN and NFV Takeaways from Light Reading’s Network Components conference in Santa Clara

Introduction:

For years, we’ve been reading and hearing about the never-ending boom in data traffic, the need for fast provisioning, agile networks, service velocity (quicker time to market for new services) for telcos, etc.  It’s been like a non-stop siren call to battle for network operators.  Yet little has been done to date to remedy the situation.

At the Nov 6, 2014 Light Reading Nex Gen Network Components conference in Santa Clara, CA, Heaving Reading analyst Simon Stanley echoed a familiar solution. He said that SDN and NFV will permit network equipment vendors and telecom carriers/ISPs to keep up with rising traffic demand, reduce OPEX, and create more flexible networks.

Standard platforms form the foundation for network hardware, Simon maintains. “Above that you’ve got a virtualization layer that essentially applies virtual resources,” Stanley said. “Instead of accessing real compute, storage and networking, these resources have become virtualized+. That gives you significant flexibility,” he added.

+ Note: The above remark assumes that the version of SDN chosen is the “overlay model,” which virtualizes or overlays the physical network.  The “classical version of SDN,” adopted by the Open Networking Foundation (ONF), doesn’t do that at all. Instead, it proposes a centralized SDN Controller which implements the Control Plane (i.e. calculates end to end paths) for many Data planes which are often called “data/packet/frame forwarding engines” that run on commodity hardware called “bare metal switches.” There is no overlay or network virtualization in classical SDN.

A representative from Advantech said that on 100 Gbps ports, virtual network functions do not scale well on commodity hardware, which results in cost inefficiencies with waste of data center or central office space and excessive energy consumption.  As no single server can handle the millions of flows embedded in a single 100GbE pipe efficiently, distributing network traffic will become an issue in a virtual infrastructure.

At the conference, Advantech announced a new 100GigE hub blade, which switches traffic between two external 100GigE CFP2 ports, up to eighteen external 10GigE SFP+ ports and twelve 40G node slots on an ATCA backplane.

An Expert’s View of SDN and NFV:

Here’s how Orange’s Christos Kolias, PhD defines SDN and NFV:

• SDN: Abstraction of the control plane from the data plane. Key benefits are: separates control from data forwarding functionality, Network Programmability, Network Virtualization, and Intelligent Flow Management.

• NFV: Abstraction of network functions from (dedicated) hardware. Key benefits are: elasticity, agility, scaleability, versatility, and savings on CAPEX/OPEX.  The NFV Concept, according to Christos, is illustrated in the figure below.

NFV Management and Orchestration:

“NFV is all about how you can manage and orchestrate all these new virtualized appliances,” Kolias said at the conference. Yet the ETSI NFV Industry Specifications Group (ISG), which Kolias co-founded and participates in,  hasn’t yet specified what that management and orchestration should be or the APIs that interface to such software entities.  Christos says, “It is important for the NFV community to agree on some Management & Orchestration (MANO) specification with emphasis on the interfaces and the APIs.”  Christos thinks “Openstack is a good open-source alternative for the MANO.”

SIDEBAR:  In a presentation at an IETF meeting, Mehmet Ersue, ETSI NFV MANO WG Co-chair, provided the following examples of Virtual Network Functions (VNFs) that might require MANO:

• Switching: Broadband Network Gateway (BNG), Carrier Grade-Network Address Translation (NAT), IP routers.
• Mobile network nodes: HLR/HSS, MME, SGSN, GGSN/PDN-Gateway, RNC.
• Home routers and set top boxes.
• Tunneling gateway elements (e.g. VxLAN).
• Traffic analysis: Deep Packet Inspection (DPI).
• Signalling: Session Border Controllers (SBCs), IP Multimedia Subsystem (IMS).
• Network-wide functions: AAA servers, Policy control.
• Application-level optimization: CDNs, Load Balancers.
• Security functions: Firewalls, intrusion detection systems

Importance of NFV Service Chaining:

Many industry analysts think that service chaining* (the scheduling of multiple virtual appliance based services) is the key to automating a NFV/NVF based network. How will that be achieved?  So far, there’s no standard or specification for that functionality.  Christos doesn’t think OpenStack is a solution for that.  What is?

* Note: Christos prefers the term “service composition and insertion” to service chaining, which seems to be a more accurate description.

What Type of Special Hardware is Needed for NFV?

Another key question is what new or different hardware is needed for NFV “virtual appliances,” which will run on a generic compute server (likely built by ODMs) with commoditzed hardware. At the conference, Christos told me he thinks some type of hardware assist will be necessary, but he didn’t specify what functions would be implemented in hardware or where they might be located.  That was later clarified in an email discussion which is summarized below.

Several industry participants (e.g. Microsoft) think the compute server’s NIC(s) should be augmented to include hardware assist functions like protocol encapsulation/de-encapsulation, encoding/decoding, deep packet inspection, protocol conversion (if necessary), and some security related functions.  Christos says these should not be too “compute intensive.”

“Off-loading processing to the NIC cards could include things related to packet processing (encapsulation, encoding/decoding and may be some security-related functions) – in general not compute intensive,” he added.

Kolias believes that “Data (packet forwarding) plane acceleration could he handled by hardware acceleration,” although exactly what that hardware actually does remains to be seen. It’s important to note that the Data plane is NOT implemented in a compute server for SDN, but rather in a “bare metal switch” built from commodity hardware/SoCs and other off the shelf silicon.

The drivers, challenges, and potential applications for NFV are illustrated below (from Kolias’ presentation):

In addition to the challenges listed in the above figure, another huge concern for NFV implementations will be security. When individual physical box appliances are replaced by virtual appliances running on a compute server, the attack service for threats and malware increases exponentially. How will that be dealt with and how will security functions be partitioned between software and hardware?  No one seems to be worried about this now, despite increased cyber attacks in recent months and years.

The Myth of NFV Compliance:

This author and Christos wonder how ANY vendor can claim to be “NFV compliant” when there are no NFV standards/specifications in place and no testing/interoperability facility to provide the certification of compliance.   Yet those false claims have been the norm for over two years!

This author believes that without solid NFV standards/specifications AND multiple vendors passing some certification/compliance test there will be no interoperability, which defeats the purpose of all the work the ETSI NFV ISG has done to date in producing architecture reference models, functional requirements, proof of concepts, etc.

An Open Platform for NFV:

Perhaps, as step in the right direction is the formation of the Open Platform for NFV (OPNFV) – a Linux Foundation collaborative project. Here are the stated OPNFV Project Goals:

• Develop an integrated and tested open source platform that can be used to build NFV functionality, accelerating the introduction of new products and services.
• Include participation of leading end users to validate OPNFV meets the needs of user community.
• Contribute to and participate in relevant open source projects that will be leveraged in the OPNFV platform; ensure consistency, performance and interoperability among open source components.
• Establish an ecosystem for NFV solutions based on open standards and software.
• Promote OPNFV as the preferred open reference platform.

We’ll be watching this industry initiative closely and reveal what we learn in subsequent articles covering NFV.

Yet we wonder where innovation will come from if the new network paradigm is to use open source software running on commoditized/open hardware. Where’s the value add or competitive differentiation between vendors and their “open” SDN/NFV products?

Intersection of SDN and NFV: 

The figure below depicts how Christos believes SDN and NFV might work together to achieve maximum benefit for the network operator and its customers.

In summary, Christos says that both NFV and SDN enable the “softwarization” of the network. Like so many others, he says that software is king and does eat everything else.  Acknowledging security threats, he cautions “beware of bugs and hackers!”