For decades, it’s been clear to many that the way we use addresses on the Internet and in other IP networks may be less than ideal. An address represents a network service access point, but we tend to use it (or want to) as a reference to an application, user, or database. In the real world, all of these things may be lightly bound to an NSAP, but in reality there are factors that make that binding unreliable. Mobile networks in particular have had to deal with this, but there have been attempts to decouple the what from the where in addressing terms, so we could reference what we want rather than figuring out where it is. Events may be exposing some options not regularly considered.
In my last blog, I noted that SDN and mobile network evolution were pushing an evolved sense of how networks are built. A couple of Light Reading pieces (THIS and THIS) made me think about whether there could or maybe even should be a link between SDN and mobile networks, and whether developing this link is a step in network and cloud evolution that we’re missing. I also wonder whether the linkage, and the means whereby we could create and support it, is an argument for greater reliance on virtual networks.
The thing that makes mobile networks different is (no surprise) mobility. A mobile network is a network that supports devices that move around, and that movement means that the route to reach a given device is likely to change over time because the device’s location has changed. Our convention is that the device’s address has not changed, which means that traditional IP routing is likely to eventually send packets to the wrong place as the device moves about.
The traditional approach to this, codified in the IP Multimedia Subsystem (IMS), is to have packets destined for a mobile device to be put into a tunnel at the point of entry into the mobile network. That tunnel’s other end is then shifted about by mobility management technology to stay linked to the path that’s associated with the cell in which the mobile device is currently served. This keeps any sessions (voice or data) intact, but obviously it’s a complicated strategy.
Another complication is the fact that mobile devices today are almost all broadband-capable and could support voice calls and texting over broadband. VoLTE is an example of this, a way of using data connectivity to create traditional telephone connectivity. However, once you start using data to carry calls and texts, you raise the question of why those calls and texts couldn’t be initiated and received via WiFi, and why we couldn’t perhaps see calls transferred from a mobile device to something else in the home or workplace, if a smartphone user enters a space where other options are presented. This idea was explored decades ago by Project Icarus in Europe.
All of this raises two questions. First, should all “network services” be viewed as overlays on the things we call “networks” today? Should they be deliverable over any transport facility that can offer the SLA, be able to cross between compatible facilities, and even be independent of endpoint specificity? In other words, should services create their own virtual networks? Second, should we be rethinking how we build transport networks based on the assumption that we answer the first question in the affirmative?
I’ve long proposed that network services should connect virtual agents that reside in the network, to which we then connect based on whatever devices are most convenient. Tom, as a real person, contacts Virtual-Tom and asks for a connection with John. He’s connected with Virtual-John, which then signals the real John via the device(s) defined in John’s policies. This would allow services to be decoupled from device specificity, allow for seamless switching between devices, and so forth. Project Icarus reborn, perhaps. We can already see some of this emerging with features that let smartphone calls ring on computer systems, and let people make calls over their cellular service from their computer.
Could something similar to this be used to support mobility? Let’s suppose that Real-Tom is driving along with his smartphone, in a coverage area we’ll call Cell A. Virtual-Tom is living somewhere in the network, always accessible via some stable address or URL. If Real-Tom initiates a call, the network simply connects him to Virtual-Tom as Real-Tom-Cell-A, and makes the call, so Real-Tom is connected. Now, still driving, he moves into Cell B. Real-Tom connects to Virtual-Tom as Real-Tom-Cell-B and Virtual-Tom simply connects that new “device” into the call.
One issue with this approach relates to situations where Real-Tom Is traveling a long distance. At some point, the connection between Real-Tom and Virtual-Tom may be unwieldy. But let’s suppose that Virtual-Tom itself can be moved around, using the same approach. Virtual-Tom decides the connections to Real-Tom are getting problematic, so it asks the Virtual-Manager to rehost it in a better location. The Virtual-Manager could then, for example, reset the DNS that decodes the Virtual-Tom URL to that new location.
Or, perhaps, all the Virtual-People are given addresses in a special address space, one controlled by SDN. If Virtual-Tom moves, then the SDN controller gets an indicator from Virtual-Manager and rejiggles the route to Virtual-Tom. No matter how far Real-Tom travels, we can place Virtual-Tom optimally, and get an optimum route to both Toms.
You can see that if services are created as an overlay, a lot of connection responsibility and power is ceded to the overlay technology. Our Virtual-agent could be hosted, for example, in a metro center and moved to another only if we actually moved a significant distance. The Real-person would connect to the Virtual-agent on demand from any set of suitable devices, but services would see only the Virtual-agent, which means service connectivity could stop at the metro area. Would this enable us to rethink the underlying network model? That underlay only has to see metro areas, because Virtual-Agents can only be hosted there. If metro connectivity is all that’s needed, then we could create MPLS tunnels or SDN routes to metro areas and connect to our agents there.
Before we toss our current models, though, I want to reiterate that this is a presumed approach for service networks. We’d have to adapt it to the Internet and other services, but I want to make a point I’ve made earlier, which is that service networks can be virtual networks. In fact, I think that’s the direction we’re ultimately going to have to go. The same model could work for the Internet on the user side, but the relationship between Virtual-agent elements and the current Internet would be the same as it is now. The Virtual-agents would be an intermediary function, perhaps no more than a routing point.
All network services don’t have the same rules. Up to now, we’ve been trying to bend all services to one rule-set, that of IP and the Internet, because we wanted a common network technology that can support everything. We should want that, but we don’t have to surrender service-specific network features to get it. It’s one of the benefits of virtual networks, and one we should be working to explore and exploit.