Das High Level Data Link Protocol (HDLC) ist ein internationaler Standard für den Einsatz in vielen unterschiedlichen Netzwerkkonfigurationen und -typen. Es operiert auf Layer 2 (Data Link Layer) des ISO-Prokollstapels und beinhaltet beispielsweise den MAC-Sublayer und den LLC-Sublayer (Logical Link Control). Ersteres sorgt für die richtige Kodierung der Daten und die Signalverarbeitung des PHY-Layers. Letzteres Protokoll arbeitet die Daten für die Gegenrichtung, den Network Layer auf. Das ursprüngliche Protokoll wurde für spezielle Anwendungen abgewandelt, darunter LAPD (Link Access Procedure D-Channel), welches für viele ISDN-Implementierungen benötigt wird, und dem Logical Link Control, welches in LANs notwendig ist. Der einzige tatsächlich wahrnehmbare Unterschied liegt in der Benutzung des Flags im HDLC-Frame-Header.

HDLC kommuniziert in zwei Konfigurationen, abhängig von der Netzwerkumgebung in der es operiert. In unbalancierten Umgebungen kommunizieren ein Primary (z.B. ein Server) und n Secondaries (z.B. Clients). Umgekehrt kommunizieren nur zwei Stationen miteinander, wenn die Umgebung balanciert ist.

HDLC kennt drei Operationsmodi:

• Normal Response Mode (NRM) – Nur in unbalancierten Umgebungen, in denen Secondaries nur übertragen, wenn Sie von dem Master (Primary) dazu aufgefordert werden. Dabei darf es sich um Point-to-Point-Verbindungen oder Multipoint-Verbindungen handeln.
• Asynchronous Response Mode (ARM) – In unbalancierten Umgebungen verwendet. Die Secondaries dürfen die Transmission initiieren, ohne direkt vom Primary dazu aufgefordert worden zu sein. Normalerweise in Point-to-Point-Verbindungen und Duplex-Links im Einsatz.
• Asynchronous Balanced Mode (ABM) – Hauptsächlich in Point-to-Point-Duplex-Verbindungen für Computer-zu-Computer-Kommunikationen wie etwa in PSDNs (Packet Switched Data Networks) vorgesehen. In dieser Konstellation sind beide Partner sowohl Primaries und Secondaries, haben also den gleichen Status. Das ist der Kommunikationsmodi für das X.25 Protokollset.

Rahmenformate

Rahmen, die vom Primary zum Secondary gesendet werden, bezeichnet man als Kommandos (commands). Umgekehrt sind Rahmen, die an den Secondary gesendet werden Antworten (responses). Es ist wichtig herauszustellen, daß der LLC-Sublayer verbindungsorientiert, also im zuverlässigen Modus, arbeitet. Alle Fehler- und Kontrollrahmen werden als Supervisory-Frames bezeichnet.

Das allgemeine Frameformat wird in folgender Abbildung dargestellt.

Aus der Abbildung geht hervor, daß HDLC auf einem bitorientierten Protokollschema basiert. Es verwendet die SOF (start of frame) und EOF (end of frame) Flags um den Anfang und das Ende eines Rahmens anzuzeigen und bit-stuffing, damit das Flagmuster 01111110 nicht noch einmal im Bitstrom zwischen den Flags vorkommt. Die Rahmenprüfsequenz (frame check sequence, FCS) wird durch das Polynom

für 16 Bit, oder

für eine 32-Bit-Sequenz bestimmt, welches eine 16-Bit CRC-Sequenz zurückgibt. Sie wird durch das Addieren von 16 Einsen (1s) zum Ende des Dividenden vor der Division und Invertierung des Rests ermittelt.

Der Inhalt des Adressfeldes hängt vom Operationsmodi ab. Im Normal Response Mode (NRM) einer Mehrpunktverbindung wird dem Secondary eine eindeutige Adresse zugeordnet. Immer wenn die primäre Station mit einem Secondary kommunizieren möchte, enthält das Adressfeld die Adresse des Secondarys. Gruppen- und Broadcastadressen können natürlich mehreren Secondaries zugeordnet werden. Wenn nun die sekundäre Station einen Anwortrahmen schickt, kann das Adressfeld über die acht Bits hinaus ausgedehnt werden. Das letzte niederwertige Bit jedes 8-Bit-Feldes zeigt an, ob ein weiteres Oktet folgt (0) oder ob es das letzte ist (1). Im Asynchron balancierten Modus (ABM) wird das Adressfeld nicht auf diese Weise verwendet, da hier nur Punkt-zu-Punkt-Verbindungen involviert sind. Stattdessen zeigt es die Richtung der Kommandos und ihrer Antworten an.

Diverse Standards erweitern das Kontrolfeld (control) durch folgende Definitionen:

Die Bedeutung der Felder wird in Kürze erklärt; zunächst zu den Bezeichnungen. Das Standardrahmenformat beinhaltet folgende Felder:

• [N(s)] Send sequence number (Sequenznummer des Senders)
• [N(r)] Receive sequence number (Sequenznummer des Empfängers)
• [P/F] Pool/Final bit

Der Platzhalter S hat folgende Bedeutung:

• [RR] Receiver ready (Empfänger bereit)
• [RNR] Receiver not ready (Empfänger nicht bereit)
• [REJ] Reject (abweisen)
• [SREJ] Selective reject (ausgewähltes abweisen)

Im wesentlichen besteht das erweiterte Rahmenformat aus den gleichen Feldern. M steht für folgende Konfigurationen:

• [SARM] Set Asynchronous Response Mode (asynchronen Antwortmodus verwenden)
• [SARME] Set Asynchronous Response Mode Extended (erweiterten, asynchronen Antwortmodus verwenden)
• [SNRM] Set Normal Response Mode (normalen Antwortmodus verwenden)
• [SNRME] Set Normal Response Mode Extended (erweiterten normalen Antwortmodus verwenden)
• [SABM] Set Asynchronous Balanced Mode (asynchronen, balancierten Modus verwenden)
• [SABME] Set Asynchronous Balanced Mode Extended (asynchronen, erweiterten balancierten Modus verwenden)
• [RSET] Reset (zurücksetzen)
• [FRMR] Frame Reject (Rahmenzurückweisung)
• [DISC] Disconnect (Verbindung trennen)
• [UA] Unnumbered Acknowledge (ungezählte Bestätigung)
• [CDMR] Command Reject (Kommandoabweisung)
• [FRMR] Frame Reject (Rahmenzurückweisung)
• [DM] Disconnected Mode (Verbindungsloser Modus)

Das P/F-Bit ist das sog. Poll/Final-Bit und wird auf P in einem Kommandorahmen und auf F in einem Antwortrahmen gesetzt. Wird ein Kommandorahmen mit dem P-Flag gesetzt muß der Empfänger den Empfang des Rahmens bestätigen. In gezählten Rahmen werden drei Bit verwendet um die Sequenznummern N(s) und N(r) zu transportieren. Erweiterte Rahmen wenden für den gleichen Zweck sieben Bits auf, die Sequenznummern von 0 bis 127 erlauben, an Stelle nur 0 bis 7 für Standardrahmen. Das macht insofern Sinn, als das Hochgeschwindigkeitsverbindungen ein größeres Sendefenster benötigen, um die Bandbreite besser auszunutzen.

Rahmentypen

Es existieren drei Rahmenklassen: ungezählte Rahmen (unnumbered frames), Informationsrahmen (information frames) und Überwachungsrahmen (supervisory frames).

Ungezählte Rahmen werden zum Link Management eignesetzt. Beispielsweise werden SNRM- und SABM-Frames verwendet, um eine logische Verbindunge zwischen einer primären und sekundären Station zu etablieren und um die sekundäre Station über den Operationsmodus zu informieren. Eine logische Verbindung wird neutralisiert, wenn der Primary einen DISC-Rahmen sendet, welcher mit einem UA-Frame (unnumbered acknowledge) des Secondarys bestätigt wird.

Zwar gibt es vier verschiedene Supervisory Frames, doch werden für NRM und ABM nur RR und RNR verwendet. Beide können dazu genutzt werden, die Bereitschaft eines Secondarys, I-Frames (information frames) zu empfangen, anzuzeigen, oder für Bestätigungen. Die REJ- und SREJ-Rahmen sind nur in ABM-Umgebungen sinnvoll, welche eine zwei-Wege-Kommunikation über Punkt-zu-Punkt-Verbindungen erlaubt. Sie zeigen einer der beiden Stationen an, daß ein Fehler in der Sequenz aufgetreten ist, beispielsweise wenn ein Informationsrahmen außerhalb der Sequenz N(s) aufgetreten ist.

Wie der Name vermuten läßt wird SREJ für selektive Retransmissionsverfahren benötigt, REJ-Rahmen werden nach dem Go-Back-N-Prinzip verwendet.

Protokolldetails

In diesem Abschnitt erläutere ich wichtige Merkmale des HDLC-Protokolls. Die beiden Grundfunktionen sind:

• Verbindungsmanagement
• Datentransfer

Während der Datenübertragung findet auch die Fehlerbehandlung statt.

Verbindungsmanagement

Bevor eine Station Informationen übertragen kann, muß eine logische Verbindung zwischen zwei Stationen einer Mehrpunktverbindung oder einer Punkt-zu-Punkt-Verbindung etabliert werden. Dies wird durch den Austausch zweier ungezählter Rahmen erreicht, wie in folgender Abbildung dargestellt wird.

In einer Mehrpunktverbindung wird zuerst ein SNRM-Rahmen von der primären Station mit dem gesetzten Poll-Bit (1) und der Adresse des angerufenen Secondarys (hier: B) an die sekundäre Station gesendet. Sie bestätigt den Rahmen mit einem UA-Rahmen und einem gesetzten Final-Bit und der eigenen Adresse im Adressfeld. Während des Verbindungsaufbaus werden die benötigten Sequenzvariablen initialisiert und im Rahmen des Verbindungsabbaus wieder freigegeben. Sie werden für die Fehlerkorrektur und Flußkontrolle benötigt. Nach dem Datentransfer, der gleich besprochen wird, sendet die Primärstation einen DISC-Frame und die Sekundärstation antwortet mit einer Bestätigung (UA).

Die soeben beschriebene Prozedur ist prinzipiell auch für Punkt-zu-Punkt-Verbindungen gültig. Da in einer solchen asynchron balancierten Konfiguration die Sekundär- und die Primärstation Secondary und Primary gleichermaßen sind, gibt es Unterschiede in den verwendeten Rahmen. So wird zuerst ein SABM-Rahmen gesendet, um den asynchron balancierten Modus einzustellen. Beide Stationen dürfen den Transfer von Informationsrahmen selbständig und unabhängig voneinander einleiten, so daß wir von Mischsystemen sprechen, weil beide Stationen sowohl als Secondary als auch Primary agieren. Beide Stationen dürfen den Verbindungsaufbau und Verbindungsabbau einleiten. In beiden Fällen wird das Adressfeld verwendet, um die Richtung der Kommandos für SABM und DISC anzuzeigen. Sollte eine der beiden Stationen den Verbindungsaufbau ablehnen wollen, antwortet sie mit einem DM-Rahmen (disconnected mode) auf SABM- oder SNRM-Rahmen. Damit wird deutlich, daß die jeweilige Station logisch nicht verbunden ist.

Datenübertragung

Im normalen Antwortmodus (NRM) findet die Übertragung von Informationsrahmen (I-frames) unter der Kontrolle des Primarys statt. Die Primärstation fordert Daten von einem Secondary durch setzen des Poll-Bits in einem UP-Rahmen (unnumbered poll frame). Hat das Sekundärsystem keine Daten, die es senden möchte oder kann, so wird dies mit einem RR-Frame (receiver ready) mit gesetztem F-Bit gesetzt quittiert. Andernfalls werden die Daten als Sequenz von I-frames übertragen, wobei der letzte das F-Bit setzt, um damit das Ende der Sequenz anzuzeigen.

Zwei kritische Aspekte der Datenübertragung sind die Fehlerkorrektur und die Flußkontrolle. Die Fehlerkorrektur wird durch eine Strategie realisiert, die als continous RQ bezeichnet wird und mit einer Go-back-N-Technik die Retransmission durchführt. Flußkontrolle unterliegt der weithin bekannten Fenstertechnik (window mechanism) koordiniert.

Fehlerkorrektur bei Mehrpunktverbindungen mit NRM

Jeder RR (positive Bestätigung) Supervisory Frame enthält eine Empfangsnummer N(r), der alle zuvor erfolgreich empfangenen I-frames bis zu der Sequenznummer N(s) = N(r) – 1 bestätigt. Durch REJ-Rahmen (negative Bestätigung), der ebenfalls eine Sequenznummer enthält, wird angezeigt, daß ein I-Frame außerhalb der Sequenz empfangen wurde und der Sender den I-Frame erneut übertragen muß, dessen Sequenznummer N(s) = N(r) entspricht. Die Fehlerhaften I-Frames werden verworfen. Wenn also ein Rahmen mit der Konfiguration I(2, 0 / P = 1) eintrifft – das P-Bit ist gesetzt, weil der vorangegangene Rahmen nicht bestätigt wurde – wird er verworfen und der Empfänger unternimmt keine weiteren Schritte. Beim Ausbleiben von Bestätigungen läuft der Timer für die Rahmen I(1) und I(2) ab und beide werden erneut übertragen.

Wenn der Empfänger einen Rahmen mit der Konfiguration I(2, 0 / P = 1) außerhalb der Sequenz entdeckt (der letzte Rahmen in der Sequenz mit P = 1), wird ein REJ-Rahmen mit gesetzten F-Bit übertragen. Der Sender wird dadurch aufgefordert, die Rahmen I(1, 0) und I(2, 0) erneut zu übertragen, wobei das P-Bit wieder in I(2, 0) gesetzt ist. Der Empfänger bestätigt seinerseits jeden Rahmen mit einem RR-Rahmen, mit gesetztem F-Bit im letzten Rahmen. Bei selektiver Transmission wird I(2, 0 / P = 1) akzeptiert, jedoch ein SREJ-Rahmen zurückgegeben, um den Rahmen I(1, 0) erneut übertragen zu lassen.

Fehlerkorrektur bei Punkt-zu-Punkt-Verbindungen mit ABM

Beachten Sie, daß in diesem Modus der gleichzeitige Empfang und das Senden von I-Frames in beide Richtungen möglich ist. Wie bei NRM wird die Bestätigung der I-Frame in der entsprechenden Richtung vorgenommen, allerdings kann die Bestätigung Huckepack mit dem nächsten I-Frame in der entgegengesetzten Richtung übertragen werden. Um die Ausführungen möglichst verständlich zu halten, verzichte ich auf die Fehlerbehandlung und beschränke mich auf die Interaktion beider Stationen.

Beim empfang eines jeden I-Frames werden die Sequenznummern N(r) und N(s). Zuerst wird N(s) mit der lokalen Sequenzvariable V(r) verglichen. Sind beide gleich, ist der Rahmen in der richtigen Sequenz und kann akzeptiert werden. Andernfalls wird ein REJ- oder SREJ-Rahmen gesendet. Wie zuvor wird N(r) zur Bestätigung aller zuvor erfolgreich empfangenen I-Frames genutzt. Stehen keine weiteren I-Frames zur Übertragung aus, wird RR zur Bestätigung aller übrigen Rahmen verwendet.

Flußkontrolle

Die Flußkontrolle für NRM-Umgebungen recht einfach. Da die gesamte Kommunikation durch die Primärstation koordiniert wird, genügt bei zu schneller Datenübertragung oder Stau das Aussetzen (suspension) der Datenanforderung (polling) bis der Datenstau aufgelöst ist. Arbeiten beide Seiten unabhängig voneinander (wie z.B. in ABM-Umgebungen), stellt sich die Situation komplizierter dar.

Die Flußkontrolle von Verbindungen in asynchron balancierten Modi basiert auf der Sliding Window Technik. Zunächst aber einige Details. Die Empfangs- und Sendesequenznummer wird nach Modulo 8 erhöht, so daß die maximale Fenstergröße K 7 betragen kann. Aus diesem Grund können maximal 7 Rahmen in der Retransmissionswarteschlange auf die erneute Übertragung warten. Jede Seite der Verbindung verwaltet eine separate Variable, die in der Regel als Retransmissionszähler bezeichnet wird und allgemein mit RetxCount abgekürzt wird und nach Initialisierung der Verbindung 0 ist. Jedesmal wenn ein I-Frame eintrifft, wird RetxCount inkrementiert und beim Eintreffen einer Bestätigung dekrementiert. Gleichzeitig werden die bestätigten Rahmen aus der Retransmissionsliste entfernt. Die Primärstation hört auf zu senden, wenn RetxCount den Wert K annimmt und fährt nicht fort, solange keine positive Bestätigung empfangen wird, sei es als eigenständiger RR-Rahmen als Huckepack mit einem neuen I-Frame in der entgegengesetzten Richtung. Somit hört die Übertragung von I-Frames auf, wenn V(s) = zuletzt empfangener Rahmen N(r) + K ist. Das Fenster steuert die Flußrichtung der I-Frames nur in eine Richtung und schließt ungezählte Rahmen sowie Kommandorahmen (supervisory frames) nicht ein. Dadurch ist es noch immer möglich, Rahmen zu übertragen, wenn das Fenster nicht mehr “frei” ist. Die Verewndung der Fenstertechnik bedeutet auch, daß die Sequenznummern der Rahmen innerhalb bestimmter Grenzen liegen muß. Bei Empfang jedes Rahmens durch die Sekundärstation wird die Prüfung durchgeführt und, wenn nicht, die entsprechende Maßnahme ergriffen. Deshalb muß jede empfangen Sequenznummer N(r) und N(s) folgende Bedingungen erfüllen:

• V(r) ist kleiner oder gleich N(s) welches selbst kleiner V(r) + K sein muß.
• V(s) ist größer als N(r) welche größer oder gleich V(s) – RetxCount ist.

Sind N(s) und V(r) gleich, ist alles in Ordnung und der Rahmen wird akzeptiert. Sind sie nicht gleich, liegen aber innerhalb erlaubter Grenzen, ist der Rahmen beschädigt und wird mit einem REJ- oder SREJ-Rahmen quittiert. Die Primärstation erkennt den Sequenzfehler und versucht die erneute Transmission des betreffenden Rahmens.

Befinden sich N(s) und N(r) außerhalb erlaubter Grenzen, sind die Sequenzvariablen auf beiden Seiten der Verbindung unsynchron und muß durch ein Zurücksetzen der Verbindung korrigiert werden. Dies wird erreicht, indem beim Empfang eines fehlerhaften Rahmens durch die Sekundärstation ein FRMR bei ABM und ein CMDR bei NRM an die Primärstation gesendet wird. Alle ausstehenden Rahmen des Primarys werden verworfen und eine neue Verbindung durch Senden eines SABM-/SNRM-Rahmens initiiert wird. Anschließend werden die Sequenznummer neu gesetzt und die Übertragung kann beginnen.

Die Softwareschnittstelle

Der Gebrauch der HDLC-Service Primitives ist relativ einfach. Der jeweilige Benutzerprozess kommuniziert mit der lokalen HDLC-Einheit, die ihrerseits mit dem entfernten HDLC-Partner kommuniziert und die Anfragen/Antworten an den lokalen Benutzerpozess weiterleitet. Beim Empfang eines initialen L_CONNECT.request durch den Anwender, sendet die empfangende HDLC-Einheit des Benutzers zunächst einen SNRM/SABM Supervisory Rahmen zur HDLC-Einheit des angerufenen Systems. Wenn dieser Rahmen empfangen wird, erzeugt das Link Layer Protocol ein L_CONNECT.indication Primitive für den angefragten Benutzer. Zusätzlich erzeugt es einen UA-Rahmen (unnumbered acknowledge) und gibt ihn an den Aufrufer zurück. empfängt der Aufrufer den UA-Rahmen, erzeugt es einen L_CONNECT.confirm Primitive und übermittelt es der Verbindungseinheit, so daß der Datentransfer mit dem L_DATA Primitive beginnen kann. Nachdem die gesamten Informationen übertragen wurden, wird die Verbindung durch die DISC- und UA-Frames terminiert. Das Ablaufschema wird in folgender Abbildung verdeutlicht.

Ein Überblick über die involvierten Service Primitives und die Rahmentypen (protocol data units, PDUs) ist in folgender Abbildung zu finden. In der Praxis sind werden mehr unnummerierte Rahmen verwendet, als zuvor beschrieben, doch wäre es der Verständlichkeit dieses Artikels nicht zuträglich, diese auch mit in die Diskussion aufzunehmen. Um die Zusammenhänge weiter zu verdeutlichen finden Sie in der nächsten Abbildung ein vereinfachtes Zustandsdiagramm.

Der erste Eintrag jedes Pfeils ist ein eintreffendes Ereignis, das den Zustandswechsel veranlaßt; der zweite Eintrag ist die resultierende Aktion aus dem Ereignis. Ein solches Diagram liefert nur einen Überblick über die korrekte Arbeit des Protokols und wird normalerweise durch Zustandstabellen und Pseudocode ergänzt.

Link Access Procedure Version B (LAPB)

Das LAPB-Protokoll ist eine Untermenge von HDLC und hauptsächlich für den Datentransfer von I-Frames über duplex Punkt-zu-Punkt-Verbindungen, die Rechner an private oder öffentliche PSDNs anbinden, vorgesehen. Solche Netzwerke sind in der Regel unter der Bezeichnung X.25 zusammengefaßt. LAPB ist, wie der Name vermuten läßt, eine Nachfolgevariante von LAPA (link access procedure version A).

Die Anwendungsumgebung von LAPB ist in folgender Abbildung dargestellt. Der Computer ist hierbei das DTE und das PSE ist das DCE (data circuit-terminating equipment). LAPB wird verwendet, um den Fluß der I-Frames über das lokale DTE-DCE-Interface und hat nur lokale Bedeutung (data link protocol, DLP).

LAPB operiert im asynchron balancierten Modus mit DTEs und DCEs als Mischstationen (Secondary/Primary) und alle I-Frames werden hier als Kommandos behandelt. Das frühe Protocol LAP setzte noch keine REJ- oder RNR-Rahmen als Kommandos ein. Eine Zusammenfassung der Befehle beider Protokolle finden Sie in Tabelle 1.

Die RR- und REJ-Rahmen werden zur Fehlerkorrektur und RNR für die Flußkontrolle verwendet. Diese Rahmen unterstützen zwar keine selektive Wiederholung (selective repeat), doch lassen sich die vorangegangenen Illustrationen direkt auf LAPB übertragen. Wie wir zuvor verdeutlicht haben resultiert das Senden eines Informationsrahmens (hier auch Kommandorahmen) mit gesetztem P-Bit in einer Antwort in Form eines Supervisory Frames mit gesetztem F-Bit. Da beide Stationen eine Verbindung auf- und abbauen können, unterscheiden wir die beiden Stationen, indem die DTE- und DCE-Adressen verwendet werden, wie in Tabelle 2 dargelegt wird. Wenn ein DTE, das nicht bereit ist, einen Setup-Rahmen wie SABM oder SABME erhält, antwortet es mit DM (disconnected mode).

Schnell waren integrierte Schaltkreise verfügbar, die LAPB in der Firmware implementierten. Sie werden oftmals als X.25-Schaltungen bezeichnet, obwohl sich nicht das gesamte X.25-Protokoll implementiert wird, sondern nur LAPB.

Mehrpunktverbindungen

Die bisherigen Beschreibungen beschränkten sich auf die Überwachung des Informationstransfers über einfache Duplexverbindungen. Deshalb ist HDLC auch als Einfachverbindungsprozedur (single link procedure, SLP) bekannt. In manchen Fällen ist die Leistungsfähigkeit und Verläßlichkeit solcher Verbindungen nicht ausreichend, sodaß Mehrpunktverbindungen über mehrere physikalische Leitungen besser geeignet sind. Wir reden dann von einer Mehrpunktverbindungsprozedur (multi-link procedure, MLP), die eine Erweiterung von LAPB darstellt.

Das Verfahren wird in Abbildung 8 verdeutlicht. Die Übertragung der Rahmen jedes physikalischen Links wird durch eine eigene LAPB-Instanz nach SLP kontrolliert. MLP operiert als Obergruppe, welche die Einzelverbindungen einfach als Pool zur Verfügung stehender Verbindungen betrachtet. Das bedeutet auch gleichzeitig, daß die Software nichts von den Interna der MLP oder gar SLP weiß und sich ihr gegenüber als eine logische Verbindung darstellen.

MLP operiert mit eigenen Sequenznummern und Flußkontrollmechanismen, die unabhängig von den von SLP verwendeten sind. Wenn also eine SLP-Verbindung nicht mehr verfügbar ist, wird MLP die Retransmission von Rahmen ganz normal mit Hilfe der übrigen Verbindungen durchführen.

Um ein solche Schema zu implementieren, werden für MLP neue Felder eingeführt. Ein Kontrollfeld wird jedem Rahmen vorangestellt bevor es an eine SLP-Instanz ausgeliefert wird. Das ist unter der Bezeichnung MLC (multilink control) bekannt und ist gegenüber SLP völlig transparent. SLP selbst behandelt das zusätzliche MLC und den Rahmeninhalt als Informationsrahmen und fährt mit der Bearbeitung durch Anfügen der eigenen Adress- und Kontrollfelder fort. Das MLC-Feld besteht aus zwei Oktets, die eine 12-Bit Sequenznummer beinhalten. Das ermöglicht 4096 Sequenznummern und damit eine Fenstergröße von 4095 (N(max) – 1). Somit kann diese Prozedur sehr viele Verbindungen verwalten und die Bandbreite schneller Verbindungen besser ausnutzen.

Link Access Procedure for Modems (LAPM)

Die LAP für Modems (LAPM) ist die in Modems mit Fehlerkorrektur verwendete Protokollvariante, auch besser bekannt als V.32. Diese Modems akzeptieren zwar asynchrone Daten von dem DTE, übertragen aber die Rahmen bitorientiert nach einem synchronen Mechanismus und einem HDLC-basierten Fehlerkorrekturprotokoll. Die Anwendungsumgebung von LAPM ist in Abbildung 9 zu finden.

Jedes Modem besteht aus zwei funktionalen Einheiten: einer Benutzerschnittstelle (user interface part, UIP), und einer Fehlerkorrektureinheit (error correction part, ECP). Das LAPM-Protokoll operiert mit letzterem, während ersteres mit dem V.24-Interface verbunden ist, das sich mit der Übertragung einzelner Zeichen oder Bytes beschäftigt und die Flußkontrolle über V.24 analysiert. Der UIP kommuniziert mit dem ECP über ein genau definierten Satz von Service Primitives.

Bevor eine logische Verbindung aufgebaut werden kann, müssen sich die ECPs beider Seiten auf bestimmte Parameter einigen, darunter die maximale Anzahl von Oktets in I-Frames, die Einstellungen des Bestätigungstimers, die maximalen Anzahl von Übertragungsversuchen und einige andere. Zwar sind allen Parametern Standardeinstellungen assoziiert, doch wenn sie nicht verwendet werden, muß der ursprüngliche UIP einen L_SETPARAM.request Primitive erzeugen, der den erforderlichen Parameter angibt. Die Werte werden ausgehandelt, indem spezielle ungezählte Rahmen, so genannte Exchange Identification (XID) Frames, zwischen den beiden ECPs ausgetauscht werden; einer als Kommando, der andere als Antwort.

Sobald die operativen Parameter ausgehandelt wurden, kann eine logische Verbindung aufgebaut werden, indem der UIP einen L_ESTABLISH.request Primitive erzeugt. Dieser sorgt für die Übermittlung eines SABM- oder SABME-Rahmens (erweitert) durch den ECP. Auf der Gegenseite wird anschließend ein L_ESTABLISH.indication Primitive für den lokalen UIP erzeugt, der bei Empfang dieser Antwort einen UA-Rahmen durch den ECP zurücksenden läßt. Der ursprüngliche ECP setzt dann einen L_ESTABLISHED.confirm Primitive ab. Damit ist die logische Verbindung etabliert und der Datentransfer kann beginnen.

Normalerweise erzeugt der UIP einen Datenblock aus Zeichen oder Bytes, die durch das V.24-Interface empfangen wurden und leitet diesen Block zum ECP, indem ein L_DATA.request Primitive verwendet wird. Der ECP kapselt die Daten in einen Informationsrahmen als Zeichenkette von Oktets und leitet den Transfer mit den normalen HDLC-Fehlerbehandlungsroutinen ein. Der empfangende ECP leitet die Datenblock an den lokalen UIP, welcher die Daten Byteweise über das lokale V.24-Interface sendet.

Wenn ein BREAK (Flußkontrollmechanismus) während des Datentransfers auftritt, wird ein X-OFF-Zeichen empfangen oder die DTE-Leitung ist inaktiv. Der UIP hält die Datenausgabe zum lokalen DTE an und setzt sofort einen L_SIGNAL.request Primitve an seinen lokalen ECP ab. Dieser informiert den entfernten ECP über das Problem und fordert ihn durch eine BRK-Nachricht auf, die Datenübertragung zeitweise auszusetzen. Der empfangende ECP sendet seinerseits einen L_SIGNAL.indication Primitive an den lokalen UIP und bestätigt den Empfang der BRK-Nachricht, die in einem ungezählten Informationsrahmen (UI) transportiert wurde, durch eine BRKACK-Nachricht in einem anderen UI-Frame. Das gleiche Flußkontrollsignal wird von dem UIP über das eigene V.24 Interface abgesetzt.

Nachdem alle Daten übertragen wurden, wird die Verbindung terminiert, wenn der ursprüngliche UIP einen L_RELEASE.request Primitive absetzt. Im bestätigten Modus werden die bereits bekannten DISC und AU mit LAPM verwendet.

Link Access Procedure D-Channel (LAPD)

Das HDLC-Subprotokoll mit der Bezeichnung Link Access Procedure D-Channel (LAPD) wird für ISDN benötigt. Es ist für die Flußkontrolle von I-Frames im Zusammenhang mit dem Signalgeber (D-Channel) definiert. Desweiteren gibt es eine erweiterte LAPD-Variante für Frame Relay. In diesem Abschnitt erläutere ich die Funktion von LAPD und den Zusammenhang mit HDLC.

LAPD kennt zwei Dienste: verbindungsorientiert (acknowledged) und verbindungslose (unacknowledged) Dienste. Wie PSTN ist auch ISDN ein Circuit-Switched Network, was bedeutet, daß vor einem Datentransfer zuerst eine Verbindung zwischen beiden Kommunikationspartnern etabliert werden muß. Dies wird durch den Einsatz des D-Kanals erreicht, dessen Protokoll im LAPD implementiert ist.

Der verbindungsorientierte Dienst wird für den Austausch von Konfigurationsnachrichten zwischen einem Telephon oder DTE und dem lokalen Vermittler (local exchange) verwendet und unterstützt Fehlerkontrolle. Der verbindungslose Dienst ist für den Austausch von Verwaltungsnachrichten vorgesehen und arbeitet nach dem Best-Try-Prinzip.

Momentan gibt es etwa acht unterschiedliche Arten von Endgeräten, z.B. Telephone, DTEs oder eine kombination aus beiden, die sich aber alle einen Zugriffskreis (access circuit), und damit auch einen D-Kanal, zwischen der lokalen Vermittlung und den Kundengeräten. Sämtliche Konfigurationsnachrichten werden von einem speziellen Geräteabschluß über den D-Kanal mit Hilfe des LAPD-Protokolls abgesetzt. Das entspricht dem Prinzip des Adressierungsmechanismus, welches wir aus dem normalen Antwortmodus (NRM) her kennen, mit der Ausnahme, daß es bei LAPD keinen Primary oder Master gibt. Alle Geräte habe quasi gleichberechtigten Buszugriff. Das allgemeine Rahmenformat ist in Abbildung 10 dargestellt.

Auffällig sind die beiden Oktets für die Adressen. Sie bestehen aus zwei Unteraddressen: einem Service Access Point Identifier (SAPI) und einem Terminal Endpoint Identifier (TEI). Der SAPI identifiziert die Dienstklasse, welcher das Terminal angehört, also etwa Sprache, Daten, Daten und Sprache, und der TEI identifiziert das Terminal selbst eindeutig in dieser Klasse. Die unterschiedlichen Kontrollfelder für LAPD sind in Abbildung 11 zusammengefaßt. Sie zeigt auch, welche Rahmen als Kommandos und welche als Antworten gesendet werden können.

Wie in LAPM, verwendet auch LAPD ungezählte Informationsrahmen (unnumbered information, UI). Sie sind für den verbindungslosen Dienst vorgesehen. Da in diesem Verfahren keine Fehlerkontrolle assoziiert ist, wird die gesamte Information mit einem einzigen Kontrollfeld ohne N(r) oder N(s) gesendet. Solche Rahmen führen ein FCS-Feld mit sich, so daß die Rahmen im Fehlerfall verworfen werden können. Ein höherer Layer muß nun dafür sorgen, daß die verworfenen Rahmen erneut gesendet werden. In lokalen Netzwerken wird dies beispielsweise durch das Ausbleiben einer passenden Antwort erkannt und durch den höheren Layer verarbeitet.

Logical Link Control (LLC)

Die logische Verbindungskontrolle (logical link control, LLC) ist ein HDLC-Derivat, das in LANs zum Einsatz kommt. Die Diskussion betrifft LANs in Ring- und Bustopologie. Beide Topologien senden ihre Daten über ein gemeinsam genutztes Medium (shared media), den Bus oder Ring, welches, im Gegensatz zu Mehrpunktverbindungen, einen speziellen Algorithmus zum Ermitteln der richtigen Reihenfolge der zu sendenden Rahmen benötigt. So wird sichergestellt, daß kein Teilnehmer das Medium zu lange belegt und die anderen quasi “unfair” behandelt. Der Data Link Layer von LANs besteht aus zwei Sublayern, dem MAC-Layer (medium access control), der den Zugriffsalgorithmus implementiert, und dem LLC-Sublayer. In diesem Abschnitt konzentriere ich mich auf den LLC. Beachten Sie, daß es in LANs keine Vermittlungsstellen innerhalb des Netzwerkes selbst gibt und das LLC damit auf Peer-Basis arbeitet, also immer zwischen den beiden LLC-Sublayern der involvierten DTEs.

Dienste

Der LLC-Layer bietet, überaschenderweise, zwei Typen von Diensten an: einen verbindungslosen und einige verbindungsorientierte. Ersterer erlaubt dem Benutzer eine Übetragung von Datenpaketen für den Dienst mit einem minimalen Overhead. Typischerweise wird dieser Dienst verwendet, wenn Fluß- und Fehlerkontrolle durche eine höhere Protokollebene zur Verfügung stehen und nicht durch den LLC-Layer repliziert werden müssen. Alternativ kann der verbindungsorientierte Dienst genutzt werden, um eine Verbindung auf Link-Ebene (Layer 2) herzustellen, bevor Datenheiten (service data units, SDU) übermittelt werden sollen und um, falls erforderlich, Fluß- und Fehlerkontrolle zu implementieren.

In vielen Echtzeitnetzwerkumgebungen, wie bei industriellen Prozesssteuerungen, ist der Zeitverlust durch expliziten Verbindungsaufbau vor dem Datentransfer nicht akzeptabel. Dennoch ist die Verifizierung der empfangenen Daten oftmals gewünscht, so daß ein verbindungsloser (unbestätigter) Dienst nicht von Nutzen wäre. Ein weiterer Dienst, der als verbindungsloser, bestätigter Dienst (acknowledged connectionless service) bekannt ist, füllt diese Lücke. Ebenso gibt es eine Technik, bekannt als Obtain Reply Service, die es einer entfernten Station erlaubt, Daten anzufordern, ohne zuvor eine Verbindung aufbauen zu müssen.

Die jeweiligen Service Primitives der beiden Diensttypen sind in Abbildung 13 für die verindungslose Variante und in Abbildung 12 für die verbindungslose Variante dargestellt. Jedem dieser Primitives sind Parameter zugeordnet, die die Quelladresse und die Zieladresse beinhalten und mindestens die physische Adresse spezifizieren, die für dieses Medium vorgesehen ist. Meistens sind es jedoch Kombinationen aus der physischen Adresse und dem SAPI (hier: LLC-SAPI).

Wenn eine LLC-Protokolleinheit im verbindungslosen Modus einen L_DATA.request Primitive empfängt, versucht es nach dem Best-Try-Prinzip eine Bestätigung über den MAC-Layer zu senden. Es gibt keine Bestätigung, ob dieser Transfer erfolgreich war oder nicht. Im bestätigten, verbindunglosen Modus wird der Network-Layer über den Erfolg oder Miserfolg benachrichtigt, indem ein L_DATA_ACK_STATUS.indication Primitive als Antwort auf einen L_DATA_ACK.indication Primitive abgesetzt wird.

Folgende Möglichkeiten sind mit dem Obtain Reply Service für Benutzerprozesse vorgesehen:

• Um den Inhalt eines Nachrichtenpuffers, der durch die entfernte LLC-Einheit verwaltet wird, abzufragen steht der L_REPLY.request bzw. L_REPLY.indication Primitive zur Verfügung.
• Um den Inhalt eines Nachrichtenpuffers, der durch die lokale LLC-Einheit verwaltet wird, zu aktualisieren, stehen die Primitives L_REPLY_UPDATE.request und L_REPLY_UPDATE zur Verfügung.

Bei Verwendung des verbindungsorientierten Dienstes muß vor der Datenübertragung eine logische Verbindung etabliert werden, indem L_CONNECT Primitives vor dem Transfer abgesetzt werden. Nachdem der Datentransfer stattgefunden hat, wird die Verbindung durch Absetzen der L_DISCONNECT Primitives getrennt. Während des Datentransfers wird jeder erfolgreich empfangene Rahmen durch die entfernte LLC-Protokolleinheit mit einem L_DATA_CONNECT.confirm Primitive (der durch die lokale Protokolleinheit erzeugt wurde) bestätigt.

Zwei erweiterte Primitives (RESET und FLOWCONTROL) erlauben dem Benutzerprozess den Datenfluß von Dateneinheiten (PDUs) über die etablierte Verbindung zu kontrollieren. RESET bricht die Übertragung ab, so daß sämtliche unbestätigte Dateneinheiten verworfen werden. Deshalb wird dieses Kommando nur verwendet, wenn der Network Layer nicht mehr synchron mit den Sequenznummern läuft. Die beiden Flußkontroll-Primitives haben nur lokale Bedeutung: der L_FLOWCONTROL.request Primitive spezifiziert die Datenmenge, auf die der Benutzerprozess vorbereitet ist und von seiner lokalen LLC-Protokolleinheit akzeptieren kann. L_FLOWCONTROL.indication zeigt an, wie viele Daten die LLC-Protokolleinheit bereit ist, von dem lokalen Benutzerprozess zu akzeptieren. Ist die angegebene Menge Null, so setzt der Datenfluß aus. Ist die Menge unendlich, so wird für diese Verbindung keine Flußkontrolle angewendet.

11 Protokollfunktionen

Das Format der LLC-Rahmen wird in Abbildung 14 dargestellt. Die Quell- und Zieladressen im Adressfeld beziehen sich nur auf die LLC-SAPs (LLC service access points); sie enthalten keine mediumspezifischen Adressen. Es gibt kein FCS-Feld. Tatsächlich werden die LLC-Rahmen an den MAC-Layer durch Service Primitives weitergeleitet und dort einer Fluß- und Fehlerkontrolle unterzogen. Das Kontrollfeld eines jeden Rahmens besteht aus einem Oktet. Es definiert den Typ des Rahmens, und enthält, wenn notwendig, Sequenznummern für das Senden und Empfangen. Die LLC-Protokolleinheit unterstützt zwei Operationsmodi: Typ 1 unterstützt unbestätigte verbindungslose Dienste und Typ 2 unterstützt den verbindungsorientierten Dienst. Typ 2 ist praktisch identisch mit dem HDLC-Protokoll, mit dem Unterschied, daß die Rahmenerzeugung und Fehlerkontrolle durch den MAC-Layer zur Verfügung gestellt wird. Die DLC-Funktionen für Typ-2-Verbindungen sind im unteren Teil der Abbildung 14 dargestellt. Der größte Unterschied zwischen dem HDLC- und dem LLC-Protokoll ist die Bereitstellung eines unbestätigten verbindungslosen Dienstes (Typ 1).

Um einen Datenblock zu einem oder mehrerer LLC-Einheiten zu übertragen wird ein UI-Rahmen (unnumbered information) verwendet. Da es weder Sequenznummern noch eine Bestätigung gibt, ist diese Art der Transmission dem Typ 1 zuzuordnen. Die beiden Rahmen XID und TEST sind optional. Wenn sie gesendet werden, wird die entfernte LLC-Protokolleinheit angehalten zu antworten.

Diese Kommandos werden auch für die folgenden Anwendungen benötigt:

• Das XID-Kommando kann mit einer Gruppenadresse die Zugehörigkeit zu der betreffenden Gruppe ermitteln. Jedes Mitglied der Gruppe antwortet mit einer XID-Antwort für die ursprüngliche LLC-Einheit.
• Eine LLC-Protokolleinheit kann einen XID-Rahmen mit einer Broadcast-Adresse absetzen um seine Anwesenheit auf dem Netzwerkmedium (welches ein gemeinsam genutztes wird) anzuzeigen.
• Das TEST-Kommando stellt eine Testmöglichkeit für den LLC-zu-LLC-Kommunikationspfad dar.

MAC-Dienste

In diesem, letzten Abschnitt, beschäftigen wir uns mit den MAC-Funktionen. Unabhängig von den Operationsmodi des zu Grunde liegenden MAC-Sublayer, ist ein Standardsatz von Benutzerdiensten für die Verwendung über LLC zum Transport von LLC-Rahmen definiert worden.

Die unterstützten Service Primitives sind folgende:

• MA_UNITDATA.request
• MA_UNITDATA.indication
• MA_UNITDATA.confirmation

Jeder Service Primitive weist einige Parameter auf. In dem Primitive MA_UNITDATA.request sind die Quell- und Zieladresse, eine Servicedateneinheit (die den LLC-Rahmen enthält) und die erforderliche Dienstklasse, die mit dem Rahmen assoziiert ist, als Parameter eingeschlossen. Letzterer ist für einige LANs mit einem priorisierten Mediumzugriffsprotokoll von Bedeutung.

Der Primitive MA_UNITDATA.confirm beinhaltet einen Parameter, der den Erfolg oder Miserfolg des assoziierten MA_UNITDATA.request Primitive anzeigt. Der MA_UNITDATA.confirm Primitive wird aber nicht als Resultat auf eine Antwort durch den entfernten LLC-Layer generiert, sondern von der lokalen MAC-Protokolleinheit.