Das OSI-Referenzmodell

Kommentieren Drucken
Teil 4 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Vom Draht bis zum Anwendungsprogramm ist es bei Rechnernetzen ein weiter Weg. Es sind viele unterschiedliche Funktionen nötig, die sinnvoll zusammenarbeiten müssen, und zwar in ALLEN Netzen. Seit über 30 Jahren hat sich dafür die Einteilung und Nomenklatur des sog. OSI-Referenzmodells der Internationalen Standardisierungsorganisation ISO bewährt. Jeder, der bei Netzen mitreden möchte, muss dieses Modell kennen, denn sonst fällt man schnell aus dem Zusammenhang. Noch wichtiger für die Praxis ist aber die sog. TCP/IP-Protokollfamilie.

Das Video zu diesem Kapitel ist: Das OSI-Referenzmodell, Dr. Jürgen Suppan

Für die meisten komplexen von Menschen konstruierten technischen oder architektonischen Gebilde gibt es einen Bauplan. Auch wenn man heute vielfach den Eindruck gewinnt, man müsse nur alles irgendwie zusammenbasteln, damit man ein Netzwerk erhält, steckt hinter all dem doch eine ausgefeilte Konstruktion, die sog. Netzwerkarchitektur. Natürlich haben sich in der Vergangenheit viele Netzwerkarchitekturen entwickelt, und einige Dinosaurier haben bis heute überlebt. Man muss herstellereigene Netzwerkarchitekturen und solche nach internationalen Standards unterscheiden. Die herstellereigenen oder proprietären Netzwerkarchitekturen verbinden natürlich zunächst nur Geräte eines Herstellers, und wenn man Pech hat, denkt kein anderer Hersteller im Traum daran, Hard- und Software nach der Spezifikation des anderen Herstellers zu bauen. Dies ist vor allem für große Anwender, die meist Geräte unterschiedlicher Hersteller betreiben und gerne wollen, dass diese auch untereinander kommunizieren können, völlig unbefriedigend.

So hat man schon früh nach Wegen gesucht, Vereinbarungen zu schaffen, die die Konstruktion von Protokollen und Schnittstellen ermöglichen, die von allen Herstellern genutzt werden können. Man spricht dann auch von Protokollen und Schnittstellen für die offene Kommunikation. Beim Telefonnetz funktioniert das schon von Anfang an. Es ist gleichgültig, von welchem Hersteller das Telefon kommt, was man gerade benutzt oder welcher Hersteller die örtliche Vermittlungsstelle geliefert hat: Man kann dennoch immer nach dem gleichen Verfahren überall hin telefonieren. Das ist ja auch der Zweck des Telefonnetzes. Die Rechnerhersteller haben die offene Kommunikation allerdings lange behindert – und tun dies oft heute noch, wo es eben geht – um Alleinstellungsmerkmale für ihre Geräte zu schaffen.

Man muss sich schon genau überlegen, wie man ein Kommunikationssystem aufbaut – und selbst wenn das System dann funktioniert, kann es passieren, dass sich die Beteiligten untereinander nicht verstehen.

Der Bauplan für ein Datenkommunikationsnetz umfasst also im Grunde genommen zwei Teile: Einen für die Übertragungstechnik und einen anderen für die richtige Interpretation der ausgetauschten Informationen.

Die Netzwerkarchitektur beschreibt vollständig den Weg von Daten zwischen zwei Anwendungen. Letztlich tauschen nämlich bei Daten- und Rechnernetzen immer Anwendungen Daten aus. Ob das in der Realität Briefe zwischen Electronic-Mail-Anwendungen oder Dateien zwischen einer Anwendung auf dem Rechner am Arbeitsplatz, die einen File-Service (logische Laufwerke) benutzt, und einer Anwendung auf dem Server, die diesen File-Service bereitstellt, sind, spielt für das Netz überhaupt keine Rolle. Die Kunst bei der Vernetzung ist die Abstraktion. Überträgt ein Netz einmal ordentlich Daten, wird es dies für einen weiten Bereich von Anwendungen tun. Ist ein Netz schlapp, wird es kaum eine Anwendung geben, die ordentlich auf dem Netz läuft. In einem heutigen PC-Netz laufen z. B. alte Anwendungen, die nur gelegentlich den File/Print-Service benutzen, neben neuen Anwendungen, die hochintelligente Kommunikationstechniken verwenden.

Das Internet ist deshalb so erfolgreich, weil man sich auf eine Menge von Regeln einigen konnte, die von allen eingehalten werden. Diese Regeln bilden die sog. TCP/IP-Protokollfamilie, die uns noch öfter begegnen wird. Die TCP/IP-Protokolle (TCP = Transmission Control Protocol = Protokoll (Regelmenge) zur Übertragungssteuerung, IP = Internet Protocol = Protokoll für das Netz zwischen den Netzen) sitzen sozusagen »in der Mitte«. »Unter« diesen Protokollen läuft die Übertragungstechnik, die sehr unterschiedlich sein kann, von der einfachen Telefonleitung mit vielleicht max. 20 kBit/s bis hin zum Gigabit-Netz mit einer Übertragungsleistung von 1 Milliarde Bits pro Sekunde, vom einfachen lokalen PC-Netz, das 50 m lang ist, bis hin zur weltumspannenden Satellitenkommunikation. »Über« den TCP/IP-Protokollen laufen die so genannte Anwendungsdienste wie E Mail, Datenübertragung und Fernzugriff auf fremde Hosts. Gleichzeitig werden hier aber auch sofort die Grenzen technischer Normierung klar: Rein theoretisch können Sie eine japanische Internet-Seite anwählen und mit einem Japaner E Mail austauschen. Allerdings wird das schwierig mit der Verständigung, wenn auf der Seite nur japanische Schriftzeichen sind und der Japaner kein Deutsch oder Englisch spricht. Das Japanisch eines Kontinentaleuropäers wird in den meisten Fällen sehr begrenzt sein.

Aber auch außerhalb des Internets ist Kompatibilität das Zauberwort bei der Kommunikation.

Kompatibilität verlangt Standards. Nur Standards sichern die Kompatibilität. Der Basis-Standard für Netze ist das OSI-Referenzmodell (Open Systems Interconnection = Verbindung Offener Systeme) der Internationalen Standardisierungsorganisation ISO. Es beschreibt die Netzarchitektur und die damit zusammenhängenden Protokolle abstrakt fast vollständig. Alle anderen Standards orientieren sich an den in diesem Modell festgelegten Funktionsbereichen.

Sie haben aber noch nie davon gehört? Die aus dem OSI-Modell resultierenden Produkte sind für PC-Netze und die allermeisten anderen Anwendungen heute zu umfangreich. So wird die reine Übertragungstechnik heute praktisch ausschließlich mit Funktionen im Rahmen der ursprünglichen OSI-Festlegungen realisiert. Die Funktionen jenseits der Übertragungstechnik werden mit »leichteren« Protokollen realisiert, die bestimmte Untermengen der durch das OSI-Referenzmodell festgelegten Funktionen anbieten, was meistens ausreicht. Wichtige »leichtere« Protokollfamilien sind die TCP/IP-Protokollfamilie, wie sie z. B. im Internet, aber auch bei vielen anderen Netzen zu finden ist, und die IPX/SPX-Protokollfamilie des Herstellers Novell, die in PC-Netzen bis ca. 1997 vorherrschte.

Wir haben gerade davon gesprochen, dass beim Internet TCP/IP in der Mitte steht und »darüber« weitere Protokolle arbeiten, die TCP/IP nutzen, und »darunter« Technik arbeitet, die ihrerseits von TCP/IP genutzt wird. Die »oberen« Protokolle sind einfach faul und benutzen in keinem Falle direkt die Nachrichtentechnik für die Übertragung von Bits und Bytes, sondern sie lassen sich die ganze Benutzung von TCP/IP vorkauen und nutzen dann nur noch einen bequemen Dienst von TCP/IP, nämlich die Übertragung größerer Einheiten von Daten und die Überwachung dieser Übertragung. Sie machen sich z. B. keinesfalls die Hände damit schmutzig, eine Verbindung aufzubauen. Sieht man genauer hin, merkt man schnell, dass eine Unterteilung in nur drei Stücke nicht ausreicht. Das OSI-Referenzmodell definiert deshalb sieben verschiedene Schichten bei der Kommunikation.

Das OSI-Referenzmodell

Das OSI-Referenzmodell beschreibt grundsätzlich die Architektur aller möglichen Netze unabhängig von der Art der Endgeräte und Anwendungen, aber auch unabhängig von der Art der technischen Vernetzung, also LAN oder ISDN oder WAN. Wir sollten jetzt den Blick darauf lenken, welche konstruktiven Komponenten in einem Netz generell vorhanden sind und wie diese zusammenwirken. Zwei Komponentengruppen spielen dabei offensichtlich eine jeweils die Konstruktion abschließende Rolle: Die Anwendungsprogramme oder Anwendungssysteme, die die Vernetzung nutzen, und die Drähte, Kabel oder Glasfasern, die der Vernetzung als physikalische Übertragungsmedien dienen. Sogar Luft oder Vakuum kann man ja bekanntlich als Medien nutzen.

Natürlich könnte man ein Anwendungsprogramm so schreiben, dass es mittels einer Treiberhardware unmittelbar auf einen Draht zugreift und Daten auf ihm überträgt. Das hat es sogar vor ca. 30 Jahren fast so gegeben, als die ersten remote Terminals angesprochen wurden: Die gesamten Steuerungsprozeduren für diese Terminals waren in den Anwendungen codiert. Der Nachteil ist offensichtlich: Man bindet eine bestimmte Gruppe Terminals an eine bestimmte Anwendung. Will man irgendetwas ändern, so muss man in der Anwendung herumfuchteln, was sicherlich nicht zu ihrer Integrität beiträgt, ganz zu schweigen von der mangelnden Flexibilität.

Zur Erhöhung der Flexibilität und Erleichterung einer sinnfälligen Konstruktion muss man vielmehr eine Reihe von Zwischenstufen einführen, die jeweils relativ eng eingegrenzte Aufgaben übernehmen. So kann man sie relativ leicht und ohne die mit zu großen Programmen oder Systemen verbundenen Risiken realisieren und die Qualität der Lösung auf Jahre hinaus angemessen sichern.

Ein anderer Aspekt ist der, dass sich vielleicht die technische Entwicklung schneller vollzieht als der Wechsel in den Anwendungen. Man möchte also z. B. die Anwendungen und die sie unterstützenden systemtechnischen Komponenten beibehalten, bei der Vernetzung jedoch von Kabeln auf Glasfasern wechseln. Dies klappt nur bei einer modularen Konstruktion einigermaßen reibungslos.

Anwendungen sind die Nutzer der Konstruktion, die technische Übertragung wird durch das Übertragungsmedium realisiert.

Von der Anwendung aus gesehen benötigen wir anwendungsnahe Grunddienste. Außer File Transfer fallen z. B. Electronic Mail (klar), Remote Job Entry (Beauftragung fremder Systeme), Virtual Terminal Service (netzweit einheitliches System für die Konversion unterschiedlicher Terminaltypen auf ein gemeinschaftliches Grundformat) und eine Reihe anderer unter diese anwendungsnahen Grunddienste. Wir nennen diese Schicht auch Anwendungsschicht (Application Layer, Layer 7) weil sie die Anwendungen unterstützt.

Für einen Dateitransfer beinhaltet die Anwendungsschicht die Operationen, die aus der Perspektive einer Anwendung dazu notwendig sind, eine Dateiübertragung zu beginnen, durchzuführen, die Durchführung zu kontrollieren und zu beendigen. Im einfachsten Fall besteht diese Schnittstelle aus einem einzigen Befehl, der, eingestreut in ein Anwendungsprogramm, den Transfer einer Datei von A nach B verursacht. Die funktionalen Arbeitseinheiten der Anwendungsschicht müssen natürlich eine ganze Menge Arbeit verrichten, um diesen Befehl in die Tat umzusetzen. Dabei werden sie aber von den Arbeitseinheiten der anderen Schichten tatkräftig unterstützt, besonders was die tatsächliche Nachrichtenübertragung betrifft. Aufgaben, die in dieser Schicht verbleiben und auch von keiner anderen übernommen werden können, sind z. B. das Prüfen des Gesamtvorganges auf seine Richtigkeit und die Umsetzung logischer Namen (z. B. Dateinamen im Anwendungsprogramm) in für den Rest der Konstruktion verwertbare physische Namen bzw. Adressen sowie weitere generelle Verwaltungsaufgaben.

Die nächste Schicht muss die anwendungsnahen Grunddienste direkt unterstützen. Wie auch immer die grundsätzliche Organisationsform eines Dateisystems ist, unterscheiden sich die Betriebssysteme vor allem in Kleinigkeiten, wie der Darstellung von Namen, Längenattributen und so weiter. Wenn man also zwischen einem Rechensystem und einem anderen einen File-Transfer durchführen möchte, reicht es nicht, die Bits und Bytes der Datei irgendwie zu übertragen. Vielmehr gibt es eine Reihe von strukturellen Attributen, die nicht nur übertragen, sondern konvertiert werden müssen, denn üblicherweise kann ein Rechensystem mit der Darstellung der strukturellen Information eines anderen Rechensystems wenig anfangen. Schließlich können innerhalb der Dateien noch verschiedene Codierungen für die Darstellung der Information verwendet worden sein.

Die Kommunikation zwischen zwei bestimmten Geräten könnte man nun so regulieren, dass man von den Formaten und Darstellungen des einen auf die Formate und Darstellungen des anderen mit entsprechenden Prozeduren übergeht. Will man jedoch keine Voraussetzungen darüber machen, welche Geräte nun miteinander kommunizieren können sollen, so muss man Konventionen für Formate und Darstellungen definieren, die für alle an der Kommunikation beteiligten Endgeräte verbindlich sind. Diese Konventionen sind sozusagen Bestandteil der Architektur des Kommunikationssystems. Jedes Gerät, welches in den Kommunikationsverbund aufgenommen werden möchte, muss sich diesen Konventionen anschließen. Dies gilt im Übrigen nicht nur für die hier betrachtete Ebene, sondern auch für alle anderen Schichten analog.

Die Aufgaben, die damit zusammenhängen, lokale Formate und Darstellungen in für das Netz allgemeingültige zu überführen, werden auch als Präsentations-Services oder Darstellungs-Services bezeichnet. Die Schicht, die unterhalb der Anwendungsschicht liegt, wird deshalb auch als Darstellungsschicht (Presentation Layer, Layer 6) bezeichnet. Darstellungsschicht und Anwendungsschicht kooperieren besonders innig und eng, da üblicherweise ein anwendungsnaher Grunddienst entsprechende Darstellungen impliziert.

Die zwei bereits betrachteten Schichten werden i. A. durch Programme realisiert. Programme müssen laufen können, und das Betriebssystem ist das zentrale Element hierfür. Es erzeugt aus Programmstücken lauffähige Prozesse und lässt sie z. B. im Zeitscheibenverfahren auf dem Prozessor arbeiten. Diese zentrale Funktion sollte sich auch das Kommunikationssystem zunutze machen können. Andersherum: Das Betriebssystem kann und sollte man nicht übergehen. Im Rahmen der Kommunikation zwischen zwei Geräten wird üblicherweise eine logische Verbindung zwischen zwei Betriebssystemen aufgebaut. Logische Verbindung bedeutet, dass diese Verbindung aus der Perspektive der Betriebssysteme unmittelbar zwischen ihnen auf einem geeigneten Medium etabliert wäre. Die ist jedoch nicht flexibel genug, und man sorgt nur durch entsprechende Vorkehrungen, auf die wir noch zu sprechen kommen, dafür, dass die Betriebssysteme eben den Eindruck der Exklusivität haben. Bei einem lokalen Netz können aber z. B. durch ein einziges Hochleistungs-Kommunikationsmedium Hunderte solcher logischen Verbindungen gleichzeitig unterstützt werden. Eine solche Verbindung wird auch als Session zwischen den beteiligten Prozessen bezeichnet, denn das Betriebssystem tritt nicht als Ganzes selbst mit einem anderen Betriebssystem in Verbindung, sondern lässt sich durch einen oder mehrere Prozesse vertreten. Diese Prozesse sind es aber auch, die die Programme der höheren Schichten realisieren. Im Rahmen einer solchen Session kann die ganze Kommunikation gesteuert werden: Die Prozesse, die die Elemente der höheren Schichten realisieren, sind abhängig vom Betriebssystem.

Meistens besteht nicht nur die Anforderung, irgendetwas auszutauschen, vielmehr möchte man auch Synchronisationsmaßnahmen durchführen können. Im einfachsten Fall sind dies Konstrukte, die es z. B. verhindern, dass zwei Prozesse aus verschiedenen Rechnern gleichzeitig auf eine gemeinsam zu benutzende Datei schreiben, was offensichtlich zu Unfug führt. Es gibt noch eine Reihe weiterer Interprozesskommunikationsmechanismen, die vom Prozessverkehr innerhalb einer Multiprozessanlage über das Netz auf die Gesamtumgebung gezogen werden.

Die Schicht, in der dies alles passiert, heißt dann auch Kommunikations-Steuerungsschicht. (Session Layer, Layer 5)

Für das Beispiel File Transfer gibt es zwei Alternativen für die Arbeitsweise der Kommunikations-Steuerungsschicht. Wird nur eine einzige Datei übertragen, ist es sicherlich nicht zweckmäßig, dafür extra eine logische Verbindung aufzubauen. Vielmehr schickt das Quell-Betriebssystem an das Ziel-Betriebssystem eine kurze Nachricht, die man oft als Datagramm bezeichnet. Jedes an ein Kommunikationssystem angeschlossene Betriebssystem muss einen kleinen Speicher für die Aufnahme ankommender Datagramme bereithalten. Das Datagramm wird im Zielsystem weiterverarbeitet, eventuell kann es eine Empfangsquittung an das Quellsystem geben, die wiederum als Datagramm verschickt wird. Die andere Alternative kommt für die Übertragung großer Dateien oder Folgen von Dateien (Bulk File Transfer) in Frage: Hier schützt die logische Verbindung den Datenverkehr und synchronisiert die Prozesse, die die Anwendungsprogramme repräsentieren.

Ein Netz besteht immer aus einem systemtechnischen und einem nachrichtentechnischen Teil. Wie wir gesehen haben, ist der systemtechnische der Teil, der die Anwendungen unmittelbar unterstützt. In der nächsten Schicht ist der Schnitt zwischen Nachrichtentechnik und Systemtechnik anzusiedeln. Die sogenannte Transportschicht (Transport Layer, Layer 4) schließt die nachrichtentransportorientierten Aspekte der noch darunterliegenden Schichten nach oben hin ab, und zwar so, dass sich die Systemtechnik nicht mit den Niederungen der nachrichtentechnischen Einzelheiten befassen muss. Von oben her gesehen, bietet die Transportschicht folgenden Service an: Es gibt einen eindeutigen globalen Adressraum zur Identifikation aller im Netzverbund irgendwie erreichbaren Rechner. Wir haben ja schon gesehen, dass es ggf. notwendig sein kann, mehrere Netze sozusagen hintereinanderzuschalten, um zwischen zwei Partnern zu vermitteln. Diese Hintereinanderschaltung sollte jedoch den teilnehmenden Systemen verborgen bleiben. Die Transportschicht bietet nunmehr eine Reihe von Kommandos an, mit denen es ermöglicht wird, Datenpakete flexibler Länge, für die es jedoch ein Maximum gibt, mit Angabe eines Zieles an das Netz zu übergeben (im Sinne eines Datagrammverkehrs) oder eine logische Verbindung zwischen zwei Elementen des Adressraums aufzubauen und über sie Datenpakete hin und herzuschicken.

Dabei abstrahiert die Transportschicht völlig von den verwandten Netzen und Zwischensystemen (Transparenz). Üblicherweise wird es so sein, dass unterschiedliche Qualitätsmerkmale für Netze vorhanden sind und man ebenfalls unterschiedliche Anforderungen an eine Verbindung zwischen Anwendungen stellt, z. B. hinsichtlich der Zuverlässigkeit usf. Für das Beispiel File Transfer ergeben sich die Aufgaben der Transportschicht in Abhängigkeit von der gewählten Alternative Logische Verbindung oder Datagramm.

Die nächste Schicht hat dementsprechend wieder etwas mehr mit der Hardware zu tun. Wir haben uns bisher noch keinerlei Gedanken darüber gemacht, wie man Wege in ggf. verzweigten Netzen bestimmen kann. Gerade das ist Aufgabe der jetzt betrachteten Schicht, der Vermittlungsschicht (Network Layer, Layer 3). Sie sieht bei von der Transportschicht gegebenen Quelle-Ziel-Paaren nach, welchen Weg es gibt und ob dieser Weg auch beschritten werden kann. Falls irgendetwas auf dem ursprünglich angepeilten Weg nicht in Ordnung sein sollte, bestimmt die Vermittlungsschicht einen Ersatzweg. Sie kennt alle Knoten und Gateways (Verbindungen zwischen unterschiedlichen Netzen) oder zumindest die in der unmittelbaren Umgebung vorhandenen. Notfalls kann sie sich mit einer anderen Vermittlungsschicht-Implementierung in einem anderen Zwischenknoten, Gateway oder Endsystem in Verbindung setzen, um den Weg zu bestimmen. Die Schicht besitzt sozusagen die Landkarte des Netzes und weiß damit umzugehen.

Die Vermittlungsschicht ist ein Kernelement der Transparenz: Ohne sie wäre es mühsam, Wege zu bestimmen. Sie ist auf diese Aufgabe optimiert und kann sich in den unterschiedlichsten Netztypen zurechtfinden.

Ein (Hardware-) Netz besteht immer aus der eigentlichen Übertragungstechnik, die in der Lage ist, Bitströme über die Medien zu schicken oder von ihnen zu empfangen. Diese Bitströme sind roh und bedürfen einer logischen Veredlung, damit man sie überhaupt als Datenpakete erkennen und weiterbehandeln kann. Diese Veredelung ist die Aufgabe der zweiten Schicht von unten. Im Rahmen dieser Veredelung wird man auch elementare Übertragungsfehler beheben und somit die Übertragung von Daten absichern. Dies hat der Schicht auch den Namen Sicherungsschicht (Data Link Layer, Layer 2) eingetragen. Wir besprechen sie jetzt nicht mehr weiter, weil sie viel interessanter wird, wenn man konkret über realisierte Netze spricht.

Nun erreichen wir endlich die letzte, die physikalische oder Bitübertragungsschicht (Physical Layer, Layer 1), die alle Elemente enthält, um über das physikalische Medium Nachrichten schicken zu können, also elektrische oder optische Sender und Empfänger.

Die Unterkante ist das Übertragungsmedium..

Wir haben gesehen, welch vielfältige Aufgaben bei einer Übertragung im Netz anfallen und wie die einzelnen Schichten unserer gedachten Konstruktion zusammenwirken, um dies zu realisieren. Jede Schicht hat dabei einen genau eingegrenzten Aufgabenbereich, jede Schicht stellt nach oben hin Dienste zur Verfügung und benutzt die Fähigkeiten der nächstunteren Schicht.

Kommunikation ist eine im wahrsten Sinne des Wortes »vielschichtige« Angelegenheit. Das OSI-Referenzmodell grenzt Aufgaben- und Funktionsbereiche untereinander ab und führt zu einem sinnvollen Gesamtbild. Die ganze Industrie hat das Modell akzeptiert, Profis reden nur noch in Schichten. Die ursprünglich mit dem Modell entwickelten Standards sind in den unteren Schichten heute überall zu finden, während sich die Standards für die höheren Schichten nicht durchsetzen konnten, weil sie zu kompliziert waren. Also greift man zu vereinfachten Implementierungen, die aber den Sinn wahren. So ist die TCP/IP-Protokollfamilie nichts weiter als eine Art »OSI für Arme«. OSI und TCP/IP sorgen für offene Kommunikation: Alle Geräte, die die entsprechenden Protokolle implementiert haben, können auch miteinander kommunizieren, falls es eine nachrichtentechnische Verbindung zwischen ihnen gibt.

Wir besprechen TCP/IP später noch genauer. In der nächsten Folge wird es (endlich) konkret und wir sehen uns an, welche Möglichkeiten es gibt, Bits, die ja die Träger aller Information sind, physikalisch zu übertragen.

« Teil 3: Grundkomponenten der DatenübertragungTeil 5: Metallische Leiter und optische Übertragungstechnik »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.