There is a profound difference between two things we think of as key in networking. There are “services”, which are the things that users consume, and there’s “traffic”, which is what the network carries. What has happened over the last 40 years is that we’ve gotten focused on the latter, when it’s the former that keeps the lights on. The question now, for both network operators and vendors, is how that’s going to get changed.
A good place to start with this tale is a contrast that’s been meaningless for decades, the difference between “connectionless” and “connection-oriented”. When we make a phone call, we’re calling another party (or parties, in a conference call). When we access a website for e-commerce, or watch a video, we’re entering into a specific relationship with a specific source or partner. These are examples of “services” because they represent what we’re trying to do, and thus what we’re willing to pay for.
In a very real sense, these services represent “connections”, though it’s better these days for reasons we’ll see shortly to consider them “sessions”. In the early days of networking, we carried this connection relationship downward to the network. The phone network set up connections, and successor technologies like ISDN, frame relay, and ATM were all based on connections.
The problem is that connections don’t scale, at least not at the network (or “traffic”) level. When you have connection-oriented networking, you “set up a connection” which essentially threads a persistent route through the network. The nodes along the way have to “remember” the forwarding rules for that persistent route, which means they’re aware of each connection. There have been various strategies to aggregate routes, but the fact is that no matter what you do, the property of connection-ness at the service level is incompatible with efficient traffic-handling.
The solution to this was IP, which is “connectionless”. In an IP network, all the packets that are associated with service-level “sessions” are aggregated and handled simply based on the destination interface. The network doesn’t know anything about “sessions”, only “packets”. The nodes (the routers) in the network only have to know about topology, not relationships. It’s proven to be highly scalable.
The problem is that scalability and traffic efficiency aren’t the only properties of networks that we have to think about. One of these other issues has been around for a long time; traffic management based on application needs. Almost every business, and probably every consumer, faces challenges when they mix traffic that’s sensitive to delay and/or packet loss, and traffic that’s well-suited to IP’s best-efforts nature. The other issue has been around too, but it’s only recently getting fully recognized; security/compliance.
Back in those early connection-oriented days, the ruling technology for data networking was IBM’s Systems Network Architecture (SNA). In SNA, all “sessions” were explicitly authorized by the mainframe, via something called the “Systems Services Control Point” or SSCP. If you didn’t have SSCP consent, you didn’t connect. This created an easy way to policy-manage connectivity built into the network architecture.
IP networks have to add security on, because it’s not intrinsic in the network model. Firewalls, which bar attempts to connect by barring packets with specific characteristics, aren’t exactly perfect, nor are they cheap. More recently, there’s been interest in “zero-trust” security and compliance, where sessions have to be authorized by the modern equivalent of the old-time SSCP. Juniper recently acquired 128 Technology, the firm I’ve always said was the leader in this space.
The big development in both security and compliance is some form of session awareness, the ability of a network element to recognize one of those “sessions” and treat it based on its needs and on the policies of the business or service involved. What this may be, and I hope will be, creeping up on, is a useful implementation model for “network-as-a-service” or NaaS.
With NaaS, though, we’re facing the all-too-common problem of hype versus reality. The properties of NaaS are difficult to understand and communicate, which allows almost anything to be called “NaaS” with little fear of contradiction. That’s too bad, because the lack of a consensus model for NaaS could hurt us all, particularly in the consumer space.
Businesses can adopt NaaS, even true session-aware NaaS, without a major problem even if there’s a hundred different implementations. They pick one and run with it. For network operators, cloud providers, content providers, and so forth, the lack of consistency is problematic because network resources at the broad-market level necessarily converge to interwork and to support consistent services.
What would be needed to provide a common-model NaaS? Obviously you’d have to start with a common requirements set, and today we don’t even have that. That’s sad, because there are only three requirements for a useful, broad, NaaS model.
The first requirement is that NaaS has to look like IP to all network users and devices. Whatever is done has to be done without requiring upgrades to existing technologies that connect, for the obvious reason that if changes were required there’s little chance NaaS could bootstrap into today’s online world.
Requirement number two is that NaaS has to be session-aware and apply policies for handling and connectivity based on that awareness. Otherwise, it doesn’t move the ball in any of the areas where pure IP falls short.
Number three on our requirements list is that NaaS has to provide an effective, efficient, and scalable means of defining, storing, and applying policies. It has to avoid being weakened by any barriers to creating connectivity control.
The last of these three is the most difficult to achieve. We already have at least one implementation of SD-WAN (128 Technology) that fits the first two. While that implementation has successfully been scaled to corporate VPN size, it’s not been tried yet at the scale of a public carrier. We also need to accept the fact that public carriers would probably not adopt a proprietary model without some resistance, so it would be ideal if we had an open definition of policy exchange. We already have standards for policy control and enforcement points (PCP and PEP), so it’s probably not rocket science to provide an adapting technology to utilize them, or to implement them directly.
There’s still one question, though, which is whether NaaS could also be supported at the network level rather than via a form of IP (real or virtual) overlay. It doesn’t seem likely that sessions could be mapped at Internet scale all the way through from end to end, no matter how transport infrastructure evolves, but that’s really not necessary. In most cases, congestion is going to be encountered near to the edge, and often right at the service demarcation. Probably, the most that would need to be done at the IP level is to provide QoS- and security/compliance-specific pathways, which isn’t far from what network slicing in 5G is supposed to do. It will be interesting to see if Juniper, both a router vendor and new acquirer of 128 Technology, will do in this area. Or what their competitors might do.
There’s still a lot of work to be done on NaaS if we’re to advance it from where we are today, but we’ve come a long way in the right direction. If networking is truly to be a service, it’s essential that we be able to classify traffic according to the relationships between users and resources. That step has now been taken, and it’s going to be very interesting to see where we go next.