Lokale Netze (LAN) — Anpassung an IP-Betrieb

It is easier to move a problem around than it is to solve it.

R. Callon, The Twelve Networking Truths, April 1996

Wenn man ein Ethernet-Netzwerk OSI-konform betreiben will, dürfen die Protokolle der Netzwerkschicht nicht direkt auf die MAC-Schicht aufsetzen. Dieses Kapitel beschreibt die Möglichkeiten, die für die entsprechenden Protokollanpassungen zur Verfügung stehen.

Logical Link Control (LLC)

Mit der mediumunabhängigen Schicht Logical Link Control (LLC) wird gewissermaßen die MAC-Schicht zu einer vollständigen OSI-Sicherungsschicht (Data Link Layer) ergänzt. Die zwischen Partnerinstanzen (Peer Entities) ausgetauschten Datenblöcke werden allgemein als Link Protocol Data Units (LPDUs) oder einfach als LLC-Rahmen (LLC Frames) bezeichnet.

Die LLC-Schicht sieht insgesamt drei Typen von Diensten vor.

Typ 1 (LLC1):

Unbestätigter verbindungsloser Dienst (unacknowledged connectionless Service): Der Sender verschickt unabhängige Rahmen, deren Empfang nicht bestätigt wird.

Typ 2 (LLC2):

Bestätigter verbindungsorientierter Dienst (acknowledged connection-oriented Service): Vor der Übertragung bauen Sender und Empfänger eine Verbindung auf. Jeder Rahmen wird numeriert und der Empfang der fehlerfrei und in der richtigen Reihenfolge eingetroffenen Rahmen wird bestätigt.

Typ 3 (LLC3):

Bestätigter verbindungsloser Dienst (acknowledged connectionless Service): Der Sender verschickt unabhängige Rahmen, deren Empfang individuell bestätigt wird.

Grundlage für die drei LLC-Typen war das im WAN- und MAN-Bereich bekannte HDLC-Protokoll (High-level Data Link Control). Die hieraus gebildeten LLC-Protokolle wurden speziell für den LAN-Bereich entwickelt und als eigene Spezifikationen verabschiedet.

Im folgenden wird nur der einfachste Typ LLC1 betrachtet. Dieser Typ ist ausreichend, um einen verbindungslosen Netzwerkdienst zu unterstützen. In LAN-Umgebungen spielen die Typen LLC2 und LLC3 keine Rolle.

LLC-Adressformat

Die LLC-Schicht verwendet ein eigenes Adressierungs-Schema. In Anlehnung an die Service Access Points (SAPs) der Kommunikationsschichten spricht man in der LLC-Schicht von einem Source Service Access Point (SSAP) beim Sender und von einem Destination Service Access Point (DSAP) beim Empfänger. Die LLC-Adresse des Senders wird somit als SSAP-Adresse und die LLC-Adresse des Empfängers als DSAP-Adresse bezeichnet. Im allgemeinen werden mit der LLC-Adresse die Dienste der über der LLC-Schicht liegenden Netzwerkschicht identifiziert. Die LLC-Adresse ist daher vergleichbar mit der Protokolltyp-Nummer bei Ethernet.

Das genaue Adressformat für die 8 bit langen DSAP- und SSAP-Adressen zeigt die folgende Abbildung.

I/G = 0:

Individual-Adresse, die genau einen DSAP identifiziert.

I/G = 1:

Gruppen-Adresse, die eine Gruppe von DSAPs oder alle DSAPs identifiziert.

C/R = 0:

Command Frame.

C/R = 1:

Response Frame.

Die folgende Tabelle zeigt einige der gebräuchlichsten LLC-Adressen, wobei das I/G-Bit bzw. das CR-Bit jeweils als Least Significant Bit (LSB) interpretiert wird.

LLC1-Rahmenaufbau

Der Aufbau eines LLC1-Rahmens wird in der folgenden Abbildung gezeigt.

DSAP Address:

LLC-Adresse des Zielendgerätes.

SSAP Address:

LLC-Adresse des sendenden Endgerätes (DSAP- und SSAP-Adresse sind in der Regel identisch, da bei Sender und Empfänger der gleiche Dienst angesprochen wird).

Control:

Kennzeichnung des Rahmens als Unnumbered Information (UI) Frame, Exchange Identification (XID) Frame oder TEST Frame durch die Modifier Bits M (das Poll/Final Bit P/F wird nur erkannt, wenn es auf 1 gesetzt ist).

Data:

Daten, die von einer höheren Kommunikationsschicht an die LLC-Schicht übergeben werden (UI Frame) oder Kontrolldaten (XID Frame, TEST Frame).

Für das Kontrollfeld sind folgende Werte gebräuchlich.

Subnetwork Access Protocol (SNAP)

Wenn man die Protokolle der Internet Protocol Suite in einem OSI-konformen LAN betreiben will, hat man das Problem, dass weder die MAC-Rahmen der einzelnen Zugriffsverfahren (Ethernet, CSMA/CD, Token Ring, FDDI), noch der LLC-Rahmen die Ethernet-Protokolltyp-Nummern kennen. Zur Lösung des Problems gibt es verschiedene, zueinander inkompatible Methoden.

Eine Methode besteht darin, die DSAP- und SSAP-Adressfelder anstelle der Protokolltyp-Nummer zur Kennzeichnung der Protokolle zu verwenden. Da diese Adressfelder jedoch nur 1 Byte groß sind, können sie nicht die 2 Byte langen Protokoltyp-Nummern aufnehmen und es müssen neue Werte definiert werden, z.B. 06 (hex) für IP. Diese Methode hat sich daher für das Internet-Protokoll nicht durchsetzen können. Ganz abgesehen davon könnten gar nicht alle vorhandenen, 2 Byte langen Protokolltyp-Nummern auf die 1 Byte langen LLC-Adressen abgebildet werden.

Die Methode, die üblicherweise Verwendung findet, besteht darin, eine Anpassungsschicht einzuführen. Durch die damit verknüpfte Einführung eines zusätzlichen Protokolls wird die Möglichkeit geschaffen, die Ethernet-Protokolltyp-Nummern auch bei allen anderen LAN-Zufriffsverfahren zu verwenden. Hierbei wird auf die Drei-Teilung der Netzwerkschicht in Subnetwork Access Sublayer, Subnetwork Independent Convergence Sublayer und Subnetwork Dependent Convergence Sublayer zurückgegriffen. In Anlehnung an den ersten dieser drei Begriffe wird das entsprechende Protokoll als Subnetwork Access Protocol (SNAP) bezeichnet.

Rahmenaufbau

Der Aufbau eines SNAP-Rahmens wird in der folgenden Abbildung gezeigt.

Organizationally Unique Identifier (OUI):

bei OSI-konformen LANs (IEEE-802-Netze) die Bitfolge 00000000 00000000 00000000.

Protocol Identifier (PID):

bei OSI-konformen LANs (IEEE-802-Netze) identisch mit der Protokolltyp-Nummer von Ethernet.

Data:

Daten, die von einer höheren Kommunikationsschicht übergeben werden.

IP-Datagramme in Ethernet-Rahmen

Um Daten der Schicht 3 (Netzwerkschicht) zu versenden, gibt es drei Möglichkeiten, das Gesamtpaket aufzubauen. Die drei möglichen Paketvarianten werden in der folgenden Abbildung gezeigt. Basis für jede Variante ist jeweils ein passender Ethernet-Rahmen. In der Praxis kommt die erste (links abgebildete) Variante am häufigsten vor, obwohl sie nicht OSI-konform ist, da bei ihr die LLC-Schicht fehlt. Während die dritte (rechts abgebildete) Variante zwar OSI-tauglich ist, stellt eigentlich jedoch nur die zweite (in der Mitte abgebildete) Variante eine saubere OSI-Umsetzung dar.

Die Übermittlung von IP-Datagrammen erfolgt in der Regel ausschließlich durch die erste Variante. Die beiden anderen Varianten werden dagegen meist für die Übermittlung von Management- oder Brückendaten verwendet (z.B. STP-Protokoll oder Management der LLC-Schicht), wobei dann die DSAP- und SSAP-Adressfelder, bzw. das PID-Feld mit den hierfür erforderlichen Werten bestückt sein müssen.