Editor's note: In the first part of this two-part series on the network encapsulation protocol GENEVE we examined...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
how the technology differs from VXLAN, NVGRE and STT. In this second half, we explain how GENEVE works and how it could lead to interoperability in network virtualization overlay tunneling.
For one, 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.
How GENEVE encapsulated packets are communicated
GENEVE encapsulated packets are designed to be communicated via standard backplanes, switches and routers. Packets are sent from one tunnel endpoint to one or more tunnel endpoints using either unicast or multicast addressing.
The end-user application and the VMs in which it is executing are not modified in any way by GENEVE. Applications generate identical IP packets as if they were communicating via hardware switches and routers. The destination IP address included in the packet is significant only within the cloud tenant's virtual network.
The tunnel endpoint then encapsulates the end-user IP packet in the GENEVE header, adding the tunnel identifier specifying the tenant's virtual network followed by any options. The header consists of fields specifying that it is a GENEVE packet, the overall length of the options if any, the tunnel identifier and the series of options.
The completed GENEVE packet is then transmitted to the destination endpoint in a standard UDP packet. Both IPv4 and IPv6 are supported.
The receiving tunnel endpoint strips off the GENEVE header, interprets any included options and directs the end-user packet to its destination within the virtual network indicated by the tunnel identifier.
The GENEVE specification offers recommendations on ways to achieve efficient operation by avoiding fragmentation and taking advantage of Equal Cost Multipath and NIC hardware offload facilities. The spec also offers options on how to support differentiated services and explicit congestion notification.
Interoperability and transition with GENEVE
The authors of the GENEVE specification do not foresee problems when GENEVE and one or more of the other encapsulation methods are in use in the same system. GENEVE tunnel endpoints will communicate only with other GENEVE endpoints and packets are handled by the network infrastructure identically to any other UDP packet.
The GENEVE data format supports all of the capabilities of VXLAN, NVGRE and STT, so eventually use of the three earlier formats may disappear. Since GENEVE doesn't specify a control plane protocol, the spec's authors expect it to support any protocol in use with the other encapsulation methods.
GENEVE's flexible option format and use of IANA (Internet Assigned Numbers Authority) to designate Option Classes are key benefits over the other encapsulation methods. Developers can include as many or as few options as they wish without being limited to 24 bits or incurring the overhead of a 64-bit field when only a fraction of that size is needed.
Application developers will be able to choose options from any Option Class without interoperability problems. Each option will be uniquely identified by its Option Class and Type so there will be no conflicts between options developed by different organizations.
Transition to GENEVE, if it occurs, will not be immediate. The other encapsulation methods have been in use for some time, and multiple methods can operate within the same system. Also, some hardware vendors have developed performance enhancements designed for one or more of the other methods.
As experience with multi-tenant clouds develops, no single encapsulation method may emerge, but GENEVE, with its flexible option format and support for all of the capabilities of the other methods, will be a strong candidate for wide adoption.
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 start-ups.