Cisco’s announcement that it would host Arbor’s DDoS defense software on its Carrier Grade Service Engine is another indication that vendors are taking Network Functions Virtualization serious, though still perhaps not serious enough. Yes, we’re hearing more about hosting functions, but we’re still not hearing about an architecture.
You can look at most forms of network security as being a kind of policy-controlled forwarding. Normally you do packet forwarding by looking stuff up in a table and forwarding to the port you find during the lookup. A firewall might block a port by simply forwarding to nowhere (not forwarding at all). You might shut off a denial of service attack by not forwarding the packet streams from offending sources to a destination under attack. The point is that there are two dimensions to the security process—changing forwarding policies and deciding when to change them. It’s not unlike SDN in that respect.
Security in software is a virtual function too, right? Not exactly. It could be implemented something like SDN could be, which means that you could visualize this kind of forwarding-based security as a device cooperating with some hosted process that decides when to change the rules. That’s NFV-like. It could also be implemented as an in-line function, as firewalls are typically implemented today. Putting service intelligence in a general-purpose line card like this may demonstrate the sort of function hosting that the NFV people have in mind, but not the independence from network appliances that drive NFV in the first place.
This raises a couple of questions. First, is the goal of virtualizing functions to make them hostable in a general sense (meaning hosting on a line card is OK) or is it to host on a cheap general-purpose server the goal? Second, are vendors jumping onto hosting stuff on line cards to preempt some of the benefits of NFV? Juniper had already claimed service chaining of virtual functions was an SDN application. Cisco doesn’t promote their Arbor thing as an NFV strategy, so might vendors be looking at their own NFV model, one that links “virtual functions” not with specialized appliances but with generalized line cards in switches and routers?
For the first question, while the NFV white paper makes it clear that the goal is hosting functions on industry-standard servers, it’s true that if vendors were to offer a line-card hosting option that wasn’t super-expensive, it might find acceptance with operators. The line card would be specific to the vendors’ own equipment but it also might be more efficient. If we presumed that security was implemented by actually passing a packet flow through the security software, having that software on the device would almost certainly make forwarding more effective.
For the second question, vendors like Cisco and Juniper might be tweaking the letter of NFV definition and (in Juniper’s case) wrapping the result in SDN to make the picture more palatable. If that’s the case, then the success of NFV as an open concept would depend on it explicitly adopting an open model that, like SDN, separated virtual functions from vestigial device handling in an explicit way. If we had line cards that provided the controlled-forwarding mechanism I described earlier, then those cards could be supported by centralized, hosted, software that controlled the forwarding using some open standard. The problem of proprietary behavior comes from the integration of both control and data handling in the same security software tool, because if that’s done then you have a powerful incentive to host the security where the data is being handled, and you’re back to a proprietary device.
Architecture is the answer to this sort of thing. You can’t express goals these days and not have vendors try to achieve them in a way that maximizes their own profits. That is likely to have the effect of minimizing the cost reductions the goals included, of course. NFV can secure its goals only by specification of enough architecture detail to nail down the implementation options. Even then, as SDN evolution shows, vendors will try to secure the spirit of the change while violating the letter of the processes. We have a lot of people talking about the definition of SDN when formally speaking SDN has been defined all along. What they’re doing is modifying the definition of SDN to establish or protect commercial interests. The same thing could well happen with NFV—even more easily given that NFV doesn’t have at this point any detailed standards or architectural models. There are a lot of ways that you can say you meet a goal.