It’s nice to have some good news on the SDN front. Ericsson took the opportunity to present their SDN strategy to me as a ramp-up to demonstrating some of the key elements at MWC in Barcelona the week of Feb 25th. They also announced a cloud strategy that included support for OpenStack, which is important because the cloud is the primary driver of SDN. I’ve been looking forward to getting some SDN detail because obviously Ericsson is a key network vendor and they’ve not said much in public about their plans. As it happens, they have a good approach—arguably the most cohesive of any of the major vendors, and certainly more detailed than either Cisco’s or Juniper’s SDN stories of the last two weeks.
The foundation of Ericsson’s SDN vision is something their CTO said some time ago, which is that there was a difference between “SDN” in the basic industry sense and “SDN” in the carrier sense. What that means to Ericsson is that SDN ties not only to the network in abstract, but also to all of the legacy technologies that are currently used to create services and all of the OSS/BSS processes that are used to create the critical monetization cycle. Monetization has to parallel any infrastructure investment cycle or there’s no ROI to drive investment in the first place. Not only is this a “holistic” SDN vision, it’s a holistic carrier monetization vision that envelops SDN and that’s key because carriers are in the profit business not the SDN business.
Ericsson’s SDN architecture has three layers, “Service Exposure and Application Ecosystem”, “Network and Cloud Management”, and “Common Control Plane and Protocols” What’s different with their vision is that all these layers contain both SDN and “legacy” elements, and their vision of an SDN network includes not only OpenFlow but also the Policy and IMS protocols as well. SDN is part of network infrastructure, in every respect. Rather than have SDN technology create another ship in the capital/operations night, they put it aboard a functional framework with everything else, at every level.
The top layer of this is a set of what Ericsson calls “composed APIs” which are effectively examples of the “Façade” design pattern; an API that stands in place of and orchestrates a series of lower-level APIs. Ericsson’s goal is to make these APIs business-friendly so that developers/partners can build services without being exposed to low-level details about network operations that would raise developer costs, delay projects, and introduce potential stability/security risks. Ericsson also plans to expose OSS/BSS elements like service metadata this way, which will allow developer APIs to tap into service/monetization management processes in parallel with the service creation activities normally represented here.
The Common Control Plane strategy makes it unnecessary to postulate an SDN architecture that offers control of the network but builds on current devices and protocols, the “distributed SDN” model I’ve blogged about. If there are standards that allow such a model to evolve, that’s fine, but even if there isn’t the “services” and “routes” created by the Ericsson SDN model can combine OpenFlow with everything else, from RAN management to TDM trunks. That also means that if OpenFlow standards evolve to provide for things like optical-path management, it’s not difficult to accommodate the shift. Management processes operate through their own APIs to the Common Control Plane, which can exercise control via any/all of the protocols available.
The Common Control Plane notion and the fact that it would be routine for OSS/BSS and NMS processes to share the Network and Cloud Management layer means that Ericsson has the hooks needed to receive an abstract SDN service model, to build the global network map and populate it with network status, to integrate IT resource status into the map, and to make network route decisions based on that combination. As I’ve noted, they can then execute on the decisions using any of the protocols that link to the Common Control Plane, including the policy and gateway management protocols used in mobile/IMS. Hold that “mobile” point; I’m coming back to it.
At MWC, Ericsson is going to present two use cases for their SDN model. One is the implementation of the same “service chaining” that Juniper claims is the key to centralized control (see my blog yesterday). Ericsson, in my briefing call, correctly characterized this as being an example of a combination of SDN (for connectivity) and Network Functions Virtualization (NFV), and they indicated they were active in the NFV space. In their MWC demo they link the services via the SDN controller. They also said they were in the process of providing a common virtual platform for hosting their logic that would offer a generic x86 cloud platform option as well as the current purpose-built appliances.
The second use case is what gets me back to my “mobile” point. In this use case, Ericsson demonstrates the use of OpenFlow to create a metro/IP aggregation network that has the scalability benefits of IP but utilizes the centralized management of OpenFlow to control operations cost and complexity. This use case makes the entire metro network look like a virtual IP router connected upstream to the real service edge (Ericsson SSRs) and downstream to mobile, wireline residential, and business uses. Given that the Ericsson approach integrates the SDN stuff with IMS elements, the configuration would support applications that merged metro configuration (including things like caching mobile content) and mobile/IMS control plane elements with overall IMS admission control and policy management. Not all this will be shown at the demo (obviously) but just the virtual-router metro-network model is a critical credibility asset.
I doubt anyone who reads my blog doesn’t understand how much importance I assign to the metro application of SDN. Metro is where the money is, where infrastructure investment remains strong and where changes in demand and mobile technology are driving the introduction of new capacity, new devices. This is the kind of fertile field that SDN needs to make it big, and obviously the kind a vendor needs to make a big success out of SDN. Ericsson is the first vendor to talk with me specifically on the metro-SDN application. Also, as I’ve noted, the first vendor to really show some of that “inside-the-black-box” SDN detail. Given all of this, I wonder whether the MWC SDN demos might be where we start to see SDN-washing and SDN implementations separate.
