We’re a long way from the scheduled end of the ETSI NFV ISG’s work, but the initiative is already spawning implementations and perhaps a tad of NFV-washing. We have two more NFV-related announcements to talk about today, in fact. One represents the “mainstream” of NFV activity among vendors and the other represents a second orchestration implementation.
Any NFV implementation ultimately needs virtual functions to deploy, and in theory pretty much any current network software, embedded or hosted, could be made into a virtual function. The level of work needed would depend on just how much the NFV platform expected its deployable functions to participate in deployment and management processes. Procera, a member of the ISG, has announced “NFV” virtualization of its policy control and DPI software.
Virtual PacketLogic platforms are cloud-hosted versions of custom policy elements in a variety of network applications to control traffic flows based on traffic type, subscriber, etc. I’ve long believed that in the two-tier SDN model I see as the future, policy control is a valuable coupler between the upper connectivity layer and the bottom traffic-handling layer. It’s very possible that Procera’s software-based approach would facilitate that kind of integration, though there’s nothing in the release to offer specific insight into that point.
There’s no question that the Procera approach is virtual, or that it’s cloud-ready, but it may be a bit early to say that it’s NFV. The problem is that it’s not yet clear what being “NFV-ready” would mean. The ISG has not fully defined the requirements for hosted virtual functions, and in particular the NFV platform services that they’d be expected to use. It’s not clear whether multiple copies of the Procera stuff could be created ad hoc for scale-out, and how traffic could be shared among them. It’s also not clear whether this logic could be composed into end-to-end services or share with existing IMS components, since the ISG has not yet defined exactly how a service that deploys once for multiple uses (like all the IMS elements for example) would be treated versus one that deployed per-user (like managed firewall).
Despite the fact that we can’t prove that Procera is really NFV, we can’t prove it isn’t either, and it still proves some valuable points. First, it shows that there will be a source of useful virtual functions to be deployed when NFV implementations are available. That’s critical because without them there’s no business case for NFV. Second, it shows that many of those involved in NFV implementation are thinking cloud when they think of the infrastructure to be used. I’ve said all along that the implementation of NFV is facilitated by presuming a cloud management system sits between iron and NFV. Third, it shows that the NFV process has game, that it is considered an asset to brand something as being compatible with NFV. Commercial forces will sustain momentum for any effort that gets enough good publicity to become a marketing platform for vendors. Eventually they have to implement it, and improve their implementation, to retain access to the bully pulpit that NFV represents.
What I’d like to see from players like Procera is a complete re-architecting of the “old” notions of policy control, content delivery, and other mobile/metro services. As I’ve said before, it makes no sense to take a flexible technology and stake it to the ground by replicating the exact devices we’re replacing.
For my other NFV announcement, I turn to Amartus Software Defined Service Orchestration (SDS). Amartus is focusing not on the virtual functions but on network service orchestration, which makes it a bit more like CloudBand. However, comparisons between SDS and CloudBand make it clear that there are going to be a lot of different approaches to the ETSI NFV process.
Amartus is different from CloudBand first and foremost because it’s not focused on virtual functions at all, it’s focused on the automated provisioning and lifecycle management of business network services. CloudBand is about hosting functions in the cloud and SDS doesn’t host functions at all. Amartus is also about service modeling and the conversion of those models into end-to-end services, where CloudBand is more about the deployment of virtual functions and relies on higher-layer OSS/BSS processes to model and create/connect end-to-end services.
There’s a lot to like about the Amartus approach, particularly the notion of creating a set of abstract service models that are instantiated by linking them to an API. It seems to me that this concept could be fairly easily extended to drive a cloud management API set and deploy virtual functions, which would make Amartus into a real NFV architecture. Amartus also integrates classical FCAPS management into their architecture and models, which is at least congruent with how I think NFV management has to work, but it’s not integrated with hosted service features because Amartus doesn’t host them. Finally, Amartus doesn’t at this point model consumer or “infrastructure” services, though I don’t see why they couldn’t make changes to do that too.
Overall, Amartus hasn’t gone the last mile in creating NFV integration, which means that they are tantalizingly close to being a true NFV orchestration package but not yet there. The company was not in the NFV ISG when I looked yesterday, but they indicated they were in the process of joining it. I’d suggest they do that and then look at how they could add in the seemingly minimal elements needed to make SDS into NFV SDS.
What Amartus shows, in addition to the value of NFV association, is that there are many products out there that could be pressed into service as a foundation for NFV deployment and management. I’d welcome as many approaches from as many different directions as we can get, because if this NFV stuff is to be made to work we need as much hard experience and real-world deployment as we can get to pick the best options. NFV’s stated goals of cost savings can be met only if we optimize implementation, and the value of NFV as the future platform for cloud service operationalization is even more delicately balanced on the edge of implementation efficiency. We have to get this right, and every test and trial helps.