5 OSI Referenzmodell
Kommunikation ist ein fundamentaler Bestandteil industrieller Systeme, früher und heute noch viel mehr. Als Basis zur abstrakten Betrachtung dienen Referenzmodelle wie das OSI oder das TCP/IP Modell. Zu beiden dieser Modelle findet man in Literatur (z.B. [1]) oder im Internet sehr ausführliche Beschreibungen, weshalb hier nur das nötigste Eingeführt wird.
Abbildung Figure 5.1 zeigt beide Modelle, die auf verschiedener Schichten basieren. Das OSI-Modell ist ein sehr ausführliches Referenzmodell und zeigt genauer den Zusammenhang zwischen Schnittstellen, Protokollen und Diensten. Das TCP/IP Modell gilt heute eigentlich als Standard, verdeckt aber den Inhalt und ist schlecht auf andere industrielle Kommunikationsprotokolle anwendbar. Aus diesem Grund eine einleitende Beschreibung zum OSI Modell, um darauf basierend das Bergdorf Beispiel nachvollziehen zu können.
6 Grundlagen
Das Open Systems Interconnection Model oder kurz OSI Modell ist eine abstrakte Betrachtung von Kommunikationslayern, entwickelt in den 1970ger Jahren. Das Modell basiert auf Layern (Schichten). Jeder dieser Layer bietet seine Dienste dem darüber liegenden an und nutzt Protokolle diese umzusetzen. Dienste werden somit zur Schnittstelle und abstrahieren aber die eigentliche Umsetzung im Protokoll. Somit kann ein Layer einfach ausgetauscht oder durch andere Funktionalität erweitert werden.
Als vereinfachte Beispiel dient folgende Kommunikation (Siehe Figure 6.1) zwischen zwei Personen. Die Kommunikation nutzt ein 4 Layer Schema. Die oberste Schicht beschreibt den eigentlich Nutzen, in diesem Fall die Übertragung von “Guten Tag”. Die nächste Schicht übersetzt dies in einen allgemeinen Standard, bevor Layer 2 die Zieladresse ergänzt. Im letzten Layer wird anhand der Zieladresse die Anschrift ergänzt und die Nachricht per Brief “übertragen”. Auf der Gegenseite nimmt Layer 1 die Meldung in Empfang und prüft in Layer 2 die Adresse. Anschliessend wird im Layer 3 die Übersetzung vorbereitet, um diese im Layer 4 auf Französisch auszugeben. Die Abstraktion der Funktionalitäten erlaubt es nun, z.B. Layer 3 auszutauschen und als Standard Italienisch zu nutzen oder auf Layer 1 die Übertragung per E-Mail einzubauen. Ohne das die Anwendung auf Layer 4 verändert wird.
Das gleiche Prinzip gilt im OSI-Modell, aber verteilt auf 7 Layer. Die einzelnen Layer werden nachstehend kurz Beschrieben. Spannend in der Grafik ist vorher aber die Box zwischen den eigentlichen Kommunikationsteilnehmern (Siehe Figure 6.2). Diese zeigt Teilnehmer, die lediglich einen Teil der Layer umsetzen. In Netzwerk sind dies später Switches oder Router. Als Sinnbild in unserem Übersetzer Beispiel könnte dies aber eine Vermittlungsstation resp. eine Poststelle sein. Der Sender muss allenfalls den Brief bei einem lokalen Postbüro einwerfen, welche den Brief anhand der Anschrift an ein grösseres Verteilzentrum weiterleitet. Diese Stelle muss für ihren Zweck der Weiterleitung aber nur Layer 1 und 2 nutzen.
Zurück zum OSI Modell möchten wir uns kurz den einzelnen Layern widmen.
6.1 Layer 1: Physical Layer (Bitübertragungsschicht)
Layer 1 ist der unterste Layer und kümmert sich um den Übergang zum Medium. Hier geht es um die Frage wie eine 1 oder eine 0 als Bit übertragen werden kann, damit sie von der Gegenseite auch so interpretiert wird. Das klingt sehr einfach, ist physikalisch aber anspruchsvoll umzusetzen. In der Vorstellung übertragen wir eine 1 als elektrisches High und eine 0 als elektrisches Low auf das Netzwerkkabel. Praktisch kann man aber keine idealen Rechtecksignale auf einem Leiter erzeugen, da dieses wie ein Tiefpassfilter wirkt. Genauso hat z.B. auch die Dämpfung einen Einfluss und verzerrt das Signal. Mit anderen Worten spielt es eine Rolle, ob das Signal auf ein 10Base-T Ethernet mit 10 MBit/s oder auf einen 10Base-FL Lichtwellenleiter übertragen wird, um es verlässlich wieder einlesen zu können.
Folgend ein Beispiel einer Manchester Codierung:
6.2 Layer 2: Data Link Layer (Sicherungsschicht)
Layer 2 verwaltet den Zugriff und die Nutzung des Kommunikationskanals oder besser eines Subnetzes, so dass die gewünschte Information übertragen werden kann (Kanalverwaltung = Media Access Control kurz MAC). Auf Sender Seite braucht es dafür Prozesse die z.B. das gleichzeitige Senden verhindern oder dieses Erkennen und beheben können (Stichwort: CSMA/CD, CSMA/CA). Genauso braucht es Adressierung, damit ein Empfänger seine Nachrichten im Kanal identifizieren kann. Dies bezieht sich meist auf eine physische Anschlussstelle (z.B. Netzwerkkarte). Weitere Themen auf diesem Layer:
- Fehlererkennung in der Übertragung (Stichwort: CRC)
- Ansprechen von mehreren Teilnehmern (Stichwort: Multicast, Broadcast)
- Synchronisierung von Bitlängen (Stichwort: Präambel)
- …
In Ethernet Netzwerken wird hier die MAC-Adresse genutzt.
6.3 Layer 3: Network (Vermittlungsschicht)
Layer 2 kümmert sich um ein Subnetz (Kanal). Layer 3 kümmert sich übergeordnet, um den Weg zwischen Sender und Empfänger, man spricht von der eigentlichen End-zu-End Kommunikation. Dafür kann eine logische Adressierung hinzukommen, die neben der Teilnehmeradresse auch Informationen vom Zielsubnetz beinhaltet. Diese Info wird dann von Geräten die Subnetze verbinden (Router) genutzt, um den Weg zum Ziel zu steuern (Stichwort: Routing).
In Ethernet Netzwerken werden auf diesem Layer IP-Adressen genutzt.
6.4 Layer 4: Transport (Transportschicht)
Layer 1-3 kümmern sich um die Übertragung von Information zwischen zwei Teilnehmern. In Layer 4 wird der Transport entsprechend dem gewünschten Anwendungszweck sichergestellt. Ist die gewünschte Anwendung ein File Transfer Client, um Dateien auszutauschen, ist die richtige und vollständige Übertragung wohl wichtiger als die Geschwindigkeit. Das bedeutet, dass dieser Layer Informationen zur Reihenfolge der Pakete, zur Anzahl der Pakete hinzufügt, wie auch einen Prozess der den Empfänger zur Bestätigung aller Pakete auffordert. Ist die Anwendung hingegen ein Telefongespräch, ist mir die stetige Übertragung wichtiger, als jedes einzelne Wort perfekt zu verstehen. Also möchte ich kurze Pakete verschicken, ohne viele Steuerinformationen für den Transport. Genauso wird auf die Bestätigung aller Pakete verzichtet.
In Ethernet Netzwerken wird hier oft TCP, UDP oder QUIC verwendet.
6.5 Layer 5: Session (Sitzungsschicht)
Layer 5 ermöglicht die Verwaltung verschiedener Dienste auf einem Teilnehmer. In Computernetzwerken kann auf einem Computer Outlook, ein Webbrowser und Netflix gleichzeitig laufen. Somit muss der Datenstrom gesteuert werden können, um Pakete von und zur richtigen Anwendung zu bringen.
In Ethernet Netzwerken werden dafür Port-Nummern verwendet.
6.6 Layer 6 - Präsentation (Darstellungsschicht)
Diese Schicht übersetzt die eigentlichen Nutzdaten von Layer 7 in ein gewünschtes, technisches Format und zurück. Als Beispiel möchte ich eine Temperatur übertragen, nehmen wir 35°C. Ich könnte nun nur den Wert in einem Byte übertragen (35, 00100011) oder aber auch ASCII-Codiert (0x33 0x35 0xB0 0x43). Genauso könnte ich hier zusätzlich noch ein JSON-Format einführen und die Temperatur wie folgt formatieren:
{ “temp”: 35, “unit”: “°C” }
Strikt nach dem OSI-Modell können hier auch Verschlüsselungsalgorithmen hinzukommen. Also die Ver- und Entschlüsselung von Nutzdaten.
6.7 Layer 7: Application (Anwendung)
Layer 7 ist der eigentlich Grund warum es alle anderen Layer benötigt. Hier wird die Anwendung ausgeführt. Möchte ich einen Webbrowser bauen, könnte ich hier z.B. HTTP Requests und Responses verarbeiten. Oder wenn ich ein Netzwerk Spiel programmiere, definiere ich hier die Befehle die ausgetauscht werden.
7 Feldbusse in der Industrie
Das OSI-Modell wird auch in der Industrie oft beigezogen. So zum Beispiel auch bei Feldbussen. Hier sieht man besonders die stärke vom OSI-Modell, da man direkt erkennen kann auf welchem Layer gearbeitet wird und welche Kompatibel sind zueinander. Abbildung Figure 7.1 zeigt als Beispiel, das Web, Ethernet IP und Profinet von Layer 1-3 alle Ethernet und IP nutzen. Somit funktionieren diese Protokolle auf einem normalen “IT”-Netzwerk und können sogar gleichzeitig betrieben werden. Hingegen EtherCAT ist komplett proprietär und erfordert ein separates Netzwerk.
Randbemerkung TCP/IP Modell: Diese Tabelle macht deutlich, warum das OSI-Modell besser geeignet ist, verallgemeinert verschiedenen Protokolle einzuordnen als das TCP/IP Modell.
8 Entwicklung OSI-Modell im Bergdorf
Versuchen wir doch mal ein praktisches Sinnbild anhand des OSI-Modells für gängige IT Kommunikation zu schaffen. Als Ausgangslage dient nachfolgendes Bergdorf. Die Buchstaben A-M sind Personen, die miteinander kommunizieren möchten. Als Kommunikationsmittel dienen Glühbirnen, wie sie bei A, B und C gezeigt werden. Andere Möglichkeiten wie Rufen oder dergleichen, sind nicht möglich. Ausserdem verhindern die Hügel den Sichtkontakt, was zu drei Teilnehmergruppen führt A-B-C; C-D-E-F; F-Haus(G-H)-Haus(I-J)-Haus(K-L-M). Es kann davon ausgegangen werden, dass die Glühbirnen unbeweglich sind und immer ein ganzes Tal ausleuchten.
8.1 Übertragen von Nutzdaten (L1, L6, L7)
Starten wir mit einer Übertragung von A nach B. A möchte die Nutzdaten “Hallo” an B übertragen. Dies entspricht der Anwendung, also den eigentlichen Grund, warum es Kommunikation benötigt. Im OSI Modell ist dies die oberste Schicht, Layer 7 Application. In der Weiterverarbeitung müssen die Nutzdaten zuerst in ein technisches Format übersetzt werden (OSI Layer 6 Presentation), damit diese über Layer 1 Physical Layer übertragen werden können (In der Regel ein binäres Format). Für Text wird meist eine ASCII oder UTF-8 kodiertabelle verwendet, aber genauso könnte auch ein fixer Befehlssatz definiert werden, wie 1 = “Hallo”, 2 = “Bye” usw. Um aber jegliche Meldungen senden zu können, bleiben wir bei ASCII (Siehe Figure 8.2). Bei ASCII entspricht ein Symbol einem Byte.
Quelle: ASCII Table
ASCII-Kodierte Zeichenfolgen (dezimal): Hallo -> 72(H) 97(a) 108(l) 108(l) 111(o)
Binär: 0100_1000 0110_0001 0110_1100 0110_1100 0110_1111
Somit ist alles vorhanden, um die Daten mittels der Glühbirne zu kodieren und aufs Medium “Luft” zu übertragen. Folgende Möglichkeiten sind naheliegend:
- Nutzen der Helligkeit (Prinzip einer analogen Übertragung)
- Ein- und Ausschalten der Glühbirne (Prinzip einer digitalen Übertragung)
Variante 1 scheint speziell fürs Senden sehr interessant zu sein, wenn es gelingt die Helligkeit in 256 Stufen einzuteilen. Damit könnte direkt 1 Byte also 8 Bit-Informationen, auf einmal gesendet werden. Praktisch wird es wohl nicht möglich sein, auf Empfängerseite 256 Helligkeitsstufen richtig zu interpretieren.
Variante 2 scheint robuster, es muss aber jeweils Bit-weise kommuniziert werden. Dafür wäre 1 = Einschalten, 0 = Ausschalten naheliegend. Hat aber das Problem, dass nicht zwischen 0 und “nicht senden” unterschieden werden kann.
Im folgenden eine Möglichkeit wie das vielleicht verbessert werden könnte:
| Blinkdauer | Bedeutung | Bemerkung |
|---|---|---|
| Lang | 1 | Eine logische 1 |
| Kurz | 0 | Eine logische 0 |
| keine | - | Keine Übertragung |
Beispiel: 1-0-1 wird zu Lang-Kurz-Lang.
Nach diesem Schritt nutzen wir folgende Layer:
| Layer | Bedeutung | Beispiel |
|---|---|---|
| 7 | Anwendung resp. Nutzdaten | “Hallo” |
| 6 | Umwandlung in in ASCII | 72 97 108 108 111 |
| 1 | Kodierung in Licht | Kurz-Lang-Kurz-Kurz-… |
Diese Festlegung erlaubt eine Kommunikation zwischen zwei Stationen im selben Tal.
8.2 Zugriffssteuerung im Tal (L2)
Das Kommunikationssystem ist in der Lage einen Text in ASCII umzuwandeln und die binären Signale mit Licht zu übertragen. Im nächsten Schritt geht es um die Zuverlässigkeit. Wir möchten sicherstellen, dass die Daten auch am richtigen Ziel ankommen (Layer 2 Data Link Layer). Betrachten wir folgende Fragestellungen:
- Wie lange ist Lang für eine 1 bzw. Kurz für eine 0?
- Kann es kurzes Flackern geben, vielleicht aufgrund von Reflexionen?
- Welche Einsen und Nullen gehören zusammen?
- Wann beginnt eine Übertragung?
- An wen richtet sich die Information?
- Was wenn gleichzeitig mehrere Stationen beginnen zu senden?
- Wurden alle Lichtsignale fehlerfrei übertragen?
- …
Als Grundlage starten wir mit einer definierten Signalfolge zur Synchronisierung (Präambel) und einen definierten Start (Start Frame Delimiter) der Nutzdaten. Definieren wir also 1 Byte zusätzlich mit der Präambel Sequenz 10101010 zur Synchronisierung und nochmals ein Byte für den definierten Start der Nutzdaten 10101011. Anhand der Präambel kann der Empfänger Lang und Kurz einordnen und weiss nach “11” beginnt der interessante Teil.
| Präambel | Startbyte (SFD) | Nutzdaten |
|---|---|---|
| 10101010 | 10101011 | Nutzdaten für Hallo |
Als Empfänger kommen aber alle im Tal in Frage, was in unserem Beispiel A, B und C ist. Ergänzen wir also direkt das Ziel und den Absender. Da in unserem Tal alle einen Buchstaben zur Identifikation nutzen, definieren wir jeweils 1 Byte, ASCII codiert.
| Präambel | Startbyte (SFD) | Ziel | Quelle | Nutzdaten |
|---|---|---|---|---|
| 10101010 | 10101011 | 0100_0002 (B) | 0100_0001 (A) | Nutzdaten für Hallo |
Ein Empfänger kann nun beim Einlesen der Zieladresse entscheiden, ob die Nachricht für ihn ist oder für jemanden anderes. Ist die Nachricht für den Empfänger, stellt sich die Frage, wie viele Bits zu erwarten sind? Dafür fügen wir direkt ein Längenfeld von einem Byte ein. Für Hallo wären das demnach 5 Bytes.
| Präambel | Startbyte (SFD) | Ziel | Quelle | Länge | Nutzdaten |
|---|---|---|---|---|---|
| 10101010 | 10101011 | 0100_0002 (B) | 0100_0001 (A) | 0000_0101 (5) | Nutzdaten für Hallo |
Mit diesem Stand des Protokolls können wir ziemlich zuverlässig Daten in unserem Tal kommunizieren. Vergleicht man unseren Funktionsumfang mit echten Protokollen im Ethernetnetwerk, ist dies aber noch nicht abschliessend. Es würden noch weitere Sicherheiten eingebaut, wie ein Prozess bei Kollisionen durch das gleichzeitige Senden mehrerer Stationen oder auch die Kontrolle, ob alle Lichtsignale richtig beim Empfänger empfangen resp. interpretiert wurden. Diese werden in diesem Beispiel der einfachheit halber weg gelassen.
Nach diesem Schritt nutzen wir folgende Layer:
| Layer | Bedeutung | Beispiel |
|---|---|---|
| 7 | Anwendung resp. Nutzdaten | “Hallo” |
| 6 | Umwandlung in ASCII | 72 97 108 108 111 |
| 2 | Steuerung Kanalzugriff | Präambel, Start, Adressen, Länge |
| 1 | Kodierung in Licht | Kurz-Lang-Kurz-Kurz … |
Beispiel Nachricht auf Layer 2:
| Präamble | Start | Ziel | Quelle | Länge | Nutzdaten: |
|---|---|---|---|---|---|
| 10101010 | 10101011 | 01000002 | 01000001 | 00000101 | 01001000 01100001 01101100 01101100 01101111 |
8.3 Kommunikation aus dem Tal hinaus (L3)
Abbildung Figure 8.3 zeigt grün unsere Broadcastdomäne, in der wir zwischen A, B und C mittels Layer 1 und 2 kommunizieren können. Wie sieht es nun aus, wenn wir aus dem Tal hinaus kommunizieren möchten? Folgen wir unserem bisherigen Schema, liegt die Lösung in einem zusätzlichen Layer.
Die eingeführten Adressen (A-M) entsprechen der MAC Adresse (Physische Adresse). Es gibt aber keinen Zusammenhang zwischen dieser Adresse und dem Standort. Ein Sender hat somit keine Ahnung in welchem Tal der gewünschte Empfänger ist. Aus diesem Grund wird im nächste Schritt, eine logische Adresse eingeführt, um den Weg ins richtige Tal zu verwalten Layer 3 Network. Mit anderen Worten, Layer 2 beinhaltet die Adressen im aktuellen Tal und Layer 3 die Adressen der eigentlichen Übertragung (In Netzwerken sind diese Adressen die IPs) sowie eine Art Hierarchie.
Für D könnte die logische Adresse als Beispiel CDEF-D sein. Dies würde Informationen über das Tal CDEF und den darin enthaltenen Teilnehmer geben. Dies können wir ebenfalls nutzen, um den Pfad der Kommunikation herzuleiten. Wenn A mit D kommunizieren möchte, kann A von der Zieladresse ableiten, dass sie nicht im selben Tal sind (ABC != CDEF) und somit an ein Gateway weitergeleitet werden muss. Das heisst zwar noch lange nicht, dass der Zielteilnehmer auch existiert. Aber wenn es jemand weiss, dann hoffentlich die Gateway Station (Best Effort).
In diesem Fall ist die Gateway Station oder treffender der Router, die Station C. Diese hat eine Schnittstelle (Glühbirne) in den angrenzenden Tälern (Siehe Figure 8.4). Nachfolgend die vereinfachten Meldungen.
| Station | L7 | L3 | L2 | Bemerkung |
|---|---|---|---|---|
| A | Hallo | ABC-A nach CDEF-D | A nach C | Schicken ans Gateway |
| C | Hallo | ABC-A nach CDEF-D | C nach D | Weiterleiten an D |
Nach diesem Schritt nutzen wir folgende Layer:
| Layer | Bedeutung | Beispiel |
|---|---|---|
| 7 | Anwendung resp. Nutzdaten | “Hallo” |
| 6 | Umwandlung in ASCII | 72 97 108 108 111 |
| 3 | Logische Adressen | Quelle und Ziel |
| 2 | Steuerung Kanalzugriff | Präambel, Start, Adressen, Länge |
| 1 | Kodierung in Licht | Kurz-Lang-Kurz-Kurz … |
Beispiel Nachricht auf Layer 2:
| … | Ziel-MAC | Quelle-MAC | Länge | Ziel | MAC | Nutzdaten: |
|---|---|---|---|---|---|---|
| … | 01000002 | 01000001 | 00000101 | 01000002 | 01000001 | … |
8.4 Nachricht angekommen (L4)
Unser Protokoll hat nun doch schon einen ordentlichen Umfang. Im nächsten Schritt geht es in Richtung der Zuverlässigkeit aus Sicht der Anwendung. Hintergrund: Nur weil ich jemandem etwas zurufe, bedeutet noch lange nicht, dass es gehört, geschweige denn verstanden wurde. Layer 4 Transport kümmert sich um den passenden Transport der Nachricht.
Möchte man nur ein “Hallo” übertragen, scheint dieser Layer wenig sinnvoll. Denkt man aber an ein Buch wird es klarer, dass es Mechanismen braucht, um eine vollständige und fehlerfreie Übertragung zu gewährleisten. Oft ist dies ein Kompromiss zwischen Geschwindigkeit, Einfachheit und Fehlertoleranz.
Beispiel Bergdorf: Kommunizieren wir zwischen zwei Hügeln, würden wir gerne wissen ob die Meldung empfangen wurde. Dafür fügen wir unserem Protokoll den Layer 4 hinzu, sprich wir fügen ein Byte zur Wahl des Mechanismus hinzu. Im einfachsten Fall könnte man definieren, wenn dieser Wert auf 1 steht, wird der Empfänger aufgefordert eine Bestätigung (Acknowledge) zu senden. Der Sender könnte so lange mit der nächsten Meldung warten, bis diese eingetroffen ist.
| Sequenz | Richtung | Meldung |
|---|---|---|
| 1 | >>> | Hallo |
| 2 | <<< | Signal: Ack |
Bereits an diesem Beispiel erkennt man Lücken. Was wenn eine Bestätigung länger ausbleibt? Nach einem Timeout könnte man die Meldung wiederholen, was wiederum heisst, die Meldung muss so lange im Speicher gehalten werden. Dieser Mechanismus benötigt aber auch Zeit, also sollte das Senden nicht unterbrochen werden, was wiederum zu einer ID pro Meldung führt, die für ein Ack genutzt wird usw. Dieser Layer kann nach belieben ausgebaut werden.
Nach diesem Schritt nutzen wir folgende Layer:
| Layer | Bedeutung | Beispiel |
|---|---|---|
| 7 | Anwendung resp. Nutzdaten | “Hallo” |
| 6 | Umwandlung in ASCII | 72 97 108 108 111 |
| 4 | Bestätigte Übertragung | 1 Byte für Ack, Sequenz |
| 3 | Logische Adressen | Quelle und Ziel |
| 2 | Steuerung Kanalzugriff | Präambel, Start, Adressen, Länge |
| 1 | Kodierung in Licht | Kurz-Lang-Kurz-Kurz … |
8.5 Mehrere Dienste an einem Empfänger (L4/L5)
Das entwickelte Protokoll nutzt alle Layer aus, ausser Layer 5 Session. Betrachten wir unsere Hügellandschaft (Siehe Figure 8.4), können wir mit allen Personen kommunizieren. Hinter F sind aber noch Personen in einem Haus, die sich die selbe Glühbirne teilen. Die Kommunikation zum Haus ist durch die bestehenden Layer abgedeckt. Das Ansprechen einer Person im Haus übernimmt Layer 5.
Postfächer übernehmen dieses Problem. Wir weisen jeder Person eine Bezeichnung als Postfach zu. Auf diese Weise können wir eine spezifische Person ansprechen und eine Antwort auch entsprechend identifizieren.
| Sequenz | Von, Nach | Postfach | Meldung |
|---|---|---|---|
| 1 | A nach GH (Haus) | G | Hallo g! |
| 2 | GH (Haus) nach A | Von G | Hi! |
Nun kann es aber sein, das bei A auch noch andere Personen in der Nähe sind. Dies führt dazu, dass beide Seiten ein Postfach benötigen. Somit gibt es jeweils ein Quell- und einen Zielpostfach. In Netzwerken entspricht dies den Ports.
| Sequenz | Von, Nach | Port Quelle | Port Ziel | Meldung |
|---|---|---|---|---|
| 1 | A nach GH (Haus) | A | G | Hallo G! |
| 2 | GH (Haus) nach A | G | A | Hi! |
Nach diesem Schritt nutzen wir folgende Layer:
| Layer | Bedeutung | Beispiel |
|---|---|---|
| 7 | Anwendung resp. Nutzdaten | “Hallo” |
| 6 | Umwandlung in ASCII | 72 97 108 108 111 |
| 5 | Port Bezeichnung | 1 Byte für ID |
| 4 | Bestätigte Übertragung | 1 Byte für Ack |
| 3 | Logische Adressen | Quelle und Ziel |
| 2 | Steuerung Kanalzugriff | Präambel, Start, Adressen, Länge |
| 1 | Kodierung in Licht | Kurz-Lang-Kurz-Kurz … |
8.6 Das Bergdorf im Netzwerk
Dieses Beispiel soll den Schrittweisen Aufbau einer Kommunikationsstruktur aufzeigen. Es ist wichtig zu verstehen, dass dies ein Weg und ein definiertes Set an Funktionalität aufweist. Je nach Kommunikation können einzelne Layer komplexer werden. Im Nachfolgend sieht man das Abbild in einem ethernetbasierten Netzwerk:
Jede Station mit Glühbirne wird zu einem Endgerät. Das Tal wird zu einer Broadcastdomäne, heute zu einem Switch. Somit können Stationen mit allen anderen Stationen am Switch einfach auf Layer 2 über eine MAC-Adresse kommunizieren. Zum verlassen des Tals kommt die logische IP-Adresse hinzu, die es ermöglicht über die Gateways resp. die Router zu kommunizieren. Da in der Regel auf einem Endgerät mehr als eine Anwendung läuft, erlauben die Ports die Identifikation.
Aber wieso Layer?: Austauschbarkeit und Strukturierung ist die einfache Antwort. Wenn wir unsere Kommunikation auf Rauchsignale umstellen, müssen wir lediglich Layer 1 und 2 anpassen. Der Rest bleibt gleich. In einem Computer spielt es somit keine Rolle, ob meine Python Anwendung das Hallo über Glasfaser, Kupfer oder Licht transportiert.
Betrachtung: TCP/IP Modell Betrachtet man die nun generierten OSI Layer etwas genauer und überlegt sich, wie und wo diese umgesetzt werden, ist folgendes denkbar:
- Layer 5,6,7 - Sind Dinge, die Alle auf Seiten der Anwendung stattfinden
- Layer 4 - Ermöglicht den geeigneten Transport
- Layer 3 - Ermöglicht den Weg der Kommunikation
- Layer 1,2 - Ermöglicht Kommunikation in und von einem entsprechenden Medium
Es ist wichtig sich alle Layer zu überlegung, in der Umsetzung werden es dann aber oft nur 4, was dem TCP/IP Modell entspricht.