Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

GENEVE primer: A universal network encapsulation protocol?

The GENEVE network encapsulation protocol is more flexible than VXLAN, NVGRE and STT and does everything they can do. Will it replace them entirely?

When it comes to the large, multi-tenant cloud, Virtual LANs (VLANs) are broken.

While VLANs have long been used to isolate traffic within smaller or less complex networks, the IEEE 802.1Q VLAN standard specifies just a 12-bit VLAN identifier field.

This 12-bit field, or roughly 4,000 VLANs, seemed sufficient in the 1990s when the standard was originally developed, but large multi-tenant clouds require many more individual network tunnels.

To tackle this problem, vendors have proposed three solutions: VXLAN, NVGRE and Stateless Transport Tunneling (STT). All three encapsulate application data packets in a new header format, but none are compatible with each other.

VXLAN and NVGRE headers both include a 24-bit field. STT specifies a 64-bit field. None requires modifying or replacing existing switches and routers, although some equipment vendors have developed hardware assists to increase the efficiency of one or more of the solutions.

Now a new network virtualization standard has emerged -- Generic Network Virtualization Encapsulation (GENEVE) -- that promises to address the perceived limitations of the earlier specifications and support all of the capabilities of VXLAN, NVGRE and STT. Many believe GENEVE could eventually replace these earlier formats entirely.

GENEVE standard: A more flexible proposal

The authors of the GENEVE proposal point to the rapid, ongoing evolution of networking technology: virtualization, public and private clouds and SDN concepts. They expect that all aspects of network technology will continue to evolve at the same rapid pace; and an extensible solution is required to evolve along with the technology.

The stated goal of GENEVE is to define an encapsulation data format only. Unlike the earlier formats, it does not include any information or specification for the control plane. The GENEVE standard authors state:

"There is a clear advantage in settling on a data format: most of the protocols are only superficially different and there is little advantage in duplicating effort. However, the same cannot be said of control planes, which are diverse in very fundamental ways. The case for standardization is also less clear given the wide variety in requirements, goals and deployment scenarios."

To achieve GENEVE's goals, the data format should be as flexible and extensible as possible. The authors agree that the 24-bit tunnel identifier field in VXLAN and NVGRE and 64 bits in STT are more than sufficient to specify all of the virtual networks that will be required, but they expect that future developers will want to subdivide this field to carry information other than the virtual network identifier. They compare potential uses of this field to the system state information currently exchanged within virtualized servers or between line cards in a chassis switch. They observe that no fixed field size can be specified that will be sufficient for all possible future uses.

Rather than subdivide the tunnel identifier field, GENEVE adds a variable length option field. Each option consists of an option header followed by a variable amount of option data. The following is an example:

Option Header

Option Class: IANA (Internet Assigned Numbers Authority) will be asked to create an Option Class Registry and allocate option class identifiers to any organization that wishes to define GENEVE options.

Option Type:  Organizations can allocate Option Types within its assigned Option Class independent of any other organization's Option Types.

Length:               Length of the option data

The goal of this format is to encourage innovation. Once an organization is allocated an Option Class, it can allocate Option Types within that class to support internal experimentation. Some new options will not prove useful but others will be widely adopted.

Editor's note: Read part two of this series, which looks further into how GENEVE works, and at how it lends itself to interoperability in network virtualization, encapsulation and tunneling.

About the author:
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.

Next Steps

VXLAN gateways integrate virtual and physical resources

Virtual overlay networks for multi-tenancy

Making the way for hybrid network virtualization

This was last published in July 2014

Dig Deeper on SDN network virtualization

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Will GENEVE replace VXLAN and NVGRE?
As noted in the article "They observe that no fixed field size can be specified that will be sufficient for all possible future uses." I think this is correct, I was around when TCP/IP was being developed and was still called "DOD Protocol" I connected my first "DOD Protocol address on a Digital Equipment Corp. VAX 11/780 to an IBM Main Frame System. We simply do not yet realize the gravity of changes coming in the Network space and the amazing technologies yet to be dreamed of.