SAARBRÜCKEN - Mit Cantus - dem campusüberdeckenden Netz der Universität des Saarlandes - wollte die Hochschule in Saarbrücken mehrere Fliegen mit einer Klappe schlagen. Neben Diensten wie Electronic-Mail wurde beispielsweise ein Zugang an Datex-P über BS2000-Rechner von Siemens realisiert. Der erste Teil des Berichts beschreibt den Ablauf der Cantus-Realisierung und gibt einen Überblick über die hier eingesetzten Komponenten und die zum Zuge kommenden Protokolle.

Cantus - das campusüberdeckende Netz der Universität des Saarlandes - wurde in den Jahren 1983 bis 1985 von Mitarbeitern des Rechenzentrums der Universität sowohl hardware- als auch softwaremäßig entwickelt. Es hat 1988 seinen vorläufigen Endausbau erreicht. Als Basiskomponente für den Aufbau einer Netzinfrastruktur nahm Cantus eine zentrale Stellung im Rahmen des I.I.I. - Kooperationsprojektes "Innovative Infomations-Infrastrukturen" zwischen der Siemens AG, München und der Universität des Saarlandes ein.

Heute sind auf einem Gelände von zirka zwei Kilometern Durchmesser und zirka 40 Gebäuden sechs Host-Systeme (vier BS2000- Anlagen, zwei Vax/Unix-Rechner), zirka 350 Mikros (Sinix-X, -X10,

-MX, -MX2, -MX300 und -MX500, MS-DOS/IBM PCs und Kompatible, Atari- Rechner) sowie zirka 400 Terminals und Drucker vernetzt. Hinzu kommt die Einbindung von Ethernet-Inhouse-Netzen, in denen Workstations unterschiedlicher Hersteller integriert sind. Darüber hinaus sind die Cantus-Subnetze auf dem Campus der Uni-Kliniken in Homburg (Entfernung zirka 30 Kilometer) und im Umweltforschungszentrum (Entfernung zirka fünf Kilometer) transparent in Cantus eingebunden; für den Netzbenutzer bedeutet dies, daß er nur ein einziges Netz "sieht".

Eigenentwicklung des Netzwerks

Cantus wurde weitgehend selbst entwickelt, denn zum damaligen Zeitpunkt waren auf dem Markt keine passenden Lösungen für eine flächendeckende Vernetzung des Campus erhältlich, oder sie waren nicht zu finanzieren. Das Netz sollte die möglichst universelle Basis ("jeder mit jedem") für die heute selbstverständlichen Dienste wie File-Transfer, Remote-Dialog und Electronic-Mail bilden. Darüber hinaus sollte auch der Zugang zu öffentlichen Netzen gewährleistet sein: Ein Zugang zum Datex- P-Netz der Deutschen Bundespost ist von allen an Cantus angeschlossenen Terminals und PCs möglich. Derzeit ist dieser Zugang über einen BS2000- Host realisiert. Zusätzlich kann über diesen auch das CSNET-Mail-System genutzt werden. Mail versenden und empfangen ist auch über ein Vax/Unix-System möglich, das ebenfalls - über eine Datex-P-Untervermittlung - an das öffentliche Netz angeschlossen ist. Zukünftig sollen diese Aufgaben von einem einzigen Rechner - einem Sinix MX500 - wahrgenommen werden, der dann auch die Verteilung der eingehenden Mail zu den Zielrechnern vornehmen wird. Möglich ist dies bisher schon für alle an Ethernet mit TCP/IP angeschlossenen Rechner.

Um den Campus flächendeckend zu vernetzen, wurde Cantus zweistufig konzipiert:

- Ein Basisnetz mit 16 internen Knoten bildet einen Backbone. Die Topologie des internen Netzes entspricht dabei einem Graphen mit dem Grad 3 und dem Durchmesser 4, das heißt ein interner Netzknoten ist mit drei Leitungen mit Nachbarknoten verbunden, und eine Nachricht muß von höchstens drei Knoten weitergeleitet werden, um den Zielknoten im internen Netz zu erreichen.

- Die zweite Stufe des Netzes bilden die angekoppelten Inhouse-Netze, zum Beispiel Ethernet oder sogenannte Stationscontroller (STC) zum Anschluß von Endgeräten.

Die Netzknoten und STCs sind mit Siemens-SMP-kompatiblen Teilen in einer modularen Form aufgebaut. Verbunden sind sowohl die STCs als auch die Netzknoten über ein Twisted-pair-Kabel, das eine Übertragungsgeschwindigkeit von 1 MBit erlaubt.

Bild 1 zeigt eine der Zugangsmöglichkeiten zu Cantus - ausgerichtet nach dem ISO-Schichtenmodell - über einen Stationscontroller. Auf Ebene 2 wird hier HDLC LAPB als gemeinsames Protokoll benutzt. Gleichzeitig sieht man die Einbettung fremder Protokolle in die Cantus-Umgebung. Cantus ist auf Ebene 3 datagrammorientiert. Innerhalb des Netzes stellt dies die höchste Ebene dar. Die Schichten 4 bis 7 müssen in den Endsystemen realisiert werden. Im folgenden Abschnitt wird die Cantus-Rechnerkopplung anhand der Sinix-MX2-(MX300, -MX500)- PCs exemplarisch dargestellt. Diese Art der Anbindung setzt jedoch voraus, daß der vom Hersteller vorgegebene Protokoll-Stack aufgetrennt und verändert wird. Dies gilt nicht für Rechner, die Cantus nur als Transitnetz benutzen und an verschiedene Ethernet-Segmente angeschlossen sind. Hier existiert eine sogenannte Cantus/Ethernet-Bridge, die funktional einer Mac-Level-Bridge gleichzusetzen ist. Dies hat den entscheidenden Vorteil, daß keinerlei Modifikationen in den Endsystemen notwendig sind.

Im Rahmen des I.I.I.-Projektes wurde von Mitarbeitern des Rechenzentrums der Universität des Saarlandes der Anschluß von BS2000- Host-Rechnern der Serie 7.XXX an Ethernet-Local-Area-Netzwerke (LAN) realisiert. Innerhalb dieser Arbeiten wurde die Zentraleinheiten- Anschlußsteuerung für LAN (kurz ZAS-LAN, Siemens-Produktname Transdata 9632) entwickelt, die aus einem PC-MX2-Gehäuse mit Stromversorgung und Multibus und aus den folgenden Multibus- Flachgruppen besteht:

- Kanal-Interface-Board zur Anpassung an den Byte-/Blockmultiplex- Kanal einer 7.XXX-Zentraleinheit ,

- Exos-201-Ethernet-Interface-Board der Firma Excelan zum Anschluß an das "Yellow Cable" und

- CPU-Board mit entsprechender Steuerungs-Firmware .

Die Möglichkeit, die Exos-201-Baugruppe mit Protokoll- /Netzwerk-Software zu laden, wird in diesem Fall nicht genutzt, statt dessen wird sie im sogenannten Link-Level-Mode betrieben. Die erforderlichen Datenkommunikationsdienste und -funktionen werden durch die BS2000- Datenfernverarbeitungskomponente Transdata-DCM erbracht, die über den sogenannten Beam-LAN-Port Zugang zur ZAS-LAN hat. Dies bedeutet, daß ZAS-LAN

- in Senderichtung bereits vollständig im Ethernet-Format aufbereitete Datenpakete vom Beam-LAN-Port über den Kanal erhält und diese "unbesehen" zum Ethernet weiterreicht und

- in Empfangsrichtung vom Ethernet kommende Datenpakete unverändert - von gewissen Filterfunktionen abgesehen - an den Beam-LAN-Port über den Kanal weitergibt.

ISO-Protokolle im Standardfall

Die ZAS-LAN bildete den Ausgangspunkt für den Anschluß der BS2000-Anlage an Cantus; hinsichtlich der Hardware wurde die ZAS-LAN um eine Baugruppe erweitert, die den Cantus-Anschluß auf Schicht 2 realisiert.

Die über Cantus von der BS2000-Anlage erreichbaren Rechner werden in Transdata DCM so generiert, als wären sie am selben Ethernet angeschlossen wie die tatsächlich über LAN erreichbaren Rechnersysteme; ihre Ethernet-Adresse bildet jedoch eine eigene Adreßfamilie und unterscheidet sich so von den "echten" LAN-Rechnern.

Die entsprechend geänderte ZAS-LAN/Cantus-Firmware der CPU-Baugruppe nutzt nun in Senderichtung die Adreßinformation und leitet die Pakete entweder zur Exos-201 - oder zur Cantus-Adapter-Baugruppe weiter; im letzteren Fall wird der von Beam gelieferte Ethernet- Paketvorspann durch einen Cantus-Vorspann ersetzt. In Empfangsrichtung wird der Paketvorspann bei von Cantus ankommenden Paketen durch einen entsprechenden Ethernet-Header ersetzt und die so veränderten Pakete werden - wie "echte" Ethernet-Pakete - an Beam weitergegeben.

Im Standardfall erfolgt die Kommunikation zwischen einem BS2000-Rechner und Partnerrechnern über ein LAN mittels ISO- Protokollen in der Transport- (ISO 8073 Class 4) und Netzwerkschicht (ISO 8473 inactive).

Durch die Angabe eines besonderen Transdata-DCM- Generierungsparameters kann jedoch erreicht werden, daß die NEA-Protokolle Neatev/T in Schicht 4 und Nean in Schicht 3 benutzt werden. Wie anschließend noch erläutert wird, sind diese Protokolle für die Kommunikation zwischen BS2000-Rechnern und Sinix PC-MX2, MX300- beziehungsweise --MX500-Rechnern über Cantus erforderlich.

Die Netzanbindung von Sinix-Rechnern moderner Bauart geschieht mittels sogenannter Communication-Controller (CC). Dabei handelt es sich um Multibus-Flachbaugruppen, die über eigene Prozessoren, sowie Speicher- und Kommunikationsbausteine verfügen. Die CCs realisieren mit ihren Kommunikationsbausteinen den Netz-Hardware- Zugang; sie werden mit - für den jeweiligen Einsatzfall geeigneter - Protokoll-Software (Communication Controller Programm - CCP) geladen und arbeiten diese Protokolle selbständig ab. Dadurch wird der Hauptprozessor von der "lästigen" Protokollabarbeitung entlastet.

Da die Protokoll-Software (CCPs) bereits die Schichten 3 und 4 umfaßt, enthält der Sinix-Kern dann "nur" noch einen Treiber, der einerseits über die Sinix-System-Call-Schnittstelle das Benutzer-/Prozeß-Interface bildet und andererseits die Anpassung an die verschiedenen Klassen von CCs durchführt. Im Normalfall benutzen Anwenderprogramme jedoch nicht die System-Call-Schnittstelle direkt; sie sind statt dessen mit der sogenannten CMX Bibliothek (CMX = Communikation Method SINIX) gebunden, deren Unterprogramme die System-Calls für sie durchführen. Diese Vorgehensweise ermöglicht einen verhältnismäßig einfach verwendbaren, transparenten und vor allem sehr flexiblen Zugang zu den Netzwerktransportdiensten.

Wegen der Verfügbarkeit von HDLC LAPB als Cantus-Schicht- 2-Protokoll sowie X.21 als Hardware-Schnittstelle wurde für die Sinix-PC- MX2/Cantus-Integration folgende Lösung realisiert: Als CC kommt das sogenannte DFÜ-Board (Dueai) zum Einsatz; damit lassen sich Übertragungsgeschwindigkeiten von bis zu 64 kBit pro Sekunde im Synchronbetrieb erreichen. Für die Software-Integration diente CCP-WAN 1, charakterisiert durch das Netzprofil

- Neatev/T in Schicht 4,

- Nean in Schicht 3 und

- HDLC LAPB in Schicht 2 als Ausgangsbasis. Die uns von Siemens zur Verfügung gestellten CCP- WAN 1-Quellprogramme wurden folgendermassen modifiziert: Der NEA/HDLC-Protokoll-Stack wurde an der Grenze zwischen Nean und HDLC - also zwischen den Schichten 3 und 2 - "aufgetrennt" und eine Cantus-Anpassungsschicht (Ebene 3) "eingezogen" (siehe Bild 2 und 3). Diese Zwischenschicht fügt nun in Senderichtung bei den von Nean kommenden Paketen einen Cantus-Header ein und reicht diese an HDLC zum Weitertransport über Cantus weiter. Dieser Vorgang erfordert eine NEA-Cantus-Adreßumsetzung, die an Hand einer dynamisch ladbaren Tabelle vorgenommen wird. Eine aktuelle Version dieser Adreßzuordnungstabelle fordert sich im übrigen der Sinix PC-MX2 beim Hochfahren von einem zunächst für diese Zwecke implementierten Name-Server vom BS2000-Host an. Bei den in Empfangsrichtung von HDLC kommenden Paketen wird der Cantus-Vorspann durch die Cantus-Zwischenschicht entfernt und die so modifizierten Pakete werden an Nean weitergegeben.

Cantus wird in seiner jetzigen Form sicherlich noch einige Jahre fortbestehen, jedoch sollte man heute schon die sich derzeit auf den Kommunikationssektor abzeichnenden Entwicklungen im Auge behalten, um hier - vielleicht durch Ablösung oder Austausch einzelner Elemente - einen sukzessiven Neuaufbau beziehungsweise eine der technologischen Entwicklung angepaßte Kommunikationsinfrastruktur zu erreichen. Hierfür stehen derzeit ins besondere die Glasfasertechnik, die im öffentlichen Bereich anstehende Einführung von ISDN, wie auch die mögliche Weiterentwicklung zum Breitband-ISDN-B mit völlig neuen Diensten. Dies wird für lokale Netze, wie etwa Campus-Netze, nicht ohne Auswirkungen bleiben. Insbesondere hilft der Einsatz von LWL-Kabeln, größere Entfernungen zu überbrücken. Hier könnte man sich zum Beispiel einen 100 Mbit pro Sekunde schnellen FDDI-Ring (Fiber Distributed Data Interface) oder einen C/P-Ring (Circuit/Paket Switch Ring) als Backbone vorstellen, womit später ein einheitliches Kommunikationskonzept realisiert werden könnte, bei dem die Zeit der getrennten Übertragung von Daten, Sprach- und Videoinformation vorbei ist. Fortsetzung folgt