Open Networking mag zwar so klingen, als bestünde es aus zusammenarbeitenden Teilen, die für mehr Flexibilität sorgen, aber es ist schwieriger zu erreichen, als Sie vielleicht denken. [...]
Es gibt offen, und dann gibt es offen. Zumindest scheint das bei der Netzwerktechnologie der Fall zu sein. Vielleicht liegt es an der Popularität und dem Einfluss von Open-Source-Software, vielleicht aber auch nur daran, dass man bei dem Wort „offen“ an Wildheit, Glück und Freiheit denkt – was auch immer es ist, das Konzept der Offenheit in der Netzwerktechnik setzt sich immer mehr durch. Was natürlich bedeutet, dass die Definition jeden Tag unschärfer wird.
Wenn ich mit Unternehmen spreche, scheinen sie zu denken, dass Offenheit in Netzwerken das Gegenteil von proprietär ist, was sie dann als eine Technologie definieren, für die es eine einzige Quelle gibt. Das suggeriert, dass offenes Networking auf einer Technologie basiert, für die es mehrere Quellen gibt, aber so logisch das auch klingt, es hilft nicht viel.
Nehmen wir das allseits beliebte Konzept der White-Box-Switches und -Router. Sind das offene Netzwerke in Aktion? Wahrscheinlich nicht so sehr, wie man denken würde. Sind alle White-Boxen aus allen Quellen gleichwertig? Nein, und insbesondere verwenden sie oft unterschiedliche Netzwerkchips, die unterschiedliche Schnittstellen zur Software haben, was bedeutet, dass, wenn Sie Ihre White-Box-Software von einer White-Box zu einer anderen mitnehmen, diese möglicherweise nicht läuft.
Jeder weiß, dass Hardware heutzutage nur noch etwas ist, auf dem man Software laufen lässt, also was ist offene Software für Netzwerke? Ist es Open Source oder gibt es andere Kriterien, die man anwenden muss? Für Hochleistungsnetzwerke ist es tatsächlich schwer, ein echtes Open-Source-Paket zu finden, wegen dieser lästigen Netzwerkchips. Die Schnittstellen der Chips sind, wie oben erwähnt, unterschiedlich, so dass man ein PC-ähnliches „Treiber“-Konzept braucht, um eine einheitliche Software-Schnittstelle für alle Chips zu schaffen.
Es gibt Initiativen, wie die P4-Flow-Programmiersprache, die einen offenen Higher-Layer-Switch oder -Router mit einem lizenzierten P4-Treiber unterstützen könnten, aber nicht alle Chip-Anbieter unterstützen P4. Broadcom, der größte, hat seinen eigenen P4-Konkurrenten, die Network Programming Language oder NPL.
Sollten wir also zugeben, dass echtes Open Networking dem Untergang geweiht ist? Vielleicht nicht, denn es gibt noch ein anderes, komplizierteres Kriterium für Offenheit, und wir kommen dazu, indem wir uns anschauen, was Anwender an proprietären Netzwerken nicht mögen – Lock-in.
Was Sie an ein proprietäres Gerät bindet, ist offensichtlich: Sie können es nur von einem Anbieter bekommen. Was die Bindung erzeugt, ist, dass die teure Hardware und die Software gebündelt sind. Nehmen wir an, Sie lassen die Benutzer die „proprietäre“ Hardware und Software separat kaufen und andere Software auf der Hardware eines anderen Anbieters laufen oder umgekehrt? Wenn es wirklich alternative Hardware/Software-Mixe gäbe, die mit einem „proprietären“ und separaten Hardware/Software-Angebot erstellt werden könnten, wäre das zumindest „offener“? Die meisten Anwender sehen das so.
Das Gleiche gilt für White Boxes. Stellen Sie sich vor, Sie hätten einen White-Box-Router, auf dem nach dem Kauf ein halbes Dutzend verschiedener Netzwerksoftware-Komponenten laufen könnten? Die Hauptinvestition, die Anwender tätigen würden – die Hardware – ist zumindest einigermaßen vor Lock-in geschützt. Da es wahrscheinlich nur zwei große Chip-Forwarding-Sprachen gibt (P4 und NPL), ist es kaum unmöglich, ein Software-Paket zu erstellen, das mit jeder von ihnen funktioniert und eine Software-Router-Implementierung technisch über die meisten Geräte hinweg portabel macht.
Und ein geeigneter „Treiber“ könnte theoretisch die gleiche Router-Software auf Cisco- oder Juniper-Geräten zum Laufen bringen. Cisco hat über seine P4-Unterstützung gebloggt, aber die meisten Kommentare auf dem Blog stellten in Frage, ob Cisco selbst es verwenden würde, was sicherlich einige Zweifel an den Zusagen von Cisco aufkommen lässt. Juniper hat ebenfalls über seinen P4-Ansatz gebloggt, und es scheint, dass sie sich etwas mehr dafür einsetzen, es in ihrer eigenen integrierten Hardware/Software-Lösung zu verwenden.
Das wirft den ganzen Disaggregationswahn auf. Wenn Sie einen Router oder Switch disaggregieren, werden die Teile Teil eines Pools von austauschbaren Elementen, aus denen Sie alles Mögliche bauen können. Ihre Unabhängigkeit wird durch das Vorhandensein eines Pools garantiert, aus dem Sie auswählen können. Das bedeutet natürlich, dass man, um sinnvoll zu sein, tatsächlich einen Pool von Auswahlmöglichkeiten für die Teile haben muss, zumindest für Hardware und Software.
Das ist der erste Test, ob eine bestimmte Strategie wirklich offener ist, ob die Disaggregation die Risiken von Lock-in oder stranded assets adressiert hat. Wenn Ihnen ein Anbieter sagt, dass er einen disaggregierten Router hat, fragen Sie ihn, für welche Whiteboxen seine Software zertifiziert ist und welche andere Software auf seiner Hardware läuft. Fragen Sie dann, ob sie P4- und NPL-Treiber unterstützen und bereitstellen.
Das ist natürlich nicht der einzige Test. Auch die Preisgestaltung spielt eine Rolle. Wenn ein Router-Anbieter seine Router-Software nicht aufschlüsselt, aber 95 % der Gesamtkosten für die Hardware verlangt, haben Sie durch das Versprechen mehrerer Software-Optionen nicht viel gewonnen, da der Großteil der Kosten bereits versenkt ist. Ähnlich verhält es sich, wenn es einen Router-Software-Anbieter gibt, der den Großteil der Kosten eines proprietären Routers für seine Software in Rechnung stellt: Sie beseitigen möglicherweise nicht den Lock-in, sondern wählen nur aus, wer den Lock-in vornimmt.
Die ganze Sache mit der Offenheit wird schwieriger, wenn es um ein Netzwerk oder einen Teil eines Netzwerks geht und nicht um ein Gerät. Ein gutes Beispiel ist Open RAN, die beliebte offene Spezifikation für die Elemente des 5G-Funknetzes. Einige Anbieter werben bei Unternehmen dafür, privates 5G auf Basis von Open RAN einzuführen, und die Offenheit klingt für die meisten sicher gut. Das Problem ist, dass es möglich ist, mehrere Implementierungen eines offenen Standards oder einer Spezifikation zu haben, bei denen es sich aber jeweils um eine vollständige Implementierung handelt, deren Low-Level-Komponenten nicht ausgetauscht werden können, obwohl es sich um Implementierungen derselben Spezifikation handelt.
Auf der Netzwerkebene haben Sie außerdem das Problem der Integration. Wenn Sie schon einmal ein Puzzle zusammengesetzt haben, wissen Sie, dass eines mit fünf Teilen viel einfacher ist als eines mit 500. Die Dinge müssen richtig zusammenpassen, und in einem Netzwerk würden die meisten Benutzer zustimmen, dass es jemanden geben muss, der für den Betrieb des Ganzen verantwortlich ist. Offene RAN-Implementierungen können ein Dutzend Anbieter involvieren, also stellen Sie sich vor, wie viel Spaß ein Meeting zur Fehlerisolierung machen würde. Die Luft würde mit Fingern gefüllt sein.
Wie können Unternehmen eine kluge Entscheidung für offene Netzwerke treffen? Systematisch. Zunächst müssen Sie die harten Vor- und Nachteile, also Dinge, die Sie (hoffentlich finanziell) quantifizieren können, von den „weichen“ Vorteilen und Risiken trennen, wie „Unterstützung von Open-Source“ oder „mein Router-Anbieter wird mich nicht mögen“. Es ist in Ordnung, eine Entscheidung für ein offenes Netzwerk mit einer ungünstigen Bilanz von harten Vorteilen und Risiken zu treffen, aber erwarten Sie nicht, dass der CFO am Ende der Präsentation lächelt.
Der zweite Punkt ist, dass Sie Ihre offenen Optionen gegen Ihre quantifizierbaren Vorteile und Risiken abwägen. Lassen Sie die Anbieter oder Integratoren ihre eigenen Antworten abzeichnen. Sie möchten eine Auswahl treffen, bei der alle Kriterien erfüllt sind und keines der Risiken. Wenn zwei Optionen ähnliche Werte aufweisen, gehen Sie zurück und bewerten Sie jede erneut, um Ihre Ansicht zu verfeinern.
Zu guter Letzt sollten Sie Ihre Nutzen-Risiko-Annahmen in den Vertrag schreiben und alle Parteien dazu verpflichten, eine Regelung für den Fall zu treffen, dass ein Anbieter seine Versprechen nicht einhält. Wenn es mehrere Anbieter gibt, stellen Sie sicher, dass die Problemisolierung nicht zu einem Gladiatorenkampf wird. Das erreichen Sie, indem Sie die Regeln für die Zusammenarbeit in den Vertrag schreiben. Wenn jemandem dieser ganze Formalismus nicht gefällt, sollte er sich nach der nächsten Möglichkeit umsehen. Denken Sie daran, dass „offen“ nicht „keine Verpflichtungen“ bedeutet, denn Sie sind immer der Committer der letzten Instanz.
*Tom Nolle ist Präsident der CIMI Corporation, einer strategischen Beratungsfirma in Voorhees, New Jersey. Seine Projekte haben ihn in die ganze Welt und in fast jede Netzwerktechnologie geführt.
Be the first to comment