I blogged yesterday about vendor differentiation in an open-model network, and closed with the point that a higher virtual layer might offer the only place where “connectivity networking” could find the features and opportunities vendors needed. SD-WAN, I pointed out, was an example of an exploitation of that higher virtual layer, but one that’s not been developed by the SD-WAN community at large. SD-WAN, which is really just an application of generalized virtual-network principles, has gotten mired in VPN-extension mode, when it could actually be a platform for building new, revenue-generating, user-empowering, connection services.
Most of you who follow my SD-WAN blogs know I’ve long been a fan of one vendor, 128 Technology, who I’ve believed has best grasped the full potential of SD-WAN. The company has been pretty quiet up to now, but they’ve just made their first big announcement of features and capabilities. Given the facts that 1) SD-WAN isn’t much of a news item in general, and 2) 128 Technology is essentially doing an update, coverage has been limited. This is a bigger story than the coverage would suggest, so I want to talk about them in the context of what “the full potential” means. And for the record, they have nothing to do with this blog, have never seen it or even been made aware of it, didn’t pay for it, and didn’t influence a word of its content. As always, this blog is my own writing, my own view.
To set the stage, it’s always been my view that SD-WAN was a mission or application of virtual-network technology to the specific problem of small-branch connection. We have a couple dozen vendors who have introduced SD-WAN products to support that mission, and most of them do little or nothing else. To me, the SD-WAN market raised an important question, which was whether we needed to think about virtual networking not as a bunch of little niche value propositions, but as a new way of defining connectivity.
IP has become a universal framework for communications of all sorts. It’s based on proven technology, there are a lot of vendors who provide devices, and the client side of IP is supported in almost every computer, phone, and tablet, and even many doorbells and thermostats. One of the reasons is that as a network protocol, IP is “connectionless”. You don’t make IP calls, really, you simply send packets. Any sense of a persistent relationship like a “call” or the general concept of a “session” between parties, is created by the endpoints themselves. IP is connectionless, and unaware of these relationships, it just carries them as disconnected packets.
The combination of proliferation and connectionlessness (to coin an awkward term) creates some challenges, though. One is that there are billions or trillions of possible connections, most of which would (if they happened) turn security-minded people and organizations white with fear. We spend a lot of money on an IP that can connect anything to anything else, and then spend more to stop most of the connections from happening.
We can’t change IP, but if we’re going to create a virtual network that can ride on IP (or anything else, for that matter), why not give that network properties that we can’t give IP because of the enormous investment sunk in devices on and within IP networks? That virtual network could be applied to the SD-WAN mission, but also to other missions that demand a lot of explicit control that IP alone doesn’t provide. 128 Technology did that, which is why I took a position on their board of advisors, something I almost never do. Unfortunately, it’s been hard to pull out that value proposition from their material, until this announcement.
The new announcement (the start of Release 4.x) is the result of working to apply the generalized virtual-network model of 128 Technology to a variety of customer accounts. Some of these are public, but in many cases the user organization mandated confidentiality. In either case, the experience with these customers refined both the product and its positioning, and that’s what got us to the point where I’m comfortable blogging about how it all works.
What 128 Technology does starts with session awareness. The 128T (I’ll use that shorthand to save my fingers!) nodes can identify those persistent relationships that to IP are just a string of connectionless packets. When a session starts, they can introduce a “tag”, a small parcel of information that identifies it, and at the same time they can classify the endpoints—who they are if they’re users (“tenants” in 128T terms) and what they are if they’re applications (“services”). Session awareness introduces the notion of a higher layer to vanilla IP, because “sessions” are higher-layer relationships.
Session awareness yields connectivity control, as a starting point. Based on the classifications and the policies that users set through central control, they can assign a priority, designate a route, and even block the connection completely. In fact, by default, all connections are blocked unless a policy authorizes them—zero-trust. All this is independent of the IP-level connectivity, which of course is promiscuous.
The control system for all of this has some cute features to make defining connection policies easier. It works on a hierarchy, meaning that you could define sites or roles, and workers/users within them. Policies for connection could be set by individual, but also by role or site. The same holds true with “services”.
Even Internet traffic-handling is improved. Many, or even most, SD-WANs or VPNs will route all traffic onto the virtual network, which means all Internet traffic carried back to the off-ramp and then pushed out onto the Internet. Because 128T remote nodes see all traffic and sessions, they recognize Internet traffic and don’t tag it for virtual-network handling. In fact, they can recognize classes of applications through a partnership with Alexa, so selective connectivity management can be applied even to websites and web services.
All of this is highly efficient. Because sessions carry these little tags, and the tags determine the handling, 128T is unique in that it doesn’t create an explicit overlay network, a kind of IP-on-top-of-IP-via-a-tunnel model. Their nodes are enhanced, session-aware, routers that can replace traditional edge routers and can be cloud-hosted. The 128T “Session-Smart” (their trademark term) network isn’t an overlay, adds virtually no overhead in traffic, and most important, doesn’t require tunnel terminations that limit the number of users that can be supported by a given device at the on- and off-ramp.
This approach is extremely simple from a network-building perspective. You’re not building a network on top of IP as much as coercing IP to behave as you’d want it to. You’re not running two levels of network, you’re running one. In some of those early customers, this simplicity meant getting literally thousands of sites up and running in a matter of days, not months. Opex is lower and reliability is higher, because instead of having two layers of network to fail, you have only one.
The combination of network-building simplicity and the no-tunnel-overlay approach also contributes to significant scalability. Even the minimum-sized 128T node can support hundreds of user sessions, and the larger devices intended for central installation can support thousands. This means that even retail operations with thousands of locations can be networked, and brought up and sustained quickly and easily.
And yes, you can still do SD-WAN. At the point of session recognition, addresses can be remapped, which is why the product can provide SD-WAN services that “look” traditional, mapping branch offices with Internet connections or even home workers, to the same address space as a company’s MPLS VPN. It’s also why a 128T virtual network is inherently multi-cloud; all components in all clouds can be made addressable in the same address space, so the whole multi-cloud context looks like one virtual data center on one network. You can also, with the newest release, use a 128T node to provide Ethernet-over-IP.
When the work-from-home impetus of the pandemic came along, 128T themselves gave mini-node versions of their appliances to key workers, which made them into little portable branch offices. They also worked with the Wireguard open-source VPN client to provide a means of connecting remote workers back to their local branch offices as though they were on the office LAN. That offers economical remote-work connectivity and preserves policy control of traffic at the branch office level.
This is the difference between virtual networking and the limited SD-WAN mission, and it’s an example of how a virtual-network layer, by taking over connection control, could create differentiation above the traditional network. It’s also an example of how network connection services, built correctly, could include features like security that we’re currently paying (a lot) to glue on. But perhaps that’s why the big network vendors haven’t pushed the concept; they already get a lot of that security money.
I’m glad that somebody is illustrating the value of true virtual networking. Perhaps it will catch on, and perhaps it will finally make networking a full partner to server virtualization and cloud computing.