Seminar aus Systemintegration Sommersemester 2000

Prof. Dr. Hermann Hellwagner Institut für Informationstechnologie - Systemintegration

Thema: Active Networks

Active Network Architectures

Martin Roscher, 9560442

Inhalt: 1. Einleitung................................................................................................................................3 2. ALIEN ....................................................................................................................................3 2.1 Einleitung ..........................................................................................................................3 2.2 Das Design von ALIEN ....................................................................................................3 2.3 Die Wahl der Programmiersprache ...................................................................................4 2.3.1 Anforderungen an die Programmiersprache ...............................................................4 2.3.2 Die Programmiersprache Caml...................................................................................5 2.3.3 Andere Programmiersprachen.....................................................................................5 2.4 Der ALIEN-Lader .............................................................................................................5 2.5 Das Core Switchlet............................................................................................................6 2.5.1 Funktionalitäten des Core Switchlets..........................................................................6 2.6 Die Library ........................................................................................................................6 2.7 Die Programmierung .........................................................................................................7 2.7.1 Anordnung von Funktionalität im Schichtenmodell...................................................7 2.7.2 Aktive Programme ......................................................................................................7 2.8 Schlussbemerkung.............................................................................................................8 3. PROTEAN..............................................................................................................................8 3.1 Allgemeines.......................................................................................................................8 3.2 Die Aktive-Router-Architektur .........................................................................................8 3.3 Virtual Network Context...................................................................................................9 3.4 Programmieren eines PROTEAN-Routers......................................................................10 3.5 Die State-Management-Architektur ................................................................................10 3.5.1 Erzeugung und Wartung eines Kern-Netzwerkes.....................................................11 3.5.2 Verbreitung/Synchronisation der Daten....................................................................11 3.5.3 Das State Management im Einsatz - technische Details...........................................11 3.6 Fallstudie .........................................................................................................................12 3.7 Schlussbemerkung...........................................................................................................12 4. Abrechnungsmodell für paketorientierte Netzwerke............................................................13 4.1 Allgemeines.....................................................................................................................13 4.2 Prinzip .............................................................................................................................13 4.3 Das Tarifsystem...............................................................................................................14 4.4 Eine Implementierung mit Java.......................................................................................15 4.5 Illustration .......................................................................................................................16 4.6 Schlussbemerkung...........................................................................................................17 5. Vergleich...............................................................................................................................18 6. Weitere Architekturen ..........................................................................................................19 6.1 RCANE ...........................................................................................................................19 6.2 ALAN und XML .............................................................................................................19 7. Problematiken und abschließende Bemerkungen.................................................................20 8. Literatur ................................................................................................................................20

1. Einleitung Netzwerke werden heutzutage recht unterschiedlich verwendet. Die Applikationsvielfalt reicht von simplen Telnet-Anwendungen über das WWW bis hin zu Multimedia und auch bis zur Sprachtelephonie und zu Videokonferenzen. All diese Applikationen haben verschiedene Ansprüche, sei es nun eine sichere Verbindung oder aber eine konstante mit kontinuierlichem Datenfluss, bei welcher der Verlust von einigen Datenpakten unter Umständen auch verkraftbar ist. Des weiteren unterscheidet sich häufig auch die Umgebung der Netzteilnehmer. Es kann zwischen stationären (z.B. via Stand- oder Wählleitung verbunden) und mobilen Teilnehmern unterschieden werden. Aufgrund der großen Komplexität der Applikationen, die über Netzwerke übertragen werden, muss zu neuen Maßnahmen gegriffen werden. Eine Möglichkeit ist es, die Netzwerke selbst aktiver werden zu lassen. Um dies zu erreichen, müssen Netzwerkressourcen wie die Bandbreite, der Speicher und die CPU-Zeit von Routern und Switches durch den Anwender konsumierbar und verwaltbar, d.h. programmierbar gemacht werden. Folgende Grundvoraussetzungen gelten jedoch: Die Performance des Netzwerkes darf nicht stark unter diesen Erneuerungen leiden. Die einzelnen Prozesse bzw. Datenflüsse dürfen sich nicht ungewollt, gegenseitig beeinflussen. Des weiteren soll das System sicher bleiben und nicht anfällig für DoS (denial of services) Attacken werden. Im folgenden werden einige Architekturen vorgestellt, welche aktive Netzwerke ermöglichen. Es handelt sich hierbei um ALIEN, eine Schichtenarchitektur, um PROTEAN, einem eventorientierten Ansatz, und um ein "Abrechnungsmodell für paket-orientierte Netzwerke". Diese Architekturen werden beschrieben und anschließend gegenübergestellt. Schließlich werden diese Architekturen durch zwei weitere ergänzt. RCANE ähnelt hierbei der Struktur von ALIEN, geht jedoch näher auf die Aufteilung von Ressourcen ein. "ALAN und XML" ist ein Ansatz, der auf älteren Cache-Technologien aufbaut und somit ebenso erwähnenswert ist.

2. ALIEN 2.1 Einleitung ALIEN [ALI] verwendet eine Architektur, welche sowohl active extensions (programmable switch) als auch active packets (Kapseln) unterstützt. Dadurch geht es auf die Anforderungen von aktiven Netzwerken direkt ein. Ein Ziel ist es, dem Softwareentwickler Programmierfreiheit und damit auch Flexibilität zu bieten. Andererseits sollen auch Services wie Multiprozessfähigkeit angeboten werden, welche zwar die Funktionalität erhöhen, gleichzeitig aber die Freiheiten reduzieren. Das Hauptaugenmerk von ALIEN liegt darin, eine Balance zwischen Flexibilität, Anwendbarkeit, Sicherheit und Performance zu erreichen. 2.2 Das Design von ALIEN Das Ziel von ALIEN war es, Experimente zu erlauben und einen Prototypen zu erstellen, um die Ideen der aktiven Netzwerke zu testen. Die Experimente sollten sowohl mit aktiven Extensionen als auch mit aktiven Paketen funktionieren. Ein Augenmerk wurde zudem auch auf die Performance gelegt.

Es wurde eine Turingfähige Programmiersprache gewählt (Caml). Ressourcenteilung sollte unterstützt werden. Zudem verwendet ALIEN nur einen einzelnen Adressraum innerhalb des gesamten Netzwerkes, was die Kommunikation erleichtern soll. Es wurde davon ausgegangen, dass die Hardware (Router) kein Speicher Management unterstützt. Weitere Ziele waren es, das System flexibel zu machen. Das heißt, dass das System zur Laufzeit stark veränderbar ist. Um dies zu erreichen, entschied man sich für ein geschichtetes Design mit einem kleinen Kern von unladbarer Funktionalität. Die Schichtenarchitektur von ALIEN sieht folgendermaßen aus: unprivileged loadable privileged loadable privileged non-loadable

Libraries Core Switchlet Loader Runtime (Caml) OS (Linux)

Abb. 1 Schichtenarchitektur von ALIEN Der ALIEN Loader stellt die niedrigste Schicht dar. Er wird beim Start des Systems angestoßen. Der Lader lädt das Core Switchlet. Dieses lädt verschiedenen Libraries, welche nicht privilegierte, aber vom Anwender erwartete Services sind. 2.3 Die Wahl der Programmiersprache 2.3.1 Anforderungen an die Programmiersprache Die vorweggenommene Entscheidung für einen einzelnen Adressraum und die Anforderungen gewisser Eigenschaften machten eine sorgfältige Auswahl der Programmiersprache notwendig. Vor allem folgende Eigenschaften sollten nach Vorstellung der Entwickler von der Sprache erfüllt werden. 1. 2. 3. 4. 5. 6.

Strong typing Garbage collection Module thinning Dynamisches Laden Einheitliche Darstellung von Aktiven Programmen, und Performance

Strong Typing und Garbage Collection wurden der Sicherheit wegen gewählt. Strong Typing gewährleistet, dass Variablen auch wirklich einen bestimmten Typ besitzen und dass folglich Funktionen auch nur mit den dazugehörigen Variablentypen aufgerufen werden. Durch die Garbage Collection soll verhindert werden, dass durch einen ansonsten möglichen Aufruf von free() alte Werte ungewollt an fremde Programme freigegeben werden. Module Thinning wird eingesetzt, um mehrere Interfaces erzeugen zu können. Das Ziel ist es hierbei, durch das Verdünnen (engl. to thin) des Interfaces die Zugriffsmöglichkeiten zu steuern. Zum Beispiel könnte ein Interface, das für den Zugriff auf Daten zuständig ist, den Zugriff nur auf das Lesen reduzieren.

Dynamisches Laden ist selbstverständlich notwendig, da einerseits Aktive Pakete geladen werden und andererseits Funktionalitäten dynamisch von der Library nachgeladen werden. Unter einer Einheitlichen Darstellung der Aktiven Programme ist zu verstehen, dass diese auf jedem Kotenpunkt identisch aussehen, was wiederum die Komplexität reduziert. Auch Zwischendarstellungen (Code mit bereits berechneten Variablen) sollten transportierbar sein. Auch die Performance soll nicht außer acht gelassen werden, da Messwerte zur Bewertung des Systems gewonnen werden sollten. Das System sollte des weiteren auch Threads unterstützen. Wäre dem nicht so, müssten diese schlussendlich selbst ausprogrammiert werden. Zudem wurden statische Variabeltypen gewählt. Diese erlauben das Überprüfen bereits zur Übersetzungszeit. Dies ist dadurch außerdem auch nur einmal nötig. 2.3.2 Die Programmiersprache Caml Objective Caml ist eine Sprache der ML-Familie. Es unterstützt Strong Typing und Garbage Collection. Der Caml-Compiler erzeugt Bytecode für die meisten Unix Varianten und ebenso für Microsoft Windows 95. Zudem kann er Native Code für Alpha und Intel X86 und weitere Systeme erzeugen. Dynamisches Laden wird nur von der Platte unterstützt. Aufgrund dessen wurde eine kleine Erweiterung der Caml Library entwickelt. 2.3.3 Andere Programmiersprachen Als Alternative wäre Java in Betracht gekommen. Es wäre jedoch nötig gewesen, gewisse Teile in C zu schreiben, wodurch der große Vorteil von Java, nämlich die Portierbarkeit, sofort zunichte gemacht wäre. Das Entwickeln einer eigenen Sprache wie etwa Netscript oder PLAN wäre ebenso zur Diskussion gestanden. Doch hat dies den Nachteil, dass eventuelle Designfehler später nur schwer oder gar nicht behebbar sind. 2.4 Der ALIEN-Lader Der ALIEN-Lader stellt das Herz der Funktionalitäten von ALIEN dar. Er stellt das Interface zum Betriebssystem dar und bietet ein paar essentielle Funktionen, die zum Systemstart und zum Laden der Aktiven Programme benötigt werden. Der Lader ist nicht ladbar und wird so klein wie möglich gehalten. Im allgemeinen sollten alle Teile von ALIEN gut ersetzbar (sprich nachladbar) sein. Der Lader bietet Mechanismen (z.B. Sicherheitsalgorithmen) an. Strategien (z.B. Sicherheitsprotokolle) sind im Core Switchlet implementiert und müssen dort geändert werden.

Die Hauptaufgaben des Laders sind: • • •

Systeminitialisierung (beinhalten die Initialisierung aller Elemente, die von ALIEN benötigt werden) Laden Aktiver Programme unter Berücksichtigung der besonders kritischen Sicherheitsaspekte Zur Verfügungsstellung von Administrationsmöglichkeiten (die Eingabe von Befehlen wird dem Operator über eine Konsole ermöglicht)

2.5 Das Core Switchlet Das Core Switchlet befindet sich über dem Lader. Es repräsentiert das Interface, welches die aktiven Programme sehen können. Es bedient sich des Laders, um auf das Betriebssystem zuzugreifen und fügt zusätzlich Mechanismen für die Sicherheit und Hilfsfunktionen hinzu. Es ist selbst ladbar und kann dadurch geändert werden (upgrade). Die Sicherheitsvorschriften werden durch Module Thinning und Typensicherheit realisiert. 2.5.1 Funktionalitäten des Core Switchlets Das Core Switchlet stellt ein Interface dar, das den Zugriff zu den darunterliegenden Ressourcen kontrolliert. Folgende Funktionalitäten werden angeboten: • Programmiersprachliches Grundgerüst (Berechnungen, Schleifen, Verzweigungen, usw.) • Zugriff auf das Betriebssystem • Netzwerkzugriff • Verfügbarkeit von Threads • Laden aktiver Programmer • Logging Das Core Switchlet kontrolliert den Zugriff auf all die oben genannten Ressourcen. Beim Netzzugriff ist es oft notwendig, statistische Daten wie die Anzahl der empfangenen und versendeten Pakete zu erhalten. Zudem muss entschieden werden, wie Pakete bei Multiplexing zwischen mehreren Anwärtern aufgeteilt werden. D.h. es stellt sich die Frage, wer und ob jemand das Paket erhält. Beim Laden ist zu entscheiden, wer welche Funktionen aufrufen darf. Zudem wird notiert, wer welche Funktionalitäten zur Verfügung stellt. Auf Grund der begrenzten Ressourcen gibt es beim Message Logging Einschränkungen. Das Logging kann auf verschiedenen Medien ausgeführt werden (z.B. Festplatte, Bildschirm,..), doch muss es keine Garantie für den Erfolg geben, da der Speicherplatz zum Beispiel auf eine gewisse Anzahl von Nachrichten beschränkt sein kann. 2.6 Die Library Die Library bietet Funktionalitäten, die nützlich sind, jedoch keine privilegierte Ausführung benötigen. Welche Funktionen angeboten werden sollen, wird noch untersucht. Für die Experimente wurden Funktionalitäten für IP und UDP implementiert.

2.7 Die Programmierung

2.7.1 Anordnung von Funktionalität im Schichtenmodell Es ist nicht immer offensichtlich, in welcher Schicht sich eine Funktionalität zu befinden hat. Es wurden deshalb folgende Prinzipien aufgestellt: Sollte es möglich sein, eine Funktionalität in einer Library unterzubringen, so soll dies auch so gemacht werden. Baut eine Funktion auf Elementen der Runtime auf, welche nicht bereits verfügbar sind, so ist der Loader oder das Core Switchlet zu erweitern. Da diese Teile allgemeine Funktionen darstellen, sollten die Änderungen so gering wie möglich sein und sich auf den grundlegendsten Teil beschränken. Der Rest gelangt in eine Library. Als dritte Regel gilt, dass Funktionen, die Sicherheitsvorschriften setzen, im Core Switchlet realisiert werden. Letztendlich sollen reine Mechanismen im Core Switchlet platziert werden, insofern sie nicht bereits vorher benötigt werden. 2.7.2 Aktive Programme Das Hauptziel ist es, dass Programme ausgeführt werden, deren Code nicht im Vorhinein bekannt ist. Es kommen entweder aktive Erweiterungen oder aktive Pakete in Frage. Aktive Erweiterungen Aktive Erweiterungen können entweder von der lokalen Platte oder über das Netzwerk geladen werden. Nach dem Laden kontrolliert Caml, ob das Programm mit den (verdünnten) Interfaces überhaupt ausgeführt werden kann. Das Interface, welches dieses Paket exportiert, wird in die Symboltabelle eingetragen. Es besteht auch die Möglichkeit, dass man Funktionsnamen im Vorhinein registriert. Dadurch ist es möglich, Aufrufe zu deklarieren, auch wenn die aufzurufende Funktion (callee) noch nicht geladen wurde. Aktive Pakete Zum Behandeln von aktiven Paketen muss ALIEN einige Libraries laden. Die Pakete von ALIEN sind ANEP-gekapselt wie in folgender Grafik zu sehen ist: Link Layer Header

ANEP Header

Code

Daten

Funktionsname

Abb. 2 Struktur von ANEP-Paketen Zuerst wird von einer Library der Header analysiert. Es wird die Ausführungsumgebung festgestellt. Die Authentifikation kann auch in dieser Phase geschehen. Wenn ALIEN nun diese Paket endgültig übernimmt, ist es für das Ver- und Entpacken (marshalling und unmarshalling) zuständig. Der Code wird dynamisch in den Speicher geladen. Die Funktion wird registriert. Anschließend wird so vorgegangen, wie bereits bei den aktiven Erweiterungen beschrieben.

2.8 Schlussbemerkung ALIEN verwaltet nicht alle Ressourcen. Der Heap wird noch immer Caml überlassen. Multiplexing liegt in der Hand von Linux. Sicherheitsprobleme, die dort auftreten, können nicht behandelt werden. Die Behandlung von Fehlern wird noch nicht gut unterstützt. Fehlende Datagramme können schnell zu einem Versagen der Programme führen. Ansonsten soll ALIEN laut [ALI] ein gut funktionierendes System sein, welches schnell, flexibel und sicher ist. Leider kann ich diese Aussage weder bestätigen noch verneinen, da mir weitere Information wie beispielsweise Testergebnisse fehlen. Zu kritisieren wäre, dass bisher noch wenig bis gar nicht geforscht wurde, welche Funktionalitäten in die Libaries gelangen sollten. Meiner Meinung nach handelt es sich bei den Funktionalitäten der Libaries um besonders wichtige Funktionalitäten, vor allem wenn es darum geht, das System als Ganzes zu beurteilen. Ohne konkrete Beispielesapplikationen (in Form von aktiven Programmen bzw. aktiven Extensions mit deren verwendeten Libaries) ist es schwer, dieses Systeme mit anderen zu vergleichen und es zu bewerten. Die 3-Schichten-Architektur als solches ist gut durchdacht. Sie erlaubt nicht nur das laden aktiver Programme sondern sie ermöglich auch ein rasches Update des Systems, indem zum Beispiel das Core-Switchlet ausgetauscht wird. Es ist zu hoffen, dass an ALIEN weitergearbeitet wird, sodass genauere Aussagen über das System getroffen werden können.

3. PROTEAN 3.1 Allgemeines Bei PROTEAN [PRO] handelt es sich um eine event - orientierte Netzwerkarchitektur, welche es erlaubt, Applikationen, Services und individuelle Datenflüsse den Kundenwünschen anzupassen. Gleichzeitig bleiben die gewohnten Datenflüsse erhalten. Wie bei anderen Netzwerkarchitekturen üblich, ist es möglich, auf den einzelnen Knoten Services zu erzeugen, diese zu propagieren und sie in Anspruch zu nehmen. Gleichzeitig ist es möglich, auf lokale und nicht lokale Daten (Stati) zugreifen und diese zu modifizieren. Auf diese Art und weise können Beispielsweise Reservierungen der Bandbreite über gesamte Pfade gemacht werden, oder man kann auf die Routing-Tabelle anderer Router zugreifen. Der Zugriff auf die Stati wird durch ein eigenes State Management ermöglicht. Im folgenden wird das Systems näher beschrieben. Es wird vor allem auf die Active-RouterArchitektur und das State Management eingegangen. 3.2 Die Aktive-Router-Architektur Die Architektur eines PROTEAN-Netzwerkes ist in Abbildung 3 abgebildet. Applikationen können auf Services zugreifen. Auf bereits vordefinierte Services kann man direkt zugreifen. Eigene Services werden von einem „Distributed Services Manager“ verwaltet. Definierten Events (z.B. das Eintreffen eines Paketes) werden dabei Event-Handlern (auszuführender Code) zugewiesen. Um auf lokale und nicht lokale Stati zuzugreifen, steht den Servicen das State Management zur Verfügung. PROTEAN übernimmt sämtliche Tätigkeiten, die für die Verwaltung der im Netzwerk verstreuten Stati notwendig sind. Mit Hilfe des State

Managements ist es sozusagen möglich, das Netzwerk und nicht nur die Knoten selbst zu programmieren. Als Beispiel wurde hierzu bereits die Reservierung von Bandbreiten über einen gesamten Datenweg genannt.

Applications

Default Services Application Injected Services

Virtual Network Context Abstraction

Access Services

Distributed Services Programming and Runtime Framework

Manager

Events, Event Handlers (Services)

Network State Abstraction

Access State

State Manager

Abb. 3 Architektur von PROTEAN [PRO]

3.3 Virtual Network Context Der PROTEAN-Router basiert auf einem event - orientierten Modell. Events sind die Haupteinheiten, welche mit Event - Handlern assoziiert werden. Ein Event / Event-HandlerPaar stellt hierbei ein Service dar. Eine Menge von Services wird mit einem Datenweg assoziiert und als Virtual Network Context (VNC) bezeichnet. Jeder Datenfluss ist einem VNC zugeordnet und wird innerhalb von diesem behandelt. Folgende Komponenten formen ein VNC: • •

Der Weg des Datenflusses innerhalb des Routers. In traditionellen Routern ist dieser typischerweise immer identisch. Bei aktiven Netzwerken kann dieser jedoch den aktuellen Bedingungen angepasst werden. Events, Event-Handlers und Service. Ein Service besteht hierbei aus einem Event / Event-Handler-Paar. Ein Event kann entweder bereits vordefiniert sein oder neu erzeugt werden.

•

Der VNC Status-Bereich. Wie auch bei den Events gibt es hier die Unterscheidung zwischen Default-Statusvariablen (wie z.B. die Routing-Tabelle, CPUBeanspruchung, etc.) und neu definierten Statusvariablen. Als Beispiel für selbstdefinierte Variablen sei die Beanspruchung der Nachbarsknoten genannt. Der PROTEAN-Statusmanager würde in diesem Fall die Überwachung der Werte und deren Konsistenthaltung übernehmen.

Ein PROTEAN VNC würde also wie folgt aussehen: VNC : = (dataPath, (Service1, Service2, ...), stateSpace) wobei ein Service die Form (event1, eventHandler1) hat. VNCs sind hierarchisch strukturiert. Kinder erben Services ihrer Eltern. Eine andere Möglichkeit, VNCs zu erstellen, ist es, diese von Grund auf neu zu entwerfen.

3.4 Programmieren eines PROTEAN-Routers Die Programmierung eines PROTEAN-Routers kann auf mehrere Arten geschehen: Defaultmäßig wird der naheste Vorgänger als VNC für einen Datenfluss herangenommen. Wünscht man eigene Anpassungen, so hat man folgende drei Möglichkeiten: • Man erbt einen der vorgegebenen VNCs zur Gänze. • Man verwendet nur Teile eines VNCs. • Man erzeugt einen VNC vollkommen neu. Zur dritten Möglichkeit muss jedoch hinzugefügt werden, dass es sich um keine explizite, komplizierte Setup-Phase handelt, sondern lediglich um eine Zuweisung der Events zu deren Event-Handlern. Die Erzeugung eines VNCs ist demzufolge implizit und nicht explizit.

3.5 Die State-Management-Architektur Das Ziel des State-Managements ist es, nicht-lokalen Status zugänglich zu machen. Gewünscht wird zusätzlich, dass das State-Management konsistent, skalierbar, mit geringem Overhead belastet und robust ist. Diese Ziele sind jedoch wiedersprüchlich. Je mehr nichtlokale Daten verwaltet werden, desto größer ist der Overhead für das Konsistenzmanagement. Je dynamischer das Netzwerk sein soll, desto wahrscheinlicher wird es, dass Daten veraltet sind. PROTEAN verwendet in seinem Ansatz 2 Konzepte: • Das Netzwerk ist hierarchisch in Clusters eingeteilt. Ein Knoten in dem Cluster verwaltet nur nicht-lokale Daten innerhalb eben diese Clusters. • Es wird ein selbst-konfigurierende Kern-Infrastruktur erzeugt und verwaltet. Diese dient anderen Knoten dazu, auf Daten zuzugreifen und diese zu modifizieren. Durch die erste Maßnahme wird der Bereich, in dem nicht-lokale Daten verwaltet werden, eingeschränkt. Die zweite Maßnahme dient zur Systematisierung der Datenzugriffe.

3.5.1 Erzeugung und Wartung eines Kern-Netzwerkes Ein Kern-Netzwerk besteht aus Kernknoten und aus Tunneln, welche die Kern-Knoten verbinden. Das Kern-Netzwerk dient zur Wartung und Konsistenthaltung der Stati. Nur autonome Netzwerke verwenden in PROTEAN Kern-Netzwerke zur Statusverwaltung. Größere Transitnetzwerke sind aufgrund von Skalierbarkeit und Overhead nicht geeignet. Knoten sind entweder Kern-Knoten oder sie haben sehr geringe Zugriffszeiten zu einem Kern-Knoten. Die Anzahl der Knoten ist zu minimieren. Alle Kern-Knoten sind mit den näheren Kern-Knoten über Tunnels verbunden. 3.5.2 Verbreitung/Synchronisation der Daten Um die Verbreitung von Daten (Stati) näher zu betrachten, ziehen wir die Bandbreite als Beispiel heran. Die Bandbreite ändert sich jedes Mal, wenn ein neuer Datenfluss hinzukommt oder terminiert. Wir nehmen an, dass ein funktionierender Beobachtungsmechanismus für die momentane Belastung einer Datenleitung existiert und konzentrieren uns auf die Verbreitung bzw. Synchronisation der gemessenen Werte. Bei PROTEAN ist jeder Kern-Knoten für einen aktuellen Stand der lokalen Daten verantwortlich. Ist einem Kern-Knoten ein nicht-lokales Datum bekannt, so ist dieser Knoten Anwärter, dieses Datum auch selbst zu verwalten. Ändern sich die Werte jedoch allzu häufig, so ist das lokale Speichern des Datums am Knoten, wo dieser Wert entstanden ist, vorzuziehen. Um dieses Ziel zu erreichen, wird wie folgt vorgegangen: Es werden Wellen eingeführt. Unter einer Welle ist die Verbreitung und Aktualisierung von Werten innerhalb des Netzwerkes zu verstehen. Man unterscheidet zwischen sich langsam und schnell fortpflanzenden Wellen. Im vorhergehenden Beispiel mit der Brandbreite würde eine sich langsam fortpflanzende Wellen einer Erhöhung der Bandbreite entsprechen. Eine sich schnell fortpflanzende Wellen wäre dementsprechend mit einer Verringerung der Bandbreite gleichzusetzen. Die Hauptidee ist, dass schnellere Wellen die langsameren überholen und "töten". Die Information über eine Verringerung der Bandbreite wird folglich schneller verbreitet als die der Erhöhung der Bandbreite. Dies lässt sich einfach dadurch erklären, dass eine niedrigere Bandbreite als mehr störend empfunden wird und dadurch diese Information im Normalfall von größerer Wichtigkeit ist. 3.5.3 Das State Management im Einsatz - technische Details Bei den gemeinsamen Status-Variablen entschied man sich für eine Shared Memory Lösung. Diese ist simpel und effizient, auch wenn ein Ansatz mittels Upcalls skalierbarer wäre, wenn das Statusmanagement eine gewisse Größe übersteigt. Die Semantik von Konsistenz hängt von mehreren Faktoren, insbesondere der Granularität, wie die Wellen getriggert werden, ab. Zwischen Nicht-Kern- und Kern-Knoten herrscht starke, zwischen Kern-Knoten schwache Konsistenz. PROTEAN liefert einstweilen keine Garantie, dass die Werte auch tatsächlich korrekt sind. Empfohlen wird, dass nicht lokale Daten nur lesbar sind und Änderungen direkt am verantwortlichen Kern-Knoten erledigt werden. PROTEAN biete schwache und starke Konsistenz an. Bei schwacher Konsistenz wird die lokale Kopie modifiziert und ein lazy update durchgeführt. Bei starker Konsistenz müssen alle Lese- und Schreiboperationen am Original durchgeführt werden.

3.6 Fallstudie Es wurden Studien durchgeführt, um einerseits zu zeigen, dass die PROTEAN-Architektur funktioniert, und um andererseits deren Anwendbarkeit zu testen. Zu diesem Zweck wurde 'packet-dropping' auf einem PROTEAN-Server implementiert. Folgende Algorithmen wurden dabei verwendet: head drop, random drop und priority drop. Im Gegensatz zu einer gewöhnlichen Architektur, wo eine neue Kompilation des Kernels notwendig wäre, können die Algorithmen bei PROTEAN on-the-fly ausgetauscht werden. Die Applikation teilt nur mit, welchen Event-Handler sie verwenden möchte. Dieser wird in der Servicetabelle eingetragen und muss gegebenenfalls nachgeladen werden. Das Nachladen ist jedoch nur einmal notwendig. Im Test wurde das System auf Funktion und auf Performance getestet. Die Ergebnisse zeigten, dass das System in der Lage war, die 3 oben genannten Drop-Algorithmen zu implementieren. Performancemessungen zeigten, dass die Unterschiede zwischen gewöhnlichen Servern und einem PROTEAN-Server nahezu bei Null liegen. Nur das Installieren von Event-Handlern benötigt eine gewisse Zeitspanne. Dies ist jedoch nur ein einziges Mal von Belang. 3.7 Schlussbemerkung Bei PROTEAN handelt es sich um eine event-orientierte Netzwerkarchitektur. Das System ist in der Lage, hierarchische Netzwerkkontexte aufzubauen, und hat die Fähigkeit auf nichtlokale Stati zuzugreifen. PROTEAN ist noch immer im Entwicklungsstadium, hat jedoch erfolgversprechende Features aufzuweisen. Es weist neue Perspektiven beim State Management und bei der flexiblen Kreierung von aktiven Netzwerken auf. Besonders positiv hervorzuheben ist, dass PROTEAN ein bereits funktionierendes System ist, für welches Beispielsapplikationen existieren. Aus den Testergebnissen lässt sich schließen, dass ein event-orientierter Ansatz gut dazu geeignet ist, dynamische (aktive) Netzwerke zu gestallten. Ein Wehrmutstropfen ist jedoch, dass die Synchronisation von Stati in größeren Netzwerken nicht skalierbar ist. Des weiteren wurde außer Betracht gelassen, wie die Messungen von Stati zur Verfügung gestellt und ausgeführt werden. Es ist anzunehmen, dass zum Messen häufig privilegierte Zugriffe notwendig sind. Dem normalen Anwender wird es also nicht allzu leicht möglich sein, selbst seine eigenen Stati zu erzeugen. Das Prinzip der Wellen zur Verbreitung von Stati ist meiner Meinung nach sehr interessant. Zwar lässt es sich nicht für zeitkritische Anwendungen einsetzen, doch man könnte es für unkritische Aufgaben anwenden.

4. Abrechnungsmodell für paketorientierte Netzwerke 4.1 Allgemeines Internet Service Provider bedienen sich heutzutage häufig eines Flat-Rate-Modells, welches einen fixen Preis pro Zeiteinheit (z.B. Stunde oder Monat) vorsieht, unabhängig von der Art und Menge der versandten und empfangenen Daten. Das Ziel dieses Systems ist es, differenzierte Levels von Netzwerkservices einzuführen, die den unterschiedlichen Anforderungen angepasst sind. Es soll eine Beziehung zwischen dem Preis und den verwendeten Ressourcen hergestellt werden. Geringe, jedoch nicht zu hohe, zusätzliche Kosten werden akzeptiert. Das Ziel des hier vorgestellten Systems [PRI] ist es, sowohl auf das Datenvolumen als auch auf die Quality of Services Rücksicht zu nehmen. Zu Zeiten hoher Ressourcenbeanspruchung soll es zudem möglich sein, mittels Strafen (engl.: Penalties) den Verkehr teils einzuschränken. Folgende Fragen sind von besonderem Interesse: Vertrauen, Stabilität, Sicherheit und Akzeptanz durch die Anwender. 4.2 Prinzip Dieses dynamische Abrechnungsmodell für paketorientierte Netzwerke verlagert die Zuständigkeit für die Berechnung der konsumierten Services von den Netzknoten zu den Anwendern. Die Entwickler gingen davon aus, dass die Rechenleistung von den Maschinen der Anwender ohnehin nicht total in Anspruch genommen werden. Die Router hingegen können sich durch diese Maßnahme auf ihre eigentlich Tätigkeit konzentrieren.

Tariffing

Tariffing

Accounting

Accounting Data flow

Measurement

Measurement Process

Provider domain

Customer domain

Abb. 4 Prozesse und Datenfluss im dynamischen Abrechnungsmodell [PRI] In Abbildung 4 ist zu sehen, wie die Kostenrechnung der Ressourcen gemacht wird. Der Provider liefert dem Kunden für jeden angebotenen Service Tarife und dazugehörige Information, wie z.B. die Tarife angewandt werden (z.B. im Minutentakt, etc.). Der Kunde erstellt nun die Berechnungen sowohl für den eingehenden als auch für den hinausgehenden Verkehr. Die Ergebnisse werden periodisch an den Provider gesandt.

Dem Kunden wird innerhalb dieses Systems sehr viel Vertrauen entgegengebracht. Dem Provider ist es jedoch möglich, Stichproben zur Überprüfung der korrekten Kostenberechnung durchzuführen. In der Abbildung ist dies mittels einer strichlierten Ellipse angedeutet. Das Abrechnungsmodell kann auch auf Services angewandt werden, die nicht paketorientiert sind. Es ist auch vorstellbar, dieses System auf Routern des Service Providers zu installieren, um seinen gesamten Verkehr zu verfolgen. Genauere Untersuchung hierzu wurden jedoch nicht angestellt. Im allgemeinen gibt es nun vier Möglichkeiten, wie Tarife zwischen zwei Partnern (z.B. Internet-Service-Provider und Kunde oder Business to Business, etc.) berechnet werden könnten: • • • •

A muss B für empfangene Pakete bezahlen A muss B für gesendete Pakete bezahlen B muss A für empfangene Pakete bezahlen B muss A für gesendete Pakete bezahlen

Um maximale Flexibilität zu ermöglichen, werden all diese Tarifsysteme erlaubt. 4.3 Das Tarifsystem Das Tarifsystem erlaubt verschiedene Tarife für verschiedene Services. Es ist sowohl möglich, dass die Preise für ein Tarifsystem wechseln, als auch dass sich das gesamte Tarifsystem selbst ändert. Beim ersten Fall wird von einer Anpassung, beim zweiten von einem Wechsel gesprochen. Diese Unterscheidung wird durchgeführt, da angenommen wird, dass ersteres wahrscheinlicher und zudem leichter durchführbar ist. Wie bereits angedeutet, soll es möglich sein, zu gewissen Zeiten Penalties zu vergeben. Darunter sind automatische Preiserhöhungen zu verstehen, welche sich ergeben, wenn das Netzwerk überdurchschnittlich beansprucht wird. Im folgenden sei kurz erwähnt, wie Preise zustande kommen können: • • • •

Eigene Festlegung durch den Provider Bezugnahme auf die Konkurrenz Berücksichtigung momentaner Ressourcen Relative Nachfrage für ein differenziertes Produkt, z.B. soll die Akzeptanz eines Produktes mittels niedrigerer Preise erhöht werden

Preisänderungen können sich auf folgende drei Arten ergeben: •

•

Lokales Monitoring: Die Preise werden durch den Anwender aufgrund von seinen eigenen Beobachtungen angepasst. Eine direkte Kommunikation mit dem Provider ist nicht nötig. Bei dieser Art von Preisanpassungen ist man total auf die Beobachtungen des Anwenders angewiesen. Ein gut durchdachtes Tarifdesign ist besonders wichtig. Anpassung von Parametern: Der Provider passt gewisse Parameter an, welche vom Anwender selbst nicht festgestellt werden können. Zum Beispiel gibt der Provider Preiserhöhungen seiner Provider direkt an den Kunden weiter.

•

Ersetzung von Tarifen: Es ist jederzeit möglich, dass der Provider neue Tarifmodelle einführt.

Die Anpassungen der Preise können entweder automatisch oder manuell geschehen. Werden diese automatisch angepasst, ist man auf ein Regelsystem angewiesen, welches Änderungen on-the-fly vornimmt. Ein Problem hierbei ist, dass diese Änderungen auch dem Kunden bekannt geben werden müssen. Dazu sind "dynamische" Interfaces notwendig, welche z.T. bereits experimentell entworfen wurden. 4.4 Eine Implementierung mit Java Es wurde ein Demonstrator implementiert. Dieser enthält folgende Hauptfunktionalitäten: • • •

Mobiler Code zur Repräsentierung von Tarifen und ein dazugehöriges graphisches Interface (GUI) Multicast-Protokoll zur Verbreitung von Tarifen und Tarifanpassungen Dynamisches Class Loading

Der Prototyp besteht aus zwei Applikationen: • •

Ein Providersystem, welches das Einführen, Ersetzen und Anpassen von Tarifen erlaubt Ein Kundensystem, welches Tarifänderungen erkennt und diese umsetzt

Es wurden JAVA Interfaces verwendet, die nach belieben anpassbar sind. Die Methode getGUI() retourniert eine SWING - Komponente, welche zur Darstellung der Tarife dient. Die GUI unterscheidet sich je nachdem, welche Klasse (in diesem Fall Produkt) dargestellt werden soll. Die Methode getCharge() liefert die eigentlichen Preise. Die Parameter können stark variieren, da sie vom Typ des Tarifes abhängig sind. Als Beispiel sei folgende UML Beschreibung gegeben:

Interface Tariff _____________________ _____________________ +getGUI():JComponent

Interface RsvpTariff ____________________________ ____________________________ +getCharge(TSPEC ts): float

Abb. 5 Interfaces von Tarif-Modellen

Interface PacketCountTariff ______________________________________ ______________________________________ +getCharge(int pkin, int pkout, int c)

Die Tarife werden zur Verfügung gestellt, indem die Interfaces implementiert werden. Die Klassen werden dann serialisiert und mit einem private key versehen. Der Kunde empfängt das Paket, entpackt es und überprüft die Authentizität. Anschließend werden die Klassen dynamisch geladen. Zur Vereinfachung des Protokolls wurden folgende Eigenschaften vorausgesetzt: Die Klassen müssen sowohl idempotent als auch komplett sein. Die erste Eigenschaft dient dazu, dass eine Tarifanpassung auch dann korrekt ist, wenn sie mehrfach übertragen wird. Die Komplettheit soll verhindern, dass verlorene Anpassungen Folgefehler verursachen. 4.5 Illustration Abbildung 8 zeigt eine GUI-Komponente des Software die am Computer des Konsumenten installiert ist. Es ist ersichtlich, wie viele Pakete hinein und hinaus gehen. Zudem sieht man die Beanspruchung des Netzwerkes. Da zum Zeitpunkt des Screenshots die Netzbeanspruchung über dem Limit liegt, ist in der Formel für die Preisberechnung ein Penalty enthalten.

Abb.6 Interface für den Kunden

Der Provider hat für seine verschiedenen Tarifsysteme mehrere Fenster zur Verfügung. Der Provider kann mehrere Parameter festlegen. Die Änderungen werden wie oben besprochen an den Kunden überliefert und dort mittels der GUI dargestellt.

Abb. 7 Interface für den Provider 4.6 Schlussbemerkung Die Arbeit konzentrierte sich einstweilen auf die Festlegung von Prinzipien bezüglich dynamischer Preisfestlegung und der dazu notwendigen Infrastruktur. Die ökonomische und soziale Akzeptanz wurde nicht genauer untersucht und ist mit Experimenten und Modellierungen zu überprüfen. Zur Zeit wird an Verbesserungen der Implementierung gearbeitet. Die Arbeit zeigt, dass die allgemeine Annahme, mobiler Code müsse auf Routern laufen, nicht immer stimmen muss. Durch diese Maßnahme wird den Routern, die an sich schon genug belastet sind, Arbeit abgenommen. Systeme von Internet-Service-Providern werden durch diese Architektur skalierbarer. Zum einem wird dem ISP Arbeit abgenommen. Zum anderen schaffen differenzierte, paketorientierte Tarife mehr Transparenz, sowohl für den Provider als auch für den Kunden. Zu kritisieren wäre eventuell die Wahl einer performancefressenden Programmiersprache. Da es sich jedoch nur um einen Prototypen handelt, ist dies vertretbar. Datenpakete mit Preisinformationen vom Kunden zum Provider sollten meiner Meinung nach wenn Möglich nicht in direkt lesbarer Form, sondern möglichst verschlüsselt, übertragen werden, um Manipulation durch den Kunden zu verhindern. Abschließend sei gesagt, das verglichen mit den beiden bereits vorgestellten Architekturen, diese Architektur nur als Ergänzung und nicht als Ersatz dienen kann.

5. Vergleich Die drei oben besprochenen Architekturen wurden nach den Kriterien Ausführungsort, Programmiersprache, Anwendungsgebiet, Konzept / Besonderheit, Sicherheit, Performance und Schwächen verglichen. Das Ergebnis wurde in einer Tabelle zusammengefasst.

Ausführungsort Programmiersprache(n) Anwendungsgebiet

Konzept / Besonderheiten

Sicherheit Performance

ALIEN Router / Switch OCaml, C

PROTEAN Router / Switch keine Angaben

Abrechnungsmodell Endpunkt (Anwender) Java

Active Extensions & Active Packets

Netzwerk Services

3-SchichtenArchitektur, On-the-fly Laden, Libraries Programmiersprache, Thin Interfaces teilweise C nötig, um Performance zu verbessern

State Management implizit erzeugte VNCs, Vererbung keine Angaben Events sind unwesentlich langsamer als fest Programmierung das Wellen-Prinzip ist für größere Netzwerke nicht ausgereift genug State Management, Error Handling

Abrechnungsmodell für paket-orientierte Netzwerke Ausführung obliegt dem Anwender, serialisierte Objekte

Skalierbarkeit

keine Aussagen machbar

Schwächen

wenig Libraries, Performance

Abb. 8 Vergleich von drei AN-Architekturen

private key, Gegenkontrolle keine Angaben, nicht vergleichbar

ist gegeben, da der Anwender die Arbeit übernimmt Einzellösung, Anwenderakzeptanz nicht getestet

6. Weitere Architekturen 6.1 RCANE RCANE (A Resource Controlled Framework for Active Network Services) [RCA] besitzt eine ähnliche Schichtenarchitektur wie ALIEN. RCANE erlaubt es dem Anwender, Netzwerkressourcen wie CPU, Speicher und Bandbreite zu konsumieren. Dazu hat der Anwender die Möglichkeit, eine Session zu kreieren. Eine Session besteht aus dem Anwender und den von ihm reservierten Ressourcen. Das Hauptaugenmerk dieses Systems liegt nun darin, dass sich die Ressourcen der einzelnen Sessions nicht gegenseitig beeinflussen. Es ist beispielsweise möglich, einen gewissen Prozentanteil der CPU-Zeit zu reservieren. Bereits reservierte Anteile sollen dadurch nicht beeinflusst werden. Zusätzlich zu den benutzerdefinierten Sessions existiert eine System-Session, welche "Hausarbeiten" durchführt. Gewöhnliche Datenflüsse, welche sich auf das Weiterleiten von Paketen beschränken, werden nach dem Best-Effort-Prinzip behandelt. Es kann gesagt werden, dass es sich bei RCANE um eine gut durchdachte aktive Netzwerkarchitektur handelt. Im Gegensatz zu ALIEN geht es besonders auf die Verwaltung von Ressourcen ein. Das System verhindert mittels Sessions auf eine geschickte Art und Weise die gegenseitige Beeinflussung von QoS verschiedener Anwender. 6.2 ALAN und XML ALAN [ALA] basiert auf existierender Technologie und besteht aus mehreren Schichten. Die erste Schicht besteht aus einem Cache-Netzwerk. Es wird davon ausgegangen, dass sich Caches an allen kritischen Netzübergängen befinden. Die darüberliegenden Schichten stellen den Kern des Systems dar. Die ALAN-Schicht implementiert die aktiven Services. Ein XMLParser liefert die Funktionalität, um Metadaten aus Objekten (z.B. http-Seiten) zu filtern.

XML ACTIVE NETWORK

ACTIVE SERVICES

XML PARSER

ACTIVE NETWORK (ALAN) CACHE NETWORK (SQUID)

Abb. 9 Architektur von ALAN (mit XML) [ALA]

In den XML-Objekten werden (derzeit) Daten über die Ansprüche für QoS gespeichert. So kann zum Beispiel eine niedrige Bandbreite mit hoher Sicherheit und hohem Durchsatz verlangt werden. Das ALAN-Netzwerk funktioniert nun folgendermaßen: Trifft ein Objekt ein, wird es vom http-Parser analysiert. Handelt es sich um ein XML-Objekt, so wird der XML-Parser aufgerufen, welcher die Metadaten extrahiert. Anhand der Metadaten kann entschieden werden, welche Proxylets unter welchen Bedingungen mit welchen Parametern und in welcher Reihenfolge aufgerufen werden sollen. ALAN unterscheidet sich von den bisher erwähnten Architekturen gänzlich, da es auf CacheTechnologien aufbaut. Bemerkenswert ist, dass das System durch die Verwendung von XML besonders flexibel ist. XML stellte eine gute Möglichkeit dar, Metadaten zu verwalten und zu transportieren.

7. Problematiken und abschließende Bemerkungen Es existiert eine Vielzahl von verschiedenen Ansätzen für aktive Netzwerke. Die Ansätze unterscheiden sich vor allem durch die unterschiedlichen Zielen Schwerpunkte und Vorgangsweisen. Derzeit konzentriert man sich auf konzeptionelle Überlegungen. Praktische Ansätze existieren meist nur als Demonstratoren und Prototypen. Testergebnisse sind daher wenig aussagekräftig oder gar nicht vorhanden. Zusammenfassend kann gesagt werden, dass sich die Forschung derzeit vor allem auf folgendes konzentriert: Sicherheit, QoS und Performance. Eine wichtige Rolle spielt dabei die Programmierbarkeit von Routern, Switches und Endgeräten. Ebenso von Bedeutung ist die Art und Weise der Programmierung, sei es nun mittels aktiver Pakete oder mit Hilfe von Extensions. Die Wahl der richtigen Programmiersprache ist ebenso besonders wichtig. Offen ist die Frage, was für eine Architektur sich schlussendlich durchsetzen wird. Es besteht die Wahl zwischen auf alten Technologien aufbauenden Systemen (wie z.B. ALAN) und gänzlich neuen Ansätzen (wie z.B. PROTEAN und ALIEN). Es kann jedoch gesagt werden, dass sich ein Standard in nächster Zeit nicht so schnell durchsetzten wird. Abschließend sei bemerkt, dass es sich bei aktiven Netzwerken noch immer um ein reines Forschungsgebiet handelt. Es gilt, die diversen aktiven Netzwerkarchitekturen auf deren Sinnhaltigkeit und Machbarkeit zu überprüfen. Kommerziell verwertbare Ergebnisse sind erst in fernerer Zukunft zu erwarten.

8. Literatur [ALI]…."The Architecture of ALIEN", D. Scott Alexander, Jonathan M. Smith [PRO].."The PROTEAN Programmable Network Architecture: Design and Initial Experience", Raghupathy Sivakumar, Narayanan Venkitaraman, Vaduvur Bharghavan [PRI]…"A Dynamic Pricing Framework to Support a Scaleable, Usage-Based Charging Model for Packet-Switched Networks", Mike Rizzo, Bob Briscoe, Jérôme Tassel, Konstantinos Damianakis [RCA]…"RCANE: A Resource Controlled Framework for Active Network Services", Paul Menage [ALA]…"Active Information Networks and XML", Ian Marshall, Mike Fry, Luis Velasco, Atanu Ghosh Alle Artikel aus: "Active Networks: First International Workshop"; Proceedings /IWAN '99, Berlin, Germany, June 30 - July 2, 1999. Springer, 1999