Alcatel-Lucent finally did their SDN announcement, and it was in most ways a major step forward for SDN, perhaps the biggest step taken by any of the vendors so far. However, as is often the case, the articulation may not do justice to the technology. In fact, in many ways the material was downright murky, and since I was traveling and unable to schedule a briefing, I had to struggle to get the measure of what was actually going on.
At a high level, there are two SDN visions in play here. One is the Nuage vision of a data center network that’s essentially a functional superset (“super” in many ways, as you’ll see) of the Nicira overlay SDN-as-connectivity-control model, and the other a much broader cloud-SDN model. I make this point because if you look at this as a Nuage story, I think you sell it short, and the same is true if you look only at the WAN side.
Let’s start with Nuage. All software-based network overlays have a common property of subsetting the “real” connectivity of the network below. With Nicira the primary goal of that was to create separation of tenants in public cloud infrastructure, and you may recall that I’ve been unhappy with that mission from the first. It does this by creating a virtual Level 2 network through tunnel overlays, which we’ll call “software-defined connectivity” or SDC here just to keep the pieces separate. This basic SDC model is OK, but it just doesn’t solve enough problems to secure a firm path to relevancy.
Nuage’s positioning (and to be fair, Alcatel-Lucent’s positioning of Nuage) focuses a bit too much on the notion that what Nuage is offering is a higher-layer SDC vision. That’s true in that Nuage recognizes virtual networks at Level 3 and also (at least as I read the stuff) also recognizes port-level subnetworking, meaning that you could create and maintain virtual networks using TCP/UDP ports and not just IP addresses. What makes this important isn’t higher layers per se, but the fact that it gets the SDC out of the data center and makes it a logical partner to both endpoints and real network technology. Layer 4 (ports) is as high as OSI layer references reasonably go because these are the application-level connections actually used in software APIs. Nuage has thus covered all of the functional-value waterfront here, the first to announce that capability.
A full-layer SDC is inherently able to span the boundary between data centers, so the Nuage offering can be used to build a cloud resource pool that offers elasticity of VM or application image positioning that crosses even national boundaries. It also supports natural hybridization of public and private clouds for cloudbursting or failover operation, and it could in my view provide a framework for federation of multiple public clouds. When you look at the feature set here, what you see is a virtual-network overlay that’s designed to manage resource addressing and connectivity management within any arbitrary cloud and also with its endpoints.
Nuage is very much a DevOps-based process, in that the benefits of Nuage are presented through a set of operations APIs that fit the model of cloud DevOps I’ve talked about here. Virtual networks are abstractions, and the abstractions are based on a set of policies that link them to the second piece of this, which is the Alcatel-Lucent part (I’ll get to the details of that in a minute). The definition of connections is via logical groups rather than as physical elements, and policies can be assigned at a group level (would normally be, in fact) and that spares the application users of network services from the details of the network itself, even at the virtual level. Each virtual network also presents a management view so you can see what’s happening at the operations level.
All of this is fine—even perhaps great—but it’s still an overlay and you still have to deal with the real network and real connectivity. Alcatel-Lucent does that with “policy-pull provisioning”, which has a nice euphonic ring and also happens to be a good idea. The Nuage policies can link down through an SDN controller (not the simple OpenFlow SDN controller but a more sophisticated and functionally complete model) that can take advantage of any and all of the protocols/processes used to control resource behavior in the real world. This makes the model applicable to mobile networks through the traditional policy-based processes and via DIAMETER, for example, and also with OpenFlow-based devices and IP/MPLS devices. This aspect of Alcatel-Lucent’s story is somewhat congruent with Ericsson’s SDN vision, but Alcatel-Lucent has provided more detail on the implementation and has embraced a broader control protocol model in terms of public articulation. Alcatel-Lucent also includes a resource discovery function that drives connectivity control changes when physical network changes occur.
The binding innovation here is the “Software Defined VPN” or SDVPN, which is a Nuage SDC overlay linked with the Alcatel-Lucent physical network piece. SDVPNs can extend endpoint services and so they are a natural source of end-to-end SDN functionality and also a natural platform for network services. SDVPN agents will be open-sourced so they could be installed anywhere as a virtual endpoint, which is what makes this concept extensible. In fact, in my view at least, an operator could build services based on these capabilities and sell them to users as ARPU-generating extensions to basic VPN services. You could also, again in my view, use this as a foundation for building a cloud-NFV application framework. Alcatel-Lucent has been active in NFV all along. The same “hosted SDVPN” concept would appear to make it possible to integrate SDVPN functionality with the real network, which could then bridge the current gap between overlays that see only connectivity and real networks that see real traffic but don’t have any view of connectivity controls applied at the overlay level.
All of this is very smart, presuming that I’m correct in my interpretation of the material, but as I noted there are some issues digging this detail out of the released documentation and there are still points where I think clarification and expansion are in order. For sure, the concept could have used a clearer articulation, but I do applaud its technical completeness and the fact that it’s going to customer trial this year—it’s not some 2014 vision that maybe will happen and maybe won’t.
For competitors, this story could present challenges. Because Alcatel-Lucent has taken a truly cloud-centric and service-centric view of SDN for the first time, they’ve made it harder for rivals like Cisco and Juniper, who have been (deliberately or by accident of articulation) glossing over their details and making SDN into more of an evolution of current networks than a partner in cloud networks and cloud services. They have established a functional litmus test for an SDN implementation by any vendor, and even startups will now have to think outside the data center and think more about the context of the applications/services than about the simple issue of connectivity. That could refine and focus the SDN dialog, but of course whether it will depends on whether anyone understands what Alcatel-Lucent has done. Eventually, I think, they will.