Rechnernetze
Geschwurbel von Daniel Schwamm (02-04/1994)
Inhalt
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.
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.
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.
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.
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?
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.
Unterschieden werden beim ISO/OSI-Referenzmodell die folgenden sieben
Schichten-Normierungen:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
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.
Ü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:
-
Common Channel Signaling: Jeder gerade Rahmen
enthält ein Signal durch das Synchronisationsbit, das für alle
Kanäle gilt.
-
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.
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:
-
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.
-
Primär-Multiplex-Anschluss: 30 x 64 kbps für PCM-Daten und
1 x 64 kbps für die Ausser-Band-Signalisierung.
-
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.
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.
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.
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.
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.
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.
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)
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.
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:
-
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.
-
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.
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.
Die Sicherungsschicht muss dafür sorgen, dass eine schnelle Quelle eine
langsame Senke nicht mit Rahmen überschwemmen kann. Dazu sind
Rückmeldemechanismen nötig.
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.
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.
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)
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
Petrinetze verdeutlichen den Ablauf, oder
besser die möglichen Zustandsübergänge eines Protokolls durch
ein Token, welches durch das Petrinetz navigiert werden kann.
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.
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.
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).
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.
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.
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.
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).
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:
-
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.
-
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.
-
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.
-
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.
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.
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.
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:
- A-Subnet: Fehlerfrei, liefert keine N-RESETs zurück.
- B-Subnet: N-RESETs möglich.
- C-Subnet: Verlorene, duplizierte Pakete und N-RESETs möglich.
Jedes dieser Subnet verlangt nach verschiedenen Transportprotokollen (TP).
OSI unterscheidet hier fünf Kategorien:
- Für A-Subnets, also genügt ein einfaches Transportprotokoll.
- Für B-Subnets, das TP muss also N-RESETs abfangen können.
- Für A-Subnets, wo das TP Multiplexing erlaubt.
- Für B-Subnets, wo das TP Multiplexing erlaubt und N-RESETs abfängt.
- 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).
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:
-
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.
-
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.
-
Die Vermittlungsschicht von B baut eine virtuelle
Verbindung zwischen seinem NSAP und dem dem des Rechners A auf.
-
Rechner A erkennt den Verbindungswunsch von B und gibt ein
T-CONNECT.indication auf den TSAP 122 und die Transportverbindung kann
aufgebaut werden.
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.
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:
-
Der Sender schickt Empfänger DISCONNECT.request und
setzt einen Timer. Falls ein Time-out erfolgt, dann wiederholt der Sender die
Prozedur.
-
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.
-
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.
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.
Hier unterscheidet OSI zwei Möglichkeiten:
-
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.
-
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.
Diese Aufgabe muss von der Sitzungsschicht wahrgenommen werden und ist auch
dann nur möglich, wenn genügend diverse Statusinformationen aufbewahrt wurden.
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:
- Klasse A: 8 bit Wan-Adresse und 24 bit Host-Adresse.
- Klasse B: 16 bit WAN-Adresse und 16 bit Host-Adresse.
- Klasse C: 24 bit WAN-Adresse und 8 bit Host-Adresse.
- 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.
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.
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.
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.
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.
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:
-
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.
-
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.
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:
-
Häufigkeit von A, B, C, D feststellen: .1, .2, .4, .3
-
Jeweils die zwei seltensten Knoten zusammenfassen zu neuem Knoten:
A-(.3)-B => D-(.6)-(.3) => C-(1.0)-(.6) => Binärbaum fertig
-
Pfad bis Zeichen abgehen: links=1, rechts=0 (oder umgekehrt) A=111, B=110, D=10, C=0
-
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
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
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?
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.
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.
-
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.
-
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:
- Klasse 1: synchron, Result und Error => 99% aller Fälle!
- Klasse 2: asynchron, Result und Error
- Klasse 3: asynchron, nur Error
- Klasse 4: asynchron, nur Result
- 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.
-
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)!
-
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.
-
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:
-
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.
-
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.
-
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:
-
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.
-
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:
- P-1: zwischen MTA und MTA zur Briefvermittlung über OSI-TP-1
- P-2: zwischen zwei IPM-UAs (Interpersonal Messaging) für elektronische Post.
- 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.
-
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.
-
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.
-
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.
-
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.
-
Weitere Dienste sind: JTM (Job Transfer and Manipulation, um
bestimmte Aufgaben von Mainframes regeln zulassen) und Videotext und BTX.
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:
-
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;
-
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.
-
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.