Skip to main content

3. Design Requirements

3. Design Requirements

Geneve is designed to support network virtualization use cases, where a logical network is overlaid on top of a physical IP network. The requirements for such a protocol are driven by the needs of the control plane, the capabilities of the data plane devices, and the desire for operational simplicity.

3.1. Data Plane

The data plane must be able to efficiently encapsulate and decapsulate packets. This implies:

  • Low Overhead: The encapsulation header should be as small as possible to minimize bandwidth usage and fragmentation.
  • ** Efficient Processing**: The format should be easy to parse and process in both hardware and software.
  • Protocol Agnostic: The protocol should be able to carry any type of inner traffic (IPv4, IPv6, Ethernet, etc.).
  • Multipathing: The protocol should support Equal-Cost Multipath (ECMP) routing in the underlay network.

3.2. Control Plane

The control plane is responsible for setting up the tunnels and distributing policy. The data plane protocol must support:

  • Decoupling: The data plane should not be tightly coupled to a specific control plane. It should be possible to use different control planes (e.g., SDN controller, BGP-EVPN) with the same data plane.
  • Extensibility: The control plane may need to attach metadata to packets to implement advanced features (e.g., security policies, service chains). The data plane must support a flexible mechanism for carrying this metadata.

3.3. Next-Generation Protocol Support

New protocols and capabilities are constantly emerging. Geneve is designed to be future-proof by:

  • Avoiding fixed fields: Aside from the minimum necessary for delivery, the header should not contain fixed fields that may become obsolete or insufficient.
  • TLV Options: Using a Type-Length-Value format for options allows new metadata types to be defined without changing the base protocol.

3.4. Options

One of the primary design goals of Geneve is to support variable-length options. Options are used to carry metadata between tunnel endpoints. This metadata can be used for a variety of purposes, such as:

  • Policy enforcement: Applying security groups or access control lists (ACLs).
  • Service chaining: Directing traffic through a sequence of middleboxes.
  • Telemetry: Carrying performance or debugging information.
  • Source identification: Identifying the source hypervisor or container.

3.5. Existing Implementations

Geneve is designed to be implementable on existing hardware and software platforms. While it supports advanced features, it should also be possible to implement a basic subset of the protocol on constrained devices.

3.6. NIC Offloads

Modern Network Interface Cards (NICs) provide offload features (such as checksum offload, Large Send Offload) to improve performance. Geneve is designed to be compatible with these offloads where possible, or to allow new offloads to be implemented efficiently.

3.7. Debugging and OAM

Operations, Administration, and Management (OAM) tools are essential for troubleshooting network issues. Geneve includes support for OAM packets (e.g., Ping, Traceroute) to verify connectivity and performance of the overlay network.