x
SDN architectures

Will 'Open' Be A Victim or Victor?

The OpenStack Foundation today celebrates three years of work on the open computing platform that helped launch cloud computing and much more.

I honestly don't know if foundations celebrate anniversaries or birthdays -- if it's the former, we should all be looking for tasteful leather gifts to send to the OpenStack Foundation headquarters, perhaps a nice luggage tag given how widespread its reach has become.

It has been interesting to see the impact of organizations such as OSF and the Open Networking Foundation, birthplace of OpenFlow, on the telecom industry's efforts in the cloud services and virtualization arenas. The rapid pace of the work and the dedication to openness are positive influences in an industry segment not known for either.

But I think the greater challenge for the telecom industry lies ahead, as it addresses its own IT issues around introducing software-defined networking (SDN) and network functions virtualization. Over the next few weeks, Light Reading will be taking a much closer look at what is required to either fit virtualization into the current Operations Support System/Business Support Systems or reconfigure those systems to work with SDN/NFV.

As my Heavy Reading colleague Ari Banerjee noted here in his recent blogs and in a July 2013 report, Service Assurance in SDN and Cloud, virtualization puts new demands on operating systems to cut across the multiple silos of today's support systems to provide a single centralized view of subscribers, their services, applications and devices and the network resources in use to deliver these. (See Service Assurance Challenges in SDN & Cloud Era and SDN Nirvana Still a Distant Dream (Part 1).)

So my first question is, can telecom stick to the promise of openness in addressing the new complexities of a virtual world? Let me know what you think.

— Carol Wilson, Editor-at-Large, Light Reading

cjanz 7/23/2013 | 3:03:14 PM
re: Will 'Open' Be A Victim or Victor? There are some good points raised here. The trend for network operators indeed will be toward expansive openness. An expansively open architecture is open at 3 distinct points, each point bringing a particular value, complementary with the others:

- Openness above network control software: an abstraction-based northbound API – what to connect, what connection parameters – stabilizes the language of communication between applications using the network, and the network controller. With technology, layer and vendor specificities removed from the interaction language, efficiencies are gained in the development of business applications, and stability of their use and portability from one network platform to another, are improved;
- Openness within network control software: “modifiability through modularity” will hand operators the keys to their control system features and architecture – operators will thus gain control of innovation delivered in that system, where the SDN architecture creates so much potential for capital & operational cost containment, as well as improvement of revenue achievement;
- Openness below network control software: network programmability – with deeply rich control of network configuration available particularly at the packet layer, where most services fundamentally are constituted – is essential to achieving the maximum cost constraint and monetization potential. SDN allows the centralized control software system directly to manipulate the network state in response to demand drivers, with computational engines attempting most closely to match supply and demand through resource assignment, pricing, etc. The more granular and rich the control system’s ability to manipulate the network state in detail, the more closely it can effect such matching. OpenFlow
was designed with this in mind.

Most real, deployed systems will need to evolve in steps toward expansive openness as described above, and such evolutions often will proceed – as a rough matter – from the top down. “Global views and control” capabilities and northbound abstraction will be added to existing network systems, and business applications (in telecom, includes OSS & BSS) will be evolved to take advantage of those changes, themselves seeing considerable transformation in the process. Control systems will then evolve toward open, modular architectures. Networks themselves need not evolve immediately – but as described above, pressure to move toward truly programmable networks will come, being driven by economics, but also opportunistically by the evolution of control systems.

An evolutionary imperative means that operators very much need their “established vendors” to assist them with solutions that support evolution. In many respects, the first step toward SDN may be the hardest, and it is critical for operators that multiple simultaneous overhauls be minimized while immediate benefits of changes are maximized. Ciena’s V-WAN software can be deployed today - in current network, and network and back office software environments, with minimal disruption – to generate the essential “global views and control” and autonomous interlock control from application software systems, including cloud orchestrators and now-transformable OSS/BSS systems, that operators need now.

It is also important to recognize evolutions that either may not happen, or will be very cautiously approached. It isn't just intransigent “established vendors” in the way of an immediate and wholesale divorce of all control plane functionality from the physical network. The ONF itself has directed – and remember, ONF directions are set by the operator board members, not vendors – that OpenFlow definitions for transport systems should, unlike for packet systems, be compatible with the use of embedded & distributed control planes, or elements of them. This is based, among other reasons, on a recognition that such control plane designs deliver affirmative “system stability” and related desirable attributes to these foundation levels of the carrier network.

Sorry for the even larger book…

Chris Janz, VP Market Development, Ciena
joe.cumello 7/22/2013 | 9:48:07 PM
re: Will 'Open' Be A Victim or Victor? In our experience, the partnerships that evolve into northbound software or app development has to do with building and establishing trust based on execution. In other words, I don't think any vendor can walk in the door and just start that kind of effort without that trust.

But these engagements normally start with:

1. The utilization of standard apps that come with the platform (inventory, design, operation, management, visualization)
2. Proving third-party device access and control if applicable
3. Then exploration of integration into existing OSS procedures

Over time, I think this evolves to solving more complex issues. For instance, once a centralized SDN platform can orchestrate virtual machine activation and movement and on-demand bandwidth provisioning, the carrier billing systems will have to be engaged.

So to answer your questions:

Is it possible today? Yes, in a limited way and typically starting with provisioning processes. The SDN platforms' multi-vendor capabilities are key here because no carrier network is built or operated with one company's equipment.

What has to happen for such partnerships to work? Execute what you promise, deploy, build trust and these engagement start to happen. This is all standard operating procedure for working with carrier partners. The X factor is the fact that SDN and NFV present a new way of operating the network, so there is new ground being broken by the innovators.

What do you think is the role of standards groups or forums? They will provide the industry with a common language to speak for device access and control and they will create industry-wide momentum. But it's important to note that carrier networks are too complex with too many layers for their to be some kind of SDN standards panacea. I think platform openness and the ability to adapt is very important in moving this initiative forward.
Carol Wilson 7/22/2013 | 7:17:52 PM
re: Will 'Open' Be A Victim or Victor? Joe,

No apology needed - you provided a very thorough response to what was my opening shot leading to an upcoming series of articles. I'm particularly focusing on the northbound interfaces and what OSS/BSS changes are needed to best take advantage of the flexibility virtualization is promising.

On your last point, the tight partnership between the vendor community and the carrier IT departments - is that possible today? What has to happen for such partnerships to work? What do you think is the role of standards groups or forums?
joe.cumello 7/22/2013 | 6:46:12 PM
re: Will 'Open' Be A Victim or Victor? Carol, a couple of other things to think about as it relates to this topic, which we agree is critical to moving the SDN and NFV initiatives forward.

1. "Openess" in the telecom universe has to do with more than OpenStack and ONF. SDN software platforms should be designed with openess in mind on both the northbound and southbound interfaces. No two service providers operate in exactly the same way, obviously, and no network has the same devices across a footprint. A platform with open northbound interfaces allows the service provider, or hardware/software vendors, to write apps for an SDN controller that match their own operational procedures, or add NFV functions that are critical to their service requirements. Open southbound interfaces allow an SDN system to talk to any device in the network.

(I'd be remiss in not noting that Cyan today has deployed its Blue Planet SDN System in over 70 service provider networks controlling or accessing over 50 third party devices outside of our own. We also have service provider partners writing custom apps into Blue Planet to support their own provisioning procedures, as an example. It will only be a matter of time before this expands to other OSS functions beyond the apps that Cyan has already written for network orchestration, operation, visualization, management, design, and inventory within Blue Planet.)

2. SDN and NFV can't be defined by OpenStack and OpenFlow alone. This statement is obvious, but is often ignored in the industry conversation. As the OpenFlow standards continue to evolve, we will hopefully see more network equipment that supports OpenFlow natively; but we have shown that network operators don't "need" OpenFlow to take advantage of SDN and NFV. Furthermore, operators are in search of a viable migration path to SDN/NFV, a path that allows them to take full advantage of the embedded equipment they have already invested in, while also enabling them to introduce new equipment and services, including virtual appliances (NFV).

3. It's not easy to be open. Established equipment providers, both large and small, have been “hardware-defined” based on 15-20 years of their R&D investments. Suddenly, nearly all of these same players now have SDN platforms, which makes marketing sense considering the intense industry hype and focus. But a number of these platforms are based upon the vendors’ established control plane and management systems (built specifically for that vendor’s equipment), and renamed as SDN. SDN systems need to be architected to be open and multi-vendor from the start. Network operators, when reviewing these technologies, should start with questions like, "did they just re-label their GMPLS (or other) control plane and management software as SDN, or did they really divorce the control plane and software from the hardware?" – as an example.

How many companies would pass that test?

The future success of carrier SDN and NFV is rooted in the SDN software's ability to work in multi-vendor and complex environments. We believe that openess on both the northbound and southbound sides of these platforms is the only way this is going to be achieved -- along with a tight partnership between the vendor community and the carrier IT organizations to coordinate established OSS procedures and applications with these platforms.

(Sorry for the book.)

Joe Cumello
CMO, Cyan
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE