Distri-Award
– Jetzt zur Umfrage!

Suchen

Disaggregierung, distribuierte SDNs und modularer Code Der klassische Router ist tot

| Autor / Redakteur: Hannes Gredler / Dipl.-Ing. (FH) Andreas Donner

Aktuelle Carrier-grade Router sind schwerfällig, teuer und bereits heutigen Anforderungen kaum mehr gewachsen. Damit Router-Designs aktuellen und zukünftigen Herausforderungen gewachsen sind, müssen grundlegend neue Router-Hard- und -Software entwickelt sowie moderne Software-Architekturen eingeführt werden.

Firma zum Thema

Klassische Router sind mit unnötigen Funktionen und Features überladen. Neue Konzepte müssen her!
Klassische Router sind mit unnötigen Funktionen und Features überladen. Neue Konzepte müssen her!
(Bild: RtBrick)

Seit ihren Anfängen in den 1980er Jahren haben sich Netzwerkrouter entschieden weiterentwickelt. Den größten Entwicklungssprung konnte man bei der Einführung des World Wide Web beobachten. Hier standen Netzwerkanbieter plötzlich vor der Herausforderung, mit der raschen Einführung von Internetdiensten und der Nachfrage nach bandbreitenintensiven Anwendungen Schritt halten zu müssen. Um dem Bedarf nachzukommen, investierten sie Unsummen in ihre Netzwerke, wobei sie große Mühe hatten diese zu refinanzieren. Sie wandten sich an die Hersteller von Netzwerkequipment mit der Bitte, beim Aufbau von Mehrwertdiensten zu helfen, was in den darauffolgenden Jahren zu einer Flut immer neuer Features führte, die heute für nahezu jeden Router verfügbar sind.

Kritiker argumentieren, dass zwar immer neue Funktionen hinzugefügt, veraltete jedoch nicht entfernt werden, was die Kosten für die Router so hat ansteigen lassen, dass diese nicht mehr im Verhältnis zum eigentlichen Nutzen stehen. James Hamilton, VP und Distinguished Engineer bei Amazon Web Services, brachte diese Beobachtung wie folgt zum Ausdruck: „Das Netzwerk ist Anti-Moore.“ In diesem Geiste sollen im Folgenden einige Funktionen betrachtet werden, die im Laufe aktueller technischer Entwicklungen redundant geworden sind.

Hardware-Buffer

In ihrem Paper Sizing Router Buffers (2004), beschreiben Forscher der Stanford Universität ihre Beobachtung, dass Buffer mit einer Tiefe von bis zu 2000 ms eindeutig für Dienste mit geringer Bandbreite und Datenstrom-Vielfalt gut geeignet sind. Doch bei Geschwindigkeiten von mittlerweile 10 GBit/s und einer Vielfalt von bis zu 10 Millionen Datenströmen, werden bei einer typischen Internet-Backbone-Verbindung die Vorteile eines Bufferings höchst zweifelhaft.

Der Nutzen wird auch dadurch infrage gestellt, dass beim „Buffern“ keine Signalisierung an den Transmission Control Protocol Layer (TCP) vorhanden ist. Die meisten Router unterstützen jedoch immer noch eine Buffer-Tiefe von über 100 ms für 100-GBit/s-Schaltungen. Eine einfache Berechnung zeigt, dass so für jeden 100 GBit/s-Port in einem gegebenen Router 1,25 GB DDR4-RAM benötigt werden.

Genau dieser DDR4-RAM, die mitunter teuerste Form von Arbeitsspeicher, macht den Buffer zum größten Kostentreiber für heutige Router-Hardware. Nicht nur wird er für eine Funktion benötigt, die bei heutigen Internet-Backbone-Nutzungsmustern nur selten funktioniert. Gleichzeitig muss er als Off-Chip-Speicher implementiert werden, wodurch die Kosten für externe E/A, Stromverbrauch und Kühlung steigen.

Hardware-Forwarding Tables

Der zweitgrößte Kostenfaktor für die Datenebene eines Routers ist die Größe seiner Forwarding Table. Moderne Hardware kann ungefähr 2 Millionen Forwarding Einträge in ihren IPv4-, IPv6- und MPLS-Forwarding Tables speichern. Das Design dieser Forwarding-Engine basiert auf zwei Grundgedanken:

Ein einzelner Forwarding-Eintrag kann einen hohen Datenverbrauch haben

Tatsächlich kann bereits ein einzelnes Präfix die gesamte Bandbreite einer Verbindung beanspruchen. Dies ist auch heute noch relevant, da Content Delivery Networks und Web-2.0-Unternehmen einen großen Teil ihres Internetverkehrs auf nur wenige IP-Präfixe lenken.

Alle Forwarding-Einträge können die volle Verbindungsbandbreite tragen

Dies gilt heute nicht mehr. Der Verkehr pro Präfix im Internet ist exponentiell gestiegen, was bedeutet, dass das Chipdesign für das Data Forwarding radikal überarbeitet werden muss. Anstatt jeden IP-Forwarding-Eintrag gleichwertig zu behandeln, ist eine Speicher-Cache-Hierarchie deutlich praktikabler. Diese ist vergleichbar mit heutigen Computerdesigns: Eine gestufte Speicherhierarchie mit verschieden gelevelten Speichern, die jeweils unterschiedlich schnell sind, bei adäquaten Kosten.

Moderne IP-Router arbeiten immer noch auf nur einem Speicher-Level, in der Annahmen, dass jeder Forwarding-Eintrag schnell sein muss. Schaut man sich die Analyse der realen Backbone-Verkehrsdaten jedoch genauer an, ist dies schon lange nicht mehr der Fall. Tatsächlich sind die Forwarding Tables für den zeitgemäßen praktischen Einsatz heute um das 10-fache überdimensioniert.

Die gute Nachricht ist, dass sich die Hardware leicht optimieren lässt. Kunden müssen lediglich klar formulieren, was in der Regel benötigt wird, sodass die nächste Generation der Forwarding Hardware dementsprechend angepasst werden kann. Die Netzwerksoftware stellt dagegen eine ganz eigene Art von Problem dar.

Software-Funktion

Es ist schwierig zu sagen, welche Software-Funktionen tatsächlich redundant sind und welche nicht, da diese von den individuellen Bedürfnissen der Telekommunikationsunternehmen abhängig sind. Im Laufe der Zeit haben Hersteller auf Wunsch der Netzwerkbetreiber unterschiedlichste Features entwickelt und direkt in den Code eingefügt. Diese Vorgehensweise macht es jedoch unmöglich, bestimmte Funktionen nach der Implementierung wieder zu deaktivieren. Dies kann schnell zu einem Kostenfaktor werden, da Netzwerkbetreiber diese Features selbst dann bezahlen müssen, wenn sie nicht genutzt werden. Gleichzeitig müssen bei der Einführung einer neuen Funktion jedes Mal Interferenztests für alle bestehenden Funktionen durchgeführt werden müssen – selbst für diejenigen, die nicht benötigt werden.

Hintergrund ist, dass Router-Software bisher als monolithisches System programmiert wurde, wobei neue Funktionen eng mit der zugrundeliegenden Infrastruktur verknüpft wurden. Die Entfernung solcher Funktionen aus der Codebasis kann dabei so aufwändig werden, wie ihre ursprüngliche Entwicklung. Gleichzeitig wird die Hürde für eine Funktionserweiterung mit jedem neuen Feature höher.

Im heute stark umkämpften Telekommunikationsmarkt sind Service Provider jedoch drauf angewiesen, dass ihre Systeme agil, leicht zu warten und auf ihre Bedürfnisse sowie die ihrer Kunden abgestimmt sind. Entsprechend müssen Hersteller von Router-Systemen einen neuen, kostengünstigeren Ansatz entwickeln, der es Netzwerkbetreibern ermöglicht, flexibel und reibungslos Funktionen zu verwalten, zu updaten und wenn nötig auch wieder zu entfernen.

Die Lösungsformel = Disaggregierte Systeme + distribuierte SDNs + modularer Code

Der erste Schritt in die richtige Richtung ist die Disaggregation von Hardware und Software. So können Netzwerkbetreiber zwischen verschiedenen Bare-Metal-Switches und für diese validierte Netzwerksoftware wählen sowie sich die neuesten Chipgenerationen zunutze machen und dadurch ihr Innovationspotential stärken. Das bedeutet jedoch gleichzeitig, dass die Verantwortung für das Funktionsmanagement voll und ganz bei den Netzwerkbetreibern liegt. Ein distribuiertes Software-Defined Network (SDN) bietet hierfür die idealen Voraussetzungen. Es verbindet die Vorteile eines SDN mit den Vorzügen einer distribuierten Steuerungsebene und ermöglicht so eine reibungslose Verwaltung der Software.

Um ein reibungsloses Hinzufügen und Entfernen von Funktionen zu gewährleisten, sollte der Code so aufgebaut sein, dass er sich beliebig aus einzelnen Code-Blöcken zusammenstellen lässt. Diese sollten beliebig ergänzt oder auch wieder herausgenommen werden können, wobei es keine Interdependenzen zwischen den Blöcken geben darf. Hier kann ein „Internet-nativer“ Ansatz helfen. Dabei werden unabhängige Mikrodienste verwendet, die in Containern ausgeführt werden. Wird eine neue Funktion oder ein Update benötigt, wird ein entsprechender Container vom Softwareentwickler geliefert, der innerhalb von Millisekunden und ohne Unterbrechung des Dienstes das jeweilige Feature aktualisiert oder hinzufügt. Auf diese Weise ist die Routenverarbeitung, Aktualisierung und der Neustart 20-mal schneller als bei herkömmlichen Router-Betriebssystemen. Stehen darüberhinaus offene Schnittstellen zur Verfügung, können Netzwerkbetreiber sogar ihre eigenen Funktionen entwickeln und implementieren.

Fazit

Traditionelle Router und dynamische Steuerungssysteme werden durch neue Konzepte, wie Disaggregation und distribuierte SDNs herausgefordert. Diese versprechen eine signifikant schnellere Implementierung, automatisierte Steuerung und eine kürzere Markteinführungszeit. Damit künftige Router-Designs diesen Herausforderungen gewachsen sind, müssen grundlegend neue Router-Hardware und -Software entwickelt sowie moderne Software-Architekturen und -Paradigmen eingeführt werden.

Ergänzendes zum Thema
Die Vorteile eines SDN mit einer distribuierten Steuerungsebene

SDN:

  • mehr Agilität beim Hinzuzufügen und Testen neuer Services
  • hohe Programmierbarkeit, bei der jedes Netzwerkattribut übergeordneten Systemen zugeordnet/ entgegengesetzt wird
  • geringere Kosten aufgrund kostengünstiger Bare-Metal-Hardware sowie der Automatisierung von Arbeitsabläufen

Distribuierten Steuerungsebene:

  • geringeres Risiko aufgrund der Robustheit des stark verteilten Kontrollsystems
  • etwaige Systemausfälle werden auf ein Netzwerkgerät begrenzt
  • höhere Skalierbarkeit, die auch durch die E/A-Grenzen eines einzelnen Controllers nicht eingeschränkt wird
  • einfache Bedienbarkeit und Migration von Netzwerkelemente
  • können auch neben älteren Routern betrieben und von klassischen SDN-Systemen gesteuert werden

Hannes Gredler.
Hannes Gredler.
(Bild: RtBrick)

Über den Autor

Hannes Gredler ist Mitbegründer von RtBrick und als CTO des Unternehmens zuständig für Engineering, Technologie-Roadmap und Systemarchitektur. Aktuell arbeitet er an Routing-Software der 3. Generation für offene Netzwerk-Hardwaresysteme. Hannes Gredler verfügt über langjährige Erfahrung im Bereich der Router-Systemen-Entwicklung. Er hat unter anderem 15 Jahre bei Juniper Networks an dem Design und der Implementierung der Routing- und Signalisierungsprotokolle BGP, OSPF, IS-IS und MPLS gearbeitet.

(ID:46826280)