Rechnernetze: Entwurf und Realisierung 9783111346175, 9783110072907

Citation preview

de Gruyter Lehrbuch Schnupp • Rechnernetze

Peter Schnupp

Rechner netze Entwurf und Realisierung

w DE

_G Walter de Gruyter • Berlin • New York 1978

Dr. rer. nat. Peter Schnupp, Mitinhaber der Firma SOFTLAB (Softwarelabor für Systementwicklung und EDVAnwendung) in München, Lehrbeauftragter für Systemprogrammierung an der Hochschule für Sozial- und Wirtschaftswissenschaften in Linz Das Buch enthält 73 Abbildungen und 4 Tabellen

CIP-Kurztitelaufnahme der Deutschen Bibliothek Schnupp, Peter Rechnernetze : Entwurf u. Realisierung. - 1. Aufl. — Berlin, New York : de Gruyter 1978. (de-Gruyter-Lehrbuch) ISBN 3-11-007290-4 © Copyright 1978 by Walter de Gruyter & Co., vormals G. J. Göschen'sche Verlagshandlung, J. Guttentag, Verlagsbuchhandlung Georg Reimer, Karl J. Trübner, Veit & Comp., Berlin 30. Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Photokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Printed in Germany. Satz: IBM-Composer, Walter de Gruyter, Berlin. Druck: Karl Gerike, Berlin. Bindearbeiten: Lüderitz & Bauer Buchgewerbe GmbH, Berlin.

Vorwort

Dieses Buch entstand aus einem selbst empfundenen Mangel: dem unerfüllten Wunsch nach einer Einfuhrung in das Gebiet der Rechnernetze und der Datenverbundsysteme, welche auf die Bedürfnisse und Vorkenntnisse des SoftwareEntwicklers abgestimmt ist. Er ist es gewohnt, ein EDV-System „top down" ausgehend von der Benutzerschnittstelle zu verstehen und zu planen. Die Mehrzahl der vorliegenden Publikationen beginnt die Darstellung jedoch mit der Hardware und den sie verbindenden Leitungen — ein Ansatz, welcher dem Nachrichtentechniker weit mehr liegt als dem Informatiker. SOFTLAB gründete deshalb einen Arbeitskreis, der im Rahmen einer Reihe von Seminaren die Struktur typischer Rechnernetze „von oben nach unten" analysierte. Das Ziel war, eine ähnlich geschlossene Vorstellung über den Aufbau und die wesentlichsten Entwurfsprinzipien eines Netzes zu erarbeiten, wie sie ein erfahrener Software-Planer auch für einen Compiler oder ein Betriebssystem hat. Ausgangspunkt hierfür waren einerseits die wichtigsten Veröffentlichungen, zum anderen aber auch die Erfahrungen, welche bei der Bearbeitung einiger größerer Netzprojekte gewonnen worden waren. Aus der Aufbereitung des so erhaltenen Materials entstand das vorliegende Buch. Es ist vorwiegend für den praktisch arbeitenden Informatiker bestimmt und bemüht sich, die notwendigen theoretischen Grundlagen soweit anzudiskutieren, daß eine Vertiefung an Hand der Literatur keine allzugroßen Schwierigkeiten mehr bieten sollte. Das Buch wendet sich also vor allem an Software-Spezialisten, erfahrene Programmierer und fortgeschrittene Studenten der Informatik. Auch als Lehrbuch für eine Einführungsvorliesung in dieses Gebiet sollte es nützlich sein. Wenn es darüber hinaus Nachrichtentechnikern und Hardware-Entwicklern hilft, die Probleme und Denkweise der Software-Planer besser zu verstehen, und damit einen Beitrag zur Verbesserung des unbedingt nötigen Dialogs zwischen diesen beiden Partnern einer Netzentwicklung leistet, würde der Verfasser sich freuen. München, im November 1977

Peter Schnupp

Inhalt

Einführung

9

1. Grundbegriffe und Grundstrukturen 1.1 Kommunikation zwischen Rechnern 1.2 Aufgaben und Aufbau typischer Rechnernetze 1.3 Physikalische und logische Struktur von Rechnernetzen 1.4 Benutzeranforderungen 1.5 Realisierungsprobleme

11 11 16 21 26 29

2. Die 2.1 2.2 2.3 2.4 2.5

Benutzerschnittstellen Die nichtlokalisierte Maschine Bedienungssprache und Terminals Die verteilte Datenbasis Zugriffsverfahren Das Netz-Betriebssystem

32 32 33 37 42 45

3. Das 3.1 3.2 3.3 3.4

verteilte System Betriebsmittel-und Prozeßverwaltung Betriebsmitteladressierung im Netz Adressierung in der SNA Ports

48 51 51 53 57

4. Netzwerkmaschinen und Netzzustände 4.1 Nachrichten und Netzwerkmaschinen 4.2 Steuerinformationen und Zustandsiibergänge 4.3 Untersysteme und ihre Zustände 4.4 Grundforderungen an Protokolle im Netz

63 63 67 70 73

5. Protokolle 5.1 Die Protokollhierarchie im ARPA-Netz 5.2 Die Protokolle des Datenübertragungs-Netzes 5.3 Höhere Protokollebenen 5.4 Grundregeln für die Protokollplanung 5.5 Die Realisierung eines Protokolls

75 75 75 79 82 83

6. Die 6.1 6.2 6.3 6.4 6.5

86 86 90 92 94 96

Netzschnittstelle und die Flußsteuerung Das Netz-Kommunikationsprogramm Netzüberlastung und Betriebsmittelverwaltungs-Strategien Grundverfahren der Flußsteuerung Globale Flußsteuerungen auf Verbindungsbasis Globale Flußsteuerungen auf Nachrichten oder -Paketbasis

8

Inhalt

7. Netzstrukturen und Laufwege 7.1 Netz-Topologien 7.2 Durchschaltungen, virtuelle Verbindungen und Datagramme 7.3 Pakete 7.4 Wegwahl 7.5 Blockierungen im Netz

99 99 102 104 108 114

8. Leitungen und Knotenrechner 8.1 Struktur der IMP-Software 8.2 Übertragungsleitungen 8.3 Modulation und Leitungssteuerung 8.4 Ökonomie der Leitungsauslastung 8.5 Lokale Belastungen und globale Übertragungseigenschaften 8.6 Kanalbelastungs-Begrenzung

118 118 121 123 125 127 129

....

9. Auslegung und Optimierung eines Netzes 9.1 Der Verwaltungsaufwand in den Protokollebenen 9.2 Optimierungsgesichtspunkte 9.3 Prioritäten fur Nachrichten und Pakete 9.4 Fehlerbehandlung und Flußsteuerung 9.5 Sende- und Empfangsfenster

131 131 135 139 140 143

10. Realisierung und Betrieb eines Rechnernetzes 10.1 Spezifikation 10.2 Planung 10.3 Implementierung und Weiterentwicklung 10.4 Betriebsüberwachung und Netzsteuerung 10.5 Der Verbund von Netzen

146 146 148 151 154 157

Anhang: Datennetz-Terminologie Literatur Sachregister

162 179 187

Einführung

Spezifikation, Planung und Implementierung von Rechnerverbundnetzen werden noch weitgehend „Bottom Up" betrieben, von der physikalischen Realisierung der Übertragungsleitungen und der Netzknoten über den Anschluß der Terminals und Teilnehmerrechner (Hosts) bis zur Benutzerschnittstelle. Dies ist verständlich. Schließlich ist der Grund für den Aufbau eines Netzes die räumliche Verteilung der Benutzer und der Betriebsmittel, der Rechner und Datenbestände, und damit die notwendige Datenübertragung. Trotzdem — die Neue Softwaretechnologie bevorzugt die Top Down-Entwicklung. Auch für eine Netzplanung ist dies ein sinnvoller Ansatz, wenn auch die Berücksichtigung der übertragungstechnischen, physikalischen Gegebenheiten und Einschränkungen hier bei jedem Entwicklungsschritt von noch größerer Bedeutung sein wird als auf fast allen anderen Gebieten der Datenverarbeitung. Das Ziel dieses Buches ist es, die innere Logik und die sachlichen Alternativen eines Netzentwurfs von „oben", den Benutzern, nach „unten", den physikalischen Komponenten, zu verfolgen. Sicher wird wohl kaum ein Rechnernetz genau in dieser Reihenfolge entstehen. Aber eine gute Planung wird immer so aussehen, als sei dies der Fall gewesen. Wichtig für das Verständnis eines Netzentwurfs ist — wie bei jeder Software — die Trennung der logischen Konzepte von ihrer physikalischen Realisierung. In den Abbildungen dieses Buches soll dem Leser hierbei eine grundsätzliche Unterscheidung helfen: — logische Einheiten (z. B. die abstrakte „Netwerkmaschine) werden als runde oder ovale Symbole, - physikalische Einheiten (z. B. ein Host- oder IMP-Rechner) als eckige Symbole dargestellt. Im übrigen versuchte der Autor, eine gut lesbare und verständliche Einfuhrung in diesen schwierigen und bis jetzt noch nicht in allen Einzelheiten verbindlich geklärten Bereich der Datenverarbeitung zu verfassen. Und für einfuhrende Schriften glaubt er mehr an die deutsche Sprache und graphische Darstellungen als an Formeln und Algorithmen. Deshalb wurde weitgehend auf Formalismen verzichtet - über die Literaturzitate kann der Leser sie leicht im Direktzugriff erreichen. Das Ziel, möglichst viel Information in deutscher Prosa zu vermitteln, drohte an einer unvorhergesehenen Schwierigkeit zu scheitern. Für eine Reihe von Begriffen (z. B. „Gateway") kennt der Verfasser kein deutsches Wort, für andere (z. B. „Netz-Kommunikationsprogramm") mehr als eines. Deshalb wurde in diesen Fällen willkürlich ein Ausdruck ausgewählt und vor Anglismen nicht zurückge-

10

Einfuhrung

schreckt — die im Anhang gegebene „Datennetz-Terminologie" hilft vielleicht, den in diesem jungen Zweig der Datenverarbeitung leider vorhandenen Begriffswirrwarr zu entflechten. Allerdings sind oft die dort aufgeführten Synonyme nur näherungsweise identisch: die „Transportstation" im CYCLADES-Netz ist nicht ganz dasselbe wie das „Network Control Programm" der ARPA-Entwickler. In derartigen Fällen wird der Leser gebeten, den vom Autor gewählten Ausdruck („Netz-Kommunikationsprogramm") als Bezeichnung für den „Mittelwert" über diese ähnlichen Begriffe zu verstehen und — wie der Verfasser — auf eine zukünftige Standardisierung der Konzepte und Bezeichnungen zu hoffen. Sollte es trotzdem gelungen sein, eine einigermaßen konsistente Darstellung des Themas zu geben, so ist dies nicht zuletzt der Verdienst von Frau Roswitha Eikel und Frau Helga Wittmann. Sie haben das Manuskript mehrmals umgeschrieben und „schrittweise verfeinert". Für ihre Mühe möchte ich ihnen an dieser Stelle herzlich danken.

1. Grundbegriffe und Grundstrukturen

1.1 Kommunikation zwischen Rechnern Voneinander unabhängige Rechner können auf die verschiedensten Weisen gekoppelt werden. Abb. 1.1-1 skizziert die hierfür am häufigsten eingesetzten Methoden. Das Hauptthema dieses Buches ist die in Abb. 1.1-1 d gezeigte Kommunikation über Datenübertragungsleitungen — nicht nur zwischen zwei, sondern auch zwischen grundsätzlich unbeschränkt vielen, weitgehend voneinander unabhängigen EDV-Anlagen, einem Rechnerverbund oder Rechnernetz. Der Grund für das Zwischenschalten einer Telex-, Datex-, Telefon- oder sonstigen Ubertragungsleitung ist hierbei meist eine räumliche Entfernung von mehr als einigen 100 m zwischen den einzelnen teilnehmenden Rechnern, welche die übrigen in Abb. 1.1-1 dargestellten Kopplungsmöglichkeiten aus technischen Gründen ausschließt: — einen gemeinschaftlich benutzten Arbeitsspeicher, in welchem ein oder mehrere Kommunikationsbereiche von den beteiligten Rechnern zur Ablage und zum Empfang von Nachrichten verwendet werden, — eine Kopplung der E/A-Kanäle der Rechner, wobei jeder Rechner den anderen als „Externspeicher" ansieht, — einen gemeinsamen Externspeicher, der über einen Mehrkanalschalter rechnergesteuert mal der einen, mal der anderen Anlage zugeordnet wird. Viele der Probleme einer Rechnerkopplung sind jedoch unabhängig von ihrer technischen Realisierung. Dies gilt vor allem für die softwaretechnischen Fragen der Kommunikation zwischen den in den einzelnen Rechnern ablaufenden Prozesse und der Protokolle zur Verbindungsaufnahme, zur Sicherung des Nachrichtenverkehrs und zur Fehlererkennung und -behebung bei einem derartigen Dialog zwischen Rechnern. Welches Verfahren gewählt wird, bestimmen technische, ökonomische und einsatzorientierte Erwägungen. Hierbei ist die — unvermeidliche oder gewünschte - räumliche Trennung zwischen den beteiligten Rechnern sowie den gegebenenfalls zu ihrer Bedienung dienenden Terminals nur eines der Kriterien, freilich oft auch das ausschlaggebende. Der Wunsch, EDV-Anlagen miteinander kommunizieren zu lassen, hat meist einen oder mehrere der folgenden Gründe: Eine Spezialisierung für bestimmte Dienstleistungen läßt es oft sinnvoll erscheinen, für unterschiedliche Arbeiten auch unterschiedliche Rechner einzusetzen. Erst ihr Zusammenwirken bietet dem Benutzer das volle Leistungsspektrum. So

12

1. Grundbegriffe und Grundstrukturen

( b ) Kanalkopplung

©

Externspeicherkopplung

(T) Kopplung über eine Datenübertragungsleitung Abb. 1.1-1 Kopplung zwischen unabhängigen Rechnern

können für Meß- und Steuerungsaufgaben in einem Produktionsbetrieb oder einem Krankenhaus Prozeßrechner die zweckmäßige Hardware sein, während für die langfristige Haltung und Auswertung der umfangreichen Datenbestände kommerzielle Großrechner eingesetzt werden [RAIM76].

1.1 Kommunikation zwischen Rechnern

13

In einem weitverzweigten Filialunternehmen oder einer öffentlichen Verwaltung werden für die Erfassung, Prüfung und Bearbeitung lokal relevanter Daten kleine Erfassungsrechner gebraucht, für die globale Auswertung der Datenbestände jedoch größere Anlagen in den Zentralen. Eine EDV-Installation für wissenschaftlich-technische Forschungsaufgaben verwendet für die „normale" Datenhaltung und -Verarbeitung auch „normale" Großrechenanlagen, für besondere Aufgaben wie die schnelle Durchfuhrung von Matrixoperationen benötigt sie jedoch vielleicht mit ihnen zusammenarbeitende Spezialmaschinen wie Feld- und „Pipeline"-Rechner. Eine der frühesten Spezialisierungen schließlich war die hardwaremäßige Trennung von Ein-/Ausgabe und Verarbeitungsvorgängen: die Architektur der CDC 6600- und 7600-Systeme beruht auf der Aufteilung des EDV-Systems in einen Zentralrechner zur effizienten Bearbeitung numerischer Probleme und zehn mit ihm gekoppelten, kleineren Peripheren Prozessoren zur Bedienung der Peripherie und zur Steuerung der Gesamtanlage. Die Erhöhung der Zuverlässigkeit und der Verfügbarkeit ist das zweite Motiv zum Verbund von Rechnern. Für kritische Steuerungs- und Kommunikationsaufgaben, vor allem im militärischen und industriellen Bereich, wurden bereits früh mehrere Rechner gekoppelt: entweder mit einer parallelen Bearbeitung identischer Daten und Aufgaben durch zwei bis drei grundsätzlich unabhängige Anlagen (hot stand-by) oder mit der Bereitstellung von Zweit- und Drittrechnern, auf die automatisch oder manuell bei Ausfall der primären Anlage umgeschaltet werden konnte (cold stand-by). Auch die räumlich getrennte Führung identischer Datenbestände wird aus Sicherheitsgründen zuweilen verlangt — zum Schutz wichtiger Daten gegen Zerstörung durch Krieg, Terrorismus, Unfälle oder Naturkatastrophen. Eine Verringerung da1 mittleren Wartezeiten kann durch den Verbund mehrerer identischer Hardware-Systeme erreicht werden, die über den Arbeitsspeicher, über eine gemeinsame Plattendatei für das SPOOL-System oder auch über Datenübertragungsleitungen gekoppelt sind. Wie stark die durchschnittlichen Wartezeiten bei hohen Auslastungen durch einen Lastausgleich zwischen mehreren Prozessoren gesenkt werden können, zeigt eine Abschätzung für die beiden in Abb. 1.1-2 dargestellten Modellsituationen. Im Single Server-Fall(ä)treffen für m gleiche Prozessoren PI bis Pm in statistischer Folge Aufträge ein. Sie werden jeweils in der Warteschlange ihres Prozessors zwischengepuffert. Die mittlere Auslastung jedes Prozessors durch die Aufträge sei A, die mittlere Ausführungszeit (Service-Zeit) für einen Auftrag sei Ts. Im Ai«/f/server-Fall(b) werden hingegen alle eintreffenden Aufträge in eine einzige Warteschlange zusammengeführt, aus der einem freiwerdenden Prozessor jeweils der nächste Auftrag zugeteilt wird. Im Unterschied gegenüber Fall(ä)ist

14

1. Grundbegriffe und Grundstrukturen PI

1 3 3 3 3 3 — ® - *

P2

N I M

A \ \ \ \

r r

\

PM

I — ( g V

( ä ) m Ringle Server" gleicher Kapazität mit getrennten Warteschlangen

(b)

„Multiserver" mit gemeinsamer Warteschlange

m

Abb. 1.1-2 Single Server-und Multiserver-System

sichergestellt, daß jeder der m Prozessoren arbeitet, solange überhaupt noch Aufträge warten. Nach der Warteschlangentheorie ([KLEI76b], S. 280ff.) gilt bei exponentieller Verteilung der statistischen Größen für die mittlere Wartezeit T von der Anmeldung eines Auftrags bis zur Fertigmeldung T= 7V (1 + 1

Pm(A)

m(l-A)

).

Pm (A) ist die Wahrscheinlichkeit, daß das Gesamtsystem m oder mehr Aufträge bearbeiten muß, d. h. daß alle Prozessoren ausgelastet sind; sie ist gegeben durch

(mA)m

k=o

k!

Für m=l ist sie gleich der Auslastung .4. Für das Single Server-System folgt als mittlere Wartezeit T= Ts - (1 +

1—Ä

Bei einer Auslastung von 80% hat sie mit A = 0,8 den Wert T= 5- Ts— sie ist also fünfmal länger als die reine Ausfuhrungszeit eines Auftrags. Arbeiten jedoch im Multiserver-Fall m = 5 Prozessoren auf die gleiche Warteschlange, so ergibt sich P5 (0,8) = 0,7885 und T= 1,7885 • Ts. Gegenüber dem Single Server-Fall ist die mittlere Wartezeit also auf fast ein Drittel reduziert! Noch ausgeprägter ist die Senkung der durchschnittlichen Wartezeiten, wenn die im Verbund zusammenarbeitenden Prozessoren durch die lokalen Anforderungen ohnehin nicht gleichmäßig ausgelastet wären und schwach belastete Systeme den

1.1 Kommunikation zwischen Rechnern

15

überlasteten Arbeit abnehmen können. Dies ist auf Grund der geographischen Ausdehnung der USA bei den unter dem TENEX-System laufenden PDPIO-Installationen des ARPA-Netzes der Fall, welches mehrere Zeitzonen überdeckt. Der Trend zur Online-Datenverarbeitung über dialogfähige Bildschirm- oder Fernschreib-Terminah ist ein weiteres Motiv zum Aufbau von Rechnernetzen. Abb. 1.1-3 zeigt die in nächster Zukunft erwartete Zunahme der Anzahl installierter Terminals in Europa, Abb. 1.1-4 die Entwicklung der relativen Kosten-

Abb. 1.1-4 Kostenverteilung einer typischen Datenübertragungs-Anwendung

16

1. Grundbegriffe und Grundstrukturen

anteile für Terminals, Rechner und Leitungsmieten bei einer typischen Datenübertragungsanwendung [INF077]. Sobald die Leitungskosten den überwiegenden Kostenfaktor darstellen, wird es wirtschaftlich sinnvoll, durch Verteilung der Rechnerkapazität und Datenhaltung einen möglichst großen Teil der Datenverarbeitung an die Aufstellungsorte der Terminals, also etwa in die einzelnen Filialen eines Handelsunternehmens selbst zu verlagern, und über den Verbund dieser Rechner nur diejenigen Daten und Informationen zwischen ihnen auszutauschen, die wirklich überregional benötigt werden. Die Erweiterung des Dienstleistungsangebots und der verfügbaren Betriebsmittel schließlich ist der wohl häufigste Grund zum Verbund mehrerer Rechner. Nur auf bestimmten Rechnern verfügbare Programmiersprachen, Betriebs-, Datenbank- und Informationssysteme oder besonders leistungsfähige Hardware können durch Eingliederung in ein Rechnernetz auch Benutzern anderer Anlagen zur Verfügung gestellt werden. Für das ARPA-Netz wurden im März 1973 die Einsparungen ermittelt, welche 20 Teilnehmer-Installationen hierdurch erzielten [ROBE74]. Umgerechnet auf das volle Jahr mußten sie statt etwa 6 Mio $ bei Eigenbeschaffung der benötigten Betriebsmittel nur ca. 2 Mio $ an Kostenbeteiligungen und Gebühren für Rechenzeiten bezahlen. Den so ersparten 4 Mio $ standen Kosten für den Betrieb des Netzes mit 3,5 Mio $ gegenüber. In Anbetracht der Tatsache, daß damals das ARPA-Netz zu nur etwa 20% ausgelastet war, dürfte die Bilanz inzwischen noch wesentlich günstiger sein. Je nachdem, ob ein Rechnerverbund auf eine Vervielfachung oder gleichmäßigere Verteilung der Rechnerleistung, auf die Verfügbarkeit von Betriebsmitteln eines EDV-Systems auch für andere Rechner oder auf eine Integration aller systemweit gehaltenen Einzel-Datenbestände abzielt, spricht man von einem Lastverbund, Betriebsmittelverbund oder Datenverbund. Wird schließlich eine Leistungserhöhung des Gesamtsystems dadurch erreicht, daß verschiedene Prozesse in den gekoppelten Einzelsystemen jeweils einen logisch abgetrennten Teilbeitrag zum Erreichen des Gesamtziels erbringen, so bezeichnet man dies als Intelligenzverbund.

1.2 Aufgaben und Aufbau typischer Rechnernetze Die verschiedenen Motivationen zur Kopplung mehrerer EDV-Systeme zu einem Rechnernetz führen zu Systemlösungen, die sich vor allem in der Hardwarestruktur und der Topologie der physikalischen Leitungsfiihrung unterscheiden. Diese Unterschiede beeinflussen die Hardwareauswahl, die Wahl der Datenübertragungsmedien, -verfahren und -techniken, die „niederen" Ebenen der Datenübertragungssoftware, Leistungs- und Kostenoptimisierungen und — natürlich — die zu realisierenden Benutzerschnittstellen. Sie verdecken damit aber auch häufig die in allen Netzen wiederzufindenden Gemeinsamkeiten der Grobstruktur und der Basisbausteine der Rechnernetz-Software.

17

1.2 Aufgaben und Aufbau typischer Rechnernetze

Trotzdem empfiehlt es sich, vor der Idealisierung einer abstrakten Netzarchitektur als konkrete Beispiele einige realisierte Rechnernetze vorzustellen. Letztlich ist der Grund für die Planung eines Netzes immer „physikalisch": eine aufgabenspezifisch vorgegebene Verteilung der Rechnerdienstleistungen, welche die einfachere und ökonomischere Lokalisierung der EDV-Installation ausschließt.

| : Terminals |

1 | : Konzentratoren

m

: zentraler Knoten

: DV-Zentrum der ÖBB Abb. 1.2-1 (Sub-)Netz der österreichischen Bundesbahn

Die räumliche Verteilung da" Benutzer ist das Hauptmotiv für den Aufbau vieler Datenerfassungs- und Informationsnetze von Großfirmen, Behörden, öffentlichen Dienstleistungsunternehmen und ähnlichen Institutionen. Ein Beispiel ist das in Abb. 1.2-1 gezeigte Netz der Österreichischen Bundesbahn, welches zugleich Subnetz in einem Verbund der europäischen Bahnverwaltungen ist. Seine Hauptaufgaben sind — Datenerfassung am Ort der einzelnen Bahnhöfe und Dienststellen, — Auskunftserteilung über die 70 000 Bediensteten der ÖBB,

18

1. Grundbegriffe und Grundstrukturen

- Voranmeldung der Güterzüge an jedem Bahnhof und Lenkung des Güterverkehrs durch Steuerung der Zugzusammenstellung, - Speichervermittlung von Fernschreiben, - Platzbuchung in Zusammenarbeit mit dem automatischen Buchungssystem der Deutschen Bundesbahn. Für jeden Bezirk gibt es ein Bezirksnetz mit einem Konzentrator und angeschlossenen Terminals unterschiedlicher Intelligenz. Die Aufgaben der Konzentratoren sind - Plausibilitätsprüfungen der Terminaleingaben, - Laufwegermittlung und Weiterleitung der Nachrichten an den oder von dem zentralen Knoten in Wien. Die Konzentratoren sind mit dem zentralen Knoten über ein mehrfach vermaschtes Netz von 1200 baud-Leitungen verbunden. Der zentrale Knoten - übernimmt die Nachrichtenvermittlung zwischen Konzentratoren, DV-Zentrum in Wien und anderen europäischen Bahn-Netzen, - überprüft die Terminalberechtigung bei Dienstleistungswünschen und Anfragen, wie etwa einer Personalauskunfts-Anforderung, - überwacht das Gesamtnetz, - führt Statistiken über den Betrieb des Netzes. Die räumliche Verteilung von angebotenen Dienstleistungen und Betriebsmitteln gab Anlaß zur Entwicklung von Rechnernetzen, die im wesentlichen die Datenbestände, Programme und Betriebsmittel verschiedener lokaler Dienstleistungsrechenzentren für wissenschaftlich-technische oder kommerzielle Anwendungen miteinander verbinden und damit jedem Benutzer bei Bedarf die Leistungen aller beteiligten Rechnerinstallationen verfügbar machen sollen. Beispiele sind das amerikanische ARPA-Netz [LOGI74] oder das französische CYCLADESNetz [POUZ73], welches in Abb. 1.2-2 skizziert ist. CYCLADES verbindet 16 Teilnehmerrechner (Hosts) von 6 verschiedenen Typen unter 8 verschiedenen Betriebssystemen und stellt auf ihnen den Netzbenutzern sowohl Timesharingals auch Stapelverarbeitungs-Dienstleistungen zur Verfügung. Das ARPA-Netz, an welches neben Rechenzentren in der gesamten USA auch noch einige europäische EDV-Installationen über Satelliten angeschlossen sind, umfaßt mehrere Zeitzonen und dient damit auch dem Ausgleich der räumlichen Verteilung der zeitlichen Anforderungsschwerpunkte. Bei der Diskussion von DV-Netzen werden schließlich die im Rahmen von öffentlichen oder privaten Datenübertragungsnetzen zusammenarbeitenden Rechner häufig vergessen. Auch sie bilden oft sehr komplexe Rechnernetze, wobei die beteiligten EDV-Anlagen jedoch nicht die Bearbeitung von Benutzer-

19

1.2 Aufgaben und Aufbau typischer Rechnernetze

=

=

48 kb-Leitung

Q-j

4,8 kb-Leitung

i——l | 2 I

Knotenrechner

TeUnehmerrechner („Hosts", 6 verschiedene Typen) Hosts können mit mehreren Knotenrechnern verbunden sein

Abb. 1.2-2 Das CYCLADES-Netz

aufgaben sondern den Nachrichtenverkehr über das Netz selbst sowie ggf. Dienstleistungen übernehmen, welche mit diesem Nachrichtenverkehr zusammenhängen (z. B. Abrechnung, Statistik, Speicherveimittlung). Abb. 1.2-3 skizziert schematisch das Fernschreibnetz der Deutschen Bundespost Die Vermittlung von Verbindungen zwischen Fernschreibteilnehmern wird über zentrale Vermittlungsrechner (EDS = Electronic Data Switch) durchgeführt, welche auch für die Gebührenberechnung und ähnliche Aufgaben zuständig sind. Neben dem Direktanschluß von Fernschreibern an die EDS-Zentralen ist auch der Anschluß von Nebenstellen-Anlagen oder Sondernetzen möglich, die über

20

1. Grundbegriffe und Grundstrukturen

\

Einzelleitungen Leitungsbündel (Trunk Lines) Abb. 1.2-3 Das Fernschreibnetz der DBP

\

\

private Nebenstellenanlage, ggf. privates Netz (Großfirma, Behörde o. ä.)

/

/

. /

mehrere Einzelleitungen

1.3 Physikalische und logische Struktur von Rechnernetzen

21

eigene, kleinere Vermittlungsrechner verfugen. Diese Nebenstellenrechner erfüllen ihrerseits weitere Dienste, wie etwa die interne Gebührenüberwachung, Speichervermittlung, externe und interne Rundschreiben, automatische Generierung von Standardtexten, Textspeicherung und -editierung. Neben dem Vermittlungsdienst bietet die Bundespost durch eigene Systeme auch noch netzbezogene Dienstleistungen, wie etwa die Automatische Telexauskunft, die auf Anfrage selbsttätig Auskunft über Telexnummern oder Teilnehmeranschriften erteilt. In einigen Ländern wie den USA (TYMNET [SCHW76]) stehen derartige öffentliche Netze bereits auch ausschließlich für den Datenverkehr zwischen Rechnern zur Verfügung. Wegen der Ergänzung der Vermittlungsfunktion durch zusätzliche Dienstleistungen werden sie oft als Vabte AddedNetworks (VAN) bezeichnet.

1.3 Physikalische und logische Struktur von Rechnernetzen Die Vielfalt der Gründe, die zum Aufbau eines Rechnernetzes fuhren können, bedingt eine Vielfalt der Entwurfsvorgaben, der bei der Realisierung gegeneinander abzuwägenden Zuverlässigkeits- und Effektivitätsgesichtspunkte, der sinnvollen Leitungsfiihrung und -auslegung, der Anordnung der verschiedenen Rechner und sonstigen Betriebsmittel sowie der Aufgabenteilung zwischen ihnen. Um Überhaupt eine einheitliche Entwicklungsmethode für DV-Netze erarbeiten zu können, welche jeweils einer bestimmten Aufgabe angepaßt und — wenn nötig — modifiziert werden kann, muß man von einer Netz-Grobstruktur ausgehen, die als Idealisierung der unterschiedlichen konkreten Realisierungen angesehen werden kann. Bei jedem DV-System lassen sich zwei wesentliche Strukturen unterscheiden: - die physikalische Struktur, d. h. die einzelnen eingesetzten Rechner, Terminals und sonstigen Betriebsmittel, die technischen Übertragungselemente wie Leitungen und Modems, sowie ihre gegenseitige (konkrete) Anordnung und Zusammenschaltung, und — die logische Struktur von Daten und Prozessen sowie deren Wechselwirkungen systemintern oder -extern in Kommunikation mit der Umgebung (Benutzern an Terminals, Meß- und Steuereinrichtungen u. ä.). Die Aufgabe jeder Software ist die Abbildung der logischen Struktur auf die physikalische, der Benutzermaschine auf die Hardware und auf die als Teil von ihr aufzufassende, bereits vorhandene Basissoftware wie Sprachübersetzer, Hersteller-Betriebssysteme und -Dienstleistungsprogramme. Die in Abb. 1.3-1 und

22

1. Grundbegriffe und Grundstrukturen

Abb. 1.3-1 Physikalische Struktur eines Rechnerverbundnetzes

1.3-2 gezeigten physikalischen und logischen Grundstrukturen eines Netzes charakterisieren damit zugleich die wesentlichen Teilaufgaben eines Netzentwurfs: — die konkrete Auswahl und Anordnung der Hardware-Strukturelemente, — die für die jeweilige Anwendung optimale Realisierung der gewünschten logischen Struktur sowie — die Zuordnung von logischen und physikalischen Strukturelementen. Die physikalische Struktur skizziert Abb. 1.3-1: verschiedene Arten von Hardware-Elementen werden durch Datenübertragungsleitungen zu einem Netz verbunden. Die im Netz zusammengeschlossenen Hardware-Einheiten können jeweils als an einem Ort lokalisiert angesehen und damit durch eine Adresse identifiziert

1.3 Physikalische und logische Struktur von Rechnernelzen Terminal-Subsystem(e)

23 Host-Subsystem(e)

Abb. 1.3-2 Logische Struktur eines Rechnerverbundnetzes

werden. Diese Adresse ist eine Bit- oder Zeichenfolge, welche eine mnemonische Bedeutung haben kann, aber nicht muß. Nach ihrer Funktion im Netz unterscheiden wir vier Grundtypen dieser HardwareElemente. Terminals (Datenendplätze, Datenstationen) sind die Ein-/Ausgabegeräte, über welche die Außenwelt, in der Regel der menschliche Benutzer, mit dem Netz kommuniziert. Es gibt dialogfähige und nicht dialogfähige Terminals. Dialogfähige Terminals sind Fernschreibgeräte, Schreibmaschinen, Datensichtgeräte und graphische Terminals. Nicht dialogfähige Terminals sind Kartenleser, Schnelldrucker, Anzeigelampen, Ausweisleser und die übliche Prozeßperipherie wie Meßfühler und Steuereinrichtungen. Hosts (Wirtsrechner, Gastrechner, Verarbeitungsrechner, Teilnehmer-Rechner, Endrechner) sind Rechner (bzw. EDV-Installationen), die für das Netz Quellen

24

1. Grundbegriffe und Grundstrukturen

und Senken von Informationen sind. In ihnen entstehen Nachrichten, welche dem Netz zur Übermittlung an andere Hosts oder Terminals übergeben werden, und an sie gelangen über das Netz Nachrichten von anderen Hosts oder Terminals zur Verarbeitung.

IMPs (Interface Message Processors, Knotenrechner, Kommunikationsprozessoren, Vermittlungsrechnerj sind Rechner, welche Nachrichten von Hosts zur Weiterleitung an eine bestimmte Zieladresse (anderer Host oder Terminal) übernehmen. Sie trennen diese Nachrichten ggf. in kleinere Einheiten (.Pakete) auf und übermitteln sie dem Adressaten entweder unmittelbar oder unter Zwischenschaltung anderer IMPs. TIPs (TerminalInterface Processors, Terminal-Knotenrechner) sind IMPs, welche nicht nur Hosts bedienen sondern auch den Nachrichtenverkehr mit Terminals abwickeln können. Die IMPs und TIPs bilden das „eigentliche" Datenübertragungsnetz, welches Hosts und Terminals zur Kommunikation benutzen. Im Rahmen des groben Strukturmodells von Abb. 1.3-1 sind Hosts, IMPs und TIPs nichts weiter als lokalisierte, adressierbare „Behälter" für bestimmte zur Verfugung stehende Betriebsmittel und ablaufende Aktivitäten (Prozesse). Über ihren Aufbau, Ausstattung, Größe u. ä. werden keinerlei Angaben gemacht. Nimmt man an, daß alle Hosts einerseits und alle IMPs und TIPs andererseits vom gleichen Rechnertyp sind und sich allenfalls unwesentlich in ihrem Arbeitsspeicherausbau, ihrer Zentraleinheit und der angeschlossenen Peripherie unterscheiden, so spricht man von einem homogenen Netz - ein Sonderfall, der in der Regel die Planung und Realisierung der Netzsoftware wesentlich erleichtert. Der technische Fortschritt oder steigende Anforderungen zwingen allerdings immer irgendwann zur Eingliederung neuer Hardwaremodelle und Datenübertragungsverfahren oder zum Anschluß an andere Netze, wodurch ein bestehendes Netz zwangsläufig inhomogen wird. Wird dies nicht bereits während der ersten Planung und Realisierung bedacht, so betragen die höheren Wartungs- und Weiterentwicklungskosten leicht ein vielfaches der durch die angenommene Homogenität des Netzes erreichten Einsparungen. In der logischen Struktur eines Rechnernetzes, die Abb. 1.3-2 darstellt, kann man auf oberster Ebene - Host-Subsysteme, - Terminal-Subsysteme, und -

Kommunikations-Subsysteme

unterscheiden. Ein Netz enthält im allgemeinen mehrere Subsysteme jeder Art, die jeweils identisch sein (z. B. gleiche Hosts mit identischer Software) oder sich voneinander unterscheiden können. Häufig gibt es nur ein einziges Kommunikations-Subsystem — das Datenübertragungsnetz mit seiner Software. Das zunehmende Kommunikationsbedürfnis in

25

1.3 Physikalische und logische Struktur von Rechnernetzen

der Datenverarbeitung führt aber immer mehr dazu, daß Hosts und/oder Terminals in mehrere Netze eingegliedert werden, wodurch ein Gesamtnetz mit mehreren Kommunikations-Subsystemen entsteht. Ein Host-Subsystem enthält ein Netz-Kommunikationsprogramm, mit dessen Hilfe Verarbeitungsprozesse einen Nachrichtenverkehr über das KommunikationsSubsystem abwickeln können. Diese Subsystem-Komponente wird in fast jedem Netz mit einem anderen Namen bezeichnet. Im ARPA-Netz heißt sie Network ControlProgram (NCPj, im CYCLADES-Netz Transportstation (TS). Die Verarbeitungsprozesse können Benutzerprozesse, aber auch Dienstleistungsprozesse für Benutzerprozesse im gleichen oder einem fremden Host oder für einen Terminalbenutzer sein (z. B. ein Dateiverwaltungs-Prozeß). Sie können aber auch für den Benutzer „unsichtbar" irgendwelche für den Betrieb des HostRechners oder des Gesamtnetzes notwendige Funktionen ausüben, wie etwa die Systemabrechnung (Accounting); derartige Prozesse werden zuweilen Dämonen genannt. Ein Terminal-Subsystem enthält die Terminalprozesse selbst, welche ein bestimmtes Terminal und den auf ihm ggf. ablaufenden Dialog mit dem jeweiligen Anwender überwachen und betreuen, sowie die Terminalbedienung, welche entsprechend dem Netz-Kommunikationsprogramm eines Host-Subsystems den Nachrichtenverkehr mit dem Kommunikations-Subsystem wahrnimmt, und für die es ebenfalls noch keine einheitliche Bezeichnung gibt. Das Kommunikations-Subsystem schließlich besteht aus einzelnen NachrichtenVermittlungs-Systemen, die untereinander sowie mit den Netz-KommunikationsProgrammen und den Terminalbedienungen Nachrichten und Steuerinformationen austauschen. logische Komponenten Terminal-Subsystem: Terminal-Prozesse Terminal-Bedienung

physikalische Komponenten

Terminal TIP

Kommunikations-Subsystem Nachrichten-Vermittlung

IMP

Host-Subsystem Netz-Kommunikationsprogramm

Host

Verarbeitungsprozesse Abb. 1.3-3 Zuordnung der logischen zu den physikalischen Komponenten eines Netzes

26

1. Grundbegriffe und Grundstrukturen

Die Zuordnung der einzelnen logischen Subsysteme von Abb. 1.3-2 auf die Hardwarekomponenten der physikalischen Systemstruktur ist im groben selbstverständlich. Bei detaillierterer Betrachtungsweise können jedoch Überlappungen auftreten, die Abb. 1.3-3 zeigt. Vor allem in die Aufgaben des Netz-Kommunikationsprogramms teilen sich in vielen Systemen Hosts und IMPs oder TIPs. Vor allem größere Hosts besitzen oft auch einen eigenen Vorrechner zur Abwicklung der Netzkommunikationsaufgaben.

1.4 Benutzeranforderungen Da die Motive für den Aufbau eines Rechnernetzes letztlich immer physikalischer und technologischer Natur sind — die räumlichen Entfernungen zwischen den Rechnerinstallationen und Terminals sowie die zwischen ihnen vorhandenen oder zu schaffenden Übertragungsmedien — wird bei der Netzplanung das von der modernen Softwaretechnologie empfohlene Top Down-Vorgehen von den Benutzeranforderungen zur technischen Realisierung noch seltener befolgt als in anderen Bereichen der EDV. Die Bevorzugung der Bottom Up-Planung gerade bei Datennetzen wird meist so begründet, daß ihre wesentlichen Leistungsmerkmale, wie Durchsatz, Antwortzeiten und Zuverlässigkeit, hauptsächlich von der Konstruktion des Kommunikations-Subsystems abhingen. Dessen Güte werde wieder maßgeblich durch seine physikalischen Bauelemente und die „niedrigen" Softwareschichten wie Unterbrechungsbehandlung, Warteschlangenführung, Pufferverwaltung und dergleichen bestimmt. Also müsse man mit ihrer optimalen Auslegung beginnen und sich dann im Netzentwurf zu den höheren Ebenen der Software und schließlich zu den angebotenen Benutzerdienstleistungen hocharbeiten. Ein Beispiel aus dem ARPA-Netz [WOOD75] zeigt jedoch, daß eine nicht von den Benutzeranforderungen ausgehende Planung durch unzweckmäßige Auslegung der oberen Softwareebenen ebenso hohe Leistungseinbußen bringen kann wie Fehler in „tiefen" Netzschichten: Im Gegensatz zum Dialogbetrieb sollte bei dem Dateitransfer, der Übertragung großer, zusammenhängender Datenmengen zwischen Hosts, die Übertragungsrate von der Länge des Übertragungswegs (gemessen in Teilstrecken zwischen IMPs) zumindest in erster Näherung unabhängig sein. Die Zahl der zu überwindenden Teilstrecken ist ja nur zu Beginn und Ende der Übertragung von Bedeutung; im eingeschwungenen Zustand kann sich ein kontinuierlicher Strom von Daten mit im Mittel gleichförmiger Geschwindigkeit über alle Teilstrecken zwischen Sender und Empfänger bewegen. Abb. 1.4-1 zeigt jedoch, daß im ARPA-Netz die Übertragungsrate mit steigender Zahl der Teilstrecken auch für den Dateitransfer drastisch abnimmt. Der Grund ist, daß bei der Netzplanung offenbar der Benutzerwunsch nach Übertragung langer Datenströme schlicht vergessen wurde. Die Regelung des Nach-

27

1.4 Benutzeranforderungen Übertragungsrate [kbit/sec] 20

--

15 - -

10

- -

5 --

0

2

4

+ 6

+ 8

10

12

Zahl der Teilstrecken Abb. 1.4-1 Durchschnittliche Übertragungsraten für den Dateitransfer im ARPA-Netz [nach WOOD75]

richtenaustauschs zwischen Host-Rechnern (das Host-Host-Protokoll) und nicht etwa das Kommunikations-Subsystem verlangt nämlich, daß zwischen Hosts jeweils maximal eine etwa 8000 bit lange Nachricht unterwegs sein darf, und daß die nächste erst abgesendet werden kann, wenn der Empfänger die vorhergehende bestätigte. Damit begrenzt die Dialogverkehr-Antwortzeit von etwa 1 sec bei langen Übertragungswegen völlig unnötigerweise auch die Übertragungsraten beim Dateitransfer auf Werte in der Größenordnung von 8000 bit/sec. Wie für jedes EDV-System sollte deshalb auch der Entwurf eines Netzes mit der Definition eines Benutzermodells beginnen. Dies ist eine Studie, welche die folgenden Fragen beantwortet: — Wer sind die Benutzer des Netzes? — Welche Dienstleistungen wollen sie vom Netz erhalten? — Welche dieser Dienstleistungen sind bereits auf irgendwelchen Hosts des künftigen Netzes realisiert? — Welche Kompromisse und Einschränkungen (z. B. Wartezeiten, verminderten Funktionsumfang) kann der Netzbenutzer bei diesen bereits existierenden Dienstleistungen hinnehmen? — Welche Dienstleistungen werden erst im Rahmen der Netzentwicklung neu geschaffen?

28

1. Grundbegriffe und Grundstrukturen

— Kann man den Benutzern die als Folge des breiteren Dienstleistungsangebots entstehende große Vielfalt unterschiedlicher Bedienungsanweisungen zumuten (z. B. unterschiedliche Auftragssteuersprachen der einzelnen Host-Betriebssysteme oder voneinander abweichende Auskunfts- und Buchungssysteme verschiedener zusammengeschlossener Reiseunternehmen), oder muß eine vereinheitlichte Benutzerschnittstelle definiert und realisiert werden? — Wie wird der Benutzer von Ganz- oder Teilausfällen des Systems informiert, und wie sieht der Wiederanlauf und die Unterstützung des Benutzers bei der Diagnose und Behebung von Ausfällen und Fehlern aus? — Wie erlernen die Benutzer die Bedienung des Netzes, welche Dokumentation und Hilfen hierfür (z. B. Schulungsprogramme) sind erforderlich, und wie werden sie über wichtige Neuigkeiten des Netzbetriebs (z. B. neue Dienstleistungen) informiert? Soweit bekannt oder abschätzbar kommen hierzu noch Mengengerüste und Vorgaben: Angaben über die Menge und zeitliche Verteilung der einzugebenden, auszugebenden und zwischen den einzelnen Hosts zu übertragenden Informationen, die Menge und Organisation der in den einzelnen Hosts zu haltenden Datenbestände, maximale Antwort- und Wartezeiten, zulässige Fehlerraten und Ausfallzeiten und ähnliches. Neben der exakten Definition der Benutzerschnittstellen, wie Bedienungssprachen, Bildschirmdialog-Formate und Makroaufrufe für Netzdienstleistungen, läßt sich aus dem Benutzermodell ableiten, welche Grundtypen der Netzwerkbenutzung unterstützt werden müssen: — der interaktive Dialog, wobei sich wieder die Dialogprogrammierung von Timesharing-Systemen, die transaktionsorientierte Benutzung von Auskunfts-, Buchungs-, Datenerfassungs- und ähnlichen Systemen sowie der vom Rechnernetz lediglich vermittelte Dialog zwischen mehreren Benutzern an Terminals unterscheiden läßt, — die Fem-Stapeherarbeitung (Remote Job Entry, RJE), — die Kommunikation mit Kleinrechnern, wobei entweder der Kleinrechner die Benutzerschnittstelle der Netzdienstleistungen durch Prozeduranpassungen, Vor- und Nachbearbeitungen, Textaufbereitungen u. ä. verbessert, oder aber im Netz vorhandene Großrechner Aufgaben wie die Haltung großer Datenbestände oder Übersetzungen aus höheren Programmiersprachen übernehmen, welche die Leistungsfähigkeit oder Speicherkapazität der Kleinrechner übersteigen, — der Datenaustausch zwischen Rechnern, wobei der Austausch kurzer Nachrichten und die Übertragung großer Informationsmengen (der Dateitransfer) unterschieden werden müssen. Jede dieser Grundformen stellt andere Anforderungen an die Protokolle, die Regeln zur Abwicklung des Datenverkehrs auf jeder Ebene der Netzsoftware. In

1.5 Realisierungsprobleme

29

einem größeren Netz müssen meist mehrere Betriebsweisen unterstützt werden. Ein Top Down-Verfahren bei der Netzentwicklung legt auf jeder Stufe einen für die Anforderungsprofile und relativen Häufigkeiten der einzelnen Betriebsweisen optimalen Kompromiß nahe. Ein Bottom Up-Entwurf hingegen überläßt dies weitgehend dem Zufall und fuhrt damit leicht zu krassen Benachteiligungen einzelner Betriebsweisen, wie sie das erwähnte das Beispiel aus dem ARPA-Netz zeigte.

1.5 Realisierungsprobleme Bei den Kompromissen, die beim Entwurf sowohl des Gesamtnetzes als auch seiner Einzelkomponenten eingegangen werden müssen, befindet sich der Planer in einem Zielkonflikt, den Abb. 1.5-1 darstellt. Die Forderungen nach — geringen Antwortzeiten (wichtig vor allem für interaktiven Dialog und Nachrichtenaustausch zwischen Rechnern), — hohem Durchsatz (besonders wichtig für die Fern-Stapelverarbeitung und den Dateitransfer),

— geringen Kosten und — hoher Zuverlässigkeit widersprechen sich jeweils und verlangen ein gegenseitiges Abwägen der Planungsgesichtspunkte. Q

Geringe Kosten und hohe Zuverlässigkeit sind immer schwer vereinbar. Je hochwertiger die Hardware, umso teurer ist sie auch. Die Fehlerbehandlung verlangt einen beträchtlichen Softwareaufwand — bei einem größeren Realzeitsystem diente 70% des gesamten Programmcodes diesen Aufgaben [MART00]. Der zur Fehlererkennung nötige Zusatzaufwand und das Wiederholen falsch übertragener Nachrichten bringt eine höhere Belastung der Übertragungsleitungen. Und wird gar die Forderung einer weitgehend ungestörten Systemverfugbarkeit auch im Fehlerfall gestellt, so erfordert dies eine Verdopplung vieler Hardwarekomponenten.

(2) Geringe Antwortzeiten bei der Nachrichtenübermittlung und -bestätigung lassen sich durch Verringerung der Zahl der Teilstrecken zwischen Sender und Empfänger erreichen. Eine Leitungsfiihrung, die jeden Knoten mit jedem anderen verbindet, erhöht jedoch die Zahl der Leitungen beträchtlich. Auch eine Verringerung der Wartezeiten in jedem IMP durch schnellere Hardware und Leitungen erhöht die Kosten. (3) Eine Erhöhung des Durchsatzes erfordert schnellere oder mehrere gleichzeitig benutzte Leitungen sowie eine Minimierung der Übertragungsfehler und der durch sie verursachten Nachrichtenwiederholungen. Höhere Leitungsqualität bedeutet aber auch höhere Leitungsmieten.

30

1. Grundbegriffe und Grundstrukturen

Abb. 1.5-1 Ziele und Kompromisse bei dem Entwurf eines Rechnernetzes

(4). Hohe Zuverlässigkeit verlangt aufwendigere Fehlererkennungs-und Bestätigungsmechanismen, möglichst auf mehreren Ebenen der Netzhierarchie. Die hierfür nötigen Bearbeitungs- und Wartezeiten verzögern die Nachrichtenübermittlung. ( D Hohe Zuverlässigkeit fordert aber auch ein Aufbewahren der gesendeten Informationen bis zur Bestätigung ihres korrekten Empfangs. Der hierfür in den einzelnen IMPs und Hosts längerfristig belegte Pufferplatz fehlt für andere zu übermittelnde Daten und begrenzt damit den gesamten zu erzielenden Durchsatz. (ö) Schließlich stehen auch die Forderungen nach hohem Durchsatz und nach geringen Antwortzeiten miteinander in Konflikt. Eine Erhöhung des Durchsatzes läßt sich durch Vergrößerung der als Einheit zu übertragenden Datenblöcke erreichen, da so der Aufwand für die mitzusendende Steuerinformation sowie die für ihre Verarbeitung in den IMPs und Hosts benötigte Verwaltungs-

1.5 Realisierungsprobleme

31

arbeit minimiert wird. Diese großen Datenblöcke werden aber wiederum von kurzen Nachrichten schlecht ausgenutzt, und sie belegen IMPs und Leitungen relativ lange Zeit. Sie verlängern damit die Antwortzeiten für alle Nutz- und Steuerdaten. Die folgenden Kapitel sollen dem Planer bei seinem Weg von den Benutzerschnittstellen zum physikalischen Netz begleiten und einige der Denkansätze und Methoden zeigen, welche ihm zur Überwindung der Probleme zur Verfugung stehen.

2. Die Benutzerschnittstellen

2.1 Die nichtlokalisierte Maschine Benutzer eines Rechnernetzes können entsprechend ihrem Zugriff auf seine Dienstleistungen in zwei Gruppen eingeteilt werden: — Terminal-Benutzer, welche unmittelbar über das Kommunikations-Subsystem oder durch Vermittlung ihres lokalen Hosts mit Verarbeitungsprogrammen (Prozessen) in entfernten Hosts kommunizieren, und — Anwendungsprogrammierer, welche Programme für einen der Hosts schreiben und dafür Zugriffe auf Daten oder sonstige Betriebsmittel anderer Hosts benötigen. Der Terminal-Benutzer sieht das Netz wie in Abb. 2.1-1 dargestellt. Die Terminals übernehmen den „lokalen Vertrieb" von EDV-Dienstleistungen, die irgendwo anders in Hosts erzeugt werden. Das eigentliche Netz, das Kommunikations-Subsystem, wird — ähnlich wie der Großhandel im Warenverkehr bestenfalls als notwendiges Übel zur überregionalen Verteilung empfunden; eine Veränderung der gelieferten „Ware" und eine Verzögerung der Belieferung sollte möglichst unterbleiben. Auch für den Anwendungsprogrammierer ist es im Grunde uninteressant, ob die von ihm benötigten Dienstleistungsfunktionen oder Datenzugriffe von einem lokalen oder einem räumlich entfernten Rechner erbracht werden. Für beide Anwendergruppen ist also die Basissoftware eines Rechnernetzes — von Sonderfällen wie ausgesprochenen Kommunikationsnetzen einmal abgesehen — nichts anderes als das Betriebssystem einer nichtlokalisierten Maschine. Die Unterschiede und die gegenseitigen Entfernungen der Einzelinstallationen sind für die Benutzer nur ein technisches DetaU. Die Software soll sie dagegen ebenso abschirmen wie etwa gegenüber Zahl, Anordnung und Typ der Plattengeräte in ihrem gewohnten, lokalisierten Rechenzentrum. Dieses Ideal ist in der Praxis kaum zu erreichen. Einige Ansätze zu seiner Verwirklichung und die auftretenden Probleme sollen im folgenden besprochen werden. Wie bei üblichen Betriebssystemen müssen hierbei entsprechend den oben genannten beiden Benutzergruppen zwei Benutzerschnittstellen unterschieden werden: — die Bedienung über ein Dialogterminal und — die Betriebssystem-Aufrufe (Supervisor Calls, Makros), die der Anwendungsprogrammierer zur Anforderung von Dienstleistungen benutzt.

33

2.2 Bedienungssprache und Terminals

Terminals verschiedener Art lokaler Vertrieb

überregionale Verteilung

Herstellung

Hosts

EDV-Dienstleitungen Abb. 2.1-1 Das Rechnernetz aus der Sicht des Terminal-Benutzers

2.2 Bedienungssprache und Terminals Die Benutzer am Dialogteiminal unterscheiden sich ihrerseits wieder in den gewünschten Dienstleistungen: — sie sind entweder Programmierer, die über das Dialogterminal im wesentlichen das gleiche Time-Sharing System oder die normale Stapelverarbeitung (Remote Job Entry, RJE) verwenden wollen, die sie auch bei lokalen Rechnern benutzen würden, — oder sie sind Sachbearbeiter oder Manager wie Schalterbeamte, Bodenstewardessen, Kaufleute, Planer, die über ihr Terminal Verarbeitungsprogrammen Daten übermitteln oder Informationen von ihnen abrufen.

34

2. Die Benutzerschnittstellen

Die erste Benutzergruppe wird in der Regel einen bestimmten Host oder einen bestimmten Betriebssystem-Typ — z. B. ein TENEX-System einer beliebigen PDP 10 im ARPA-Netz — anwählen. Hierfür muß die Dialog- oder Stapelverarbeitungs-Schnittstelle des angewählten Systems über das Kommunikations-Subsystem auf das Terminal verlagert werden. Schwierigkeiten treten dann auf, wenn die unterschiedlichen Steuersprachen verschiedener beteiligter Systeme durch eine einheitliche, netzweite Netz-Job Control Language (NJCL) [RAYM74] ersetzt werden sollen. Wichtiger für anwendungsorientierte Verbundsysteme und damit für die überwiegende Mehrzahl der öffentlichen und privaten Rechnernetze ist die zweite Gruppe der Terminalbenutzer. Ein häufiges praktisches Problem sind deshalb die Unterschiede zwischen den verschiedenen Terminals, die in einem größeren, inhomogenen Netz von den Verarbeitungsprogrammen bedient werden müssen — sie reichen vom einfachen Fernschreiber bis zum intelligenten Video-Terminal mit Hardcopy-Einrichtung, eigenem Speicher, verschiedenen Schrifttypen, freier Cursorbewegung über Tasten oder Steuerhebel („Joystick") und zahlreichen Funktionstasten. Diese Vielfalt wird noch dadurch erhöht, daß gleiche oder ähnliche Funktionen bei Terminals verschiedener Hersteller in ihrer Schnittstelle zur Hardware oft ganz unterschiedlich realisiert sind, und daß andererseits die Terminalbedienung durch die Hersteller-Betriebssysteme oder Task-Monitore freier Software-Produzenten ebenfalls keineswegs standardisiert ist. Eine ungefähre Vorstellung von dem Aufwand und den Kosten, welche diese Terminalvielfalt bei einer Netzentwicklung verursacht, vermittelt die Tatsache, daß von den 28k Arbeitsspeicher-Worten eines ARPA-TIPs die Software und Tabellen zur Codewandlung für nicht-ASCII-Terminals allein lk Worte benötigen [PYKE73]. Um Anwendungsprogramme und Netzsoftware einigermaßen unabhängig von den physikalischen Eigenschaften des jeweils eingesetzten lokalen Terminals entwickeln zu können, wird innerhalb eines Netzes meist ein Standard definiert, der als virtuelles („scheinbares") Terminal bezeichnet wird [BARB77, DÜNK77]. Eine der wichtigsten Aufgaben des in Abb. 1.3-2 gezeigten Terminal-Subsystems ist dann die softwaretechnische Abbildung der Eigenschaften eines realen Terminals auf die des vereinbarten virtuellen. Abb. 2.2-1 zeigt die hierfür nötigen Komponenten eines Terminal-Subsystems [WOOD75a], die am besten jeweils über Kontrollblöcke parametrisiert und gesteuert werden: - die terminalseitige Leitungssteuerung bedient die verschiedenen (realen) Leitungsarten zum Anschluß der Terminals und puffert die ein- und auszugebenden Zeichen oder Zeilen, - die Terminal-Steuerung verwaltet die verschiedenen realen Terminals, - die virtuelle Terminal-Simulation übersetzt die physikalischen Eigenschaften der realen Terminals in die des virtuellen Standards,

2.2 Bedienungssprache und Terminals multidrop

abgesetzt

(reale) Terminals

Abb. 2.2-1 Terminal-Subsystem

36

2. Die Benutzerschnittstellen

— das Verbindungsmanagement kümmert sich um Auf- und Abbau der Verbindungen (Sign On und Sign O f f ) sowie die in die zu übertragenden Daten einzuschiebende Steuerinformation, — die netzseitige Leitungssteuerung übernimmt die Pufferung, Wegwahl und Ein-/Ausgabe der zu übertragenden Nachrichten. Wie Abb. 2.2-2 zeigt, können je nach der „Intelligenz" der benutzten konkreten Terminals diese Funktionen teilweise auch in ihnen durch Software oder Mikroprogramme realisiert werden - in diesen Fällen simuliert das Terminal selbst den virtuellen Netz-Standard.

Abb. 2.2-2 Das virtuelle Terminal GS: Geräte-Steuerung (Terminal- und Leitungssteuerung) VT: Virtuelles Terminal (Simulation) VM/LS: Verbindungs-Management und Leitungssteuerung

Diese Simulation verlangt in der Regel eine Abstraktion der realen Terminalfunktionen. Einige von ihnen kann das virtuelle Terminal überhaupt nicht erbringen — dies gilt etwa fur die freie Bewegung des Cursors, wenn auch Fernschreiber verwendet werden sollen. Andere Eigenschaften müssen je nach eingesetztem Terminal sehr unterschiedlich abgebildet werden — so ist die virtuelle Funktion des Her-

2.3 Die verteilte Datenbasis

37

vorhebens von Zeichen oder Texten (Contrasting) eine Abstraktion so unterschiedlicher konkreter Darstellungsmittel wie Unterstreichen, Rotdruck, Blinken, Negativschrift oder höhere Leuchtintensität. Eine zu starke Einschränkung der Möglichkeiten des virtuellen Terminals durch die Forderung nach Realisierung auch auf einfachsten Fernschreibern wird meist dadurch umgangen, daß bestimmte Eigenschaften, wie etwa die freie Beweglichkeit des Cursors oder die maximale Zeilenlänge, als freie Parameter angesehen werden. Sie können bei Verbindungsaufnahme zwischen den Verarbeitungsprogrammen und der Terminalbedienung „ausgehandelt" werden. Ein sehr anpassungsfähiges Konzept für die Anordnung verschiedener Informationen auf einem konkreten Bildschirm oder auch als sequentielle Fernschreiberausgabe ist die Aufteilung des virtuellen Bildschirms in Zonen [BARB77a, LUCA75]. Je nach dem Format und den sonstigen Eigenschaften des benutzten Terminals werden diese Zonen — auf dem realen Bildschirm verteilt, — als getrennte Bildschirminhalte gezeigt, — sequentiell jeweils mit einer Identifikation der Zone ausgedruckt — oder auch völlig unterdrückt. Die einfachste Realisierung einer virtuellen Terminal-Schnittstelle, wie sie etwa im CYCLADES-Netz eingesetzt wird, sind Nachrichten variabler Länge zwischen Terminalsimulation und Anwenderprogramm [SCHI76, SCHI77]. Das erste Byte ist hierbei ein Code, welcher entweder — eine Operation wie etwa Zeilenvorschub, Wagenrücklauf oder Cursorbewegung angibt oder — die folgenden Bytes als sequentiell eingegebenen oder auszugebenden Text identifiziert. Die folgenden Bytes enthalten, wenn vorhanden, — einen Operanden für die Operation, z. B. die neue Position des Cursors oder — den Text selbst. Diese Nachrichten können dann als „Befehle" für die Ausgabe auf das reale Terminal oder für die Ablage eingegebener Texte in die Puffer des Verarbeitungsprogramms interpretiert werden.

2.3 Die verteilte Datenbasis Ebenso wie bei einem lokalisierten System sind für den Anwendungsprogrammierer auch in einer Netz-Umgebung neben der Ein-/Ausgabe zu Terminals die Zugriffe zu Datenbeständen die häufigsten Systemaufrufe. Dabei kann es sich um

38

2. Die Benutzerschnittstellen

Dateien in einem File-System oder um eine Datenbank handeln, oder aber auch um Ein-/Ausgabegeräte wie Kartenleser und Drucker, die in üblichen Betriebssystemen wie Dateien angesprochen werden und in der Regel auch über ein SPOOLSystem als solche realisiert sind [SCHN75]. Die Realisierung und Behandlung verteilter Datenbasen (.Distributed Data Bases) ist deshalb eines der wichtigsten Untergebiete sowohl der theoretischen als auch der praktischen Beschäftigung mit Rechnernetzen [BOOT76, CHAM77, CHAN76, INF077, LEVI74, LOWE76, MORG76]. Auch vom wirtschaftlichen Standpunkt aus ist dies meist eines der stärksten Argumente für den Aufbau von Rechnernetzen. Fry und Sibley [FRYJ76] berichten, daß ein größeres Unternehmen durch den Verbund seiner Teil-Datenbasen in die Lage versetzt wurde, jeden Freitag eine exakte Bilanz seiner laufenden Guthaben und Kassenbestände aufzustellen und die Mittel über das Wochenende als kurzfristige Darlehen auszuleihen. Überraschenderweise deckten allein die Zinsen hieraus die gesamten Kosten des Datennetzes. Das Bedürfnis, eine verteilte Datenbasis zu realisieren, d. h. entweder einen früher zentral gehaltenen Datenbestand nunmehr auf verschiedene Hosts zu verteilen, oder die Datenbestände mehrerer Host logisch zusammenzufassen, entsteht in der Regel in einer der folgenden Situationen [CHAM77]: (1) Lokal werden große Datenmengen erzeugt, die schnell abgefragt und geändert werden müssen. Die meisten dieser Anforderungen fallen lokal an, jedoch wird zuweilen zu den Datenbeständen auch von entfernten Stellen zugegriffen. Ein Beispiel ist das internationale Buchungssystem der Fluggesellschaften (SITA-Netz). (2) Lokal fallen große Datenbestände an. Einige dieser Daten sowie Ergebnisse ihrer lokalen Verarbeitung (Summen, Mittelwerte o. ä.) werden in einer Zentrale zur Weiterverarbeitung benötigt. Ein Beispiel hierfür ist die Filialkette eines Handelsunternehmens, welches täglich die Kassen- und Lagerbestände in die Zentralverwaltung übermittelt haben will. (3) Zentral fallen große Datenmengen an. Lokal werden ein rascher Zugriff auf Teile dieser Daten sowie ihre Verarbeitung und Korrelation mit lokalen Daten gebraucht. Ein Beispiel ist die Produktionssteuerung eines Industriebetriebes, wenn Aufträge der Zentrale in räumlich verteilten Produktionsstätten als Grundlage zur Stücklisten- und Fertigungsplanerstellung sowie zur Lager- und Vorratshaltung dienen. Welche dieser drei Situationen bei den geplanten Anwendungen vorliegt, ist Ausgangspunkt für die Spezifikation und Planung einer verteilten Datenbasis. Hiervon hängt nämlich ab, welcher der beiden möglichen Grundtypen sinnvoll ist:

- Bei der aufgeteilten Datenhaltung (.Partitioned Data Base) ist der Gesamtdatenbestand, wie Abb. 2.3-1 zeigt, auf die lokalen Datenbasen der einzelnen

39

2.3 Die verteilte Datenbasis

(logische) GesamtDatenbasis

lokale Datenbasen

A

B

C

Hosts

Kommunikations-Subsystem

Abb. 2.3-1 Aufgeteilte Datenhaltung (Partitioned Database)

Hosts verteilt; ein bestimmtes Datum ist immer nur auf einem der Hosts zu finden. Dies ist die Standard-Konfiguration für die erste der obigen Anwendungs-Situationen . - bei der mehrfachen Datenhaltung (Replicated Data Base) enthalten entsprechend Abbildung 2.3-2 die lokalen Datenbasen der einzelnen Hosts Unteroder Übermengen der Datenbasen anderer; ein bestimmtes Datum ist deshalb unter Umständen auf mehreren der Hosts gespeichert. Die obigen Anwendungsfälle (2) und (3) sind von dieser Art. Da in der Regel eine verteilte Datenbasis nicht nur einer einzigen Anwendung dienen soll, überlappen sich oft die verschiedenen Ausgangssituationen. Es ist dann die Aufgabe des Systemplaners, die optimale Verteilung der Datenbestände als Mischform der beiden Grundtypen zu ermitteln. Diese Datenanalyse ist dann eine der Grundlagen für die logische Planung des Gesamtnetzes — ähnlich wie die Struktur der zu verarbeitenden Daten einer der besten Ausgangspunkte für die Entwicklung eines üblichen Anwendungsprogramms ist [JACK75]. Abb. 2.3-3 zeigt als Beispiel das Netz einer französischen Großbank [INF077].

40

2. Die Benutzerschnittstellen

(logische) GesamtDatenbasis

lokale Datenbasis

Hosts

Abb. 2.3-2 Mehrfache Datenhaltung (Replicated Database)

Das Netz ist dreistufig: — die oberste Ebene sind zwei gekoppelte Großrechner in Paris und Aix, — die nächste Ebene sind 200 lokale Rechner mit eigener Datenhaltung und — als unterste Ebene dienen Konzentratoren in 2000 Filialen, die jeweils bis zu 5 Videoterminals und einen Drucker bedienen. Auf der obersten Ebene ist die vollständige Kunden-Datenbasis aufgeteilt, wobei in Paris 70% und in Aix 30% der Konten gehalten werden. Zwischen den zentralen und den lokalen Rechnern ist eine mehrfache Datenhaltung eingerichtet. Die lokalen Rechner erhalten am Anfang des Tages die aktuellen Kontenstände der von ihren Filialen betreuten Kunden übermittelt. Während des Tages werden von ihnen die aktuellen Transaktionen abgewickelt und nachts die neuen Kontenstände an den zentralen Rechner zurückgesendet. In den relativ seltenen Fällen, daß Kunden in fremden Filialen Abhebungen vornehmen wollen, müssen die beteiligten lokalen Rechner über das Gesamtnetz korrespondieren. In der Regel kann jedoch der lokale Rechner alle Realzeit-Aufgaben selbständig abwickeln,

41

n (Verbindung gestört)

Seiteneffekte senden: Nachricht speichern; Time Out: Wiederholungszähler := Wiederholungszähler+1; ACK: Nachricht löschen, Wiederholungszähler :=0;

empfangen: if

Nachricht nicht früher bereits empfangen then bearbeiten eise nicht beachten;

Abb. 4.3-2 Zustandsdiagramme einer einfachen Nachrichtenübertragung mit Zeitüberwachung durch den Sender

72

4. Netzwerkmaschinen und Netzzustände

diagramme zusammen mit den nötigen Seiteneffekten während der Übergabe zwischen den Prozeßzuständen — so muß der Empfänger bei Empfang einer Nachricht prüfen, ob er bereits eine frühere Kopie der gleichen Nachricht besitzt, da er nicht weiß, in welchem Zustand der Sender gerade ist. Er seinerseits kann deshalb bei längerem Verweilen im Zustand 1 auch nicht wissen, ob der Sender zur Zeit keine Nachrichten zu übermitteln hat (Zustand 1), oder ob er gerade Nachrichten wiederholt (Zustand 4) und nur die Netzwerkmaschine gestört ist — ob er also warten oder auch seinerseits einen Fehlerzustand annehmen soll.

Abb. 4.3-3 Restunsicherheit nach mehrmaliger Quittung einer Nachricht

4.4 Grundforderungen an Protokolle im Netz

73

Diese gegenseitige Unsicherheit über den jeweiligen Zustand zweier Partner ist unvermeidlich, wenn der einzige Kommunikationsweg zwischen ihnen ein unter Umständen gestörter Kanal ist. Daß sie sich auch durch beliebig viele gegenseitige Quittungen nie voll beseitigen läßt, zeigt Abb. 4.3-3 an einem Beispiel. Zwei Bankräubergruppen sind darauf angewiesen, daß Gruppe B exakt zu dem Zeitpunkt in den Tresor eindringt, zu dem Gruppe A die Alarmanlage stillegt. Führt eine der Gruppen ihre Teilaufgabe nicht aus, so darf auch die andere nichts unternehmen. Der einzige Kommunikationsweg zwischen ihnen seien unzuverlässige Boten. Auch eine mehrfache gegenseitige Bestätigung kann nicht beiden Partnern gleichzeitig volle Sicherheit über den Zustand des anderen geben — der Leser ist eingeladen, sich hiervon durch Ergänzung von Abb. 4.3-3 durch einige weitere Quittungsübermittlungen zu überzeugen.

4.4 Grundforderungen an Protokolle im Netz Diese Unsicherheit ist charakteristisch für den Unterschied zwischen lokalisierten und räumlich verteilten EDV-Systemen, zwischen herkömmlichen virtuellen Maschinen und Netzwerkmaschinen, zwischen einer lokalisierten Rechnerinstallation und einem Rechnernetz. Zwar besitzt die Netzwerkmaschine zu jedem Zeitpunkt einen definierten Zustand, dieser ist jedoch an keiner Stelle innerhalb oder außerhalb des Netzes vollständig und exakt bekannt. Wie bereits in Abb. 4.1-3 skizziert, besteht eine Netzwerkmaschine im allgemeinen aus einem Netz „tieferer" Netzwerkmaschinen, die ausschließlich über interne Nachrichtenströme miteinander kommunizieren. Informationen über Zustandsänderungen in einer dieser Netzwerkmaschinen können anderen Netzwerkmaschinen also bestenfalls mit der — endlichen — Geschwindigkeit der Nachrichtenübertragung im Netz bekannt werden. Damit kann jede der tieferen Netzwerkmaschinen allenfalls ihren eigenen aktuellen Zustand genau und vollständig kennen — und auch das nur, wenn sie selbst lokalisiert ist und nicht ihrerseits wieder aus noch tieferen Netzwerkmaschinen besteht. Über den momentanen Zustand aller anderen Netzteile kann sie allenfalls Vermutungen anstellen, die sich auf Informationen über vergangene Zustände gründen, jedoch nie sicher sind. Aus dieser unvermeidlichen Unkenntnis des genauen Zustands des Gesamtnetzes ergeben sich Forderungen für die Informations- und Steuerflußstruktur im Netz, die in konventionellen, lokalisierten Systemen nicht auftreten: — Das Zusammenarbeiten der einzelnen Netzwerkmaschinen wird umso besser sein, je schneller jede von ihnen über Zustandsänderungen in den anderen informiert wird. Die netzinternen Nachrichtenströme müssen deshalb — entweder als Beipack der zum Datentransport durch das Netz dienenden Nachrichten (Piggy Back) oder als spezielle Steuernachrichten - laufend möglichst

74

4. Netzwerkmaschinen und Netzzustände

viel Informationen über Zustand und Zustandsänderungen der einzelnen Netzteile vermitteln. — Keine Netzwerkmaschine kann sicher sein, daß eine andere eine von ihr übermittelte Nachricht auch erhält, versteht und bearbeitet. Deshalb muß eine Netzwerkmaschine jede korrekt empfangene Nachricht durch eine Quittung (Acknowledgement, ACK) bestätigen, entweder als Beipack zu einer in der Gegenrichtung laufenden Nachricht oder mit einer speziellen Quittungsnachricht. Bevor der Absender diese Quittung nicht erhalten hat, darf er die ursprüngliche Nachricht nicht vergessen, da er sie unter Umständen wiederholen oder auf einem anderen Weg weiterleiten muß. — An Hand dieser Quittungen müssen die korrespondierenden Netzwerkmaschinen die Synchronisation zwischen sich entsprechenden Zuständen aufrechterhalten. — Zwischen Netzwerkmaschinen muß immer auch ein Wiederaufsetz- Verfahren (Recovery Scheme) vereinbart werden. Dieses legt fest, auf welche Weise sich zwei Netzwerkmaschinen durch Rücksetzen auf einen früheren, beiden bekannten, gemeinsamen Zustand resynchronisieren können, wenn sich herausstellt, daß nicht behebbare Differenzen zwischen den tatsächlichen und den jeweils vermuteten aktuellen Zuständen aufgetreten sind. Die Absicherung eines zuverlässigen Nachrichtenverkehrs trotz der Unkenntnis des vollständigen aktuellen Zustands der Netzwerkmaschine erfordert also Verwaltungsaufwand: neben den eigentlich zu übertragenden Daten müssen zusätzliche Zustandsinformationen auf den Leitungen übermittelt und in den einzelnen Rechnern des Netzes ausgewertet und verarbeitet werden. Die Minimierung dieses Zusatzaufwands bei gleichzeitiger Maximierung der Ubertragungssicherheit und Übertragungsleistung für die Nutzdaten ist der wesentliche Gesichtspunkt bei dem Entwurf oder der Auswahl der Protokolle, der Regeln für den Nachrichtenverkehr zwischen zwei Partnern auf jeder Ebene der Netzwerkmaschinen-Hierarchie.

5. Protokolle

5.1 Die Protokollhierarchie im ARPA-Netz Die Hierarchie abstrakter Netzwerkmaschinen und der in ihnen zwischen Sendeund Empfangsports fließenden Nachrichten konkretisiert Abb. 5.1-1 am Beispiel des ARPA-Netzes [KLEI76]. Auf jeder Ebene wird der Informationsaustausch zwischen den Ports nach einem Satz von Regeln, dem Protokoll abgewickelt. Ein Protokoll besteht aus Vereinbarungen über — Übertragungsformate für die Informationseinheiten, — Wertebereiche und Interpretationsregeln für die Verwaltungs- und Priifinformationen, — Ablauf des Informationsaustauschs im Normalfall, — Sicherung und Fehlererkennung sowie den weiteren Verkehr nach Fehlererkennung (Abbruch, Wiederholung o. ä.), — Resynchronisierung und Wiederaufsetzverfahren bei Erkennen von Inkonsistenzen im Systemzustand, — Steuernachrichten für die Quittungsübermittlung, die Aktualisierung von Zustandsinformationen, Anforderung spezieller Funktionen u. ä. Ein wesentlicher Teil jedes Protokolls ist die Formatierung der Nachrichten in den zu übertragenden Text und die Steuer-, Verwaltungs- und Prüfinformationen, die in dem aus Kopf und ggf. Abschluß bestehenden Nachrichtenrahmen übermittelt werden. Der Text wird auf der jeweiligen Protokollebene grundsätzlich weder interpretiert noch verändert; für die nächst höhere Ebene zerfällt er jedoch seinerseits wieder in einen Nachrichtenrahmen zur Steuerung der höheren Netzwerkmaschine und den auf dieser Ebene zu vermittelnden Nutztext. Abb. 5.1-2 zeigt dies an den untersten Protokollebenen des ARPA-Netzes: je tiefer die Ebene, umso weiter außen liegen der zugehörige Kopf und — falls vorhanden — der Abschluß.

5.2 Die Protokolle des Datenübertragungs-Netzes Im ARPA-Netz wird die unterste Netzwerkmaschine durch das Datenübertragungs-Netz, die IMPs und deren Software realisiert. Nach dem IMP-IMP-Protokoll werden zwischen ihnen Pakete mit einer maximalen Länge von 1192 bit übertragen. Wie Abb. 5.1-2 zeigte, enthält der äußerste, dieser Ebene 0 zugeordnete

5. Protokolle

76 Netzhierarchieund ProtokollEbene

®

(und höher)

©

o ® : Protokoll Abb. 5.1-1 Hierarchie- und Protokoll-Ebenen im ARPA-Netz

Rahmen die hierfür nötigen Steuer- und Prüfinformationen. Von diesen 104 bit werden 72 bit bereits durch die Hardware erzeugt und ausgewertet. Auf diesem IMP-IMP-Protokoll baut als Ebene 1 das Ende-Ende-Protokoll zwischen Quell- und Ziel-IMP auf, welchem die Informationen im 80 Zeichen langen Paketkopf zugeordnet sind. Quell- und Ziel-IMP realisieren die Schnittstelle zur Netzwerkmaschine der Ebene 2, über welche die Kommunikation zwischen den jeweils angeschlossenen

•O W

o o

2

CU s N

93

•eho o 3 N

M CU •i P-

et
0

I

L.

I ggf. Füllbits | zur Anpassung an | Host-Wortlänge

.J

Abb. 5.2-1 Das Host-Host-Protokoll-Format des ARPA-Netzes

(72 bit)

5.3 Höhere Protokollebenen

79

Abb. 5.2-1 zeigt, wie hierauf Rücksicht genommen wurde. Jeder Nachricht ist ein Nachrichtenkopf von 72 bit vorangestellt — 72 bit deshalb, weil diese Länge sowohl üblichen 6 bit- oder 8 bit-zeichenorientierten Maschinen als auch Maschinen mit 12-, 24- oder 36-bit Wortlänge angepaßt ist. Der Nachrichtenkopf im Host-Host-Protokoll enthält — die „byte"-Größe (b) in Bit, wobei unter byte die vom sendenden Host benutzte Zeichen- oder Wortlänge verstanden wird, sowie — die „byte"-Anzahl (a) im Nachrichtentext. Der Ziel-Host kann daraus sowohl die Länge (a * b bit) des folgenden Textes als auch, wenn für Code-Wandlungen notwendig, seine Strukturierung entnehmen. Sofern eine Nachricht nicht mehr durch ein einzelnes Paket übermittelt werden kann, ist es Aufgabe des Quell-IMPs, sie in Pakete zu fragmentieren. Der ZielIMP übernimmt es, sie vor Übergabe an seinen Host wieder zu reassemblieren. Der Abwicklung des Host-Host-Protokolls dienen die NetzkommunikationsProgramme, welche im ARPA-Netz als Network Control Program (NCP) bezeichnet werden. Auf sie wird in Abschnitt 6.1 näher eingegangen.

5.3 Höhere Protokollebenen Das Host-Host-Protokoll ist die Grundlage der höheren Protokolle auf Ebene 3 für die Abwicklung der Interprozeß-Kommunikation. Diese Protokolle bilden im ARPA-Netz entsprechend Abb. 5.3-1 selbst wieder eine aufgabenorientierte Hierarchie. Sie werden ständig weiter ausgebaut und ergänzt: in Entwicklung sind ein Graphics-Protokoll, ein „Data Reconfiguration Services"-Protokoll zur Anpassung von Datenformaten an unterschiedliche Rechner und Aufgabenstellungen und ein „Mail"-Protokoll zur Übermittlung von Texten zwischen Benutzern. Wie man auf der Basis eines höheren Protokolls ein weiteres aufbauen kann, zeigt Abb. 5.3-2 an Hand einer einfachen Erweiterung des ARPA-TELNETProtokolls für die Übertragung sequentieller Text-Dateien [CROW72], Sie besteht aus zwei zusätzlichen TELNET-Kommandos, deren Funktion im Grunde das „Umlegen eines Schalters" von dem Benutzer-Terminal zu einer lokalen Datei ist: — SCRIPT lenkt einen ankommenden Zeichenstrom in die Datei und — SENDFILE sendet einen Dateiinhalt zeichenweise, als würde er gerade vom Terminal aus eingegeben.

80

5. Protokolle Fernstapelverarbeitung (Remote Job Entry Protocol)

Datentransfer (File Transfer Protocol)

Terminalbedienung und zeichenorientierter Dialog (Telecommunication Network Protocol)

Verbindungsaufbau zwischen Prozessen (Initial Connection Protocol)

Kommunikation zwischen NCPs (Host-Host-Protocol) Abb. 5.3-1 Höhere Protokolle im ARPA-Netz und ihre gegenseitige Abhängigkeit

BenutzerText-Datei

BenutzerTerminal Abb. 5.3-2 Einfacher Textdatei-Transfer mit Hilfe des erweiterten ARPA-TELNET-Protokolls

Für den abgesetzten Dienstleistungsprozeß, welcher eine korrespondierende Datei verwaltet, erscheint somit die Datei des Benutzers als „virtuelles ARPATerminal". Damit übernimmt das TELNET-Protokoll gegebenenfalls auch die aufwendige Codewandlung zwischen Rechnern mit unterschiedlicher Zeichendarstellung.

81

5.3 Höhere Protokollebenen

Inzwischen ist diese TELNET-Erweiterung zwar längst durch das wesentlich effizientere FTP ersetzt, entsprechende Lösungen werden aber immer wieder in Netzentwicklungen sinnvoll sein, wenn es gilt, möglichst rasch brauchbare Übergangsverfahren bereitzustellen. Abb. 5.3-3 zeigt die Struktur der höheren Protokolle im europäischen EIN-Netz. Die baumartige Hierarchie schafft klarere Abhängigkeiten und dürfte — wegen der Trennung in Dialog und Massendaten-Übertragung auf der ersten Hierarchiestufe — auch effizienter zu realisieren sein. Für den Benutzer und den Entwickler von Anwendungsprogrammen definieren diese höheren Protokolle die vom Netz realisierte „verteilte Maschine" und die von ihr bereitgestellten Dienstleistungen. Alle tieferen Ebenen dienen ausschließlich der Realisierung dieser an verschiedenen Orten implementierten funktionalen Ebene und sollten für jeden, der nicht als Systemprogrammierer unmittelbar an der Implementierung der Netzsoftware arbeitet, unsichtbar („transparent") sein. Die Verständlichkeit, Handhabbarkeit, Vollständigkeit und Sicherheit der höheren, anwendungsorientierten Protokolle ist entscheidend für den Einsatzwert und für die Leistungsfähigkeit eines Netzes: auch die effizientesten „tieferen" Protokolle sind schlecht, wenn sie nicht auf die Bedürfnisse der höheren abge-

FernstapelVerarbeitung (Remote Job Entry)

Terminal-Dialog (Virtual Terminal)

\ Dialogprotokoll okoll (Line Oriented Protocol)

\

/ N

Dateitransfer

Datenbasiszugriff

(File Transfer Protocol)

(Remote Data Base Access)

/

^

Host-Host

Abb. 5.3-3 Höhere Protokolle im EIN-Netz

Kommunikation zwischen )I ,„Transportstationen" , 1 IdJI.tf/V J (=NCPs)

82

5. Protokolle

stimmt sind. Sie lassen dann nur unzweckmäßige Realisierungen zu und zwingen Benutzer und Anwendungsprogrammierer auf Grund von Mißverständnissen oder mangelhaften Möglichkeiten zu ungünstigen Lösungen ihrer Kommunikationsprobleme.

5.4 Grundregeln für die Protokollplanung Die Planung eines Netzes sollte deshalb mit einer zumindest groben Spezifikation der anwendungsorientierten Protokolle beginnen. Das bereitzustellende Angebot umfaßt Protokolle zum - Vermitteln zwischen Prozessen und Verbindungsaufnehmen zwischen Ports zum Senden, Empfangen und Unterbrechen zu übertragender Nachrichten (ARPA: Initial Connection Protocol), - Benutzerdialog mit dem Netz und seinen Dienstleistungen (ARPA: TELNET Protocol, Remote Job Entry), - Übermitteln von Datenbeständen innerhalb des Netzes (ARPA: File Transfer Protocol, Data Reconfiguration Services), - Anfordern spezieller Netzdienstleistungen (ARPA: Graphics Protocol, Mail Protocol und experimentelle Protokolle für Sprachübertragung, Message Switching und Sonderwünsche spezieller Benutzergruppen). Die Forderung der Transparenz der tieferen Protokollebenen hat für den Entwurf der höheren eine wesentliche Konsequenz: der Benutzer oder Anwendungsprogrammierer sollte sich nicht Rechenschaft darüber geben müssen, ob sein Kommunikationspartner ein Prozeß auf dem gleichen oder einem fremden Host ist. Die Primitivoperationen sollten also denen einer normalen Interprozeß-Kommunikation oder Dienstleistungsanforderung in einem lokalisierten System entsprechen, also etwa aus einem OPEN, CLOSE, READ, WRITE, WAIT und ggf. noch einigen Steuer- und sonstigen Sonderfunktionen bestehen. Insbesondere muß aber bei höheren Protokollen das Vertrauensprinzip in die Rückmeldung gelten: erhält ein Prozeß eine positive Quittung aus dem zuständigen Port, so soll er sich darauf verlassen können, daß keine Diskrepanzen zwischen dem eigenen Zustand und dem seines Partners vorliegen, und daß er keine weiteren Kontrollen mehr vorzunehmen braucht. Dies ist der entscheidene Unterschied zwischen den höheren und tieferen Protokollebenen. Für das Host-Host-Protokoll und darunter liegende Ebenen bedeutet nämlich der Empfang einer Quittung in der Regel noch nicht, daß eine vollständige Synchronisation der Zustände aller bei der Übertragung mitwirkenden Systemkomponenten vorliegt, und daß die Gesamtübertragung bis zu diesem Zeitpunkt völlig fehlerfrei verlief. Auf den tieferen Ebenen können Nachrichten trotz korrekter Einzelquittung ausfallen, doppelt auftreten oder in ihrer Reihenfolge vertauscht werden. Es ist eine wesentliche Aufgabe der tieferen Netzwerkmaschinen, die jeweils von ihnen betreuten

5.5 Die Realisierung eines Protokolls

83

Ports so gut wie möglich von diesen Fehlern abzuschirmen. Das Protokoll muß durch entsprechende Sicherungen, wie Folgenumerierung und Zeitüberwachung, die Möglichkeit hierzu schaffen.

5.5 Die Realisierung eines Protokolls Ein Protokoll wird durch Prozeduren realisiert, welche auf den jeweiligen Rechnern als Softwarebausteine (Leitungsprozeduren) oder auch teilweise hardwareunterstützt (Übertragungssteuerung) ablaufen. Die Sendeprozedur übernimmt den zu übertragenden Text. Sie hat die Aufgabe, ihn in den Nachrichtenrahmen (Startzeichen, Kopf, Prüfzeichen u. ä.) einzuschließen. Die Empfangsprozedur muß den Nachrichtenrahmen interpretieren und den übermittelten Text zur Weiterverarbeitung zur Verfügung stellen. Abb. 5.5-1 zeigt als einfaches Beispiel das BSC-Protokoll, welches u. a. im ARPA-Netz als IMP-IMP-Protokoll benutzt wird (vgl. Abb. 5.1-2). Ein zu übertragender Block wird mit SYN-Zeichen zur Synchronisation von Sender und Empfänger eingeleitet. Die Zeichenkombination DLE STX (Data Link Escape und Start of Text) kündigt den Beginn des eigentlichen Textes an. Das Ende des Textes zeigt die Kombination DLE ETX {Data Link Escape und End of Text) an. Anschließend folgt noch die 24 bit lange Prüfsumme. Der Text selbst wird vom Protokoll grundsätzlich als Zeichenkette angenommen, auch wenn er „in Wirklichkeit" eine anders strukturierte Bitkette ist. In dieser könnte jedoch zufällig die Zeichenkombination DLE ETX vorkommen, welche vom Empfänger als Textende mißverstanden würde. Um dies zu vermeiden, setzt die Sendeprozedur grundsätzlich vor jedes zufällig im Text auftretende DLEZeichen ein weites, welches der Empfänger wieder entfernen muß. Protokolle, welche auf diese oder ähnliche Weise (z. B. Einschieben von einzelnen Bits bei der HDLC-Prozedur) eine Übertragung jedes beliebigen Textes ohne Verwechslungsgefahr mit Steuerinformation ermöglichen, werden transparent genannt. Wahrend des Sendens oder Empfangens eines Datenblocks müssen die miteinander kommunizierenden Prozeduren eine Reihe von Zuständen durchlaufen, in welchen jeweils bestimmte Aktionen ausgeführt werden (z. B. Zeichen lesen, Textzeichen abspeichern). Die Abfolge dieser Aktionen wird durch die gemäß dem Protokoll als nächste gesendeten oder in der Nachricht empfangenen Zeichen gesteuert. Abb. 5.5-1 zeigt auch das Zustandsdiagramm für die BSC-Empfangsprozedur. Die Zustandsdiagramme beschreiben das jeweilige Protokoll und sind gleichzeitig Ausgangspunkt für seine programmtechnische Realisierung [SCHN75] — eine fachmännisch implementierte Übertragungsprozedur wird immer als endlicher Automat geplant. Sie wird meist durch eine Tabelle der einzelnen Zustände und der in ihnen auszuführenden Aktionen (Unterprogramme) sowie durch die

84

5. Protokolle

auszusendenden oder empfangenen Zeichen getrieben. Dabei durchlaufen ihre Zustände das Zustandsdiagramm gemäß Abb. 5.5-1. Sind die Protokolle als endliche Automaten beschrieben, so ist die Programmierung der zu ihrer Abwicklung nötigen Prozeduren weitgehend Routine. Die in

5.5 Die Realisierung eines Protokolls

85

der Praxis oft beträchtlichen Realisierungsschwierigkeiten entstehen in der Regel entweder aus Unklarheiten in der Protokolldefinition, vor allem in der Beschreibung der Fehler- und Ausnahmezustände, oder aus Zeitproblemen: häufig sind der empfangende Rechner und die auf ihm laufende Prozedur nicht schnell genug, die ankommende Bit- oder Zeichenkette abzuarbeiten. Das Programm muß dann oft „trickreich" optimiert werden. Darunter leiden wieder die klare Strukturierung, die Fehlerfreiheit und die Anpassungsfähigkeit bei Änderungen oder Erweiterungen der Prozedur. Auch und gerade bei der Entwicklung der Datenübertragungsprozeduren rächt sich jedes Abgehen von der konsequenten Top Down-Planung und -Realisierung. Es fuhrt zu unzuverlässiger Software und teurer Fehlersuche und Wartung. Erst nach exakter und vollständiger Definition der Aufgabenstellung — hier der Protokolle und der sie beschreibenden Zustandsdiagramme — darf mit der Realisierung begonnen werden. Eine Optimierung ist erst dann möglich, wenn auf der Grundlage dieser Zustandsdiagramme einwandfrei strukturierte, korrekte und übersichtliche Programme für die Prozeduren vorliegen.

6. Die Netzschnittstelle und die Flußsteuerung

6.1 Das Netz-Kommunikationsprogramm Bereits im ersten Kapitel idealisierten wir ein Rechnernetz als eine Menge von Verarbeitungsprozessen auf Hosts und Terminalprozessen mit einem Kommunikations-Subsystem. Dieses ist in der Regel als räumlich verteilte Netzwerkmaschine aus einzelnen Knotenrechnern, den IMPs, realisiert und übernimmt die Nachrichtenvermittlung. Zwischen Verarbeitungs- und Terminalprozessen auf der einen Seite und dem Kommunikations-Subsystem auf der anderen existiert eine Schnittstelle, welche durch ein Softwaresystem überbrückt werden muß. Für dieses überwiegend auf den Hosts, manchmal teilweise auch auf Vorrechnern oder IMPs realisierte Programmsystem gibt es eine Reihe von Bezeichnungen. Die häufigsten sind — Network Control Program, NCP (ARPA-Netz), — Transportstation, TS (CYCLADES). Wir wollen hier die gebräuchliche Abkürzung NCP übernehmen und sie als NetzKommunikationsprogramm interpretieren. Die Aufgabe des Netz-Kommunikationsprogramms ist es — den Prozessen Schnittstellen (Ports) für die Abwicklung der höheren Protokolle zur Interprozeß-Kommunikation zur Verfügung zu stellen, — diese mit Hilfe des niedrigeren Host-Host-Protokolls möglichst effizient über die Netzschnittstelle zu realisieren, — die höheren Prozesse gegen wechselnde Übertragungscharakteristiken und Übertragungsfehler im Netz abzuschirmen und — Steuer- und Betriebsmittelverwaltungsfunktionen sowohl für die betreuten Prozesse als auch für das Netz wahrzunehmen. Für die Implementierung dieses Netz-Kommunikationsprogramms in einem bereits bestehenden Host-System gibt es die beiden Alternativen, welche Abb. 6.1-1 zeigt. Es kann (ä) entsprechend den Zugriffsmethoden zur lokalen Peripherie in das Betriebssystem eingefügt werden oder (b) als „privilegierter Verarbeitungsprozeß" die empfangenen und auszusendenden Daten mit den eigentlichen, von ihm bedienten Verarbeitungsprozessen über die Interprozeß-Kommunikation des Betriebssystems austauschen.

87

6.1 Das Netz-Kommunikationsprogramm

© /" ( V

N/' "V Verarbeitungsprozesse ^v >-v

N ) V

V

V

-

L-V r

Betriebssystem f

1. CP fj

^

Kommunikations-Subsystem

Abb. 6.1-1 Alternative Realisierungsmöglichkeiten eines Netz-Kommunikationsprogramms: (ä) als Teil des Host-Betriebssystems (Zugriffsmethode) ©

als privilegierter Verarbeitungsprozeß

Die Möglichkeit(a)erfordert Eingriffe in das Hersteller-Betriebssystem des HostRechners und ist daher verhältnismäßig mühsam zu implementieren. Die einfachere Realisierungsmöglichkeit® bringt andererseits durch den zeitaufwendigen Nachrichtenaustausch zwischen NCP und Verarbeitungsprozessen Verzögerungen, die zuweilen die Größenordnung von einer Sekunde erreichen können und deshalb meist nur bei vorläufigen „Experimentierlösungen" tragbar sind. Oft wird ein Kompromiß zwischen beiden Alternativen gewählt, wobei die zeitkritischen Aufgaben als Teile des Betriebssystems, die übrigen jedoch auf der Ebene der Anwendungsprozesse realisiert werden. Die Struktur einer derartigen Netzschnittstelle zeigt Abb. 6.1-2. Es handelt sich hierbei um den Anschluß von PDP 11-Rechnern unter dem UNIX-Betriebssystem an das ARPA-Netz [CHES75]. Das Netz-Kommunikationsprogramm ist aufgeteilt in einen arbeitsspeicherresidenten Kern und einen nichtresidenten Dämon, welcher logisch und programmtechnisch auf gleicher Ebene wie die betreuten Verarbeitungsprozesse steht. Er übernimmt ohnehin zeitaufwendige oder seltene Steuerungsfunktionen, wie etwa OPEN und CLOSE von Verbindungen oder die Aktualisierung von Tabellen. Man kann ihn als Dienstleistungsprozeß für die Verwaltung der Host-Netz-Schnittstelle betrachten. Der Kern des NCP ist kein Prozeß sondern ein Satz von Routinen zur Unterbrechungsbehandlung der angeschlossenen Datenübertragungshardware. Wie

88

6. Die Netz Schnittstelle und die Fluß Steuerung

Abb. 6.1-2 Programmstruktur der UNIX-Netz-Schnittstelle (NCP = residenter Kern und nichtresidenter Dämon)

Tabelle 6.1-4 Codeumfang einiger „Transportstationen" (Netz-Kommunikationsprogramme) im CYCLADES-Netz (private Mitteilung von L. Pouziri). Hardware

Codeumfang

Leistungsmerkmale

Großrechner: CII IRIS 80 IBM / 360

24 k Byte 28 k Byte

dynamische Port- und Pufferverwaltung

Kleinrechner: CII IRIS 50

8 k Byte

feste Ports, keine dynamische Pufferverwaltung

intelligentes Terminal: TVT 6000

1,6 k Byte

1 Port

6.1 Das Netz-Kommunikationsprogramm

89

Abb. 6.1-3 Funktionen des Kerns des NCP

Abb. 6.1-3 zeigt, nimmt er von ihr einerseits Einzelzeichen oder Zeichengruppen (z. B. Worte, Pakete) entgegen, um aus ihnen Nachrichten für die Verarbeitungsprozesse aufzubauen; andererseits zerlegt er von den Verarbeitungsprozessen übergebene Ausgabenachrichten in Einzelzeichen oder Zeichengruppen für die Datenübertragung. Dabei ist er auch für Behandlung der nötigen Steuerzeichen und Steuernachrichten zuständig.

90

6. Die Netzschnittstelle und die Flußsteuerung

Je nach den Anforderungen an ein Netz-Kommunikationsprogramm kann seine Komplexität und damit die Programmgröße sehr unterschiedlich sein. Vor allem kommt es hierbei darauf an, welcher Aufwand für die Port- und Pufferverwaltung getrieben wird. Tabelle 6.1-4 (S. 88) zeigt dies an einigen realisierten Transportstationen (NCPs) des CYCLADES-Netz.

6.2 Netzüberlastung und BetriebsmittelverwaltungsStrategien An der Netzschnittstelle tritt erstmals ein Problem auf, welches die gesamte niedere Netzhierarchie durchzieht, und mit welchem sich der Entwickler auf jeder Ebene der Netzplanung erneut auseinandersetzen muß: die Flußsteuerung (.Flow Control). Anschaulich handelt es sich um das Vermeiden einer Überlastung des Empfängers oder des Übertragungsmediums, sei es einer Einzelleitung oder des Kommunikations-Subsystems, durch eine zu schnelle Nachrichtenabgabe des Senders. Eine Überlastung (Congestion) ist in einem Netz wesentlich gefährlicher als in einer lokalisierten EDV-Installation; bei ihr führt nämlich eine Erhöhung der Belastung lediglich zu einer etwa proportionalen Verlängerung der mittleren Wartezeiten und wirkt damit selbstregulierend. Im Kommunikations-Subsystem hingegen gehen diejenigen Nachrichten verloren, die von ihrem Empfänger — einem IMP oder dem Ziel-Host - nicht angenommen werden können. Sie müssen nach einiger Zeit wiederholt werden, was die Netzbelastung weiter erhöht und so lawinenartig zu einem überraschenden Zusammenbruch der gesamten Nachrichtenübermittlung fuhren kann. Von einem allgemeineren EDV-technischen Standpunkt aus betrachtet ist die Flußsteuerung ein Teilproblem der Regelung des Wettbewerbs verschiedener Prozesse um einen beschränkten Vorrat an Betriebsmitteln, und zwar deijenigen, die für die Nachrichtenübertragung benötigt werden. Dies sind Puffer und Rechnerkapazität in IMPs und Hosts sowie die Übertragungsleitungen. Neben der primären Aufgabe jeder Flußsteuerung, der Vermeidung einer wesentlichen Verschlechterung der Übertragungsleistung eines Netzes oder gar seiner völligen Blockierung (Deadlock) durch Überlastungen, sind bei ihrer Planung noch einige sich teils widersprechende Sekundärziele zu beachten und gegeneinander abzuwägen: — die optimale Auslastung der zur Verfugung stehenden Betriebsmittel, — die faire Zuteilung der Übertragungsleistung und -betriebsmittel an die einzelnen Prozesse oder Hosts, ggf. unter Berücksichtigung bestimmter Informationen, wie etwa Rückmeldungen odep Nachrichten zur Netzsteuerung, — maximaler Durchsatz für alle oder ausgewählte Nachrichtenströme im Netz, — minimale Antwortzeiten, besonders für interaktiven Nachrichtenverkehr.

91

6.2 Netzüberlastung und Betriebsmittehrerwaltungs-Strategien

In Kapitel 3 hatten wir das Netz auf jeder Ebene der Top Down-Entwicklung als eine Netzwerkmaschine idealisiert, die aus Ports Nachrichten entgegennimmt und an andere übermittelt. Entsprechend Abb. 6.2-1 sind dabei folgende Betriebsmittel zu verwalten: die Übertragungs- und Verarbeitungskapazität der Netzwerkmaschine und des Empfängers sowie die Puffer von Sender, Empfänger und Netzwerkmaschine. Die Pufferkapazität der Netzwerkmaschine braucht dabei nicht ausschließlich durch physikalische Puffer in IMPs realisiert zu sein. Auch die zu jedem Zeitpunkt gerade auf Übertragungsmedien transportierten Nachrichten sind in der Netzwerkmaschine gespeichert. Vor allem bei Satellitenübertragungen mit Signallaufzeiten von ca. 1/4 sec ist die Speicherkapazität des Übertragungskanals selbst beträchtlich. Nach Abb. 6.2-1 gibt es drei an der Flußsteuerung beteiligte Instanzen und damit drei sich in der Verantwortungsverteilung unterscheidende Grundstrategien. Entweder (T) müssen Netzwerk(maschine) und Empfänger die Übernahme jeder Nachricht garantieren oder (2) der Sender darf nur soviel Nachrichten abgeben, wie Netzwerk(maschine) und Empfänger aufnehmen können oder (3) Sender, Netzwerk(maschine) und Empfänger arbeiten jeweils mit ihrer maximalen Geschwindigkeit, und jede Nachricht, welche die Übertragungskapazität überschreitet, geht verloren und muß bei Ausbleiben der Bestätigung durch den Sender wiederholt werden. AusgabePorts

EingabePorts

Host

gesamtes Kommunikations-Subsystem

Host

IMP

Unternetz oder Leitung

IMP

Abb. 6.2-1 Sender, Netzwerkmaschine und Empfänger als Betriebsmittel der Nachrichtenübertragung

92

6. Die Netzschnittstelle und die Fluß Steuerung

Die Strategie (T) ist in der Regel nicht zuverlässig realisierbar. Die Wahl zwischen den beiden anderen sollte durch die gewünschte Übertragungseigenschaften des Netzes bestimmt werden. Die Strategie(2), die Steuerung der Sendegeschwindigkeit entsprechend der vorhandenen Übertragungs- und Verarbeitungskapazität, optimiert die Ausnutzung der verfugbaren Betriebsmittel und gibt damit die Möglichkeit, den Gesamtdurchsatz des Rechnernetzes vor allem für längere Nachrichtenströme zu maximieren. Dies erfordert jedoch Anfragen des Senders an Netzwerkmaschine und Empfänger über deren Aufnahmefähigkeiten zu jedem Zeitpunkt. Da diese Anfragen zeitraubend sind, erhöhen sie die Wartezeit für kurze, interaktive Nachrichten. Strategie das Senden und Übertragen mit höchstmöglicher Geschwindigkeit, hat diesen Nachteil nicht, zumindest solange Netz und Empfänger nur schwach belastet sind. Für Netze, bei welchen geringe Übertragungs- und Antwortzeiten für kurze Nachrichten das primäre Entwurfsziel sind, wird deshalb die dritte Flußsteuerungsstrategie bevorzugt. Allerdings muß dann eine schnelle und ausgeprägte Verschlechterung der Übertragungseigenschaften bei Überlastung in Kauf genommen werden. Zuweilen werden auch Mischstrategien benutzt, wobei für die Übertragung von Massendaten, wie etwa den Dateitransfer, eine durchsatzoptimierte, für kurze, interaktive Nachrichten jedoch eine antwortzeitoptimierte Flußsteuerung implementiert wird. Da beide Datenverkehrsarten sich jedoch gegenseitig beeinflussen, wenn sie das gleiche Netz benutzen, ist die Realisierung solcher Kompromißlösungen keineswegs problemlos.

6.3 Grundverfahren der Flußsteuerung Unabhängig von der verwendeten Strategie und der jeweils betrachteten Ebene setzt jede Flußsteuerung Informationen über den momentanen Zustand der Sender, der Empfänger und der Netzwerkmaschine voraus. Je nachdem, wo und wie diese Informationen gesammelt, verwaltet und verteilt werden, unterscheidet man die zentralisierte, die globale und die lokale Flußsteuerung. Bei der zentralisierten Flußsteuerung ist ein zentraler Steuerrechner für die Überwachung des Gesamtnetzes und die Zuteilung der Betriebsmittel verantwortlich. Dieses Verfahren ist nur dann praktikabel, wenn durch die Netzgeometrie bereits ein Rechner als zentraler Netzknoten ausgezeichnet ist. Da über ihn der gesamte Nachrichtenverkehr läuft, kann er damit auch diese Aufgabe auf natürliche Weise übernehmen. In anderes strukturierten Netzen scheitert eine zentralisierte Flußsteuerung meist an den aufwendigen Auslastungsberechnungen für das Gesamtnetz, der zu großen Netzbelastung durch die erforderlichen Steuernachrichten zwischen Hosts, Knoten und zentralem Steuerrechner, der durch die Nachrichtenlaufzeit verursachten Trägheit der Anpassung an wechselnde Belastungszustände und den Problemen der Übernahme der Steuerungsaufgabe bei Ausfall des zentralen Steuerrechners.

6.3 Grundverfahren der Fluß Steuerung

93

All diese praktischen Schwierigkeiten bei der Realisierung einer zentralisierten Flußsteuerung haben letztlich ihre Ursache darin, daß die in Abb. 6.2-1 gezeigte Netzwerkmaschine nur bei einfachen Sternnetzen ein einziger, lokalisierter Rechner ist. Bei komplizierter strukturierten Netzen ist sie selbst wieder ein Netz hierarchisch tieferer Netzwerkmaschinen, z. B. der einzelnen IMPs. Damit hat sie zwar zu jedem Zeitpunkt einen definierten Zustand, dieser ist aber an keiner Stelle im Netz exakt bekannt. Deshalb gibt es auch keine Stelle im Netz, welche die Funktion einer zentralen Steuerung übernehmen kann, die ja eine vollständige und aktuelle Information über den gesamten Netzzustand voraussetzt. Um diese grundsätzliche Schwierigkeit zu umgehen, kann man zwei Ausgangspunkte wählen: — Man kann die Netzwerkmaschine als „schwarzen Kasten" ansehen und sich auf die Aussagen beschränken, die man global über ihre Aufnahmefähigkeit für Nachrichten und ihr Verhalten an den Netzschnittstellen machen kann, ohne genaue Kenntnisse über ihren aktuellen Zustand zu besitzen. — Man kann aber auch die Netzwerkmaschine in ihre tiefsten Komponenten aufspalten, etwa in die einzelnen IMPs und die Übertragungsleitungen zwischen ihnen, und es jedem IMP überlassen, lokal den Nachrichtenfluß zwischen sich und seinem nächsten Nachbarn zu optimieren. Dementsprechend unterscheidet man zwei weitere Grundverfahren der Flußsteuerung, von denen es jeweils eine Reihe von Varianten gibt. Die globale Flußsteuerung basiert auf der Kenntnis der gesamten Aufnahmefähigkeit des Netzes und versucht, die Zahl der Nachrichten im Netz entsprechend zu beschränken. Da dies zwangsläufig an der Netzschnittstelle der Hosts im Rahmen des Host-Host- oder Host-IMP-Protokolls geschehen muß, ist die globale Flußsteuerung primär auch für eine faire Verteilung der Übertragungsleistung des Netzes an die einzelnen Hosts und gegebenenfalls für eine gewollte Bevorzugung bestimmter Nachrichten verantwortlich. Die lokale Flußsteuerung beruht hingegen auf den Informationen, die jeder IMP über den aktuellen eigenen Belastungszustand, die gerade ankommenden und abgehenden Nachrichten, den Zustand seiner unmittelbaren Nachbarn und den vermuteten Zustand des Gesamtnetzes hat. Diese Informationen hält er in Tafeln, die er mit Hilfe eines ständigen Austauschs von Steuernachrichten mit seinen Nachbarn periodisch aktualisiert. Die lokale Flußsteuerung ist damit zugleich auch für eine optimale Auslastung der einzelnen Betriebsmittel des Netzes sowie für die Vermeidung lokaler, gegenseitiger Blockierungen von IMPs zuständig. Da globale und lokale Flußsteuerungsverfahren somit verschiedene Ausgangspunkte und Zielrichtungen haben, müssen sie in der Regel kombiniert werden, um ein optimales Netzverhalten zu erzielen. Deshalb kann bei der Top DownPlanung eines Netzes die Flußsteuerung nicht auf einer bestimmten Netzwerkmaschinen- oder Protokoll-Ebene abgehandelt werden. Sie muß vielmehr auf jeder Planungsstufe erneut mit jeweils anderen Forderungen und Zielen überdacht und gelöst werden.

94

6. Die Netzschnittstelle und die Fluß Steuerung

6.4 Globale Flußsteuerungen auf Verbindungsbasis Auf der Ebene des Host-Host-Protokolls und der Netzschnittstelle eines Hosts ist lediglich die globale Flußsteuerung von Bedeutung. Sie geht meist entsprechend Abb. 6.2-1 von der durch die Netzwerkmaschine hergestellten realen oder virtuellen Verbindung zwischen zwei miteinander kommunizierenden Hosts aus. Die Ende-Ende-Steuerung (End to End-Control) nimmt an, daß diese Verbindung zu jedem Zeitpunkt einschließlich der im Empfänger noch unverarbeitet zwischengepufferten Informationen nur eine bestimmte Datenmenge fassen kann [HERR76, KAHN72], Die Steuerung des Datenflusses kann dann auf unterschiedliche Weise erfolgen. Im ARPA-Netz hat der empfangende Host die Führung: entsprechend seiner Pufferkapazität autorisiert er den Sender über Albcation-Nachrichten von Zeit zu Zeit, eine bestimmte Maximalzahl weiterer Nachrichten und Bits zu senden. Der Sender fuhrt für jede Verbindung Zähler für die ihm zugebilligten Nachrichten und Bits. Diese zählt er bei jeder Allocation-Nachricht hoch und bei jeder abgesandten Nachricht wieder herunter. Steht einer der Zähler auf 0, so muß der Sender bis zur nächsten Allocation-Nachricht vom Empfänger aussetzen. Dieser Mechanismus ist zwar sehr plausibel, er hat aber einen wesentlichen Mangel. Gehen Allocation-Nachrichten verloren, so sind Sender und Empfänger in Bezug auf die Flußsteuerung nicht mehr synchronisiert, und die Sendegeschwindigkeit wird unnötig herabgesetzt. Im Extremfall kann die Übertragung sogar völlig zum Erliegen kommen: ob der Sender schweigt, weil er zur Zeit keine zu übermittelnden Daten mehr hat, oder weil keine Allocation-Nachrichten bei ihm angekommen sind, kann der Empfänger nicht unterscheiden. Weder Sender noch Empfänger bemerken den Verlust und sehen deshalb auch keinen Grund, sich zu resynchronisieren. Ist ein Protokoll gegen Übertragungsfehler empfindlich, so spricht man von mangelnder Robustheit. Einen wesentlich robusteren Flußsteuerungsmechanismus ermöglichen Laufmimmern (Sequence Numbers) für die Nachrichten sowie Übertragungsfenster (Windows) bei Sender und Empfänger. Hierbei gibt der Sender jeder Nachricht als „Namen" eine sequentiell aufsteigende Laufnummer. Der Empfänger meldet jeweils die höchste Laufnummer zurück, bis zu der er alle Nachrichten vollständig empfangen hat. Dabei wird die Möglichkeit berücksichtigt, daß Nachrichten auf Grund unterschiedlicher Wege durch das Übertragungsnetz beim Empfänger in anderer Reihenfolge eintreffen, als sie ausgesandt wurden. Abb. 6.4-1 skizziert das Verfahren. Dabei ist angenommen, daß im Nachrichtenkopf 4 bits für die Laufnummern vorgesehen sind, so daß für die Nachrichten als Namensraum die Nummern 0 bis 15 zur Verfugung stehen; nach Erreichen der Laufnummer 15 wird mit 0 wieder neu begonnen. Die Beschränkung des

6.4 Globale Flußsteuerungen auf Verbindungsbasis

x

95

ACK 3 + 4

Abb. 6.4-1 Laufnummern und Übertragungsfenster

Nachrichtenstromes zwischen Sender und Empfänger wird durch ein „Fenster" bestimmt, das Sender und Empfänger über diesen zyklischen Namensraum „weiterschieben". In Abb. 6.4-1 ist die Breite dieses Fensters mit 5 angenommen, so daß zu jedem Zeitpunkt maximal fünf unbestätigte Nachrichten unterwegs sein können. Auf der Abbildung hat der Sender die Nachrichten 3 bis 6 bereits abgesandt und baut 7 zum Senden auf. 3 und 4 hat der Empfänger bereits erhalten und bestätigt sie gerade, 5 und 6 sind (in der Netzwerkmaschine) unterwegs. Der Sender kann die Nachricht 7 noch abschicken, muß dann aber eine Bestätigung abwarten. Sobald die Quittung für die Nachrichten 3 und 4 eingetroffen ist, schiebt der Sender sein Fenster weiter; er kann jetzt auch 8 und 9 aufbauen und absenden. Die bestätigten Nachrichten 3 und 4 braucht er nicht mehr zwischenzupuffern, da ihr Verlust und eine Wiederholungsnotwendigkeit nicht mehr zu befürchten sind. Der Empfänger seinerseits ist verpflichtet, eine der Fensterbreite entsprechende Pufferzahl zur Verfügung zu halten. Die Bestätigung der Nachrichten 3 und 4 bedeutet zugleich, daß er sein Fenster für Nachricht 5 bis 9 geöffnet hat und sie bei ihrem Eintreffen sicher aufnehmen kann. Dieser Flußsteuerungsmechanismus ist robust gegen jeden Übertragungsfehler. Die Fensterbreite wird einmal entweder für das gesamte Netz oder zwischen den

96

6. Die Netzschnittstelle und die Fluß Steuerung

Hosts für die jeweilige Verbindung vereinbart und bleibt dann konstant. Das Umlaufen der Fenster bei Sender und Empfänger wird automatisch synchronisiert. Geht eine Nachricht verloren, so hält das Sende-Fenster wegen des Ausbleibens der Quittung bei ihr an, und der Sender wiederholt auf Grund der Zeitüberschreitung (Time Out) die unbestätigten Nachrichten. Eine verlorene Quittung stört ebenfalls nicht. Entweder merkt der Sender an einer Bestätigung für eine höhere Laufnummer, im Beispiel von Abb. 6.4-1 etwa an einer Quittung für Laufnummer 5, daß auch die vorhergehenden Nachrichten angekommen sind, oder er wiederholt seine Nachrichten ab der ersten unbestätigten Laufnummer und zwingt damit den Empfänger zu einer neuen Bestätigung. Der Empfänger erhält zwar auf diese Weise unter Umständen mehrmals dieselbe Nachricht. Laufnummer und Fenster sorgen aber dafür, daß Duplikate nicht irrtümlich für neue Nachrichten gehalten werden. Es muß lediglich darauf geachtet werden, daß die Breite des Fensters wesentlich kleiner ist als der gesamte durch die Laufnummern aufgespannte Namensraum - 0 bis 15 im Beispiel von Abb. 6.4-1. Andernfalls könnte es vorkommen, daß ein Duplikat, welches sich im Netz „verlaufen" hat und mit sehr großer Verspätung beim Empfanger eintrifft, bereits wieder ein offenes Fenster für seine Laufnummer vorfindet und für das erste Exemplar dieser Nummer aus dem nächsten Zyklus gehalten wird. Ist dies bei sehr weitverzweigten Netzen zu befürchten, so kann es zweckmäßig sein, Nachrichten mit einem Zeitstempel oder einem Laufzeitzähler zu versehen und sie nach einer bestimmten maximalen Übertragungszeit zu vernichten.

6.5 Globale Flußsteuerungen auf Nachrichten- oder Paketbasis Flußsteuerungsmechanismen, welche entsprechend Abb. 6.2-1 ausschließlich die in der Netzwerkmaschine aufrechterhaltenen Einzelverbindungen berücksichtigen, können auch nur den Nachrichten ström auf diesen einzelnen Verbindungen begrenzen. Einer Überlastung des Netzes durch eine starke allgemeine Zunahme des Verkehrs läßt sich auf diese Weise nicht vorbeugen. Einen einfachen Schutz gegen überraschende Überlastung des Gesamtnetzes ermöglicht hingegen die Nachrichtenvermittlung (Message Switching) [WALD72], die oft auch als Datagramm- Vermittlung bezeichnet wird [POUZ76]. Bei ihr wird nicht von einer stehenden virtuellen Verbindung zwischen den Hosts ausgegangen. Vielmehr wird für jede zu übertragende Nachricht vom Netz eine Verbindung aufgebaut. Das Kommunikations-Subsystem garantiert dabei weder die rechtzeitige Abnahme, die korrekte Zustellung oder die Übermittlungsreihenfolge der zu übernehmenden Nachrichten. In diesem Fall ist die Nachricht auch die zweckmäßige Einheit für die Flußsteuerung. Sie wird nur dann vom Netz dem Sender abgenommen und an den Empfänger weitergeleitet, wenn im Netz und im Empfänger die hierzu nötigen Pufferkapazitäten zur Verfugung stehen. Andernfalls muß der Sender sie nach einiger Zeit wiederholen.

6.5 Globale Flußsteuerungen auf Nachrichten- oder Paketbasis

97

Eine Nachrichtenvermittlung hat für das Host-Host-Protokoll eine Reihe von Vorteilen. — Für den Aufbau einer Verbindung ist nicht wie im ARPA-Netz ein vordefinierter Port nötig. — Das Gesamtverfahren, die Pufferverwaltung, die Verwaltung der Ports und damit das Netzkommunikationsprogramm in den Hosts ist einfach und damit auch auf kleinen Rechnern mit wenig Aufwand realisierbar. — Das Protokoll ist sehr robust, da keine Synchronisation zwischen Sender und Empfänger nötig ist. In Fehlerfall wird die Verbindung einfach erneut aufgebaut und die Nachricht wiederholt. — Wegen der kurzlebigen Verbindung ist das Übertragen eines Ports auf einen anderen Host, etwa bei Ausfall einer Dienstleistung oder bei Wechsel des Bearbeiters an ein anderes Terminal, problemlos möglich. — Der aus Gründen der Ausfallsicherheit wünschenswerte Anschluß jedes Hosts an zwei oder mehr IMPs ist einfacher zu realisieren als bei stehenden Verbindungen. Diesen Vorteilen steht als einziger Nachteil der Aufwand für den Neuaufbau der Verbindung vor jedem Nachrichtenaustausch gegenüber. Bei längerfristig stehenden, nicht nur für die Einzelnachricht durchgeschalteten Verbindungen zwischen Hosts ermöglicht die isarithmetische Flußsteuerung [DAVI72] eine Regelung der Gesamtbelastung des Netzes. Ihr liegt die Vorstellung zu Grunde, daß die gesamte Transportkapazität des Netzes durch eine bestimmte Anzahl von „Behältern" für zu befördernde Daten repräsentiert wird. Diese verkehren im Netz ähnlich wie Taxis in einer Stadt. Manche sind mit Nachrichten „besetzt", die sie vom Sender zum Empfänger befördern. Andere warten an „Halteplätzen", den einzelnen IMPs, auf Kundschaft. Dabei kann die normalerweise an einem bestimmten Halteplatz wartende Taxi-Anzahl je nach dem erwarteten Verkehrsaufkommen, etwa entsprechend der Zahl und Aktivität der angeschlossenen Hosts, unterschiedlich sein. Taxis, die am Ziel ihres Nachrichtentransports eine überdurchschnittliche Zahl von bereits wartenden vorfinden, begeben sich leer zu Nachbarstandplätzen, um so einer Massierung freier Transportkapazität an einem Punkt vorzubeugen. Das gleiche tun Taxis, die auf Grund eines geringen Verkehrsaufkommens an ihrem Standort schon lange gewartet haben. Eine Nachricht oder ein Datenpaket kann nur dann vom Sender zum Empfänger befördert werden, wenn die Netzwerkmaschine am Absendeport, also etwa im IMP des sendenden Hosts, über ein freies „Taxi" verfügt. Andernfalls muß sein Eintreffen abgewartet werden. Selbstverständlich sind diese „Taxis" für Nachrichten in der Regel keine physikalisch vorhandenen Leer-Nachrichten. Sie sind vielmehr durch Zähler in den IMPs repräsentierte Anrechte (Capabilities) zum Nachrichtentransport. Zwischen

98

6. Die Netzschnittstelle und die Flußsteuerung

IMPs weitertransportiert werden sie in den Köpfen von Steuer- oder Nutznachrichten. Lediglich in Ringnetzen wird zuweilen ein fester, nach einem geregelten Takt gleichförmig umlaufender Strom von vorformatierten leeren Nachrichtenrahmen aufrechterhalten. Am Sendeort werden sie mit den zu übermittelnden Daten gefüllt und nach Erreichen des Empfängers wieder zur erneuten Benutzung freigegeben. Die isarithmetische Flußsteuerung begrenzt die Zahl der maximal im Netz laufenden Nachrichten auf die der insgesamt vorhandenen Transportanrechte, unabhängig von der Zahl und dem Datenaufkommen der einzelnen Host-HostVerbindungen. Sie arbeitet allerdings auch rein statistisch: Kommt es zufällig zu einer Konzentrierung des im Netz fließenden Nachrichtenstrom in einem lokalisierten Unterbereich, dann konzentrieren sich dort auch die Anrechte. So kann eine örtliche Überlastung auftreten, während andere Teile des Netzes wegen Mangel an Transportkapazität nicht ausgelastet werden. Ein weiterer Nachteil der isarithmetischen Flußsteuerung ist ihre mangelnde Robustheit. Werden auf Grund eines Fehlers irgendwo im Netz irrtümlich Anrechte erzeugt oder vernichtet, so bricht der Betrieb nach einiger Zeit wegen Überlastung des Kommunikations-Subsystems oder Versiegen der Transportkapazität zusammen. Die Zahl der im Netz verkehrenden „Taxis" muß deshalb auf irgendeine Weise überwacht werden — eine Aufgabe, die wegen der freien Beweglichkeit und mangelnden Identifikation jedes einzelnen Transportanrechts sehr schwer befriedigend lösbar ist.

7. Netzstrukturen und Laufwege

7.1 Netz-Topologien Bis jetzt wurde das Datenübertragungsnetz als intern unstrukturiertes Kommunikations-Subsystem idealisiert, als abstrakte Netzwerkmaschine, welche „irgendwie" Informationen zwischen Hosts über Ausgabe- und Eingabeports vermittelt. Dieses rein logische Konzept muß als physikalisches Netz aus IMPs (Knotenrechnern) und Leitungen realisiert werden. Je nach der Anordnung der IMPs und der sie verbindenden Leitungen können verschiedene Netz-Topologien gewählt werden, die sich in ihren Vor- und Nachteilen unterscheiden, und aus denen der Planer entsprechend den beim Entwurf der höheren Ebenen aufgetretenen Anforderungen seine Auswahl treffen muß. Tabelle 7.1-1 dient hierbei als Wegweiser: sie zeigt die wichtigsten Grundtypen aus einer Taxonomie der Rechnerkopplungen und -netze [ANDE75]. Auf der obersten Ebene dieses Schemas können zwei Übermittlungsstrategien unterschieden werden. Bei der direkten Übermittlung übergibt die Quelle (IMP oder Vorrechner eines Hosts, oder der Host selbst) die Nachricht unmittelbar an das Ziel, bei der indirekten sind im allgemeinen Vermittlungsrechner oder andere IMPs zwischengeschaltet. Das nächste Unterscheidungskriterium zwischen den verschiedenen Netztopologien ist die Laufwegermittlung, d. h. die im Netz zur Feststellung des gewünschten Zielrechners, der Wegwahl, zuständige Instanz. Bei der direkten Übermittlung gibt es hier zwei Möglichkeiten. Entweder wird die Nachricht von der Quelle nur an den gewünschten Zielrechner gesendet — dann ist dieser eindeutig bestimmt — oder sie gelangt über einen Bus, eine gemeinsame Übertragungsleitung, an alle anderen Rechner im Netz — dann ist die Zielrechnerermittlung dezentralisiert, und jeder Rechner muß durch Interpretation der im Nachrichtenkopf stehenden Zieladresse selbst feststellen, ob er der gewünschte Adressat ist. Auch bei der indirekten Übermittlung gibt es eine dezentralisierte Laufwegermittlung: jeder IMP muß selbst anhand der Zieladresse einer ankommenden Nachricht den richtigen Weg für ihre Weiterleitung bestimmen. Die Alternative ist die zentralisierte Laufwegermittlung, bei welcher ein zentraler Vermittlungsrechner für die korrekte Zustellung der Nachrichten verantwortlich ist. Tabelle 7.1-1 zeigt für jede dieser Übermittlungs- und LaufwegermittlungsStrategien die wesentlichen Topologien mit den für den Netzentwurf wichtigsten Eigenschaften:

ff s 5 «

¿>

!* 8 'S

J l

IIP

Ì

gering, jeder mäßig, der zentrale Vermittler Sender gibt muß Laufwege verwalten Nachrichten mit Adreßangabe über den Bus an alle Knoten, und die Empfänger selektieren die für sie bestimmten Nachrichten selbst

gering, da keine Laufwegermittlung nötig

schlecht für zentralen Vermittler, sonst gut

sehr gut, ein neuer Knoten braucht nur einen Anschluß an den Bus

schlecht, ein n+l-ter Knoten braucht n neue Leitungen

]

gering, jeder Knoten gibt Nachrichten einfach zum Nachbar weiter

- a

gut, jeder neue Knoten braucht 1 neue Leitung

^

M

mäßig wegen des regelmäßigen Aufbaus

sehr schlecht wegen Forderung nach absoluter Regelmäßigkeit

sehr schlecht wegen Forderung der absolut regelmäßigen Anordnung

1

logische Komplexität

r

99

Bus mit zentralem Vermittler

dezentralisiert

. ,

schlecht für zentralen Vergut, neue Knoten können mittler, sonst gut mit minimalem Aufwand angeschlossen werden

X

Stern

zentralisiert

hoch, jeder Knoten verwaltet eigene Laufwegtafeln für die Topologie des Gesamtnetzes

gut, neue Knoten benötigen nur 1 bis 2 neue Leitungen

sehr gut, neue Knoten können beliebig eingefügt werden

.B

KostenModulaiität

i

gut, da die Symmetrie der Anordnung durch neue Knoten nicht gestört wird

n

passiver Bus

dezentralisiert

,

n

vollständige Vermaschung

keines

indirekt über Vermittler (mit Adresstransformations- und/oder Laufwegermittlungsfunktionen)

jifS

Lokali sierungsModularität

8. o H N

Eigenschaften:

w Q Z