Most industry watchers agree that the networking industry is transforming from a hardware-centric approach to a software-driven model. A few analysts are using the word metamorphosis to describe the scope of this transformation. As you will recall from your high-school biology class, metamorphosis means a profound change in form, as in from a caterpillar to a butterfly. While it is difficult for the capital-intensive telecommunications and enterprise networking worlds to morph overnight, there is no doubt that these industries are going through a disruptive change rather than incremental changes more typical of the last 20 years.

For disruptive change to occur, two forces must be clearly visible. First, market trends must illustrate that the current approach to building solutions cannot be incrementally improved to meet the customer demands of the future. Today, it is clear that the proprietary hardware-centric approach to today’s communications infrastructure cannot cost-effectively handle the huge forecasted growth in data traffic and the explosion in the use of more demanding technologies such as video. It is also difficult, time consuming and far too costly to develop, trial and deploy new applications; in effect, innovation critical to the success of any industry is stymied in the networking world. Secondly, new technologies and solution architectures must demonstrate that they address the problems with the current solutions, cost-effectively meet future market needs and allow for a managed transition to the new technologies.

The transformation of today’s networking infrastructure into a more robust, cost-effective solution that supports rapid innovation includes two key elements: first, the move away from customized, propriety hardware platforms to lower-cost, industry-standard platforms with features that support communications functions and, second, the transition to a software-driven network architecture that is inherently more flexible and enables rapid innovation. Two software technologies are driving the transition: Software Defined Networking (SDN) which makes it easier to build and efficiently manage large complex networks and Network Functions Virtualization (NFV) to increase telecom network resource utilization while reducing the costs associated with developing, trialing and deploying new services.

Software Defined Networking

There is some confusion surrounding the use of the term “SDN”. In the early stages of the discussion, SDN was used synonymously with OpenFlow, a new standard communications protocol between the control and forwarding layers of a software-driven network. Current definitions take more of an architectural view in which SDN refers to all of the protocols and technologies that work to create a global view of the network and provide for centralized, intelligence-based network control.

The Open Networking Foundation (ONF) is the organization dedicated to the promotion and adoption of Software-Defined Networking (SDN) through open standards development. ONF defines Software Defined Networking as “an emerging network architecture where network control is decoupled from forwarding and is directly programmable. This migration of control, formerly tightly bound in individual network devices, into accessible computing devices enables the underlying infrastructure to be abstracted for applications and network services, which can treat the network as a logical or virtual entity.”

Stated slightly differently, SDN abstracts the underlying infrastructure of the network so it can be treated as a logical or virtual entity. In today’s definition, there are three fundamental elements of SDN:  a programmable network with the separation of the control plane and data plane and centralized network management. Figure 1 shows a high-level depiction of the SDN architecture showing the physical infrastructure layer separate from the control layer and applications using an API abstraction to access all network services.

In a software-defined network, traffic is managed from a centralized control point by changing the rules used by any switch in the network when necessary. SDN-related products in the market today include the routers, switches and network orchestration software that utilize programmable network protocol standards such as OpenFlow.

Network Functions Virtualization

As we learned in the data center, virtualization technology can increase resource utilization, thereby reducing CAPEX and OPEX primarily through reduced equipment costs and reduced power consumption. Network Functions Virtualization (NFV) is an initiative driven by the ETSI Industry Specification Group to virtualize network functions previously performed by proprietary dedicated hardware. The goal of the ETSI effort is to reduce the cost of telecom network infrastructure by allowing the appropriate functions to run on a common, commodity platform that hosts the necessary virtualized environments.

Almost any network function can be virtualized. The NFV focus in the market today includes:

  • Virtual Switching – physical ports are connected to virtual ports on virtual servers with virtual routers using virtualized IPsec and SSL VPN gateways.
  • Virtualized Network Appliances – network functions that today require a dedicated box can be replaced with a virtual appliance. Examples include security functions such as firewalls and gateways, Broadband Remote Access Servers (BRAS) and LTE Evolved Packet Core (EPC).
  • Virtualized Network Services – examples here are network management applications such as traffic analysis, network monitoring tools, load balancers and accelerators.
  • Virtualized Applications – almost any application you can imagine. For example, there is a great deal of development today for cloud applications, such as virtualized storage and photo imaging services, to support the explosion in tablet and smartphone usage.

The computing infrastructure required to support today’s mobile-device-driven networking world contains an increasing variety of proprietary hardware appliances (Fig. 2). Each network appliance is slightly different in that it is optimized to support its particular function, whether it is traffic management, security or video transcoding. Launching new network services frequently requires adding a new fixed-function appliance, with the risk that this new equipment becomes redundant if the service is not popular with end customers. Finding space and power for the new box can be challenging and the overall lifecycle management of multiple network platforms is complex and costly. Many operators believe that this ‘function-per-box’ model constrains the innovation and deployment of new network services and reduces ROI.

A standard approach to the virtualization of network functions works to reduce these challenges by allowing the consolidation of proprietary network platforms onto industry standard, high-volume servers. The ability to deploy virtual versions of network functions on standard hardware anywhere in the network eliminates the need to install new equipment and greatly simplifies network management.

In addition to CAPEX and OPEX reductions, NFV works to reduce time-to-market of new services and provides greater scalability (up or down) of individual services. Being standards-based creates a more open virtual appliance market allowing for new entrants and greater innovation.

SDN and NFV: Related and Complementary

In the software-driven networks of the future, SDN and NFV technologies are complementary in that they address different elements of a software-driven solution. SDN increases network flexibility through holistic management of the network, enables rapid innovation and lowers operating expenses. NFV works to reduce network operator CAPEX and OPEX through reduced equipment costs and reduced power consumption. NFV also reduces complexity and makes managing a network and deploying new capabilities easier and faster. It is interesting to note that the highest interest in SDN technology is in data center and cloud computing arenas while telecom carriers are driving many of the NFV efforts. SDN and NFV are indeed driving the transformation of today’s networks.


CloudNFV: an early multi-vendor Proof-of-Concept for NFV

NFV expands the playing field of conventional networking in a number of key ways.  First, service components are individually addressed elements, which can raise the complexity of a “service” by creating many more cooperative element relationships and addresses.  Second, services are likely to be more extemporaneous, so they have to be easy to build, manage, and tear down as needed. 

The CloudNFV (Fig. 3) initiative is developing a Proof-of-Concept (PoC) that includes these participating companies: 6WIND, CIMI Corp, Dell, EnterpriseWeb, Metaswitch, Overture, and Qosmos. It addresses these issues in 3 ways:

  • CloudNFV presumes cloud-based deployment of virtual functions on an OpenStack model (other cloud models can also be supported), so that proven concepts of cloud scalability and tenant separation are incorporated into NFV without duplicating the vast body of work already in place for the cloud.  The architecture is so cloud-like that CloudNFV can deploy cloud application components and built “services” that are a combination of network features and application features.
  • CloudNFV uses a dynamic management model called “derived operations” that allows fully distributed management of virtual and real network resources in any combination, based on any arbitrary management interface.  This means that CloudNFV can be managed by any system currently managing network services, but also that new and more convenient management models can be constructed.
  • CloudNFV defines network connections, both within a virtual-function set and between users and service components, using an agile Connection Model Handler concept.  With this approach, any connection relationship can be defined in a “recipe” and built using open or proprietary SDN, legacy network, or combined interfaces.  For example, any OpenFlow controller can be supported with the proper handler and at the same time supplemented by other network APIs as needed to support the installed equipment.

The CloudNFV architecture is open and extensible, and CloudNFV has an integration program and public tutorials and papers to help educate partners on the process of integration.  The work of CloudNFV is being fed back to both the NFV ISG and the TMF to insure conformance with appropriate standards, and also reflects the latest IETF positions on SDN and NFV-related issues.