This is the second in a series of NFV-related postings by Marc Cohn, a delegate to the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) chartered to analyze the NFV requirements. Be sure to check out his first post, NFV, An Insider’s Perspective: Goals, History, and Promise, which introduces NFV and explains the structure of the ETSI ISG.
Over the past few months, I have participated in a number of major SDN events, with plans to participate in several more in the autumn. I have noticed an unmistakable shift from last year. No longer is SDN solely couched in the context of the data center. Service providers large and small, from around the globe, are increasingly sharing their thoughts and plans on SDN. More often than not, such plans encompass not only the network, but network functions virtualization (NFV) as well.
For over two years, network operators have been investigating how they can exploit cloud technologies that have been proven in the data center and enterprise for over a decade, and some NFV proofs-of-concept (PoCs) have been brought to the ISG, which is intent on adapting cloud technologies (and open-source software, such as OpenStack) to the needs of the carrier as opposed to the data center environment. Another proof point is the recent unveiling of the CloudNFV initiative, where vendors are cooperating on an ambitious NFV/Cloud PoC.
But much of the focus of the NFV ISG has been on the lifecycle of virtualized network functions (VNFs), including how they may be orchestrated, operated, assured, managed, and scaled. Scant attention has been paid to the network and SDN.
In fact, the ISG explicitly distanced NFV from SDN, as documented in the NFV White Paper, which is understandable. The pervasive benefits of NFV can be exploited today, while SDN is perceived as being promising, yet too immature for immediate deployment.
Aside from technology debates, a more interesting question has emerged: What are the networking requirements to support NFV? The answer is revealed in the use cases and applications that are driving NFV, near-term, and in the future.
For a number of months, the NFV ISG has undertaken the non-trivial task of establishing baseline NFV requirements by defining NFV use cases, which drive platform requirements, which in turn serve as the basis for the NFV End-to-End architecture.
Table I- Network Function Virtualization Use Cases
|Cloud Use Cases||Mobile Use Cases||Data Center Use Cases||Access/ Residential|
|NFV Infrastructure as a Service (IaaS) (NFVIaaS)||Virtualization of the Mobile Core Network and IMS||Virtualization of CDNs||Virtualization of the Home Environment|
|Virtual Network Functions as a Service (VNFaaS)||Virtualization of Mobile Base Station||Fixed Access Network Functions Virtualization|
|Service Chairs (VNF Forwarding Graphs)|
|Virtual Network Platform as a Service (VNPaaS)|
At the July 2013 meeting of the NFV ISG in Bonn, nine NFV use cases were presented, as summarized in Table I. The scope ranges from the data center to fixed and mobile end-users, including cloud services.
The ISG has avoided making assumptions about the network, defining it as “the totality of all hardware and software components which build up the environment in which VNF are deployed, managed, and executed.” (Source: ETSI NFV ISG GS NFV 009- Network Functions Virtualization; Use Cases)
But closer examination of the NFV use cases in Table I revealed a common set of network assumptions:
- Cloud use cases: require optimized utilization and elasticity to cope with dynamic network demands.
- Mobile use cases: require optimized resource utilization, service availability, and granular policy management.
- Data-center use cases: require elasticity, scalability, and quality-of-service (QoS) to support the explosive growth of multimedia streaming.
- Access networks and residential networks: require rapid provisioning, capex reduction, and resource optimization through consolidation.
These requirements in themselves do not mandate SDN. However, SDN is particularly well suited in addressing these requirements, especially when compared to today’s networks, as indicated in Table II.
Table II- Network Requirements to support NFV Use Cases
SDN vs. Traditional Networks
Predominant Use Cases
|Resource Pooling||Proprietary overlays to provide link aggregation, adding configuration complexity over the static infrastructure||SDN networks facilitate network virtualization and as a result optimize resource utilization and simplify the overall network.||Cloud|
|Improved Scalability||Scalability is typically achieved through over-provisioning||SDN networks are designed to support dynamic behavior and provide elasticity and scalability||Mobile and Data Center|
|Improved Service Availability||Distributed, complex algorithms require hardware support, driving up costs||By logically centralizing network state, alternative paths may be pre-computed to expedite recovery from failures||Mobile and Data Center|
|Multi-Tenancy||Multi-tenancy is typically provided through tunnels, VLANs, and often through physically distinct networks||Multi-tenancy is provided through the flow-based paradigm, which lends itself to granular policy management decoupled from physical objects||Cloud|
|Reduced provisioning times||Orchestration and provisioning remain a manually-intensive, relatively slow process||Extensive automation reduces provisioning times significantly, while reducing manual errors||All|
|Multi-vendor Interoperability||Each vendor’s equipment is managed individually; hardware tends to be proprietary and costly||Open interfaces, APIs, and an open software framework offer unprecedented openness and true multi-vendor interoperability||All|
Software-defined networking enables operators to realize the NFV vision and value proposition, namely:
- Improved service velocity and innovation
- Optimized resource utilization
- Streamlined operations
- Unprecedented openness
SDN is already delivering such benefits for network operators and service providers as well.
How to reap the benefits of SDN remains a challenge. Operators must invest not only in technology, but in their people as well, to prepare them to cope with the transformative nature of SDN. A particularly important consideration is the decision to automate. Replacing tens/hundreds of millions of dollars of installed base of BSS and OSS systems, not to mention people, necessitates a compelling value proposition to act.
Widespread adoption of NFV softens the blow. By deploying NFV orchestration, the fundamental framework to automate the network will be in place. This paves the way to incrementally adopt SDN to support NFV, vs. the alternative of developing “throw-away” code to mask the dynamic behavior of the system from the existing OSS and network management systems.
The people challenges for NFV and SDN are not to be underestimated as manual, craft-sensitive processes are automated and operations are dramatically revamped. Exposing network programmability where it did not previous exist necessitates that networking people become software people for network operators to cross the chasm into the software-intensive NFV/SDN universe.
SDN and NFV offer a synergistic launch pad into tomorrow’s networking landscape, with growing end-user demands, a radically defined competitive landscape, and unbounded potential as the “Internet of Everything” becomes reality. Large operators are beginning to respond, offering hints on their plans for initial deployment of NFV over SDN.
There are a number of encouraging signs: SDN gaining traction with carriers; increasing announcements by carriers and OEMs alike; steady progress in the Open Networking Foundation (ONF) on the standardization, interoperability, management, silicon-ization, and migration fronts; and the recently chartered Optical Transport working group’s efforts to extend OpenFlow to operate with transport networks.
Every quarter, new OpenFlow-based SDN switches and controllers are being launched. Announcement of the OpenDaylight open-source software initiative, backed by many of the networking and telecommunications market’s leading OEMs, will likely accelerate the SDN adoption curve as well. Another positive sign of progress is the steady, yet loosely coupled collaboration between the ONF and the NFV ISG — a role model for the intersection between standards and end-users.
At the next round of events beginning in September, I suspect the questions about the relationship between NFV and SDN may not entirely disappear, but shift to the “when” rather than the “what.”