Wird GENEVE zum universellen Netzwerk-Encapsulation-Protokoll?

Das Netzwerk-Encapsulation-Protokoll GENEVE hat das Zeug zu einem universellem Standard, da es wesentlich flexibler ist als VXLAN, NVGRE und STT.

Sprechen wir über eine große, mandantenfähige (Multi-Tenant) Cloud, sind VLANs (Virtual LANs) unzureichend.

VLANs wurden in kleineren oder weniger komplexen Netzwerken lange Zeit verwendet, um Traffic zu isolieren. Allerdings spezifiziert der VLAN-Standard IEEE 802.1Q lediglich ein VLAN-Identifikator-Feld (Identifier) von 12-Bit.

Das 12-Bit-Feld entspricht ungefähr 4000 VLANs. Der Standard wurde ursprünglich in den 1990ern entwickelt und schien damals auszureichen. Mandatenfähige Clouds benötigen allerdings viel mehr individuelle Netzwerktunnel.

Um dieses Problem zu adressieren, haben Anbieter drei Lösungen vorgeschlagen: VXLAN, NVGRE und STT (Stateless Transport Tunneling). Alle drei kapseln Applikations-Datenpakete in ein neues Header-Format ein. Allerdings sind sie alle nicht zueinander kompatibel.

Die Header von VXLAN und NVGRE beinhalten ein 24-Bit-Feld. STT spezifiziert ein 64-Bit-Feld. Keines der Protokolle setzt eine Modifikation oder ein Austauschen existierender Switches und Router voraus. Einige Hardware-Anbieter haben allerdings Geräte entwickelt, um die Effizienz der einen oder anderen Lösung zu erhöhen.

Nun hat sich ein neuer Standard für Netzwerk-Virtualisierung entwickelt, der sich GENEVE (Generic Network Virtualization Encapsulation) nennt. Damit will man bestehende Grenzen der früheren Spezifikationen adressieren und alle Leistungsmerkmale von VXLAN, NVGRE und STT unterstützen. Viele sind der Meinung, dass GENEVE schlussendlich die früheren Formate komplett ersetzen kann.

GENEVE-Standard: Ein flexiblerer Vorschlag

Die Autoren des GENEVE-Vorschlags stellen die schnelle und fortlaufende Evolution von Netzwerk-Technologie heraus: Virtualisierung, private und Public Clouds, sowie SDN-Konzepte. Sie erwarten, dass sich alle Bereiche der entsprechenden Netzwerk-Technologie mit rasender Geschwindigkeit weiterentwickeln. Aus diesem Grund braucht man eine erweiterbare Lösung, um mit den Technologien auf Augenhöhe zu sein.

Das ausgewiesene Ziel von GENEVE ist, lediglich ein Encapsulation-Daten-Format zu definieren. Anders als frühere Formate enthält es keine Informationen oder Spezifikationen für die Kontrollebene. Die Autoren des GENEVE-Standards erklären:

„Es gibt einen klaren Nutzen, wenn man sich auf ein Datenformat einigt. Die meisten Protokolle unterscheiden sich lediglich oberflächlich und es gibt wenig Vorteile, indem man doppelten Arbeitsaufwand hat. Allerdings lässt sich das nicht auf die Kontrollebenen übertragen. Diese unterscheiden sich fundamental. Ein Argument für Standardisierung ist deswegen nicht so ersichtlich, da in Bezug auf Anforderungen, Ziele und Einsatz-Szenarios große Vielfalt herrscht.“

Um die Ziele von GENEVE zu erreichen, sollte das Daten-Format so flexibel und erweiterbar wie möglich sein. Die Entwickler geben zu, dass die 24-Bit-Tunnel-Identifikatoren in VXLAN und NVGRE, sowie das 64-Bit-Feld in STT mehr als ausreichend sind, um alle jemals notwendigen virtuellen Netzwerke zu spezifizieren. Sie gehen aber davon aus, dass künftige Entwickler das Feld unterteilen wollen, um neben dem Identifkator für das virtuelle Netzwerk noch andere Informationen zu übermitteln. Sie vergleichen potenzielle Anwendungsbereiche für dieses Feld mit den Statusinformationen eines Systems, die innerhalb virtueller Server ausgetauscht werden. Auch Linecards in einem Chassis-Switch sind in diesem Zusammenhang als Beispiel geeignet. Es herrscht die Meinung, dass man keine feste Feldgröße spezifizieren sollte, da diese möglicherweise für alle künftigen Anwendungs-Fälle nicht ausreichend ist.

Anstelle das Tunnel-Identifier-Feld zu unterteilen, stellt GENEVE ein Optionsfeld mit variabler Länge zur Verfügung. Jede Option liefert einen Options-Header, dem eine variable Menge an Options-Daten folgt. Nachfolgend finden Sie ein Beispiel:

Option Header

Option Class: Man wird IANA (Internet Assigned Numbers Authority) einbeziehen, um eine Option Class Registry zu erstellen. So kann jedem Unternehmen, das GENEVE-Optionen definieren möchte, einen Options Class Identifier zugewiesen werden.

Option Type: Unternehmen können Options-Typen innerhalb ihrer Option Class zuweisen. Das ist unabhängig von den Options-Typen anderer Organisationen.

Length: Länge der Optionsdaten.

Das Ziel dieses Formats ist es, Innovation vorantreiben. Sobald einem Unternehmen eine Option Class zugewiesen wurde, kann es Option Types innerhalb dieser Klasse definieren. Das lässt sich intern gut für Experimente verwenden. Einige neue Optionen sind sicherlich nicht sehr nützlich. Andere wiederum werden breite Akzeptanz finden.

Anmerkung der Redaktion: Im zweiten Teil dieser Artikel-Reihe beschäftigen wir uns detaillierter damit, wie GENEVE funktioniert. Weiterhin gehen wir auf Interoperabilität im Zusammenhang mit Netzwerk-Virtualisierung, Encapsulation und Tunneling ein.

Über den Autor:

David B. Jacobs hat mehr als 20 Jahre Erfahrung in der Netzwerkbranche. Er hat hochmoderne Software-Entwicklungsprojekte geleitet und „Fortune 500“-Unternehmen ebenso beraten wie Software-Startups.

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close