http://www.dkrz.de/dkrz/hhr.html (Einblicke ins Internet, 10/1995)Die ersten Planungen für den Aufbau eines regionalen Hochgeschwindigkeitsdatennetzes begannen im Frühjahr 1989. Die Telekom tat sich damals sehr schwer, neben München und Stuttgart weitere Pilotversuche in DQDB-Technik zu starten. Insgesamt dauerte es noch weitere zwei Jahre, bis dann im Dezember 1992 Verträge für den Aufbau eines FDDI-Backbone zwischen den sechs Partnern des HHR mit der Telekom geschlossen werden konnten.
Die Topologie der zu realisierenden Verkabelung zwischen den einzelnen Standorten der HHR-Partner wurde von der Telekom festgelegt. Aufgrund der bei FDDI gegebenen Entfernungsbegrenzung auf 100 Kilometer konnten die Standorte nicht durch einen einzigen Doppelring miteinander verbunden werden. Daher setzt sich das HHR aus drei FDDI-Ringen zusammen, wobei ein Doppelring mit "Dual Attached Stations" und zwei "Einfach"-Ringe mit "Single Attached Stations" aufgebaut wurden. (HHR-Topologie)
Eingesetzt werden als technische Komponenten in diesem Netz neun CISCO-Router AGS+ mit Translation-FDDI-Interface-Karten, ein Konzentrator Network Peripherals und zwölf Konverter FDDI-Electronics. Bis auf den Management-Anschluß der Hamburger Informatik (Uni-FBI) wurden alle CISCO-Router der Telekom mit zwei FDDI-Interface-Karten ausgestattet. Dadurch konnte zwischen dem HHR-Backbone und den lokalen Netzen der Institutionen eine FDDI-FDDI-Kopplung aufgebaut werden, da alle anzuschließende LANs schon damals jeweils über eigene FDDI-Backbone-Netze verfügten. Der Anschluß der Hamburger Informatik weicht davon ab: Durch die zwischenzeitliche räumliche Trennung des FB Informatik vom Regionalen Rechenzentrum ist die Informatik über ein Ethernetsegment an das HHR angeschlossen.
Das Management und damit verbunden die Auswahl der einzusetzenden Protokolle lag in der Verantwortung des HHR, wobei der Hamburger Informatik eine federführende Rolle zukam. Für die Startphase des HHR wurde zunächst nur das Routing für Internet-Protokolle vereinbart, da nur für diese Protokollvarianten eine durchgängige sowie globale Rechneradressierung existierte; dieses gilt immer noch.
Das HHR ist als ein eigenständiges Netz anzusehen, an welches die LANs der einzelnen Institutionen angeschlossen werden. Daher wurde es notwendig, für die Einbindung des HHR in das Internet einen eigenen Klasse C -- Adreßbereich beim NIC zu beantragen. Bei der Auswahl eines Routing-Protokolls für das HHR fiel die Wahl auf ein internes Routing-Protokoll, da der Einsatz externer Routing-Protokolle zur Folge gehabt hätte, daß das HHR hierarchisch den einzelnen LANs überzuordnen gewesen wäre; die WAN-Verbindungen über das HHR hätten koordiniert werden müssen. Dieses konnte und wollte keine der beteiligten Institutionen akzeptieren.
Die Wahl des einzusetzenden internen Routing-Protokolls fiel auf das damals neue Protokoll OSPF (Open Shortest Path First). Abgesehen davon, daß dieses Protokoll beim Verteilen von externen "Routes" von allen existierenden internen Routing-Protokollen die geringsten Netz- und CPU-Ressourcen benötigt, ermöglicht es, Subnetzinformationen von Adreßbereichen beteiligter Institutionen zu verteilen, was für die beiden Anschlußpunkte der Universität Hamburg -- Uni-FBI (Fachbereich Informatik) und Uni-RRZ (Regionales Rechenzentrum) -- von Bedeutung ist, da beide zum gleichen Internet-Adreßbereich 134.100.0.0 gehören. Die Auswahl des OSPF-Protokolls erschien zum damaligen Zeitpunkt zwar etwas gewagt, jedoch zeigt sich rückblickend auf das erste Betriebsjahr, daß OSPF die darauf gesetzten Erwartungen voll erfüllt hat.
Einige Anpassungsarbeiten in der ersten Betriebsphase ergaben sich aus der Tatsache, daß die gewachsenen Netzstrukturen in den beteiligten Institutionen bei der jeweiligen Anbindung an das HHR berücksichtigt werden mußten und damit eine einheitliche Konfiguration der Anschluß-Router nicht möglich war. So gab und gibt es einige Institutionen, die in ihrem LAN kein OSPF-Protokoll fahren wollen oder können, da Router in den LANs betrieben werden, die das OSPF-Protokoll nicht unterstützen.
Einige Protokollübergänge (Redistributions) zwischen OSPF und IGRP (CISCO eigenes Protokoll: Interior Gateway Routing Protocol), sowie zwischen OSPF und RIP (Routing Information Protocol) waren notwendig. Diese Übergänge erwiesen sich erwartungsgemäß auch als gewisse Problemstellen beim Betrieb.
So zeigte sich unter anderem, daß aufgrund eines Fehlers in der Software der HHR-Router der RIP-OSPF-Übergang nicht stabil zu betreiben war; in diesem Falle mußte auf statische "Routes" ausgewichen werden. Diese statischen "Routes" wurden dabei nur auf dem betroffenen Anschluß-Router konfiguriert und werden dort sofort wieder nach OSPF übernommen.
Ebenfalls kamen statische "Routes" bei OSPF-IGRP-Übergängen für die im OSPF mit Subnetz-Informationen versehene Route 134.100.0.0 zum Einsatz, da hierfür fehlerhafterweise keine Route für IGRP generiert wird.
Beide Problempunkte sind in der aktuellen Version (9.1.7) der CISCO-Betriebssoftware behoben; diese wird demnächst im HHR installiert. Bestehen bleiben dann noch insgesamt vier bis fünf statische Routing-Einträge für Institutssubnetze, welche nur über Router oder Rechner mit Routing-Funktion erreicht werden können, die über kein dynamisches Routing-Protokoll verfügen.
Für Abnahme und Betrieb des von der Telekom aufgebauten FDDI-Netzes sind Vereinbarungen getroffen worden, durch welche im HHR für jeden Partner eine zu erbringende Mindestleistung und Verfügbarkeit sichergestellt werden soll. Aus diesem Grunde wurde frühzeitig mit Leistungsmessungen im HHR begonnen.
Als Mindestleistung der Übertragungsbandbreite war definiert worden, daß Ethernet-zu-Ethernet-Verbindungen zwischen zwei beliebigen HHR-Anschlußeinrichtungen über das HHR-FDDI-Netz ohne Leistungsminderung übertragen werden müssen. Messungen ergaben, daß diese Bedingung ohne jede Einschränkung von Anfang an erfüllt wurde.
Da alle Institutionen an das HHR mit seinen Telekom-Routern in die lokalen FDDI-Backbones integriert wurden, sind Leistungsmessungen zwischen Rechnern mit FDDI-Interfaces über das HHR hinweg wesentlich interessanter und aussagekräftiger.
Die Leistungsmessungen wurden unter Verwendung der Internet-Protokolle "User Datagram Protocol" (UDP) und "Transmission Control Protocol" (TCP) durchgeführt, und zwar wurden hierfür das Programm spray unter UDP und eine eigene Programmentwicklung tcpspeed unter TCP eingesetzt. Wie bei solchen Untersuchungen üblich, wurde generell auf das Ablegen der transferierten Daten auf einen Massenspeicher verzichtet und lediglich der Datentransfer zwischen den Prozeß-Images auf den eingesetzten Rechnern gemessen.
Um die Leistungsgrenze des HHR ausloten zu können, wurden die FDDI-FDDI-Messungen so durchgeführt, daß gleichzeitig mehrere Rechner an verschiedenen Standorten die Daten zielgerichtet auf einen -- sehr leistungsfähigen -- Rechner transferierten. Bis auf die Management-Maschine der Informatik waren alle bei den Messungen beteiligten Rechner mit FDDI-Interface-Karten ausgestattet. Dieses Verfahren wurde deshalb gewählt, weil gegenwärtig kaum Rechner zur Verfügung stehen, deren FDDI-Interface allein die volle FDDI-Leistungsbandbreite ausschöpfen können.
Die Leistungsmessungen für das HHR lassen sich wie folgt zusammenfassen:
Maximale Durchsatzleistung über das HHR unter TCP/IP 22 MBit/Sek
Maximale Durchsatzleistung über das HHR unter UDP/IP 52 MBit/Sek
Neben der Frage nach der Durchsatzleistung eines Hochgeschwindigkeitsnetzes ist der Grad der Verfügbarkeit von besonderer Bedeutung. Aussagen über die Verfügbarkeit lassen sich in zwei Klassen untergliedern: der Totalausfall des Netzes oder der Ausfall einzelner Komponenten mit der Konsequenz eines singulären Ausfalls einer oder mehrerer Institutionen. Im HHR wird die Protokollierung von Ausfällen auf der Management-Maschine mit dem Software-Tool SunNet-Manager durch periodisches Absenden von ICMP-Kontrollmeldungen an ausgewählte Rechner in den LANs der Institutionen ermittelt.
Im bisherigen Betrieb des HHR hat es einen Totalausfall noch nicht gegeben. Durch die "Recovery"-Fähigkeit von FDDI zum einen und die beim HHR durch die drei Backbone-"Ringe" gegebene Teilautonomie zum andern ist dieser Fall auch praktisch ausgeschlossen. Alle hervorstechenden Ausfallzeiten sind jeweils nur auf ein Einzelereignis zurückzuführen, nämlich den Ausfall eines FDDI Multi-/Monomode-Konverters. Hier mußte leider festgestellt werden, daß ein Teil der im HHR eingesetzten Geräte aus einer fehlerhaften Serie stammten; diese Fehlerquelle wurde inzwischen beseitigt.
Die Erfahrungen des nun gut einjährigen Betriebes haben gezeigt, daß die in das HHR gesetzten Erwartungen voll und ganz erfüllt werden. Mit dem Aufbau des FDDI-Netzes steht bisher leider nur ausgewählten Institutionen in der Hamburger Region ein leistungsfähiges Hochgeschwindigkeitsnetz zur Verfügung. Das HHR wird als Backbone zwischen diesen Institutionen gut genutzt, wobei schwerpunktmäßig zur Zeit Ressource-Sharing, Massendatentransfer und der Einsatz von X11-Anwendungen zwischen DESY -- (UniHH, TUHH), DKRZ -- (GKSS, UniHH) und TUHH -- (UniBwH, UniHH) hervorstechen. Für diese Art der Nutzung hat sich die Kapazität des HHR zur Zeit als vollkommen ausreichend erwiesen. In Vorbereitung sind Untersuchungen zu breitbandintensiven Anwendungen, wie z.B. Videoconferencing, Zugriffe auf Echtzeit-Bilddatenbanken und Informationsdienste wie das "World-Wide-Web" (WWW). Hierbei könnte sich die mangelnde Fähigkeit der FDDI-Technologie für isochronen Datentransfer nachteilig auswirken.
Aus heutiger Sicht muß die Frage gestellt werden, ob ein Hochgeschwindigkeitsnetz auf Basis von FDDI die Erfordernisse an ein regionales Hochleistungsdatennetz wie das HHR erfüllen konnte und auch zukünftig erfüllen wird. Inzwischen vermarktet die Telekom das MAN-Verfahren Distributed Queue Dual Bus (DQDB) unter dem Produktnamen DATEX-M als die geeignete Technologie für Metropolitan Area Networks. Als der ultimative Netzstandard der Zukunft wird nun jedoch der Asynchrone Transfer Modus (ATM) als neue Vermittlungstechnik prognostiziert.
Das HHR wurde als Pilotprojekt mit einer Laufzeit von fünf Jahren ausgelegt. Dieses bedeutet, daß sich das HHR-Konsortium einerseits rechtzeitig um die Fortführung des Projektes im Jahr 1998 sorgen muß , andererseits aber auch frühzeitig die Ankopplung des regionalen Hamburger HDN an andere regionale oder auch nationale Hochgeschwindigkeitsnetze zur besseren Nutzung planen und betreiben sollte. Hier bietet sich entweder ein Anschluß des HHR an die vom DFN geplanten und geförderten Regionalen Testbeds an oder auch die Teilnahme an den ATM-Feldversuchen der Telekom. Gespräche über einen Anschluß des HHR an ATM als Pilotprojekt haben zwischen dem HHR-Kreis und der Telekom bereits stattgefunden. Nachdem die Telekom nun ihre ersten Vorstellungen über ATM-Tarife öffentlich bekanntgegeben hat, sind weitere Gespräche eingefroren.
Wir warten auf bessere Zeiten.
Dr. Hans-Joachim Mück
Universität Hamburg,
Fachbereich Informatik
email: mueck@rz.informatik.uni-hamburg.d400.de
