I wrote on Friday about the demand-side evolution of network function virtualization and the importance of framing an NFV story within a broader revamping of service management and operations. Today we have two more NFV-related data points that again demonstrate that moving to a software-driven vision of network features is complicated—and likely to be competitive.
Alcatel-Lucent, Fujutsu, and NTT announced a research partnership aimed at developing the ideal telecom-industry server, and said that this relationship would expand “with the goal of creating advanced technology, increasing its level of sophistication, and achieving early feasibility checking. The project aims to establish new server architecture that will enable the three partners to develop service applications at an early stage…..The desire of the involved companies is to see this technology spread and become a global standard.”
It’s pretty obvious that NFV is a “service application”, and Alcatel-Lucent’s CloudBand is the only full-scale NFV implementation that’s both public and has specific credibility with operators in my surveys. Of course, all of NFV and the cloud runs on servers, and Alcatel-Lucent doesn’t make servers. The fact that this venture would produce servers and server standards suggests to me that Alcatel-Lucent has determined it needs to be more than just a supplier of software for NFV and carrier cloud, it has to be a full-service solution provider. That could speak volumes for how a telecom giant sees the NFV space.
NFV is a standards-based initiative, right? Well, if we assumed that NFV were driven by completely open standards and processes you could argue that having a complete NFV solution from servers to software wouldn’t be necessary. In fact it might be an expensive diversion of resources. But if NFV is in fact going to be rolled out by major vendors in generally proprietary ways, then you either have a complete solution or you’re a market non sequitur. Alcatel-Lucent’s partnership here would be a good defense against that kind of marginalization.
Why might they believe in at least semi-proprietary NFV, though? I think there are two reasons. First, the exploding scope of benefits operators are looking for NFV to produce, and second a specific competitive dynamic in the market.
NFV started with the notion that hosting functions on COTS would be cheaper than middle-box technology from proprietary sources. That’s true to at least some extent, but the key point is that it’s a benefit that can be realized almost per-middle-box. I’ve pointed out that further discussion with operators, including those actually driving NFV, shows that they now see improvements in opex and service velocity as the key benefits. These benefits are achieved only if you redo operations practices overall, not just host some functions. That means a lot of scope and change are needed, and most of it is technically out of the scope set for itself by the ETSI NFV ISG. That’s why I suggested a TMF partnership would be in order.
But so would a full-service NFV strategy, because for now at least, we have no standards to define the holistic kind of revolutionary operations future that operator goals now dictate. Operators tell me they are more than eager to generate lower opex and faster service velocity. That, plus no standards, equals lots of specialized vendor opportunity. As a leader in telco infrastructure and integration, it would be amazing if Alcatel-Lucent didn’t see dollar signs here.
Even more amazing if they didn’t see competition, and guess who I think Alcatel-Lucent is almost surely focusing on? Cisco, the arch-rival in the routing layer. Cisco, according to my surveys, has been showing operators a proprietary approach to NFV and of course Cisco’s UCS means they have servers to include in their offering. Cisco also has the ability to marry SDN and NFV for end-to-end services, so they can take a step outside strict ETSI NFV to enhance benefits. Obviously, Alcatel-Lucent’s SDN strategy also supports that kind of extension, making the two obvious rivals for the Big Pie.
For Alcatel-Lucent to fight Cisco with their server hands tied behind their back is a big risk. Of course, that means that for server players like Dell and HP to fight for NFV share without a specific and highly differentiable software strategy is similarly risky. We may be seeing the first steps in the bulking up of NFV into complete solutions. If so, the question of just how wide the benefit scope of these “complete” solutions will be will loom large.
Against this backdrop, we have the second development—Metaswitch’s announcement of Clearwater Core, a subscription-service professionally supported version of its open source Project Clearwater IMS. I’ve noted a number of times that Metaswitch had the only example of a cloud-and-virtual-function-ready network service I could find, and with Clearwater Core they’re stepping out of being a validation framework into being something you can deploy. Again the question is “why now?” and I think the answer is a combination of evolution of NFV and regulatory policy.
You could adapt Project Clearwater to a standard management and orchestration framework, if there were one. If NFV is indeed going to be deployed using more proprietary tools to address the operations and service agility goals, then the Project Clearwater code will likely have to be customized for the specific the major NFV platform providers—likely the major network equipment vendors. Clearwater Core provides a professional services framework in which that can be done, which is smart.
Regulatory changes are creating a demand-side driver too. The evolution from TDM to IP voice for wireline voice services raises the question of how you provide next-gen telco-grade voice. If you look at wireline voice over IP, you find it’s a kind of immobile subset of mobile LTE IP voice. You can build a wonderful telco-quality voice service on a combination of WebRTC, SBCs for session data path assurance, and IMS for subscriber management. You don’t need mobility management for wireline so you don’t need full IMS. Clearwater Core could be just the ticket for semi-OTT voice services, not as laissez-faire as traditional Skype-like voice services and likely more easily harmonized with the FCC’s and other regulators’ goals of maintaining high-reliability voice services with lawful intercept and E911.
Clearwater Core may be demonstrating how close “the cloud” and “NFV” really are. Some network applications that are very static, like IMS, may well be more cloud-like. Some cloud applications like CDN or transaction processing may be more NFV-like. Certainly an implementation of NFV that supersets virtual functions with high-level service composition could be extremely powerful in the cloud. So the cloud could funnel away some applications of NFV, and could empower a larger mission at the same time. I bet vendors are looking at both possibilities.