What Might Intel’s Open Network Platform Mean?

There’s a clear difference between dispatching an ambulance to an accident scene and chasing one there, as we all know.  There’s also a difference between a company reacting opportunistically to a market trend and a company actually shaping and driving that trend.  Sometimes it’s hard to tell the difference in this second area, and so it is with Intel’s announcement of a reference implementation of a server architecture for networking.

Trends like the cloud and SDN and NFV are driving servers into a tighter partnership with networking.  I’ve been saying for months that the future of IT was going to be created by the shift from IT as a network service access point to IT as a network component.  That’s what the cloud really means.  And Intel seems to know that, whatever is driving their interest, because they’re participating and not just product-washing.  In the NFV space, for example, they’re a more thoughtful and active participant than most of the network equipment vendors.

Intel’s Open Network Platform reference design includes the Wind River Open Network Software suite and a toolkit for creating tightly integrated data-plane applications.  The platform will implement an open vSwitch and the toolkit means that other vSwitch architectures, including we think the Nuage/Alcatel-Lucent one, could be implemented easily on the platform.  So at the minimum Intel may be voting with its R&D and positioning dollars that things like SDN and NFV are real.  At best, it might be taking steps that will actively drive the process.

One of the most important points I cited in Alcatel-Lucent’s Nuage launch was that the new SDN model the two companies promote is an end-to-end hybrid of virtual-overlay networking (what I’ve called “software-defined connectivity”) and real device-SDN networking.  The Intel platform seems to encourage the creation of a new model of highly functional virtual device, one that could form the branch edge of a network as easily as the server side.  This model would encourage the creation of application VPNs or what Alcatel-Lucent calls “software-defined VPNs”.  It could be deployed by enterprises, and also by network operators, and it could be linked by common central control down to policy-based or even route-based special handling at the traffic-connection level.

Perhaps the most profound impact of the Intel step could be the impact is has on NFV, and I don’t mean just the ability to create better server platforms to host virtual functions.  The value of the NFV concept, if it’s contained to network operators, will be slow in developing and limited in scope.  Intel might be framing a mechanism to link NFV to what it frankly should have been linked to from the first—the cloud.  NFV as a cloud element is NFV for enterprises, which is a much bigger market and a market that will move opportunistically with demand for cloud-specific services.  Thus, Intel might be at least attempting to single-handedly make NFV mainstream and not an operator science project that could take years to evolve.

The most general model for a network-coupled IT environment is an as-a-service model where all functional elements are represented by URLs and RESTful interfaces.  In such a model it doesn’t matter what platform hosts the functional element; they all hide behind their RESTful APIs.  That model is likely the ideal framework for NFV, but it’s also the ideal framework for the evolution of cloud services and the creation of a cloud virtual operating system that hosts a currently unimaginable set of new features and applications, for workers, and consumers.  This may be the NFV model Intel is thinking about.

The Intel step may put network vendors in the hot seat.  Alcatel-Lucent has already committed to a hybrid virtual-overlay-and-real-SDN-underlay approach, a model that tends to commoditize enterprise network hardware.  That’s fine for them because they’re not enterprise incumbents, but what do Cisco and Juniper and the other smaller enterprise players do?  Even for carrier applications like the metro cloud I’m always harping on, there’s a necessary marriage between the virtual-overlay stuff Intel’s ONP proposes to host and the metro Ethernet and fiber networks that build aggregation and backhaul.  A formalistic link between virtual-overlay and real device networks may be mandatory now, and that link to be useful has to elevate the former above Level 2, link it effectively to the cloud and to componentized software architectures, and then bind it in a general way to the real device networks that alone can move real traffic in high volumes.

Make no mistake, Intel’s ONP doesn’t replace specialized switching and routing and the major layers of transport networking.  An x86 platform running any UNIX derivative with the BSD enhancements could have done that for decades (and in fact the first Internet routers were servers like this).  We got specialized devices for traffic-handling because they’re better at that mission, and that’s almost surely true now and forever.  However, every time we add IT intelligence to a service we have a traffic-terminating mission from a network perspective, and that’s what Intel is optimizing for.  If they’re aggressive and clever in their support for things like Quantum, DevOps, SDN, and NFV, they’ll have a major leg up on an important server mission of the future.

Leave a Reply