This article will examine network operator motivation for “Service Provider SDN,” and then raise the question whether the solution might be some form of Network Virtualization instead of the ONS SDN-Open Flow standard(s). We reference VMware’s version of Network Virtualization which is currently available and will soon be enhanced. The ETSI Network Functions Virtualization (NFV) activity is described and properly positioned, especially in light of mis-leading vendor support claims.
A follow up article will summarize the new ONF Optical Transport WG and Ciena’s committment to SDN-Open Flow standards in their packet optical product line.. We will examine the relationship between ONF-SDN and ETSI-Network Function Virtualization WG in more detail with input (hopefully) from the ONF on how the two organizations will work together going forward.
What’s “Service Provider SDN” and Why is it Needed?
“Service Provider SDN” is definitely gaining market traction, although it’s not clear if the service providers (telcos, MSOs, cloud networking providers, etc) will require use of the ONS-Open Flow standard, and/or require strict separation of data and control plane in “SDN” networking equipment. They may even skip SDN-Open Flow entirely (as DT has done for now in their SDN pilot -disclosed at ONS 2013) and opt for some form of network virtualization (which is discussed later in this article).
At the recent Open Network Summit, large telcos like Verizon, NTT, DT, Telstra, gave talks on their SDN trials and future projects. Telecom/network equipment vendors Huawei, Ericsson, Ciena, Alcatel-Lucent (Nuage Networks), Cisco and Juniper also made presentations and/or had booths in the exhibit hall. Ericsson and Telstra talked about “Service Provider SDN” in their presentation (which may be available as a pdf or video).
The telco motivation for a software defined and controlled network is to improve operational efficiency. That includes: quicker provisioning of new services and facilties, dealing with exponential traffic increases, dynamically allocating bandwidth to customers, coping with network reconfiguration, customer moves and changes, giving applications more visibility into the network state, and others.
A recent ONF white paper, “Operator Network Monetization Through OpenFlow™-Enabled SDN ONF Solution” provides ample justification for the SDN (or network virtualization) approach to networking by describing the many challenges that network operators face in today’s competitive business environment.
“Smart devices, video content, and cloud services are all generating double-digit growth in network traffic. Operators, however, are still locked into cost-avoidance strategies, bearing most of the costs and risks of maintaining and upgrading the network but with little ability to monetize this new network traffic. Declining average revenue per user (ARPU), market saturation, and a volume-based subscriber acquisition model combined with intense competition from over-the-top (OTT) services are all leading operators to the inescapable conclusion that the future lies in new services and experiences.”
“In order to extract the full value of their core asset, the network, operators must drive a customer-centric market shift, moving from commoditized connectivity services to leveraging subscriber and network intelligence for service innovation and new business models. But legacy networks are inflexible, static, and closed to innovation. This severely limits the operator’s ability to cost-effectively respond to the scale, performance, and user experience requirements of today’s dynamic environments, or to roll out differentiated services.”
Will Service Provider SDN be based on Network Virtualization or the ONFs SDN-Open Flow standard(s)?
As per the above arguments, a new software based network architecture is urgently needed. The critical question is will that be based on SDN-Open Flow or some form of Network Virtualization?
- VMware has described their version of Network Virtualization at many conference presentations and in this Design Guide.
- Alternatively, service providers might base their network virtualization requirements on the outputs of the ETSI Network Functions Virtualization (NFV) Industry Specification Group (ISG).
The carriers that formed the ETSI NFV ISG produced an excellent White Paper which provides an introduction, benefits, enablers, challenges and a “Call for Action.” But the work is just getting started, as the ETSI NFV group was only formed in mid January of this year. At that time, AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefonica and Verizon were joined by 52 other network operators, telecoms equipment vendors, IT vendors and technology providers. The formation of this new ETSI NFV ISG was announced in a January 22nd press release.
The ETSI NFV ISG will NOT produce any standards. Instead, they will focus on whitepapers and contributions to ITU-T SG13 work on Future Networks. All the documents are available at: http://portal.etsi.org/portal/server.pt/community/NFV/367
A recent article compares NFV with SDN and includes an informative table which summarizes the similarities and differences.
NFV Support by Network Equipment and Silicon Vendors
What was mind blowing to this author were the number of vendors on the Open Network Summit exhibit floor that were claiming NFV support and capabilities in their new equipment. In fact, Intel announced a set of three products that supposedly support NFV as per this press release
“The new (Intel) reference architectures combine open standards for SDN and NFV with industry-leading Intel hardware and software to enable networks to be more agile and intelligent so they can adapt to changing market dynamics.”
But here’s the catch: You can’t support an “open standard” till it exists! As one might expect, the ETSI NFV WG is not close to producing any standard, which would have to be forwarded to ITU-T as a new work item before it had international recognition. Moreover, the new ETSI NFV WG is developing requirements and architecture for network virtualization, rather than an implementable specification, e.g. protocol, physical interface, API(s), etc.
The aforementioned press release states:
“The ETSI Industry Specification Group for Network Functions Virtualization (ISG NFV) will develop requirements and architecture specifications for the hardware and software infrastructure required to support these virtualized functions, as well as guidelines for developing network functions. This effort will incorporate existing virtualization technologies and existing standards as appropriate and will co-ordinate with ongoing work in other standards committees. The first specifications are expected before the end of 2013.”
Comment and Analysis:
We think it’s preposterous for network equipment or silicon vendors to claim support for an “open NFV standard” which doesn’t exist and won’t specify anthing implementable for quite some time!
Nonetheless, we are quite impressed with ETSI NFV as a carrier driven standards activity, which makes it very likely to be deployed in production networks. Compare that effort with other networking standards that were developed mostly by vendors, based on perceived carrier needs, e.g. OIF UNI (AKA IETF GMPLS) for optical control plane.
For more on the Open Network Summit, please visit:
and my summary at: