All the talk about “cloud networking” and “virtual networks” and “software defined networks” seems to be diverging as often as converging, and I’ve talked about the “network model” issues that might be behind a good part of that. There’s another factor worthy of mention, too, and that’s the perspective issue. If you’re the cloud looking down at the network, you see things one way. If you’re the network looking up at the cloud, you have a different vision. Clearly the two need to harmonize, and understanding how they differ may be a good place to start.
From the cloud perspective, everything pretty much has to be about virtual networking, unless you’re talking about cloud-hosted network functionality and not cloud applications. The cloud sees a network as a connection topology and associated QoS. We know what the latter means, but the former means the relationship between users as defined by their traffic. There are three broadly recognized connection topologies—Line (point to point), LAN (multipoint) and Tree (multicast). Each of these topologies connect a community of endpoints—users if you like.
From the network’s perspective, we’re almost certainly going to have a widely connective native infrastructure that supports everyone who might be part of a virtual network, and so one of the mapping properties between cloud-viewed networks and network-viewed clouds is this subsetting. VPNs and VLANs have this property; they subset a larger connection community. Tunnels are “Lines” that connect two endpoints, and so we can see from both these examples that there are mappings we can already define to unify the viewpoint of the cloud and the network.
The deeper challenge comes with the process of creating QoS, meaning creating a virtual network that has services that can appear to be traffic-engineered to suit application needs. The cloud sees QoS as a requirement; the network has to make it a property of a virtual network service. That’s where we start to see issues with our mapping, because many of the examples of virtualization (LANs created with overlay technology like Nicira, or tunnels used for point-to-point, for example) are overlays that can’t control the underlying service. Thus, they can’t traffic engineer themselves, they’d have to be given some specific service by the network. But if they’re just traffic to the network—as overlays are—then how does the network know one virtual network from another?
I think this is where the models of software-defined networking may end up differentiating themselves, or at least we can use this to define a new differentation of SDN. One SDN model is the EXPLICITLY INTEGRATED model, where the SDN creates the virtual network within the physical network. Here, because the physical network is aware of the virtual (it’s a part of it, like a VPN or VLAN), the SDN can offer both segmentation of the connectivity space and QoS. In the other model, the COUPLED MODEL, the virtual network model has to be coupled to the network, meaning that there has to be a central or management process that “knows” virtual and also knows the real network.
Where this may be important is in understanding how a player like Cisco is likely to approach its SDN play. If Cisco doesn’t want to depend on OpenFlow, whose per-device forwarding control lets you build unlimited virtual networks and engineer them any way you like, then it has to either base its SDN on something like VLAN/VxLAN to segment the network down where the devices can see traffic and supply QoS, or it has to couple the overlay virtual network models down to the network handling of traffic. The only way to do that and retain the current protocols and devices is to use policy management (PCC), which is what Cisco seems to be doing. So is there method to their madness? Maybe. And maybe others will, of necessity, inherit it.