s~

Ein Rechenzentrumals Nutzer:Gateway contraHacker

Zur Integration desdeutschen EARNin das DFN:Ein Schritt vorwärts

Standards-FunctionalStandards-Profiles:Ein Pfad durch denweiten OSI-Dschungel

Für und Wider:Ein eigenes Netz desDFN?

Heft 5Juli 1986 . Jahrgang 3

Herausgeber:Verein zur Förderung einesDeutschen Forsch u ngsnetzes e.V.-DFN-

ISSN 0177-6894

Inhalt Vorwort Prof. Dr. G. Turner

Impressum

Herausgeber: Verein zur Förderung einesDeutschen Forschungsnetzes e. V. - DFN-Verein -Pariser Str. 44, 1000 Berlin 15, Tel. : 030/884299-25

Redaktion: Marion Kern, Ahornstr. 22, 1000 Berlin 37,Tel. : 030/8029601, Mitarbeit: K.-F. Egetenmeier,DFN-Verein

Druck: gnauck+hermenau, Berlin

Nachdruck nur mit schriftlicher Genehmigung durchden DFN-Verein und mit vollständiger Quellenangabe.

Titelbild: Für einen PKW-lnnenraum wurdenmit Hilfe des DFN Eigenschwingungen be-rechnet. Die gelben Linien entsprechen Be-reichen gleicher Druckschwankung, d. h.Lautstärke. Die Zahlenangaben sind auf700% normiert. Die Rechnungen erfolgtenvon Erlangen aus an dem Feldrechner DAPdes Queen Mary College in London.

Ein Rechenzentrumals Nutzer:Gateway contra Hacker

Zur Integration des deutschenEARNindasDFN:Ein Schritt vorwärts

DFN-Dienste:AngeschlosseneInstitutionen

Start des Messagedienstes:Rund um den Globus

Standards-FunctionalStandards-Profiles:Ein Pfad durch denOSI-Dschungel

Datenkommunikationin Europa:RARE - eineeuropäische Idee

Für und Wider:Ein eigenes Netzfür das DFN?

AbgeschlosseneDFN-EntwicklungenJetzt wird's ernst!

E-Mail-Premiere auf der CeBIT:Viele Produkte - Eine Sprache

Teilnehmer äußern sichzurCeBIT'86:Debüt des DFN

Nutzergruppen

Die Mitgliederdes DFN-Vereins

Ansprechpartner

Veranstaltungen

Berichte undVeröffentlichungen

Dr. P. Holleczek

K. Birkenbihl, M. Hebgen,Dr. B. Wagner, G. Henken,K. Ullmann, M. Wilhelm

Dr. P. Kaufmann

Dr K. Truöl

Dr. W. BauerfeldM. Wilhelm

M. Wilhelm

R. Grimm

G. Scheint, Dr. G. MüllerH. Bliedung, P. Gentz,G. Foest

12

14

15

18

19

22

23

24

26

27

27

28

Einlege-blatt

ZumTo evonProf DrKarl HeinzBeckurts

Nach einem Anschlag verstarb am 9. Juli 1986das Mitglied des DFN-VerwaltungsratesProf. Dr. Karl Heinz Beckurts im Alter von 56 Jahren.

Professor Beckurts war ein engagierter underfolgreicher Wissenschaftler, von dessen Erfahrungzahlreiche wissenschaftliche und technische Projekteprofitiert haben. Er gehörte zu den Gründungsmitgliederndes DFN-Vereins und trug in zentraler Position imVerwaltungsrat mit die Verantwortung für dieKonzeptionierung und die Entwicklung des DeutschenForschungsnetzes. Seine fachliche Kompetenz undMenschlichkeit gaben dem Verwaltungsrat Bedeutungund Gewicht.

Sein Tod ist ein großer Verlust.

Tief erschüttert nehmen wir Abschied vonHerrn Professor Beckurts.

Vorstand und Verwaltungsrat desVereins zur Förderung eines DeutschenForschungsnetzes e. V.

Vorwort

Als neuer Senator für Wissenschaft und Forschung in Berlin und frühererPräsident einer deutschen Universität freut es mich, in den DFN-Mitteilun-gen ein Grußwort an die Adresse der vielen Nutzer und Interessenten desDeutschen Forschungsnetzes zu richten.Vor dem Hintergrund der Informations-und Kommunikationstechnikals fürdie Zukunft bedeutsame Schlüsseltechnologie mißt Berlin der Vernetzungvon Rechnerleistungen und dem dadurch verbesserten Austausch vonWissen und Informationen über Ländergrenzen hinweg große Bedeutungzu; Informationen sind heute unverzichtbare Voraussetzung für erfolg-reiche Forschung und Entwicklung. Daher begrüße ich es, daß der Vereinzur Förderung eines Deutschen Forschungsnetzes gerade von Berlin ausdie Infrastruktur für ein bundesweites leistungsfähiges Informations- undKommunikationssystem aufbaut. Dieses System ist offen für unterschiedli-ehe Rechner verschiedener Hersteller, um größtmöglichen Nutzen ausdem in ihnen gespeicherten Wissen zu ziehen, und zwar durch Rechner -zu Rechner - Dialog, Übertragung von Dateien und Austausch von Informa-tionen.

Für besonders bedeutsam halte ich auch den Einsatz des DFN-Vereins beider Gründung einer europäischen Vereinigung sowie seine Bereitschaft,die Erfahrungen des DFN für den Aufbau eines offenen europäischen Kom-munikationssystems einzubringen. Cooperation of Open Systems Inter-connection in Europe (COSINE) ist hierfür das Stichwort und EUREKA derRahmen, in dem dieses Projekt realisiert werden soll.Durch die seinerzeitige Wahl Berlins als Sitz für den DFN-Verein wird aner-kannt, daß Berlin bereits frühzeitig regionale Erfahrungen bei der Ent-Wicklung offener Rechnernetze gesammelt hat. Es seien hier das BerlinerRechnernetz (BERNET) für die Wissenschaft und das HMI-Netz erwähnt.Auf den Erfahrungen und Kenntnissen, die im Rahmen dieser Systement-Wicklungen gesammelt worden sind, baut das DFN auf. Es wird vom Bun-desminister für Forschung und Technologie gefördert und von Berlin aktivunterstützt, und das nicht nur beim Aufbau durch Bereitstellung von qualifi-ziertem Personal, sondern auch durch Haushaltsmittel für den späterenBetrieb des DFN.

Das Deutsche Forschungsnetz verwendet die öffentlichen Datenübermitt-lungsdienste, insbesondere das DATEX-P-Netz der Deutschen Bundes-post und ist von daher für den heutigen Bedarf an schneller Datenübertra-gung konzipiert. Eine wesentliche Erweiterung für die Datenkommunika-tion wird das Berliner Kommunikationssystem (BERKOM) bieten, das vonder Deutschen Bundespost und dem Berliner Senat gemeinsam in Koope-ration mit wissenschaftlichen Einrichtungen und wirtschaftlichen Unter-nehmen als Forschungs-und Pilotprojekt mit überregionaler Ausstrahlungin Berlin durchgeführt wird. Beide Vorhaben - DFN und BERKOM - sind fürBerlin sehr wichtig; das eine, weil es der Wissenschaft eine für sie geeigne-te Kommunikationsinfrastruktur anbietet, das andere, weil es künftigeAnwendungsmöglichkeiten von Breitband-ISDN verwirklichen hilft. Beideunterstützen die in Berlin gebildeten Schwerpunkte in den BereichenMikroelektronik, rechnergestütztes Konstruieren, Hochenergie- undPlasmaphysik sowie Robotertechnologie und Paralleles Rechnen.Ich wünsche dieser Ausgabe der DFN-Mitteilungen und dem DeutschenForschungsnetz viel Erfolg.

Prof. Dr. George TurnerWissenschaftssenator

Ein Rechenzentrum als Nutzer

Der DFN-Anschlußdes RegionalenRechenzentrumsErlangen (RRZE)Dr. Peter HolleczekUniversität Erlangen-Nürnberg

Wachsende Panik und die Auszeich-nung aller Unbeteiligten stünde kurzbevor - handelte es sich um ein typi-sches Projekt. Seit Februar 1 986 gibt es,zu allem Überfluß, nachts und an Wo-chenenden Probeläufe - zum Leid-wesen mancher gutwilliger Benutzerund zum Arger vieler schlauer Hacker.Worum geht es? Die Entwicklungsarbei-ten am 1984 begonnenen DFN-Projektdes Regionalen Rechenzentrums Erlan-gen (RRZE) neigen sich dem Ende zu.Die einzelnen Protokollimplementatio-nen sind abgenommen, das Zusam-mensetzen aller entwickelten Pro-grammteile und Netzwerk-Komponen-ten gleicht einem Puzzlespiel.

r ommunikations-möglichkeiten

Ziel des DFN ist die Verbesserung derKommunikations-lnfrastruktur in derdeutschen "Forschungslandschaft", zuder Universitäten, Großforschungsein-richtungen und Forschungseinrichtun-gen der Industrie gehören. FolgendeMöglichkeiten der Kommunikation sol-len geschaffen werden:- Geräteverbund (z. B. Zugriff auf

Größtrechner),- Programmverbund (Zugriff auf

spezielle Software, z. B. zu Entwurfs-und Konstruktionszwecken),

- Datenverbund (zwischen beteiligtenEinrichtungen),

- Nachrichtenverbund (unter denbeteiligten Wissenschaftlern).

Das DFN bedient sich der Technik derDeutschen Bundespost für die Vermitt-lung von Datenpaketen (Datex), örtli-eher lokaler Netze und später auch desISDN-Dienstes. Die genannten Ver-bundarten werden durch folgendeBasis-Dienste ermöglicht:- Dialog,- Filetransfer,- Jobtransfer (RJE) und- Nachrichtenaustausch

Die im DFN-Projekt des RegionalenRechenzentrums Erlangen betroffenenBasisdienste sind Dialog und Filetrans-fer

PRIV.X. 25-NETZ

DFNDATEX-P

Gateway

Rechner CYBER,. .

PC'S

Terminals

Rechner IBM, VAX,

LAN

LN 20 - -Abb. 1:DFN/Datex-P-Zugangsmöglichkeitendes RRZE.

Der -Gateway desErlanger Rechen-Zentrums

Als Einrichtung der Universität Erlan-gen-Nürnberg betreibt das RRZE inNordbayern ein weitverzweigtes Time-sharing- und RJE-Netz mit den zweiZentralrechnern Cyber 855 und IBM4361. Angeschlossen sind die Universi-täten Bamberg und Bayreuth sowie dieFachhochschulen Nürnberg und Co-bürg.

Das RRZE möchte seinen Kunden einenFiletransfer- und Dialogzugang zumDFN anbieten. Das soll über einen Gate-way-Rechner erfolgen, dessen Entwik-klung vom DFN-Verein/BMFT finanziertwird. Bild 1 zeigt die Zugangsmöglich-keiten zum DFN am RRZE.

Durch den Filetransfer-Gateway kön-nen Dateien von Rechnern des DFN indi-rekt auf die CYBER des RRZE und um-gekehrt übertragen werden. Zwischender CYBER und dem Gateway bestehtein privates Ubertragungsverfahren.Netzseitig wickelt der Gateway die vor-geschriebenen DFN-Protokolle ab (sie-he Bild 2). Dieser Weg wurde gewählt, daeine reine Host-Lösung für das Be-triebssystem CDC/NOS nicht mehrunterstützt wird. Erst für CDC/NOS-VEwird eine solche Lösung verfügbar sein.

RDACYBER

priv.T. 70 priv.

X. 25 X.25 X.25

DATEX-P X. 25

Abb. 2: Gateway für Filetransfer

Über den Gateway ist es auch möglich,aus dem lokalen Breitbandnetz und demprivaten X. 25-Netz des Rechenzen-trums heraus zeilenweisen Dialog ent-sprechend der Norm X. 3/X. 28 mitRechnern des DFN zu führen. Umge-kehrt wird aus dem DFN heraus ebensoüber X.29 ein zeilenweiser Dialog mitden am lokalen Netz angeschlossenenRechnern unterstützt. Dazu istderGate-way-Rechner einerseits mit dem Datex-P-Netz, andererseits mit dem lokalenNetz und dem privaten X.25-Netz ver-bunden.

Technisch ist ein Dialogzugriff zwischenden lokalen Netzen und dem Datex-P-Netz (über PADs - Packet-Assembly-Disassembly/HMIP/) schon jetzt mög-lich. Er wird auch bereits vom DFN-Ver-ein unterstützt und intensiv genutzt. Dasbisher eingesetzte Verfahren erlaubt je-doch jedem, unkontrolliert kostenpflich-tige Leistung in Anspruch zu nehmen. Esläßt sich auch nicht verhindern, daßdiese Leistungen von Benutzern außer-halb des RRZE mißbräuchlich genutztwerden.

So stiegen die dem RRZE von der Bun-despost monatlich in Rechnung gestell-ten Datex-P-Kosten von etwa 2000, - DMim Frühjahr 1985 auf einen Rekordwertvon rund 8000,- DM zum Jahresende1985. Bei näherer Untersuchung stelltesich heraus, daß die Dienste des Datex-P-Netzes nicht nur von Mitgliedern derUniversität in Anspruch genommen wur-den, sondern auch von einer Reihe ganzanderer Benutzer. Aus ganzDeutschland kommend wählten sie sichin das inzwischen weitverzweigte Netzdes RRZE ein und fanden einen Weg,sich als "RRZE-Benutzer" wieder in dasDatex-P-Netz zurückzuwählen. Dem

RRZE überließen sie freundlicherweisealte weiteren Kosten, insbesondere fürAuslandsgespräche. Sie zählen zu demneuen Typus der Netzwerk-Hacker, un-ter denen hauptsächlich Universitätenmit größeren privaten Netzen zu leidenhaben, wie Karlsruhe und Erlangen.

Deshalb hat der Gateway die Aufgabe,die Zugangsberechtigung des Benut-zers zum Datex-P-Netz (über Benutzer-nummer und Paßwort) zu prüfen und dieAbrechnung der Gebühren für die in An-Spruch genommenen Netzleistungenvorzunehmen.

Nach der bisherigen Freizügigkeit istdas eine spürbare Beeinträchtigung. Er-freulicherweise hat diese (leider not-wendige) Reglementierung auch positi-ve Nebenwirkungen.

Um nämlich benutzerorientiert abrech-nen zu können, muß eine Benutzerum-gebung geschaffen werden. Hat man sieerst einmal zur Verfügung, so lassensich weitere benutzerorientierte Lei-stungen einführen.

Im Gegensatz zu den bisher erhältlichenund genutzten PADs, die nur eine be-grenzte Zahl von (für alle Benutzer glei-

abgehenderDialog

KontrolleAbrechnung

PAD

X.25

DATEX-P LN20

ankommenderDialog Kontrolle

Abrechnung

X.29

Rechner

X.25

DATEX-P

Abb. 3: Dialoggateway für das lokale Netz LN 20.

LN20

chen) Netzwerkadressen führen kön-nen, ermöglicht der Gateway-Rechnereine "persönliche" Verwaltung vonNetzwerkadressen. Außerdem erlaubter es, Dialogsitzungen (von PAD undX.29) auf Plattenfiles mitzukopierenbzw. Plattenfiles als Eingaben für Dia-logsitzungen zu verwenden. Auf dieseWeise läßt sich ein primitiver Filetransferrealisieren. Jeder Benutzer kann dazuüber einen begrenzten Plattenplatz aufdem Gateway verfügen.

Architektur und Anordnung des Gate-ways zwischen den Netzen zeigen dieBilder 3 und 4.

Das lokale Breitbandnetz LN20 der (Fir-ma Sytek) des RRZE ist ein typischesTerminalnetz. Es wird z. B. auch bei VWin Wolfsburg und an der Eidgenössi-sehen Technischen Hochschule (ETH)Zürich eingesetzt. Über Anschlußein-heiten können asynchron arbeitendeGeräte mit Geschwindigkeiten bis zu19,2 KBits/Sek. angeschlossen werden.Das Breitbandnetz umfaßt zur Zeit rund100 Anschlüsse. Über einen im Gate-wayrechner installierten PAD könnenDialogsitzungen in das Datex-P-Netzweitergereicht werden. In der Gegen-richtung sorgt eine X.29-Komponenteim Gateway für eine Vermittlung.

KontrolleAbrechnung

X. 29

X. 25 X. 25DATEX-P

PAD

X. 25

abgehender

Rechner

X. 29

X. 25

ankommender

Dialog

Abb. 4: Dialoggateway für das X. 25 Netz.

Das private X.25-Netz des RRZE bestehtaus handelsüblichen Komponenten wieUntervermittlungen, PADs und Rechner-eingängen. Es umfaßt zur Zeit ca. 60 An-Schlüsse. Für ankommende wie abge-hende Dialoge sorgt eine X.29-Kompo-nente am Gateway für eine Vermittlung.

Die Implementation

Die Aufgaben des Gateways lassen sichnach dem in Bild 5 gezeigten Schemaanordnen. Die Gesamtaufgabe stellt einSystem von kommunizierenden paralle-len Prozessen dar. Die Grundprinzipiensolcher Aufgaben sind auch im ISO-

Schichtenmodell für offene Kommuni-kationsnetze beschrieben.

Betriebssystem und Programmier-Sprache des Gateway-Rechnersmüssen also die Formulierung parallelerProzesse und der Kommunikation zwi-sehen ihnen erlauben. Die Wahl fiel aufden Siemens-Prozessrechner R30(M70), der mit dem BetriebssystemORG/PV (BS/M) häufig in industriellenEchtzeitanwendungen eingesetzt wird.

Er verfügt über einen X.25-Anschluß,der aus einem HDLC-lnterface und demSINEC/SNVP-Softwarepaket besteht.Seit 1981 kommt er in Rechnernetzen,wie z. B. dem HMINET2 zum Einsatz. AlsProgrammiersprache wurde PEARL(DIN 66253) gewählt, die über alle nöti-gen Spracheigenschaften verfügt, wie

- Multiprozessing- Timing- Bit- und Character-Operationen.

Zur Spezifikation der Programme wirddie graphisch orientierte Technik PASS/Gl 85, eingesetzt.

Die Wahl dieses Gateway-Rechners hatgewisse Rückwirkungen auf die Struk-turierung der Programme: Die vomNetzwerkprogramm SINEC angebote-nen Leistungen entsprechen zwar derCCITT-Norm X.25, nicht jedoch seineSchnittstellen. Deshalb wurden für alleDienste Anpassungsschichten einge-fügt, welche die Schnittstellensignalerichtigstellen. Da SINEC außerdem nurvon einem Benutzerprozeß angespro-chen werden kann, war eine Schichtzum Verteilen der Benutzeraufträge(Dispatcher/HMID/) nötig. Andererseitsgab es für diesen Rechner bereits ferti-ge Lösungen, wie z. B. einen PAD/HMIP/nach den Protokollen X.28/X.3, die mit-verwendet werden konnten.

Bisherige Erfahrungen

Um den Datex-P-Dienst für Dialog-An-Wendungen einem breiteren For-schungspublikum zugänglich zumachen, wurden vom DFN-Verein For-schungseinrichtungen, darunter dasRRZE, durch Bereitstellen von PADsbeziehungsweise X.25-Untervermittlun-gen unterstützt. Beim Erlanger Rechen-Zentrum, das schon Anfang der 80erJahre den Grundstein für ein eigenesX.25-Netz gelegt hatte, fiel diese Initiati-

ve auf fruchtbaren Boden. So beträgtdas täglich in etwa 150 Gesprächenüber den Datex-P-Anschluß ausge-tauschte Datenvolumen (mehr als 3MB). Entsprechend der Struktur einerUniversität gibt es keine typischenSchwerpunkte der Anwendung, son-dem ein breitgefächertes Spektrum.

Die meisten Gespräche werden amRRZE mit folgenden Einrichtungen ge-führt:

- Queen Mary College London (DAP),- Universität Dortmund (Unix-Mail),- Universität Karlsruhe (CYBER 205),- Deutsches Elektronen Synchroton

(DESY) Hamburg,- Leibniz Rechenzentrum (LRZ)

München.

Manche Anwendergruppen sind dabeifast völlig auf externe Kommunikationangewiesen. Zwei Gruppen könnenstellvertretend genannt werden.

Beispiel 1:Lärm im uto

Der Informatik-Lehrstuhl für Rechnerar-chitektur und Verkehrstheorie benutztzusammen mit dem Lehrstuhl fürStrömungsmechanik den FeldrechnerDAP am Queen Mary College in London,zum Beispiel zum Berechnen derTem-peraturverteilung von strömendenFlüssigkeiten und von Eigenschwingun-gen in (Auto-) Innenräumen /DAP84/.Probleme dieser Art lassen sich durchgekoppelte Differentialgleichungen be-schreiben, die für verschiedene, überFlächenschnitte verteilte Gitterpunktezu lösen sind. Bei geeigneter Wahl derGitterpunkte läßt sich erreichen, daßGleichungssysteme mit 64x64 Unbe-kannten berechnet werden müssen -genausoviel, wie der DAP Prozessorenhat. Von einer Lösung dieses Glei-chungssystems für die Eigenschwin-gungen in Pkw-lnnenräumen erwartetman sich Aussagen darüber, an wel-chen Stellen für einen gegebenen Fahr-zeuglängsschnitt die Schwingungsam-plituden und die damit verbundene Ge-räuschbelästigung besonders hochbzw. gering sind. Aufgaben dieser Artlassen sich in einem "normalen" Univer-sitätsrechenzentrum nur sehr zeitauf-wendig, an einem Feldrechner dagegensehr elegant lösen. Der Zugriff zum DAPin London erfolgt über PADs im RRZE-

Local Area Network (LOCALNET)

privaterDateitransfer

Dateitransfer-Verfahren

RDA(remote data

access)

T. ZO-Protokoll

T. 70'

Gebühren-erfassung

Zugangskontrotle

einfacherDateitransfer

PADFunktion

facher c>ial°9 weitereDatei- zum Modute

transfer LAN

ist von PADs im RRZE-Netz möglich.Umgekehrt ist es für die Entwicklungund Pflege der Programme sinnvoll,CERN-Programme auch an RRZE-Re-chenanlagen zur Verfügung zu haben.Der dazu nötige Austausch von Pro-grammen und Daten läßt sich durch denSoftware-PAD auf einer R30 des RRZE,der im Filetransfer-Modus betriebenwird, für nahezu alle CERN-Rechner,auch solche ohne eigenes Filetransfer-Verfahren, einfach bewerkstelligen.

PAD(X.28/X.3)

Kommandointerpreten ErSt©

Gebühren-erfassung

X.29-Anschluß

X. 29'

Gebühren-erfassung

DISPATCHER

SINEC-Paketvermittlung (SNPV)

DATEX-P-Netzzugang

Abb. 5: Architektur des Gateway-Rechners Siemens R 30.

Netz. Die DAP-Benutzung zählt mit ca.1000 Gesprächen im Monat zu denstärksten Anwendungsgruppen.

Das Titelbild zeigt den Längsschnittdurch einen Pkw-lnnenraum mit dendurch Berechnungen am Array-Prozes-sor des Queen Mary College in Londonermittelten Eigenschwingungen. Die Li-nien mit großer Amplitudenangabe (auf100% normiert) zeigen Gebiete mit gro-ßer Druckschwankung, d. h. großerLautstärke.

Beispiel 2:Suche nach denQuark-Eigenschaften

Die Lehrstühle für Experimentalphysikbearbeiten Probleme der Kern- und Teil-chenphysik zunehmend an großen For-schungsstätten, wie z. B. CERN in Genf,DESY, SIN und dem Kernforschungs-

Zentrum Karlsruhe (KfK). Die dort ge-wonnenen Daten werden zum Teil vorOrt, zum Teil an "heimischen" Rechnernausgewertet. Das bedingt einen teil-weise sehr intensiven Austausch vonDaten und Programmen zwischen denForschungsstätten. Finden Experimen-te in Kollaborationen mit anderen For-schergruppen statt, vervielfacht sich dieZahl der Kommunikationspartner.

Im Experiment PS185 am CERN werdenmit dem Antiprotonenstrahl des LEAR-Beschleunigers die Eigenschaften desStrange-Quarks untersucht (CE81). Da-tenaufnahme bzw. -Auswertung erfol-gen in der Regel auf Rechnern am CERN(VAX 750 bzw. CYBER 875, IBM 3081).Die Auswertungen können nach Ab-Schluß des eigentlichen Meßzyklus, Mo-nate dauern. Um zum Anstoß von Rech-nungen und Variieren von Modellpara-metern nicht ständig am CERN präsentsein zu müssen, ist ein Dialogzugriffzu den CERN-Rechnern notwendig. Das

Um mangelnde Resonanz auf die ange-botenen Netzdienste müßte sich amRRZE keiner Gedanken machen, gäbees nicht die Probleme mit der unkontrol-lierten Datex-P-Benutzung. Wie sieht esmit dem Gateway aus?

Die ersten Erfahrungen, die mit demDFN-Gateway des RRZE gewonnenwerden konnten, betreffen hauptsäch-lich die Implementierungstechnik. DieImplementierungsarbeiten verliefennach Plan. Die Ecktermine für Fertig-Stellung und "Abnahme"-Bereitschaftder einzelnen Protokolle konnten einge-halten werden - obwohl ein Programm-code von rund 20. 000 Zeilen entwickeltwerden mußte. Das soll nicht heißen,daß es keine Probleme zu bewältigengab. So machte sich die Schranke von64 K Worten bei der Adressierung oftunangenehm bemerkbar. Lediglich dieModularisierungs-Möglichkeiten vonPEARL erlauben, den im konkreten Fallzur Verfügung stehenden Hauptspei-eher von 1 MB (M 70) effektiv aus-zunutzen.

Trotzdem muß man sich fragen, ob nichtdie verhältnismäßig glatte Implementie-rung durch zu abstrakte Hilfsmittel undeine daraus resultierende mangelndeEffizienz erkauft worden ist. Ein Beispielmag eine Antwort darauf geben. Den Da-tendurchsatz durch mehrere Protokoll-schichten kann man als Maß für Lauf-zeiteffizienz einer Implementation be-trachten. Vergleicht man einerseits denvöllig in Assembler geschriebenen PADund andererseits die in PASS spezifi-zierte und in PEARL programmierteX.29-Schicht im Filetransfer-Modus, soerreichen beide annähernd (bis auf ca.10°/o) den gleichen Datendurchsatz. DieLaufzeiteffizienz ist durchaus vergteich-bar.

8

Zur Integration des deutschen EARN in das DFN

Problemabriß undLösungsvorschlägeDipl. -Math. Klaus Birkenbihl, BonnDipl.-Math. Michael Hebgen, HeidelbergundDr. Bernd Wagner, Oldenburg,Deutsches EARN

Dipl.-lnform. Gerrit Henken,Dipl.-Phys. Klaus Ullmann undDipl.-lng. Martin WilhelmDFN-Verein,Zentrale Projektleitung, Berlin

Die 3. Mitgliederversammlung des DFN-Vereins hat im November 1985 den Vor-stand gebeten, sich mit der Konkreti-sierung der Integration des deutschenEARN in das DFN zu befassen. Sie folgtedamit der Aufforderung der deutschenEARN-Gruppe. Es wurde eine gemein-same Kommission gebildet, die insge-samt fünfmal getagt hat; ferner fand eineBesprechung mit dem Vorstand desDFN-Vereins statt. Der folgende Berichtlegt Rechenschaft über die gemeinsamerarbeitete Strategie ab. Methodischwird dabei folgendermaßen vorgegan-gen: Zunächst wird ein funktionellerVergleich zwischen EARN- und DFN-Diensten vorgenommen. Danach wirdein Kostenvergleich für die Datenüber-tragung durchgeführt. Anschließendwerden die Problematik des X. 400-DFN-EARN-Gateways skizziert und organi-satorische Fragen behandelt. ZumSchluß werden die Folgerungen zusam-mengefaßt.

Funktioneller Vergleichder EARN-undDFN-DiensteVerglichen werden DFN-Dienste Dialog(X. 3, X.28, X.29), File Transfer, Remote

Job Entry (RJE) und Message HandlingSystem (MHS) und die EARN-Dienstegemäß EARN Packet Ref. Manual.

Die Dialog-Funktionalität ist im EARNnicht vorhanden.

äs ist R ?IBM gab den Anstoß zu EARN (Euro-pean Academic and Research Net-work), um eine Infrastruktur für dieKommunikation zwischen Universitä-ten und wissenschaftlichen For-schungseinrichtungen zu schaffen.Bis Ende 1987 werden die Leitungs-kosten für das Netz, das von ausge-wählten Pilotpartnern entwickelt wur-de, von IBM übernommen.

Jedes Land, das an EARN ange-schlössen ist, hat einen zentralenRechner, der zentrale Dienste und dieVerbindung zu entsprechenden Net-zen in anderen europäischen Län-dem und den USA zur Verfügungstellt.

QueUe: IBM 1984, EARN - PocketReference Summary

Betriebserfahrungen mit dem DFN-Gateway müssen erst noch gesammeltwerden. Seit Beginn des Probebetriebsim Februar 1986, der nur Teilkomponen-ten umfaßt, zeigt sich allerdings dieWirksamkeit der Zugangskontrolle. DieHacker, die sich hauptsächlich nachtsund am Wochenende des RRZE-Netzesbedienten, können draußen gehaltenwerden. Das dürfte sie aber in ihremsportlichen Ehrgeiz nur anstacheln. Sohandelt man in Hackerkreisen schonProgramme zum Knacken von (Netz-werk-) Paßwörtern /C 64,. Ein hand-fester Erfolg läßt sich aber feststellen:Die Datex-P-Kosten sind gefallen.Eine endgültige Bewertung des DFN-Gateways läßt sich allerdings erst nacheiniger Betriebszeit vornehmen.

ukunftsaspekteNachdem eine benutzerorientierte Da-tex-P-Zugangskontrolle offenbar eineMarktlücke darstellt, wird dieser Teil derGateway-Software auf einen leistungs-

fähigen Mikrorechner übertragen. EinRechner dieser Art könnte z. B. auch fürkleinere Rechenzentren erschwinglichsein.

Unabhängig davon wird der DFN-An-Schluß des RRZE auch auf die IBM 4361erweitert. Für das Betriebssystem VM/CMS soll der Dienst RJE implementiertwerden. Die Zeitvorstellung für den Ab-Schluß dieser Arbeit ist Ende 1987.

Literatur

/C64/"Hallo Hacker,Mailbox-Freaks und DFU-Freunde",DFÜ-News, C'64er (1/86), S. 12-13,Verlag Markt und Technik, Haar beiMünchen.

/CE81/Peter Barnes et ai. : Study of thresholdproduction of pp -> YY at LEAR Propo-sal to CERN PSCC-Commitee, Genf,1981.

/DAP84/Andreas Polster: Numerische Lösung

von Eigenwertproblemen der Akustikmit Hilfe des Verfahrens der konjugier-ten Gradianten. Diplomarbeit am Institutfür Angewandte Mathematik der Univer-sität Erlangen-Nürnberg, 1984.

/G185/C. Andres, A. Fleischmann, U. Hillmer,P. Holleczek, R. Kummer: Eine Methodezur Beschreibung von Kommunika-tionsprotokollen, Kommunikation inVerteilten Systemen l, Informatik Fach-berichte (95), GI-NTG-Fachtagung1985, Springer Verlag./HMID/Spezifikation und Dokumentation fürdas Dispatcherprogramm für Rechnervom Typ Siemens R30 unter dem Be-triebssystem ORG-PV, Hahn-Meitner-Institut für Kernforschung Berlin GmbH,Bereich Datenverarbeitung und Elektro-nik.

/HMIP/Das Dialogsystem im HMINET2, Hahn-Meitner-lnstitut für Kernforschung Ber-lin GmbH, Bereich Datenverarbeitungund Elektronik.

Ein Vergleich der Funktionalität desDFN-RJE mit Network Job Entry (NJE)ergibt, daß bei der vorgesehenen Imple-mentierung beide Systeme funktionaläquivalent sind.

Der derzeit im EARN eingesetzte File-transfer ermöglicht das Absenden vonFiles, die auf dem Zielsystem im Spool-bereich abgelegt werden. Dadurch istdie Kenntnis einer User-ld und einesUser-Paßwortes nicht erforderlich.

Beim DFN-Filetransfer werden die An-gaben User-ld und User-Paßwort i. A.benötigt. Es ist jedoch möglich, durchdie Einrichtung einer allgemein zugäng-lichen Nutzerkennung die Arbeitsweisedes EARN-Filetransfers nachzubilden.Darüber hinaus besteht beim DFN-File-transfer zusätzlich die Möglichkeit, Filesvon einem System zu einem Nutzer zuholen.

Bei der Realisierung der Benutzer-Schnittstelle des DFN-MHS auf der funk-tionellen Basis der EARN-Komponente(EARN-Mailer) ergibt sich ein funktio-neller Gewinn, da mehr Endgeräte unddamit mehr Benutzer erreicht werdenkönnen. Interaktives Messaging ist imDFN nicht möglich.

Offen bleibt die Frage der Integrationderjenigen IBM-Anlagen mit dem Be-triebssystem MVS, die keinen SNA (Sy-stem Network Architecture) - Zuganghaben. Ferner ist derzeit die Integrationkleinerer VM-Anlagen, die evtl. nichtSNA-fähig sind, noch offen. Die hohenLizenzkosten für die notwendigen IBM-Kommunikationskomponenten sind füreine große Anzahl von IBM-lnstallatio-nen unerschwinglich und gefährden da-durch die Verbreitung der DFN-Produk-te. In beiden Fällen empfiehlt die Kom-mission dem DFN-Verein, mit der IBM inVerhandlung zu treten.

osten vergleich fürdie Datenfernüber-tragung

Ausgangspunkt für die Betrachtungenwar die Fragestellung, ob aus Kosten-gründen von Seiten des DFN-Vereinsdie Betriebsphilosophie überdacht wer-den muß. Methodisch wurde dabeifolgendermaßen vorgegangen:

Auf der Basis der EARN-Statistik vomFebruar 1986 wurden die Kosten für dasüber DEARN transferierte Datenvolu-men, nunmehr vermittelt über DATEX-P,berechnet.(DEARN ist der bei der Gesellschaft fürSchwerionenforschung (GSI) in Darm-Stadt installierte zentrale Knoten desdeutschen EARN).

Es ergeben sich folgende Konsequen-zen:

a) Basis der DFN-Vermittlung ist X.25.Eine Vermittlung allein über DATEX-Pwird nicht empfohlen. Vielmehr müs-sen Verbindungen mit hohem Daten-volumen ggf. über andere Post-Dien-ste realisiert werden.

b) Eine ökonomische Notwendigkeitzum Betrieb eines DFN-eigenen Lei-tungsnetzes läßt sich derzeit aus demKostenvergleich nicht herleiten.

c) Aus den unter a) und b) getroffenenFeststellungen ist abzuleiten, daß fürentsprechend gelagerte Fälle Kom-munikationsbeziehungen zwischenzwei oder mehreren Partnern über ei-nen Hauptanschluß für Direktruf(HfD) abgewickelt werden ("HfD-ln-sein") können. In einigen Fällen kannder Zugang zu derartigen "Inseln"über leitungsvermittelnde Dienste(Z. B. DATEX-L) kostengünstiger seinals der DATEX-P-Zugang.

Für Teilnehmer, die nur über einenDATEX-P-Anschluß verfügen, ist eineevtl. Mitbenutzung von HfD-Streckeninnerhalb der "Inseln" aus Kostengrün-den nicht interessant. Bei der Kommuni-kation zwischen "Inseln" bringt die Be-nutzung von HfD-Strecken innerhalb ei-ner "Insel" ebenfalls keinerlei Vorteile.Diese Verhältnisse sollen an einem Bei-spiel klar gemacht werden:

Wegen der hohen Nutzung der CRAY inBerlin vom Regionalen Rechenzentrumfür Niedersachsen in Hannover (RRZN)sind die X.25-Untervermittlungen beiderEinrichtungen über eine HfD-Leitungmiteinander verbunden. Für einen Be-nutzer mit DATEX-P-Anschluß in Mün-chen, der ebenfalls Daten zur CRAYnach Berlin übertragen möchte, ist dieMitbenutzung der HfD-Verbindung Han-nover-Berlin von den Kosten her uninte-ressant, da DATEX-P entfernungsunab-hängig tarifiert wird. Dagegen könnte esfür einen Anwender in Hildesheim, derdie CRAY ebenfalls nutzen will, bei ent-

sprechendem Datenvolumen durchausinteressant sein, sich über einen HfD-Zugang am RRZN anzuschließen unddann die HfD-Leitung nach Berlin mitzu-benutzen. Der DFN-Verein sollte daraufhinwirken, daß die Betreiber derartigerHfD-lnseln anderen Vereinsmitgliederndie Mitbenutzung (ggf. bei entsprechen-der Kostenbeteiligung) gestatten.

Der DFN-Verein bietet dafür eine Be-ratung an. Voraussetzung dafür ist, daßdie Betreiber derartiger HfD-Streckenden DFN-Verein entsprechend infor-mieren.

DF -EAR -Gateway

Betrachtet man die möglichen Kommu-nikationspfade, so sind drei verschiede-ne Vermittlungsfunktionen des Gate-ways sichtbar-

DeutschesEARN

EARN/ i i EARN/X. 400 ; i npN..,BITNET i 3, !' ̂ Gatewa'y"' ; i L"-"'-Ä'4

Bild 1: Vermittlungsfunktionen desEARN/X.400-Gateways

1. : Die Kommunikation zwischen Teil-nehmern des EARN/BITNET undTeilnehmern des deutschen EARNgehört nicht zur Vermittlungsauf-gäbe des Gateways.

2. : Die Kommunikation zwischen DFN-X. 400 Teilnehmern und Teilnehmerndes deutschen EARN wird (zeitlichbegrenzt) durch den Gateway unter-stützt. Sobald die X.400-Produkte(Hersteller- oder DFN-Produkte) fürdie IBM-Systeme VM und MVS vor-liegen, sollen diese installiert wer-den. Diese Systeme werden dann alsPrivate Management Domains(PRMDs) (DFN-X. 400) in den DFN-Message-Verbund integriert, so daßdie unter 2. dargestellte Verbindungnicht mehr benötigt wird. Dieses Zielsoll bis Ende 1987 erreicht werden.

3. : Die Kommunikation zwischen inter-nationalen EARN/BITNET-Teilneh-mern und DFN-Teilnehmern soll län-ger (über 1987 hinaus) durch denGateway unterstützt werden. Jedoch

10

ist durch die geplante Umstellungder internationalen EARN-bzw.BITNET Leitungen auf öffentliche Da-tennetze (X.25) und die geplante Ein-führung der X.400-Gateways der na-tionalen EARNs auch diese Verbin-düng langfristig vermutlich nicht er-forderlich.

Abrechnung undRechnungserstellung

Die Benutzung der Gateways wirddomain-spezifisch abgerechnet; d. h.jede Domain im DFN, die den Gatewaynutzen will, muß dort eingetragen undzugelassen werden. Damit erklärt sichder DFN-Domain-Betreiber bereit, dieKosten für die vom EARN/BITNETempfangene und an die DFN-Domainweitergesendete Nachricht zu überneh-men. Hierbei handelt es sich im Normal-fall um die beim Gateway entstandenenDATEX-P-Kosten. Der Gateway-Betrei-ber erstellt für jede angeschlosseneDFN-Domain eine Rechnung nach demPrinzip der elektronischen Briefmarke.Die Gebühr ergibt sich aus den DATEX-P-Kosten und kann abhängig von derLänge der Nachricht, dem Versandzeit-punkt und den angeforderten Dienstlei-stungen (Empfangsbestätigung etc.)variieren. Jede angeschlossene DFN-Domain mußeine Grundgebühr zurNut-zung des Gateways zahlen, mit derstän-dig anfallende Kosten (Rechenzeit,Speicher, Wartung der Software) abge-deckt werden sollen.

Bis Ende 1987 entstehen bei der Kom-munikation vom DFN zum EARN/BITNETbeim Gateway keine Kommunikations-kosten, da bis zu diesem Zeitpunkt dieFinanzierung der Leitungen durch IBMübernommen wird. Da keine Anschluß-finanzierung der Leitung zum EARN/BITNET durch IBM erfolgt, muß auch fürdie Senderichtung zum EARN eineAbrechnung beim Gateway erfolgen.

Inbetriebnahme

Der DFN-Verein beabsichtigt, den Gate-way Mitte 1986 in Betrieb zu nehmenund diesen Betrieb bis Ende 1987 unterden oben genannten Bedingungendurchzuführen. Für den genannten Zeit-räum werden keine Grundgebühren fürdie Benutzung des Gateways von denDFN-Domains erhoben. Die beim Gate-way entstehenden Kommunikations-kosten werden vom DFN-Verein bezu-schußt, so daß monatlich etwa 10 MB

(für die DFN-Domains kostenfrei) vomGateway an die DFN-Domains gesendetwerden können.

Dieser Pilotbetrieb soll dazu dienen, Er-fahrungen im Betrieb des Gateways zusammeln und vor allem das Abrech-nungskonzept zu erproben. Es sollenfiktive Rechnungen erstellt werden, da-mit die beteiligten Domains einen Ein-blick über die verursachten Gateway-Kosten erhalten. Durch eine Subkom-ponente muß die wechselseitige Er-reichbarkeit der deutschen X.400-Teil-nehmer mit den RFC 822/BSMTP-Mai-lern und Gateways sichergestellt sein(RFC=RequestforComment;BSMTP=Basic Simple Mail Transfer Protocol).

OrganisatorischeFragen

Entscheidend für alle organisatorischenFragen ist der Beschluß des EARN-Board of Directors (BOD) vom Septem-ber 1984, sich künftig auf X.400 und an-dere Standards abzustützen. Dies be-deutet mittelfristig (ca. 2 Jahre gerech-net ab 1987) für die Softwarekompo-nenten in den Endsystemen, daß sieüber die üblichen DFN-lnfrastrukturen(z. B. Referenzmaschine) bzw. Betriebs-konventionen betrieben werden sollten.Darüber hinausgehende Vereinbarun-gen sind nicht notwendig. Nötig ist dieErarbeitung eines Einführungsplanes,der die zeitliche Einbindung jedesEARN-Hosts in den X.400-DFN-Dienstfestlegt. Ein weiterer Übergang ist durchden Betrieb des Gateways sicherge-stellt. Naturgemäß kann dieser Plan erstmit Festlegung des Verfügbarkeitsda-tumsfürdieX. 400-DFN-DiensteinMVS-und VM-Umgebungen definiert werden.

Für den Betrieb der Gateways ist dieSituation anders: Hier betreibt der DFN-Verein zunächst einen EARN-Host, derden EARN-Betriebskonventionen ge-horchen muß. Der Betrieb dieses Gate-ways soll die Erreichbarkeit der euro-päischen und im wesentlichen derame-rikanischenEARN/BITNET-HostsfürdieDFN-Klientel sicherstellen. Derzeit läuftbereits ein Feldversuch zwischen ca. 10europäischen EARN-Hosts, der die in-ternationalen Verbindungen auf eineX-400-Basis stellen soll. Somit ergibtsich mittelfristig, daß der Gateway auf

europäischer Ebene betrieben undauch finanziert werden sollte. Darausfolgt, daß kurzfristig ein technischerKontakt zwischen dem DFN-Verein unddem EARN-BOD für die Lösung der be-trieblichen Fragen notwendig ist. Essollte ferner angestrebt werden, daß mitEinführung der internationalen X.400-Verbindungen der Gateway von ande-ren Ländern mitbenutzt wird.

Die meisten deutschen EARN-Teilneh-mer sind DFN-Mitglieder und umgekehrtund sind daher an der Harmonisierungbzw. Integration von EARN-Deutschlandmit DFN in technischer wie organisatori-scher Sicht stark interessiert; die Kom-mission unterstützt dieses Anliegen.Insbesondere soll die Migration des vor-handenen EARN zu standardisiertenDiensten vom DFN-Verein unterstütztwerden. Folgende Punkte müssen hier-zu noch diskutiert werden:

OVertretungen des deutschen EARN ininternationalen Gremien z. B. EARN-Board of Directors

Ofinanzielle und betriebliche Sicherungdes deutschen EARN im DFN- nationale Leitungen- DEARN-Service- internationale Leitungen- Verwaltung/Betrieb/EARN-Europa

erschlage

a) Implementierungen:Es werden Implementierungen, diedie Kommunikation der EARN-Kom-ponenten (CROSSNET/VM undUCLA-Mail/MVS) überX.400 möglichmachen, vorgeschlagen (UCLA =Univ. of California, Los Angeles)

b) Ergänzungen vorhandener Imple-mentierungen:Der vorhandene EARN-DFN-Gate-way soll EARN-seitig eine Kommuni-kation mit RFC822/BSMTP-Mailernmöglich machen.

c) Vermittlungsdienste:Eine Vermittlung ausschließlich überDATEX-P wird nicht empfohlen. Be-sonders für volumenintensive Kom-munikation sollte der Zugang zukostengünstigen DATEX-Diensten(z. B. HfD) auswählbar sein. Die prin-zipielle Erreichbarkeit über DATEX-Psollte gewährleistet sein.

11

DFN-Dienste

AngeschlosseneInstitutionen(Rechenanlagen/Betriebssysteme)

Liste der Abkürzungen

AEG

BAM

DBI

FhGFhs

FIZ Chemie

FIZ Energie

FUBGMD

GWD

AllgemeineElektriztätsgesellschaftBundesanstalt fürMaterialprüfungDeutschesBibliotheksinstitutFraunhofer Gesellschaft

Fachhochschule

FachinformationszentrumChemie

FachinformationszentrumEnergieFreie Universität BerlinGesellschaft für Mathematikund DatenverarbeitungGesellschaft f. wissen-schafl. Datenverarbeitung

HHI

HMIIDSLRZMPIRWTH

TUBTUM

vws

ZIB

Heinrich-Hertz-lnstitut

Hahn-Meitner-lnstitut

Institut für Deutsche SpracheLeibniz-Rechenzentrum

Max-Planck-lnstitut

Rheinisch-WestfälischeTechn. Hochschule

Technische Univ. Berlin

Technische UniversitätMünchen

Versuchsanstalt fürWasserbau und Schiffbau

Konrad Zuse-ZentrumFür Informationstechnik Berlin

BS 2000 {U}VAX (tl)

Der DFN-DienstDialog

HamburgUniv. : 2 VAX (U)

HannoverUniv. : CD NOS/BE

BS 2000MünsterUniv. ; IBM VM (tl)

(tl)

DuisburgFhS: VAXUniv. : BurroughsDüsseldorfUniv. : ND 100 (tl)

BS 2000 (tt)TR 445 (H)

AachenRWTH:BS2000 (tl)

LSI11 (U)VAX (U)

BonnUniv. : 2VAX (tl)

IBM MVS (tf)St. AugustinSMD: VAX (U)

BS 2000 (tl)IBM MVS (tl)

BielefeldUniv. ; ND 100

TR 440

Paderborn'*) Uni». : VAX (tl)")Dortmund

Univ. : BS 2000 (U)2 VAX (tl)

WuppertalUniv. : CD NOS (t))

VAX (tl)HagenUniv. : BS 2000 («)

IBM MVS (tt)SiegenUni». : 3VAX (tt)

GöttingenGWD: SPERRY

(tl)N

BraunschweigUnlv. : VAX (tl)

) ClausthalTU: VAX (tl)

FrankfurtUni». : BS2000(t))

SaarbrückenUni». : BS 2000 (tl)

VAX (U)

Bate!le:VAXDarmstadtGMD: BS 2000

PCS MUNIXTH: BS 2000

4VAXIBM MVSKauerslautern '°;"^"°.

Un,.. : VAX (H) ""|"""^n"" ""HeidelbergMPI: DEC 10 (I)

2 VAX (IQIBM MVS (U)Univ.

KarlsruheFhG: VAXFIZ, Energie:

BS 2000NETONE2 VAX

BayreuthUni«. : VAX (tl)

BambergUniv. : BS 2000 (tl)

ErlangenUni». : CD NOS (tt)

IBM VM (tl)BS 2000 (U)R300RG (tl)

RegensburgUni». : VAX (U)

Univ

(tl)

(tl)(tt)(tl)

MSP (D 205) (I)

AugsburgUniv. : BS 2000 (U)

£rn*lb"BgS 2000 (l) UnlwPDM1, RSX(;)) ^. VAX__ (U)

VAXSPERRY

3VAX (tl)CD NOS/BE (l)IBM VM (l)

UlmAEG:Fhs: MICROVAX (U)

FurtwangenFhs: VAX (tl)

MünchenFhG: VAXLRZ: CDNOSMPI: VAXTUM: VAX/ULTRIX

VAX

Zeichen:(ti) = aktiver Dialog +

passiver Dialog(t) = nur aktiver Dialog(Q = nur passiver Dialog

12

Der DFN-DienstDatei-Transfer

ibur2 VA)

Duisbura DortmundFhG"~WX Univ. : BS 2000 (1)

WuppertalUniv. : VAX

DüsseldorfUniv. : 832000(1)

-y000 dl

^

^

r

AachenRWTH: LSI 11

VAX

SaarbrückenUniv. : BS 2000(1)

KaiserslautoUni v, : VAX

i StadtBS 2000 (1)4VAX

Zeichen:

(1) = 1. Protokollgeneration

KarlsruheFhG. : VAX(1)Univ. : 2 VAX

FreiburgUniv. : VAX

SPERRY (1)

StuttgartUniv. : FDP 11 RSX

3 VAX(1)

UmAEG: VAXFhs: MICROVAX

AugsburtUniv. : BS 2000(1)

EchinsEUROSIL: VAX

MünchenFhG: VAXTUM: VAX

Der DFN-DienstRemote^Job Entry

KW ~ ~~</ /Univ. : BS 2000(1)

VAX (1)

f-

Zeichen:(1) = 1. Protokollgeneration

^

BlelefeldUniv, : ND 100(1)

TR 440 (1)

vGWD: SPERRY (1)

Unsvs:NSlOO (1) Univ:CDNOS(CD205K1)BS 2000 11)TH, 45'il) ^."^"""

KölnUniv. : CD NOS/BE (1)

CDSCOPE (1)

AachenRWTH: BS 2000 Frankfurt

CDNOS/BE(1) Univ. : BS2000

DarmstadtTH: BS 2000 (1)GMD: BS 2000

IDS: BS 2000

S'S.TP'SP IIRSXICRAVIVAX(I)

/FreiburgUniv. - SPERRY (1)

BS 2000

13

Start des Messagedienstes

Installationen desEAN-Systems

Dr. Peter KaufmannDFN-Verein,Zentrale Projektleitung, Berlin

Im Pilotbetrieb des DFN haben die In-stallationen des Mailsystems EAN be-gönnen. Ein Mailsystem (Message-Handling-System) ermöglicht seinenBenutzern eine schnelle und sichereKommunikation mit elektronischenBriefen. EAN ist ein Produkt der Univer-sity of British Columbia und entsprichtweitgehend den Empfehlungen CCITT-X. 400 ff. Die Installationen erfolgen aufVAX-Rechnern mit den Betriebssy-Sternen VMS und UNIX-bsd sowie aufPCS-Computern mit MUNIX (UNIXV).

Bisher wurden über 20 Aufträge zur In-stallation des EAN-Systems an die dreiReferenzanlagen im Hahn-Meitner-ln-stitut für Kernforschung Berlin (HMI)und bei der Gesellschaft für Mathematikund Datenverarbeitung (GMD) in Bir-linghoven sowie in Darmstadt erteilt. Vorallem im UNIX-bsd-Bereich gibt es we-gen fehlender X.25 Anschlüsse aller-dings einige Verzögerungen, so daßvor-erst auch der eigentlich auf Dauer nichtgewünschte PAD-Anschluß genutztwerden wird.

Im nebenstehenden Kasten sind die inAuftrag gegebenen Installationen auf-geführt (Stand Ende Juni; mit (B) ge-kennzeichnete Anlagen sind in Betrieb).

ege ins Ausland

Den Teilnehmern bieten sich mit EANneben der Kommunikation mit bundes-deutschen Partnern auch bereits vieleVerbindungsmöglichkeiten ins Ausland.

1 Innerhalb des (homogenen) EAN-Net-zes gibt es Verbindungen in folgendeLänder:

Australien, Großbritannien, Irland, Ita-lien, Kanada, Niederlande, Norwegen,Schweden, Schweiz, Spanien.

Insbesondere CERN ist auch Teil desEAN-Verbundes.

Hinter dem EAN-Host im UC Londonverbirgt sich für den hiesigen EAN-Be-nutzer völlig transparent das gesamte

britische Forschungsnetz JANET mit ei-nigen hundert Mail-lnstallationen. AlleTeilnehmer von JANET können mit EANproblemlos erreicht werden. Ähnlichestrifft für den australischen EAN-Host zu,über den man in das australische For-schungsnetz gelangt.

2. Weitere Möglichkeiten werden durchdas bereits arbeitende EAN-UUCP-Ga-teway in der GMD eröffnet. Durch diesesGateway kann man von EAN aus andereUUCP-Teilnehmer im weltweiten UUCP-netz erreichen, wobei dafür die Universi-tat Dortmund (FB Informatik) alszentra-ler bundesdeutscher UUCP-KnotenUnterstützung leistet. Allerdings hatdieses Gateway noch experimentellenCharakter und es kann hin und wiederzu Problemen kommen. Auch dürfenhier keine Mega-Bit-Nachrichtendurchgeschleust werden.

Ein Gateway von EAN zu EARN und indas amerikanische Netz BITNET wirdvoraussichtlich noch vor Beginn derSommerpause in der GMD Darmstadtzur Verfügung stehen.

Der dritte im Rahmen des DFN geplanteGateway von EAN zum US-Netz CSNETwird ebenfalls bald zur Verfügungstehen. Die Lizenzverträge mit CSNETsind unterzeichnet und es muß "nur"noch die Installation der fertigen Soft-wäre erfolgen.

Institution/Stadt

G M D Bonn

GMD Darmstadt

HMI BerlinTU BerlinBessy BerlinGBF BraunschweigUni BrenwnUni BochumUni BonnUni Dortmund

Uni DüsseldorfUni Frankfurt

MPI QarchingUni HamburgGBR Hannovar

Fsrnuni HagwiUni KaiserslauternUni KarlsruheKFK KarlsruheFHG KarlsruheTU MönchenUni Saarbrücken

Uni Stuttgart

Uni Wuppertal

Knoten na me (z. T. voraussichtlich)

(B) xps. gmd. tffn(B) zi.gmd.cHn(B) darmstadt.gmd.dfn(B) pcs1. darmstadt. gmd. dfn(B) vax.hmi.dfn(B) nmr. stranski. tu-berlin. dfn

(B) exp bessy. dfnve n us. gbf-b rau nschwefg .dfnvax. Informatik, u n i-bram e n. dfn

(B) analyt.chemle.um-bochum.dfn(B) plbv. physik. uni-bonn. dfn

subdomain. informatik. uni-dortmund dfn(B) ad .chemie.unl-duesseldorf.cHn(B) nmr. chemie. uni-frankfurt. dfn(B) venus. mpe-garching.dfn(B) rz. informatik. unt-hamburg. dtn(B) gatel.gbf/nlfb.dfn

szg rf. bgr/n Ifb dfnvax1lnformatik. femuni-hagen. dfnukli rb. i nform atik. u n i -kaiserslt. dfnsubd&main. informattk. uni-karlsruhe. dfnvax.idt.Mk.d1n

iv. litb. fhg.dfninfovax informatik. tu-muenchen. dfnsbsvax. informatik. uni-saarland. dfn

comvax.rus uni-stuttgart.dfnsubdomain. informatik. uni-stuttgart. dfnvax1 physik.uni-wuppwtal.dfn

14

Standards - Functional Standards - Profiles

turen sehr wesentlichen Harmonisie-rungsarbeiten zu Überblicken.

Dr. Klaus TruölDFN-Verein,Zentrale Projektleitung,Darmstadt/Berlin

OSI nur mit inter-nationalen Standards?

Standards oder Normen für die Telekom-munikation - und nur von solchen han-delt dieser Beitrag - werden von den zu-ständigen Gremien der ISO (Internatio-nal Standards Organization) in Zusam-menarbeit mit den nationalen Nor-mungsgremien wie DIN (Deutsches Insti-tut für Normung), AFNOR (AssociationFranpaise de Normalisation), BSI (BritishStandards Institution) usw. erarbeitetund verabschiedet. Der CCITTgibtfür diedurch Telematik-Dienste berührten Be-reiche Empfehlungen (Recommenda-tions) heraus, die natürlich auch de factonormativen Charakter haben. Mit einerunendlichen und sehranerkennenswer-ten Fleißarbeit legen diese genanntenGremien die Grundregeln für eine vomAnwender dringend geforderte weltweiteoffene Kommunikation fest; OSI (OpenSystems Interconnection) ist dasSchlagwort, dem sich Normer, Herstellerund Anwender verschrieben haben.

"International Standards" und "Recom-mendations" dieser Art liegen inzwi-sehen zahlreich vor, manche sind kurzvor der Verabschiedung, einige sindnoch in recht vorläufigem Arbeitszu-stand. Der Anwender kann sich also zu-frieden zurücklehnen; der Implementie-rer wird flugs diese Standards inbenutzerfreundtiche Programmpaketeüberführen? OSI, herstellerübergrei-fend, weltweit und offen, ist damit Realitätgeworden? - Dies ist leider nicht der Fall.

Es beginnt eine emsige Arbeit, auf diesich Hersteller und Implementierer, An-wender und Nutzervereinigungen stür-zen, um OSI wirklich praktikabel zu ma-chen, um die Kommunikationsfähigkeitheterogener Systeme sicherzustellen.Die internationalen Standards undEmpfehlungen sind in ihrer Funktionali-tat - sicher vernünftigerweise - sehr um-fangreich; sie decken alle vorhersehba-ren Anwenderwünsche ab; sie enthaltenviele Optionen und unterschiedlicheWahlmöglichkeiten. Implementierungenfür spezielle Anwendungsbereiche wer-den sich im allgemeinen daher auf be-stimmte Teilmengen eines Standardsbeschränken (etwa nur die Klasse 0 desTransportprotokolls der Schicht 4 odernur die einfache Möglichkeit der Über-tragung ganzer Files bei FTAM - FileTransfer Access and Management); siewerden für Parameterwerte und Para-meterlangen, für Puffergrößen Ein-schränkungen machen. Es werden so-mit Anwender mit unterschiedlichenSoftwarepaketen nur dann miteinanderkommunizieren können, wenn beidendie gleiche Teilsicht der relevantenStandards zugrunde liegt.

Genau hier ist die Arbeit an FunctionalStandards, Profiles, ImplementationAgreements, Implementation Guides,etc. anzusiedeln, die bei zahlreichenGruppierungen, Organisationen undProjekten mit teilweise komplex ver-maschten Kooperationsbeziehungendurchgeführt werden. Es ist das Anlie-gen des vorliegenden Berichtes, demLeser zu helfen, diese vielfältigen undfür die künftigen Kommunikationsstruk-

Organisationen undProjekte

Es wird ein kurzer Überblick über Orga-nisationen und Projekte gegeben, die"Functional Standards" oder "Profiles"erarbeiten, bzw. in deren Vorbereich tä-tig sind.CENComite Europeen de NormalisationErarbeitet zusammen mit CENELEC eu-ropäische Vornormen (ENV) bzw. Nor-men (EN), die als Functional Standardsbeschrieben werden. Grundlage sind i.a. ISO-Standards. CEN wird getragenvon den europäischen nationalen Nor-mungsgremien. Diese Functional Stan-dards, an deren Erarbeitung auch dieHersteller stark beteiligt sind, sind ver-stärkt die Grundlage für Implementie-rungen im europäischen Raum.Ein Functional Standard enthält eineEmpfehlung, wann und wie gewisseinternationale IT-Standards benutztwerden sollen, um eine bestimmte Funk-tion zu erfüllen. Also: "Um die Funktion Xzu liefern, verwende die Standards A, B,C, ... in der folgenden Art und Weise".Damit wird die Kommunikationsfähig-keit verschiedener Implementierungensichergestellt.

CENELECComite Europeen de NormalsationElectriqueAnalogie zu GEN, getragen von den na-tionalen Gremien aus dem Bereich derElektrotechnik. CEN und CENELEC ar-beiten im Bereich der Informationstech-notogie (IT) zusammen.CEFTKonferenz der Europäischen Post-undFernmeldeverwaltungenErläßt Functional Standards, soweit siein die Hoheit der PTTs fallen. DieseFunctional Standards haben die Re-commendations des CCITT als Grund-läge.

CEN CENELEC CEPT

ITSTC

ITAEGS

IT-Standardisierung in Europa

15

ITSTCInformation TechnologySteeringCommittee

Gemeinsames Gremium von CEN,CENELEC und CEPT, das der Koordinie-rung von Aktivitäten dieser drei Organi-sationen bei der Erarbeitung von ITFunctional Standards dient.

ITAEGSInformation Technology ad hoc ExpertGroup on StandardsExpertengruppe von ITSTC, welche Vor-bereitung und Planung für FunctionalStandards durchführt. Von ITAEGS gibtes 3 in diesem Zusammenhang relevan-te Dokumente:

M-IT-01: Memorandum on theConceptand Structure of FunctionalStandards for IT

M-IT-02: Memorandum on Directory ofFunctional Standards

M-IT-04: Memorandum on Programmefor Development ofFunctionalStandards for IT

Diese beschreiben allgemeine Prinzi-pien für Functional Standards, geben ei-ne Übersicht über alle Functional Stan-dards und ihren augenblicklichen Sta-tus. Das Dokument M-IT-04 beschreibt

die Zeitplanung für die Veröffentlichungder Standards sowie die jeweils verant-wörtliche Organisation (CEN/CENELECoder CEPT).

SPAGStandards Promotion and ApplicationGroupEine Organisation 12 europäischer Her-steiler (ohne IBM, DEC), die gemein-same "Profiles" für die wichtigstenFunktionen und Anwendungen der ITerarbeitet. Ein Profil entspricht einemFunctional Standard. Es beschreibt dieNormen und die evtl. in ihnen getroffe-nen Auswahlen, die für eine bestimmteFunktion oder Anwendung zwischenzwei kommunizierenden Endsystemenvereinbart werden.

Diese Profile werden im "Guide to theUse of Standards" (GUS) veröffentlicht.Die nächste GUS-Version (Revision 3)ist für Oktober 1986 zu erwarten.

Die Arbeit von SPAG ist i. w. im Vorfeldder europäischen Standardisierung an-zusiedeln. Diese SPAG-Profile beein-flussen sehr stark die Arbeiten bei CEN/CENELEC/CEPT und umgekehrt wer-den die Profile i. a. anschließend an dieFunctional Standards angeglichen.SPAG beobachtet auch sehr intensiv

Europäische (Vor-) Normen

uneti Stand

on

ISO-InternationalStandards

CCITT-Recommendations

Profilen

lemer

Harmonisierungen von OSI-Standards

A üements

bzw. kooperiert teilweise mit den Arbei-ten bei CEN/CENELEC/CEPT, CNMA,MAP, TOP, COS und NBS.

Das DFN ist seit mehreren Jahren Gast-Mitglied beim Technischen Komitteevon SPAG. DFN-Studien und Ent-Wicklungen (z. B. für MHS) haben teil-

weise wesentliche Beiträge zur Arbeitvon SPAG gebracht. Zur Zeit hat dasDFN verantwortlich die Koordinierungder Entwicklung der FTAM-Profile über-nommen.

Im folgenden werden noch einige Her-steller/Anwender-Projekte und Grup-pierungen aufgeführt, die zwar keineStandards verabschieden, die aber auf-grund ihres Mitgliederpotentials einegewisse "Macht" darstellen und so defacto einen normativen Einfluß haben.

CNMACommunications Network forManufacturing ApplicationEin ESPRIT-Projekt im Rahmen desComputer Integrated Manufacturing(CIM). Beteiligt sind Hersteller wie BULL,Nixdorf, Olivetti, Siemens und Anwenderwie BMW, Aeritalia und Peugeot.Es werden "Implementation Guides" fürden Bereich der Produktionsautomati-sierung erarbeitet; dazu gehören z. B.lokale Inhouse-Netze, Kommunikationzwischen einzelnen Konzernteilen,Automatisierung der Kommunikationmit Zulieferfirmen. Im Anwendungsbe-reich sind FTAM, Netzmanagement,Directory Dienste, Conformance Testsund Automationsprotokolle die bearbei-teten Themen.

MAPManufacturing Automation ProtocolEine Initiative - angestoßen von Ge-neral Motors in den USA - von Herstel-lern und Anwendern zur Definition einergemeinsamen Kommunikationsarchi-tektur für heterogene Automationsum-gebungen. Die MAP- und TOP-Architek-turen wurden zum ersten Mal auf derAUTOFACT 85 demonstriert. Schwer-punkte der Entwicklungen sind IEEE802.4 (10 Mbit/s, Token) und IEEE 802.3(10 Mbit/s, CSMA/CD) mit Connection-less Network Service, Transport Class 4und den Anwendungsbereichen FTAM,Netzmanagement, Directory Dienste,Conformance Test. (IEEE = Institute ofElectrical and Electronics Engineers).Mit der "European MAP User Group"EMUG hat die MAP-Bewegung in-zwischen auch Europa erfaßt.

16

TOPTechnical and Office Protocols

Dies ist eine von Boeing vorangetriebe-ne Parallelbewegung zu MAP, die sichinsbesondere mit dem technisch-wis-senschaftlichen Bereichen und dem

Büro befaßt. MAP und TOPsind sehr enggekoppelt, besitzen u. a. auch ein ge-meinsames Steering Committee.

Arbeitsbereiche sind Document Archi-tecture (SGML [Structured GeneralizedMarkup Language] kurzfristig, ODA/ODIF [Office Document Architecture/Office Document Interchange Format]langfristig), MHS (Message HandlingSystems) Directory, Electronic Docu-ment Interchange, Graphics, Produkt-definierende Daten, VT (Virtual Termi-nal), FTAM.cosCorporation for Open SystemsEine in etwa mit SPAG vergleichbareGruppierung von Herstellern (IBM ein-geschlossen) und allerdings auch An-wendern, mit z. Zt. 42 Mitgliedern, davon10 Anwender. Ziel ist die Vereinheit-lichung und die Unterstützung der Im-plementierung von OSI-Standards.COS hat Sub-Committees zu Architek-tur, Testen, FTAM, MHS, Data Base,NBS/MAP/TOP-Kopplung. COS erar-beitet allerdings selbst keine Profileoder Functional Standards sondernübernimmt die vom NBS-Workshop er-stellten.

NBSNational Bureau of Standards der USADas NBS veranstaltet im Abstand von2-3 Monaten Workshops, auf denen die"Implementation Agreements AmonglmplementorsofOSIProtocols"erarbei-tet und fortgeschrieben werden. DieseAgreements entsprechen FunctionalStandards und zwar für die Bereiche Lo-wer LayerArchitecture (u. a. LANs, Con-nectionless Network Service, Connec-tion Oriented Network Service), Trans-port (Classes 4, 0), FTAM, MHS, Perfor-mance, Security.Diese Agreements werden laufend mitMAP und TOP abgestimmt und werdenaußerdem von COS übernommen.Die Workshops werden recht informelldurchgeführt. Es gibt keine feste Mit-gliedschaft. Jede teilnehmende Institu-tion kann mitdiskutieren und ab-stimmen.Zusammenfassend sei hier noch einmaldarauf hingewiesen, daß zwischen denArbeiten bei CEN/CENELEC/CEPT,SPAG, CNMÄ, MAP, TOP, COS und NBS

eine sehr enge Kopplung und Koopera-tion stattfindet. Diese geht insbesonde-re bei den US-Gruppen bis zur Identitätder Ergebnisse, jedenfalls aber wird sie- hoffentlich - weltweit zur Kompatibili-tat der Produkte führen.

Functional Standardsund Profile

Es würde an dieser Stelle zu weit führen,alle existierenden Functional Standards(CEN/CENELEC/CEPT) und Profile(SPAG) aufzuzählen und zu beschrei-ben. Es soll daher nur eine grobe Struk-turierung beschrieben werden, die so-wohl für CEN/CENELEC/CEPT als auchfür SPAG gilt. Für genauere Einzelheitenwird auf die Originaldokumente verwie-sen.

Die Funktionsbereiche für die Telekom-munikation werden unterschieden in

- Telekommunikationsfunktionen (T-Profile). Hierzu gehören z. B. der Zu-gang zum Telefonnetz, dem paketver-mittelnden Netz, dem leitungsvermit-telnden Netz, zu lokalen Netzen(CSMA/CD, Token Bus); PABX (Priva-te Automatic Branche Echange).

- Relais-Funktionen (R-Profile). Diessind Relais- und Gateway-Funktionenzwischen verschiedenen Netztypen.

- Anwendungsfunktionen (A-Profile),wie FTAM, MHS, Teletex, Manage-ment.

- Erweiterte Anwendungsfunktionen(Q-Profile), wie Document Inter-change Formats, Content Types, Ad-dressing.

- Spezifikationen fürZeichen-Repertoi-res (S-Profile).

Alle diese vielfältigen Functional Stan-dards bzw. Profile haben unterschied-lichen Bearbeitungsstatus bei SPAGund CEN/CENELEC/CEPT, z. T. als"Drafts", als stabile Profile oder garschon als verabschiedete europäischeVornormen. Zu letzteren gehören z. B.- ENV 41201: MHS PRMD - PRMD- ENV für MHS PRMD - ADMD

wird die endgültige Ver-abschiedung bei CEPTfür September 1986 er-wartet

- ENV 41101: CSMA/CD LAN (NullInternet)

-ENV41102:CSMA/CD LAN (CLInternet)

Bezug zum DF

Die standardisierenden, harmonisie-renden und multivendororientierten Ak-tivitäten sind zur Zeit europaweit undweltweit ausgesprochen zahlreich undzum Teil komplex vermascht. Das be-deutet aber positiv ausgedrückt, daß dieOSI-ldee der weltweiten offenen Kom-munikation allgemein bei Herstellernund Anwendern akzeptiert wurde undihre Realisierung in allen Bereichenstark vorangetrieben wird. Die engeKopplung aller dieser Aktivitäten gibtHoffnung für wirklich OSI-orientierteKommunikationsmöglichkeiten in derZukunft.

DFN ist damit in Europa (CEN, SPAG,RARE) eingebettet in entsprechendeAktivitäten. Der Einsatz von stabilenHerstellerprodukten, der schon immererklärtes Ziel des DFN war, wird künftigfür die 2. DFN-Protokollgeneration sehrrealistisch sein. Dies wird insbesonderefür die Bereiche MHS, FTAM und wohlauch LAN gelten.

Eigene Profil-Definitionen im DFN - diez. B. im MHS-Bereich noch sehr sinnvollund auch führend waren - sowie eigeneImplementierungen werden künftig nurnoch in geringem Umfang nötig sein.Das DFN wird als Repräsentant einergroßen Nutzerschaft über RARE, SPAGund ähnliche Organisationen weiterhinAnwenderwünsche in die Arbeit anFunctionat Standards tragen und somitzu deren Gestaltung beitragen.

Pilotimplementierungen z. B. für FTAMauf UNIX oder im Bereich "VerteilerDirectories", werden auch weiterhin fürdas DFN wesentlich sein, wenn in be-stimmten Bereichen Herstellerproduktekurz oder mittelfristig nicht zu erwartensind. Ähnliches gilt auch für Bereichemit sehr starkem Anwenderbedarf, z. B.Graphik, in denen aus DFN-Projektenheraus auch noch Beiträge zur interna-tionalen Normung geleistet werden kön-nen.

Mit dem Zurücktreten des Arbeitsauf-wandes für Spezifizieren und Imple-montieren gewinnen die Probleme derBetreuung von Nutzern, der Organisa-tion und des Betriebes der Kommunika-tionsdienste im DFN-Bereich und im eu-ropäischen RARE-Umfeld an Gewichtund verlangen erhöhte Aufmerksamkeitdurch die Leitung des DFN-Vereins.

17

Datenkommunikation in Europa

Am 13. Juni 1986 wurde die europäischeNetzorganisation RARE (ReseauxAsso-cies pour la R6cherche Europeenne) inAmsterdam offiziell gegründet.

iele von RARE

RARE ist eine Vereinigung von nationa-len Netzorganisationen und unabhängigvon Herstellern oder Regierungen. Zielvon RARE ist es, die infrastrukturelleVoraussetzung für die Datenkommuni-kation des Wissenschafts-und For-schungsbereiches in Europa zu schaf-fen.

RARE trittfür die von der ISO (Internatio-nal Standards Organization) verab-schiedeten Standards für OSI (OpenSystems Interconnection) ein, um dieVerbindung von möglichst vielen Sy-Sternen herstellerunabhäng sicherstel-len zu können.

itgliedschaftDie RARE-Satzung läßt vier verschiede-ne Mitgliedschaften zu:

1. Nationale Mitglieder2. Assoziierte nationale Mitglieder3. Internationale Mitglieder4. Liaisonmitglieder.

Nationale Mitglieder von RARE sindnationale Netzorganisationen des Wis-senschafts- und Forschungsbereiches.

Die mit der EG im Rahmen des For-schungsprogrammes COST (Coopera-tion Scientifique et Technique)vertraglich gebundenen Länder sind aufdiese Weise mitgliedsberechtigt.

Gründungsmitglieder sind1. ACONET, Wien, Österreich;2. RUNIT, Trondheim, Norwegen;3. Griechenland;4. Luxemburg;5. Portugal;6. FUNDESCO, Spanien;7, CHUNET, Schweiz;8. JANET, United Kingdom;9. DFN, Bundesrepublik Deutschland;

10. SURFNET, Niederlande;11. SUNET, Stockholm, Schweden;12. HEANET, Dublin, Irland;13. ABUT/BVT, Brüssel, Belgien;14. FUNET, Helsinki, Finnland.

Als assoziierte Mitglieder kommen Netz-Organisationen anderer Länder in Be-tracht, sofern sie die Ziele von RAREunterstützen und an der Nutzung, derKoodination oder der Bereitstellung ei-ner Infrastruktur zugunsten der Daten-kommunikation des Wissenschafts-undForschungsbereiches arbeiten. Interna-tionale Mitglieder sind z. B. CERN undECFA (European Commission for FutureAccelerators). Liaisonmitglieder sindinternationale Organisationen, die imNetzbereich und in damit zusammen^hängenden Gebieten tätig sind. Ein Bei-spiel für eine Aufnahme als Liaisonmit-glied in RARE ist CEPT, die Vereinigungder europäischen Postgesellschaften.

Committee

Peter Linington, JANET (UK)Klaus Ullmann, DFN (D)Kees Neggers, SURFNET (NL),TreasurerBirgitta Carlson, SUNET (S)

Die vorläufige Geschäftsstelle ist inAmsterdam:

c/o James Martin AssociatesDe Boelelaan 873

NL-1082 RW Amsterdam

Organisation undbetriebliche AspekteIn vielen europäischen Ländern existiertbereits eine organisatorische und teil-weise technische Basis für die Kommu-

nikation im naturwissenschaftlichen Be-reich. Dort angebotene Dienste bauenauf unterschiedlichen Technologien,abhängig von den nationalen Gegeben-heiten, auf. Um der wachsenden Nach-frage der Wissenschaftler nach grenz-überschreitender Datenkommunikationnachzukommen, arbeitet RARE eng mitden europäischen Gremien, im beson-deren mit CEN/CENELEC und CEPT zu-sammen. Um jedoch eine wirksame Nut-zergemeinschaft etablieren zu können,bedarf es organisatorischer und be-trieblicher Harmonisierungen. Hier hatRARE eine entscheidende Rolle zuspielen.

orking GroupsDie unterschiedlichen Arbeitsgebietevon RARE sind in sog. Working Groupsorganisiert. Sie setzen sich aus Fach-leuten des Telekommunikationsberei-ches der RARE-Mitglieder zusammen,die sich regelmäßig treffen sollen. Diefolgende Aufstellung bezeichnet bereitsexistierende Working Groups mit ihrenVorsitzenden:

1. Message Handling - Alf Hansen (N),2. File Transfer - Francois Fluckiger

(CERN),3. Informationsdienste - Barry Mahon

(CEC DG XIII),4. Füll Screen Terminals -

Brian Gilmore (UK),5. Medium and High Speed Communi-

cations - Jaques Prevost (F),6. Zusammenarbeit mit nationalen

Postgesellschaften -Albert Kündig (CH).

etworkshopsRARE organisiertjährlich einen Informa-tionsaustausch (einen sog. Network-shop), zu dem Fachleute aus dem Wis-senschaftsbereich, der Industrie undder nationalen Postgesellschaften ein-geladen werden. Sie können dort ihreErfahrungen austauschen.

Der erste europäische Networkshopwurde 1985 in Luxemburg veranstaltet,Am zweiten Networkshop im Mai diesenJahres in Kopenhagen nahmen 120Fachleute aus 20 Ländern teil. Der dritteWorkshop wird 1987 in Madrid statt-finden. S. F. -S.

18

Für und Wider

Dr. Wulfdieter BauerfeldDipl.-lng. Martin WilhelmDFN-Verein,Zentrale Projektleitung, Berlin

Das Deutsche Forschungsnetz isteigentlich kein Netz: Der Transport derDaten wird von der Deutschen Bundes-post besorgt, das DFN nutzt ihre Vermitt-lungsdienste, in der Hauptsache denDienst Datex-P. Eine Reihe von DFN-Mitgliedern betreibt jedoch eigeneUntervermittlungen, welche die Daten-kommunikation in ihren privaten Netzengewährleisten. Nun könnte es durchauseinige Gründe für den DFN-Vereingeben, über diese privaten Vermitt-lungseinrichtungen hinaus große Teiledes öffentlichen Vermittlungsnetzes Da-tex-P der DBP durch ein in eigener Ver-antwortung zu betreibendes DFN-Ver-mittlungsnetz zu ersetzen. Drei Faktorenkönnten für diese Lösung sprechen:

1. höhere Betriebssicherheit,2. größere Datensicherheit,3. geringere Kosten.

Zur Untersuchung dieser Frage ist einekurze Darstellung der Datenvermittlungerforderlich:Aufgabe der Vermittlungsschicht istnach dem OSI-Referenzmodell die Be-reitstellung von Verbindungen zwischenEndsystemen. Vermittlung (switching)heißen die Funktionen, die ausgeführtwerden, um Daten von ihrem Ent-stehungsort zu dem Zielort zu transpor-tieren. Innerhalb des DFN geschieht dieVermittlung auf unterschiedliche Weise:

Im grundstücksüberschreitenden Da-tenverkehr1. durch öffentlich vermittelnde Daten-

dienste der Deutschen Bundespost(DATEX) bzw. durch Direktanschlußan diese Dienste,

2. durch den öffentlich nicht vermit-telnden Datendienst der DBP (HfD -Hauptanschluß für Direktruf"Standleitung"). Er umfaßt nur die un-teren Kommunikationsschichten (Bit-Übertragung, Sicherung) mit einemzwischen den HfD-Partnern ausge-handelten Zugangsprotokoll.

Im nicht-grundstücksüberschreitendenDatenverkehr1. durch private Untervermittlungen der

vermittelnden Dienste der DBP,2. durch private "Gateway"-Rechnerzur

Ankopplung unterschiedlicher loka-ler Netze bzw. Anwenderumge-bungen an private Untervermittlun-gen bzw. vermittelnde Datendiensteder DBP.

Als vermittelnder Datendienst der Bun-despost wird im DFN bisher in der Regelder paketvermittelnde Dienst DATEX-Püber das Anschlußprotokoll X.25 ver-wendet. Nicht-vermittelnde Verbindun-gen über HfD-Leitungen werden zurZeitinnerhalb des DFN aus tariflichen Grün-den im Berliner Raum (BERNET) undzwischen Hannover (RRZN) und Berlin(ZIB) benutzt. Auf diesen Leitungen wer-den X.25- bzw. X.25-ähnliche Protokolleverwendet, wobei in Berlin zur Vermitt-lung zusätzlich eigene Routing-Tabellenin entsprechenden Systemen imple-mentiert sind.

Zur privaten Untervermittlung vonDATEX-P werden innerhalb des DFNzwanzig bis dreißig X.25-Einrichtungenmeist von den jeweiligen Rechenzentrenso betrieben, daß gemäß den Bestim-mungen der Deutschen Bundespost ein,

19

zwei oder drei niederwertige Stellen derDATEX-P-Adressen weitervermitteltwerden. Die vorhandenen, in Laborsoder Rechenzentren betriebenen ca.zehn Gateway-Systeme bilden meistTeilmengen von DFN-Diensten auf loka-le Anwenderumgebungen ab. Diesesind über unterschiedliche Technikenmiteinander verbunden.

Doch zurück zu den möglichen Gründenfür ein DFN-eigenes Netz:Unter Betriebssicherheit wird hier aus-schließlich die Verfügbarkeit einerDatenübertragung zwischen zwei DFN-Endsystemen verstanden.

Zur Untersuchung der Datensicherheitmüssen unterschieden werden:- der Zugriff zum Vermittlungsnetz,- die Übertragung auf dem Vermitt-

lungsnetz,- der Zugriff auf ein Endsystem,- die Datensicherheit auf einem End-

System.

Die Kosten zum Betrieb eines Vermitt-lungssystems setzen sich zusammenaus den Kosten für die Bitübertragungzwischen Vermittlungssystemen undden Kosten für die Vermittlung.

Technischer ufbau

Um die anfangs genannten drei mög-lichen Gründe für ein mögliches DFN-Vermittlungsnetz näher betrachten zukönnen, wird im folgenden sein denk-barer technischer Aufbau kurz skizziert.

Seine Schnittstellen sollten den Schnitt-stellen zum öffentlichen Vermittlungs-netz Datex-P (d. h. X.25) entsprechen.Nur dann wären keine Änderungenin den angeschlossenen Endsystemennötig und der problemlose Zugang zumöffentlichen Netz wäre möglich. EinDFN-Vermittlungsnetz müßte daherdurch eine Anzahl leistungsstarker Ver-mittlungsrechner (entsprechend konfi-gurierte X.25-Untervermittlungssy-steme) verwirklicht werden. Diesewären durch HfD-Leitungen miteinan-der verbunden. In einem ersten Ansatzwird von zehn Untervermittlungen aus-gegangen, die durch HfD-Leitungenvermascht sind. Damit wäre eine Nord-Süd-Verbindung mit hohem Durchsatzgewährleistet. Zur Festlegung einer ge-nauen Netztopologie wären allerdingsweitere Untersuchungen nötig.

HfD HfDX. 25uv insgesamt 10 UV

X.25 X.25uv

Terminals

PAD

Gateway

Mini Mini \'\

HfD

HfD

X.25uv

LA N

uv

DFN-Netz

DFN-Anschluß

DFNHost

DFNHost

HfD

X.25VK

"HfD"

X.25VK

"HfD"

"HfD"

X.25VK

insgesamt 17 VK

X.25VK

Datex-P-Netz

Datex-P Anschluß

Host 1X.25uv

Privates Gelände DFN-Nutzer (Beispiel 1)

Host 2Privates Gelände (Nutzer 1 von Datex-P)

PAD

Privates Gelände (Nutzer 2 von DATEX-P)

PADHost Datex-P

Privates Gelände DFN-Nutzer (Beispiel 2) Privates Gelände (Nutzer 3 von DATEX-P)

UV = Untervermittlung. HfD = Hauptanschluß für Direktruf ("Standleitung"). VK = Vermittlungsknoten.

/s( die Einordnung eines eigenen DFN-Vermittlungsnetzes in die DATEX-P-Umgebung sinn-voll?

Die Vermittlungsrechner müßten durchStichleitungen mit den DFN-Endsy-stemen oder den bisher schon inner-halb des DFN betriebenen Vermit'tlungs-einrichtungen verbunden werden. ZurAnbindung an den öffentlichen Vermitt-lungsdienst (Anschluß temporärer oderwenig genutzter DFN-Endsysteme/Kommunikation mit nicht DFN-Partnernim öffentlichen Bereich) bzw. zur inter-nationalen Kommunikation wäre dasDFN-Vermittlungsnetz über ein odermehrere Vermittlungssysteme anDatex-P angeschlossen.

Rechtliche Fragen

Nach den zur Zeit gültigen Bestim-mungen erlaubt die Deutsche Bundes-post eine Weitervermittlung von Datenzwischen unterschiedlichen juristi-sehen Partnern nur mit einer Sonder-genehmigung. Für den Wissenschafts-bereich wäre eine solche Genehmigungeventuell zu erhalten. Schwierig wäreindes vermutlich die Einbindung indu-strieller Partner in das DFN-Vermitt-lungsnetz. Außerdem ist der Betrieb vonVermittlungssystemen nur in Kombina-tion von Vermittlung und Verarbeitunggestattet: Höchstens fünfzig Prozent der

ankommenden Daten dürfen aus die-sem System unverarbeitet wieder her-ausgehen, also weiter vermittelt werden.

Im privaten Vermittlungsbereich gibt eskeine mit dem Fernmeldegeheimnisvergleichbare allgemeine Regelung. Siemüßte innerhalb des DFN-Vereins nochgeschaffen werden. Zudem müßte auchdafür gesorgt werden, daß Unbefugtekeinen Zugang zu einem der Vermitt-lungsrechner haben.

Technische FolgenDie Betriebssicherheit

Die Betriebssicherheit des DFN-Ver-mittlungsnetzes hängt ab von

- der Ausfallsicherheit der HfD-Ver-bindungen,

- der Ausfallsicherheit der Vermitt-lungsrechner und

- der Redundanz des Vermittlungs-netzes (Vermaschungsgrad, Back-up-Rechner etc. ).

"Die mittlere Ausfallzeit einer Datex-P-Verbindung ist nur etwa halb so groß,wie bei einem HfD-Anschluß. Die Zuver-lässigkeit bzw. Verfügbarkeit ist beiDatex-P erheblich größer, als bei HfD"

20

Dies stellt eine kürzlich veröffentlichteUntersuchung (DATACOM 6, 1985,S. 36) fest. Und: "Je größer die Entfer-nungen sind, desto zuverlässiger wirdDatex-P im Vergleich zu HfD".Um die Betriebssicherheit von Datex-Pzu erreichen, müßte ein auf HfD-Verbin-düngen aufbauendes DFN-Vermitt-lungsnetz deshalb mit Redundanz aus-gelegt werden.

Die Datensicherheit

Die Zugangskontrolle von DFN-Endsy-stemen in ein DFN-Vermittlungsnetzhinein könnte im Prinzip mit geringerenMitteln erfolgen, als zu einem öffent-lichen Netz. Diesgiltallerdings nurdann,wenn die Kommunikationskostenpauschal erhoben würden. Außerdemdürfte das Vermittlungsnetz nicht unnö-tig durch "Mißbrauch" belastet werden.Die Zugangskontrolle zu den öffent-lichen Vermittlungsdiensten (z. B.Datex-P) wäre in demselben Umfang wiebisher nötig.

Die Kostenverrechnung

Bei einer pauschalierten ÜbernahmederVermittlungskosten durch den DFN-Verein könnte auf eine direkte Abrech-nung nach dem Verursacher-Prinzipverzichtet werden. Diese vereinfachteLösung steht zur Zeit aber noch imWiderspruch zum Wirtschaftskonzeptdes DFN-Vereins. Zudem würde sie aufjeden jeden Fall Nutzer mit geringemKommunikationsbedarf benachteiligen.Eine DFN-interne Kostenumlage bedarfeiner ausführlichen Untersuchung.Weitgehenden Verhandlungen über ei-ne mögliche DFN-Tarifstruktur wärenerforderlich.Eine ganze Reihe von Problemen würdedie Erfassung und Umlage der Kostenfür den Datenverkehr in den öffentlichenVermittlungsbereich hinein bringen. An-derenfalls müßten die DFN-Protokollegeändert werden. Eine entsprechendeDatenerfassung ist nur dann möglich,wenn die Daten der Anwender-ldentifi-Ration mitgeschrieben werden. DerDFN-Verein müßte also eine zentraleAbrechnungsstelle für die Kosten derDatenfernübertragung einrichten.

Integration in Datendienste derBundespost

Auch eine DFN-interne Vermittlungs-adresse müßte die Adressierbarkeit imbisherigen nationalen und internationa-len Rahmen (X. 121) mit Kostenabrech-

nung nach dem Verursacherprinzip ge-währleisten. Eine übergreifende Nut-zung internationaler Standardprotokol-le aus dem DFN-Vermittlungsnetz her-aus wäre sonst nicht möglich. Eine Al-ternative wäre nur der Betrieb von"Ga-teway"-Systemen als "Store-and-For-ward"-Knoten auf der Anwendungs-Schicht. Derartige Gateway-Systemeschließen aber die Online-Nutzung z. B.über Dialog von Zielsystemen aus, bzw.schränken sie ein. Die Möglichkeit der"technischen Loslösung" des DFN vonden logischen Prinzipien der offenenKommunikation wäre damit nicht auszu-schließen.

Die zur Zeit gültige Adreßstruktur derDBP läßt die Untervermittlung nur bishöchtens drei Stellen zu. Eine DFN-Adressierung nach dem Prinzip der DBP(Netzkennung, Ortsvorwahl, Teilneh-mer) ist nicht möglich.Der Betrieb nur einer DFN-Untervermitt-lung als öffentlicher Netzknoten ließemaximal 1000 Vermittlungsadressen zu.Der zur Zeit innerhalb des DFN bereitsausgeschöpfte Adressraum (ca. 100Hauptanschlüsse) wird auf etwa 500 ge-schätzt. Der Betrieb mehrerer öffentli-eher Netzknoten im DFN-Vermittlungs-netz würde zwar den möglichen internenAdressraum erhöhen, aber ein kompli-ziertes System für Abrechnung, Zu-gangsüberwachung und Routing erfor-dem.

In Zukunft wird ISDN (IntegriertesSprach- und Datennetz) das herkömm-liche Telefonnetz ablösen und dieSprachdaten zusammen mit den bereitsvorhandenen Datendiensten IDN ver-einigen. Nach dem aktuellen Informa-tionsstand wird der 1989 geplante Aus-bau von Datex-P (Version II) auf mehr als100. 000 Anschlußeinheiten zeitparallelmit der Einführung des ISDN erfolgen.Das bedeutet, daß z. B. Datex-P nichtdurch ISDN ersetzt wird, sondern als einwichtiges Datenvermittlungs-und Uber-tragungssystem bestehen bleiben wird.Entsprechende Aussagen der Bundes-post werden auch auf der nächsten Ver-Sammlung der Datex-P-Nutzer erwartet.Ein "Direktanschluß" an das paketver-mittelnde Datex-P'wird voraussichtlichweiterhin möglich sein. Mit der Einfüh-rung einer ISDN-"Steckdose" hat derNutzer die Möglichkeit, den für ihn gün-stigsten Tarif auf der Basis der Sprach-daten-Kommunikation oder auf der Ba-sis des über ISDN erreichbaren paket-vermittelnden Netzes zu wählen. Eine

Harmonisierung der unterschiedlichenTarife durch die DBP wird erwartet undist angekündigt.Die technischen Erfordernisse einesausschließlich auf ISDN basierendenDFN-Vermittlungssystems müßten nachOffenlegung der tariflichen Randbedin-gungen noch einmal geprüft werden.Ähnlich wie bei einem auf Paketver-mittlung basierenden DFN-eigenen Ver-mittlungsnetz könnten aber zur Zeitnoch nicht bekannte technische Impli-kationen zu einer Insellösung des DFN inBezug auf nationale und internationaleKommunikation und deren Verfügbar-keit führen.

Die Kostenstruktur

Die Kosten für ein Vermittlungsnetz set-zen sich zusammen aus- Investitionskosten und- Betriebskosten.

Der Aufbau des DFN-Vermittlungsnet-zes aus ca. zehn (Datex-P besitzt zurZeit 17) leistungsfähigen X.25 Unterver-mittlungen zu einem Stückpreis von 200bis SOOTausend DM würde Investitionenvon ca. 2, 5 Millionen DM erfordern.

Die Betriebskosten eines Vermittlungs-Systems setzen sich zusammen aus- Leitungskosten (abzuführen an die

DBP),- Wartungskosten für Vermittlungs-

Rechner und- Personalkosten.

Für die folgenden privaten nationalenVermittlungsnetze liegen Kalkulationender Betriebskosten vor bzw. konntenaus vorliegenden Zahlen geschätztwerden:Janet(UK):ca. 2, 5 Millionen DM/Jahrmit ca. 35% Leitungskosten

45% Wartungskosten20% Personalkosten

EARN (BRD):mind. ca. 650. 000 DM Leitungskosten(davon 516. 000 DM Finanzierung durchIBM),ca. 1 Mio DM Personalkosten.Vermittlungskosten sind unbekannt, zurZeit wird als zentraler Knoten eineIBM 4361-LOS eingesetzt.

FazitDie unterschiedlichen Betrachtungenzeigen, daß sowohl die rechtlichen Fra-gen als auch die Kosten den Aufbau undden Betrieb eines eigenen DFN-Vermitt-lungsnetzes nicht rechtfertigen.

21

Abgeschlossene DFN-Entwicklungen

DFN-Dienste für dieerste Protokoll-generation

Dipl.-lng. Martin WilhelmDFN-Verein,Zentrale Projektleitung, Berlin

Bereits in der letzten Ausgabe der DFN-Mitteilungen wurde berichtet, daß fürImplementierungen der DFN-Diensteauf Rechenanlagen der Typen CDC/NOS-BE, Siemens/BS2000 und Sper-ry/031100* ein Feldversuch begonnenwurde, um erste Betriebserfahrungenmit der Protokollgeneration 1 zu sam-mein und möglicherweise noch verbor-gene Fehler sowie Schwächen imDesign aufzudecken. Erste Erfahrungs-berichte liegen jetzt vor. Sie zeigen, daßeine sehr intensive Nutzung jedoch bisvor Kurzem noch nicht möglich war, dadie Zahl der über die Dienste der erstenProtokollgeneration erreichbaren Part-ner naturgemäß klein war.

Fast unbemerkt wurde von den am Job-verbünd Nordrhein-Westfalen beteilig-

ten Hochschulen (Aachen, Bielefeld,Bochum, Düsseldorf und Köln) der RJE-Dienst für die erste Protokollgenerationin den Alltagsbetrieb überführt. Den Be-nutzem, die mit Hilfe dieser Komponen-ten in die Lage versetzt werden, ihrerechenintensiven Aufträge auf der sehrleistungsstarken CDC 205 Rechenanla-ge der Ruhruniversität Bochum bearbei-ten zu lassen und die Ergebnislisten zu-rück zu ihrem "Heimatrechenzentrum"übertragen lassen können, ist derWechsel zu einem internationalen Stan-dard in der Transportschicht sichernicht aufgefallen - und das ist auch gutso!

Die Cray-Anlage des Konrad-Zuse-ln-stitut (ZIB) in Berlin, die auch in erhebli-ehern Umfang von wissenschaftlichenEinrichtungen außerhalb Berlins ge-nutzt wird, ist seit Anfang Mai sowohl mitden Diensten der Generation 0 als auchüber die Dienste der ersten DFN-Proto-kollgeneration erreichbar. Zur Zeit wirddieser zusätzliche Service hauptsäch-lich von der Gesellschaft für wissen-schaftliche Datenverarbeitung (GWDG)von Göttingen aus in Anspruch genom-men. Dank intensiver Vorbereitungdurch das Rechenzentrum der Universi-tat Freiburg konnten trotz eines Ver-sions-Wechsels die DFN-Dienste aufdem Sperry System 1100/80 der GWDGproblemlos installiert und binnen vierWochen in den täglichen Routinebetriebüberführt werden. Dazu hat sicherlichauch das Engagement des Herstellersbeigetragen, der seine in der Sulz-bacher Zentrale installierte Anlage füreine Pilotinstallation zur Verfügungstellte und wertvolle Anregungen für dieSystemintegration gab.

Eine derartige Lösung, bei der für eineÜbergangszeit beide Protokollgenera-

tionen parallel angeboten werden kön-nen, ist für die Beteiligten sicherlich be-sonders günstig. Leider ist dies austechnischen Gründen nicht immermachbar.

Neben diesen Entwicklungen, die schonihre Bewährungsprobe im Tageseinsatzhinter sich haben, sind in den letztenWochen weitere DFN-Kommunikations-komponenten von den jeweiligen Ent-Wicklern fertiggestellt worden. Dazu ge-hören die Entwicklungen für

- VAX/VMS- PDP11/RSX- UNIX System V- UNIX bsd 4.2- Prime/Primos

Nach dem Abschluß der Entwicklungs-arbeiten soll nun in einem erweitertenFeldversuch das betriebliche Verhaltendieser neuen Komponenten erprobtwerden. Dazu haben sich einige DFN-Mitgliedseinrichtungen bereiterklärt. Essoll an dieser Stelle ein herzliches"Dankeschön" all jenen gesagt werden,die entweder während der Entwicklungoder in einem anschließenden Feldver-such daran mitgearbeitet haben (oderdies noch immer tun), daß die entwickel-ten DFN-Dienste sich nicht nur durcheinwandfreies Protokollverhalten aus-zeichnen, sondern auch den Bedürfnis-sen von Nutzern und Betreibern gerechtwerden.

Dadurch, daß nun eine größere Anzahlvon Entwicklungen dem Feldversuchzugeführt werden kann, sind auch dieVoraussetzungen für eine intensivereNutzung und damit für aussagekräftige-re Ergebnisse gegeben.

* In Heft 4 DFN-Mitteilungen, fehlte das BetriebssystemOS1100 in dem Übersichtsbild auf Seite 4. Wir bedauerndieses Versehen.

CDC CDC* CDC IBM IBM Siemens Siemens Siemens DEC DEC UNIX UNIX . .._... ". Abb. 1:NOS/BE NOS NOS/VE MVS VM BS 2000 MSP R 30 RSX11 VMS V BSD4. 2 !iperry NU1"U "lme Verfügbarkeit von DFN-Diensten

(Stand Juni 1986)

derzeit keine Planung fürEntwicklungen,

V: bereits verfügbar,11/87: verfügbar ab 2. Quartal 1987P; In Planung, z. Zt. keine

Termine angebbar

*)überVorrechnerND100

MHS

RJE

File Tr.

T. 70

PAD

X.29

X.25

v

v

v

v

v

v

v

p

v

v

v

v

11/87

11/87

11/87

11/87

11/87

IV/87

p

1/87

1/87

v

v

v

v

p

1/87

1/87

IV/86

1/87

v

v

p

v

v

v

v

v

v

1/87

1/87

IV/86

v

v

v

v

v

v

v

v

v

v

v

v

v

v

v

v

v

v

v

p

v

v

v

v

v

p

v

v

v

v

v

v

v

v

v

v

v

v

p

v

v

v

v

v

v

v

v

v

v

22

E-Mail-Premiere auf der CeBIT

Koordination vonMessage-Handling-Systemen mehrererHersteller

Dipl.-Math. Rüdiger GrimmGesellschaft für Mathematik undDatenverarbeitung mbH (GMD),Darmstadt

Auf der CeBIT '86, der größten Compu-ter-Fachmesse der Welt, wurde unterder Schirmherrschaft des DeutschenForschungsnetzes eine Weltpremiereaufgeführt. In den vergangenen Mona-ten ist es dem DFN gelungen, eine Prä-sentation von Message-Handling-Sy-Sternen verschiedener Hersteller so zukoordinieren, daß sie nach den moder-nen Standards offen miteinander kom-munizieren können. Das Ergebnis wur-de auf der CeBIT mit großem Erfolg vor-geführt. Zu den kooperierden Partnerngehörten die Firmen IBM und Siemenssowie die Gesellschaft für Mathematikund Datenverarbeitung, auch ICL undBULL beteiligten sich in erprobter Zu-sammenarbeit mit Siemens. Und auchNixdorf akzeptierte, trotz denkbar kür-zester Testzeit, die Chance der gemein-samen Pioniertat. So zeigte schließlicheine große heterogene Gruppe unterdem Dach des DFN-Standes, daß ihreverschiedenen Produkte doch eineSprache miteinander sprechen können.

on geschlossenen zuoffenen SystemenElektronische Nachrichtensystemesind durchaus nichts Neues auf demComputermarkt. Jede größere Compu-terfirma benutzt und verkauft sie schonseit langem. Der Haken ist nur: Aus demNachrichtensystem des einen Herstel-lers konnte man bisher keine Nachrichtin das System eines anderen Herstellerssenden. Solche Systeme nennt man da-her auch "geschlossene Systeme". Aufdem nordamerikanischen Markt derKommunikationstechnik zum Beispiel

sind zahlreiche Netze mit jeweils großerVerbreitung, aber unterschiedlicherTechnik in Betrieb - nur über teure undlangsame Gateways sind sie miteinan-der verbunden. Die europäischen Netzestehen erst am Anfang ihres Aufbaus.Das Deutsche Forschungsnetz setztsich dabei für "Offene Systeme" ein, diemiteinander durch international ge-normte Codierungsregeln entspre-chend den X.400-Empfehlungen derInternationalen Vereinigung der Postge-Seilschaften (CCITT) kommunizierenkönnen und daher herstellerunabhän-gig sind. Dazu sind die Ideen auf einenNenner zu bringen, die in den europai-sehen Entwicklungslabors beginnen,Wirklichkeit zu werden. Wenn erst ein-mal der "Appetit" der Kunden auf her-stellerunabhängige und normgeprüfteProdukte angeregt ist, dann werden sichdie Hersteller schon ganz allein, darumbemühen, ihre Netzprodukte "offen" zugestalten - so hofft man auf die Kräftedes Marktes. Darin sah das DFN eineAufgabe.

Anregungen für dieComputerfirmenDas erste Ziel dieser Messevorführungwar es daher, den Computerfirmen eineAnregung zu geben und den erstenSchritt mit ihnen gemeinsam zu tun. Dieeinzelnen Hersteller sollten sich um ei-nen Tisch setzen, gemeinsame Verabre-düngen waren zu treffen und Testseriendurchzuführen. Produkte für denNachrichtenaustausch waren schonvorhanden. Aber jetzt mußten sie denX.400-Regeln angepaßt werden. Und dain der Kürze der Zeit der volle Funktions-umfang nicht herstellbar war, mußteman sich über eine sinnvolle Teilmen-ge und gemeinsame Interpretationenvon Zweifetsfällen einigen. Man konntesich da auf das sogenannte SPAG-Profileinigen, das von zwölf europäischenHerstellern entworfen worden war.Schließlich mußte das DFN auch denRahmen für eine Messevorführung an-bieten, in dem alle Teilnehmer gut reprä-sentiert waren. Die Lösung: Auf demDFN-Stand wurden Geräte aller Partneraufgestellt, gleichzeitig wurden Verbin-düngen zu Geräten der Firmenständeund zu weltweit bereits operierendenrealen Nachrichtensystemen gehalten.Dies wurde übereinstimmend als glück-lich empfunden.

23

Teilnehmer äußern sich zur CeBIT '86

DFN-Mitteilungen im Gespräch mit:

Georg Scheint,Siemens AG, München

Dr. Günter Müller,IBM Deutschland GmbHEuropäisches Zentrum fürNetzwerkforschung (ENC), Heidelberg

Horst Bliedung,Nixdorf Computer AG, Paderborn

Peter Gentz,Technische Universität Berlin

Gertrud Foest,DFN-Verein, Berlin

Die Premiere der ersten selbständigenCeBIT war auch gleichzeitig das Debütdes DFN auf internationalem Messepar-kett. An dieser Stelle sei für die freund-liche Unterstützung des DFN durch dieGesellschaft für Mathematik und Daten-Verarbeitung mbH (GMD) gedankt, mitder man sich gemeinsam einen Standteilte. Die CeBIT erwies sich als ein gutesForum für das Anliegen des DFN, ein

fachorientiertes Publikum anzuspre-chen, das auf dieser Messe reichlichvorhanden war.

Es begann mit der Pressekonferenz am12. 3. 1986. Über 50 Pressevertreter vonTages- und Fachpresse fanden sich indem Saal London des Pressezentrumsder CeBIT ein. Der DFN-Verein stellteder Presse die Exponate "Mail-Ver-

300

Der Stand des Deutschen Forschungsnetzes auf der CeBIT '86 in Hannover.Foto: Dr. G. Müller, IBM Deutschland GmbH.

Das DFN war auf eine solche Aufgabegut vorbereitet. In Zusammenarbeit mitdem DFN waren im Lauf der letzten Jah-re schon mehrere offene Systeme ver-fügbar geworden, die bereits von Mit-gliedern des DFN benutzt werden. Fürdie Betriebssysteme UNIX und VAX-VMS ist im Auftrag des DFN das bekann-te kanadische Produkt EAN auf aktuel-len Stand gebracht worden. Die GMDund das European Network Center derIBM haben - ebenfalls in Abstimmungmit dem DFN - einen EARN-Gatewayzuroffenen Kommunikationswelt fertigge-stellt. Innerhalb der GMD wird auf demSiemens-System BS 2000 schon langedas Nachrichtensystem KOMEX ver-wendet, das nun nach den X.400-Re-geln geöffnet ist. Siemens und IBM wa-ren außerdem jeweils mit einer Eige-nentwicklung beteiligt. Und auch die Fir-men ICL, BULL und Nixdorf führten in ei-

genen Labors hergestellte Nachrichten-

Systeme vor. Als Bonbon konnte dieGMD noch einen Anschluß an das post-eigene Teletexsystem vorführen. So wa-ren es nicht weniger als zehn verschie-dene Produkte, zwischen denen in freierWahl Briefe hin- und hersausten.

Geschwindigkeit nochkeine StärkeMit dem "Sausen", das muß zugegebenwerden, gab es einige Probleme. Ge-schwindigkeit war keine Stärke dieserVorführung, da einige Systeme auf derMesse erstmals unter volle Betriebsbe-lastung kamen und dabei Mängel auf-wiesen. Die Entwicklungsingenieure,welche die ganze Zeit bei der Messe an-wesend waren, haben buchstäblich eiligmitgeschrieben, um die Messe-Erfah-rungen in die weitere Entwicklungsar-beit einfließen zu lassen.

Und damit ist das zweite Ziel dieser Mes-sevorführung genannt, das - neben derAnregung für den Computermarkt - ge-nauso wichtig einzuschätzen ist: Erfah-rungen zu sammeln und auszuwerten.Denn auf der Messe wurden nicht ver-kaufsfertige Produkte vorgeführt - dasgalt für alle Teilnehmer - sondern einEntwicklungsstand auf dem Weg zu of-fenen, schnellen und leicht bedienbarenElektronischen Nachrichtensystemen.In Zukunft, das zum Beispiel ist über-deutlich geworden, werden strenge undzentral überprüfbare Konformitätstestsnotwendig sein, um dem Dschungel derbilateralen Tests "jeder mit jedem" undden sich daraus ergebenden Diskus-sionen über Normen-lnterpretationenzu entgehen. Offenbar müssen die Sy-steme auch noch ein- facher und hand-licher werden und ihr Ingenieurdesignüberwinden.

24

bund", "Info-System" und "Erfahrungender Chemie im Umgang mit DFN-Dien-sten" vor. Das erste Presse-Echo ließdann auch nicht lange auf sich wartenund man besuchte von Seiten der Pres-se den DFN-Stand, wo sich die Journali-sten vor Ort vom Funktionieren desneuen Mail-Verbundes sowie der Fern-messung von zu analysierenden Probenin der Chemie überzeugen konnten. DasInformationssystem, das zum Selbst-probieren einlud, wurde ebenfalls mitgroßem Interesse wahrgenommen. Un-ter der Überschrift "DFN-Basis-Dienstesind bisher weltweit ohne Beispiel"konnten sich die Leser in der CeBIT-Nachlese der "Computerzeitung" überdas DFN informieren. Im CeBIT-Reportder Zeitschrift "Online" gilt das Wis-sensnetz für die Zukunft als gesichert.Die "Chemische Rundschau" griff natur-gemäß das Thema "Chemische Instituteam Netz" auf und berichtete ausführlichauf der ersten Seite über die Möglich-keiten, die das DFN dem Chemiker bie-tet. Unter der Überschrift "OSI zum An-fassen" und "Kooperation durch OSI-Demonstration" wurde der Mail-Ver-bund durch die schon erwähnte Com-puterzeitung in einer ausführlichen Re-portage gewürdigt. Die "Zeitschrift fürMedien und Werbung" sprach in diesemZusammenhang von der sympathi-sehen OSI-ldee des Jeder-mit-Jedem-Kommunizierens. "DFN - Forschen imVerbund, offenes Datenkommunika-tionsnetz made in Germany" war dieÜberschrift der "Elektronik Technolo-gie"-Zeitschrift mit einem ebenfalls aus-führlichen Artikel über das DFN. Unterder Überschrift "Noch ein Netz" hob das"Computer Magazin" die Tugenden(Herstellerunabhängigkeit und Offen-heit), die das DFN gegenüber anderenNetzen aufweist hervor. Darüberhinauserschien ein Artikel zum Thema DFN indem Berliner "Tagesspiegel" und in der"FAZ".

Wie beurteilen die Teilnehmer, die dieKommunikationsdienste auf der Messevorführten, den Erfolg? K.-F. Egenten-meiervon den DFN-Mitteilungen richte-te einige Fragen an die Mitarbeiter aufdem Messe-Stand des DFN.

DFN-Mitteilungen: Ein großer Ansturmvon Besuchern war bei der Electronic-Mail-Demonstration des DFN zu ver-zeichnen. Hierzu einige Fragen an diebeteiligten Firmenvertreter

Sie haben sich mit Ihrer Firma auf derCeBIT am Mail-Verbund beteiligt. Wiewaren Ihre Erfahrungen bezüglich desFunktionierens des ersten offenen Mail-Verbundes?

Scheint (Siemens AG): Die Multiven-dor-Vorführungen waren insgesamtsehr überzeugend, vor allem durch dieVielfalt der beteiligten Systeme (BULL/ICL/SIEMENS/IBM/NIXDORF/GMD/DFN).

Dr. Müller (IBM-ENC): Da nur ein Ver-mittlungsrechner der Post zur Verfü-gung stand, war die Performance ge-ring. Die Zusammenarbeit mit den Part-nern auf dem Stand würde ich als gut bishervorragend bezeichnen.

Bliedung (Nixdorf Computer AG):Unsere Erfahrungen waren aufgrundder guten Zusammenarbeit zwischenden Herstellern und der Koordinationund Durchführung durch das DFN sehrpositiv. Wichtig für uns war zu demon-strieren , daß mit OSI ein Standard ge-schaffen wurde, der es ermöglicht, daßSysteme verschiedener Hersteller mit-einander kommunizieren können.

DFN-Mitteilungen: Wie haben dieMessebesucher auf den Verbund rea-giert?

Bliedung: Nixdorf hatte sehr viele Be-Sucher mit Interesse an Bürolösungenauf der Basis von OSI auf dem Stand.Sehr positiv wurde die Präsentation derMultivendorkommunikation aufgenom-men. Für viele Interessenten war es daserste Mal, daß sie die Kommunikationzwischen Systemen verschiedener Her-steiler auf der Basis der OSI Architekturam Beispiel von Electronic Mail sehenkonnten. Insbesondere wurde der vonNixdorf gezeigte Ansatz der Integrationin die Dokumentenverarbeitung positivbewertet.

Scheint: Viele wichtigen Kunden habensich die Multivendor-Vorführungen amSiemens-Stand (in der Halle 1), am BIS-Stand (Halle 6) und am DFN-Stand(Halle 4) angesehen.

Dr. Müller: Sehr gut. Wir hatten 249 Be-sucher auf dem Stand gezählt.

DFN-Mitteilungen: Meinen Sie, daß derwichtige Standard für e-Mail (X. 400 ff)eine weite Verbreitung finden wird?

Scheint: Ja, ganz bestimmt.

4,n.

Frau Gertrud Foest von der Zentralen Projekt-leitung im Gespräch mit Herrn K. -F. Egeten-meier von den DFN-Mitteilungen.Foto:,Rüdiger Grimm (GMD).

Dr. Müller: Ja, davon sind wir - das ENG- sehr überzeugt.

Bliedung: Ja, Nixdorf ist der Uberzeu-gung, daß sich X.400 ff als Standarddurchsetzten wird, der von vielen nam-haften Herstellern und Postbehördenunterstützt wird. Aus diesem Grund hatNixdorf die Strategie für den Dokumen-tenaustausch darauf abgestimmt.X.400 ff ist für Nixdorf der Standard fürden Dokumentenaustausch und nichtnur ein Mitteilungsdienst.

DFN-Mitteilungen: Sollte solch eine De-monstration in dem gleichen Rahmennoch einmal stattfinden?

Scheint: Eine solche Demonstrationwird in der Zukunft mit Standardproduk-ten vorgeführt. Eine Demonstration aufder Hannover-Messe 87 ist im Ge-sprach, mit viel größerem Teilnehmer-kreis.

Bliedung: Ja, es sollten weitere Prä-sentationen dieser Art stattfinden. Eswäre wünschenswert, wenn dieses in ei-nern noch größerem Rahmen unter derBeteiligung von weiteren interessiertenFirmen mit Einbeziehung der Bundes-post durchgeführt würde.

Dr. Müller: Wir halten dies nichtfür nötig,da die technische Machbarkeit gezeigtwurde. Entweder sollte das DFNProduk-te zeigen, oder die Firmen in eigener Re-gie mit dem DFN zusammen Produktezeigen.

DFN-Mitteilungen: Herr Gentz, Sie sindvom Ivan-Stranski-lnstitut der TU Berlinund haben die "Chemie am Netz"vorge-führt. Wie waren Ihre Erfahrungen aufder CeBIT?

25

Nutzergruppen

f<,

Gerrit Henken vom DFN-Verein (links) im Ge-sprach mit Staatssekretär Hans-Hilger Haun-Schild vom BMFT (rechts). In der Mitte Dr.K/aus Eckart Maass vom DFN-Verein.Foto; Dr. Manch (GMD).

Gentz (TU Berlin): Auch wenn man nichtaus der Informationstechnik kommt,wird man mit der Zeit zum Profi und zwarkonkret durch den praktischen Umgangmit den Diensten, die das DFN demChemiker bietet. Die erste Fernbedie-nung eines NMR-Spektrometers (analy-tisches Meßgerät) über das DATEX-P-Netz der Bundespost haben wir auf demStand des DFN-Vereins im Herbst 1985auf der "Big-Tech" vorgeführt; dies magfür Leute aus der Informationstechnikals nichts besonderes erscheinen, aberin der Chemie ist es etwas, was bis vorkurzem noch für unmöglich gehaltenwurde. Wichtig für diese Möglichkeit istder hohe Computerintegrationsgraddieser Geräte, so daß sogar der Proben-Wechsel vom Rechner gesteuertwerdenkann. Auf der CeBIT bestand die Mög-lichkeit, dies einem wesentlich größe-rem Publikum als seinerzeit auf der "Big-Tech" zu demonstrieren. Die Leute, diekamen, zeigten sich sehr interessiert.Ein ganz positiver Nebeneffekt war, daßdie Leute aus dem DFN, die sonst nichtoder sehr selten zusammenkommen,alle da waren, was den persönlichenKontakt ausweitete.

DFN-Mitteilungen: Frau Foest, Siehatten das Info-System betreut. Daszentrale Informationssystem des Deut-sehen Forschungsnetzes soll über diewesentlichen organisatorischen undtechnischen Gegebenheiten des DFNAuskunft geben. Hat es diesen Ansprü-chen auf der CeBIT Genüge getan?

Foest (DFN-Verein): Das Informations-System liegt derzeit in einer ersten Pilot-Version vor, dementsprechend frag-menthaft sind auch noch die Informatio-nen. Ich glaube, daß es uns gelungen ist,dem Interessenten einen Überblick zugeben, was später das Informationssy-stem sein soll.

DFN-Mitteilungen: Auf der CeBIT wur-den die Besucher eingeladen, sich desInformationssystems selbständig zu be-dienen, d. h. sich ans Terminal zu setzen,um an die für sie interessanten Informa-tionen heranzukommen. Wie waren IhreErfahrungen im Umgang mit den Inte-ressenten?

Foest: Man konnte auf der Messe zweiunterschiedliche Gruppen von Interes-senten ausmachen. Die eine Gruppezeichnete sich dadurch aus, daß ihnendas DFN über ihre Institution bekanntwar, und das waren recht viele. DieseLeute hatten überhaupt keine Schwie-rigkeiten, sich ganz konkrete Informa-tionen zu beschaffen, die sie sich aufPapier ausgedruckt dann mit nachHause nahmen. Die andere Gruppe,denen das DFN relativ unbekannt war,hatte doch eine gewisse Schwellen-angst, sich an das Terminal zu setzenund einfach auszuprobieren. Die es ge-wagt haben, waren im großen undganzen damit zufrieden. Die meistenwollten sich lieber im persönlichen Ge-sprach darüber informieren, was ist daseigentlich, das DFN. Dieser Personen-kreis war von den beiden der größere.

DFN-Mitteilungen: Viele Interessentenerhofften sich durch das DFN-lnforma-tionssystem eine spontane Online-ln-formation auf beliebig viele Datenban-ken von Fachinformationszentren usw.in der Bundesrepublik Deutschland.Kann das DFN-lnfo-System eine derartglobale Information vermitteln?

Foest: Das Informationssystem kannund soll so etwas nicht vermitteln, eskann in einem weiteren Ausbau Aus-kunft darüber geben, welche Datenban-ken über das DFN zugänglich sind. Eswäre wünschenswert, wenn möglichstviele Fachinformationszentren sich andas DFN anschließen und der Wissen-schaftsgemeinde einen Zugang zu ihrenInformationen ermöglichen würden. DasInformationsbedürfnis der Besucherwar sehr groß.

Nutzergruppen und Sprecher

Zur Klärung technischer und admini-strativer Fragen existieren derzeitfolgende

Fachspezifische Nutzergruppen:

Methodenbank RSYST:Prof. Dr. Rühle, Univ. Stuttgart

Chemische Analytik:Prof. Dr. P. Ziessow, TU Berlin

Hochenergiephysik (HEP)Dr. T. Kokott, Univ. Bonn

Künstliche Intelligenz undMustererkennung:Prof. Dr. B. Radig, Univ. Hamburg

Entwurf Integrierter Schaltkreise(E. I.S.):A. Kaesser, GMD Bonn

Schiffbau:Prof. Dr. H. Nowacki, TU Berlin

Arbeitskreis der LeiterWissenschaftlicherRechenzentren (ALWR)

K. Brauer,Univ. Osnabrück

EARN:M. Hebgen, Univ. Heidelberg

Max-Planck-Gesellschaft:Dr. Th. Plesser, MPI fürErnährungsphysiologie, Dortmund

SUPRENUM:C. Vogt, GMD, St. Augustin

Regionale Nutzergruppierungen:

Nordrhein-Westfalen (Jobverbund):Prof. Dr. J. Knop, Univ. Düsseldorf

Nord-Bayern, RRZE Erlangen:Dr. P. Holleczek, Univ. Erlangen

NiedersächsischerRechnerverbund,RRZN:Dr. H. Pralle, Univ. Hannover

Berlin, BERNET:Dr. K. Andre, Konrad-Zuse-Zentrumfür Informationstechnik Berlin

Termin der 6. Mitgliederversammlung:

Mittwoch, 10. Dezember 1986, in Berlin.

26

Die Mitgliederdes DFN-Vereins

Ansprechpartner

Stand Juli 1986

Der DFN-Verein hat derzeitfolgende (97) Mitglieder

Wirtschaftsunternehmen:

AEG Aktiengesellschaft, FrankfurtCRAY Research GmbH, München

Danet GmbH, Darmstadt

Digital Equipment GmbH, MünchenEDS Electronic Data Systems (Deutschland)GmbH. Rüsselsheim

Hoechst AG, Frankfurt/M.Honeywell Bull AG, KölnIBM Deutschland Gmbh, SindelfingenMannesmann Kienzle GmbH,Villingen-SchwenningenNixdorf Computer AG, PaderbornPeriphere Computer Systeme GmbH,München

Philips-Kommunikationsindustrie AG,NürnbergPrime Computer GmbH, Wiesbaden

Siemens AG, München-Berlin

Sperry GmbH, SulzbachStandard Elektrik Lorenz AG, StuttgartTriumph Adler AG, Nürnberg

Forschungsgesellschaften,Großforschungseinrichtungen undvergleichbare Forschungs-einrichtungen:

Alfred-Wegener-lnstitut für Polar- und Meeres-forschung, BremerhavenBerliner Elektronenspeicherring-Gesellschaftfür Synchotronstrahlung mbH (BESSY)Bundesanstalt für Materialprüfung (BAM),BerlinCentre Europöen de RechercheNucl6aire (CERN), GenfDeutsches Elektronen-Synchroton(DESY), HamburgDeutsche Forschungs- und Versuchs-anstalt für Luft- und Raumfahrt e. V.(DFVLR), KölnDeutsches Institut für Normung e. V.(DIN), BerlinDeutsches Krebsforschungszentrum(DKFZ), HeidelbergFachinformationszentrum Energie,Physik, Mathematik Gmbh, KarlsruheFraunhofer-Gesellschaft zur Förderungder Angewandten Forschung e. V., MünchenGermanischer Lloyd, HamburgGesellschaft für BiotechnologischeForschung (GBF), BraunschweigGesellschaft für Information

und Dokumentation mbH (GID), FrankfurtGesellschaft für Mathematik und Daten-Verarbeitung mbH (GMD), St. AugustinGesellschaft für SchwerionenforschungmbH (GSI), DarmstadtGesellschaft für Strahlen- und Umwelt-forschung mbH (GSF), NeuherbergHeinrich-Hertz-lnstitut für Nachrichten-technik Berlin GmbH (HHI)Hahn-Meitner-lnstitut für KernforschungBerlin GmbH (HMI)Kernforschungsanlage Jülich GmbH (KFA)Kernforschungszentrum KarlsruheG mb H (KfK)Konrad-Zuse-Zentrum fürInformationstechnik Berlin (ZIB)Max-Planck-Gesellschaft zur Förderung derWissenschaft e. V. (MPG), München

Universitäten unduniversitäre Einrichtungen:Rheinisch-Westfälische TechnischeHochschule Aachen

Universität AugsburgUniversität BambergUniversität BayreuthFHS der Deutschen Bundespost BerlinFreie Universität BerlinTechnische Universität Berlin

Universität BielefeldUniversität Bochum

Universität BonnUniversität BraunschweigHochschule Bremen

Universität Bremen

Technische Universität Clausthal Zellerfeld

Technische Hochschule Darmstadt

Zentrum für GraphischeDatenverarbeitung e. V., DarmstadtUniversität Dortmund

Universität Düsseldorf

Universität Gesamthochschule DuisburgUniversität Erlangen-NürnbergUniversität Gesamthochschule Essen

Universität Frankfurt/MUniversität FreiburgUniversität Giessen

Gesellschaft für wissenschaftliche Daten-Verarbeitung mbh, GöttingenFernuniversität HagenUniversität HamburgUniversität Hannover

Universitätsbibliothek Hannover undTechnische Informationsbibliothek

Universität HeidelbergHochschule Hildesheim

Universität Hohenheim

Universität Kaiserslautern

Universität Karlsruhe

Universität KielUniversität zu KölnUniversität Konstanz

Computer Centre for Research and Education(RECKU), KopenhagenInstitut Europeen pour la Gestionde l'lnformation, LuxemburgUniversität Mainz

Universität Mannheim

Universität MarburgLeibniz-Rechenzentrum der BayerischenAkademie der Wissenschaften, München

Technische Universität München

Universität der Bundeswehr, München

Universität MünsterUniversität OldenburgUniversität Osnabrück

Universität Gesamthochschule Paderborn

Universität Passau

Universität RegensburgUniversität des Saarlandes

Universität Gesamthochschule SiegenUniversität StuttgartUniversität Trier

Universität TübingenUniversität Würzburg

Geschäftsstelle des DFN-Vereins,Pariser Straße 44, 1000 Berlin 15,Telefon (030) 884299-25... 21Telefax (030) 88 42 99-70Telebox DFN 100

VorstandProf. Dr. N. Szyperski (Vorsitzender),Mannesmann Kienzle GmbH,Villingen-SchwenningenDr. H. Hultzsch (stellv. Vorsitzender),EDS, RüsselsheimProf. Dr. E. dessen (stellv. Vorsitzender),TU München

Weitere Verwaltungsrats-mitgliederProf. Dr. K.-H. Beckurts, Siemens AG,MünchenDipl. Volkswirt A. E. Eßlinger, IBMDeutschland GmbH, StuttgartProf. Dr. D. Haupt, RWTH AachenProf. Dr. H. Jordan, DFVLR KölnProf. Dr. K. Pinkau, MPG MünchenProf. Dr. B. Schlender, Universität KielProf. Dr. M. Syrbe, FhG MünchenProf. Dr. K. Zander, HMI Berlin

Technischer AusschußDr. U. Dierk, Nixdorf, PaderbornG. Goergens, Siemens AG, MünchenM. Hebgen, Univ. HeidelbergProf. Dr. H. -G. Hegering, TU MünchenProf. Dr. E. Jessen, TU München (Vorsitz)0. B. Kirchner, IBM Deutschland, StuttgartDr. E. Raubold, GMD, DarmstadtProf. Dr. B. Suhlender, Univ. KielDr. A. Vogel, BMFT Bonn

Geschäftsführungund Zentrale Projektleitung(® 88 42 99-)K. Ullmann: wiss. techn. GF (® -20)Dr. K.-E. Maass: administr. GF (® -25)

Entwicklungsaufgaben:0 Basis-Dienste Dialog, Remote Job

Entry (RJE) und File Transfer (FT):M. Wilhelm (® -30) (Federführung)G. Henken (®-33)Dr. W. Lehmann-Bauerfeld (® -34)Dr. K. Truöl (® 06151-869311)

0 Lokale Rechnernetze (LAN)Dr. W. Lehmann-Bauerfeld (® -34)

0 Graphische Dienste im DFNG. Maiß (® -37)

0 Rechnergestützter Briefverkehr(CBMS)G. Henken (® -33) (Federführung)Dr. P. Kaufmann (® -32)R. Schroeder (® -38)Dr. K. Truöl (® 06151-869311)

Betriebsaufgaben:M. Wilhelm (® -30) (Federführung)G. Foest (® -36)

Betreuung und Akquisition vonNutzergruppen:J. Lügger (® -31) (Federführung)Dr. W. Lehmann-Bauerfeld (® -34)U. Kahler (® -35)Programm " VernetzteArbeitsplatzrechner im DFN"Dr. W. Lehmann-Bauerfeld (® -34)(Federführung)J. Heigert (® -39)Administrative Aufgaben:E. Kostrzewa (® -26)D. Assheuer (® -27)

Internationale Kontakte:S. Fuhrmann-Seifert (® -60)Öffentlichkeitsarbeit:K. -F. Egetenmeier (® -28)

27

Berichte undVeröffentlichungendes Deutschen Forsch u ngsnetzes (DFN)Publications in DFN

Stand: Dezember 1986

Diese Bibliographie ist nach Sachge-bieten geordnet. Hierbei werden we-niger umfangreiche Veröffentlichun-gen allgemeinerer Art, Z. B. in Tages-und Wochenzeitungen nicht berück-sichtigt. Sie können als Presseechogesammelt angefordert werden beim"Verein zur Förderung eines Deut-sehen Forschungsnetzes - DFN-Ver-ein e.V.", Pariser Str. 44, 1000 Berlin15, ebenso wie die nachfolgend auf-geführten Veröffentlichungen:

A. Allgemeines

DFN-BroschüreDas Deutsche Forschungsnetz -was ist das?DFN INFO Nr. 1, Februar 86

Truöl, K.:An Application Oriented Develop-ment Based on OSI Standards,DFN-Bericht Nr. 29, Juli 85

Kommunikationsdienste im DFN- Produktübersicht -,

- 1. Protokollgeneration -,DFN-Bericht Nr. 27, Juni 85

Communication Services at DFN

Survey of ProductsFirst Protocol Generation,DFN-Bericht Nr. 34, June 85

Jessen, E.:

Das Deutsche Forschungsnetz- technische Grundlagen -,In: Der GMD - Spiegel, 2/84

Zander, K.:

Deutsches Forsch u ngsnetz- DFN - ein Rechnerverbund

für die Wissenschaft,In: Wissenschaftsmagazin der TUB,Heft 6/84

Lügger, J.:Deutsches Forschungsnetz - DFN -Objectives, Protocolsand Usage of Standards,In: IEEEInternational Conference onCommunications 1985Volume 1; Session 19

Jessen, E.:

Das Deutsche Forschungsnetz(DFN).In: Kommunikation in Verteilten

Systemen l;Informatik-Fachberichte Band 95

(Hrsg. ) Heger, D. u. a.,Springer Verlag Berlin, Heidelberg,New York, Tokio, S. 237; März 85

Santo, H., Tschichholz, M.:VERDIA Distributed Directory System forthe Deutsches Forschungsnetz,DFN-Bericht Nr. 42, July 86,DM 20,-

B. Untersuchungsberichte undHandbücher

Görgen, K., Passlow, H.,Vieberg, U, Vollmer, S.:DFN-Protokoll-Testlabor - eineÜbersicht über vorhandene und

geplante Testeinrichtungen im DFN,DFN-Bericht Nr. 19, Februar 85,DM5,-

L-Bauerfeld, W., Henken, G.,Ullmann, K.:

Zur Architektur undzurSpezifikationvon Kommunikationssystemen amBeispiel des Projektes "DeutschesForschungsnetz - DFN",Angewandte Informatik, S. 62, 2/85

Protokollhandbuch DFN Version II,DFN-Bericht Nr. 23, Mai 85, DM 30,-

Johannsen, W., Schulze, J.,Wolfinger. B.:Leistungsuntersuchung eines DFN-Gateways mit den WerkzeugenMAOS und MOSAIC,DFN-Bericht Nr. 36, Februar 86,DM 20-

C. Nachrichtenverbund

Henken, G., Schroeder, R.:Aufbau und Betrieb des

DFN-Message-Verbundes.In: Informatik-Fachberichte 127

(Hrsg. ) G. Hommel u. S. SchindlerSpringer-Verlag Berlin, Heidelberg,New York, London, Paris, Tokyo,S. 191; Oktober 1986.

Name

Straße

PLZ. /Ort

Das Message Handling System im DFN- Spezifikation und Realisierung.DFN-Bericht Nr. 21, März 85,DM 16,-(vergriffen)

The DFN Message Handling System- Specifications for Realization -DFN-Bericht Nr. 28, June 85, DM 20,-

Henken, G., Kaufmann, P.:

Konzept und Realisierung desDFN-Message-Verbundes.DFN-Bericht Nr. 30, August 85,DM 5, - (vergriffen)

Henken, G.. Kaufmann, P.:

Concept and Realization of theDFN Message Handling System,DFN-Bericht Nr. 35, August 85,DM7,-

D. Netzverbund

Zur Architektur von Kopplungenvon "Local Area Networks" und

"Wide Area Networks" im DFN,DFN-Bericht Nr. 3, Januar 84,DM16,-

Lokale Netze im Deutschen

Forschungsnetz,Beiträge zum Arbeitstreffen "LANim DFN" vom 4. -5. Juli 1985DFN-Bericht Nr. 43, Juli 85, DM 30-

L. -Bauerfeld, W.:ZurEinbettungvon lokalen Netzwerkenim Deutschen Forschungsnetz-DFN,In: Kommunikation in Verteilten

Systemen l;Informatik-Fachberichte Band 95,(Hrsg.) Heger, D. u. a.,Springer Verlag, Berlin, Heidelberg,New York, Tokio, S. 527; März 85

Heigert. J.:Arbeitsplatzrechner- Stand der Entwicklung und Ein-satzformen im Wissenschafts-

bereich -,DFN-Bericht Nr. 44, Juli 1986DM8,-

E. Graphik

Egloff, P.:Die Graphischen Protokolle imDeutschen Forschungsnetz - DFN,In: Kommunikation in Verteilten

Systemen l;Informatik-Fachberichte Band 95,(Hrsg. ) Heger, D. u. a.,Springer Verlag Berlin, Heidelberg,New York, Tokio, S. 543; März 85

Scheller, A., Smith, C.,DAPHNEDocument Application Processingin a Heterogenious NetworkEnvironment,

DFN-Bericht Nr. 41, April 86, DM 10,-

Report on the Hermes-meeting ofthe DFN Graphics WOrking Groupheld on November 11-15, 1985in Hermes, Franken, Föderal

ftepublic of Germany:Status Review and Future Plans for

Graphics, Modeling and DocumentServices in DFN

DFN-Bericht Nr. 46, July 1 986DM8,-

Standards der Graphik undModellierung und deren Verwendungim Deutschen Forschungsnetz- DFN -,- Tagungsband -,DFN-Bericht Nr. 49, September 86DM 25-

Bitte

freimachen

ANTWORTKARTE

Verein zur Förderung eines DeutschenForschungsnetzes e.V.-DFN-Verein-Pariser Straße 44

D-1000 Berlin 15

F. Betrieb des DFNTruöl, K.:Konzepte zum Betrieb des DFN,DFN-Bericht Nr. 14, September 84,DM7,-

Birkenbihl, K., Kröger, K.,Limburger, F.:Abnahme, Pflege und Wartungvon DFN-Produkten (Version 1.1),DFN-Bericht Nr. 18, Dezember 84,DM6,-

Truöl, K.:Das DFN-Betriebsmodell.DFN-Bericht Nr. 25, Mai 85, DM 4,-

Truöl, K.:Aufbau eines Deutschen

Forschungsnetzes - Stand derRealisierungen und Konzeptezum Betrieb -,Gl Fachgespräch über Rechen-Zentren Kassel,DFN-Bericht Nr. 26, Juni 85, DM 4,-

Bruns. T., Fetzer, E.:

Kosten und Leistungsrechnung inRechnernetzenDFN-Bericht Nr. 45, Juli 1986DM18-

G. Basisdienste des DFN

Study for the Implementation ofa File Transfer for the DFN based

on the ISO FTAM Standard,Prepared by DANET for DFN,DFN-Bericht Nr. 31, September 85,DM 10,-

Schroeder, R.:

DFN-CONCEPTS FOR FTAM-INTEGRATION,DFN-Bericht Nr. 32, NORDUNET-Conference 85, DM 5,-

Als Sonderdrucke können folgende Artikel kostenlos angefordert werden

Deker, U.:Das Deutsche Forschungsnetz,In: Bild der Wissenschaft, 4/85

Ziessow, D.:Chemische Analytik,In: DFN-Mitteilungen, Heft 2, 5/85

SNA PAD SystemVersion 1,User's Reference,DFN-Bericht Nr. 37, May 86, DM 6,-

SNA PAD SystemVersion 1,

Operator s Reference,DFN-Bericht Nr. 38, May 86, DM 6,-

SNA PAD SystemVersion 1,

Planning and Installation,DFN-Bericht Nr. 39, May 86, DM 6,-

SNAPAD SystemVersion 1,Messages,DFN-Bericht Nr. 40, May 86, DM 6,-

Bauerfeld, W. D., UNmann, K.:Anmerkungen zur Entwicklung und zum Be-trieb eines offenen Kommunikationsystems,In: DFN-Mitteilungen, Heft 4, 2/86

0 Bitte streichen Sie mich aus Ihrem Verteiler

0 Bitte schicken Sie mir kostenlos _ Exemplare der DFN-Broschüre.

0 Bitte senden Sie mir folgende Berichte und Schriften:

Veranstaltungen 15. -19. September 1986 International Conference on ComputerCommunication (ICCC)

München, Sheraton-Hotel

24. und 25. September 1986 Standards der Graphik und Model-lierung und deren Verwendungim Deutschen Forschungsnetz DFN

Einerseits wird den Teilnehmern einedetaillierte Einführung über die ver-schiedenen existierenden oder sichentwickelnden Standards auf den Ge-bieten der Graphischen Datenverarbei-tung, der Modell-Datenverarbeitungund der Dokumenten-Datenverarbei-tung gegeben, wobei auch auf die Be-Ziehungen der einzelnen Standardszueinander eingegangen wird. Anderer-seits wird die Verwendung dieser Stan-dards als Grundlage für die Entwicklungvon Kommunikationsprotokollen undAustauschformaten dargestellt, die denentsprechenden Diensten des Deut-sehen Forschungsnetzes DFN zugrun-de liegen. Zur praktischen Veranschau-lichung der bisher erreichten Arbeitser-gebnisse des DFN in diesem Bereichwerden im Rahmen von Demonstratio-nen das GKS-orientierte Kommunika-tionssystem, der Austausch von Bildern,die dezentrale Erzeugung von Text- undGraphikinformation (Dokumente) sowiederen Transfer und der Austausch vonCAD-Modellen gezeigt.

Das Tutorium findet an der TechnischenUniversität Berlin, Straße des 17. Juni135, 1000 Berlin 12, Hauptgebäude,1. GG., Raum H 1012, statt.

Ansprechpartner:Frau G. Maiß,Zentrale Projektleitung,Tel. : (030) 884299-37

21. -25. September 1987 7th International Conference on Dis-tributed Computing Systems

Berlin

"Call for Papers": 1. Januar 1987

Ansprechpartner:Dr. R. Popescu-Zeletin, Hahn-Meitner-Institut für Kernforschung Berlin GmbHTel. : (030)8009-2594