3. Design Requirements (Designanforderungen)

Geneve wurde entwickelt, um Anwendungsfälle der Netzwerkvirtualisierung zu unterstützen, bei denen ein logisches Netzwerk über ein physisches IP-Netzwerk gelegt wird. Die Anforderungen an ein solches Protokoll ergeben sich aus den Bedürfnissen der Steuerungsebene, den Fähigkeiten der Geräte der Datenebene und dem Wunsch nach betrieblicher Einfachheit.

3.1. Data Plane (Datenebene)

Die Datenebene muss in der Lage sein, Pakete effizient zu kapseln und zu entkapseln. Dies impliziert:

Low Overhead (Geringer Overhead): Der Kapselungs-Header sollte so klein wie möglich sein, um Bandbreitennutzung und Fragmentierung zu minimieren.
** Efficient Processing (Effiziente Verarbeitung)**: Das Format sollte sowohl in Hardware als auch in Software einfach zu parsen und zu verarbeiten sein.
Protocol Agnostic (Protokollunabhängig): Das Protokoll sollte in der Lage sein, jede Art von innerem Datenverkehr zu übertragen (IPv4, IPv6, Ethernet usw.).
Multipathing (Mehrwege-Routing): Das Protokoll sollte Equal-Cost Multipath (ECMP) Routing im Underlay-Netzwerk unterstützen.

3.2. Control Plane (Steuerungsebene)

Die Steuerungsebene ist für den Aufbau der Tunnel und die Verteilung von Richtlinien verantwortlich. Das Protokoll der Datenebene muss unterstützen:

Decoupling (Entkopplung): Die Datenebene sollte nicht eng an eine bestimmte Steuerungsebene gekoppelt sein. Es sollte möglich sein, verschiedene Steuerungsebenen (z. B. SDN-Controller, BGP-EVPN) mit derselben Datenebene zu verwenden.
Extensibility (Erweiterbarkeit): Die Steuerungsebene muss möglicherweise Metadaten an Pakete anhängen, um erweiterte Funktionen (z. B. Sicherheitsrichtlinien, Service Chains) zu implementieren. Die Datenebene muss einen flexiblen Mechanismus zur Übertragung dieser Metadaten unterstützen.

3.3. Next-Generation Protocol Support (Unterstützung für Protokolle der nächsten Generation)

Neue Protokolle und Fähigkeiten entstehen ständig. Geneve ist so konzipiert, dass es zukunftssicher ist, indem es:

Avoiding fixed fields (Feste Felder vermeidet): Abgesehen vom Minimum, das für die Zustellung erforderlich ist, sollte der Header keine festen Felder enthalten, die veraltet oder unzureichend werden könnten.
TLV Options (TLV-Optionen): Die Verwendung eines Type-Length-Value-Formats für Optionen ermöglicht die Definition neuer Metadatentypen, ohne das Basisprotokoll zu ändern.

3.4. Options (Optionen)

Ein primäres Designziel von Geneve ist die Unterstützung von Optionen variabler Länge. Optionen werden verwendet, um Metadaten zwischen Tunnel-Endpunkten zu übertragen. Diese Metadaten können für eine Vielzahl von Zwecken verwendet werden, wie z. B.:

Policy enforcement (Durchsetzung von Richtlinien): Anwendung von Sicherheitsgruppen oder Zugriffskontrolllisten (ACLs).
Service chaining (Service-Verkettung): Lenkung des Datenverkehrs durch eine Abfolge von Middleboxes.
Telemetry (Telemetrie): Übertragung von Leistungs- oder Debugging-Informationen.
Source identification (Quellidentifikation): Identifizierung des Quell-Hypervisors oder Containers.

3.5. Existing Implementations (Bestehende Implementierungen)

Geneve ist so konzipiert, dass es auf bestehenden Hardware- und Softwareplattformen implementiert werden kann. Während es erweiterte Funktionen unterstützt, sollte es auch möglich sein, eine grundlegende Teilmenge des Protokolls auf eingeschränkten Geräten zu implementieren.

3.6. NIC Offloads (NIC-Offloads)

Moderne Netzwerkschnittstellenkarten (NICs) bieten Offload-Funktionen (wie Checksum Offload, Large Send Offload), um die Leistung zu verbessern. Geneve ist so konzipiert, dass es nach Möglichkeit mit diesen Offloads kompatibel ist oder die effiziente Implementierung neuer Offloads ermöglicht.

3.7. Debugging and OAM (Debugging und OAM)

Operations-, Administration- und Management-Tools (OAM) sind für die Fehlerbehebung im Netzwerk unerlässlich. Geneve beinhaltet Unterstützung für OAM-Pakete (z. B. Ping, Traceroute), um die Konnektivität und Leistung des Overlay-Netzwerks zu überprüfen.