Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.02.1990 - 

PCs unter MS-DOS wurden vorrangig behandelt

Beispielhafte PC-Anbindungen im Deutschen Forschungsnetz *Thomas Baumgarten, DFN-Verein, Zentrale Projektleitung, Berlin

In Forschung und Lehre sind PCs in den letzten Jahren an vielen Arbeitsplätzen von Wissenschaftlern und Studenten zu unentbehrlichen Werkzeugen geworden. Damit ist ein großer Bedarf an Rechnerkommunikation von PCs untereinander oder von PCs zu Großrechnern entstanden, ein Bedarf, wie er wegen seiner unterschiedlichen Ausprägungen auch für viele Kommerzanwendungen maßgeblich ist.

Klar ist, daß dieser Bedarf in der Regel wegen der Vielfalt der unterschiedlichen Systeme langfristig nur mit standardisierten Mitteln der Kommunikation befriedigt werden kann. Die Heterogenität der Rechner zeigt sich schon in den unterschiedlichen, wesentlichen PC-Gruppierungen:

- IBM-kompatible PCs mit Betriebssystem MS-DOS (PC-DOS),

- IBM-kompatible PCs mit Betriebssystem OS/2 (PS/2),

- Macintosh PCs,

- PCs mit Betriebssystem UNIX oder Vergleichbarem.

Personal Computer oder Workstations mit UNIX-ähnlichem Betriebssystem, wie zum Beispiel UNIX-System V oder Xenix, werden in diesem Artikel nicht berücksichtigt, da für fast alle verbreiteten Systeme Implementierungen von OSI- beziehungsweise DFN-Diensten existieren oder derzeit entwickelt werden.

Bedarf läßt sich auch anhand der benötigten Dienste ermitteln. Dieser erstreckt sich über alle Basisdienste des DFN:

- Dialog (PAD, romote login) nach CCITT X.3/X.28/X.29,

- Filetransfer, entweder DFN-FT oder OSI-FTAM,

- Remote Job Entry (DFN-RJE),

- Electronic Mail nach CCITT X.400.

Entwicklungen im Hinblick auf ihre Portierbarkeit

Bei allen DFN-Entwicklungen beziehungsweise Vorhaben wird die Ausnutzung bestehender Vernetzungen nach Möglichkeit unterstützt. Unterschieden werden Stand-alone-PCs, auf denen alle Dienste beziehungsweise Protokollschichten verfügbar sind, und LAN-integrierte PCs, bei denen eine Vernetzung, zum Beispiel in einem Ethernet-LAN, ausgenutzt werden kann, um einzelne Funktionen auf einem speziellen PC (Server) für alle anderen an die lokale Vernetzung angeschlossenen PCs zur Verfügung zu stellen. Eine solche Funktion kann beispielsweise der Netzwerkdienst (X.25) sein.

Folgende Vernetzungstechniken sollen unterstützt werden:

- X.25 über X.21 für Stand-alone-PCs und Kommunikations-Server für LAN-integrierte PCs,

- lokale Vernetzungen mit NetBIOS-Unterstützung (Token Ring, fast alle Ethernets-, Arcnet-LANs) für LAN-integrierte PCs,

- X.25 über ISDN (X.31) für Stand-alone-PCs und Kommunikations-Server für LAN-integrierte PCs,

- OSI-LAN mit CONS,

- OSI-LAN mit CLNS,

- Btx.

In den DFN-Vorhaben werden PCs mit Betriebssystemen MS-DOS vorrangig behandelt. Alle Entwicklungen in diesem Bereich werden im Hinblick auf eine gute Portierbarkeit zu OS/2 durchgeführt.

Kurzfristig wird diese Portierung nicht erfolgen, da speziell in der Wissenschaft OS/2 noch nicht die Verbreitung gefunden hat, die Entwicklungen rechtfertigen. Als Übergangslösung können alle unter MS/DOS ablauffähigen Kommunikationsdienste auch in OS/2-Umgebungen genutzt werden, auch wenn nicht alle Eigenschaften, wie zum Beispiel Multitasking, einsetzbar sind.

Die Integration von Macintosh-Systemen wird der DFN-Verein in Kooperation mit Apple durchführen.

DFN-Entwicklungen ergänzen Marktspektrum

Die Vernetzung über Btx wird in der ersten Stufe nur den Dialogdienst ermöglichen. Abhängig von der Akzeptanz und den Betriebserfahrungen aus einem Pilotversuch mit dieser Technik werden gegebenenfalls weitere Dienste entwickelt werden.

Entwicklungen und Vorhaben des DFN-Vereins sollen dann einsetzen, wenn für ein bestimmtes Ziel keine beziehungsweise nicht ausreichend Produkte auf dem Markt verfügbar sind. Dies betrifft die Anwendungen:

- FTAM

- RJE,

- X.400 m.E., und Netzzugangstechniken:

- Btx,

- ISDN.

ln der Konfiguration X.25 über X.21 für Stand-alone-PCS ergibt sich die traditionelle Protokollschicht im DFN: (siehe Abbildung 1).

In der Konfiguration X.25 über X.21 für Kommunikations-Server wird eine lokale Vernetzung verwendet, in der NetBlOS unterstützt wird. Zahlreiche LAN-Anbieter bieten diesen Dienst - zumindest emuliert an.

Die X.25 Schnittstelle ist mit Hilfe des NetBIOS-Dienstes im LAN verteilt, also auf alle PCs zur Verfügung gestellt. Für die Nutzung von OSI/DFN-Diensten ist dieser Mechanismus eines Kommunikations-Servers vollkommen transparent. Die Kommunikationsserver stehen auch in dieser Konfiguration für alle anderen Anwendungen zur Verfügung, unterliegt auch keinerlei Einschränkung hinsichtlich seiner weiteren Nutzung (siehe Abbildung 2).

X.25-Zugang über ISDN transparent

Der Zugang zu einem X.25 Netz über ISDN (Minimalintegration nach X.31) ist für die Anwender der Dienste transparent, obwohl zwei Wahlvorgänge (ISDN-Wahl und X.25) durchgeführt werden müssen (siehe Abbildung 3, Seite 64).

Bei Nutzung einer ISDN-Nebenstellenanlage (Abb. 3) ist die Kommunikation von daran angeschlossenen Rechnern ohne den Weg über ein X.25-Netz möglich.

OSI- beziehungsweise DFN-Protokolle können auch in lokalen Netzen eingesetzt werden ("OSI-LAN"). Eine von zwei Alternativen hierzu ist die Verwendung von X.25 als

verbindungsorientiertem Netzwerkdienst ("CONS"). Für den Einsatz von Ethernet (IS 8802-3) wird dies zum Beispiel durch die Norm ENV 41103 festgelegt (Abb. 4). Einer der vielen Vorteile dieser Konfiguration ist der Einsatz einer einheitlichen Netzwerkschicht sowohl im LAN als auch im WAN. Für den LAN-WAN-Übergang ist ein Gateway zur Umsetzung der unteren Schichten erforderlich (siehe Abbildung 4, Seite 64).

Verbindungsloser NW-Dienst aIs OSI-Variante

Der verbindungslose Netzwerkdienst (CLNS) stellt die zweite OSl-Variante dar. Hier wird über dem IP (Internet Protocol) der Transportdienst Klasse 4 (TP4) eingesetzt (siehe Abbildung 5, Seite 64).

Um aus einer lokalen TP4-Umgebung mit Rechnern im CONS-Bereich kommunizieren zu können, ist ein Gateway auf der OSI-Ebene 4 notwendig. Der vorher beschriebene Dialogdienst kann hier nicht eingesetzt werden, da er direkt auf X.25 aufsetzt und nicht auf einer Transportschnittstelle. In dieser Konfiguration muß auf die Verfügbarkeit des OSI-Dialogdienstes VT (Virtual Terminal) gewartet werden.

Ein Btx-Anwender hat in diesem Szenario die Möglichkeit, im Btx-Dialog eine bestimmte Btx-Seite auszuwählen, hinter der ein externer Rechner mit der Anwendung PAD steht. Auf dieser Seite können PAD-Kommandos eingegeben (zum Beispiel call) und damit ein Dialog nach X.31/.28/X.29 aufgebaut werden.

Zugangstechnik via Btx sehr preiswert

Diese Zugangstechnik kann für den Btx-Anwender sehr preiswert sein, wenn der Betreiber des externen Rechners die bei ihm entstehenden Kosten (zum Beispiel Btx- und entstehende DATEX-P-Volumenkosten) trägt.

Der Dialog-Zugang kann von jedem Btx-Teilnehmergerät genutzt werden, eine spezielle Hard- oder Software ist nicht erforderlich. Damit wird der Einsatz von Btx-Modems, anderen Modems und Akustikkopplern möglich. Soft- und Hardwaredecoder auf dem PC sind einsetzbar. Es ist sogar ein Zugang über die Gastkennung des Btx denkbar, sofern der Betreiber des Externen Rechners mit dem PAD diesen Btx-Teilnehmer autorisiert und die angezeigten Btx Seiten kostenlos zur Verfügung stellt.

Vom Hersteller dieses "Btx-PAD" wird eine spezielle Decoder-Software angeboten, welche den Btx-Dialog für den Nutzer vollkommen transparent macht. Die Beschränkungen, bedingt durch die Größe der Btx-Seiten (40 Zeichen pro Zeile), entfallen dabei, der Umbruch breiterer Zeilen findet nicht statt.

Zugangskontrollmechanismen sind auf dem Externen Rechner einsetzbar, mit denen sogar zum Beispiel einzelne DTE-Adressen für Nutzer individuell gesperrt oder zugelassen werden können.

Das vom DFN-Verein erarbeitete Konzept für PCs mit dem Betriebssystem MS/DOS sieht eine Mischung von Herstellerprodukten und Diensten, die vom DFN-Verein zur Verfügung gestellt werden, vor.

Eine X.25-Steckkarte mit zugehöriger Software - wie zum Beispiel triple X-Dialog mit Terminal-Emulationen - wird vom DFN-Verein nicht angeboten werden. Hierzu existieren auf dem Markt schon sehr viele Produkte, die zum Teil auch in einem lokalen Netzwerk (LAN) oder in einer ISDN-Umgebung einsetzbar sind. Ist ein PC mit einer derartigen Karte und Software ausgestattet oder hat über ein LAN Zugriff auf eine Karte, steht auf dem PC der X.25-Netzwerkdienst zur Verfügung. Die Syntax der Schnittstelle ist abhängig vom Hersteller des Produktes und unterliegt keiner Norm oder Empfehlung.

Der aktive Dialogdienst, also die Nutzung des PCs als Terminal an einem entfernten Rechner, wird nicht vom DFN-Verein angeboten werden, da dieser bei allen Anbietern von X.25-Produkten in der Produktpalette enthalten ist.

Die Funktion eines PCs als Rechner, zu dem ein entfernter Nutzer einen Dialogzugriff ausüben kann, wird vom DFN Verein wegen des geringen Bedarfes ebenfalls nicht verfolgt. Sinn ergibt der passive Dialog bei einigen organisatorischen Konfigurationen, in denen eine Wartung des PCs von einer zentralen Stelle wahrgenommen wird. Es gibt darum auch einen Anbieter auf dem deutschen Markt, der den passiven Dialog zumindest in Aussicht gestellt hat.

OSI-FTAM wird den DFN-FT ersetzen

Der derzeit noch am weitesten verbreitete Filetransfer im deutschen Wissenschaftsbereich ist der DFN-Filetransfer (DFN-FT), also der auf DFN-Empfehlungen Basierende. Zum Zeitpunkt der Festlegung des DFN-FT existierte noch keine stabile

OSI-Norm, was inzwischen nicht mehr der Fall ist. Für die OSI-Norm FTAM (File-Transfer,

-Access und Management) sind auch schon einige Produkte verfügbar, und sehr viele namhafte Hersteller haben FTAM-Produkte angekündigt. In der zweiten Protokollgeneration des DFN ersetzt der OSI-FTAM den DFN-FT. Aus diesen Gründen wurde auf eine Entwicklung des DFN-FT für MS/DOS-PCs verzichtet, der DFN-Verein wird eine Sammellizenz für den FTAM-Dienst auf MS/DOS erwerben.

Der aktive FTAM-Dienst (Initiator) des DFN nach ISO IS 8571, ENV 41 204 (A/lll) unter MS/DOS wird die Dokumententypen FTAM-1 (unstructured text file) und FTAM-3 (unstructured binary file) unterstützen. Verfügbar ist die Implementierung ca. ab dem 2. Quartal 1990. Der Transportdienst ist bei der vom DFN zur Verfügung gestellten Software enthalten.

Die Schnittstelle zwischen Transport- und Sessiondienst ist der von X-Open spezifizierte funktionale Standard XTl. Als (X.25) Schnittstelle zwischen Transport- und Netzwerkdienst werden im ersten Entwicklungsschritt drei verschiedene herstellerspezifische Schnittstellen unterstützt werden.

Die passive Seite des FTAM-Dienstes

Die passive Seite des FTAM-Dienstes (Responder) kann bei Bedarf zur Verfügung gestellt werden. Damit kann zum Beispiel in einem LAN ein FTAM-Fileserver eingesetzt werden, was gerade dann sinnvoll ist, wenn auch andere, nicht im LAN eingebundene Fileserver mit FTAM genutzt werden sollen, da dann ein einheitlicher Dienst für den lokalen und den nicht lokalen Transfer genutzt werden kann.

Beim Einsatz eines MS/DOS FTAM-Fileservers im LAN ist es notwendig, den PC eindeutig adressieren zu können (DTE- oder NSAP-Adresse). Dies ist der Fall, wenn im LAN direkt OSI-Protokolle eingesetzt werden. In der NatBlOS-Konfiguration für LANs ist der Einsatz von passiven Diensten wie dem FTAM-Responder derzeit schlecht möglich, da fast alle auf dem Markt befindlichen X.25-Karten mit LAN-Unterstützung einzelne PCs im LAN bei einem Anruf von außen nicht adressieren können. Hier sind in Kürze leistungsfähigere Produkte zu erwarten.

Den Einsatz von X.25 für Ethernets nach IEEE 802.3 beschreibt der europäische Normenvorschlag (ENV) 41103, für Token-Ring-LANs nach IEEE 802.5 der ENV 41108. Einige Anbieter von X.25-Steckkarten haben die Unterstützung von X.25-Version von 1984 angekündigt.

Die aktive Seite des Remote Job Entry

Die aktive Seite des DFN-Dienstes Remote Job Entry umfaßt das Versenden eines Auftrages und den Empfang des Ergebnisses. Es wird derselbe Transportdienst wie beim FTAM verwendet, also werden auch die oben genannten Schnittstellen unterstützt. Beim Warten auf das Ergebnis des Jobs ist der PC blockiert für andere Anwendungen (fehlende Multitasking-Eigenschaft).

Die aktive Seite des Remote Job Entry-Dienstes wird wie der FTAM im zweiten Quartal 1990 zur Verfügung stehen. Die passive Seite, also das Empfangen und Abarbeiten des Auftrages sowie das Verschicken des Ergebnisses wird wegen des geringen Bedarfes im DFN nicht entwickelt werden. Die Idee des passiven RJE auf einem PC mutet zunächst seltsam an, aber nur, wenn man als Sinn des RJE die Nutzung entfernter Rechenkapazität versteht. Es ist jedoch zum Beispiel auch denkbar, Informationen in entfernten Datenbanken mit Hilfe des RJE zugänglich zu machen, und dies kann auch auf einem PC sinnvoll sein.

MHS-Systeme setzen LAN voraus

Message Handling Systeme nach CCITT X.400 ff sind für PCs bereits verfügbar. Alle Systeme setzen jedoch ein lokales Netzwerk voraus, in dem ein PC ausschließlich als Mail- Server eingesetzt wird. Für einen einzelnen PC ist MHS auch in absehbarer Zeit nicht zu erwarten, da die Komplexität und der Umfang der Systeme den Einsatz auf einem (MS/DOS) PC unmöglich machen. Der DFN-Verein wird jedoch die Möglichkeiten des Einsatzes eines sogenannten "Remote User Agents" weiterverfolgen, diesen aber nicht in dem ersten Entwicklungsschritt anbieten können. Ein solcher Remote UA beinhaltet nur einen Teil des gesamten X.100-Systems, nämlich die Datenhaltung und -erstellung der Nachrichten lokal auf dem PC.

Das Versenden mit allen notwendigen Routinginformationen und ähnlichem geschieht durch einen entfernten Message Transfer Agent.

Dienste-Portierung auf die X.25-Schnittstelle

Ein DFN-Vorhaben beschäftigt sich mit der Implementierung von X.25 über ISDN und der Portierung der oben beschriebenen Dienste auf diese X.25-Schnittstelle. Damit kann ISDN als Zubringer zu einem X.25-Netz genutzt werden, wie es in der "Minimalintegration" nach X.31 beschrieben ist. Der Weg über ein X.25-Netz ist nicht zwingend, es kann auch nur ISDN verwendet werden, sofern der Kommunikationspartner über ISDN erreichbar ist und den entsprechenden passiven Dienst bietet. Es sind bei der Nutzung von ISDN zwei Szenarien denkbar. Entweder erhält jeder PC einen ISDN-Anschluß und damit zwingend auch eine ISDN-Steckkarte, wodurch eine zusätzliche LAN-Vernetzung nicht mehr erforderlich ist, oder in einem LAN wird ein Kommunikationsserver eingerichtet, der über einen ISDN-Anschluß und -Steckkarte verfügt und den Server über NetBIOS-Kopplungen zugänglich macht. Damit wäre ein direkter Anschluß des LAN an ein X.25-Netz (Untervermittlung, Datex-P oder Wissenschaftsnetz) nicht erforderlich.

Auch für billigere Endgeräte als PCs

Ein weiteres Vorhaben des DFN beschäftigt sich mit dem einfachen (ISDN-)

Dialogzugang zu einem Rechner (Host). Auf diesem Rechner können dann zum Beispiel OSI- beziehungsweise DFN-Dienste und/oder ein Konferenzsystem installiert sein. In dieser Konfiguration ist es möglich, auch billigere Endgeräte als einen PC zu nutzen, zum Beispiel kann ein Terminal über V.24 an ein ISDN-Telefon angeschlossen sein.

Übungsbetrieb mit Heimarbeitsplätzen

Ein anderes DFN-Vorhaben dient der Piloterprobung des Dialogzuganges (PAD nach X.3/X.28/X.29) über Btx. Dieses Modell ist besonders gut für die Abwicklung eines

universitären Übungsbetriebes von Heimarbeitsplätzen von Studentinnen und

Wissenschaftlerinnen geeignet. Die Einrichtung eines Btx-Anschlusses und die monatliche Grundgebühr sind sehr preiswert, die Übertragung ist bis zum Btx-Endgerät protokollgesichert, und laufende Kosten (Datenvolumen) können vom Betreiber des Externen Rechners übernommen werden. Weiterhin ist die Identifizierung des Teilnehmers schon durch die Btx-Kennung möglich.

An dieser Stelle drängt sich die Frage auf, warum der Datex-P20-Dienst der Deutschen Bundespost nicht empfohlen wird. Gegen dessen Nutzung spricht

in diesem speziellen Szenarium im wesentlichen das Problem der Kostenübernahme. Die Kostenübernahme durch den Übungsrechner bei (allen) ankommenden Rufen ist im Datex-P möglich, jedoch müssen alle Rufe entgegengenommen werden, also werden Hacker-Angriffe auch noch von der Universität bezahlt. Ist keine Kostenübernahme bei ankommenden Rufen vorgesehen, müssen folglich die Kosten für die genutzten P20-NUls (Network User Identifications) übernommen werden. Dies ist wegen eines möglichen Mißbrauches praktisch unmöglich. Werden NUls der Universität verwendet, kann niemand einen Mißbrauch verhindern, da die volle X.25-Konnektivität zur Verfügung steht und eine Kontrolle nicht möglich ist. Das gleiche gilt, wenn die NUI eines Studenten verwendet wird. Hier dürfte es schwerfallen, einem Studenten seine Postrechnung zu zahlen, da wiederum keine Nachweise über die Nutzung möglich sind.

Insgesamt entstehen bei dem Btx-Zugang Kosten, die in der Größenordnung vergleichbar den P20-Kosten sind, aber die Subventionierung des Übungsbetriebes wird hier erst möglich. Als Alternative bliebe nur ein Datex-P-Hauptanschluß, der aber aus Kostengründen für einen studentischen Heimarbeitsplatz nicht in Betracht kommt. Der Nachteil der Btx-Lösung für den skizzierten Übungsbetrieb liegt in den hohen

Beschaffungskosten des Externen Rechners.

Das oben beschriebene Konzept ist zunächst für IBM-kompatible PCs mit dem Betriebssystem MS/DOS (PC/DOS) ausgelegt. Entwicklungen, Anpassungen oder Portierungen für das andere, im Bereich der IBM-Kompatiblen wichtige Betriebssystem OS/2 sind nicht geplant. Dennoch können PCs mit OS/2 im DFN eingesetzt werden, denn OS/2 bietet die Möglichkeit, MS/DOS-Programme ablaufen zu lassen. Solche Programme können dann auch Kommunikationsprogramme sein, die eine Anbindung eines OS/2-PCs an das DFN ermöglichen. Das Multitasking von OS/2 wird in diesem Lösungsansatz nicht unterstützt; hierzu wäre eine Portierung der Programme erforderlich. X.25-Karten für OS/2 auch mit Unterstützung des Microchannels sind schon verfügbar. +

Obiger Beitrag ist eine aktualisierte Fassung eines zweiteiligen Artikels aus den DFN-Mitteilungen Nr.17 und 18 vorigen Jahres.