The article originally appeared in the Jan./Feb. edition of INTERNET TELEPHONY.

It’s that time in the cloud hype cycle when we follow the profound advice given to Inigo Montoya in “The Princess Bride” to go back to the beginning. In the case of cloud, it means refocusing on the network and how to address the challenges arising from widespread virtualization and cloud computing adoption.

Virtualization and cloud computing, which have created more agile, fluid server infrastructures, have exposed the hard truth of brittle, inflexible underlying networks that, in order to handle the volatility in today’s architectures, have been cobbled together with scripts and file-based configurations.

Recognizing these techniques will likely not withstand the deluge of change and rate of growth putting pressure upon them (and their scripts and configuration files); the market is turning to virtualization to resolve the situation and create a network as fluid and as flexible as the application infrastructure it must support.

These efforts are now – whether accurate or not – lumped together into a single movement called software-defined networks (SDN). Like cloud, its definition is wispy and subject to interpretation, but in general its focus remains on imbuing the network with the agility necessary to bridge the widening gap between traditional network infrastructure and modern, agile application infrastructure.

One of the subsets of SDN focuses solely on the use of emerging and existing protocols to decouple networks from static, inflexible constructs such as the (now obviously poorly named) VLAN. Emerging tags and tunnels protocols from competing virtualization vendors – VXLAN and STT from VMware and NVGRE from Microsoft (News - Alert) – are competing with existing protocols such as VPLS, Q-in-Q, and GRE for mindshare, all attempting to be the next big thing in virtualization.

At issue for many organizations leveraging a dual (or more) vendor strategy to server virtualization is support for these emerging SDN-related standards not only in competing vendor products, but also in the network infrastructure, where support must also be enabled in order to fully execute on a network virtualization strategy.

Conversely, while existing protocols are generally supported by network infrastructure, even in a single-vendor server virtualization scenario, there may be gaps in hypervisor and operating system support for existing protocols.

That leaves implementers in a bit of a bind, doesn’t it?

Because the goal of SDN and nascent virtualization protocols is to create a virtual network decoupled from the underlying L2/L3 physical network, the case can be made that network infrastructure need not adapt at all in order to become more flexible. But such a view would be naïve and ignore the impact of virtual networking on the network regardless of native support for its protocols within the infrastructure.

Changes in packet sizes due to insertion of virtual network-supporting identifiers and the reliance on such protocols on multicast support are merely two facets of virtual networking that will impact the network regardless of native support.

And one could argue (convincingly, no doubt) that one of the roles of network infrastructure is to provide functions such as network protocol transition. The logical place to provide for transitioning between protocols is in the network, whether IPv4 to IPv6 or VXLAN to NVGRE.

And if the network is going to need to transition between two protocols, that implies the network is going to have to support both protocols.

That ultimately means network infrastructure is going to end up natively supporting these new protocols and playing a part in SDN. Look this year for a spate of vendors announcing support for both – and likely more – pieces of the SDN puzzle.

With the attention back on networking, and in particular network virtualization, it’s time to start formulating a strategy for implementing the next big thing: network virtualization.

Lori MacVittie is senior technical marketing manager at F5 Networks (News - Alert) (www.f5.com).