At last week's OpenDaylight Summit, an event that celebrates open-source and all it implies, Ericsson was walking a bit of a tight rope.
On the one hand, the Swedish telecom giant played a significant role in OpenDaylight as a premium sponsor and is credited with doing significant integration work involved in Hydrogen, the open-source software-defined networking (SDN) controller launched this week.
Ericsson AB (Nasdaq: ERIC) announced last week it is opening a test lab for Hydrogen in California and has already committed to transitioning away from the SDN controller it developed and has been testing with Telstra Corp. Ltd. (ASX: TLS; NZK: TLS), to adopt Hydrogen at some point in the future. (See Ericsson Launches OpenDaylight Lab and Service Provider SDN Gets Real.)
On the other hand, Ericsson is well aware of the needs of its service provider customers for some level of standardization, at least where things such as network interfaces are concerned, and for ongoing support of legacy equipment and systems, which are highly specialized -- the antithesis of "open."
That's why Don McCullough, director of strategy communications at Ericsson, sees two separate routes within future networks: One will be driven by organizations such as 3rd Generation Partnership Project (3GPP) , with specifications and standards; and a second one will follow the more de facto standards approach of the IT world, where open systems are the dominant influence.
"We need to be able to take advantage of the benefits of open systems -- speed, community, and leverage," McCullough says. "Plus a common infrastructure to prevent vendor lock-in. But you can't get those positives without a significant cultural shift."
He maintains that shift is happening within Ericsson, which has been working on SDN for more than three years, developing its own commercially released controller, even as it contributed code to Hydrogen, in addition to the integration work. As the open-source controller "proves itself in," Ericsson will migrate away from its separate controller fairly quickly, McCullough says, and be in a position to assist its carrier customers with their own migrations to open-source, through its professional services arm.
To be useful, service provider SDN has to be implemented across the network, from the datacenter through the packet-optical transport network and the access network to the customer, and that all has to be orchestrated and managed by a combination of legacy and new systems, to enable the exposure of network services via an applications programming interface (API).
"That can be done today, but the trick is to get the manual processes out of it, so that the provisioning is automated and can be done in flexible fashion," and that's one of the key things on which Ericsson is focused.
It's why McCullough is a little slower to dismiss the need for a standardized northbound interface than are many of those gathered in Santa Clara last week. As he points out, exposing network features and capabilities for use by third-parties or customers has requirements in both directions: Customers need to get the quality of service they expect and will pay for; and the network needs protection as well, so that one customer's activity doesn't degrade the service levels experienced by others. All of that is supposed to happened in the controller. (See Standards Lose Steam as Software Dominates.)
"We are already doing things you would call SDN -- policy control management is an example," he says. "But today that is only used by the operator. The question is, can you expose that to third parties?"
That exposure will require interfaces that are robust and well defined. In the old telecom world that would mean a standard interface. McCullough says in the newer SDN realm, the interfaces may need to be more fluid than in the past and able to change with usage. He doesn't rule out other initiatives to develop such an interface, particularly as service providers move to what is generally called "service chaining" -- tying together virtual appliances in flexible ways to meet specific service or customer requirements.
"Service providers want to be able to define a chain in a flexible, automated way based on the service required and based on the customer. They can do it today manually."
Working on the chaining gang
This is one of the capabilities Ericsson is testing with Telstra -- the ability to flexibly create service chains without routing every customer through an unnecessary process.
McCullough admits, however, that developing new services quickly is not the forte of the telecom network operator, and moving at Internet speeds, as those with IT-oriented DNA are learning to do, is something else that is new to Ericsson's traditional customer base. That is where a greater embrace of open-source technologies and less dependence on a rigid standards process comes back into play.
The trick is getting the balance right between the new, open-source approach that allows de facto standards to evolve, and the network operator's need for more certain standards.
— Carol Wilson, Editor-at-Large, Light Reading