We looked at clouds from both sides, so the song says, and we probably need to do that with “logical networking” too. From the bottom, SD-WAN is a simple way of extending VPNs, but from the top it’s different. I’ve said in many past blogs that SD-WAN was the on-ramp to a new logical networking and network-as-a-service (NaaS) model. Some vendors realize that, but not every SD-WAN implementation leads to logical networking, and from another angle, some non-SD-WAN implementations may be nosing in that direction.
The industry really doesn’t have a definition for “logical networking” (that’s no surprise since I think I first used the term). In the context I’ve used it, logical networking means the set of tools and facilities needed to establish, maintain, and manage connectivity between logical entities regardless of where they are and how they’re connected. It’s a network of the “What” and not the “Where”, in short. Because virtualization necessarily creates a “What-level” abstraction, I think logical networking is an inevitable consequence of virtualization.
We don’t really have a good definition for network-as-a-service either. Most of the definitions say it’s a subscription form of networking, something that lets you have connectivity without owning network equipment and diddling with configuration and parameterization. But isn’t that pretty much what VPNs were supposed to be? Or SDN? In computing, the “as-a-service” model means that you get an application in usable form, for the asking. Should NaaS then be networks-for-the-asking?
I asked a bunch of enterprises what NaaS meant to them, and the results were all over the place. I took some common points and fed them back, and what I finally found the most resonance for was “NaaS is a model of network service where connectivity is established where and when it’s needed.” Users also liked the idea of explicit connectivity rather than open, permissive, Internet-like connectivity. They preferred using logical names for users and applications, liked the names to follow the things they represented even if they moved around, and thought that NaaS was the natural communications service for virtualization and the cloud. Those are the features I’ve said are the foundation of “logical networking”. Logical networking is an implementation of NaaS principles as users see them.
The next question, of course, is how you actually do logical networking, and here we have some historicity in thinking and implementations. The answer is another layer, something that sits above the level of traditional IP networks (“Where” networks) that rely on network addresses that designate a specific fixed exit port. Perhaps the best, and least-known, example is something called the “Next-Hop Resolution Protocol” or NHRP (RFC 2332).
NHRP was designed to make it possible to extend IP connectivity over a switched-virtual-circuit network like the old frame relay and asynchronous transfer (ATM) networks that never made much of a hit in the market. The notion was simple; an IP packet got to the edge of one of these networks (which, with typical standards-body interest in creating acronyms, was called an “NBMA” or non-broadcast multi-access). There, a routing table found the address of the NBMA exit point associated with the destination, set up a virtual circuit (if there wasn’t one already), and sent the packet on its way. At the other end, normal IP routing applied.
There’s no reason this couldn’t be done for logical networking. We build a higher layer, corresponding to the IP network in NHRP. We use MPLS VPNs, the Internet, or any other set of connection facilities, as though they were NBMAs, and we use our higher-layer routing to identify the right NBMA and exit point. That’s how SD-WAN works in NHRP language, except both the higher layer and the transport layers talk IP and we’re using the SD-WAN layer to extend a private VPN address space.
There would actually be more than one “higher layer” involved if we look toward all the features we’d expect from logical networking. THIS FIGURE shows the logical layer structure needed to offer a complete logical-network implementation. Network users (real humans or application components) are first registered, meaning that they are assigned or associated with a logical name. The logical names would likely look like a qualified URL, something like “me.mybranch.mycompany” or “update.payroll.employeeapps.mycompany”.
Logical names would likely translate to an address, but the address would be a logical-network address. This address would designate the place on the logical network to which the name was currently associated. Changes in location would be reflected in the logical-name table, so a user that moved around or a redeployed or scaled application would get a new address.
Below that, there would be a logical connectivity and policy layer, where policies determined what connection associations were permitted and how they were to be treated in terms of routing, rerouting, QoS, etc. Think of this as a firewall process that’s closed by default and opened only where a rule is provided. This layer would then connect with the encapsulation and transport routing process that would move packets over one of the available transport networks to the exit point, where it would re-enter the logical network stack to be delivered.
If we refer back to the figure, today’s SD-WAN products typically handle the inner layer and may offer some basic features at connectivity and policy layers. They don’t support logical addressing or registration. Standards aiming at SD-WAN have even more limited scope; most deal only with behavior in the inner layer. The higher layers of the figure represent the connection, policy, and security value-add points for logical networking, which is why I say that most SD-WAN solutions today don’t support the more advanced feature model I believe is emerging.
To me, logical addressing and explicit registration are the things that separate traditional overlay networking from logical networking and NaaS. Because not only are these things above IP, they’re above the overlay networks of traditionally modeled SD-WANs, it’s theoretically possible that vendors who didn’t see themselves as SD-WAN vendors, at least not at first, could develop the layers and end up with a credible logical network offering.
The most obvious source of logical networking outside SD-WAN would be SDN players. There are probably a dozen different overlay-SDN models for data center tenant separation, and some SDN solutions aimed at cloud and container networking. An overlay network can be turned into SD-WAN simply by adding some client “nodes” that can be stuck in appliances and hosted in branch locations or deployed in the cloud to serve cloud-hosted components.
This doesn’t get you to logical networking or NaaS, though. SDN vendors have not seemed interested in the higher layers in my figure, in fact. Nokia/Nuage has, from the first, supported both data center networking and branch networking, but only fairly recently has the company positioned itself as an SD-WAN player. They do not at this point support the higher logical-networking layers of my model. VMware bought an SD-WAN vendor and wrapped its entire NSX overlay SDN position in the tag line “Virtual Cloud Network”, but so far has not advanced into the logical-network layers either.
I’m hearing reports from operators and larger enterprises that vendors who have products more aimed at security and cloud connectivity, not specifically called “SD-WAN” are emerging as well. Some of these, say my contacts, are claiming to have more of the logical networking features that the figure illustrates. That raises a question about the future of “SD-WAN” as a term. If the SD-WAN market as we know it ossifies on the basic model, would vendors find it easier to claim they’ve invented another product category? Analyst firms who do sector reports love that; they get to do more reports and ultimately charge more. The media might like it too, since a new category seems revolutionary, and revolutions are easier to cover than evolutions.
How that will turn out may depend on the small number of SD-WAN vendors who have logical networking features already. As I’ve noted in prior blogs, the vendors in the space are uniformly weak in positioning their assets. Some buyers who have been involved in RFP activity over the last couple of months have complained to me that “nobody really gives us a full picture of what they can do.” That not only implies that vendors are shooting behind the SD-WAN duck, but also that users are seeing at least some of the bigger picture. They recognize they don’t have the full story.
Vendors outside the SD-WAN space are seeing some of that bigger picture too. I’ve seen a couple of NDA presentations that make a stronger case for logical networking than the SD-WAN vendors make, even those who have it. That might stimulate some better positioning from SD-WAN vendors, or it might be the opening for that “new product category”. Who sings best, and fastest, wins.