Rechnernetze

Geschwurbel von Daniel Schwamm (02-04/1994)

Inhalt

1. Einführung

Unter Rechnernetze verstehen wir in dieser Arbeit mehrere selbstständiger Computer, die über ein Netzwerk in Verbindung stehen und untereinander Daten austauschen können. Abzugrenzen sind Rechnernetze von Terminal-Netzen, wie sie bei Grossrechnersystemen üblich sind, z.B. SNA von IBM. Abzugrenzen sind sie auch von Verbundsystemen, die nur eine Untergruppe von Rechnernetzen repräsentieren, nämlich die der transparent arbeitenden - hier liegt der Unterschied weniger in der HW als vielmehr in der SW und dem BS.

1.1. Geschichte von Rechnernetzen

Sehen wir uns kurz die Geschichte der Rechnernetze an:

1950 Batch-Betriebssystem und Einbenutzersysteme erlauben keinen Netzbetrieb.
1960 Multiprogramming und I/O-Kanäle benötigen ein CPU-Sharing. Die Batch-Files können nur direkt am Host eingegeben werden.
1970 Time-Sharing-Betriebssysteme gestatten es, dass sich mehre Benutzer einen Mainframe teilen können. Batches können von Systemprogrammieren über Terminal-Netze zum Host gesendet werden.
1980 Transaktionsmonitore gestatten über Online-Kommunikation einen zuverlässigen Terminal-Netzverkehr, und zwar auch für Nicht-Systemprogrammierer.
1990 Die Workstations und PCs verdrängen als vernetzbare Arbeitsplatzrechner die Mainframes. UNIX, LANs (Local Area Networks im Herstellerbesitz, hier v.a. VMS=Voice-Mail-Systeme in Büros), WANs (Wide Area Networks wie z.B. X.25), Glasfaserkabel, Mobilfunk und das ISO/OSI-Referenzmodell (International Organisation for Standardization/Open System Interconnection-Referenzmodell) finden allgemeine Verbreitung. Der Ruf nach nicht-proprietären Systemen ist nicht mehr zu überhören.

Rechnernetze haben die Ziele, als Kommunikationsmedium zu dienen, beliebig erweiterbar zu sein sein, durch redundante Datenhaltung alle Sicherheitsaspekte zu erfüllen und Ressourcen Sharing anzubieten, um so dem Tyrannen Geographie Paroli bieten zu können. Rechnernetze wollen Datenverbund (z.B. Zugriff auf entfernte Daten), Funktionsverbund (z.B. durch Print-Server), Lastverbund (z.B. durch verteilte Jobs) und Verfügbarkeitsverbund (z.B. durch hohe Fehlertoleranz) erreichen.

1.2. LAN & WAN

Hinsichtlich der Netzwerkstrukturen sind zu unterscheiden: das LAN für den Nahbereich und das WAN für den Weitverkehr, wobei Letzteres ein Subnet mit untereinander verbundenen IMPs benutzt, also i.d.R. point-to-point (=store-and-forward, packet-switched) überträgt, während das LAN meist broadcast arbeitet, und zwar entweder statisch über einen Token-Mechanismus wie Token-Ring oder dynamisch über ein dezentrales Trial-and-Error-Verfahren wie CSMA oder einen zentral gesteuerten Entity-Mechanismus. An Topologien für die Subnets stehen den Netztechnikern Busse, Ringe, Bäume, Sterne und vollständig oder teilweise vermaschte Netze zur Verfügung.

1.3. Netzwerkarchitekturen

Unter Netzwerkarchitekturen versteht man Sätze von Schichten in einem Rechner, die anderen Schichten auf dem gleichen Rechner Dienste (die nicht standardisiert sein müssen!) anbieten und über Protokolle (die unbedingt standardisiert sein müssen!) mit ihren Partnerschichten auf anderen Rechnern kommunizieren. Üblicherweise wird von sieben verschiedenen Schichten ausgegangen, wobei ab der vierten Schicht an die Protokollnachrichten von jeder Schicht Header angefügt werden, die u.a. Sequenznummer enthalten, damit die Reihenfolge der Nachrichten eingehalten werden kann, und von der zweiten Schicht zusätzlich eine Markierung für das Nachrichtenende. Wir werden uns insbesondere mit der Netzwerkarchitektur-Vorform des ISO/OSI-Referenzmodells beschäftigen.

1.4. Protokoll-Entwicklung

Entwickelt man Protokolle, dann ist folgendes zu beachten:

  • Jede Schicht benötigt Mechanismen zum Verbindungsaufbau bzw. Verbindungsabbau.
  • Es muss entschieden werden, ob der Datentransfer (voll) duplex, halbduplex oder simplex erfolgen soll.
  • Soll es Kanäle verschiedener Priorität geben? Üblich sind z.B. zwei Kanäle, wobei einer für normale Daten und der andere für dringende Daten gedacht ist.
  • Wie soll die Fehlerüberwachung realisiert werden? Soll sie in allen Schichten stattfinden, oder nur in den oberen bzw. unteren? Soll Fehler nur entdeckt werden oder auch behoben? Soll ein Quittungsbetrieb installiert werden?
  • Wie kann man bei einer Paketvermittlung die Reihenfolge der Pakete garantieren?
  • Muss in jeder Schicht ein Schutzmechanismus installiert werden, der verhindert, dass die Senke von der Quelle mit Datenpaketen überschwemmt wird? Üblicherweise (d.h. nach der OSI-Norm) geschieht die Flusskontrolle (Schutzmechanismus, der wie der Schwimmer im Toilettenboiler die Zielstation vor Überschwemmungen schützt) einmal in der dritten Schicht zwischen den IMPs des Subnets und einmal in der vierten Schicht zwischen den Netz-Endteilnehmern über einen ACK/NAK-Mechanismus.
  • Sollen grosse Nachrichten zerkleinert werden oder sollen viele kleine Nachrichten aus Effizienzgründen zu grösseren zusammengepackt werden?
  • Ein Multiplexing bzw. Demultiplexing auf evtl. verschieden Ebenen könnte eine bessere Ausnutzung von bestehenden Verbindungen oder einen erhöhten Datentransfer über mehrere Verbindungen bewirken.
  • Besonders komplex gibt sich die Gestaltung des Routings, also der Verfahren, die den Paketen den Weg durch das Netz weisen. Soll das Routing nur in einer Schicht erfolgen oder in mehreren?

2. Das ISO/OSI-Referenzmodell

Wie bereits erwähnt stellt das ISO/OSI-Referenzmodell nur eine Vorform einer Netzwerkarchitektur dar, da es nur eine SOLL-Beschreibung (Normierung) ist und keine IST-Anwendung wiedergibt. Die Normen sind Vereinheitlichungen, die planmässig und gemeinschaftlich durch interessierte Kreise zum Nutzen der Allgemeinheit durchgeführt wurden.

2.1. Die sieben Schichten

Unterschieden werden beim ISO/OSI-Referenzmodell die folgenden sieben Schichten-Normierungen:

  1. Bitübertragungsschicht (Physical Layer): Benutzt als kleinste Übertragungseinheit das rohe Bit. Diese Norm beschreibt v.a. die mechanischen, elektrischen und prozeduralen Eigenschaften der diversen Schnittstellen sowie des physikalischen Überträgermediums.
  2. Sicherungsschicht (Data Link Layer): Diese Schicht ist zuständig für die Versendung von Datenrahmen und die Verarbeitung von Quittierungsrahmen. Sie muss die Rahmengrenzen einfügen/erkennen, sie muss verlorene, beschädigte oder duplizierte Rahmen behandeln, wozu sie i.d.R. kostenunterschiedliche Qualitätsdienste walten lassen kann, die von der dritten Schicht angefordert werden. Sie übernimmt häufig auch die Flusskontrolle innerhalb eines Subnets und muss bei Vollduplex-Betrieb die verschiedenen Quittungsrahmen besonders behandeln, um sie nicht mit normalen Datenrahmen zu verwechseln, z.B. über das Piggybacking.
  3. Vermittlungsschicht (Network Layer): Diese Schicht fällt bei Broadcast-Subnets häufig weg; sie wird nur zur Paketvermittlung benötigt. Sie ist zuständig für die Leitwege der Pakete, die sie über dynamische oder statische Tabellen ermittelt, oder indem sie verdrahtete Leitungen benutzt. Sie muss dafür sorgen, dass Paketstauungen im Subnet nicht zum Chaos führen. Da die Subnets oft von anderen Firmen betrieben werden, enthält sie auch häufig eine Abrechnungsfunktion, die sich besonders beim Internetworking als recht schwierig erweisen kann. Zudem regelt sie die Übergänge zwischen den verschiedenen Netzen, z.B. wandelt sie das Adressenformat, die Paketgrösse oder das ganze Protokoll.
  4. Transportschicht (Transport Layer): Diese Schicht zerlegt u.U. die SPDUs in TPDUs. Sie fängt alle HW-Änderungen gegenüber der Sitzungsschicht ab. Sie kann über Multiplexing mehrere Verbindung über einen Kanal realisieren, um so das Netz besser auszunutzen, oder sie kann mehrere Kanäle für datenintensive Verbindungen zusammenschalten. Sie ist die erste End-to-End-Schicht, regelt also den Datenverkehr nicht nur zwischen IMPs, sondern zwischen Endteilnehmern. Dies bedarf einer Extra-Flusssteuerung und eine Regelung mittels Sequenznummern in Headern, um die Reihenfolge der Pakete zu garantieren. Ausserdem initiiert diese Schicht den Auf- und Abbau von Verbindungen zwischen den Teilnehmern durch das ganze Subnet und nicht nur von Hop zu Hop.
  5. Sitzungsschicht (Session Layer): Sie bietet der Darstellungsschicht die Transportdienste und einige gehobene Dienste an. Ein gehobener Dienste ist z.B. die Dialogsteuerung, die bei Simplex-Übertragung sagt, wer wann was senden darf. Ein ähnliches Verfahren, dass Token-Management, ist auch bei Duplex-Übertragungen nötig. Zudem können die Teilnehmer synchronisiert werden, was die Setzung von Fixpunkten erlaubt, die markieren, bis wohin eine Übertragung bisher erfolgreich verlaufen ist.
  6. Darstellungsschicht (Presentation Layer): Diese Schicht kann den zu übertragenden Bit-Strömen Syntax und Semantik einhauchen, um inkompatible Systeme auf einer höheren, abstrakteren Ebene zu einem gemeinsamen Kontext finden zu lassen. Sie enthält Regeln zur Codierung von Datentypen wie Fliesskommazahlen oder Integer-Zahlen, sowie ganz gewöhnlicher Buchstaben. Sie kann Des Weiteren auch eingesetzt werden, um Daten zu komprimieren oder zu verschlüsseln.
  7. Anwendungsschicht (Application Layer): Diese Schicht beinhaltet eine nach oben offene Menge von Protokollen, die diverse spezialisierte Kommunikationsaufgaben übernehmen können, wie z.B. E-Mails, ein virtuelles Terminal-Programm (das man genauso gut in der 6.Schicht hätte vermuten können), Dateitransferdienste, Remote Procedures für verteilte Systeme (ähnlich oder identisch mit Verbundsystemen) und Directory-Dienste.

2.2. OSI-Terminologie

Zur OSI-Terminologie gehören folgende Ausdrücke:

  • Entity: Instanz; laufender Prozess einer Schicht auf einem Rechner.
  • Dienstleister: Die Schicht N, die der Schicht N+1 Dienste anbietet.
  • Dienstbenutzer: Die Schicht N, die die Dienste der Schicht N-1 benutzt.
  • Dienstklassen: Alternative Schichtimplementierungen mit verschiedenen Qualitätsmerkmalen.
  • SAP (Service Access Point): Portnummern an fixen Adressen, die bei Aufruf die jeweilige Schicht dahinter instanziiert. Hier werden IDUs ausgetauscht.
  • IDU (Interface Data Unit): Nachricht+SDU der Schicht N an Schicht N-1, die über die SAPs ausgetauscht werden.
  • SDU (Service Data Unit): Dienstkontrollinformation der Schicht N für Schicht N-1, wird in der IDU über die SAPs übermittelt.
  • PDU (Protocol Data Unit): IDUs ohne SDU, dafür aber mit einem schichtspezifischen Header. Eine SDU kann auch in mehrere PDU segmentiert und später reassembliert werden oder mehrere SDUs können auch zu einer PDU geblockt und später entblockiert werden.
  • Header: Protokollkontrollinformationen der Schicht N für die Partnerinstanz der Schicht N auf dem Kommunikationspartner-Rechner.
  • Dienst: Reihe von Dienstelementen.
  • Dienstelement (Primitives): Operation einer Schicht. Hier wären CONNECT, DATA, DISCONNECT u.a. zu nennen.
  • Dienstarten: Jeder Schicht bietet der darüber liegenden verbindungsunabhängige und verbindungsorientierte Dienstarten an.
  • Dienstklassen: Nach OSI gibt es vier verschiedene Dienstklassen, die Anforderung (Request) eines Dienstes, die Anzeige (Indication) eines angeforderten Dienstes, und für zuverlässige, d.h. bestätigende Dienste die Antwort (Response) auf die Anzeige und die Bestätigung (Confirm) der Aufforderung.
  • (N)-Subsystem: Eine oder mehrere (N)-Instanz(en).

2.3. Datenaustausch-Schema

Ein typischer Datenaustausch kann so nach OSI folgendermassen ablaufen:

A: CONNECT.request von Schicht N nach N-1.
B: CONNECT.indication von Schicht N-1 nach N.
B: CONNECT.response von Schicht N nach N-1.
A: CONNECT.confirm von Schicht N-1 nach N.
A: DATA.request von Schicht N nach N-1.
B: DATA.indication von Schicht N-1 nach N.
B: DATA.request von Schicht N nach N-1.
A: DATA.indication von Schicht N-1 nach N.
A: DISCONNECT.request von Schicht N nach N-1.
B: DISCONNECT.indication von Schicht N-1 nach N.

2.4. Normierungsinstitute

Bei der Netzwerk-Normierung müssen De-facto-Standards von De-jure-Standards unterschieden werden. De-facto-Standard wurden von der Industrie initiiert, De-jure-Standard von den staatlichen oder freiwillig-ökonomischen Normierungsinstituten. An Normierungsinstituten sind zu nennen:

  • ITU (International Telecommunication Union), eine Agentur der Vereinten Nationen, die ein Organ, die CCITT besitzt, die für die Datenkommunikation zuständig ist.
  • Die CCITT ist eine internationale Vereinigung von Postgesellschaften, die bei ihren alle 4 Jahren stattfindenden Vollversammlungen verschiedenfarbige Empfehlungen ausgibt, die oft zum Standard werden, wie z.B. die V.24-Norm (in USA RS-232-Norm) für asynchrone Terminal-Kommunikation und die X.25-Norm, die Schnittstellenfestlegungen beinhaltet für eine Kommunikation zwischen Computern und (paketvermittelnden) Netzwerken. Die ISO ist Mitglied bei der CCITT.
  • Die ISO ist ein freiwilliges Komitee, gebildet aus den Mitgliedern der Normungsinstitute der 89 beteiligten Länder, z.B. ANSI, BSI und DIN, und diversen Unternehmensmitgliedern. Arbeitsgruppen erarbeiten hier zuerst Working Drafts (WD), dann Draft Proposals (DP), die nach Prüfung zu Draft International Standards (DIS) werden und nach einer weiteren Prüfung zu International Standards (IS). Die ISO hat zwar das letzte Wort bei internationalen Normen, ihre Normen besitzen jedoch keine Rechtsverbindlichkeit!
  • Bei der Normierung mitzureden hat auch noch der IEEE-Verband, der grösste Fachverband der Welt. U.a. lieferte er die 802-Normen für LANs, die von der ISO als 8802-Normen übernommen und in das ISO/OSI-Referenzmodell integriert wurden.

2.5. Kritik

Kritik am ISO/OSI-Referenzmodell: Vielfach wird behauptet, das "Tal" der Normierung zwischen Forschung und Industrieinvestitionen ist bei den offenen Netzen zu schmal geraten, daher machen die OSI-Normen so einen überhasteten Eindruck. So ist z.B. eine deutliche Asymmetrie zwischen den Schichten festzustellen, z.B. werden die Schichten fünf und sechs selten gebraucht und sind entsprechend schmal ausgefallen, während die Schichten zwei und drei aus allen Nähten platzen. Oft wurde auch recht kompliziert und redundant verfahren, so ist es u.a. nicht einsehbar, warum für jede Schicht ein Fehler-Handing nötig sein soll, wo doch im funktionierenden ARPANET dieses nur in Schicht vier erfolgt. Auch ist es oft nicht einfach zu entscheiden, welches Netzprogramm in welche Schicht gehört; das virtuelle Terminal hätte statt in Schicht sieben genauso gut in Schicht sechs gepasst. Verzichtet wurde auch auf die Normierung von verbindungsunabhängigen Protokollen, sowie von Kryptologieverfahren. Die genannten Lösungen erfordern häufig Interrupt-Lösungen, was modernen, prozeduralen Programmiersprachen nicht gerecht wird. Und zuletzt sind die OSI-Begriffe zwar gut auf Telefonsysteme abgestimmt, aber wenig auf Computer-Kommunikationssysteme.

3. Beispielnetze

3.1. Öffentliche Netze

Sie sind oft Teil des öffentlichen, analogen Telefonnetzes. Hier bietet ein Betreiber anderen Dienste an. Fast alle öffentlichen Netze haben für die unteren Schichten die CCITT-X.25-Normen übernommen, allerdings wird statt der digitale Schnittstelle X.21 i.d.R. die analoge Schnittstelle RS-232 benutzt. In die 2. Schicht wurde das synchrone, bitorientierte HDLC/LAPB-Protokoll (High-Level Data Link Control/Link Access Procedure, Balanced) integriert, welches von IBMs SDLC (Synchronous Data Link Control) abgeleitet wurde. Falls Terminals an das öffentliche Netze gehängt werden sollen, finden die Triple X-Normen Verwendung, die die Funktionsweise von PAD-Boxen (Packet Assembly/Disassembly) beschreiben, sowie die Terminal-PAD-Box- und PAD-Box-X.25-Netz-Protokolle. Für die oberen Schichten existieren Normen von der ISO, z.B. für die Transportschicht fünf verschiedene Varianten von verbindungsorientierten Protokollen. Die Sitzungsschicht- und Darstellungsschichtprotokolle finden dagegen bisher kaum Verwendung. Und auf der Anwendungsschicht werden folgende Protokolle angeboten: FTAM (File Transfer Access and Management), MOTIS (Message Oriented Text Interchange System; X.400), VTP (Virtual Terminal Protocol) und JTM (Job Transfer and Manipulation).

3.2. ARPANET

Dieses Netz wurde vom Department of Defense (DoD) entwickelt und 1969 aufgeteilt in das MILNET und das ARPA Internet für BSD-UNIX-Rechner in Universitäten. Einzelne LANs können hier über Subnets, die aus Punkt-zu-Punkt-IMP-Verbindungen bestehen, miteinander vernetzt werden. Es wird zentral verwaltet, z.B. zur Vergabe der Adressen. Die Protokolle richten sich noch nicht nach OSI, weil sie älter sind. Als Vermittlungsprotokoll dient das verbindungsunabhängige IP und als Transportprotokoll das verbindungsorientierte TCP. Auf der Anwendungsschicht finden sich die Protokolle: FTP, SMTP, TELNET und andere Spezialprotokolle. Eine Sitzungsschicht oder Darstellungsschicht existiert nicht.

3.3. MAP und TOP

OSI-Protokolle sind nicht automatisch zur Kommunikation mit anderen OSI-Protokollen geeignet, weil in einer Schicht verschiedene Standards existieren können - wie wir sie bei MAP (Manufacturing Automation Protocol) und TOP (Technical and Office Protocol) finden können. Warum? Weil zuerst Ethernet der De-facto-Standard für LANs wurde, zumindest für DEC, Xerox und Intel. Für Real-Time-Anwendungen ist dieses Protokoll aber nicht geeignet, daher schufen IBM den Token-Ring und General Motors den Token-Bus. Das IEEE-Komitee übernahm schliesslich alle drei Protokolle: 802.3 (Grundlage Ethernet), 802.4 (Token-Bus) und 802.5 (Token-Ring). MAP von GM und TOP von Boeing sind folgendermassen aufgebaut:

MAP-Garnitur: FTAM (File Transfer Access and Management), ASCE (Association Service Control Element) und Dateisystem als Applikationen, BER für ASN.1, einen sicheren, vollduplexen Transportdienst der Klasse 4, ein IP-ähnliches, also verbindungsunabhängiges Vermittlungsprotokoll (ungleich zu X.25), die LLC-Norm 802.2 der Klassen 1 und 3, und in Schicht 1 die Token-Bus-Norm 802.4. Es ist für Arbeiten auf Produktionsebene gedacht; es soll v.a. durch den MMS-Standard (Manufacturing Message Specification) mit der Standardvielfalt bei CNC-Maschinen aufräumen. Seit 1990 liegt die Version 3.0 vor, die inkompatibel zum ASN.1-losen Vorgänger 2.1 ist.

Es existiert auch eine Schicht 1 bis 3-Version von MAP: MAP Enhanced Performance Architecture (EPA). Da die Schichten 4 bis 7 fehlen, arbeitet diese MAP-Version wesentlich schneller. Allerdings sind nur noch kurze Nachrichten möglich sind, da die Segmentierungsfunktion fehlt. Ausserdem kann die Mini-MAP nicht mit der Full-MAP kommunizieren.

TOP-Garnitur: FTAM, DS und MHS als Applikationen und in Schicht eins die Protokolle für Token-Ring und Ethernet. Die restlichen Schichten sind identisch mit denen der MAP-Garnitur. Es ist für Arbeiten auf Büroebene gedacht. In den höheren Schichten ist es kompatibel mit MAP!

Mögliche Subsysteme von MAP/TOP sind:

  • Hosts mit allen sieben Schichten
  • Gateways mit vier bis sieben Schichten für Verbindungen zwischen OSI-LANs und Nicht-OSI-LANs.
  • Router mit Schicht eins bis drei für LAN-WAN-Verbindungen.
  • Bridges mit Schicht eins und zwei für LAN-LAN-Verbindungen.
  • Nicht-intelligente Repeater mit reiner Verstärkerfunktion, wobei die Repeater einmal an die Netzwerkkarte der Computer und einmal an einen Transceiver, der Kabelkontakt hat (z.B. über einen T- oder einen Vampir-Stecker), angeschlossen sind. Sie können aber auch zwei Basisband-Bussegmente miteinander verbinden; bei grösseren Strecken teilen sich zwei Remote Repeater am Anfang und Ende der Strecke die Arbeit.

3.4. SNA

Das Service Network Architecture-Netz (SNA) von IBM diente OSI als Vorlage für seine Architektur. Es ist allerdings noch komplizierter, da es gewachsen ist und versucht hat, sämtliche Spezialwünsche der Anwender zu erfüllen. Offiziell hat es 7 Schichten, weil das laut Effelsberg so "schick" klingt, inoffiziell aber nur 4. Eine Domäne, also ein Adressbereich, besitzt bei SNA eine Baumstruktur: der Host ist verbunden mit einer Vorstufe, die verbunden sein kann mit einer anderen Vorstufen und den verschiedenen Controllern, an die jeweils mehrere Terminals angeschlossen sein können. Wie OSI besitzt SNA sieben Schichten mit verschiedenen Aufgaben. Schicht zwei Z.B. enthält die SDLC-Protokolle, die für die OSI-LLC als Vorlage dienten, besonders für die HDCL-Protokolle. Mehrere Pakete können zu einem Grösseren zusammengepackt werden, um die Netzeffizienz zu erhöhen. Ausserdem arbeitet SNA generell sitzungsorientiert und damit auch verbindungsorientiert.

4. Die ISO/OSI-Schichten

4.1. Bitübertragungsschicht

Alle Funktionen, die stetig sind mit einer Periode T, lassen sich durch die Summation von Kosinus- und Sinusfunktionen als Fourierreihe darstellen. Zur Bitübertragung will man eine Rechteckfunktion haben, was aber nicht vollständig möglich ist, da die einzelnen Komponenten der Fourierreihe unterschiedlich stark gedämpft werden im physikalischem Medium. Durch Energieverluste kommt es zu Verzerrungen, die Rechteckform wird kurvig. Durch nötige Bandfilter bzw. Eigenschaften des Mediums ist ein relativ verzerrungsarmer Frequenzbereich zudem noch eingeschränkt.

Ein Zeichen ist acht Bits gross und benötigt zur Übertragung die Zeit T, die abhängig ist von der Codierungsmethode und der Signalgeschwindigkeit, also der Anzahl der Spannungsänderungen pro Sekunde, die in Baud gemessen wird. Da i.d.R. mehrere Spannungsstufen möglich sind, können mit jedem Signalwert auch mehrere Bits übertragen werden, z.B. bei sieben Spannungsstufen jeweils drei Bit pro Sekunde, d.h. die Bitrate ist in diesem Fall dreimal grösser als die Baudrate.

Die maximale Bitrate eines rauschfreien Kanals beträgt nach Nyquist:

2 * Bandbreite * log2( diskrete Stufen )

Die maximale Bitrate eines rauschenden Kanals beträgt nach Shannon:

Bandbreite * log2( 1 + Rauschabstand )

Der Rauschabstand baut sich auf aus Signalstärke geteilt durch Rauschstärke und wird angegeben in Dezibel, einem logarithmischem Mass. Es gilt: Eine Rauschstärke von 10 ergibt 10 Dezibel, von 100 ergibt 20 Dezibel und von 1000 ergibt 30 Dezibel.

Ein Sprachsignal erfordert analog z.B. 3000 Hz, um verständlich zu sein. Um ein solches analoges Signal mit 256 verschiedenen Amplitudenstufen digital übertragen zu können, benötigt man nach Nyquist:

2 * 3000 Hz * log2( 256 ) = 6000 * 8 = 48000 bit/s.

Die Post hat sich im Rahmen von ISDN aus diesem Grund für 64000 bit/s zur Sprachübertragung entscheiden.

4.1.1. Übertragungsmedien

  1. Magnetische Medien: Disketten und Magnetbänder für "Turnschuhnetze". Besitzen eine nicht zu unterschätzende Bandbreite. So schlägt ein LKW, der beladen wurde mit Magnetbändern, auf kürzeren Strecken jedes andere Übertragungsmedium.
  2. Verdrillte Leitungspaare: sind verdrillt, damit die Kabel keine Antenne bilden können, die Störgeräusche auffängt. Finden Verwendung im öffentlichem Telefonnetz, weil sie billig sind und Repeater eingefügt werden können. Zudem eignen sie sich für analoge und digitale Übertragungen.
  3. Basisband-Koaxialkabel: ist durch seine Ummantelung rauscharm und erlaubt den Anschluss von T- und Vampir-Steckern, was sich als ideal für LANs erweist. Wird für die digitale Übertragung benutzt, wobei selbsttaktendes Manchester-Coding (low-high=0, high-low=1) oder differential Manchester-Coding (Pegeländerung am Anfang=0, keine Pegeländerung am Anfang=1) eingesetzt wird, damit Null-Bits von Nicht-Sendungen unterschieden werden können - auch wenn sich dadurch die zur Verfügung stehende Bandbreite halbiert. Im Basisband-Kabel werden nur Pakete auf einem einzigen schmalen Frequenzband versendet, d.h. ein Verbindungsaufbau ist hier unüblich, das alle anderen für die Dauer der Verbindung blockiert sein würden - es sei denn durch Zeit-Multiplexing werden wie beim Telefon mehrere Kanäle geschaffen. Wird häufig als Broadcast-Medium eingesetzt.
  4. Breitband-Koaxialkabel: wird für die analoge Übertragung benutzt, z.B. beim Kabelfernsehen, wo die grosse Bandbreite in Kanäle unterteilt wird. Ist für grössere Entfernungen geeignet, weil nur ein Kabel für viele Kanäle gelegt werden muss. Da es aber relativ teuer ist und in jeder Station Modems verlangt, ist seine Verbreitung auf LANs begrenzt.
  5. Lichtwellenleiter: das sichtbare Licht hat einen Frequenzbereich von 10 hoch 8 MHz. LWL besitzen damit eine riesige Bandbreite (theoretisch bis 300 THz, praktisch bis 10 GHz), sind aber wegen ihrer Technik - LED/Laser als Lichtquelle, Photodioden als Empfänger - nur unidirektional zu gebrauchen. Wir unterscheiden Multimodefasern-LWL mit kleinen Datenraten und Monomodefasern-LWL mit grossen Bitraten. Beide erlauben aktive (verstärkende) oder passive Repeater dazwischenzuschalten, was hier aber bei Weitem nicht so einfach gelingt wie bei Koaxialkabel. Für grosse und schnelle LANs sind LWL jedoch inzwischen unentbehrlich geworden.
  6. Sichtverbindungen: über Laser, Infrarotsender, Mikrowellen und Radiosender lassen sich ebenfalls Verbindungen aufbauen, die sich zur Datenübertragung eignen. Auch hier sind sehr hohe Bitraten möglich. Allerdings bestehen Gefahren durch Interferenzen durch Phasenverschiebungen und durch Absorbierung der Wellen bei schlechtem Wetter, besonders bei hohen Wellenfrequenzen.
  7. Kommunikationssatelliten: sie sind grosse Himmelsverstärker, die über Transponder verschiedene Frequenzen (simplex) empfangen, z.B. 794 Simplexkanäle zu je 64 bit/s, und sie dann mit einer anderen Frequenz wieder (simplex) abstrahlen. Dadurch werden Interferenzen aufgrund der anfallenden Verzögerung von 270 ms ausgeschlossen, jedoch bleibt die Gefahr der Absorbierung der Signalwellen bestehen. Ausserdem ist diese Art der Kommunikation wegen ihrer Broadcast-Eigenschaft nicht abhörsicher. Token-Mechanismen funktionieren sind wegen der Zeitverzögerung nicht sinnvoll, daher wird i.d.R. TDM (Time-division Multiplexing) benutzt.

4.1.2. Analoge Übertragung

Die Bitübertragungsschicht beschreibt für die analoge Übertragung von digitalen Daten die Schnittstelle RS-232 und die Funktionsweise von Modems (DCE), die die seriellen RS-232-Daten des Computers (DTE) empfangen und in einen modulierten Trägerstrom wandeln. Als Techniken kommen infrage: Phasen-, Frequenz- oder Amplitudenmodulation (PM, FM oder AM). Die Quadratur-Amplituden-Modulation beispielsweise erlaubt eine Datenrate von bis zu 9600 bps auf einem 300 kHz-Band. Damit ein Duplex-Betrieb über die Telefonleitung möglich wird, schaltet ein Innenband-Ton von 2.100 Hz die Echosperren aus.

  • Mechanisch spezifiziert ist, dass die RS-232-Schnittstelle zur Regelung des Datenverkehrs über 25 Anschlüsse verfügt.
  • Elektrisch spezifiziert ist, dass Spannungen kleiner als -3 Volt als Null gelten und Spannungen über 4 Volt als Eins, dass Kabel maximal 15 m lang sein dürfen und dass maximal 20 kbit/s gesendet werden dürfen.
  • Funktional spezifiziert ist, wie welche Anschlüsse (Pins) mit welchen Aufgaben belegt wurden.
  • Prozedural spezifiziert ist, wie die Protokolle miteinander welche Aktions-Reaktionspaare austauschen dürfen.

4.1.3. Digitale Übertragung

Überträgt man Daten direkt digital, hat dies den Vorteil, dass man die Bit-Informationen leichter verstärken kann, d.h. die Fehlerhäufigkeit geht gegenüber analogen Übertragungsmedium um ein Vielfaches zurück. Um analoge Daten in digitale umzuwandeln, benutzt man einen Codec, der üblicherweise Pulscodemodulation betreibt, wobei er den analogen Trägerstrom z.B. 8.000 Mal in der Sekunde abtastet, was nach Nyquist immerhin zum Lesen eines 4 kHz-Bandes genügt. Je nachdem, mit wie viel diskreten Spannungsstufen zuvor moduliert wurde, können entsprechend hohe Datenraten entgegengenommen werden. Typisch sind für das analoge Medium 256 Stufen, also können jeweils

8 bit (für 256 Stufen) * 8000 Abtastungen/s = 64000 bit/s

abgetastet werden, die dann über Zeit-Multiplexing auf 24 Kanäle verteilt werden, d.h. das digitale Medium besitzt insgesamt eine Datenrate von

24 Kanäle * 64000 bit Abtastung/s = 1.544 Mbps.

Jeder Rahmen wird dadurch 193 bit gross (8*24 bit Informationen plus 1 Synchronisationsbit). Zwei Normen behandeln das Signaling auf digitalen Medien:

  1. Common Channel Signaling: Jeder gerade Rahmen enthält ein Signal durch das Synchronisationsbit, das für alle Kanäle gilt.
  2. Channel Associated Signaling: Jeder sechste Rahmen enthält acht Signale durch das Informationsbyte, die kanalspezifisch gelten.

Höhere Bitraten sind durch verschiedene Komprimierungsverfahren zu erreichen, die darauf beruhen, dass nur selten grosse Amplitudenänderungen übertragen werden. Hier wären zu nennen:

  • Differenzielle Pulscodemodulation: Nur die Änderung der Amplitudenhöhe wird übertragen, dadurch genügen 5 bit (für -3 bis +3) statt 8 bit.
  • Deltamodulation: eine verschärfte Variante obiger Methode. Hier werden nur Nullen oder Einsen übertragen, je nachdem, ob die Amplitude gegenüber dem Vorgänger kleiner oder grösser geworden ist. Statt 8 bit genügt 1 bit.
  • Vorhersagemodulation: Bei dieser Methode wird nur die Differenz zwischen dem vorherberechneten und tatsächlichem Amplitudenwert übertragen. D.h., dass zum Teil überhaupt nichts übertragen werden muss.

Die Norm X.21 beschreibt eine digitale Schnittstelle, die zwischen Computer (DTE) und digitaler Leitung (DCE) sitzt. Sie verfügt über acht Anschlüsse, die einen verbindungsorientierten Datenaustausch im Vollduplex-Betrieb gestatten.

Die Multiplexmethoden der analogen Übertragung wie FDM und TDM (Time-division Multiplexing) eignen sich für die digitale Übertragung wenig, denn bei der Computerkommunikation benötigt man keine ständige, kleine Bandbreite, sondern nur kurzfristige, aber grosse Bandbreiten. Aus diesem Grund erweisen sich Speicher- bzw. Paketvermittlungen hier als effizienter als Leitungsvermittlungen. Als Hybridvermittlungen bieten sich noch an: ISDN (Integrated Services Digital Network), Schnellverbindungsleitungsvermittlungen und Zeitmultiplexverfahren mit Synchronisation, aber ohne Puffer.

4.1.4. ISDN

Dieses internationale Vorhaben der CCITT wird hier vorgestellt, da es OSI-Netzen eine unsichere Digitalpipeline, also eine Bitübertragungsschicht, anbieten kann (eigentlich bietet ISDN dem Benutzer sogar die Oberkante von Schicht 3 an). Dabei werden Daten, Sprache, Bilder und Texte auf einem Kabel integriert, was eine rein digitale Arbeitsweise voraussetzt. Im Einzelnen beinhaltet ISDN die folgenden Dienste:

  • Erweiterter Sprachdienst (integrierter Telefonbeantworter, Weckdienste, Nummernanzeige und Konferenzschaltungen).
  • Videotext (für Online-Informationsdienste).
  • Teletext (für elektronische Post).
  • Fax-Dienst (für Bilderübertragung).

Zwei Möglichkeiten existieren, um sich in ISDN-Netzwerke einzuklinken: die NT-1-Box mit 8 Anschlüssen für den Heimbetrieb und die NT-2-Box (PBX) für Betriebe, die Eingangsleitungen entweder über einen Koppelnetzvermittler oder über Zeitmultiplexer auf Ausgangsleitungen umlegen. NT-1-Boxen wachsen mit der Zahl der Anschlüsse quadratisch [n*(n-1)/2], NT-2-Boxen nur linear, weil interne Tabellen genügen, die Puffer leistungsgerecht auszulesen - was allerdings sehr schnell geschehen muss, sodass auch hier nach oben eine Grenze gesetzt ist.

An genormten Kanälen bietet ISDN an:

  1. Basisanschluss (B-Kanal): 1 x 64 kbps für PCM-Sprache, 1 x 64 kbps für PCM-Bilder und 1 x 16 kbps für die Ausser-Band-Signalisierung.
  2. Primär-Multiplex-Anschluss: 30 x 64 kbps für PCM-Daten und 1 x 64 kbps für die Ausser-Band-Signalisierung.
  3. Hybridanschluss: Analoges Telefon mit 4 kHz und einem digitalem Kanal mit lächerlichen 16 bps zur Ausser-Band-Signalisierung.

ISDN arbeitet verbindungsunabhängig, also paketvermittelnd, wenn nur der nächste IMP (Interface Message Processor) angewählt wird, ansonsten leitungsvermittelnd. Die benutzte Ausserband-Signalisierung wird durch die Norm CCITT-SS-7 festgelegt, die dem in alten Telefon- oder X.25-Netzen üblichen CCS-Verfahren (Common Channel Signaling) ähnelt. Es findet intern Duplex-Übertragung und Time Division Multiplexing statt. In Zukunft soll ISDN zu Breitband-ISDN (B-ISDN) erweitert werden, bei dem 150 Mbps übertragen werden können. Bis dahin werden X.25-Netze und ISDN-Netze parallel existieren; ISDN muss also X.25 verstehen können.

4.1.5. Terminal-Handling

Da einzelne Leitungen teuer sind, lohnt es sich, Verfahren zu entwickeln, die helfen, dass sich viele Anwender gleichzeitig eine Leitung verwenden können. Will man z.B. mehrere Terminals über eine Leitung miteinander kommunizieren lassen, so benötigt man dazu einen Terminal-Controller. Dieser fragt die Teilnehmer z.B. über IBMs Bisync-Protokolle, die ASCII- (American Standard Code for Information Interchange) und EBCDIC-Zeichen (Extended Binary Coded Decimals Interchange Code) erlauben, regelmässig ab, ob sie einen Sendewunsch haben (Polling). Falls ja, werden die Zeichen auf die Leitung gemultiplext bzw. konzentriert, je nachdem, ob man über Multiplexer (Time Division Multiplexing (TDM) ohne Puffer) oder sogenannte Konzentrierer (Asynchronous Time Division Multiplexing (ATDM), statistische Multiplexer mit Puffern) verfügt.

4.1.6. Die MAC-Teilschicht

4.1.6.1. Protokolle

Diese Schicht ist nötig bei Broadcast-Medien, wie sie bei LANs, MANs und WAN-Satellitennetzen Verwendung finden. Möglichkeiten, das Medium für alle Teilnehmer zugreifbarer zu gestalten - zu beachten ist v.a., dass Kollisionen entdeckt oder verhindert werden müssen -, gibt es viele:

  • FDM (Frequency Division Multiplexing): Bandbreitenverschwendung, weil normalerweise synchron, d.h. alle Kanäle bekommen immer einen Bandbreitenanteil, egal, ob sie Senden oder nicht.
  • TDM (Time Division Multiplexing): Bandbreitenverschwendung, weil normalerweise synchron.
  • ATDM (Asynchronous TDM): Besser als TDM/FDM, aber Kollisionen sind bei mehreren Konzentratoren nicht auszuschliessen.
  • ALOHA-Protokolle: Senden von Rahmen fester Grösse zu beliebigen Zeiten und bei Kollisionsfeedback von nur einem Bit nach Zufallszeit (backoff time) noch einmal versuchen. 18% Durchsatz sind hiermit erreichbar.
  • Slotted ALOHA: Diskrete Variante; hier wird nur zu bestimmten Zeitschlitzen (Slots) gesendet, deren Länge der eines Pakets entsprechen, wodurch sich die Kollisionen-Anzahl halbiert - das macht 36% Durchsatz.
  • 1-persistent CSMA (Carrier Sense Multiple Access): Senden von Rahmen mit einer Wahrscheinlichkeit von 1, wenn das Medium frei ist. Bei Kollisionen nach Zufallszeit Sendung noch einmal wiederholen. Damit ist ein Durchsatz von bis zu 55% zu erreichen, der mit steigenden Sendewünschen allerdings rasch fällt.
  • Non-persistent CSMA: wenn der Kanal belegt ist, dann eine Zufallszeit warten, bevor geprüft wird, ob er inzwischen frei geworden ist. Durchsatz bis zu 90%, wobei eine erhöhte Anzahl von Sendewünschen den Durchsatz erhöhen.
  • p-persistent CSMA: Senden von Rahmen mit einer Wahrscheinlichkeit von p, wenn das Medium frei ist. Bei Kollisionen nach Zufallszeit Sendung noch einmal wiederholen. Durchsatz bei p=0.01 am höchsten mit 92% Durchsatz (unabhängig von der Zahl der Sendewünsche).
  • (1-persistent) CSMA/CD (802.3-Norm, Ethernet): Wie CSMA, nur mit sofortigem Sendeabbruch, wenn - analog! - eine Kollision festgestellt wurde. Die Norm sieht hier ein Manchester-Coding und eine Bitrate von 10 Mbps vor. Ausserdem müssen Rahmen, um sie vom Kollisionsmüll unterscheiden zu können, mindestens 64 Bytes gross sein, was schlecht für die Übertragung von einzelnen Terminal-Zeichen ist. Als Adressformate können wie beim Token-Ring 48-bit- oder 16-bit-Felder genutzt werden.
  • Token-Bus (802.4-Norm): logischer Ring mit umlaufendem Token - wer es hat, darf Ring benutzen. Ideal für Echtzeitanwendungen wie Sprache, weil ein vierstufiger Prioritätsmechanismus feste Bandbreite garantieren kann. Es findet keine zentrale Überwachung statt, sondern eine dezentrale, was die Ausfallsicherheit erhöht. Die Busstruktur eignet sich für Fliessband-Anwendungen. Vorgesehen ist eine Bitrate von 10 Mbps.
  • Token-Ring (802.5-Norm): Ist eigentlich kein echtes Broadcast-Medium, sondern arbeitet über unidirektionale Point-to-Point-Verbindungen (über ein spezielles Adressformat sind aber Broadcast-Nachrichten möglich). Auch hier gilt: Wer das Token hat, darf senden. Wichtig ist, dass der Ring gross genug ist, um das 3 Byte grosse Token aufzunehmen. Ausgegangen wird von einer Bitrate von 4 Mbps und dem differential Manchester-Encoding. Die Token-Haltezeit beträgt maximal 10 ms.

Es gibt zwar einen Prioritätsmechanismus, der kann aber u.U. auch Stationen verhungern lassen. Eine Sendestation geht in den "Priority Hold"-Status über, wenn eine andere Station in ihren Rahmen einen höhere Priorität angefordert hat, d.h. sie sendet dem anderen das Token und wartet, bis es es wieder zurückerhält. So lange andere Stationen eine höhere Priorität anfordern, bleibt die Station im "Priority Hold"-Status - eventuell ewig.

Überwacht wird der Ring über eine zentrale, aktive Monitorstation (der wiederum von einem Standby-Monitor überwacht wird), die den Ring schützt vor:

  • Zirkulierenden Rahmen und Token mit hoher Priorität: setzt Prüfbit im Rahmen => wenn es im Rahmen bleibt, dann hat sich Sender abgeschaltet => Monitor löscht Ring und baut ihn mit "Purge" neu auf.
  • Verlorenen Token: merkt Monitor über Timeout.
  • Mehreren aktiven Monitoren: Monitor schaltet sich bei fremden Monitor-Frames selbst ab.

Alle Stationen können Management-Frames versenden, wie z.B. Claim Token="Ich will das Token haben oder Monitorstation sein" oder Purge="Ich installiere den Ring neu". Häufig wird daher der Ring als Stern konzipiert, wobei im Kabelzentrum intern ein Ring geschaltet werden kann, wenn eine Station ausfallen sollte.

Bemerkt eine Station den Ausfall des Monitors, dann wird der Token-Claiming-Prozess gestartet: die Station sendet ein CLAIM-Token und jede Station, deren Adresse grösser als die des Senders ist und die Monitor sein will, kann das CLAIM-TOKEN durch ein eigenes ersetzten - kommt es zweimal unverändert an der Station vorbei, wird sie Monitorstation.

Kritik: Für die beiden letzten MAC-Protokolle gilt, dass je höher die Auslastung ist, sie desto effizienter die Bandbreite des Mediums nutzen. Für Die CSMA-Varianten gilt dagegen, dass sie bei starkem Verkehr wegen der vielen Kollisionen nur wenig effizient sind.

4.1.6.2. FDDI

Die vorherigen Protokollnormen basierten alle auf Kupfernetzen, jedoch sind Lichtwellenleiter-Netzwerke immer stärker vertreten. Eines der bekanntesten Protokolle auf diesem Sektor stellt FDDI dar. Mit ihm können bis zu 1000 Stationen über LWL verbunden werden. Statt Laser werden ungefährliche LEDs als Signalgeber eingesetzt, statt teurer Monomodefasern Monomodefasern, da die für die Bitrate von 100 Mbps genügen. Sehr häufig werden FDDI-Netzwerke als Backbone für bestehende Kupfernetze gebraucht.

Physikalisch besteht FDDI aus zwei gegenläufigen, unidirektionalen Ringen, die bei einem Bruch zusammengeschaltet werden können, sodass ein sehr langer Einzelring entsteht. Es werden zwei Klassen von Stationen unterschieden: A-Stationen, die an beiden Ringen hängen und B-Stationen, die nur an einem Ring hängen. Da Manchester-Coding sehr redundant arbeitet, wird für FDDI das günstigere 4 aus 5-Coding eingesetzt, dass allerdings nicht selbsttaktend ist, wodurch sich der Synchronisationsaufwand etwas erhöht.

Im Gegensatz zum Token-Ring können in FDDI Stationen auch selbst Token erzeugen, wenn der Ring frei ist. Dadurch können sich mehrere Rahmen gleichzeitig auf dem Ring befinden. Mithilfe von Synchronisationsrahmen kann man sich auf FDDI auch Bandbreite garantieren lassen und als PCM-Kanal nutzen. Dazu werden maximal 16 Synchronisationsrahmen 8000/s von einer Hauptstation erzeugt, jeder mit 96 PCM-Kanälen mit je einem Byte Kapazität, die zu reservieren sind. Alle 16 Synchronisationsrahmen bieten 1536 PCM-Kanäle und belegen eine Bandbreite von 98.3 Mbps. Über den Rest kann frei verfügt werden.

4.2. Die Sicherungsschicht

Die Funktionen der Sicherungsschicht, die in den folgenden Abschnitt diskutiert werden, werden in der IEEE-Norm 802.2 beschrieben, die die Logical Link Control (LLC) umfasst, die auf den HDCL-Protokollen von IBM basieren.

4.2.1. Schnittstelle anbieten für die Vermittlungsschicht

Um eine Schnittstelle anzubieten für die Vermittlungsschicht bietet die Sicherungsschicht unbestätigte, verbindungsunabhängige Dienste (LLC-Klasse 1) an, z.B. für Sprache, wo Fehler nicht ins Gewicht fallen, bestätigte, verbindungsunabhängige Dienste (LLC-Klasse 3) und verbindungsorientierte Dienste (LLC-Klasse 2), die die Reihenfolge der abgesendeten Daten garantieren.

4.2.2. Rahmenaufbau festlegen

Die Sicherungsschicht umrahmt Pakete der Vermittlungsschicht und versieht sie mit einer Prüfsumme. Als Rahmenmarkierung kommen folgende Techniken infrage:

  • Zeitlücken zwischen den Rahmen (jedoch sind Zeitabläufe in LANs nicht garantierbar)
  • Zeichenanzahl-Feld (Chaos, wenn falsch, da alle nächsten Rahmen dann auch nicht mehr erkannt werden können; zudem ist die Abbruchstelle für Duplikat-Sendungen nicht mehr feststellbar)
  • Anfang- und Endzeichen mit Zeichenstopfen. DLE-STX (Data Link Escape, ASCII Code 127, und Start of Text, ASCII Code 2) und DLE-ETX (End of Text, ASCII Code 3), im Datenteil werden alle DLEs mit einem zusätzlichen DLE versehen und vom Empfänger dann wieder herausgenommen)
  • Anfang- und Ende-Flag mit Bitstopfen (01111110, im Datenteil werden nach Fünf Einsen stets eine Null eingeschoben und später vom Empfänger wieder rausgenommen)
  • Kodierungsregelverstösse in der Bitübertragungsschicht (z.B. beim Manchester-Coding low-low- oder high-high-Bits übertragen; diese Technik wird bei OSI in der 802-Norm beschrieben)

4.2.3. Fehlerüberwachung

Probleme bei der Übertragung von Daten haben die physikalischen Medien durch Absorption (Dämpfung, d.h. die Amplitude der Signale schrumpft), Dispersion (Verzerrung, d.h. die Periodendauer eines Signales wird gestreckt, weil das Signal von eckiger zu runder Form übergeht), weisses Rauschen (Grundrauschen), Übersprechen (z.B. durch Induktionsstrom) und Impulsstörungen durch die IMPs. Fehler treten i.d.R. meist blockweise auf (nicht in LWL!), was ihre Verteilung gering hält, ihre Entdeckung aber nicht erleichtert. Neben Fehlern in der Übertragung können auch ganze Rahmen verschwinden oder Bestätigungen ausbleiben. Die Aufgaben der Sicherungsschicht sind hier:

  • Datenfehler bei der Übertragung zu erkennen/zu beheben.
  • Rahmen zu Quittieren über ACK/NAK.
  • Time out-Techniken gegen verlorene Rahmen/Quittierungen einzusetzen.
  • Sequenznummern zu führen, die Duplikate verhindern helfen sollen.
4.2.3.1. Fehlererkennungsmethoden und Fehlerkorrekturmethoden

Fehlererkennungsmethoden sind z.B. VCR (Vertical Redundancy Check, Querparität, Paritätsbit für jeweils ein Zeichen) und LRC (Longitudinal Redundancy Check, Blockparität, Paritätsbits für geblockte 0er-Bits, für alle 1er-Bits usw.). Beide Methoden versagen jedoch bei der Entdeckung von stossweise Störungen. Hierfür eignet sich die Matrixtechnik, die Paritätsbits pro Spalte und pro Zeile eines Datenblocks mitsendet. Bei einem 8 x 8-Datenblock wird der Fehler gefunden, sofern er nicht mehr als 8 bit auf einmal geändert hat.

Für fehlererkennende Codes sind den Codewörtern mindestens e+1 zusätzliche redundante Bits anzuhängen, um e-Bit-Fehler zu erkennen, Fehler-korrigierenden Codes sogar 2*e+1, um e-Bit-Fehler zu korrigieren, wobei e+1=D bzw 2*e+1=D der Zahl entspricht, mit der sich zwei Codewörter eines Codes minimal unterscheiden (Hamming-Abstand D).

Beispiel: wir betrachten einen Code, dessen Wörter sich aus 2 bit aufbauen, d.h. es existieren folgende Wörter: 00, 01, 10 und 11. Wie leicht zu erkennen ist, besitzt dieser Code einen Hammingabstand von 1, d.h. ohne Zusatzbits ist er weder fehlererkennend, noch fehlerkorrigierend. Zur Fehlerkorrektur ist ein Hammingabstand von 3 nötig, der durch 3 Zusatzbits erreicht wird. Dann lassen sich nach obiger Formel (D=3=2*e+1=2*1+1) 1-bit-Fehler korrigieren. Annahme: es genügen zwei Zusatzbits zur Korrigierung von 1-bit-Fehlern => wir erhalten die Übertragungswörter 0000, 0101, 1010 und 1111. Wird nun aber das fehlerhafte Wort 1000 übertragen, so lässt es sich nicht eindeutig korrigieren, da es 1010 oder 0000 gewesen sein könnte.

Es lässt sich sagen: Zur Korrektur von 1-Bit-Fehlern sind r Prüfbits nötig, wobei gilt (n=Anzahl illegaler Codewörter mit Hamming-Abstand 1=m+r, wobei m der Code-Bitanzahl entspricht):

(n+1)*m^2 <= 2^n <==> (m+r+1) <= 2^r.

Daraus lässt sich z.B. ermitteln, dass bei einem 7-Bit-Code wie ASCII minimal 4 Paritätbits nötig sind, um Ein-bit-Fehler zu erkennen (weil 7+4+1=12 <= 16). Dazu schlug Hamming die folgende Methode vor:

  1. Die 7 bit der Codewörter belegen die (von links gezählten) Bitposition 3, 5, 6, 7, 9, 10 und 11, während die 4 Prüfbits die Positionen 1, 2, 4, und 8 belegen.
  2. Ist ein Datenbit gesetzt, so wird dessen Position als Binärzahl ausgedrückt. Anschliessend werden alle Binärzahlen XOR-aufsummiert. Das Ergebnis gibt dann die Prüfbits wieder.

Beispiel: das Codewort 1000110 soll nach obiger Methode mit 4 Prüfbits codiert werden. Wir erkennen, das die Bitposition 3, 9 und 10 gesetzt sind - als linksseitige, vierstellige Binärzahlen ausgedrückt ergibt das 1100, 1001 und 0101. XOR-aufsummiert erhalten wir das Ergebnis 1100 XOR 1001 XOR 0101 = 0000, d.h. das Codewort wird ohne Setzung eines Prüfbits übertragen, also in der Form "00 1 0 000 0 110".

Die Fehlerkorrektur spielt nur in Simplex-Kanälen eine Rolle, die keine Rückmeldung für eine Wiederholungssendung gestatten. Zur Fehlererkennung gibt es einfache Paritätbits, die zur Blockparität erweiterbar sind, aber es werden v.a. Polynom-Codes (CRC, Cycle Redundancy Check) verwendet: Bei dieser Technik werden die Rahmen (samt Prüfsumme) durch ein sogenanntes Generatorpolynom geteilt, wobei sich Null ergeben muss. Damit sind alle Fehlerbündel auffindbar, deren Länge unter der Anzahl der Prüfbits liegt.

Das folgende Beispiel erklärt die Vorgehensweise: Der Rahmen 1101011011 soll übertragen werden. Als Generatorpolynom wird 10011 verwendet. Der Sender muss nun dem Rahmen 4 Nullen anfügen (Anzahl der Generatorpolynom-Stellen - 1) und ihn dann durch das Generatorpolynom teilen.

11010110110000
10011
010011
 10011
  00001
  00000       <=== Generatorpolynom > 00001
   00010
   00000
    00101
    00000
     01011
     00000
      10110
      10011
       01010
       00000
        10100
        10011
         01110  ===> abzusendender Rahmen: Rahmen+Rest
                ===> 1101011011 1110

Für das Generatorpolynom kennt OSI drei Normen: CRC-12, CRC-16 und CRC-CCITT.

4.2.3.2. Weitere Fehlerüberwachungsprotokolle

Die restlichen Fehlerüberwachungsaufgaben der Sicherungsschicht werden in diverse Protokolle integriert. Hier sind zu nennen:

  • Uneingeschränktes Simplex-Protokoll: Das einfachste Protokoll, dass nur einfach Daten von der Quelle zum Sender pumpt, ohne Flusskontrolle und ohne Quittungen.
  • Stop-and-Wait-Simplex-Protokoll: Dieses Protokoll ist zwar im Datenfluss simplex, gestattet aber Quittierungen. D.h. der Sender sendet einen Rahmen, wartet auf die Quittung und sendet dann erst den nächsten Rahmen. Der Grossteil der Bandbreite bleibt dabei ungenutzt, weil der Sender immer erst auf die ACKs warten muss.
    Sender-Prozedur:                   Empfänger-Prozedur:
    
    while(TRUE) do begin               while(TRUE) do begin
        FromHost(buffer);                  wait(event);
        frame.info=buffer;                 getf(frame);
        sendf(frame);                      ToHost(frame.info);
        wait(event); // for ACK            sendf(frame2);      // ACK
    end;                               end;
    
  • Schiebefensterprotokolle: Diese Protokolle dienen der Duplex-Übertragung. Aus Effizienzgründen werden die Quittungen (ACKs und NAKs) Piggybacking transportiert. Die Quelle verfügt über einen Puffer, in den n Rahmen passen. Die Rahmen bleiben immer genau so lange in ihrem Puffer, bis ihr Empfang bestätigt wurde. Bleibt die Bestätigung aus, weil der Rahmen oder die Quittung verloren gegangen ist, dann sorgt ein Time-out für eine Duplikatsendung. Falls in diesem Fall nur die Quittung verloren gegangen war, erkennt der Empfänger den Rahmen an der Sequenznummer als Duplikat und ignoriert ihn (die Sequenznummer dient damit gleichzeitig der Flusskontrolle und der Fehlerüberwachung). Er ignoriert zudem alle Rahmen, die keinen Platz mehr finden in seinem Puffer. Der Rahmen mit der untersten Fensternummer wird jeweils an die Vermittlungsschicht weitergegeben, wodurch die Reihenfolge gesichert wird, und dann quittiert.

Das Schiebefenster kann die Grösse eins haben, wobei es dann einem Stop-and-Wait-Protokoll entspricht oder es hat grössere Fenster, die ständig mit der maximalen Anzahl unbestätigter Rahmen gefüllt sind, was einer Pipeline-Protokoll entspricht. Letzteres kennt zwei Methoden das Fehlerhandlings: Gehe-n-zurück-Strategie (bei Time-out Duplikatsendung aller Rahmen mit grösserer Sequenznummer als der zerstörtem Rahmen) und selektive-Wiederholungsstrategie (nur den falschen Rahmen nach dem Time-out duplizieren, nur das ACK des höchsten erfolgreich übertragenen Rahmens zurücksenden).

Es gilt: je grösser die Verzögerung bei der Übertragung, desto grösser muss die Fenstergrösse w (des Empfängers) gewählt werden. Genügt bei Terminal-Host-Verbindung dem Host ein Puffer, sind bei gleichwertigen Partnern schon ca. 7 Puffer und bei Satelliten-Kommunikation sogar bis zu 127 Puffer nötig.

4.2.4. Rahmenflusssteuerung

Die Sicherungsschicht muss dafür sorgen, dass eine schnelle Quelle eine langsame Senke nicht mit Rahmen überschwemmen kann. Dazu sind Rückmeldemechanismen nötig.

4.2.5. Verbindungsverwaltung

Um eine Verbindung ähnlich einem Draht zu machen, auch wenn Paketvermittlung zugrunde liegt, muss die Reihenfolge über z.B. Sequenznummern garantiert werden. Der Verbindungsaufbau und Verbindungsabbau muss im Protokoll berücksichtigt werden. Und es sollte Poll-Pakete geben, die es untergeordneten Terminals gestatten, dass Übertragungsmedium zu nutzen.

4.2.6. Protokollverifikationstechniken

Protokolle können schnell sehr umfangreich und komplex werden. Daher ist es sinnvoll, formale Instrumentarien zu entwickeln, die helfen, die Protokolle auf Korrektheit und Vollständigkeit zu überprüfen.

4.2.6.1. Endliche Automaten

Die Instanz eines Protokolls und seine Kanäle zum Austausch von Paketen befinden sich immer in einem bestimmten Zustand, d.h. alle Variablen und der Programmzähler haben einen definierten Wert. Von jedem Zustand aus gibt es Übergänge zu einem anderen Zustand. Ausgelöst werden solche Übergänge durch Ereignisse, wie z.B. dem Time-out einer Instanz oder dem Paketverlust eines Kanals. Zustände und Übergänge sind als gerichteter Graph darstellbar, der von einem bestimmten Anfangszustand aus über Erreichbarkeitsalgorithmen analysiert werden kann, um so z.B. Deadlocks aufzuspüren. Formal kann ein endlicher Automat als Quadrupel dargestellt werden:

(Zustandsmenge, austauschbare Rahmen, Anfangszustände, Übergänge)

4.2.6.2. Estelle-Protokolle

Da endliche Automaten unübersichtlich werden können, obwohl sich viele Funktionen nur mit anderen Variablenwerten einfach nur ständig wiederholen, wurden Estelle-Protokolle geschaffen, die die einzelnen Module als abgewandelte Pascal-Prozeduren beschreiben.

trans
from            Zustand 1
to              Zustand 2
when            Ereignis                  <== z.B. Time-out
provided        Boolescher Vergleich      <== z.B. Sequenznummer > 5
priority        wenn mehrere Ereignisse gleichzeitig möglich sind
begin
  Pascal-Programm
end
4.2.6.3. Petrinetze

Petrinetze verdeutlichen den Ablauf, oder besser die möglichen Zustandsübergänge eines Protokolls durch ein Token, welches durch das Petrinetz navigiert werden kann.

4.2.7. Beispiele der Sicherungssicht

4.2.7.1. Öffentliche Netzwerke

Benutzen als Sicherungsschicht HDLC (OSI), auch LAPB (Link Access Procedure-Balanced, CCITT-X.25) genannt. Dieses Protokoll ist synchron, bitorientiert, benutzt Bitstopfen, 3-bit-Sequenznummern-Schiebefenster-Protokolle (auf 7 bit erweiterbar für Satelliten-Kommunikation), Piggybacking und kennt drei verschiedene Rahmenarten, gekennzeichnet im Steuerungsfeld: Informationsrahmen für Daten, Überwachungsrahmen für z.B. NAKs mit gehe-n-zurück-Strategie oder selektive-Wiederholungsstrategie und unnummerierte Rahmen für die Signalisierung, die nicht an die Vermittlungsschicht weitergegeben wird. Das Rahmenformat sieht folgendermassen aus:

01111110 Terminalnummer Steuerungsfeld Daten CRC-CCITT 01111110

Bei HDCL gibt es verschiedene Prozedurklassen, die die Teilnehmer verwenden können:

  • Unbalanced Mode: Eine Station ist der Boss und darf alleine Senden oder Senderecht vergeben (Token Passing oder Polling).
  • Balanced Mode: Die Stationen sind gleichberechtigt und dürfen senden, sowie das Medium frei geworden ist.
4.2.7.2. ARPANET

Unterscheidet Host-IMP-Protokolle und IMP-IMP-Protokolle. Zuerst zum Host-IMP-Protokoll: Ohne ACK erfolgt ein Time-out nach 30 Sekunden, dann erfolgt eine Duplikatsendung; das BS packt an 8000 bit grosse Rahmen ein 40 bit-Kopf, die Sicherungsschicht zusätzlich einen Protokollkopf von 96 bit. Das IMP-IMP-Protokoll ist ein lebendes Fossil: Es ist zeichenorientiert, benutzt Zeichenstopfen und ein achtkanaliges Stop-and-Wait-Protokoll, kennt aber immerhin Piggybacking und Prioritäten; alle 125 Millisekunden findet ein Timeout statt und jeder IMP prüft die CRC-Summen der jetzt nur noch 1000 bit grossen Rahmen.

4.3. Die Vermittlungsschicht

Hier findet die unterste End-to-End-Übertragung statt, wobei v.a. Adressierungsprobleme auftreten, da nicht nur eine Kommunikation von End- zu Endstelle, sondern auch zu LANs hinter den Endstellen aufgebaut werden sollen. Dazu muss das Protokoll Bescheid wissen über das Subnet. Die einzelnen Funktionen der Vermittlungsschicht werden jetzt vorgestellt. Zu bemerken ist noch, dass die 3. Schicht häufig die Funktionen auch der 2. Schicht übernimmt (u.a. Fehlererkennung und Fehlerbehebung).

4.3.1. Funktionen

Dienste für die Transportschicht: Es gilt, dass die Dienste des Subnets i.d.R. den Diensten der Vermittlungsschicht entsprechen. Es sind also die Dienste, die ein Netzwerkbetreiber dem Benutzer anbieten kann. Da Netzwerkbetreiber sich gerne Verbindungen bezahlen lassen, bevorzugen sie verbindungsorientierte Dienste (Kanäle), die genau übertragen und die Komplexität in die IMPs verlegt. Die Internetgemeinde mag aber lieber schnelle und billige unbestätigte verbindungsunabhängige Dienste (Datagramm-Dienste) wie im ARPANET, da hier Überprüfungen auch im eigenen Host stattfinden können. OSI übernahm daher beide Dienste in die Protokolle der Vermittlungsschicht. Eine Sonderform stellen die virtuellen Verbindungen wie SNA und X.25 dar, die eine feste Verbindung durch das Subnet aufbauen, die Daten aber in Form von Paketen übertragen; sie sind sicherer, die Flusssteuerung obliegt dem Subnet, aber sie sind aufwendiger für das Subnet oder die Endgeräte (je nach Implementierung) als reine Datagramm-Dienste.

  • Dienstelementen des verbindungsorientierten N-Dienstes sind: CONNECT, DISCONNECT, DATA, DATA-ACKNOWLEDGE (wenn kein Piggybacking möglich ist), EXPEDITED-DATA (beschleunigte Daten) und RESET (Katastrophen-Informationspaket).
  • Dienstelementen des verbindungsunabhängigen N-Dienstes sind: UNITDATA, FACILITY (für QOS-Austausch) und REPORT (für Subnet-Fehlermeldungen).

Das OSI-Netzwerkadressformat ist sehr flexibel: Ein Feld enthält eine Nummer von 10-99, dass den Adresstyp angibt, z.B. 13=Telefon, 17=IP. Ein zweites Feld enthält dann die Adresse im jeweiligen Format, wobei bis zu 20 Bytes belegt werden dürfen. Üblich sind dabei hierarchische Adressen von globaler Eindeutigkeit, die genau einen NSAP (Network Service Access Point) identifizieren, indem ein Teil die WAN-Adressierung beinhaltet und ein anderer Teil die LAN-Adressierung.

Es werden zur Verwendung realer Netze, die nicht nach OSI aufgebaut wurde, wie z.B. SNA, sogenannte Rollen-Protokolle angeboten, die ein OSI-Netz bei Nicht-OSI-Umgebung simulieren können. Die interne Organisation der Vermittlungsschicht ist aus folgenden Rollen-Protokoll-Subschichten aufgebaut:

  • SNICP (Subnetwork Independent Convergence Protocol): sitzt auf SNDCP auf und simuliert den OSI-Vermittlungsdienst.
  • SNDCP (Subnetwork Dependent Convergence Protocol): sitzt auf SNAcP auf und gleicht die Mächtigkeit des realen Subnets an die Mächtigkeit von OSI-Netzen an.
  • SNAcP (Subnetwork Access Protocol): entspricht dem spezifischen 3.Schicht-Vermittlungsprotokoll des realen Netzes.

Durch Rollenprotokolle kann ein X.25-Verbindungsaufbau (zur Erinnerung: X.25 ist eigentlich ein verbindungsunabhängiger Dienst) durch folgende Transformationen durch OSI-Protokollen erreicht werden.

N-CONNECT.request            ->            CALL REQUEST packet
N-CONNECT.indication         <-            INCOMING CALL packet
N-CONNECT.response           ->            CALL ACCEPTED packet
N-CONNECT.confirm            <-            CALL CONNECTED packet      

Für verbindungsorientierte Dienste eignen sich Datagramm-Subnets und virtuelle Verbindungssubnets gleichermassen. Für verbindungsunabhängige Dienste machen nur Datagramm-Netze einen Sinn. Datagramm-Subnets brauchen viel Adressen-Overhead, es genügen einfache Tabellen in den IMPs, überleben IMP-Abstürze problemlos, können ein Subnet gleichmässig ausnutzen und sind v.a. geeignet für Transaktionsdienste, die keiner ständigen Verbindung bedürfen.

Virtuelle Verbindungssubnets genügen kleine Adressfelder zur Bestimmung des virtuellen Kanals, brauchen dafür in den IMPs aber zusätzlich eine virtuelle Verbindungstabelle, bei ihnen sind belegte Leitungen möglich, ein IMP-Absturz bedeutet Leitungszusammenbruch, sie sind aber geeignet für Terminal-Dienste, die laufend Ein-Zeichen-Pakete versenden.

4.3.2. Leitwegbestimmung (Routing)

Pakete müssen einen Weg vom Quell-Host zum Ziel-Host finden und von IMP zu IMP. Dafür existieren verschiedene Algorithmen, die im Folgenden vorgestellt werden:

  • Statische Leitwegbestimmung: Beim Hochfahren des Systems werden den IMPs hier statische Tabellen vom Netzwerkoperator gegeben, die entweder nur kürzeste Pfade von Quelle zum Ziel enthalten (Shortest-Path-Routing) oder auch Mehrfachwege kennen (Multi-Path-Routing), aus den sie Alternativen wählen können, wodurch sich auch die Robustheit des Subnets erhöht. Geschieht dies zufällig, dann sprich man von einem Random Walk-Algorithmus. Werden Duplikate auf alle Ausgänge gelegt, dann spricht man vom Fluten (das auch selektiver geschehen kann, dann aber adaptiv ist).
  • Adaptive Leitwegbestimmung: Bei diesen Algorithmen erfahren die IMPs etwas über den aktuellen Zustand des Subnets und passen sich entsprechend an. Unterschieden werden müssen hier isolierte, zentralisierte und verteilte Leitwegbestimmungsalgorithmen.
  • Isolierte Leitwegbestimmung: Diese ist dann vorhanden, wenn jeder IMP sich selbst Informationen über das Subnet besorgt. Beispiele:

    Der Hot-Potato-Algorithmus (Paul Baran 1964) legt eingehende Pakete einfach auf den leersten Ausgang, egal wo dieser hinführt.

    Der Rückwärtslernen-Algorithmus (ebenfalls von Baran) bekommt über die Pakete Informationen über die Anzahl der Hops, die sie von bestimmten IMPs zurückgelegt haben. Danach kann der IMP Pakete in Zukunft dorthin leiten, wo die wenigsten Hops zu erwarten sind, bis sie am Ziel sind.

    Das Delta-Routing ist eine Mischung aus isoliertem und zentralisiertem Algorithmus. Die Knoten sammeln Daten aus ihrer Umgebung (Verkehr, eigenes Delay, Puffervorrat usw.), senden sie an ein Routing Control Center (RCC), das optimale Routing-Tabellen zurücksendet, auf denen mehrere Pfade zur Auswahl stehen.

  • Zentralisierte Leitwegbestimmung: Dieses Verfahren benötigt ein RCC, welches die IMPs immer wieder mit Tabellen versorgt, die den aktuellen Datenverkehr berücksichtigen, was aber mit vielen Nachteilen verbunden ist, z.B Konzentration um das RCC, Ausfallgefahr und verschiedene Aktualisierungsgeschwindigkeit der IMPs. Dieses Verfahren wurde z.B. mit über 1.000 Knoten im TYMNET realisiert.
  • Verteilte Leitwegbestimmung: Hier tauschen die IMPs Informationen untereinander aus, z.B. durch Echopakete, die die Hops zählen u.ä. Dieses Verfahren wurde früher bei ARPANET verwendet.

4.3.3. Überlaststeuerung

Damit ein Subnet nicht in Paketen ersäuft, müssen Strategien getroffen werden, die helfen, dies zu verhindern, z.B:

  • Pufferreservierung: Verteilung der Subnet-Kapazität durch Vorabzuweisung von Puffern bei virtuellen Verbindungen (statt nur Tabelleneintrag zu besetzten). Z.B. zur audiovisuellen Übertragung notwendig, um Bandbreite garantieren zu können.
  • Paketverwerfung: Hier werden nicht zustellbare Pakete verworfen, indem man gegenteilig zur ersten Strategie verfährt, d.h., indem man alle Pakete verwirft, die keinen Pufferplatz finden können. Verfeinert werden kann das Ganze z.B. wie im ARPANET, wo wenigstens alle Piggybacking-Informationen weitergeleitet werden und jede Leitung ein Mindestmass an Puffern hat, der erste Benutzer aber den ganzen Rest zugewiesen bekommt.
  • Isarithmetische Überlastkontrolle: Die Paketanzahl im Netz wird hierbei beschränkt durch eine Überlastkontrolle, bei der der IMP für jedes weiterzuleitende Paket erst eine Genehmigung (Permit) erhalten muss, wobei die Anzahl der Genehmigung konstant bleibt. Problematisch dabei ist jedoch, dass einzelne IMPs immer noch in Paketen ersaufen können.
  • Datenflusssteuerung: Dies bedeutet die Begrenzung der Sendeleistung der Quell-Hosts. Kann ebenfalls helfen, Subnets vor zu viel Paketen zu bewahren (beliebt im ARPANET). Da Grenzwerte aber meistens von der Durchschnittsbelastung ausgehen, wird hier häufig Bandbreite verschenkt; der Durchsatz des Subnets ist also schlecht.
  • Choke-Pakete: Eine Datenflusssteuerung, die nur in Notfällen greift, ist effektiver als die vorherige Strategie. Wann immer ein IMP in Paketen zu ertrinken droht, sendet er ein Choke-Paket an die Quelle, die dann ihre Leistung um x Prozent senkt, und nach einem Timeout wieder volle Leistung fährt.

Die schlimmste Folge von Subnet-Überlastungen sind Deadlocks, d.h., zwei IMPs versuchen Pakete auszutauschen und warten dazu jeweils auf einen freien Puffer des anderen. Damit es hier nicht zum ewigem Halt kommt, wurde eine spezielle Anti-Deadlock-Methode entwickelt: Jedes Paket bekommt einen eindeutigen Zeitstempel (genaue Synchronisation wichtig!) und die ältesten Pakete werden jeweils vorrangig behandelt, während der Verlierer den IMP-Puffer räumen muss und in eine anderer Richtung gesendet wird.

4.3.4. Internetworking

Möchte man Daten von einem Netz in ein anderes versenden, dann kommt es dabei zu vielfältigen Problemen. Doch zuerst wollen wir sehen, warum eine LAN-Brücke-LAN-Verbindung sinnvoll sein kann.

  • Zur Verbindung von LANs wegen der Geographie oder Autonomiebedürfnissen.
  • Weil ein LAN zu wenig Kapazität für alle Rechner besitzt.
  • Weil eine Brücke als Verstärker nötig ist.
  • Weil Brücken LANs vor anderen LANs schützen können.

Auch das Internetworking zwischen OSI-Protokollen ist nicht trivial, denn:

  • Es existieren idiotischerweise drei verschiedene Rahmenformate.
  • Die Standards arbeiten mit verschiedenen Bitraten, was sich v.a. auf die Time-out-Technik katastrophal auswirken kann.
  • Die Standards verlangen verscheiden grosse Rahmen, aber die OSI-Protokolle verfügen in der Vermittlungsschicht über keine (Re-)Assemblierungstechniken.

Mit anderen Worten: Die OSI hat drei Standards geschaffen (802.3, 802.4 und 802.5), die untereinander nicht kompatibel sind!

Doch das ist nicht ganz alleine Schuld der OSI, denn die Rahmengrösse ist z.B. nicht frei wählbar; sie ist abhängig von:

  • der Hardware (z.B. TDM-Slots).
  • dem BS (z.B. alle Puffer sind im System generell 512 Bytes gross).
  • der Software bzw. den Protokollen (z.B. Paketlängenfeld-Bitanzahl).
  • Effizienzgründen (kleine Pakete belegen Kanal nur kurz und wirken sich besser aus bei Duplikate-Sendungen).

4.3.5. Die Trägerdienste der Telekom

Ein Dienst der Telekom umfasst alle sieben OSI-Schichten, denn er ermöglicht eine wohldefinierte Endanwendung. Dienste sind z.B Telefonie, Telex, Teletext und BTX. Ein Trägerdienst dagegen reicht nur bis zu Schicht 3, da er nur eine Übertragungstrecke zur Verfügung stellt. Trägerdienste sind z.B. Datex-L, Datex-P, Hauptanschluss für Direktruf und z.T. ISDN.

Sehen wir uns einige (Träger-)Dienste einmal näher an:

  1. Telefonnetz: für analoge Endgeräte. Intern wird z.T. mittels PCM digital übertragen. Es findet In-Band-Signaling statt. Die Verbreitung ist weltweit gegeben. Bandbreite: 3100 Hz. Eine Datenübertragung kann über Modems erfolgen.
  2. Datex-L: dient hauptsächlich der leitungsvermittelnden Kommunikation zwischen Grossrechnern, wobei Datenraten bis 64 kbps möglich sind. Wichtig dabei: Sender und Empfänger müssen exakt gleichschnell sein! Die Gebühren hängen von der Verbindungsdauer ab.
  3. Datex-P: benutzt die X.25-Protokolle, ist also paketvermittelnd, d.h. Sender und Empfänger müssen nicht gleichschnell sein. Die Zeichenströme der Terminals können über PAD-Protokolle auf Datex-P angepasst werden. Datenraten bis 48 kbps sind möglich. Die Gebühren hängen vom übertragenen Datenvolumen ab.
  4. Hauptanschluss für Direktruf (Standleitungen): dient der leitungsvermittelnden Kommunikation innerhalb von Organisationen, mit Datenraten bis zu 2 Mbps * ganzzahliges Vielfaches. Die Gebühren hängen alleine von der Entfernung ab. Es kann unterscheiden werden, ob die Telekom oder die Organisation die Verwaltung der Leitung übernimmt.

4.4. Die Transportschicht

Diese Schicht ist sehr wichtig, schützt sie doch den Anwender von Rechnernetzen vor allen Mängeln des Subnets und liefert der Sitzungsschicht damit einen fehlerfreien Dienst an. Trotzdem gibt es neben der OSI-Transportschicht nur noch das TCP vom ARPA Internet. Beide sind sie hauptsächlich verbindungsorientiert zu benutzen. Ihre Funktionen werden im Folgendem beschrieben.

4.4.1. Dienste an die Sitzungsschicht

Dienste an die Sitzungsschicht: Die Dienste der Transportschicht entsprechen denen der Vermittlungsschicht, sie bietet der Sitzungsschicht also verbindungsorientierte und verbindungsunabhängige Dienste an. Doch warum eigentlich? Weil die Transportschicht die QOS der Vermittlungsschicht verbessern soll, also deren Fehler unterbinden will. Dazu führt sie vor dem Verbindungsaufbau eine Optionsabsprache durch, in dem sie die gewünschten Soll-Werte u.a. für

  • die Verbindungsaufbaudauer
  • die Verbindungsaufbau-Ausfallwahrscheinlichkeit
  • die Restfehlerrate
  • den Durchsatz
  • den Datenschutz
  • und die Priorität

vorschlägt, und das Subnet daraufhin eine positive oder negative Antwort zurückmeldet.

Die Restfehlerrate ist folgendermassen aufgebaut (TPDU: Transport Protocol Data Unit; T1=verlorene TPDUs, T2=falsche TPDUs, T3=generierte, aber nicht abgesendete PDUs, T4=korrekte TPDUs):

Restfehlerrate = (T1+T2+T3) / (T1+T2+T3+T4)

Die T-Dienstelemente sind die gleichen wie bei der Vermittlungsschicht, nur dass es jetzt keine N-REPORTs und N-RESETs mehr gibt, denn mit diesen soll die Sitzungsschicht ja gerade nichts mehr zu tun haben. Im Ganzen ähnelt der OSI-Transportdienst damit sehr dem Pipe-Dienst des UNIX-Systems.

4.4.2. Transportprotokolle

Die Transportprotokolle erinnern an die Protokolle der Sicherungsschicht, sind jedoch aufwendiger zu gestalten, da hier nicht nur IMP-IMP-Verbindungen, sondern Verbindungen durch ein ganzes Subnet zu berücksichtigen sind. Und Subnets haben die Fähigkeit, Pakete zu verlieren, sie zu duplizieren oder längere Zeit zu speichern. Ausserdem müssen den Paketen Adressen mitgegeben werden und nicht nur die Kanalnummer, auf der sie der gerade aktuelle IMP weiterleiten soll.

Es gibt drei Arten von Subnets:

  1. A-Subnet: Fehlerfrei, liefert keine N-RESETs zurück.
  2. B-Subnet: N-RESETs möglich.
  3. C-Subnet: Verlorene, duplizierte Pakete und N-RESETs möglich.

Jedes dieser Subnet verlangt nach verschiedenen Transportprotokollen (TP). OSI unterscheidet hier fünf Kategorien:

  1. Für A-Subnets, also genügt ein einfaches Transportprotokoll.
  2. Für B-Subnets, das TP muss also N-RESETs abfangen können.
  3. Für A-Subnets, wo das TP Multiplexing erlaubt.
  4. Für B-Subnets, wo das TP Multiplexing erlaubt und N-RESETs abfängt.
  5. Für C-Subnets, TP verhindert doppelte/verloren Pakete und N-RESETS.

Das Transportprotokoll der Kategorie 4 entspricht dabei in etwa TCP.

Die OSI-Transportprotokoll kennen zehn verschiedene TPDUs: CONNECTION REQUEST, CONNECTION INDICATION, DISCONNECTION REQUEST, DISCONNECT INDICATION, DATA, EXPEDITED DATA, DATA ACKNOWLEDGEMENT, EXPEDITED DATA ACKNOWLEDGEMENT, REJECT (nur Kategorie 0+3 zur Wiederherstellung nach N-RESETS) und ERROR (für Protokollfehlermeldungen).

4.4.3. Verbindungsverwaltung

Die Verbindungsverwaltung erweist sich in der Transportschicht als wesentlich komplexer als bei der Sicherungsschicht, wo nur Verbindungen von einem IMP zum anderen aufgebaut bzw. abgebaut werden mussten. Eine typische Ereignisfolge für eine Verbindung sei kurz dargestellt:

  1. Server-Prozess PA auf Rechner A, der die Uhrzeit übermittelt, hat sich an einen TSAP 122 (Transport Access Service Point) gehängt und wartet auf ein T-CONNECTION.indication.
  2. Prozess PB auf Rechner B will wissen, wie viel Uhr es ist. Weiss er, wo der Uhrprozess PA läuft, kann er entweder den TSAP 122 direkt oder einen fixen T-SAP ansprechen, der von einem generischem Prozess-Server generiert wurde. Dieser liefert ihm dann als Antwort den TSAP 122 zurück. Weiss PB jedoch nicht, wo sich PA befindet, so kann er über einen anderen fixen TSAP einen Name-Server befragen, der z.B. auf Rechner C läuft, der aber weiss, dass Rechner A am TSAP 122 den Uhrdienst anbietet. Weiss PB also nun Bescheid, so kann er ein T-CONNECT.request über einen freien NSAP an die Vermittlungsschicht geben mit TSAP 6 als Quelle und TSAP 122 als Ziel.
  3. Die Vermittlungsschicht von B baut eine virtuelle Verbindung zwischen seinem NSAP und dem dem des Rechners A auf.
  4. Rechner A erkennt den Verbindungswunsch von B und gibt ein T-CONNECT.indication auf den TSAP 122 und die Transportverbindung kann aufgebaut werden.
4.4.3.1. Verbindungsaufbau

Der Verbindungsaufbau ist problematisch, weil im Subnet verzögerte Duplikatpakete die neue Verbindung nutzen könnten, obwohl ihre eigene inzwischen abgebaut wurde. Dies lässt sich verhindern durch:

  • Wegwerf-TSAPs, d.h., an neue TSAPs können nie alte Duplikate gelangen.
  • Gedächtnis von IMPs, d.h. sie merken sich alle aufgehobenen Verbindungen und können so Duplikate, die bei ihnen ankommen, zerstören, bevor sie den TSAP erreichen.
  • Töten der Pakete und Rückmeldungen nach einer bestimmten Hop-Anzahl.
  • Töten der Pakete+Rückmeldungen nach einer bestimmten Zeit.
4.4.3.2. Verbindungsabbau

Der Verbindungsabbau ist problematisch, weil die Transportschichten eine Verbindung abbrechen können, während eine andere gerade Daten gesendet hat. Dies führt u.U. dazu, dass diese Daten nirgends mehr ankommen können und verlustig gehen. Dies lässt sich durch den Dreiwege-Quittungsbetrieb verhindern, wo der Verbindungsabbau in drei Schritten erfolgt:

  1. Der Sender schickt Empfänger DISCONNECT.request und setzt einen Timer. Falls ein Time-out erfolgt, dann wiederholt der Sender die Prozedur.
  2. Der Empfänger erhält DISCONNECT.indication und sendet dann ein DISCONNECT.response zurück. Ausserdem setzt er einen Timer. Nach Time-out bricht der Empfänger die Verbindung ab.
  3. Der Sender empfängt DISCONNECT.confirm, löscht seinen Timer, sendet ein DATA ACKNOWLEDGMENT.request und unterbricht die Verbindung.

Als vierten Schritt lässt sich noch anfügen, dass der Empfänger seinen Timer löscht, sofern er etwas anderes als ein DATA ACKNOWLEDGEMENT.indication erhält, d.h. in diesem Fall würde er die Verbindung nicht abbauen.

Wie ist nun eine TSAP-Adresse aufgebaut? Sie besteht aus der Host-Adresse der NSAP-Adresse (die aus einer Country-, Network- plus Host-Adresse besteht) plus der Portnummer, die den Prozess innerhalb des Host identifiziert.

4.4.4. Flusssteuerung

Die Pufferstrategie der Sicherungsschicht ist für die Transportschicht nicht praktikabel, da ein IMP nur wenige Leitungen besitzt, eine Transportschicht aber unzählige Verbindungen verwalten können muss. Üblicherweise wird daher so vorgegangen, dass der Sender nur alle abgeschickten, noch unbestätigten TPDUs im Speicher hält, während der Empfänger sich jeweils Speicher dynamisch allokiert und nach dem Empfang wieder freigibt. Kommt er mit der Allokation nicht nach, dann werden die TPDUs einfach ignoriert und keine ACKs zum Sender geschickt.

4.4.5. Multiplexing

Hier unterscheidet OSI zwei Möglichkeiten:

  1. Aufwärtsmultiplexing: Viele TSAPs werden mit einem NSAP verbunden, d.h., viele Sitzungskanäle können auf eine virtuelle Verbindung gemultiplext werden, wodurch sich deren Durchsatz erheblich erhöhen kann.
  2. Abwärtsmultiplexing: Ein TSAP wird mit vielen NSAPs verbunden, d.h. eine Sitzung kann über mehrere virtuelle Verbindungen verfügen, wodurch sie erheblich mehr Daten auf einmal durch das Subnet schicken kann.

4.4.6. Wiederherstellung nach einem Systemabsturz

Diese Aufgabe muss von der Sitzungsschicht wahrgenommen werden und ist auch dann nur möglich, wenn genügend diverse Statusinformationen aufbewahrt wurden.

4.4.7. TCP/IP-Netzwerkprotokoll

TCP ist das Transportprotokoll des ARPA Internet. Es ist nicht OSI-konform, jedoch so weit verbreitet, dass seine Besprechung hier nicht fehlen darf. In die Sockets des BSD-UNIX ist es gleich mit eingebaut worden und auch NFS von SUN basiert auf TCP/IP. Die Qualität dieses Protokoll zeigt sich nirgends deutlicher, als darin, dass es trotz explodierender Teilnehmerzahlen immer noch funktioniert. Dazu hat sicher auch das Schwarze Brett des Internets, die RFCs (Request for Comments), seinen Teil beigetragen. TCP/IP ermöglicht eine sichere Kommunikation heterogener Systeme - schnelle LANs, lahme WANs, X.25-Netze, alle werden bedient.

IP ist das Vermittlungsprotokoll. Es arbeitet verbindungsunabhängig und kennt auch keine virtuellen Pfade wie die X.25-Netze. Ausserdem überlässt es die Datensicherung vollständig der Transportschicht, d.h. dem TCP-Protokoll, das verbindungsorientiert arbeitet. Die Schichten 5 und 6 fallen bei TCP/IP weg, dafür bietet die Schicht 7 standardisierte Anwendungen wie z.B. FTP, TELNET (für Remote Logins, besser als PAD), SMTP (verbindungsorientierte E-Mail), rlogin, rsh, rcp (einfaches FTP), rpc (ROSE-ähnlich; Remote Operation Service Element), NFS usw. Wie bei OSI stellt die 4. Schicht die erste End-to-End-Verbindung. Statt TCP kann mit UDP auch ein unsicheres, verbindungsunabhängiges Transportprotokoll verwendet werden.

TCP/IP kennt vier Adressformate von 32 bit Länge:

  1. Klasse A: 8 bit Wan-Adresse und 24 bit Host-Adresse.
  2. Klasse B: 16 bit WAN-Adresse und 16 bit Host-Adresse.
  3. Klasse C: 24 bit WAN-Adresse und 8 bit Host-Adresse.
  4. Klasse D: Multicast-Host-Adresse mit 28 bit.

Je flacher die Adressen werden, umso grössere Routing-Tabellen benötigen die Gateways. Daher sind hierarchische Adressen die Norm, die in Punktnotation geschrieben werden. Hier können die Gateways alleine nach der Netz-ID des Zielnetzes routen und können die Host-ID vernachlässigen. Nachteilig daran ist, dass sich die physische Adresse eines Rechners ändert, sowie er in ein neues Netz gehängt wird. Ausserdem werden bei mehreren Netzanschlüssen mehrere Adressen nötig.

Die Adressen werden i.d.R. auf hierarchische Namen abgebildet, wobei jede Hierarchiestufe einer Domäne von Adressen entspricht, für die jeweils ein Name-Server existiert. Für jede Domäne gibt es eine Autorität, die die Namen vergeben darf. Der Domain Name Service im Client sorgt über timeout-aktualisiertes Caching (im Server oder Client) und eine Zuerst-Lokale-Abfrage-dann-Globale-Abfrage-Strategie dafür, dass die Domänenverwaltung die Name-Server, insbesondere die Wurzel-Server, nicht zu sehr belastet. Der lokale Server kann je nach Aufrufart entweder selbst den richtigen Name-Server suchen (Chaining-Methode) oder dem Benutzer die Adresse eines anderen Name-Servers zurücksenden (Referenzmethode).

Es existiert seit einiger Zeit auch eine Art 6.Schicht bei TCP/IP. Das XDR-Protokoll (External Data Representation), das - typisch amerikanisch - zwar wenig durchdacht ist, aber sehr effizient arbeitet im Gegensatz zum europäischen Presentation Layer. Es gibt keine Verhandlungsmöglichkeiten bezüglich der Transfersyntax, sondern Ganzzahlen sind z.B. generell als 4-Byte-Big-Endian zu übermitteln, Texte generell im ASCII-Format, usw. Nachteilig ist, dass identische Maschinen wegen XDR zu Umwandlungen gezwungen werden, die eigentlich gar nicht nötig wären. Eine Kontext-ID wie bei OSI entfällt, wie auch XDR überhaupt keinen eigenen Header benötigt in Datenpaketen.

NFS erlaubt einen ortstransparenten Zugriff auf Dateien (im Gegensatz zu ftp). Doch es kann nicht wie FTAM auf Dateiteile zugreifen. Um über NFS auf Dateien zugreifen zu können, müssen sie zuerst durch das Mount-Protokoll in den eigenen Dateibaum eingehängt werden. Eine Schwäche von NFS stellt derzeit noch die Sicherheit dar, doch hieran wird emsig gearbeitet. Ein Lock-Manager sorgt dann dafür, dass nicht mehrere NFS-Clients auf die gleichen Daten zugreifen können - erst dadurch wird eine Art Transaktionsverwaltung erst ermöglicht.

4.5. Die Sitzungsschicht

4.5.1. Funktionen

Diese Schicht bietet dem Benutzer Mehrwertdienste zur Transportschicht an. Sie sollen es der Darstellungsschicht ermöglichen, eine Sitzungsverbindung aufzubauen. Dabei gilt, dass jede Sitzungsverbindung eine oder mehrere Transportverbindungen benötigt. Mehrere Sitzungsverbindungen können auch die gleiche Transportverbindung nutzen. Diese Mehrfachnutzung läuft jedoch stets sequenziell ab, nie simultan, ist also deutlich zu unterscheiden vom Multiplexing der Transportschicht.

Die Sitzungsschicht (auch Session Layer oder Kommunikationssteuerungsschicht genannt) erlaubt eine verfeinerte Kommunikation als die reine Transportschicht. So lassen sich verschiedene Verbindungsabbau-Dienstelemente verwenden (wobei man sich die Frage stellen darf, warum dies nicht bereits in der Transportschicht geschehen ist), über Token wird der jeweilige Sender bestimmt (besonders elegant für SW, die auf Halbduplex-Betrieb ausgerichtet ist), die Setzung von Synchronisationspunkten erlaubt die Wiederherstellung der übertragenen Daten, sollten sie in den oberen Schichten oder beim Zielrechner verloren gegangen sein (wenn z.B. zufällig vom Benutzer ein Druckvorgang von direkt übertragener Daten unterbrochen wurde) und die Aktivitätsverwaltung ermöglicht es, Sitzungsströme zu untergliedern, kurzzeitig abzubrechen und wieder aufzunehmen (ermöglicht auch, dass z.B. Transaktionen erst am Activity-Ende ausgeführt werden).

Die Sitzungsschicht verfügt über folgende Dienstelemente:

  • S-CONNECT, S-RELEASE (Abbau ohne Datenverlust durch ein Quittungsverfahren), S-U-ABORT (abrupter Abbruch durch Benutzer), S-P-ABORT (abrupter Abbruch durch Betreiber).
  • S-DATA, S-EXPEDITED DATA, S-TYPED DATA (Ausserbanddaten, die kein Data-Token benötigen), S-CAPABILITY DATA (Sitzungsdatenänderungen; erlaubt das Senden von Daten ausserhalb einer Sitzung).
  • S-TOKEN GIVE (ein Token weitergeben), S-TOKEN PLEASE (um Token bitten), S-CONTROL GIVE (alle Token weitergeben).
  • S-SYNC-MAJOR (zu puffernder und zu bestätigender Rücksetzpunkt), S-RESYNCHRONIZE, S-SYNC-MAJOR (unbestätigter Vorsetzpunkt nach S-SYNC-MAJOR).
  • S-ACTIVITY START/END/DISCARD (Aufgabe)/INTERRUPT (Aussetzung)/RESUME (Wiederaufnahme nach INTERRUPT).
  • S-U-EXCEPTION REPORT (Benutzer-Ausnahmebehandlung), S-P-EXCEPTION REPORT (Betreiber-Ausnahmebehandlung).
  • S-UNITDATA (für verbindungsunabhängigen Dienst)

Die Sitzungsschicht verwaltet vier verschiedene Tokens:

  • Daten-Token (für Halbduplex-Modus nötig)
  • Abbau-Token (für verhandelnden Verbindungsabbau)
  • Neben-Sync-Token
  • Haupt-Sync+Activity-Token

Die SPDUs (Session Protocol Data Units) sind den Dienstelementen sehr ähnlich. Ausnahmen sind: FINISH für S-RELEASE, DATA-TRANSFER für S-DATA, GIVE-TOKENS-CONFIRM für S-CONTROL-GIVE und MAJOR/MINOR-SYNC-POINT für S-MAJOR/MINOR-SYNC.

4.5.2. Remote Procedure Calls

Das Konzept der RPC passt nicht gut zu OSI, da die OSI-Schichten Zeit kosten und von verbindungsorientierten Diensten ausgehen. Ausserdem geht OSI von symmetrischen Partnern aus, was aber z.B. beim Client-Server-Konzept der RPC nicht gegeben ist. Ein Halbduplex-Betrieb ist in der Sitzungsschicht simulierbar, aber wesentlich langsamer als ein Dienst auf Datagramm-Basis. Zuletzt arbeitet OSI mit Interrupts (z.B. indication) oder ungewohnten I/O-Operatoren (z.B. CONNECT). Besser wären hier transparente Prozeduraufrufe, die Funktionen von Server-Stub-Prozessen erledigen lassen, sich dabei aber äusserlich nicht von anderen Prozeduraufrufen unterscheiden - das ist das RPC-Konzept. Allerdings wird häufig auch auf die Transparenz durch ein vorangestelltes "remote" verzichtet, um den Compiler zu signalisieren, dass er mit diesem Aufruf speziell verfahren muss.

Problematisch sind RPCs aus folgenden Gründen:

  • Die Übergabe von Call-by-Reference-Argumenten gestaltet sich sehr schwierig. Eine Lösung ist hier das Copy/Restore-Verfahren, bei dem das Referenzierte Objekt im Server noch einmal generiert wird. Allerdings funktioniert dies nicht mit Objekt-Mehrfachaufrufen, da dabei jedes Mal wieder ein Objektduplikat geschaffen wird. Aus diesem Grund verbieten RPC häufig einfach alle (Call-by-Reference-)Argumente, was aber einmal mehr Transparenz zerstörend ist.
  • Sie müssen schnell arbeiten, daher sind langer Verbindungsaufbau und voller Schichtendurchlauf wenig effektiv für sie. I.d.R. existiert daher ein externes Datenbanksystem (DBS), welches dem Client-Stub sagt, wo er welche RPC-Server-Stubs finden kann. Hat der Client einmal die 32 bit-Kennung erhalten, so kann er sie für alle weiteren RPC weiterverwenden.
  • Der Server kann abstürzen, fährt wieder hoch und meldet sich beim DBS mit neuer (!) Adresse. Wie soll sich dann der Client-Stub verhalten? So lange seine RPCs senden, bis der Benutzer das Programm abbricht? Besser ist es, einen Timeout einzusetzen - tritt er ein, kann eine Exception ausgelöst werden (Höchstens-einmal-Senden-Semantik) oder er kann ein Duplikat senden (Mindestens-einmal-erfolgreich-Senden-Semantik), wozu allerdings Transaktionsnummern zur Duplikate-Unterscheidung nötig sind. Bei letzter Semantik ist darauf zu achten, dass nicht alle Prozesse idempotent sind, d.h. beliebig oft ohne Seiteneffekte ausgeführt werden können.
  • Die Behandlung von Waisen muss durchgeführt werden, d.h. von Server-Stubs, deren Client-Stubs abgestürzt sind. Solche Waisen machen nämlich Ärger, indem sie Dateien blockieren, CPU-Zeit verschwenden und neu hochgefahrene Client-Stubs mit ihren Ergebnissen überfallen. Daher ist es sinnvoll, sie einfach loszuwerden. Die ist möglich durch (a) Ausrottung: Der Client protokolliert alle Aufrufe und killt nach dem Hochfahren alle alten Server-Stubs, (b) Verfallszeit der Server-Stubs, (c) Wiedergeburt: Hierbei werden alle Server-Stubs gekillt und eine neue Epoche gefahren (Holzhammermethode, nur nötig, wenn (a) nicht möglich sein sollte) und (d) sanfte Wiedergeburt, wo Server-Stubs sich nur dann selbst killen, wenn sie ihren Client-Stub nicht mehr finden können. Problematisch bleibt bei diesen Methoden aber nach wie vor, wie die Server-Stubs zu killen sind, denn einige blockieren vielleicht danach immer noch Dateien oder haben belegte Warteschlangen und führen dadurch zu Deadlocks.

4.6. Darstellungsschicht

Die Darstellungsschicht (Presentation Layer) von 1984 umfasst die Normen für den Darstellungsdienst, dem Darstellungsprotokoll, der ASN.1-Sprache und der Basic Encoding Rules. Es wird damit ein gemeinsames Diskurs-Universum zwischen zwei Partnern geschaffen, die über Schlüssel, Entities und Relationships als konzeptionelles Schema beschrieben werden. Die Partner müssen dazu klären, was sie wie austauschen wollen. Eine globale Repräsentation ist vorzuziehen, damit nicht jeder ein anderes konzeptionelles Schema verwendet, denn dies würde sehr viele Konvertierungsregeln beanspruchen, auch wenn ein Konvertierungsschritt eingespart würde (lokal 1 nach lokal 2, anstatt lokal 1 nach global nach lokal 2). Die ISO räumt aber auch Ausnahmen ein, sodass zwei gleichartige PCs direkt miteinander kommunizieren können.

4.6.1. Dienste an die Anwendungsschicht

Die Dienstelemente der Darstellungsschicht sind praktisch identisch mit denen der Sitzungsschicht, bis auf P-ALTERNATE KONTEXT, mit dessen Hilfe man den Kontext einer Verbindung, d.h. den Datenstruktursatz, ändern kann. Dies wird z.B. bei FTAM eingesetzt, bei dem jedes Dokument einen anderen Kontext zugewiesen bekommt. P-ALTERNATE KONTEXT wird auf die Ausserband-PDU S-TYPED-DATA abgebildet, alle anderen Dienstprimitive werden 1:1 durchgereicht.

Am Protokoll ist bemerkenswert, dass es keine Verbindungsabbau-PDU gibt (ausser abnormale). Die Verbindung bricht also nach einem Timeout ab (?). Wenn die Anwendungsschicht einen Darstellungsdienst aufruft, sendet sie u.a. folgenden besonderen PDUs: CPA/R (Connect Presentation Accept/Reject), ARU/P (Normal Release of User/Provider), TTD (Transfer Typed Data), TCC (Transfer Capability Confirm), ALA (Alternate Context ACK) und RSA (Resynchronize ACK).

Eine weitere Besonderheit ist, dass einige PPDU-Parameter (Presentation Protocol Data Units) wie z.B. die P-context-list auf das SPDU-Benutzerdatenfeld und andere PPDU-Parameter wie z.B. die P-QOS auf das SPDU-Parameterfeld abgebildet werden. Diese gemischten PDUs tauchen hier zum ersten Mal im OSI-Modell auf und widersprechen eigentlich der reinen OSI-Lehre, die die einzelnen Schichten streng getrennt sehen will.

Wird ein P-CONNECT.request abgesendet, wird dabei implizit auch eine Sitzungsverbindung aufgebaut. Dazu müssen auch die Session-Parameter wie QOS als Argument übergeben werden, genauso wie die Bezeichnungen für die abstrakte Syntax, die Transfersyntax und die gewünschte Funktionseinheit. Als Antwort führt P-CONNECT.response das RESULT-Feld mit, das angibt, ob er die Verbindung akzeptiert.

4.6.2. Konvertierung

Die Darstellungsschicht will im Gegensatz zu den anderen Schichten keine Binärverbindung, sondern eine Semantik-Übertragung erreichen. In offenen Rechnernetzen kommunizieren verschieden Rechner miteinander, was erst durch Konvertierung der Daten möglich wird, das sonst ASCII-Zeichen von EBCDIC-Rechnern nicht verstanden wird. Probleme machen auch die Datenformate: Little Endian (0=rechts) bzw. Big Endian (0=links) oder Einer-Komplement bzw. Zweier-Komplement. Aus diesem Grund müssen die Nachrichten der Anwendungsschicht erst in eine Transfersyntax gebracht werden.

ASN.1-Notation: Diese abstrakte Sprache (eigentlich Thema der Schicht 7) hilft, um Daten nach Datentypen strukturiert, also in der Transfersyntax befindlich, zu übertragen. Ihre Bausteine/Konstruktortypen sind:

  • SEQUENCE: geordnete Liste mit verschiedenen Typen
  • SEQUENCE OF: geordnete Liste mit nur einem Typ
  • SET: reihenfolgeunabhängige Liste mit verschiedenen Typen
  • SET OF: reihenfolgeunabhängige Liste mit nur einem Typ
  • CHOICE: varianter Record: Instanz kann verschiedenen Typs sein

In die Listen können zur besseren Lesbarkeit vor die Basistypen klein geschriebene Text-Labels ohne abschliessendem Komma eingefügt werden. Über die hinter den Basistypen stehenden Schlüsselwörter DEFAULT und OPTIONAL können direkt Wertzuweisungen erfolgen und die Übersendung dieses Typs kann dem Sender überlassen bleiben, d.h. er muss ihn nicht senden, wenn er nicht will.

Als Dienstelemente/Basistypen stehen in ASN.1 zur Verfügung: INTEGER (beliebig lang), REAL (Mantisse-Basis-Exponent-Tripel), BOOLEAN, BIT STRING, OCTET STRING (Verfeinerung in Printable oder Visible Strings möglich), ANY (Vereinigung aller Typen), NULL, ENUMERATED (Aufzählungstyp) und OBJECT IDENTIFIER (z.B. {ISO Standard 8571}).

Die sogenannten Tags (gekennzeichnet durch []) werden eingesetzt, um der Darstellungsschicht den Datentyp der folgenden Sendung anzugeben. Für gewöhnlich genügt dies einmal zu Beginn der Übertragung. Damit das Tag nicht jedes Mal wieder übertragen wird, fügt man ihm ein IMPLICIT an. Bei ANY/CHOICE darf kein IMPLICIT angewendet werden, denn hier muss das Tag jeweils den Datentyp angeben. Man kann sich für eigene Datentypen auch eigene Tags definieren (über APPLICATION oder besser noch PRIVATE). Standardtags werden durch das Schlüsselwort UNIVERSAL optional gekennzeichnet, dem eine Nummer folgt (z.B. 1 für BOOLEAN oder 26 für das genormte Uhrzeitformat). Ein Beispiel:

Dinosaurier::=[PRIVATE 3] IMPLICIT SEQUENCE {
  Name [0] IMPLICIT OCTET STRING, --12 Characters
  Länge [1] IMPLICIT INTEGER
}

Die Transfersyntax (die Daten, die zwischen den Peer-Entities der Schicht 6 übertragen wird) unterscheidet sich von der Abstrakten Sprachfassung in ASN.1 dadurch, dass sie die Werte in Bit-Feldern des folgenden Formats darstellt:

KENNUNG (Typ oder Tag) LÄNGE des Datenfeldes DATENFELD ENDE-FLAG (optional)

Leider wird beim KENNUNG-Feld bitgenau vorgegangen, d.h. um den Feldtyp zu erkennen sind Bit-Operationen wie z.B. SHIFT nötig, was entsprechend viel Rechnerzeit verschlingt. Die bits 7 und 8 geben eine der vier Tag-Klassen an, die bits 1 bis 5 die Tag-Nummer.

Das LÄNGE-Feld wird fast immer angegeben. Es kann von kurzer Form sein (1.bit=0, 7 bit-Länge) oder von langer Form (1.bit=1, 7-bit-x, x-Byte-Länge). Ist die Länge nicht verfügbar, z.B. bei zusammengesetzten Datentypen, wird angegeben: 1.Byte=0.

Die Transfersyntax erhält man aus der abstrakten Syntax, wenn man auf sie die Encoding Rules anwendet. Bisher existieren nur die Basic Encoding Rules (BER) für ASN.1.

Der Darstellungskontext (Presentation Syntax) ist die Kombination aus gewählter Abstrakter Syntax und gewählter Transfersyntax. Er wird während der Verbindungsaufbauphase ausgehandelt. Eine Codierung/Decodierung-Einheit in Schicht 6 muss die abstrakte Syntax, die Transfersyntax und die jeweils lokale Präsentation kennen. Zudem muss sie während der Laufzeit neben den eigentlichen Daten, die hier erstmals im OSI-Referenzmodell direkt angefasst werden, auch noch das Strukturwissen verarbeiten können, was nicht trivial ist.

Zwei Ansätze existieren, wie der Codierer/Decodierer agiert:

  1. Interpretativer Ansatz: Der Codierer durchläuft die lokale Präsentation und codiert alle lokalen Typen sofort in die globale Präsentation. Das geht zwar langsam, ist aber flexibel und zum Testen ideal.
  2. Kompilierender Ansatz: Der Codierer sucht erst alle Strukturen aus der lokalen Präsentation heraus und fängt erst dann mit dem Codieren an. Das geht schnell, ist aber zum Austesten weniger geeignet. Bisher verstehen die Compiler-Codierer in erster Linie ASN.1-Spezifikationen, die sie mittels der wenig effizienten BER in die Transfersyntax codieren.

Die Funktionseinheit für die Verbindungsverwaltung ist der Presentation-Kernel. Für das Hinzufügen/Löschen von Kontexten ist das Context Management zuständig. Und die Kontext-Restauration erfolgt über die Context Restauration-Funktionseinheit.

4.6.3. Komprimierung

Daten zu übertragen kann teuer werden. Daher lohnt es sich, sie nach bestimmten Verfahren zu komprimieren. Alle diese Verfahren berücksichtigen eine der folgenden Strategien:

  • Endlichkeit einer Menge: Datenfelder können durch End-Flags variabel klein gehalten werden.
  • Häufigkeitsverteilung: Bestimmte Symbole kommen oft häufiger vor als andere. Es kann daher sinnvoll sein, den häufigsten Symbolen kurze Bit-Ketten zu zu weisen, und selten Symbolen die übrigen Längeren. Eine solche Huffman-Codierung lässt sich binär z.B. folgendermassen erreichen:
    1. Häufigkeit von A, B, C, D feststellen: .1, .2, .4, .3
    2. Jeweils die zwei seltensten Knoten zusammenfassen zu neuem Knoten:
         A-(.3)-B => D-(.6)-(.3) => C-(1.0)-(.6) => Binärbaum fertig
      
    3. Pfad bis Zeichen abgehen: links=1, rechts=0 (oder umgekehrt) A=111, B=110, D=10, C=0
    4. Kontext beachten: Bei Bildern weiss man, dass die Bilddaten vorrangig aus Nullen und zum anderen aus Einsen bestehen. Daher kann man viel Platz sparen, wenn man Lauflängencodierung betreibt, indem man nicht alle Nullen übertragt, sondern nur deren Anzahl, und die Eins danach ganz weg lässt. Ein Beispiel für 3-Bit-Symbole:
      000 1 00000 1 000000000000 1  1 001
      3     5       12                2
      011   101     111 101      000  010  ==> wesentlich kürzer
      

4.6.4. Kryptographie

Methoden zur Verschlüsselung von Daten sind:

  • monoalphabetische Substitution: z.B. Cäsar-Code (a zu d, ...)
  • polyalphabetische Substitution: Text-Wort-Addition
  • Codes: Klartext kürzer als codierter Text
  • Transpositionscodes: die Buchstabenfolge wird umgestellt
  • öffentliche Schlüssel

4.7. Die Anwendungsschicht

Eigentlich existiert nicht nur eine Schicht 7, sondern so viele, wie es Schicht-7-Applikationen gibt. Alles, was in die unteren Schichten nicht hineingequetscht werden konnte, bleibt der Anwendungsschicht überlassen. Ein Anwender kann nun sagen: mein Programm soll das und das können, also nehme ich die Schicht 7-Dienste CCR, ACSE und ROSE und klebe sie zusammen. Doch wie geschieht dieses zusammenkleben?

4.7.1. Application Layer Structure

Application Layer Structure (ALS) ist ein konzeptionelles Modell der Anwendungsschicht, dass keine Protokolle und Dienste definiert, sondern nur die Terminologie und die Architektur der Schicht 7 wiedergibt. Hier gilt: Jedem Programm sind eine oder mehrere OSI-Anwendungsentitäten zugeordnet, jede Entität ist aber nur genau einem Programm zugeordnet. So kann z.B. ein Händlerprozess dreimal über das ACSE-Dienstelement verfügen, um darüber die Kommunikation mit dem ACSEs von Bank, Hersteller und Kunde betreiben zu können.

Kommunizieren zwei oder mehrere Partner in einer gemeinsamen Assoziation, dann werden die verschiedenen Dienstelemente, z.B. ACSE und ROSE, pro Anwender über die SACF (Single Association Control Function) verwaltet, d.h. miteinander verklebt. Hält dagegen ein Anwender mehrere Assoziationen gleichzeitig aufrecht, sind bei ihm also mehre SACF-Instanzen aktiviert, so muss er diese mittels der MACF (Multiple ACF) verwalten. Z.B. kann dadurch ein Client gleichzeitig auf zwei verschiedene Server zugreifen und deren Daten miteinander kombinieren.

Der Anwendungskontext gibt Auskunft darüber, wie die einzelnen Dienstelemente der Anwender in einer Anwendung kooperieren können. Dies betrifft insbesondere das Zusammenspiel von SACFs und MACFs.

4.7.2. Anwendungsdienstelemente (Application Service Elements)

Die ASEs lassen sich unterscheiden in die allgemeinen Anwendungsdienstelemente ACSE, CCR, ROSE, RTSE und TPSE, und in die spezifischen Anwendungsdienstelemente FTAM, JTM, VTP, MOTIS/X.400, RDA, Directory und EDI/EDIFACT (Electronic Data Interchange/Electronic Data Interchange For Administration). Sie alle kommunizieren über PSAPs (Presentation Service Access Points) mit der Darstellungsschicht. Wir wollen sie uns im Folgenden einmal näher betrachten.

  1. ACSE (Association Control Service Element): Dieser OSI-Dienst dient der Steuerung von Assoziationen. Seine Dienstelemente stimmen mit der der Darstellungsschicht überein. Warum gibt es dann überhaupt ACSE? Es ist zwar richtig, dass die Darstellungsschicht alles kann, was ACSE kann, jedoch ist es aus Symmetrie-Gründen richtig, auch in der Anwendungsschicht dem Benutzer Dienste zur Verfügung zu stellen. Zudem erleichtert dies auch die Erweiterbarkeit des Dienstes, z.B. wenn mit dem Verbindungsaufbau auch gleichzeitig eine Authentifizierung durchgeführt werden soll.

    Die Dienstelemente im Einzelnen: A-ASSOCIATE (Assoziationsaufbau), A-RELEASE ohne Informationsverlust, A-ABORT durch den Anwender und A-P-ABORT durch den Dienstverwalter. ACSE benötigt als Minimum die Benutzung der Kernel-Funktionseinheit der Darstellungsschicht. Es sind die Parameter des Applikation-, Presentation- und des Session-Layers anzugeben. Der result-Parameter erhält als Ergebnis accepted oder rejected zurück.

  2. ROSE (Remote Operation Service Element): Remote Operationen können mithilfe von ROSE in zwei Modi realisiert werden: synchrone oder asynchrone, wobei bei letzteren der Prozess nicht auf das Ergebnis des RO-Aufrufs warten muss. Es kann auch entschieden werden, ob nur Fehler, nur Ergebnisse, beides zusammen oder keines von beiden zurückgeliefert werden soll. Damit ergeben sich die fünf Operationsklassen:
    1. Klasse 1: synchron, Result und Error => 99% aller Fälle!
    2. Klasse 2: asynchron, Result und Error
    3. Klasse 3: asynchron, nur Error
    4. Klasse 4: asynchron, nur Result
    5. Klasse 5: asynchron, ohne Error und Result

    Da ROs (Remote Operations) für alle möglichen Aufrufe funktionieren sollen, werden sie über die folgenden ASN.1-Makros spezifiziert, die direkt von den Anwendungsprogrammen eingesetzt werden: BIND (wird abgebildet auf A-ASSOCIATE), UNBIND (abgebildet auf A-RELEASE), OPERATION und ERROR. Aus diesem Grund muss der Presentation Layer nicht nur die abstrakte Syntax von ACSE codieren können, sondern auch die von ROSE - üblicherweise geschieht dies in verschiedenen Darstellungskontexten.

    Als Dienstelemente (alle ohne CONFIRMATION) kommen infrage: RO-INVOKE (Verbindungsaufbau), RO-RESULT (positive Antwort), RO-ERROR (negative Antwort), RO-REJECT-U (benutzerinitiierte Zurückweisung, z.B. wenn die RO nicht existiert) und RO-REJECT-P (erzeugerinitiierte Zurückweisung, z.B. wenn die Presentation-Verbindung zusammengebrochen ist). Will man besonders zuverlässige ROs erreichen, dann wird zu ROSE auch noch RTSE zugeschaltet. ACSE dagegen wird in jedem Fall im Anwendungskontext benötigt.

  3. TPSE (Transaction Procession Service Element): Transaktionen sind Alles-oder-Nichts-Aktionen (aus diesem Grund existierte früher z.B. die ENTER-Taste, die die Terminal-Daten erst versandte, als ihre Editierung abgeschlossen war). V.a. bei Parallelrechner muss man aufpassen, da dort selbst Assemblerbefehle nicht sicher atomar sind. Um die Sicherheit der Transaktionen zu garantieren, sind Recovery-Strategien nötig, die auch nach einem Systemcrash die übersendeten Daten rekonstruieren können (UNDO- und REDO-Techniken). Ebenso ist eine Concurrency Control nötig, um z.B. "Lost Updates" (Transaktion 2 überschreibt die Transaktion 1 im gleichen Moment wieder) und "Inconsistent Analysis" (jemand liest etwas, was im selben Moment überschrieben wird) zu verhindern. Durch Sperren lässt sich Serialisierbarkeit von Transaktionen garantieren.

    Über TPSE lassen sich verteilte Transaktionen in einem Transaktionsbaum verwalten, wobei das (hierarchische) 2-Phasen-Protokoll automatisch mit abgewickelt wird. Wenn alle Transaktionen READ-ONLY sind, dann entfällt die Phase 2. Der mögliche Dialogbaum umfasst (und übertrifft) alle Stationen, die im Transaktionsbaum enthalten sind. Alle Stationen, die die Koordinationsstufe "Commitment" innehaben, gehören dem Transaktionsbaum an , d.h. sie werden vom TPSE verwaltet. Alle anderen Stationen des Dialogbaums werden durch die Anwendung selbst koordiniert.

    Es gilt: Transaktionsdauer <= Dialogdauer <= Assoziationsdauer. Wichtig ist aber, dass eine TP-Dialogverbindung einen ACSE-Verbindungszusammenbruch überleben kann, wenn danach sofort eine neue ACSE-Verbindung aufgebaut wird (d.h. Dialogdauer > Assoziationsdauer)!

  4. CCR-Dienst (Commitment, Concurrence, and Recovery): Dieser OSI-Dienst verhilft dem Anwender zu Dienstelementen, die ihm atomare Aktionen ermöglichen, also absturzsichere Transaktionen, die entweder gar nicht oder vollständig ausgeführt werden. Dabei wird i.d.R. das folgende Muster eines 2-Phase-Commit-Protokolls (das auch in hierarchischer Weise realisiert sein kann, d.h. eine Transaktion erwartet von einer anderen Station eine Transaktion, deren COMMIT erst erreicht sein muss, bevor sie selbst mit COMMIT antworten kann) eingesetzt:
    Master (z.B. Kunde):
    Begin atomic Action;
    Send Request 1; ... Send Request n;
    Send "Prepare to Commit"-Message;
    
    Slave (z.B. Bank):
    if Action possible then begin
      Lock Data;
      Save Requests on sure disk (z.B. gespiegelt);
      Send "OK"-Message;
    end
    else Send "Failure"-Message;
    
    Master:
    If all Slaves send "Commit"-Message
      then Send "Commit"-Message;
      else Send "Rollback"-Message;
    Wait for "ACK"-Messages;
    
    Slave:
    If Master send "Commit"-Message then begin
      Do Work;
      Unlock Data;
    end;
    Send "ACK"-Message;
    

    Die Dienstelemente für den Master sind: C-BEGIN, C-PREPARE, C-COMMIT, C-ROLLBACK und C-RESTART.

    Die Dienstelemente für die Slaves sind: C-READY, C-REFUSE (Slave nicht bereit) und C-RESTART.

  5. FTAM (File Transfer, Access and Management): Dieser Dienst dient dem Dateitransfer (ganze Dateien bearbeiten) und dem Dateifernzugriff (Dateiteile bearbeiten). Er läuft normalerweise als Ewigschleifen-Serverprozess auf einem Datei-Server und wird v.a. bei der Kommunikation mit Diskless-Workstations eingesetzt. Im Prinzip ermöglicht FTAM einen virtuellen Dateien-Speicher, der eine genormte Schnittstelle bietet und die Details des Zugriffs vor dem Anwender verbirgt.

    Operationen die für ganze Dateien angeboten werden: Create File, Delete File, Select File (für Attribute-Management), Deselect File, Open File, Close File, Change Attributes und Read Attributes.

    Operationen die für Dateiteile (FADUs) angeboten werden: Locate, Read, Insert, Replace, Extend (Anhängen von Sätzen) und Erase.

    Ähnlich wie beim Session Layer lassen sich je nach Funktionsumfang verschiedene Dienstklassen von FTAM erzeugen - und zwar die Dateitransfer-, die Dateizugriff-, die Dateimanagement-, die Dateitransfer- und Management- und die unbeschränkte Klasse.

    FTAM beherrscht auch Grouping-Dienstaufrufe der folgenden Art:

    begin group;
      select existing file;
      open for read;
    end group;
    

    Die Korrigierung des Dateidienstes mittels Recovery kann wahlweise vom User selbst oder von FTAM übernommen werden. Die Assoziationen werden dazu über ACSE verwaltet und die Session-Schicht übernimmt die dialogorientierte Token-Steuerung sowie das Check-Pointing.

    Zu beachten ist, dass der konkurrierende Dateizugriff selbst zu steuern ist, z.B. durch Shared Locks oder Exclusive Locks, die aber Gefahren durch offene Dateien oder Deadlocks bei abgestürzten Servern bergen. Besser ist es hier, CCR für atomare Aktionen einzusetzen.

    Oft sind aus Geschwindigkeitsgründen und Sicherheitsgründen im Rechnernetz gleich mehrere Dateiserver verankert, auf denen Duplikate von Dateien gehalten werden. Änderungen an einer Datei sind dabei üblicherweise nur über einen Master-Datei-Server an einer Primär-Datei möglich.

    Unterscheiden werden zwei Datei-Serverarten:

    1. Zustandslose, d.h. verbindungsunabhängige Dateiserver, bei denen vor den Operationen die Datei nicht geöffnet werden muss, dafür den Sendungen aber alle Angaben mitzugeben sind. Z.B. ist NFS ein solcher robuster Datei-Server.
    2. Verbindungsorientierte Dateiserver, die interne Tabellen über die Zeiger-Position der geöffneten Dateien verwalten. OSI setzt auf diesen Typ auf. FTAM arbeitet dazu mit verschachtelten Regimes, die jeweils bestimmte Operationen erlauben. Die zugehörigen FADUs zu den Regimes sind:
      • Assoziationsregime: F-Initialize bis F-TERMINATE/ABORT
      • Dateiauswahlregime: F-SELECT/CREATE bis F-DESELECT/DELETE
      • Dateiöffnungsregime: F-OPEN bis F-CLOSE
      • Datenübertragungsregime: F-READ/WRITE bis F-TRANSFER-END

    Bleibt zu sagen, dass der FTAM-Dienst so kompliziert ist, weil er jede noch so kleine Ausnahme berücksichtigt, dass dieser er wohl auf keinem System vollständig implementiert werden wird.

  6. MOTIS (Message Oriented Text Interchange System): von der ISO übernommen CCITT-Norm X.400 für ein Message Handling System (MHS), um elektronische Briefe - E-Mails - zu übersenden. Tatsächlich liegt der Datenanteil von E-Mails deutlich über den von IPC, wie man an ARPANET ersehen kann. Im Prinzip gleicht MOTIS einem Transferdienst von Dateien, allerdings sind Briefe strukturiert und bedürfen Informationen für das Netz und den Empfänger, also dem menschlichen Leser. MOTIS unterscheidet zwei Programmarten:
    1. User Agent (UA): Das sind die E-Mail-Programme, die auf der Anwenderebene arbeiten. Über sie können z.B. Briefe editiert und abgesendet werden. Die UAs können beliebig unzuverlässig sein, denn die Verwaltung der E-Mails obliegt alleine den Transfer-Agents. Die UAs kümmern sich nur darum, dass die User-Informationen als ASN.1-OCTETSTRING in einen Briefumschlag gepackt werden, den sie dann an die MTAs (Message Transfer Agents) über ROSE (!) weiterleiten. UAs können für elektronische und interpersonelle Nachrichten verwendet werden - abhängig davon, ob eine Inter-Personal-Message- oder Electronic-Data-Interchange-UA-Klasse vorliegt.
    2. Message Transfer Agent (MTA): Dies sind elektronische Schaltstellen auf speziellen Serverrechnern, die die Briefe anwendungsunabhängig store-and-forward hop-by-hop durch das Netz leiten und meistens einen Pufferbereich als Mailbox (Message Store) zur Verfügung stellen. Sie prüfen zudem das korrekte Format der eingehende Briefe, während ihr Inhalt sie nichts angeht.

    Ein MTA-Entity besteht aus folgenden Bausteinen:

    • Association Manager: verwaltet die Verbindungen, Kontakt zu RTS.
    • Message Dispatcher: um Speicherfunktion erweiterte Transportschicht.
    • Reliable Transfer Server (RTS): transferiert APDUs (Application Protocol Data Units) zuverlässig.

    Die Grundfunktionen des MHS sind:

    • Komposition: Nachrichtenerzeugung
    • Transfer: Nachrichtenübermittlung
    • Konvertierung: z.B. ASCII nach EBCDIC oder Terminal nach FAX/BTX.
    • Disposition: Nachrichtenverwerfung oder Nachrichtenzwischenspeicherung.
    • Formatierung: Text mit Formatierung übertragbar.

    Besonders die Formatierung stellt hohe Anforderungen an das MHS, sind doch bei verschiedenen Rechnern z.B. die Textcodes oft nicht identisch, das amerikanische Papierformat stimmt nicht mit DIN A4 überein, BTX kann nur 40 Zeichen in der Zeile darstellen. An einer Dokumenten-Architektur wird noch gebaut. Quasi-Standards wie MS-WORD oder UNIX-TECH können aber bereits verwendet werden.

    Drei Protokolle finden beim MHS Verwendung:

    1. P-1: zwischen MTA und MTA zur Briefvermittlung über OSI-TP-1
    2. P-2: zwischen zwei IPM-UAs (Interpersonal Messaging) für elektronische Post.
    3. P-3: zwischen UAs und MTAs zur Briefauslieferung mittels ROSE.

    Anders als bei ARPANET findet bei OSI keine hierarchisch-domänengesteuerte Adressierung statt, sondern die sogenannte O/R-Adressierung. Diese ermöglicht es dem MTA, Adressen im Netzbereich über bestimmte Attribute zu finden. So kann z.B. angegeben werden: L=de, ADMD=www, FIR=IBM, ABT=V&V, NAME=Konstantin. Alternativ existiert auch noch eine terminalorientierte Form, die aber kaum benutzt wird. Da logische O/R-Namen über einen globalen Directory-Dienst auf die (physischen) O/R-Adressen abgebildet werden, können die Ziele ohne Namensänderung migrieren.

    Aufgrund des Alters von MOTIS wird zur Datenübertragung nicht das FTAM-Protokoll genutzt, sondern der zuverlässige Übertragungsdienst RTS. Dieser bietet folgende Dienstelemente an: RT-OPEN, RT-CLOSE, RT-U-ABORT, RT-P-ABORT, RT-TRANSFER, RT-TURN-PLEASE (Token anfordern) und RT-TURN-GIVE.

    Einen Unterschied gibt es zwischen X.400 und MOTIS: MOTIS sieht im Gegensatz zu X.400 vor, (E-Mail-)Daten auch über die Landesgrenzen durch private Netzbetreiber (Private Management Domain, PRMD) abwickeln zu lassen, wogegen sich die Post (Administration Management Domain, ADMD) aber wehrt. In Zukunft wird wohl das Postmonopol dahin gehend eingeschränkt werden, dass sie zwar als einzige Leitungen verlegen und den Telefondienst anbieten darf, dass aber die Leitungsverwaltung und die Datendienste auch in privater Hand liegen können. Folgende Systeme sind bereits möglich:

    • Post bietet Benutzern mit Terminals einen User Agent-Anschluss an.
    • privater UA geht an einen öffentlichen MTA.
    • privater UA+MTA gehen an einen öffentlichen MTA.

    Alles in allem kann MOTIS als sehr gut durchdachtes Modell angesehen werden, was man schon daran erkennt, dass es trotz seines Alters - es entstand 1984 - ohne grosse Änderungen aktueller denn je ist. MOTIS ist auch der einzige Standard für E-Mails, der weltweit Gültigkeit besitzt. Auch die Multicast-Funktion beweist Klasse: dadurch, dass das Kopieren der Briefe möglichst spät erfolgt, wird Bandbreite gespart. Nachteilig an MOTIS ist seine lange Implementierungsdauer, daher dominiert derzeit auch noch UNIX-MAIL an den Universitäten, obwohl dessen Funktionalität viel kleiner ist. Wegen der optimalen Funktionalität müssen auch Standardmengen gebildet werden, damit verschiedene OSI-MOTIS kommunizieren können. Prof. Effelsberg war z.B. an der ENC X.400-Prototyp-Umgebung beteiligt.

    Seit 1985 können auch grosse IBM Mainframes X.400 nutzen, indem sie sich über ein Gateway Zugang zum X.25-Netz Datex-P verschaffen. Das Gateway muss dazu alle 7 Schichten enthalten. Die UAs werden mit einer PROFS-Schicht überlagert, die den Anwender die IBM-vertraute Umgebung anbietet.

  7. RDA (Remote Database Access): Dieser Dienst dient dem Fernzugriff auf Datenbanken mithilfe von interaktiven Datenstationen. Das zugrunde liegende Netz kann ein Terminalnetz, ein Rechnernetz oder ein verteiltes DBS sein. Ersteres benötigt ein Transaktionsmonitor und evtl. PAD für eine X.25-Kommunikation. In UNIX können für Terminal-Zugriffe auf DBS die X.11-Protokolle von X-WINDOW verwendet werden. In Rechnernetzen wird ein DBS-Zugriff i.d.R. nach dem Client/Server-Konzept durchgeführt, wobei der Server den Clients ein Application Programming Interface (API) anbietet. Die Transaktionsverwaltung kann hierbei völlig unabhängig vom DBS abgewickelt werden - es ist also egal, ob es sich um ein hierarchisches, relationales oder netzartiges DBS handelt. Gegenüber Terminal-Netzen arbeiten Rechnernetze dezentral und verwenden symmetrische Protokolle für Peer-to-Peer-Links. Verteilte DBS machen es nötig, dass verteilte DBMS ständig miteinander kommunizieren. Ausgereifte Optimizer für SQL-Abfragen sind hier besonders wichtig.

    RDA basiert auf Rechnernetzen und kann mit jedem Rechner, jedem Betriebssystem und jedem DBMS arbeiten. Am C/S-Konzept wird festgehalten (obwohl OSI sonst eigentlich von gleichberechtigten Partnern ausgeht). Ein Client muss mehre RDA-Links zu verschiedenen Servern aufrecht erhalten können. Ein SQL-Protokoll wurde integriert und in ASN.1 beschrieben. Folgende Dienstelemente stehen u.a. zur Verfügung: R-Begin/End-Dialog, R-Open/Close, R-Executable (führe SQL-DB-Befehl aus), R-Begin-Transaction, R-Commit, R-Rollback, R-Cancel (streiche Operationen) und R-Status.

    Der Anwendungskontext benötigt neben RDA und SACF (die z.B. kontrolliert, dass ACSE vor ROSE erfolgt) ACSE zur Dialogverwaltung, sowie ROSE, CCR und TPSE zur Transaktionsverwaltung. Der Client benötigt zusätzlich noch die MACF, da mehrere SACFs für mehrere DBMS verwaltet werden müssen. Insbesondere CCR kann Probleme aufwerfen, da nicht alle DBMS zu einem 2-Phasen-Protokoll fähig sind.

    In Zukunft wird RDA verteilungstransparenter werden, d.h., die Clients müssen dann nicht mehr wissen, auf welchem Server sich welche Daten/Relationen befinden - alle Query-Abfragen sammeln sich dann selbst alle Informationen zusammen, was dem Client fast DBMS-Qualitäten gibt (nur die Speicherkomponente fehlt noch). Eine Gefahr liegt derzeit auch noch darin, dass das Commit-Protokoll von unsicheren Benutzer-Clients initiiert wird - das birgt zu viele Risiken für die Unternehmen (z.B. wenn User abstürzen, ist die DB blockiert), weshalb sie RDA auch ablehnend gegenüberstehen. Der Commit-Koordinator muss daher irgendwann einmal auf die sicheren Hosts verlagert werden.

  8. VTS (Virtual Terminal Service): Herkömmliche Terminals benutzen herstellerabhängige Escape-Sequenzen, obwohl es u.a. von ANSI Normen dazu gibt. Das macht z.B. die Gestaltung eines allgemeinen Ganzseiten-Editors im Rechnernetz sehr schwierig. Bisher wurden deshalb jegliche Terminal-Protokolle von nur einem Hersteller bezogen, was aber in offenen Netzen unmöglich ist. Dort benötigt man virtuelle Terminals, die genormte Schnittstellen bieten und sich den jeweiligen Erfordernissen anpassen können.

    Einen Quasi-Standard bietet z.B. der PAD-Paketierer/Depaketierer der Triple X-Norm von CCITT für X.25, bei dem bei der Erstverbindung abgeglichen wird, über welche Möglichkeiten ein Terminal verfügt/nicht verfügt oder wie sich das Protokoll in bestimmten Situation verhalten soll (z.B. Timeout-Länge oder die Füllzeichenmenge nach einem Wagenrücklauf). Die ursprünglich zeichenorientierte Terminal-Datenstrom wird durch PAD in X.25-Pakete gepackt.

    Doch OSI wollte nicht nur die Daten, sondern auch Formulareigenschaften für formularorientierte Terminals übertragen können. Diese werden nach dem VTS-Protokoll abgeglichen: Dienstelemente sind hier: VT-ASSOCIATE, VT-RELEASE, VT-U/P-ABORT, VT-SWITCH PROFILE (zur Profil-Angleichung), VT-END-NEG, VT-OFFER/ACCEPT/REJECT-NEG, VT-DATA, VT-DELIVER (Puffer leeren), VT-ACK-RECEIPT (DELIVER-ACK), VT-GIVE-TOKEN und VT-REQUEST-TOKEN.

  9. OSI-Verzeichnisdienst X.500: Dieser Dienst dient zum managen der OSI-Umgebung und ist neben dem TCP/IP-Verzeichnisdienst der am höchsten Ausgereifte, wenn auch die verteilten Operationen zu wünschen übrig lassen; die ISO versteht leider nichts von verteilten Betriebssystemen (VBS). Verzeichnisdienste werden nicht nur von Personen benötigt, sondern auch von (OSI-)Prozessen und Telekommunikationsdiensten wie z.B. X.400, Teletext usw. Bei der globalen Namensgebung ist mit kurzzeitigen Inkonsistenzen zu rechen - genauso wie bei Telefonbüchern, da die Aktualisierungsrate kleiner als die Abfragerate ist (ein globales Commitment zu einem Augenblick wäre zu aufwendig). Die Benutzbarkeit symbolischer Namen macht es menschlichen Benutzern leichter, ausserdem erlaubt das die Migration von Prozessen. Betrachten wir nun X.500 einmal unter verschiedenen Aspekten:
    • Funktionales Modell: Bei X.500 gibt es Directory User Agents, mittels denen der Benutzer mit dem Directory System Agents kommunizieren kann, die das verteilte, globale Verzeichnis als Dämonenprozesse transparent verwalten.
    • Organisatorisches Modell: Wer hat die Verantwortung/die Kompetenz zur Vergabe der symbolischen Namen in X.500? Es gibt öffentliche Directory Management Domains (DMD) und innerhalb von Organisationen die administrativen DMD (ADDMD) und privaten DMD PRDMD). Diese Thematik kümmert den Informatiker allerdings eher weniger.
    • Sicherungsmodell: X.500 stellt Authentifikationsdienste zur Verfügung, und zwar einmal eine einfache Autorisierung durch Passwörter uns zum anderen eine asymmetrische Verschlüsselung auf Public-Key-Basis.
    • Informationsmodell: Welche logische Struktur wird von den Verzeichnissen verwaltet? Das wäre zum einen die Directory Information Base (DIB), die die Verzeichniseinträge beinhaltet. Die Verzeichniseinträge enthalten jeweils Informationen über einzelne Objekte. Mehrere Objekte können auch in einer Objektklasse zusammengefasst sein, sofern sie bestimmte Eigenschaften/Attribute gemeinsam haben, die sie weiter vererben können. Die Objekte haben mehrwertige genormte Attribute, z.B. mehrere Autorennamen für eine Buchdatei, sind also nicht in der ersten Normalform. Das Schlüsselattribut muss ungleich NULL sein. Objekte können auch als Alias-Einträge existieren. Der Directory Information Tree (DIT) zeigt auf, wie die einzelnen Objektklassen miteinander in Relation stehen; dadurch wird das Auffinden von Einträgen durch eindeutiges Parsing und das verteilte Management erleichtert. Effelsberg bemängelt hier, dass bei "Yellow-Page"-Informationen, also inhaltsbezogenen Informationen, das Hierarchiekonzept sicher fehl am Platz ist (Ausnahmen sind aber über Alias-Namen erreichbar). Die möglichen Objektklassen (z.B. ORGANIZATION) und Attribute-Typen (z.B. USER PASSWORD) liegen in genormter ASN.1-Form vor.

    DUAs (Directory User Agents) verfügen über folgende Operationen:

    • Bind/Unbind
    • Read/Compare/Abandon (Abbruch)
    • List/Search
    • Add Entry/Remove Entry/Modify Entry (erst Löschen, dann ändern)

    Die DSAs (Directory System Agents) erreichen die verteilte Verarbeitung durch die Operationen:

    • Chained Read/Chained Compare
    • Chained List/Chained Search
    • Chained Add Entry/Chained Remove Entry/Chained Modify Entry

    Die verteilte Verarbeitung wird im einfachsten Fall dadurch erreicht, das ein DUA alle Query-Informationen vom lokalen (nicht unbedingt konsistenten) DSA bekommt. Weiss der lokale DSA zu wenig, kann er dem DUA die Adresse eines anderen DSA zurücksenden (Referenzmethode). Die Verkettungsmethode dagegen sieht vor, dass der DSA selbst einen anderen DSA befragt, um von ihm das nötige Wissen zurückzuerhalten. Als dritte Möglichkeit gibt es natürlich noch die Multicast-Methode, die aber das Netz stark belastet.

    Beispiel für eine Abfrage über X.500:

    read DN=(L=de, O=uni-mannheim, F=informatik, I=pi4, N=effelsberg)
    return Abteilung, Telefonnummer, Adresse

    X.500 verwendet zur Kooperation zwischen DUAs und DSAs das Directory Access Protocol (DAP) und zwischen DSAs und DSAs das Directory System Protocol (DSP). An Anwendungsdienstelementen benötigt es jeweils ACSE und ROSE.

  10. MISE (Management Information Service Elements): Das ist eine Sammlung von Protokollen, die weit über das hinausgeht, was X.500 zum OSI-Management anbietet. Dieses System ist noch nicht zu kaufen, und auch noch nicht so ausgereift wie bei SNA.
  11. Weitere Dienste sind: JTM (Job Transfer and Manipulation, um bestimmte Aufgaben von Mainframes regeln zulassen) und Videotext und BTX.

5. Spezifikationssprachen und Werkzeuge zur Erstellung von OSI-Software

Um Protokolle zu entwickeln, ist es hilfreich, eine formale Beschreibungstechnik (FDT) zur Verfügung zu haben, die eine Verifikation der Protokolle erlaubt und aus der sich direkt Computercode erzeugen lässt. Dazu benötigen die FDT eine formale Syntax (eindeutige Regeln) und eine formale Semantik (eindeutige Interpretation). Gute FDTs sind ausdrucksstark, so abstrakt, dass ein Compiler sie gerade noch verarbeiten kann, modular, d.h. die einzelnen Spezifikationen sind alleine testbar und anschliessend zusammensetzbar, und strukturierbar, sodass Module nicht länger als eine DIN A4-Seite sein müssen.

Solche FDTs existieren bereits; es sind dies:

  1. ESTELLE (ISO): FDT für höhere Schichten, die mit erweiterten endlichen Automaten operiert. Die Beschreibungen der Typ-Definitionen erfolgen in PASCAL-Notation. Sehen wir uns dazu einen X.25-CALL_REQUEST an, der zwischen Poststeckdose und DTE (Data Terminal Equipment, Datenendeinrichtung) ausgetauscht wird, und die Zustandsbeschreibung eines DTE-Knotens:
    CALL_REQUEST=RECORD
    header: Paket_header;                // woanders definiert
      calling_dte_address_length: INTEGER;
      called_dte_address_length: INTEGER;
      called_dte_address: BCD_STRING;     // woanders definiert
      ...
      user_data: ARRAY[1..16] OF OCTET;
    END;
    
    BODY X_25_dte_body FOR X_25_dte;
      state p1, ..., p7;
      VAR lcs: LC_status_type;           // woanders definiert
      ...
      INITIALIZE TO p1; BEGIN lcs:=free; ...; END;
      TRANS FROM p1 TO p2 WHEN nsap.n_connect_req PROVIDED lcs=free
      BEGIN ... OUTPUT packets.call_req(CR_PDU); ... END;
    END;
    
  2. SDL (Standard Description Language von der CCITT): FDT für niedrige Schichte (nicht LANs!), die mit erweiterten endlichen Automaten operiert, die im Unterschied zu Estelle grafisch als Flussdiagramme dargestellt werden.
  3. LOTOS (ISO): Eine komplizierte FDT, die mit Prozess-Algebra arbeitet.

Ein endlicher Automat ist ein Quintupel aus einer Menge von Zuständen, einer Menge von Eingabezeichen, einer Menge von Ausgabezeichen, Zustandsübergangsfunktionen und Ausgabefunktionen. Manchmal wird auch noch ein Startzustand hinzugefügt.

Anschaulich lässt sich ein Automat als Zustands-/Übergangsdiagramm darstellen, d.h. als Graph mit gerichteten Kanten (=Zustandsübergangs- und Ausgabefunktionen), die mit der auslösenden Eingabe und Ausgabe beschriftet werden. Die Knoten stellen die verschiedenen Zustände dar.

Eine andere Darstellungsform endlicher Automaten sind Tabellen, wobei auf der x-Achse die Zustände stehen, auf der y-Achse die Eingaben und in den Mittelfeldern die Folgezustände, die sich aus der Zustandsübergangsfunktion ergebene, und die Ausgaben, die sich durch die Ausgabefunktion ergeben.

Wenn bei zwei verschiedenen Automaten eine Eingabemenge die gleichen Ausgabenmengen erzeugt, dann sind die beiden Automaten äquivalent. Äquivalente Automaten können z.B. isomorphe Automaten sein, d.h. strukturell identische - sie müssen aber nicht isomorph sein. Es können auch bloss zwei Zustände innerhalb nur eines Automaten äquivalent sein. Ziel ist immer, den strukturell einfachsten äquivalenten Automaten zu finden, es sei denn dadurch geht zu viel Semantik verloren.

Automaten sind zusammenhängend, wenn es Eingabefolgen für jeden Zustand gibt, sodass er vom Startzustand aus erreichbar ist. Von einem minimalen Automat spricht man, wenn der Automat keine äquivalenten Zustände mehr enthält. Äquivalente minimale Automaten sind immer isomorph.

Da endliche Automaten rasch sehr gross werden können, können sie mittels protokollunrelevanter Variablen erweitert werden, damit deren Änderung keine neuen Zustände erfordert. Die Eingabe- und Ausgabezeichen werden mit Bedingungen belegt. Dadurch benötigt ein Sliding Window-Automat nicht für jede neue Sequenznummer einen neuen Zustand.

Wenden wir uns nun wieder der Protokoll-Entwicklungsumgebung zu. Normalerweise haben wir zuerst ein Problem vorliegen, dass mittels eines FDT-Editors angegangen wird. Als Ergebnis erhalten wir eine Spezifikation von Protokollen, z.B. in Estelle. Ein Code-Generator hilft uns nun, die Spezifikation zu testen, zu validieren, auf OSI-Norm-Konformität hin zu überprüfen, was natürlich eine prima Sache ist. Eine Konformitätsprüfung sollte genügen, denn komplette Tests oder Verifikationen sind unmöglich bzw. viel zu aufwendig. Mögliche Teststufen sind: BASIC Interconnection Tests, Capability Tests, Behavior Tests und Conformance Resolution Tests. U.U. sind sogar verteilte Testmethoden möglich, d.h., der Prüfer testet die SW direkt über das Netz. Aussagekräftige (aber die Reihenfolge der Bedingungen für Zustandsübergänge vernachlässigende) Testszenarien lassen sich z.B. mit der ASN.1-/pascalähnlichen TTC-Notation (Testing and Test Control) entwickeln, die für bestimmte Eingaben protokollkonforme Ausgaben hervorbringen müssen. Als Ergebnis erhält man jeweils: PASS, FAIL oder INCONCLUSIVE. Wenn wir und die Prüfer zufrieden sind, lassen wir den Code-Generator unser Werk implementieren, z.B. als C++-Quellcode, der nur noch von Super-Cracks verstanden werden muss.

Zu Beachten ist, dass das Betriebssystem des Rechners, auf dem die Spezifikation implementiert wird, all das beherrscht, was OSI-Protokolle verlangen, also z.B. Pufferverwaltung, Timer und Dateiverwaltungssysteme. Am idealsten wäre natürlich ein spezielles OSI-Betriebssystem, das auf dem lokalen BS aufsitzt.