Einführung

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.

Internet 2

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

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.

Internet2 Topologie

QoS für Internet2

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.

Skalierbarkeit

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.

Verwaltung und Messung

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.

Q-Bone

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.

Qbone Premium Service (QPS)

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:

Messungen im QBone

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.

Bandwidth Brokers

Die Bandwidth Broker sollen die Reservation und die Kontrolle von QoS vereinfachen. Ein BB soll 5 Funktionen erfüllen:

  1. Applikationen oder Router müsse Bandbreiten Reservationen austauschen (Protokoll).
  2. Der BB soll den Applikation oder den Routern antworten, nachdem er die QoS mit den Routern hergestellt hat.
  3. Bandbreiten over-booking verwerfen.
  4. Router rekonfigurieren.
  5. Den Abbau der Verbindung behandeln und die Bandbreite wieder freigeben.

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.

Bandwidth Broker
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.

Schlussfolgerungen

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.

Referenzen

/Camr98/
D.Camron: The Internet2 Project; in Internet2, The Future of the Internet, Computer Technlogy Research Corporation, U.S.A., 1998, pp 19-30.
/TeGe99/
B. Teitelbaum, R. Geib: Internet2 Qbone: A test Bed for Differentiated Services; In Proceedings of The Global Internet Summit (INET'99), San Jose, California, U.S.A., June 1999.
/TeSi98/
B. Teitelbaum, J. Sikora, T. Hanss: Quality of Service for Internet2; First Internet2 Joint Applications/Engineering QoS Workshop, Santa Clara, California, U.S.A., May 1998
/Jaco98/
Van Jacobson: Differentiated Services for the Internet; First Internet2 Joint Applications/Engineering QoS Workshop, Santa Clara, California, U.S.A., May 1998
/Wroc98/
J. Wroclawski: Evolution of End-to-End QoS: A Design Philosophy; First Internet2 Joint Applications/Engineering QoS Workshop, Santa Clara, California, U.S.A., May 1998
/Teit99/
B. Teitelbaum: QBone Architecture (v1.0); Internet2 QoS Working Group Draft, http://www.internet2.edu/qos/wg/papers/qbArch/1.0/draft-i2-qbone-arch-1.0.html, August 1999

Internet2 website