Das Internet wird zur Zeit für "kommerzielle" Anwendungen
benutzt. Die aktuellen Protokolle (die "best-effort" Protokollen
sind) und die Bandbreitenverstopfung können die Anwendungen
des nächsten Jahrhunderts, die von der Forschung und den
Universitäten gebraucht werden, nicht unterstützen. Um
dieses Problem zu lösen wurde die Internet2 Projekte in Gang
gebracht. Von Anfang an wurde Quality of Service (QoS) als ein
wichtiger Teil des Internet2 Projekt erkannt. Es soll skalierbar
und verwaltbar sein sowie interdomain QoS bieten.
Das Internet2 Projekt wird von 130 US Universitäten, 40 Unternehmen und 30 sonstige Organisationen unterstützt. Es wurde 1996 gestartet. Es soll ein Breitbandnetzwerk sein. Seit dem letzen Jahr sind auch Netzwerken aus dem Rest des Welt beteiligt.
Das Netzwerk ist auf mehreren Backbonenetzen basiert: vBNS (very
high performance Backbone Network Service), Abilene und lokale
Netzen.
Das vBNS Backbone besteht aus OC-12C-Verbindungen (622 Mbit/s)
zwischen 12 POPs. Die Universitäten sind dann mit
OC-3C-Verbindungen (155 Mbit/s) an den POPs angeschlossen. Das
Backbone soll auf OC-48 (2,4 Gbit/s) upgegradet werden. vBNS
verbindet IP durch eine ATM-switching Matrix und eine SONET
Architektur. Das vBNS Netzwerk wird auch als Testnetzwerk für
IPv6 und RSVP (Resource Reservation Protocol) und PIM (Protocol
Independent Multicast).
Abilene ist ein jüngeres Projekt (es wurde von Al Gore im
April 1998 gestartet). Von Anfang an ist es auf einem 2,4 Gbit/s
Backbone basiert und soll nachher auf 9,6 Gbit/s upgegradet werden.
Die Universitäten sollen mit OC3 oder OC12 an Abilene
angekoppelt sein. Abilene benutzt IP über SONET.
Abilene und vBNS sind nicht gleich: Abilene ist mehr ein
Prüfstand für neue Netzwerktechnologien als für
Produktionapplikationen. Abilene muss nicht so zuverlässig
sein wie vBNS, das von der Forschung schon gut benützt ist,
und es kann Tests geben, die den Netzwerkbetrieb für mehrere
Stunden oder Tagen stark stören.
Diese Unterschiede werden den Forschern helfen, um zu testen, ob
die Applikationen über verschiedene, Netzen und
Netzwerktechnologien funktionieren.
Die QoS-Lösung muss fortschtritliche Applikationen ermöglichen, skalierbar, verwaltbar und messbar sein. Verschiedene einzelne Teile und Netzwolken müssen miteinander funktionieren und Operating System und Middleware müssen es unterstützen.
Die Skalierbarkeit ist wahrscheinlich die schwierigste Arbeit. Die Kernrouter werden mehrere tausende Datenströme mit einem grossen Durchsatz übermitteln müssen. Per-Strom QoS-Eigenschaften können nicht bei so vielen Datenströme unterstützt werden. Lösungen wie RSVP oder IntServ können deshalb nicht für Internet2 gebraucht werden.
Es müssen Mechanismen, über die man QoS alloziert,
entstehen. Der Endbenutzer soll auf QoS-Charakteristiken zugreifen
können, ohne dass es die Netzwerkverwaltung überlastet.
Und QoS-Raub muss abgeschreckt werden.
Da die Benutzer (Institutionen oder Endbenutzer), für die QoS
erbracht worden, zahlen werden muss es Mittel geben, um diese
Qualität zu überprüfen. Netzwerkanbieter werden auch
Werkzeuge brauchen, um QoS Services zu debuggen.
DiffServ scheint die einzige Lösung zur Zeit zu sein die auf
dem Backbone funktionieren kann. Das Aufwand von IntServ, wo jeder
Datenstrom einzel behandelt wird, und RSVP kann bei Kernrouter
nicht ertragen werden. Die ersten Lösungen werden mit DiffServ
gemacht, aber IntServ und RSVP werden trotzdem betrachtet, um zu
sehen, ob es eine Mittellösung zwischen DiffServ (langfristig,
Aggregate) und IntServ (dynamisch, per-flow) gibt.
Qbone ist einen Prüfstand für Interdomain DiffServ. Jedes
Netzwerk das an QBone beteiligt ist, wird als "DS domain" genannt
und die Union von diesen Netzwerken eine "DS Region". Der erste
Service der implementiert werden soll ist der "Virtual Leased Line
Service" (auch Qbone Premium Service (QPS) genannt). Jede DS Domain
muss expedited forwarding (EF) per-hop behavior (PHB)
unterstützen und seine Stromklassifizierer und conditioner
(meters, markers, shapers und droppers) müssen einen QPS
für EF-Aggregaten besitzen.
Qbone wird Mehrwert zu den normalen DiffServ bringen, in dem es
interdomain Operationen geben wird. Man kann erwarten, dass die
Netzwerk Operatoren automatisierte Werkzeuge einsetzen werden um
"admission control" und Konfigurierung der Netzwerk Device zu
machen. Diese Werkzeuge werden als Bandwidth Broker (BB) benannt.
Es steht klar, dass die BB auch untereinander kommunizieren
müssen, um interdomain Reservation zu machen und das ein
inter-BB Signalling Protokoll entworfen werden muss.
Jeder DS Domain muss eine gut definierte administrative Grenze
haben. Bilaterale service level specifications (SLS) existieren
zwischen angrenzenden DS Domain. Diese SLS definieren, wie der
Verkehr von DS Grenzknoten klassifiziert und weitergeleitet
wird.Für Qbone werden einige minimale Eigenschaften
verlangt.
Das QPS gibt eine maximale Bandbreite Garantie. Das PHB kann als "forward me first" interpretiert werden. QPS benützt das Expedited Forwarding per-hop forwarding behavior. EF verlangt, dass die der Senderate von einem Aggregat von Paketen von einem DiffServ Knoten gleich oder grösser eine konfigurierbaren Rate sein muss und der EF Verkehr sollte diese Rate bekommen, unabhängig von anderen Datenströme, die durch diese Knoten fliessen: die ankommende Rate muss kleiner als die abfahrende Rate für eine Zeit gleich oder grösser als die Zeit die für das absenden einen MTUgrossen Paket mit der peak Rate. QPS hat übrigens auch sehr strenge maximale jitter (0,42 ms für eine 64 Byte MTU, 3.36 ms für eine 512 Byte MTU, 9,84 ms für eine 15000 Byte MTU).
Jede QPS Reservation wird durch 8 Parameter definiert: source,
dest, route, startTime, endTime, peakRate, MTU, jitter.
Die anderen Type of Service (ToS), die noch nicht implementiert
werden, sind:
Es werden zwei Arten Messungen gemacht:
Die Messungen werden in 3 Klassen geteilt: verlangt, empfohlen und
zukünftig. Die empfohlenen Messungen sind die Messungen, die
noch nicht gut definiert sind. Zukünftige Messungen sind jene
wo man noch nicht weiss, wie man diese Messung machen muss.
Verlangte Messungen: one-way packet loss, one-way delay variation
(jitter), routing Informationen, Bandbreite, EF commitment, EF
reservation load.
Diese Messungen werden mit Hilfe von SNMP oder passiv
durchgeführt.
Empfohlene Messungen: EF und BE discards, one-way packet delay,
burst throughput.
Zukünftige Messungen: routing und Applikation spezifische
Messungen.
Die Bandwidth Broker sollen die Reservation und die Kontrolle von QoS vereinfachen. Ein BB soll 5 Funktionen erfüllen:
Der BB wird die Routern von Leaf (der erste Routeur der von den
Daten gesehen wird) bis Edge konfigurien. Der Datenstrom wird dann
in einem Aggregat angepasst. Der BB von dem Netzwerk des anderen
Benutzers wird die Router von Edge bis zum Host
konfigurieren.
Ein erster Test von BB wurde Anfang November 1999 gemacht in Ann
Arbor, Michigan: das Bandwidth Broker Operability Event. Leider
wurde das Bericht noch nicht veröffentlicht.
Die Nachfrage nach grosser Bandbreite und QoS ist immer wachsend.
Heute gibt es eine gute Definition und erste Versuche, es zu
implementieren, nur für Premium Service. Um mehr
Flexibilität zu haben werden Assured Service und CoS
nötig. Nachdem diese neuen Service existieren, wird es
möglich zu wissen, ob DiffServ und die Bandwidth Broker QoS
garantieren können.
Nachdem diese technischen Probleme gelöst sind, werden
administrative Probleme erscheinen: wie wird QoS berechnet? Wie
werden QoS-Verletzungen behandelt? Wie werden die Endbenutzer
sicher sein, dass sie bekommen was sie zahlen?
Der Schritt danach wird erkennen lassen, wie die neuen Technologien
und QoS von Internet2 das "kommerzielle" Internet beeinflussen
werden und ob man eine Alternativen zu Best Effort haben
wird.