Is the Internet the Model for 'Everynet?'
Perhaps it's time to set aside the Internet model and instead look to a model of networking based on SDN and NFV.
Mobility already has driven profound changes in how we use the Internet, and it's in the process of driving changes in how enterprises empower workers. If we add in things like the personal digital assistants -- Siri and Cortana, for example -- and the Internet of Things (IoT), it's hard to see more than a shadow of the "old" days of browsing and searching for content. If things are really changing that much, does that mean the model of networking itself has to change? Are things like software-defined networking (SDN) and network functions virtualization (NFV) going to make today's networking and the Internet "better" or are they going to end up replacing them with something else?
The Internet was a success in no small part because it became what many called "data dial tone," a fabric of connectivity that let any user access any resource. This connectivity has been essential to the World Wide Web and to evolving content and social-media applications. It's also been the source of hacking, denial-of-service, security and compliance headaches; address space problems; and declining operator profit per bit.
We can build the new contextual services, personal agency, and all of what I've called "information populism" on the Internet model, and hope that the benefits of open connectivity aren't overrun by the problems and risks. Or we could try something else. That might sound farfetched given how mature IP and the Internet are, but SDN and NFV do in fact open a new model and this is the time to ask how far the new model could take us.
Think Outside the Tunnel
We already know that NFV can build service features by deploying components onto what effectively are private subnetworks created via SDN. Think of an NFV deployment as a set of features inside a residential LAN -- you can create a gateway in and out but what's inside isn't accessible from the outside. That's essential if we're to keep hackers from attacking pieces of a critical service. It's also useful in building applications.
Imagine a data center with SDN/NFV-based applications, each on its own little private VPN. Now imagine branch offices from which users get tunnels to the application-specific networks they need. They get only what they're allowed to have, and the applications and their data are not accessible except through those little controlled tunnels. A lot of security is now intrinsic.
Mobile services could work similarly. You have a cloud based on private addresses where all kinds of location, social, and IoT data is collected as a bunch of microservices. You also have a personal assistant that lives in that cloud and talks to services over secure pipes. You can tunnel from your mobile device only to that assistant, and that assistant provides you with all your access to information, all your social connections. If the tunnel is secure, you're secure.
Pipe It Down
Enterprises (and service providers) can create this kind of tunneling using what's sometimes called "overlay SDN," the kind of thing Nicira (now VMware) made a name for itself by providing. Everyone gets connectivity from the overlay SDN network, not from the underlying real infrastructure. You can set up as many of these little service- or application-specific overlays as you like. They share common underlying resources, but those resources don't have to provide any universal connectivity. They're just pipes.
Pipes based on what? On agile optics, on groomed Ethernet, on pretty much anything. You could use OpenFlow and white-box gadgets to build pipes that have no direct user connectivity at all. You could also, of course, build them over traditional Ethernet or IP but you'd lose some of the security benefits.
How do the user tunnels get set up? Well, maybe what we do is to link the Domain Name Service (DNS) that decodes our URLs with an SDN controller. Somebody clicks on a URL and the DNS decides if that person is allowed to access the resource the URL represents. We then use the SDN controller to build the tunnels as needed.
This sort of thing is very different from the Internet today, but not as different as it might appear. You can still have universal connectivity; any resource owner could admit the "public" if it wanted. But you could also have resource security and control where needed, because the SDN overlay would only build tunnels for allowed connections. It does no good to fish for resources by scanning IP addresses and ports -- if you're not on the "permitted" list, you don't even see the address of the resource. Mobile apps and personal assistants could also shield us from all of the changes. If you ask Siri for something, do you know how the resources Siri uses are addressed, or care? I doubt it.
We don't have to get to this future in one swoop, either. Overlay tunnels and secure subnetworks can be applied to a single application or service, or to small groups of either. It's likely that the stuff that's most sensitive to security issues would convert first, and then the market would have to decide how far the idea could, or should, be taken.
We're at the point in networking where we can do the same things we do today, only differently and in many ways better. This is the time to ask whether exercising those capabilities makes sense for users, for over-the-top providers, and for operators. We have time and the opportunity to change.
Follow Tom Nolle on Google+!
Tom Nolle on Google+