Network functions virtualization (NFV) has garnered a great deal of attention in the carrier community, grabbed headlines in the media, and even spawned a set of conferences seeking to capitalize on the momentum. In a mere six months, the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) on NFV has emerged as the largest ISG in ETSI. At the July 24-26 meeting in Bonn, 25+ operators and 245 delegates convened for NFV meeting No. 3.

NFV would enable network operators to virtualize network functions currently deployed on proprietary, and increasingly costly, hardware-based appliances that, as the NFV white paper states, “inhibit the rollout of new revenue-earning network services and constrain innovation in an increasingly network-centric, connected world.”

In actuality, many of the original carriers that proposed the NFV initiative had already begun working on virtualizing network functions long before the NFV ISG was conceived. Operator expectations for the benefits of NFV that may be realized in the near to intermediate term (one to three years) include:

• Improving time-to-market for new services by minimizing the typical network operator cycle of innovation.
• Optimizing resource utilization to reduce equipment cost, space, and power consumption.
• Improving operational efficiency through automation and intelligent platforms.
• Achieving elasticity and scalability to address the dynamic demands imposed in the multi-tenant environment.
• Encouraing openness to enable multi-vendor interoperability of hardware and software.

Sound familiar?

NFV shares several common benefits with software-defined networking (SDN), at least from the 15,000-metre view. Both NFV and SDN have been driven by a notably strong end-user following and as a result enjoy strong vendor support. In addition, both are based on a compelling value proposition realized by virtualization, which enables capex and opex reduction, as well as improved differentiation and agility. And NFV and SDN represent architectures that will not be fully standardized themselves.

However, SDN and NFV address very different problems and are not initially dependent upon one another, a point that was explicitly reiterated in the NFV white paper. Whereas SDN is focused on exposing unprecedented programmability and virtualization of network devices, NFV is concerned with the virtualization and consolidation of network appliances. SDN promises to automate the orchestration and configuration of the network; NFV will automate the deployment and control of the network functions, which will run in a virtualized server platform.

NFV originated from many of the world’s largest carriers' discussions about how to improve network operations as text and email are supplanted by streaming multimedia content. A set of informal discussions and meetings culminated in the drafting of the NFV White Paper at the 2012 SDN and OpenFlow World Congress in Darmstadt, Germany last October, where the group proclaimed their intentions: leveraging standard IT virtualization technology to consolidate many network equipment types onto industry standard, high-volume servers, switches and storage.

By the end of 2012, the NFV ISG was formed in ETSI, primarily to exploit ETSI’s existing administration, processes, and governance model. The initial meeting of the NFV ISG was held in Sophia Antipolis in the south of France in January, with 20+ carriers and 100+ participants. There was an aura permeating that initial meeting hosted by ETSI that the ISG was onto something big, albeit with a daunting task ahead.

Not surprisingly, when the world’s largest carriers band together on their own to do anything, the vendor community will respond. And they have. More than 100 ISG participants whose products span the entire NFV value chain are now participating, along with the 25+ network operators.

By charter, the ETSI NFV ISG was established not as a Standards Development Organization (SDO) but as a body that would specify a broad set of requirements for an NFV platform that can be adopted by diverse network operators whose environments span a wide range of scale, operational, regulatory, and technology requirements. The ISG defined Virtual Network Functions (VNFs) to refer to the network software functionality that is virtualized.

To harness such a large group, the ETSI ISG established an operational structure in accordance with ETSI conventions, depicted below.

Here's what it all means:

• ISG Leadership: ISG Chair: Prodip Sen, Verizon; Uwe Michel, Deutsche Telekom.
• Network Operators' Council (NOC): Guides and oversees all ISG activities; the NOC is limited to Network Operators exclusively. Chair: Don Clarke, British Telecommunications.
• Technical Steering Committee (TSC): provides technical leadership; the TSC consists of the Working and Expert Group leaders (i.e., Co-Chairs and Editors). Chair: Diego Lopez, Telefónica; Vice chair: Tetsuya Nakamura, NTT Docomo.
• Working Groups: Working-level teams for particular NFV functional areas:
  • Architecture for the Virtualization Infrastructure (INF): Addresses the infrastructure requirements for the compute, storage, and network domains.
  • Management and Orchestration (MANO): Addresses management considerations for the NFV platform.
  • Software Architecture (SWA): Addresses the environment that the VNFs will execute.
  • Reliability and Availability (REL): Addresses VNF resiliency and fault tolerance.
  • Expert Groups (EGs) responsible for technical recommendations that span multiple WGs:
    • Security: Responsible for security considerations throughout the NFV platform.
    • Performance and Portability (PER): Addresses scalability, efficiency, and performance considerations when moving from dedicated to generic hardware.

The ETSI NFV ISG is currently focused on three end-to-end documents that form the baseline for subsequent technical working group activities:

• NFV Use Cases: A representative set of service models and high-level use cases that may be addressed by NFV.
• NFV Virtualization Requirements: High-level operational requirements for to achieve the goals of NFV, broken down into the NFV technical domains.
• End-to-End NFV Architecture: A high-level functional NFV framework and reference architecture that ultimately serves to partition out the NFV work activities.

The NFV Use Cases are intended to drive the Virtualization Requirements, which in turn drive the End-to-End Architecture. NFV encompasses functionality in the compute, storage, and network domains. To date, the majority of the effort has been focused on the software virtualization framework, along with management and orchestration. Consequently, limited attention has been paid to the network.

By seeking to leverage cloud methods and technologies, network operators are looking to NFV to deliver significant gains on both the revenue and cost sides of their ledgers. NFV is anticipated to revamp network operations and, in turn, service delivery. With the end-to-end NFV baseline specifications in place, the network will arise as the focal point. But that is the topic of another post.