What do enterprises think their network should be? I can’t say that I get much in the way of explicit comments on this, other than the expected toss-offs like “cheap”, “reliable”, and “secure”. Few enterprises really think about how network technology should evolve, and fewer offer spontaneous comments on the topic. However, I’ve been looking over the 2023-2024 enterprise tech comments I’ve gotten, and I propose there may be an implicit view lurking on the network of the future. Try “Invisible”.
Networks, enterprises reason, connect things. If there’s a “thing” I want connected, therefore, it should be networked. Following this thread, we could say that the network of the future is a vast cloud of connectivity that can carry the traffic I’ve chosen to generate to the places I need it delivered. What’s in it? I don’t care. What technology does it use? Don’t care. My toss-offs are my criteria—cheap, reliable, secure. And, implicitly, invisible.
If we try to nail this to technology, I think the obvious high-level linkage is to the network-as-a-service or NaaS concept, but like everything these days, NaaS as a term has been spread around too much to be very useful. Let me draw on the distant past to illustrate what I think invisible networking a la NaaS might look like.
When X.25 packet switching, frame relay, and ATM came along decades ago, they presented the need to somehow merge these technologies with the reality of IP dominance at the application level. How does a virtual-circuit technology mesh with datagrams? Answer: NHRP.
In IP-speak frame relay and ATM are “Non-Broadcast Multi-Access” networks, or NBMAs. If you stick a virtual-circuit network, an NBMA, into an IP network, you have to be able to create a virtual circuit to carry a hop of traffic routing, even though IP routing protocols are broadcast protocols that won’t work. NHRP stands for “Next Hop Resolution Protocol” and what it did was to allow any NBMA to live inside IP by letting its edge elements (gateways into the world of IP) know the IP addresses available at all the other NBMA gateways. Each such gateway broadcast the IP destinations it could reach, and so any packet that arrived at a gateway could there be linked to another “exit” gateway and could establish a virtual circuit to it.
No, I’m not proposing that the future of networking is virtual circuits, but think about this. What any IP user knows is addresses; their own, and that of the entities they’re connecting with. We could suppose that our invisible network, or that a true NaaS, would be a network that, when presented with an IP address (let’s say a URI or “Uniform Resource Identifier” and a “Uniform Connection Property” vector, would somehow deliver a packet to the URI with the QoS, security, and cost specified in the UCP.
A consumer user of the Internet, and perhaps smaller business sites, might have a single default UCP provided by their selected ISP, but some sites might have multiple ISPs, or there might be an ISP who offers selection of UCPs based on user needs. I’d guess that UCP selection would be made for most when a service was contracted; each packet sent would then have a small “NaaS header” that selected the UCP desired, and this header could be attached at the NaaS interface based on address/URI, protocol used, or any other set of properties that could be derived from the packet itself and the user’s NaaS policies. Where no NaaS UCP is offered, the default handling of the ISP is invoked.
The effect of this would be to codify a NaaS concept, but also make the network effectively invisible in a tech sense, but versatile in a properties sense. A VPN of any sort could be a NaaS UCP selection too, which would wrap current VPN security into the overall mantle of NaaS. QoS, to the extent that regulatory policies on net neutrality permit, could be selected where the operator provided the capability, and priced the way buyer and seller agreed. You could also see the possibility of access ISPs offering a facility to “shop” a UCP around for pricing, and to select the connecting peered partner routes based on the best price for the specified capability.
This, to me, is an example of a true NaaS, because it would mean that any set of UCPs could be offered at a network interface, and any offered one could be selected. It would even be possible for the ISP to set the UCP based on the address/protocol and header information of a packet. The model would make the distinction between the Internet and any VPN, including a private company VPN, simply a matter of selection.
I’m not advocating this model, nor am I saying that enterprises are. Since I rely on enterprise comments for input on their views, I don’t have specific insight into how they’d react to this, though I expect I’ll get comments from them now that I’ve offered this blog. What I am trying to do is to unravel the true value behind hyped tech concepts, like NaaS, and to illustrate the risks of that hype on the marketplace overall.
What is “NaaS”? According to the AI overview Google gave me on searching the term, “Network as a Service (NaaS) is a cloud-based model that allows businesses to access networking services without the need to own or maintain their own infrastructure. NaaS uses software-defined networking (SDN) to provide a flexible, scalable, and cost-effective way for businesses to operate their networks.” If you look at the definitions that dominate the results below that summary, the common thread is the “cloud model” notion. You’ll surely see that there is nothing cloud-specific in what I’ve described above, and there’s a reason for that.
An implementation- or technology-centric definition of something new has two inherent risks. First, it may well be that the presumed approach isn’t really the optimum one, and in fact there may be reasons why it’s impractical or unlikely to be accepted. Why link NaaS to either the cloud or to SDN? The second risk, the more profound one, is that any “service” should be first defined by its properties, then by its relationship to its prospective users, which is what I’ve tried to do here. That links you to practical reality before you start thinking about the what and how, and I think that’s essential in making a business case.
NaaS is a good idea, but I think we’re fleeing its value by trying to decide how to do it rather than how and why to use it. I hope my enterprise contacts will tell me what they think, when they read this blog.
