The 'Internet of Things'

Esmeralda Swartz

Subscribe to Esmeralda Swartz: eMailAlertsEmail Alerts
Get Esmeralda Swartz: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, Network Virtualization, SDN Journal

Article

Close Familial Ties: SDN and NFV | Part 2

SDN and NFV have different origins and different interest groups championing their causes

In a previous blog I took the opportunity to comment on the role of billing in a future of Software Driven Networks (SDN). However, before we get too caught up in the billing component, it might be worthwhile to discuss where SDN itself is going and to tease out some of the distinctions between SDN and its cousin, Network Functions Virtualization (NFV). For those who are not deeply involved in the development of either SDN or NFV, some of the discussions might seem arcane, while some of the distinctions might seem overly subtle.

SDN and NFV have different origins and different interest groups championing their causes. SDN, as I described in the last blog, originated from some interesting thoughts from Stanford and Berkeley. It now has its own organization, the Open Network Foundation (ONF), which is pushing the idea forward. The motivation for this work lies in the understanding that our current telecommunications network architecture is not going to be economically scalable to meet the demands of network users, and that it's about time, conceptually at least, that some of the efficiencies already being achieved in IT through abstraction, modularization and virtualization should be brought into the world of communications networks.

NFV is a service provider initiative that is now established as an ETSI Industry Specification Group (ISG). The original primary goal was to find ways to dramatically reduce network service providers' OpEx and CapEx by virtualizing a range of network functionality and decoupling it from the network elements or appliances that perform network transport and switching. This architectural approach brings some additional benefits, now included in the list of stated goals, such as more rapid service definition and deployment, greater service flexibility and reduced time to market.

The emphasis for SDN is a more efficient and more manageable large-scale network architectures, while NFV is focused on the cost of network devices and appliances and the services those devices support. Both organizations are careful to highlight that the two programs are complementary, mutually supportive and not in conflict. Certainly, NFV concepts can be implemented without the need for wholesale SDN deployment, and SDN can be adopted as an architectural target without getting in the way of NFV.

However, as the two initiatives move forward, some convergence will occur. In fact, it is already happening. There are a lot of companies whose names appear as members or participants in both membership lists. Separating network functions from network devices in accordance with NFV implies the need for some consistent way of communicating between the network functional layer and the physical network: this is exactly the role of the OpenFlow standard, and indeed ONF is working with ETSI to ensure that OpenFlow will meet the NFV requirements. Virtualizing network functions in a way that makes them logically separate from the network hardware, a la NFV, sounds pretty much the same as the SDN push to create a control plane separate from the data forwarding plane. Either way, network functions are abstracted in order to allow them to run on commodity servers using commodity storage with all the benefits associated with that approach: cost reduction, flexibility and superior management.

I would not be surprised if at some point those two programs converge in a more formal manner. However, in the meantime, there may be value in having two parallel lines of thought and technical exploration brought about by those two parallel programs.

Right now, we all need to plan on the understanding that the general approach characterized by both SDN and NFV is the only vision around that has traction. Both these programs will evolve and change shape, but one principle should be clearly understood: before long, the "network" (the SDN data forwarding plane) will be simplified and somewhat dumb, and the intelligence, such as it is, will then exist in a consolidated management layer (the SDN control plane) running on large scale commercial off-the-shelf hardware (also known as "merchant silicon").

From the control plane level, the packet-carrying network below will look pretty much like a single giant switch responding to programming and instructions from above and sending back usage records and performance parameters to the management systems.

Above the control plane will sit the application layer, and that is where the BSS/OSS applications, including billing, will sit, along with a plethora of other apps that provide higher-level functionality for the business.

A continuous cascade of triggers and information will pass between the network and billing applications via the control plane. What difference will that make to billing? Won't it just work in pretty much the same old way? After all, a chargeable event will still be a chargeable event. Won't it?

I don't think so. I'll explore this further in my next blog.

More Stories By Esmeralda Swartz

Esmeralda Swartz is VP, Marketing Enterprise and Cloud, BUSS. She has spent 15 years as a marketing, product management, and business development technology executive bringing disruptive technologies and companies to market. Esmeralda was CMO of MetraTech, now part of Ericsson. At MetraTech, Esmeralda was responsible for go-to-market strategy and execution for enterprise and SaaS products, product management, business development and partner programs. Prior to MetraTech, Esmeralda was co-founder, Vice President of Marketing and Business Development at Lightwolf Technologies, a big data management startup. She was previously co-founder and Senior Vice President of Marketing and Business Development of Soapstone Networks, a developer of resource and service control software, now part of Extreme Networks.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.