I blogged yesterday about the vCPE model of services, talking both about its role in NFV and how it might have a life outside/beyond NFV. Some of you were interested in what might be said about other new service models, and in particular how “interior” rather than edge models could work. My information on this topic is more speculative because operators have focused on vCPE and have really looked at only a few “interior” models, but I’m happy to offer what I have and draw some tentative conclusions.
Edge-related services, in my vernacular, are services that are normally associated with devices connected at or near the point of service connection. Interior services are thus the opposite; ones that don’t normally look like an extension of the access device. I’m not classifying service chains that support natural-edge functions as “interior services”; they’re virtualized services that happen to be hosted deeper. For my discussions I want to focus on the natural habitat of the service, not its hosted manifestation. I also want to exclude, for a later blog, the topic of interior services of routing, switching, and other connection functions.
Operators who have looked at NFV-driven service evolution have identified a number of possibilities for interior services, which I’ll list in order of operator mentions:
- Mobility, meaning IMS and EPC. This is the runaway winner in terms of interest.
- Content delivery networks (CDN) and the associated elements.
- “Distributed” network features such as load balancing and application delivery control.
- Hosting services, including web, email, collaboration, and cloud computing.
While there’s widespread interest in the mobility category of interior NFV targets, operators confess that there’s still a lot of confusion in terms of the “what” and the “why”. Operators have tended to divide into three groups by their primary goal. The largest is the “agility, elasticity, and cost” group that’s targeting a virtualized replacement of fixed IMS/EPC elements. This group isn’t seeing a major change in the conceptual structure of IMS/EPC, only elastic hosting of RAN, mobility management elements, HSS elements, and EPC components. The second “re-architect” group would like to see all the mobility elements redone architecturally based on current insights and current technology. The final group, “applications”, wants to focus on extending mobile services with applications and look to NFV to host the application components and integrate them with IMS/EPC.
Perhaps the most interesting of the “re-architect” concepts is framing the whole notion of EPC in SDN terms. Tunneling in the classic EPC sense may not be needed if you can control forwarding explicitly. In addition, if you presume that EPC components like PGWs and SGWs are virtual and cloud-hosted, might they not end up being adjacent for all practical purposes? If so what’s the value of having them as separate entities?
The content delivery area is less conflicted but still somewhat diverse in interests. It divides into two segments; operators primarily worried about mobile content delivery and operators looking for IP video offerings primarily as home viewing offerings. The first group is blending CDN and IMS/EPC virtualization into a single goal, and the second is looking at CDN and perhaps set-top box virtualization.
TV Everywhere is the primary focus of the first group, obviously. Operators who have multichannel video services are very interested in leveraging their assets, and those who don’t are looking perhaps to partnership relationships with others who do. A CDN, IMS-like user certification, and a strong virtual EPC could make TV Everywhere, well, go “everywhere.”
The distributed network features interests are the least focused, obviously in no small part because the category itself is so diffuse. For all the specific feature targets there are two sub-classes—a group who want to architect the concept for the virtual age and a group that simply wants to virtual-host elements.
Some distributed features, like DHCP and DNS, already exist and would likely be simply virtualized and made scalable in some form. But in both cases it would be helpful to explore how scaling for performance would be handled given that both DHCP and DNS servers are updated. Other features like load balancing and application performance management (“higher OSI layer” services) really have to be re-architected to be optimally useful when they’re employed in the cloud, particularly when they’re in front of a scalable community of components.
Many operators believe that the logical structure of these higher-layer, traffic-and-application-aware services is a distributed DPI capability. Most don’t see DPI being added to every trunk, but rather see it as something that would be hosted in multiple data centers and then used in a cooperative system of forwarding management. Some believe that DPI would also be coordinated with DNS/DHCP services, particularly for load balancing.
The last category of interior features are the hosted elements of today—things like web servers, mail, SMS/IM, collaboration, etc. Even cloud computing services could fall into this category. You might find it surprising that this item is last on the list, but the fact is that these services are typically not provided by the network (regulated) entity and most NFV planners come from that side of the house.
The questions that these services raise in the network sense are only starting to emerge. If you assume that the hosted element/service is either “on the Internet” or on a VPN/VLAN, then you could assume that the service might simply be made visible in the proper address space. However, some operators are looking at things like “bicameral email” where an email server has a VPN presence and a public SMTP presence and a security element between. Here we have something live in both worlds—Internet and VPN.
That model is of growing interest for hosted elements and applications. I’ve mentioned the idea of having “application-specific VPNs” created through SDN where every application or class of application has its own subnet, and where users are connected onto subnets based on what they’re allowed to access. This same approach, meaning the creation of what are essentially service-specific subnetworks, would also be valid for NaaS based on SDN technology, and some technology planners in the operator world think that some sort of SDN/NFV hybrid of connectivity and features would likely represent what all future services might look like.
This model could unite the edge and interior visions. It might also be the key to creating a useful mobile services model, one that can exploit things like IoT, location, social context, and so forth. That may seem counter-intuitive, so let’s look a bit at why that’s true.
If you think about NFV services, and in particular the notion of “interior” models, what you see is the notion of a service that’s almost everything-independent. It lives out there on its own hosted by some set of network-linked systems and represents connectivity or other experiences that a buyer finds valuable. The service is delivered by making an edge connection. We’d think of that connection as being one of a number of fixed-branch-site access pipes because that’s the typical VPN or VLAN model, but it would be perfectly feasible to envision a service as a kind of “meet-me” where users access a service on-ramp and obtain the service when needed.
That model suits mobility in two ways—first it is easily adapted to a roaming user, and second it adapts to the notion of a “personal assistant” or mobile-agency service models. It also suits the notion of a universal dmarc with NaaS on-ramps ready to be connected when needed, and with NFV-based services also there to be accessed as an application/service-specific subnetwork. In fact, if the model were in place, users would have a virtual persona in the network that they could contact from any device, and obtain the services they count on.
One interesting question which (like many, I confess) I don’t have a good answer to is whether edge and interior models of NFV services can grow naturally together to support this symbiotic model. So far, trials and use cases for both SDN and NFV are fairly contained and so something like this would be a major change of approach. But without a vehicle that moves both edge and interior forward, we might end up missing the change to help both missions, operators and vendors, and the market overall.
