HDLC Framing

Frame Synchronisation

Nach dem Start einer HDLC-Verbindung werden kontinuierlich Bits übertragen, auch wenn die Verbindung im Leerlauf ist, wobei die Merkersequenz - 0111111110 (oder 0x7E) übertragen wird. Frames werden innerhalb der Lücken zwischen den Flags übertragen, so dass der Empfänger durch Synchronisation mit den Flags bestimmen kann, wann ein Frame startet und stoppt.

Um die Transparenz zu gewährleisten, wird vom Sender nach 5 kontinuierlichen 1s innerhalb des Rahmeninhalts ein 0-Bit eingefügt und vom Empfänger entfernt, wenn er 5 kontinuierliche 1s gefolgt von einer 0 erkennt, um zu verhindern, dass Daten innerhalb des Rahmens mit den Flags verwechselt werden, was als "bit-stuffing" bezeichnet wird.

Normale Frames werden mit einem Flag beendet - jeder Frame, der mit 7 1s oder mehr endet, gilt als abgebrochen und wird verworfen. Der Sender kann einen Frame bewusst abbrechen, wenn er sich dafür entscheidet - dies kann manchmal passieren, wenn Frames erneut gesendet werden müssen, und der Sender weiß, dass der aktuell gesendete Frame vom Empfänger verworfen wird.

Zwischen den Frames ist nur ein einziges Flag erforderlich - das End-Flag eines Frames kann das Start-Flag des nächsten Frames sein. Das Flag ist daher nicht wirklich Teil des HDLC-Frames selbst.

HDLC Frame Structure

Der HDLC-Frame (vor der Übertragung - d.h. vor dem Bit-Füllen und Wrappen mit Flags) besteht aus den folgenden Feldern:

Address field Control field Information field Frame Check Sequence

Der Frame wird mit dem Bit niederster Ordnung jedes Bytes zuerst übertragen - und in der Tat zeigt die Rahmenstruktur innerhalb der X.25-Spezifikation die Feldkodierungen so an, dass sich das Bit niederster Ordnung links befindet, was mit denen der normalen Computernotation eher verwirrend sein kann. Da alle Felder in Wirklichkeit byteorientiert sind, verwendet dieser Leitfaden die Standardreihenfolge der einzelnen Bytes - zum Beispiel werden die LAPB-Adressfelder mit 0x03 und 0x01 beschrieben.

Address Field

Das Adressfeld kann theoretisch die Anzahl der Bytes sein; wenn der Bytewert gerade ist, bedeutet das, dass ein weiteres Adressbyte folgt.

Das Feld Adresse für LAPB ist immer ein einzelnes Byte und nimmt den Wert 0x01 oder 0x03 wie folgt an:

0x03 Command frames DCE to DTE
Response frames DTE to DCE
0x01 Command frames DTE to DCE
Response Frames DCE to DTE

Beachten Sie, dass die unterschiedlichen Werte der Adressfelder bedeuten, dass eine LAPB-Verbindung nicht symmetrisch ist - ein Ende muss eine DEE und eines eine DCE sein, sodass die Verbindung bei Fehlkonfiguration nicht funktioniert. Um dies zu umgehen, verwendet die FarSync X.25 Software einen recht cleveren Algorithmus, der bewirkt, dass sich ein Ende der Verbindung neu konfiguriert, wenn es auf die Situation trifft, in der beide Enden der Verbindung auf die gleiche Weise konfiguriert sind, aber dies geschieht nur, wenn die Auto Link Rolle aktiviert ist.

Control Field

Das Steuerfeld ist in der Regel 1 Byte groß, kann aber bei LAPB 2 Byte lang sein. Dies hängt vom Rahmentyp ab und davon, ob normale (modulo-8) oder erweiterte (modulo-128) Sequenznummern verwendet werden. Modulo-8-Sequenznummern werden meistens verwendet, wobei das Steuerfeld immer 1 Byte beträgt.

Information Field

Das Informationsfeld enthält die Daten der höheren Schicht, die von der Verbindungsschicht getragen werden - für X.25 ist dies typischerweise das X.25-Paket.

Frame Check Sequence (CRC)

Die Frame-Check-Sequenz ist für LAPB 16 Bit lang (ein 32-Bit-FCS ist für andere Arten von HDLC möglich). Sie enthält eine zyklische Redundanzprüfsequenz und wird daher oft als CRC anstelle des FCS bezeichnet.

Das FCS wird erzeugt, wenn ein Frame gesendet wird (vor dem Bitstuffing) und wird überprüft, wenn ein Frame empfangen wird. Wenn ein oder mehrere Bits während der Übertragung durch einen Leitungsfehler geändert wurden, sollte die CRC-Prüfung fehlschlagen, in diesem Fall wird der gesamte Frame verworfen.

Zurück zum Anfang des X.25 Leitfadens.

© Farsite Communication Ltd.

* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!

Daten letztmalig aktualisiert am 20.10.2018

Interessiert an mehr Information? Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Partner | Referenzen
  • 1_LOGO_VEEAM.png
  • 1_LOGO_Avalara.jpg
  • Tsystems.gif
  • DEUTSCHE_BANK.png
  • Postbank.jpg
  • vodafone.gif
  • 1_LOGO_SSH.png
  • LMK.png
  • dekabank.gif
  • netcologne.gif
  • idRoboTica.png
  • tuev-nord.jpg
  • ASKLEPIOS.png
  • Exponet Infrakon 4c.png
  • commerzbank.gif
  • 1_LOGO_FARSITE.png
  • VENTURETEC.png
  • 1_LOGO_VARONIS.png
  • AIRBUS.png
  • gieseckedevrient.gif