Networking, say the line departments in most businesses, is way too complicated. Network issues can delay connectivity for new sites, stall mobile work plans, and even constrain operations because of congestion or failure. Whatever happens seems to take forever to connect, and users want something better, like network as a service (NaaS).
In a very real sense, the problem we have with business networking today stems from the peering nature of IP or Ethernet. Networks are adaptive and cooperative, so if you're going to use one you have to adapt by cooperating -- in other words, you have to present an edge device that obeys collective rules. It then becomes not a user of the network, but a member of it. Your discrete need, to access a URL representing your application, may be met by the network, but so are an almost infinite number of other "needs" that, in your case, perhaps aren't needs at all. You pay the price of generalized communication, and all you wanted to do was access your own application.
NaaS is often seen as being extemporaneous communication, and while that's a part of the goal of our user here, you could do extemporaneous communication with IP or Ethernet. It's just that you end up doing a lot more than you wanted, and that broader capability means connectivity is network-building, not application-connecting. What needs to be fixed with NaaS is the need to build a whole network just to connect an application. That seems an impossible goal, but we actually already have something that can do it, and it's called software-defined WAN (SD-WAN).
SD-WAN... or NaaS?
SD-WAN started off as a way of exploiting the Internet to extend, augment, or back up IP VPNs. An edge device has connections to both the traditional VPN and the Internet, and it creates an overlay VPN network over the Internet that can be the only path, a backup path, a workload-burst path, etc. SD-WANs as they're usually viewed (and even as they're promoted by their vendors) don't look like futuristic NaaS, but they are very close to being just that.
Suppose a user wants an application connection. In the real world, it would probably virtually click on a URL, and that would result in a control packet sent. The Domain Name Server (DNS) returns a response, which is the IP address of the application's server. Suppose that DNS response was intercepted by the SD-WAN CPE, and that the CPE first checked to see if it had a NaaS connection with that location. If it did, it could simply pass the address back to the user. If not, it could set up a connection to the server. Isn't that NaaS?
This approach may seem radical and new, but the fact is that the concept has been around for almost a decade. It was developed to let IP networks use an interior connection-oriented technology like frame relay or ATM. Referencing the model I've described above, the IETF specification (called Next-Hop Resolution Protocol, or NHRP) sets up an ATM/frame relay connection to build a path on demand. All the protocols and processes to use NHRP with SD-WAN are defined, and many vendors implement them.
Obviously, this could bring about a profound change in enterprise networking. Every branch office buys a box and an SD-WAN "service." The box uses tunnels/overlays on IP or Ethernet or whatever, and sets up a connection to another box that's at the edge of the data center network. However, since corporate VPNs and the Internet are fairly ubiquitous, this step might seem unnecessary. Think further, and you find other benefits.
Neutrality at Issue
First, this could put a new dimension on application security. Every application has an IP address today, and in theory every VPN user can at least try to connect unless you put in a barrier. In the SD-WAN-NaaS model, all users have to request a connection, and so their access rights can be authenticated before they can get a single packet to the server. Explicit security has to beat add-on security, and without the overlay SD-WAN a user wouldn't have any way of accessing the SD-WAN service box at the data center, and so would have no access to applications at all.
Then there's neutrality. Today we have neutrality rules that effectively bar paid prioritization, but the new majority at the FCC already says they're going to look at the rules. I think they're likely to allow prioritization, and that means that when users access applications through an SD-WAN-NaaS box, they could be assigned (or request) a better level of QoS. That request could then be passed to the network that makes the underlying connection to all the sites.
So, does this kill the enterprise network? The network as we know it, yes. The combination of neutrality changes and SD-WAN-NaaS would probably render private WANs unnecessary, but you'd still have to manage application-to-user connectivity and the LANs at the branch and data center locations. With VPN services as they are, few companies build their own WANs anyway.
Network organizations in enterprises should be building network services, not networks. A combination of SD-WAN, NaaS, NHRP, and neutrality changes could let today's enterprise network teams focus on what they need to be focusing on, which is user/application connection services. That could blunt a lot of criticism and improve operations for everyone.
