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
Herunterladen