There’s been a lot of talk about “layers” in SDN and even in NFV, and I’ve blogged in the past that most of it is at the minimum inconsistent with real OSI model principles. Some is just nonsense. Interestingly, given that we seem to want to invent layer behaviors ad hoc, we’re ignoring a real “layer”, one that could actually be the glue to a lot of stuff in both the SDN and NFV space. It’s signaling, or what in IP is called the “control plane”.
When you dial a conventional phone (or most mobile phones) you create a set of messages that aren’t you call but rather a request for service. When you click on a URL, you’re generating something very similar—a “signal” in the form of a DNS request that will eventually return the IP address of the site you’re trying to access. The fact is that every Internet or IP service relationship we have today, and nearly every Ethernet one as well, is based in part on what’s typically called control plane interactions that lay the groundwork for data exchanges.
We don’t recognize the role of the control plane until we don’t have it. Recently a big ISP lost DNS service and it ended up breaking the Internet services of millions. I’ve had recurrent problems with Verizon’s FiOS service because of DNS reliability or loading, and as a result I changed to another DNS provider. DNS is also often the means used to direct traffic to one of several points of service—load balancing. In SDN, you still need DNS services and many think that DNS “signaling” is a better way to set up paths than waiting for traffic to be presented for routing. In NFV, DNS may well be the core of any effective strategy for horizontal scaling. And DNS is only one control-plane service/protocol.
One of the central truths of our networking revolutions is that all of them necessarily end up creating what’s popularly called “Networking-as-a-Service” or NaaS. This control plane stuff comes into play with any conception of NaaS, and so ignoring it not only hampers realistic implementation of SDN or NFV, it also impedes our understanding of what has to be done.
Suppose you have this little app called “generate-a-packet”. When invoked, it sends a packet to some URL. Now suppose that you want that app to be supported by our evolving SDN/NFV world, through the medium of NaaS. How does it work?
One way it doesn’t work is that you present your packet out of the blue and hope for the best. If you are sending a packet to a URL you need two things—an address for yourself and one for your target site. So presumptively your “NaaS” has three functions available. One is “get me an address for myself”, based on a DHCP request. One is “decode this URL” based on DNS, and the other is “transport”. In a sense we could say that the first service is “Initialize” or “pick up the phone”, the second is “dial information and set up a call” and the final one is “talk”. We could visualize web access in terms similar to a phone call, with the process of clicking a URL setting up a session. We could drive an SDN route from user to website based on this kind of NaaS.
The problem with this is that we don’t have any way to signal that we’re done, so in an SDN world we’d end up having a route for every URL path the user ever clicked on. Is that necessarily bad, though? In an Internet sense, taking this approach eventually reduces to replicating generalized routing tables because it scales better to provide uniform connectivity than to manage all the individual “sessions”. In a VPN though, it might be very rational. The user doesn’t need an infinite variety of destinations, only the ones they’re supposed to be talking to.
What this proves is that it’s possible to conceptualize ever-so-slightly-different services if you go back to control plane exchanges and NaaS. It’s also possible to resolve some ambiguities in current “services” by adding some new commands, in the form of new signaling. We signaled via DNS to decode an address and that was taken as a session setup request. Could we signal to break down a session? Surely. In fact, there have been numerous proposals to set up IP relationships inside SIP sessions, so SIP could be the mechanism.
This may not be the best approach for the Internet at large but it could be fine not only for VPNs but also for content relationships. In SDN applications to mobile services, session-NaaS for content delivery could allow us to bind users to cache points that varied as the user moved around. The central address management process simply sets either end of the session to the correct source/destination.
In the NFV world, moving to a NaaS with explicit sessions could relieve one of the big challenges of horizontal scaling, which is how you keep a sequence of packets going to the same destination when they’re related. “Stateful load balancing” isn’t easy because we don’t know what packets go together as a single request. We could know if the application bounded the requests in a “session”.
I’m not trying to rewrite how IP or the Internet works here. In fact, quite a bit of this could be done by simply using current signaling/control plane protocols in a different way. More could be done if we were to assume that some critical applications used a NaaS that had features different from those of traditional IP or Ethernet. Exploiting those features would make services based on SDN or NFV better and not just cheaper, and that could boost the business case for deployment.
Signaling and control plane stuff is an untapped gap between the high-volume data-plane movement of packets and the management processes that provision infrastructure. It may be that if we’re going to get the most out of either SDN or NFV we have to fit some features into this gap, to exploit some of the extra stuff that could be done with signaling. I contend that DNS-based load-balancing, already in use, is an example of this truth. We need to look for other examples, opportunities, and see if realizing them will move the ball.
