QoS-Management mit mobilen Agenten
Werbung
Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol QoS-Management mit mobilen Agenten Seminar: Datenkommunikation und verteilte Systeme Sommersemester 2003 Christoph Plum Matrikelnummer: 218433 Betreuung: Yuri Babich Lehrstuhl für Informatik IV, RWTH Aachen Inhaltsverzeichnis 1 Einleitung 3 2 Mobile Agenten 4 3 Qos Routing für MPLS Netzwerke mit Mobilen Agenten 6 3.1 Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Multi-Protokoll Label Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 mp2p Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Das Wave Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 Der Routing Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 5 Netzwerkmanagement mit mobilen Agenten 14 4.1 Das MANTRIP Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 JAIN/Parlay API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Einsatz der mobilen Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4 Das IP DiffServ Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Zusammenfassung und Ausblick 19 Literatur 20 2 1 Einleitung Im heutigen Internet gibt es keine Möglichkeit Benutzern bestimme Arten von Quality of Service (QoS), wie hohe Bandbreite oder geringe Verzögerungszeiten, anzubieten. Sämtliche Daten werden nur mittels best-effort so schnell, wie es die Auslastung des Netzes erlaubt, verschickt. Mehr und mehr entsteht jedoch die Nachfrage nach Qualitätsgarantien, insbesondere durch kommerzielle Teilnehmer. Solche Teilnehmer sind bereit für besseren Service zu bezahlen, wodurch ein Bedarf für verschiedene Serviceklassen entsteht. So sind zum Beispiel Inhaber kommerzieller Online-Angebote daran interessiert, dass ihre Seiten schnell erreichbar sind und wünschen sich schnelle Verbindungen zu ihren Servern. Unternehmen, die Internettelephonie oder Videokonferenzen betreiben, legen Wert auf geringe Verzögerungen und Schwankungen. Privatpersonen, die nur eine Verbindung ins Internet benötigen, legen dagegen auf solche Dienste keinen Wert. Daher sollte es für Internet Service Provider (ISP) möglich sein, ihren Kunden verschiedene Serviceklassen zu verschieden Preisen anzubieten. Tabelle 1 zeigt einige Anwendungen und ihre Anfordungen an die Internetverbindung. Anwendung E-Mail Dateitransfer Web-Zugriff Remote Login Audio on Demand Video on Demand IP-Telefonie Videokonferenz Zuverlässigkeit hoch hoch hoch hoch niedrig niedrig niedrig niedrig Verzögerung niedrig niedrig mittel mittel niedrig niedrig hoch hoch Jitter niedrig niedrig niedrig mittel hoch hoch hoch hoch Bandbreite niedrig mittel mittel niedrig mittel hoch mittel hoch Tabelle 1: Internetanwendungen und ihre QoS-Anforderungen Man könnte der Meinung sein, dass die Übertragungskapazitäten des Internets eines Tages so groß sind, dass selbst mit einem best-effort Service für alle Teilnehmer ein zufriedenstellendes Ergebnis erreicht wird. Es ist jedoch davon auszugehen, dass immer, wenn die Übertragungskapazität des Internets steigt, auch neue Anwendungen entstehen, die diese Kapazitäten verbrauchen [1]. Es existiert bereits eine Reihe von Techniken, die den Bedarf für QoS erfüllen sollen, wie zum Beispiel DiffServ und MPLS, welche in dieser Arbeit noch eine Rolle spielen werden. Eine Übersicht über Ansätze zur Bereitstellung von QoS im Internet liefert [2]. Im Rahmen dieser Arbeit sollen Beispiele dafür gezeigt werden, wie es künftig möglich sein könnte mit der Hilfe von mobilen Agenten QoS im Internet bereitzustellen. Der zweite Abschnitt soll dazu zunächst eine kleine Einführung in das Thema mobile Agenten geben. Im dritten Abschnitt wird gezeigt, wie sich mobile Agenten nutzen lassen, um QoS gerechte Routen zu finden. Abschnitt vier zeigt eine Anwendung, mit der es für Administratoren möglich ist, Netzwerkmanagement im Bezug 3 auf QoS zu betreiben. Benutzer erhalten die Möglichkeit ihnen gemachte Qualitätszusagen zu überwachen. Der letzte Abschnitt fasst die Vor- und Nachteile der beschriebenen Ansätze noch einmal zusammen. 2 Mobile Agenten In großen, dynamischen Computernetzwerken bringt das klassische Client/Server Modell immer häufiger Probleme mit sich. Um verteile Aufgaben oder Berechnungen durchzuführen ist es oftmals nötig, große Datenmengen über das Netzwerk zu transportieren, wenn die Daten in verschiedenen Knoten gespeichert sind. Mobile Agenten sind in der Lage diese Knoten nacheinander zu besuchen, an jedem Knoten einen Teil der Berechnung auszuführen und schließlich mit dem Ergebnis zurückzukehren. Ziel ist es, dadurch die Belastung eines Netzwerkes erheblich zu reduzieren. Mobile Agenten sind geeignet Aufgaben in der Anwendungsschicht, sowie auch auf tieferen Netzwerkebenen, zu erfüllen. Mobile Agenten sind Programme, die in der Lage sind mit ihrem gesamten Code, von ihnen gesammelten Daten sowie ihrem aktuellem Zustand von einem Netzwerkknoten zu einem anderen zu wandern, um dort durch ihren Benutzer definierte Aufgaben zu erfüllen. Es sei erwähnt, dass das Wort Agent in vielerlei Hinsicht verwendet wird. Es existieren mehrere Arbeiten, die sich damit befassen das Wort Agent zu definieren [3, 4]. Einige wichtige Eigenschaften von mobilen Agenten, die jedoch nicht alle stets erfüllt sein müssen, sind: • Mobile Agenten treffen sämtliche Entscheidungen autonom, um ihr gegebenes Ziel zu erreichen. • Mobile Agenten sind in der Lage auf Veränderungen ihrer Umwelt zu reagieren. • Mobile Agenten sind in der Lage mit ihrem Benutzer, ihrem Wirt (Host) und anderen Agenten zu kommunizieren. • Mobile Agenten können geklont werden, um Berechnungen an verschiedenen Netzwerkknoten auf parallele Art und Weise durchzuführen. • Mobile Agenten benötigen ein Mobile Agent System (MAS) das ihre Anweisungen ausführt und ihnen verschiedene Dienste bereitstellt. Host Client Anfrage Antwort Anfrage Antwort Agent Agent + Daten Service Host Agent Client Service Abbildung 1: Vergleich: Mobile Agenten - Client/Server Modell 4 Abbildung 1 zeigt einen Vergleich des klassischen Client/Server Modells mit dem von mobilen Agenten. Der Unterschied besteht darin, dass im Falle des mobilen Agenten Modells die durch den Server bereitgestellten Informationen auch dort verarbeitet werden und somit das Netzwerk nicht unnötig belastet wird. Außerdem arbeiten Client und Agent asynchron, d.h. der Client muss nicht auf die Antwort des Servers warten und kann in dieser Zeit andere Aufgaben erfüllen. Damit der Agent auf verschiedenen Plattformen ausgeführt werden kann, sollte er in einer interpretierenden Sprache geschrieben sein. Daher sind mobile Agenten oftmals in der Programmiersprache Java geschrieben. Es existiert eine Vielzahl von mobilen Agentensystemen, wie z.B. Wave [5], Voyager [6], Grasshopper [7] und Aglets [8]. Das Konzept einer MAS soll in Abbildung 2 verdeutlicht werden. Client (Server) Anwendung MAS Mobile Agenten Umgebung Messaging Sub−System Netzwerk Infrastruktur Abbildung 2: Konzept mobiler Agenten Sowohl eine Client als auch eine Server Anwendung kann die durch die mobilen Agenten bereitgestellten Informationen nutzen. Eine solche Anwendung muss allerdings nicht zwingend vorhanden sein, da der mobile Agent auch selbst eine Anwendung darstellen kann. Die mobile Agenten Umgebung führt die Anweisungen der Agenten aus. Die MA Umgebung nutzt das messaging sub-system als Transportservice, um Agenten über das Netzwerk zu versenden und zu empfangen. Die Einsatzmöglichkeiten für mobile Agenten sind vielseitig. Dadurch, dass mobile Agenten auf eine MAS angewiesen sind, findet man fertige Anwendungen zurzeit nur in höheren Netzwerkschichten. So können sie zum Beispiel dazu eingesetzt werden, um in Datenbankservern oder auf WWW-Seiten nach Informationen zu suchen. Mobile Agenten eignen sich auch für die Realisierung von verteilten Simulationen. Jedoch können auf diese Weise die Vorteile mobiler Agenten nicht vollständig genutzt werden. Nach [9] sind mobile Agenten aufgrund ihrer Autonomie, Dynamik und Robustheit auch für den Einsatz auf tieferen Netzwerkschichten geeignet. Da nun schon einige Vorteile von mobilen Agenten angedeutet wurden, möchte ich nun noch kurz auf einige Nachteile bzw. Gefahren hindeuten. Zunächst einmal lassen sich mit mobilen Agenten sicherlich keine Probleme lösen, die man nicht auch ohne ihren Einsatz lösen könnte. Ihre Verwendung kann 5 jedoch häufig zu verbesserter Effizienz führen. Sollen MAs auf tieferen Netzwerkschichten eingesetzt werden, so müssen auch Router innerhalb eines Netzwerkes über eine MAS verfügen. Dadurch wird der Kern des Netzwerkes komplexer und wohl auch teurer. Schließlich bringen MA unter Sicherheitsaspekten Probleme mit sich. Sowohl der MA als auch sein Wirt können sich gegenseitig schaden. Was ist, wenn der MA versucht seinem Wirt zu schaden und sich wie ein Virus verhält? Was ist, wenn der Wirt den MA einfach löscht? Denkbar wäre auch, dass ein MA durch Klonen versucht das Netzwerk zu überlasten. Eine kritische Auseinadersetzung mit mobilen Agenten findet man unter [10]. 3 Qos Routing für MPLS Netzwerke mit Mobilen Agenten In diesem Abschnitt soll gezeigt werden, wie sich Routingprobleme mit der Hilfe von mobilen Agenten lösen lassen. Dazu werden zunächst einige Begriffe und Techniken erläutert. Anschließend wird ein Algorithmus zum Routing vorgestellt und seine Effizienz anhand von Messungen bewertet. 3.1 Differentiated Services Differentiated Services (DiffServ) ist ein Ansatz, bei dem verschiedene Datenströme zu Klassen aggregiert werden können. Pakete, die einen Router erreichen, sind einer Klasse zugeordnet und werden dementsprechend behandelt. Pakete von verschiedenen Klassen erhalten somit unterschiedliche Prioritäten. Diese Prioritäten ergeben sich zum Beispiel aus sogenannten Service Level Agreements (SLA), die ein Kunde mit einem ISP schließt. Ein SLA ist ein Vertrag, der dem Kunden zusichert mit welcher Priorität seine Daten behandelt werden. Man unterscheidet zwischen statischen und dynamisches Service Level Agreements: Bei statisches SLAs wird dem Kunden für bestimmte Zeit ein bestimmter Service zugesichert. Im Falle von dynamischen SLAs hat der Kunde die Möglichkeit bei Bedarf eine bestimmte Dienstklasse in Anspruch zu nehmen. Die Information, zu welcher Klasse ein Paket gehört, wird im Type of Service (TOS) Feld des ipv4Headers gespeichert. Im Internetprotokoll der nächsten Generation, ipv6, existiert dafür ein sogenanntes Traffic Class Feld. Der Eintrag in das ToS Feld wird als DiffServ Code Point (DSCP) bezeichnet. Durch den DSCP wird das Verhalten eines Paketes auf dem Weg von einem Router zum Nächsten bestimmt (per-hop-behaviour, PHB). Zurzeit sind für DiffServ u.a. folgende PHBs defieniert: • expedited forwarding (EF): Es wird zwischen ”regulären” und ”eiligen” Paketen unterschieden. Eilige Pakete werden in einer separaten Warteschlange verwaltet und erhalten somit höhere Priorität. • assured forwarding (AF): Es wird zwischen vier Prioritätsklassen unterschieden, jede mit eigenen Ressourcen (Warteschlangenspeicher und Bandbreite). In jeder Klasse werden drei Wahrscheinlichkeiten für das Verwerfen eines Paketes vergeben. Somit gibt es insgesamt 12 6 Dienstklassen. Fairness ist dadurch gegeben, dass im Falle einer Überlastung auch Pakete niedriger Prioritätsklasse aufgrund ihrer eventuell niedrigen Verwurfswahrscheinlichkeit Chancen haben, übertragen zu werden. DiffServ definiert jedoch nur das Setzen des ToS Feldes, welche Dienste und Klassen angeboten werden, liegt in der Hand des Netzwerkbetreibers. Eine Domäne, also ein Teil des Netzes, welche DiffServ unterstützt, lässt sich in Zugangsrouter und interne Router unterteilen. Die Zugangsrouter liegen am Rand einer solchen Domäne. Dort wird jedes Paket, das die Domäne betritt, einer Dienstklasse zugeordnet. Innerhalb einer solchen Domäne werden die Pakete von den inneren Routern mit der entsprechenden Priorität weitergeleitet. Dies hat den Vorteil, dass die Komplexität des Netzwerkes an den Rand verlagert wird. Dadurch und aufgrund der Tatsache, dass die Anzahl der Zustandsinfomationen, die ein Paket mit sich führen muss, proportional zur Anzahl der Serviceklassen ist, zeichnet sich DiffServ durch gute Skalierbarkeit aus [2]. Pakete, die über mehrere Domänen laufen, müssen beim Wechsel einer Domäne erneut markiert werden. Dazu sind dann auch SLAs zwischen den Inhabern dieser Domänen notwendig. DiffServ ist jedoch in jedem Falle auf die Hilfe weitere Techniken angewiesen. Diese werden benötigt, • um an den Zugangsroutern die Pakete entsprechend zu markieren und • um die in den inneren Routern ankommenden Pakete nach Serviceklassen zu gruppieren und zu verarbeiten. 3.2 Multi-Protokoll Label Switching Multi-Protokoll Label Switching (MPLS) ist eine Technik, die es ermöglichen soll Routing in Netzwerken zu beschleunigen, sowie gleichzeitig die Möglichkeit bieten, QoS im Internet bereitzustellen. Die Idee von MPLS ist einfach. Zwischen benachbarten Netzwerkknoten werden Labels ausgetauscht, um Pakete, die verschieden Klassen angehören zu identifizieren, sowie den Zielknoten des Paketes zu bestimmen. Da im IP-Header für solche Informationen kein Platz ist, wird ein extra MPLS-Header benötigt. Dieser wird zwischen den Netzwerkschichten 2, also der Sicherungsebene, und Schicht 3, der Netzwerkebene, platziert. MPLS soll keine neue Ebene im OSI-Referenzmodell definieren, sondern kann vielmehr als eine Verbindung zwischen beiden Schichten gesehen werden [14]. Auf der Netzwerkebene können neben dem IP Protokoll auch andere Protokolle verwendet werden, daher auch der Name Multi-Protokoll Label Switching. Wie sich Abbildung 3 entnehmen lässt, besteht der MPLS-Header aus vier Teilen. Einem 20 Bit großen Feld für das eigentliche Label, gefolgt von einem drei Bit großen QoS-Feld. Das S-Feld ist zur Verwendung in hierarchischen Netzen gedacht, mit dem es dort möglich ist durch Setzen dieses Bits mehrere MPLS-Header hintereinander zu platzieren. Am Ende des Headers befindet sich noch ein acht Bit langes time-to-live (TTL) Feld. 7 L2 Header MPLS 20 L3 Header 3 Label 1 QoS S 8 TTL Abbildung 3: MPLS-Header Die Arbeitsweise von MPLS lässt sich wie folgt beschreiben. Wenn ein Paket eine MPLS-Domäne erreicht, wird vom Router für dieses Paket ein Label vergeben und dieses somit einer so genannten forward equivalence class (FEC) zugeordnet. Alle Pakete einer FEC werden vom Router gleich behandelt, dass heißt sie haben die gleiche Priorität, sowie die gleiche Ausgangsleitung. Danach schickt der Router das Paket zum Nächsten. Der nachfolgende Router vergibt wieder ein Label, teilt das vergebene Label dem vorherigen Router mit und sendet das Paket weiter. Dies wird fortgeführt, bis das Paket sein Ziel erreicht hat, oder die Domäne verlassen hat. Das Ziel des Paketes wird hier noch durch die IP-Adresse bestimmt. Durch diese Vorgehensweise ist für alle nachfolgenden Pakete des gleichen Datenstroms der Weg durch das Netzwerk festgelegt. Es wurde quasi eine Verbindungsorientierung geschaffen, ohne dass ein Verbingungsaufbau nötig war. Erreicht nun ein nachfolgendes Paket einen Router, so kann dieses sehr schnell abgearbeitet werden. Ohne dass der IP-Header analysiert werden muss, wird das Label gelesen, durch ein Label für den nächsten Router ersetzt und über die entsprechende Leitung versendet. Haben zwei verschiedene Datenströme das gleiche Ziel innerhalb einer MPLS-Domäne, sei es der gleiche Host oder der gleiche Zugangsrouter zu dieser Domäne, und haben die Pakete innerhalb dieses Datenstroms die gleiche Priorität, so lassen sie sich zu einer FEC zusammenfassen und können mit dem gleichen Label ausgestattet werden. 3.3 mp2p Verbindungen Für die Realisierung eines wie oben beschriebenen DiffServ-über-MPLS Netzwerkes besteht die Notwendigkeit für weitere Protokolle. Zum einen wird ein Routingprotokoll benötigt, um die Routen für die ersten Pakete eines Datenstromes zu bestimmen. Zum anderen braucht man ein Protokoll, um die Labels zwischen den Routern zu verteilen. Will man, wie oben erwähnt, mehrere Datenströme zu einer FEC zusammenfassen, sind Routingprotokolle notwendig, die so genannte multi-point-to-point (mp2p) Verbindungen unterstützen. Dies ist eine Menge von Datenströmen, die ihren Ursprung an verschiedenen Stellen haben, an einem gemeinsamen Knoten zusammenlaufen und dann den gleichen Pfad entlanglaufen oder sich vielleicht später wieder trennen. Leider unterstützen heutige Routingprotokolle wie Open Shortest Path First (OSPF) das Aufbauen von mp2p-Verbindungen nicht. Um mit einem DiffServ-über-MPLS Netzwerk QoS-Dienste bereitzustellen, ist jedoch das Aufbauen solcher Verbindungen notwendig, nicht zuletzt um die Netzwerkbelastung durch ständiges Aktualisieren der Routingtabellen so gering wie möglich zu halten. 8 Die Frage ist nun wie sich dieses Problem lösen lässt. Das ist der Punkt, an dem die mobilen Agenten ins Spiel kommen. Im nächsten Abschnitt wird nun Wave, eine Plattform für mobile Agenten, vorgestellt, und anschließend gezeigt, wie sich das Aufbauen von mp2p-Verbindungen mit Hilfe von mobilen Agenten realisieren lässt. 3.4 Das Wave Modell Die Idee das Wave Modells geht auf seinen Erfinder, Dr. Peter Sapaty, Anfang der 70er Jahre zurück. Die erste Implementierung wurde 1992 für UNIX-Systeme veröffentlicht [5]. Wave-Programme werden als Zeichenketten repräsentiert, womit Operationen und Funktionen definiert werden. Sie zeichnen sich durch extreme Kompaktheit aus. So sind Wave-Programme typischerweise 20- bis 50-mal kürzer als äquivalente C/C++ oder Java Programme [11]. Die mobilen Agenten, hier auch Waves genannt, verfügen über Variablen, deren Inhalt nur ihnen zugänglich ist, sowie die Möglichkeit Variablen in den Netzwerknoten zu verwenden, um Informationen mit anderen Agenten, die diesen Knoten besuchen, zu teilen. Das Wave System kann dem Agenten über Umgebungsvariablen Informationen über den Zustand des Netzwerkes an einem Knoten geben, wie zum Beispiel Auslastung des Knotens oder ähnliches. Das Wave System bietet den mobilen Agenten auch die Möglichkeit mit externen Programmen, die in C/C++, Java oder anderen Programmiersprachen geschrieben sind, zu kommunizieren. Dadurch eignet sich das System auch für Aufgaben auf höheren Netzwerkschichten. Somit verfügt die Wave Plattform über die wichtigsten Eigenschaften eines mobilen Agentensystems, wie starke Migration, paralleles Arbeiten der Agenten, synchrone/asynchrone Navigation, Flexibilität, Autonomie und Kompaktheit. Die Waves starten ihre Ausführung an einem beliebigen Knoten des Netzwerkes. Auf parallele Weise erobern sie dann das Netzwerk, indem sie als UDP Pakete verschickt werden. Indem sie bestimmte Informationen (z.B. über die Auslastung oder die noch verfügbaren Ressourcen) des Netzwerkes sammeln, bilden sie ein so genanntes (virtuelles) Knowledge Network (KN). Abbildung 4 zeigt ein Beipiel für ein Wave-Programm, das jeweils den kürzesten Pfad von einem Knoten a zu allen anderen Knoten des Netzwerkes bestimmt [12]. @#a.F=0.RP(N~,F<N.N=F.N1=P.$.F+L) Abbildung 4: Ein Wave-Programm In einer klassischen Programmiersprache würde das Programm folgendermaßen aussehen: 9 springe zu Knoten a; F:=0; while (N = undefiniert oder F < N) begin N:=F; N1:=P; springe zu allen Nachbarknoten; F:=F+L; end; Die Variable F wird von den Agenten stets mitgeführt. Sie speichert die (gewichtete) Entfernung des Agentes zum Knoten a. Die Variablen N und N1 sind Variablen der jeweiligen Knoten. Die Schleife wird ausgeführt, wenn ein Knoten zum ersten Mal besucht wird, oder der Agent eine kürzere Entfernung zum Knoten a gefunden hat. Ist dies der Fall, speichert der Agent die gefundene (gewichtete) Entfernung im aktuellen Knoten ab (N). Desweiteren speichert er seinen Vorgängerknoten, der ihm über die Umgebungsvariable P zur Verfügung gestellt wird, in N1 ab. Nachdem der Agent zu allen Nachbarknoten gesprungen ist, erhöht er die (gewichtete) Entfernung zum Knoten a mit Hilfe der Umgebungsvariablen L. 3.5 Der Routing Algorithmus Nun wird der eigentliche Algorithmus nach [14] vorgestellt. Um das QoS-Routing mit mobilen Agenten zu realisieren werden zwei Typen von Agenten benötigt. • statische Agenten: Ihre Aufgabe ist es Informationen über die Verfügbarkeit von Netzwerkressourcen zu sammeln. • mobile Agenten: Ihre Aufgabe ist es Routen durch das Netzwerk zu finden, die bestimmten QoS-Anforderungen gerecht werden. Die einzigen Anforderungen an das Netzwerk sind, dass die Knoten über einen Wave Interpreter verfügen und MPLS fähig sind. Den Aufbau eines solchen Routers zeigt Abbildung 5. Der Classifier teilt den Datenstrom in die eigentlichen Daten und die mobilen Agenten auf. Der Wave Interpreter führt die Operationen der Wave-Programme aus und erhält Informationen über die Auslastung und den Zustand des Routers vom Ressourcen Management. Zu versendende Agenten erhalten vom Marker eine Priorität und werden dann dem Paket Scheduler zugeführt. Dieser fügt die beiden Datenströme wieder zusammen. Um ein QoS-basiertes KN zu erzeugen verbleibt je ein statischer Agent in einem Netzwerkknoten, um diesen zu überwachen. Der Wave Interpreter eines solchen Netzwerkknotens bildet einen virtuellen Knoten im KN. Der Agent speichert und aktualisiert den Zustand aller Verbindungen seines Knotens. Der Zustand wird in Form eines Wertes gespeichert, der die QoS Eigenschaften einer (virtuellen) 10 Wave interpreter Marker Resources management Packet scheduler Classifier Abbildung 5: MPLS-Router mit Wave Interpreter nach [14] Verbindung beschreibt. Diser Wert kann sich aus Bandbreite, Verzögerung, Schwankungen oder einer Kombination aus diesen ergeben. Der Vorteil hierbei ist, dass die QoS Informationen verteilt über das KN gespeichert sind und es nicht nötig ist das Netzwerk mit QoS relevanten Routinginformationen zu belasten. Nun können mobile Agenten gestartet werden, um die QoS gerechten Routen zu erkunden. Aufgabe ist nun einen mp2p-Baum von mehreren Eingangsknoten zu einem gemeinsamen Ausgangsknoten zu finden. Dieser Baum sollte sowohl minimale Pfade, als auch möglichst viele Knoten, die von mehreren Pfaden durchlaufen werden, enthalten. Es wird also ein Baum gesucht, dessen Blätter (oder auch innere Knoten) die Eingangsknoten sind und dessen Wurzel der Ausgangsknoten ist. Dieses Problem entspricht dem Problem des Minimalen Steiner Baumes aus der Graphentheorie [13]. Durch das Erreichen dieses Zieles werden die benötigten Netzwerkressourcen minimiert: • Die Anzahl der benötigten Verbindungen und Router wird minimiert. • Die Anzahl der benötigen MPLS Labels werden minimiert, da Datenströme, die über die gleiche Verbindung laufen von den Routern zu einer FEC zusammengefasst werden können. Leider ist kein polynomieller Algorithmus bekannt, der solche Steiner Bäume berechnet. Der nun vorgestellte Algorithmus stellt eine heuristische Lösung für dieses Problem dar. Als Beispiel dazu kann das in Abbildung 6a dargestellte Netzwerk betrachtet werden. Das Netzwerk besteht aus den Eingangsknoten E1 , .., E4 , den inneren Knoten I1 , .., I4 und dem Ausgangsknoten A. Der Algorithmus besteht im Wesentlichen aus vier Schritten. Im ersten Schritt wird eine Gruppe mobiler Agenten an den Eingangsknoten gestartet, welche das Netzwerk in Richtung des Ausgangsknotens durchlaufen. Dabei durchlaufen die Agenten nur solche 11 E1 E1 E2 E2 A I2 A I2 I3 I3 E3 E3 I1 I1 E4 I4 E4 I4 a) b) E1 E1 E2 I2 E2 A I2 I3 A I3 E3 E3 I1 E4 I4 I1 E4 I4 c) d) Abbildung 6: Berechnung des mp2p-Baumes Verbindungen, die die geforderten QoS-Eigenschaften erfüllen. Beachte, dass diese Eigenschaften durch die statischen Agenten überwacht werden. Wenn ein Agent einen Knoten im Netzwerk erreicht, speichert er dort seinen Ursprungsknoten sowie die Entfernung, die er bereits zurückgelegt hat. Hatte bereits ein Agent mit gleichem Ursprung diesen Knoten mit kürzerer Entfernung erreicht, so wird der Agent gelöscht. Andernfalls wird der Agent geklont und über alle QoS gerechten Verbindungen des Routers versendet (Abb. 6b). Im zweiten Schritt wird eine weitere Gruppe Waves auf die gleiche Weise wie im ersten Schritt gestartet. Doch diesmal dürfen die Agenten ihren Weg nur fortsetzen, wenn ihre zurückgelegte Distanz gleich der durch die erste Welle von Agenten aufgezeichnete Entfernung ist. Auf ihrem Weg zum Ausgangsknoten speichern die Agenten den von ihnen zurückgelegten Weg. Das Ergebnis ist eine Menge aller möglichen kürzesten Wege von den Eingangsknoten zum Ausgangsknoten. Außerdem ist sichergestellt, dass die Pfade kreisfrei sind, da Agenten, die einen Knoten mehrmals besuchen, sofort verworfen werden. Nun müssen noch möglichst viele Pfade zusammengefasst werden, um die Kosten des Baumes zu reduzieren. Dazu wird erneut eine Gruppe Agenten von den Eingangsknoten gestartet. Dabei durchlaufen die Agenten nur die vorher ermittelten kürzesten Pfade in Richtung des Ausgangsknotens (Abb. 6c). Bei jedem Knoten, den der Agent auf seinem Weg erreicht, prüft er zunächst, ob er der erste Agent mit gleichem Ursprung ist (es könnten verschiedene, parallele kürzeste Pfade existieren). Ist 12 dies der Fall, speichert er in dem Knoten die Information, dass bereits ein Agent mit seinem Ursprung da war und erhöht eine Variable, die die Gesamtzahl der Besuche aller Agenten wiedergibt. Je öfter ein Knoten besucht wurde, desto größer ist sein Gewicht für die Aufnahme in mp2p-Baum. Im vierten und letzten Schritt durchlaufen die Agenten die Pfade noch einmal. Dabei speichern sie die besuchten Knoten und ihre Gewichte in einer Liste und führen diese mit sich. Erreicht ein Agent eines bestimmten Eingangsknotens als erster den Ausgangsknoten, so speichert er dort den mitgebrachten Pfad sowie sein Gewicht ab. Erreicht ein weiterer Agent mit dem gleichen Ursprung den Ausgangsknoten, so wird der vorher gespeicherte Pfad überschrieben, falls das mitgebrachte Gewicht größer ist. Damit ist der mp2p-Baum im Ausgangsknoten gespeichert (Abb. 6d). Im oben gezeigten Beipiel lauten die gefunden Routen E1 − I2 − A, E2 − I3 − I2 − A, E3 − I3 − I2 − A und E4 − I2 − A. Die Identitäten der Knoten, die zum Baum gehören (z.B. deren IP-Adresse) können nun an den MPLS Teil des Ausgangsrouters übergeben werden. Dieser startet dann ein Protokoll, um die MPLS-Label an die Router des mp2p-Baumes zu verteilen. Auf ein solches Protokoll soll hier nicht weiter eingegangen werden. Im Falle von dynamischen SLAs müsste dieser Algorithmus jedes Mal wiederholt werden, wenn eine Verbindung zum Baum hinzukommt oder ihn verlässt. Dadurch können jedoch Anfragen von Benutzern mit SLAs hoher Qualität befriedigt werden. 3.6 Ergebnisse Der oben beschriebene Algorithmus wurde auf einer Solaris-UNIX Version von Wave implementiert [14]. Zur Simulation wurden zufällig Verbindungen generiert, die existierenden mp2p-Verbindungen beitraten und sie auch zufällig wieder verließen. Das Eintreffen der mobilen Agenten an einem bestimmen Knoten wurde anschließend gemessen. Abbildung 7 zeigt ein Beispiel nach welchem Muster die Agenten einen Knoten erreichten. Es fällt auf, dass häufig eine ganze Reihe von Agenten stoßweise eintrifft. Dies ist auch nicht weiter verwunderlich, da jedes Mal, wenn eine Verbindung einem mp2p-Baum beitritt oder diesen verlässt, der Algorithmus erneut ausgeführt werden muss. Dann wird stets eine ganze Gruppe von Agenten erzeugt, die einen neuen mp2p-Baum berechnen müssen. Es hat sich im Rahmen dieser Simulation herausgestellt, dass die Anzahl der erzeugten Agenten, die einen Knoten erreichen im Wesentlichen von folgenden Faktoren abhängt: • dem Grad des betrachteten Knotens, • der Topologie des Netzwerkes, • der Lage des Zielknotens im Netzwerk, sowie • den QoS-Eigenschaften der Netzwerkverbindungen. 13 Abbildung 7: Ankunftsmuster der mobilen Agenten Eine mathematische Beschreibung dieser Zusammenhänge ist schwierig. Es lässt sich jedoch folgendes festhalten. Aus der Sicht eines einzelnen Knoten sind die eintreffenden Verbindungsanfragen exponentialverteilt. Die Bedienzeit eines Agenten lässt sich als deterministisch annehmen, da diese kurz sind und im Wesentlichen stets die gleichen Operationen ausgeführt werden. Da jeder Knoten über einen Wave-Interpreter verfügt und die Agenten mit jeder Verbingsanfrage stoßweise eintreffen, erhält man ein M[x]/D/1 Warteschlangenmodell. Die Komplexität des vorgestellten Algorithmus liegt nach [14] in O(N · logN), wobei N die Anzahl der Knoten des Netzwerkes ist. 4 Netzwerkmanagement mit mobilen Agenten In diesem Abschnitt soll anhand einer Untersuchung von [16] gezeigt werden, wie mobile Agenten zum Netzwerkmanagement eingesetzt werden können. Heutige Netzwerkmanagementsysteme sind häufig für bestimmte Netzwerkkomponenten ausgelegt. Oft sind sie herstellerabhängig und durch ihre zentralisierte Architektur nicht sonderlich flexibel. 4.1 Das MANTRIP Projekt MANTRIP (MANagement, Testing and Reconfiguration of IP based networks using Mobile Agents) ist ein Projekt der IST (Information Society Technology) [15] und hat das Ziel mit der Hilfe von mobilen Agenten moderne Netzwerkmanagementsysteme und -anwendungen zu entwickeln. Durch den Aufbau aus modularen Softwarebausteinen erhält das System eine hohe Flexibilität. Abbildung 8 zeigt einen vereinfachten Aufbau des Systems, welches sich in vier Ebenen unterteilen lässt. Diese werden im Folgenden weiter erläutert. 14 pplication ayer QoS Management Anwendung MA Platform JAIN/Parlay API ervice ayer QoS Management MA System Common MA API daption ayer MANTRIP MA Platform Linux/Cisco API MA Platform etwork ayer IP DiffServ Netzwerk Linux/Cisco Router Abbildung 8: Vereinfachter Aufbau des MANTRIP-Systems Die Netzwerkebene: Auf der Netzwerkebene wird eine ganze Reihe von Protokollen unterstützt [16]. Für dieses Beispiel genügt es jedoch die Netzwerkebene als ein IP-DiffServ Netzwerk zu betrachten, in dem sowohl Linux als auch Cisco Router vorkommen. Die Anpassungsebene: Aufgabe der Anpassungsebene ist es von der Netzwerkebene zu abstrahieren. Sie bietet der Serviceschicht eine einheitliche Schnittstelle. So spielt es für die Serviceschicht keine Rolle, ob sie mit einem Cisco- oder einem Linuxrouter kommuniziert. Die Serviceebene: Die Serviceebene enthält das QoS-Managementsystem, dies sind Softwaremodule, die die Ausführung verschiedener Anwendungen unterstützen. Für dieses Beispiel sind sie Module Configuration Management, Monitor Management und Reconfiguration Management von besonderem Interesse. Eine Parlay/JAIN API (Application Programming Interface) stattet diese Module mit einer einheitlichen Schnittstelle zur Anwendungsebene aus (s.u.). In Richtung der Anpassungsebene setzt das Managementsystem auf einer MA API auf, so dass verschiedene Plattformen für mobile Agenten verwendet werden können, entweder Voyager oder Grasshopper. Die Anwendungsebene: In diesem Beispiel besteht die Anwedungsebene nur aus einer einzigen Anwendung, der QoS-Mana15 gement Anwendung. Diese Anwendung ist eine graphische Benutzerschnittstelle, die es Netzwerkadministratoren erlaubt, QoS-Eigenschaften des Netzwerkes zu überwachen und zu verändern. So kann er zum Beispiel dynamisch die maximale Bandbreite jeder Serviceklasse anpassen und den von Benutzern erzeugten QoS-Verkehr überprüfen (im Bezug auf Bandbreite, Verzögerung, usw.). Benutzer haben ebenfalls Zugang zu dieser Anwendung, können aber keine Werte verändern. Dadurch erhalten sie jedoch die Mäglichkeit zu überprüfen, ob ihnen gemachte Qualitätszusagen auch eingehalten werden. Des Weiteren können Benutzer mit diesem System dynamisch Ressourcen für sich reservieren. Für einen bestimmten Zeitraum kann eine bestimmte QoS-Klasse reserviert werden, sowohl für eine als auch für beide Richtungen der Verbindung. 4.2 JAIN/Parlay API Die Parlay Gruppe [17] ist ein Firmenkonsortium mit der Aufgabe offene, unabhängige APIs zu entwickeln. Diese sollen Dritten ermöglichen Anwendungen zu entwickeln, die über verschiedene Netzerkplattformen hinweg einsatzfähig sind. Dieser Gruppe gehören Firmen wie IBM, SUN, Nokia, Ericsson, Siemens, Cisco u.a. an. Viele Vorgaben der Parlay Gruppe wurden von Standardisierungsorganisationen wie 3GPP (3rd Generation Partnership Project) und ETSI (European Telecommunications Standards Institute) angenommen. JAIN (Java API Initiative) [18] ist eine Gruppe, vergleichbar mit Parlay, die von der Firma SUN unterstützt wird. Ihre Ziele sind ähnlich der von Parlay, jedoch stärker konzentriert auf die Entwicklung von Java APIs, die von verschiedenen Netzwerkprotokollen abstrahieren sollen. Innerhalb des hier vorgestellten Systems wird auf der Anpassungsebene eine Java API, hier als LinuxCisco API bezeichnet, und auf der Serviceebene eine Java Implementation der Parlay API verwendet. 4.3 Einsatz der mobilen Agenten In dem hier vorgestellten System werden die mobilen Agenten, wie in Abbildung 9 dargestellt, eingesetzt. Eine Gruppe von Agenten wird so nah wie möglich zu den Routern geschickt. Ihre Aufgabe ist es die Router zu überwachen und ihnen Befehle zu erteilen. In diesem Zusammenhang werden die Agenten hier als statisch bezeichnet, da sie einmal in die Nähe der Router wandern und dann dort verbleiben. Die statischen Agenten können direkt zu den Linux-Routern wandern, die Cisco Router steuern sie mit Hilfe von telnet und überwachen sie über SNMP (Simple Network Management Protocol). Die statischen Agenten kommunizieren über die Linux-Cisco API mit den mobilen Agenten. Die mobilen Agenten können von den statischen Agenten Informationen über den Zustand der Router einholen und diese anweisen, die QoS-Parameter der Router neu zu konfigurieren. 16 Abbildung 9: Zusammenarbeit der mobilen Agenten [16] 4.4 Das IP DiffServ Netzwerk Wie oben beschrieben, kann das QoS-Managementsystem verwendet werden, um die DiffServ Netzwerkknoten zu steuern. Den internen Aufbau eines solchen Knotens zeigt Abbildung 10. Eintreffende Meter Classifier Shaper / Dropper Marker EF / AF / BE Scheduler Abbildung 10: IP DiffServ Router nach [16] Pakete werden vom classifier und vom meter charakterisiert. Der meter überprüft, ob der Datenstrom eine bestimmte Bandbreite überschreitet und markiert die Pakete daraufhin grün, gelb oder rot (three color marking, TCM) [19]. Grün bedeutet die Bandbreitete liegt unterhalb einer festgesetzten Schranke, gelb wird vergeben wenn die Schranke leicht überschritten wird und rot, wenn eine starke Überschreitung festgestellt wird. Die Aufgabe des classifiers ist es festzustellen, zu welcher Dienstklasse ein Paket gehört. Der marker setzt den DSCP im IP-Header des Paketes. Das PHB eines Paketes wird 17 sowohl vom shaper/dropper, wie auch vom scheduler bestimmt. Der shaper/dropper leitet die Pakete an den scheduler weiter. Die Pakete werden gemäß ihrer Farbe einer Dienstklasse zugeordnet. Im Falle einer Überlastung werden Pakete gemäß ihrer Dienstklasse verworfen. Der scheduler verwaltet schließlich die Warteschlangen des Routers. Diese sind so konfiguriert, dass Pakete der EF Klasse den besten Service erhalten. 4.5 Anwendungsbeispiel Dieses Beispiel zeigt, wie ein Benutzer mit Hilfe der QoS-Management Anwendung eine Reservierung von Netzwerkressourcen vornehmen kann. Abbildung 11 zeigt die Benutzeroberfläche dieser Anwendung. Abbildung 11: QoS-Management Anwendung [16] 18 Der Benutzer kann folgende Parameter der erwünschten Verbindung wählen. • Serviceklassse (Bronze, Silber, Gold, Best-Effort oder andere. Dies hängt von den durch den Provider zur Verfügung gestellten QoS Wahlmöglichkeiten ab) • Start- und Zielknoten der Verbindung (Service Access Points, SAPs) • Verbindungsrichtung, in der ein bestimmter Service zur Verfügung gestellt wird • garantierte Bandbreite • Zeit, zu der der Service erfolgen soll In dem in Abbildung 11 gezeigten Beispiel möchte der Benutzer ”jpm” jeden Dienstag ab dem 12. Dezember Netzwerkressourcen in der Zeit von 22 bis 24 Uhr nutzen. Nun fordert er mit Hilfe der QoS-Management Anwendung eine so genannte VPrP (Vitual Provisioned Pipe), also eine virtuell eingerichtete Verbindung, an. Da er zum Beispiel einen Film über das Internet sehen möchte braucht er eine gute Verbindung zu ihm selbst, die Verbindungsqualität in die andere Richtung ist weniger wichtig. Also wählt er eine bidirektionale VPrP zwischen SAP1 und SAP2 und wählt BE für seine ausgehende Verbindung und Gold für die andere Richtung. Als nächstes wird er noch die benötigte Bandbreite festlegen, zum Beispiel 2Mb/s. Die wählbare Bandbreite ergibt sich aus der in der Klasse Gold maximal verfügbaren Bandbreite. Dies bewirkt dass Pakete innerhalb der 2Mb/s Bandbreite mit grün markiert werden und somit höchste Priorität (EF) erhalten. Wird die Bandbreite um bis zu 10% überschritten, werden die entsprechenden Pakete gelb markiert und auf eine der AF DiffServ Klassen aufgeteilt. Wenn die Bandbreite um mehr als 10% überschritten wird, werden die Pakete rot markiert und erhalten niedrigste Priorität (BE) in den DiffServ Routern. Zum Zeitpunkt des bestellten Services werden die Router mit Hilfe der mobilen Agenten entsprechend konfiguriert. Der Benutzer wird in der Lage sein seinen Datenstrom zu überwachen und somit zu überprüfen, ob die ihm gemachten Zusagen auch eingehalten werden. 5 Zusammenfassung und Ausblick In den vorherigen beiden Abschnitten wurde an zwei Beispielen gezeigt, wie mobile Agenten zum Routing und zum Netzwerkmanagement eingesetzt werden können. Im ersten Beispiel, dem QoS-Routing, hat sich gezeigt dass die Agenten fast immer stoßweise auftreten. Dies war immer dann der Fall, wenn der mp2p-Baum neu berechnet werden musste. Aus diesem Grund muss ein solches Routingsystem mit großer Vorsicht geplant werden. Schließlich war eines der Hauptargumente für den Einsatz von mobilen Agenten, dass dadurch die Netzwerkbelastung reduziert werden kann. Dies scheint bei Aufgaben, bei denen Agenten im Kollektiv auftreten und kooperativ arbeiten, nicht der Fall zu sein. Daher könnte man zu dem Schluss gelangen, dass mobile Agenten sich eher für den Einsatz auf höheren Schichten eignen, wo sie meist für sich alleine arbeiten. In 19 jedem Falle ist, je nachdem auf welcher Ebene die Agenten eingesetzt werden sollen, die Wahl der Agentenplattform von entscheidender Bedeutung. Auf höheren Ebenen können aufgrund ihrer besseren Programmierbarkeit Plattformen verwendet werden, die zum Beispiel in Java geschrieben sind. Für Aufgaben auf tieferen Ebenen, wie im ersten Beispiel, ist die Kompaktheit des Agentencodes wichtig. Hier sind Plattformen wie Wave besser geeignet. Im zweiten Beispiel, dem QoS-Management, konnte durch die Dezentralisierung der Managementaufgaben von mobilen Agenten profitiert werden. Durch den Einsatz der Agenten, sowie die Verwendung mehrerer APIs wurde ein modulares System erstellt, das sich durch leichte Realisierung und große Flexibilität auszeichnet. Hier erleichterten die mobilen Agenten die Steuerung der Netzwerkknoten erheblich. Es ist jedoch in den beiden hier vorgestellten Systemen nicht endgültig gezeigt oder widerlegt, ob der Einsatz von mobilen Agenten letztendlich zu höherer Effizienz und geringerer Netzwerkbelastung führt. Im ersten Beispiel muss durch weitere Untersuchungen abgewogen werden, ob hier die Verwendung der mobilen Agententechnik lohnenswert ist. Vielleicht führen auch bessere Navigationsalgorithmen für die Agenten, auch wenn dies höhere Rechenkraft in den Routern erfordert, zu besseren Ergebnissen. Für das zweite Bespiel liegen noch keine Messungen über die Effizienz des Systems vor. Dennoch ist davon auszugehen, dass mobile Agenten in zukünftigen Kommunikationsnetzwerken eine wichtige Rolle spielen werden. Ihre größten Vorteile liegen in ihrer Dynamik, der Möglichkeit Steuerungsaufgagen zu dezentralisieren und der Fähigkeit Aufgaben parallel auszuführen. Literatur [1] R. Jain, ”Myths about Congestion Management in High Speed Networks”, Internetworking: Res. and Exp., vol. 3, 1992, pp. 101-13. [2] X. Xiao and L. Ni, ”Internet QoS: A Big Picture”, IEEE Network, March/April 1999. [3] L. Foner, ”What’s an agent anyway? - A sociological”, FTP Report - MIT Media Lab case study, May 1993. [4] S. Franklin, A. Graesser, ”Is it an agent, or just a program?: A taxonomy for autonomous agents”, Technical Report, Institute for Intelligent Systems, University of Memphis, March 1996. [5] The Wave Page, http://www-zorn.ira.uka.de/wave/wave.html, hosted by the Faculty of Informatics, Univ. of Karlsruhe, and the Dept. of Elect. and Elec. Eng., University of Surrey. [6] http://www.recursionsw.com/products/voyager/ [7] http://www.grasshopper.de 20 [8] D. Lange, M. Ishima, ”Programming and Deploying Java Mobile Agents with Aglets”, AddisonWesley, Reading, MA, 1998. [9] D. Lange, M. Oshima, ”Seven Good Reasons for Mobile Agents”, Commun. ACM, March 1999 [10] D. Chess, C. Harrison, A. Kershenbaum, ”Mobile Agents: Are they a good idea?”, in Jan Vitek and Christian Tschudin, editors. Mobile Object Systems: Towards the Programmable Internet (MOS’96), Linz, July 1996, volume 1222 of Lecture Notes in Computer Science, Berlin 1997, Springer Verlag, pages 24-45. [11] S. Vuong and I. Ivanov, ”Mobile Intelligent Systems: Wave vs. Java”, IEEE Comp. Soc., Mar. 1996. [12] P. Sapaty, ”The WAVE paradigm”, Technical Report 17/92, Dept. of Informatics, Univ. of Karlsruhe, Germany, July 1992. [13] D. Cieslik, Steiner Minimal Trees, Kluwer, 1998. [14] S. González-Valenzuela, V.C.M. Leung, ”QoS-routing for MPLS networks employing mobile agents”, IEEE Network, vol. 16, no. 3, pp. 16 - 21, May 2002. [15] http://www.cordis.lu/ist/ [16] T. Mota, S. Gouveris, G. Pavlou, A. Michalas, J. Psoroulas: Quality of Service Management in IP Networks Using Mobile Agent Technology. MATA 2002: 193-205 [17] The Parlay Group http://www.parlay.org [18] The JAIN initiative http://java.sun.com/products/jain [19] J. Heinanen, ”A Single Rate Three Color Marker”, http:///www.ietf.org/rfc/rfc2697.txt, RFC 2697, September 1999. 21