I’ve noted in past blogs that the world of SDN is evolving, and perhaps the most significant element of this evolution is the emergence of a distinct two-layer model of SDN. The top layer of SDN, based on “software overlay” virtualization, focuses on agile connection management to adapt to the dynamic notion of the cloud. The lower layer that represents actual infrastructure is aimed at traffic management and network operations efficiency.
While this “bicameral” model of SDN is helpful, I think, it does have the effect of layering two virtual things on top of each other, which is hardly the formula for creating a hardened, operationally effective process. In fact, the “dirty secret” of SDN as I’ve called operations, has been a growing problem. Which is why I’m very interested in the Netsocket SDN approach. They designed their whole concept around operations, because cloud operations is where the company got started, and they’re bringing a new notion of harmony to SDN.
The Netsocket Virtual Network, as the product is called, has the right three pillars of design—end-to-end application to mimic a real network, a management model that recognizes the inherent difference between virtual and physical networks, and the ability to seamlessly integrate with physical networks, both in an overlay sense and at a boundary point to extend or federate services. But perhaps the biggest insight Netsocket has brought to the SDN place is their focus on northbound applications, the very area where most SDN players have hidden behind loosely defined APIs. In fact, the Netsocket model is to give away the virtual network layer and sell the applications.
The infrastructure layer of NVN is made up of their own vFlow switches, which are interoperable with OpenFlow hardware switches (but a lot more agile, not to mention cheaper). The vFlow Controller layer is analogous to the traditional SDN controller of OpenFlow, but it includes the ability to interact with legacy IP networks at the edge, sniffing the routing protocols to provide the ability to extend network services between vFlow and legacy devices. This is a commercialization of the private implementation Google did to create an SDN core, but with broader application (and easier integration if you’re not a gazillion-dollar-revenue search giant).
The “northbound API” of NVN is the vSocket API, which is a web service that couples applications to the controller. This is an open interface in that Netsocket has made the specs freely available. The applications that run through vSocket provide the network service smarts, including optimization, policy management, and of course connection management. One of the vSocket-connected applications is their management console, another is the centerpiece of their operationalization.
vNetOptimizer is a service operationalization application that can correlate between virtual-network services and physical network conditions, including the linking of physical network events with the service flow conditions that they cause. It’s this linkage that gives Netsocket that direct operational support capability that nearly all overlay virtual network technologies lack. It will take some time for the details on how vNetOptimizer evolves to understand just how complete it can make the operations link between layers, and also to understand how it might present “virtual management” options that are more attuned to network services than to devices, but since Netsocket has cloud-service roots, I’m of the view that they have good credentials here already.
One of the interesting things that the legacy/virtual linkage Netsocket offers can allow is the control and automation of legacy networks. Their operations scripting/policy control can be extended through plugins to standard devices (Cisco and Juniper are the two mentioned in the press release, but in theory you could build a plugin for pretty much anyone). This deals with an issue that’s already come up in the Network Functions Virtualization (NFV) discussions—how you use NFV concepts to virtualize some elements of a network while there are still legacy devices in place. By accelerating operations benefits, the Netsocket strategy can reduce first-cost risks to operators or cloud providers, or even to enterprises.
For end-to-end support, Netsocket is drawing on an NFV-ish concept, which is using a COTS server to host virtual functionality in branch/edge locations. This is actually congruent with the general goals of the NFV ISG in converting complex edge devices (“branch routers” or “integrated routers”) to applications running on a standard server. Pretty much any virtual-overlay SDN solution could in theory be run this way, but their providers (as you know) don’t tout that approach but stay focused on the data center. Netsocket will likely change that, forcing overlay virtual network providers to explain how they can be used across a complete service network…and of course how that virtual creation can be operationalized.
I noted in an earlier blog that I believed that new-generation software overlay SDN solutions were emerging and would likely put pressure on the “traditional” OpenFlow purists to be more articulate about how their stuff actually provides applications north of those anonymizing northbound APIs. I think that Netsocket is going to ratchet up that pressure considerably. Their stuff is cloud-friendly, carrier-grade, and it’s the first SDN story I’ve heard that had the specific cloud-service-level operationalization focus as well. That could be a very powerful combination.