“Carriers could have a couple of different viewpoints [on SDN]. One is we’ve gotta do something on our equipment costs because they’re not going down as fast as traffic is going up. Others say I want to compete with the data centre operators, the cloud providers. Others say I just want greater service velocity. I want to be able to create my own services and not say it to my vendors, “I need this feature” and they say, “okay, well we’ll go to some standards body and it will take 2 years and then we’ll have to program it into our proprietary operating system and get it to work with our NICs and then we’ll deliver it and maybe it’s what you want three years later.” They want to be able to offer some new service and they want to be able to hire their own programmers or their own contractors or their own whatever it is program it themselves and introduce it in 6 weeks.”
Dan Pitt in his YouTube video (see below for link).
As described by Dan Pitt above, SDN represents a very attractive proposition for carriers to be able to increase their speed of service change and flexibility.
The speed of software change, as opposed to getting a vendor to make changes to their proprietary network operating systems, is one of the single most exciting things to happen in the network world in recent years. Nobody can predict what disruptive technologies will come along, but it seems that virtualised network functions are the way of the future.
But more importantly, it changes the OSS mindset too. Previously an OSS was integrated with devices that didn’t really change much over the years, perhaps coping with operating system patches from time to time. However, SDN introduces the possibility of a programmer writing some code, testing it, updating it five minutes later, then refining it further another five minutes after that. How is your OSS to device mediation platform (ie integration) going to be able to handle that?
The integration and data mapping activities that take huge amounts of time in traditional OSS project implementations simply can’t keep up under the SDN paradigm of the possibility* of endless change in the network and its northbound interfaces (NBI).
A new type of network to OSS integration is required and it has to be agile rather than via interface specification, documentation and planning. It has to be as easily re-configured as the programmable network.
I’m not aware of any adaptive integration methodologies, but I have proposed one in an earlier blog entry.
Dan Pitt’s video can be seen below: