X.25 Logical Channels
Eine X.25-Verbindung ist in mehrere logische Kanäle unterteilt - jeder logische Kanal kann einen separaten VirtualCircuits tragen.
Jeder logische Kanal wird durch seine Logical Channel Number (LCN) identifiziert, auch bekannt als Logical Channel Identifier (LCI).
Die LCN belegt 12 Bit innerhalb des Headers des X.25-Pakets - es stehen also 4096 verschiedene potenzielle LCNs pro X.25-Verbindung zur Verfügung - 0 bis 4095. In den meisten X.25-Netzwerken ist LCN 0 für den Link-Control-Verkehr reserviert und nicht für virtuelle Schaltungen verfügbar, so dass nur 4095 gleichzeitige virtuelle Schaltungen möglich sind. Einige Netzwerke unterstützen jedoch Virtual Circuits auf LCN 0, so dass 4096 Virtual Circuits unterstützt werden können - dies wird auch von der FarSync X.25 Software unterstützt.
Die logische Kanalnummer ist eine rein lokale Angelegenheit für jede X.25-Verbindung zwischen der DEE und dem Netzwerk - eine virtuelle Verbindung wird in der Regel auf einer völlig anderen LCN auf der lokalen Verbindung zu dem LCN geführt, das auf der entfernten Verbindung zwischen dem entfernten Netzwerkknoten und der DEE auf der anderen Seite des Netzwerks verwendet wird - das Netzwerk stellt sicher, dass die Pakete an das richtige LCN weitergeleitet werden.
Die Anzahl der verfügbaren logischen Kanäle hängt von der vom Netzbetreiber zugewiesenen Anzahl ab - in einem öffentlichen Netz kostet es normalerweise zusätzlich, eine große Anzahl zu haben, und einige Verbindungen können mit nur 2 LCNs versorgt werden.
Auch der Nummernkreis wird vom Netzbetreiber festgelegt - die Konfiguration der Kanalzuordnungen ist für den erfolgreichen Betrieb der X.25-Verbindung von entscheidender Bedeutung: Die Konfiguration der DEE muss mit der Konfiguration der DÜE übereinstimmen.Dies macht die Konfiguration von X.25 leider schwieriger als TCP/IP - X.25 funktioniert einfach nicht richtig, wenn die Kanalzuordnungen falsch konfiguriert sind.
Aus diesem Grund enthält die FarSync X.25 Software unter Windows ein Dienstprogramm - x25ChanProbe.exe - um die Kanalzuordnungen automatisch zu bestimmen. Dies geschieht durch das Übertragen eines Anrufanforderungspakets auf jedem möglichen LCN und das Überprüfen der Ergebnisse - typischerweise wird eine Anrufanforderung auf einem nicht zugewiesenen Kanal ignoriert, so dass es einige Zeit dauern kann, bis die Ergebnisse gesammelt sind.
* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!
Daten letztmalig aktualisiert am 20.10.2018
Interessiert an mehr Information?
Flow Control Parameters
Flow Control Parameter sind die Paketgrößen und Fenstergrößen, die von einer virtuellen Verbindung verwendet werden. Diese können bei der Verbindungsherstellung für SVCs verhandelt werden, sind aber für PVCs festgelegt.
Paket- und Fenstergrößen können in jeder Richtung unterschiedlich sein, obwohl dies in der Praxis ungewöhnlich ist.
Die Verhandlung ist optional und in der Tat nicht immer verfügbar; einige Netzwerke erheben zusätzliche Gebühren für ein Abonnement der Verhandlung.
Größen, die in Ermangelung von Verhandlungen verwendet werden.
Jeder X.25-Link ist mit Standardgrößen (oder Normalgrößen) konfiguriert, die ohne Verhandlung verwendet werden können. Diese Werte müssen daher korrekt konfiguriert werden, wenn die Verhandlung nicht verwendet wird, da eine Fehlkonfiguration sonst zu Problemen führen kann:
- wenn die Rx-Paketgröße zu klein konfiguriert ist, kann die virtuelle Verbindung zurückgesetzt werden, wenn ein großes Paket empfangen wird.
- wenn die Tx-Paketgröße zu groß konfiguriert ist, setzt das Netzwerk die virtuelle Verbindung zurück, wenn ein großer Block übertragen wird.
- iwenn die Tx-Paketgröße zu klein konfiguriert ist, kann das Netzwerk das M-Bit fallen lassen, weil es denkt, dass die Pakete nicht voll sind.
- wenn die Rx-Fenstergröße zu klein konfiguriert ist, kann die virtuelle Verbindung zurückgesetzt werden, wenn zu viele Pakete gleichzeitig empfangen werden (obwohl dies nur dann der Fall ist, wenn die Ablaufsteuerung auf die virtuelle Verbindung angewendet wird).
- wenn die Tx-Fenstergröße zu groß konfiguriert ist, kann das Netzwerk oder die entfernte DEE die virtuelle Verbindung zurücksetzen.
Normalerweise ist die Standard-Paketgröße 128 und die Standard-Fenstergröße 2, aber das ist nicht immer der Fall. Eine Standard-Paketgröße von 256 ist nicht allzu ungewöhnlich.
Packet Size Negotiation
Eine anrufende DEE, die die Paketgröße verhandeln möchte, beinhaltet die Paketgrößenverhandlungsoption (Anlagencode 0x42) innerhalb des Anlagenfeldes eines Anrufanforderungspakets. Sowohl die Größe von der anrufenden DEE zur gerufenen DEE (d.h. die Übertragungsgröße für die anrufende DEE) als auch von der angerufenen DEE zur anrufenden DEE (d.h. die Empfangsgröße für die anrufende DEE) kann unabhängig voneinander angegeben werden.
Wenn das Netzwerk die Anrufanforderung empfängt, kann es die Paketgrößen so ändern, dass, wenn der eingehende Anruf an die angerufene DEE übermittelt wird, die Paketgrößen möglicherweise geändert wurden. Die angerufene DEE kann auch die Paketgrößen ändern, bevor sie mit einer Rufannahme antwortet.
Beispiel:
Die Standard-Paketgrößen betragen 128 Byte, und die anrufende DEE möchte eine Größe von 1024 verwenden, sodass die Paketgrößenfunktion in das Paket Call Request aufgenommen wird. Das Netzwerk kann keine Paketgrößen größer als 512 Bytes unterstützen, daher reduziert es die Größe im Feld Einrichtungen, wenn es das Paket für eingehende Anrufe an die angerufene DEE liefert. Die Gerufene DEE möchte keine Paketgrößen größer als 256 Byte verwenden und setzt das Call Accept Package entsprechend. Die Größe von 256 wird an die Calling DEE im Call Connect Paket geliefert.
Window Size Negotiation
Die Verhandlung der Fenstergröße ist im Wesentlichen ähnlich wie die Verhandlung der Paketgröße - eine aufrufende DTE, die die Fenstergröße verhandeln möchte, beinhaltet die Möglichkeit der Verhandlung der Fenstergröße (Anlagencode 0x43) im Paket der Anrufanforderung.
Sowohl die Größe von der anrufenden DEE zur gerufenen DEE (d.h. die Übertragungsgröße für die anrufende DEE) als auch von der angerufenen DEE zur anrufenden DEE (d.h. die Empfangsgröße für die anrufende DEE) kann unabhängig voneinander angegeben werden.
Flow Control Settings und Performance
Die Verwendung einer möglichst großen Fenstergröße ist fast immer von Vorteil für die Performance. Große Paketgrößen können jedoch zu Verzögerungen bei der Übertragung beitragen und sind nur bei der Übertragung von Massendaten - zum Beispiel bei Dateiübertragungsanwendungen - wirklich von Nutzen.
In der Tat können Anwendungen, in denen kurze Reaktionszeiten wichtig sind, von der Verwendung kurzer Paketgrößen profitieren, und es ist möglich, eine Paketgröße auszuhandeln, die kleiner ist als der übliche Standard von 128 Bytes.
* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!
Daten letztmalig aktualisiert am 20.10.2018
Interessiert an mehr Information?
X.25 Facilities
X.25 Facilities werden im Allgemeinen für die Kommunikation mit dem Netzwerk verwendet, obwohl viele von ihnen auch von End-to-End Bedeutung sind. Tatsächlich gibt es eine Klasse von Einrichtungen (X.25 Annex-G), die für die End-to-End-Nutzung reserviert sind.
Zu Facilities gehören unter anderem:
- Verhandlung der Paket- und Fenstergröße
- Durchsatz Class negotiation
- Umkehrung des Ladevorgangs
- Geschlossene Benutzergruppen
- NUI selection
- Ladeinformationen
- Auswahl der Anrufumleitung und Benachrichtigung bei Umleitung
Bestimmte Einrichtungen sind in bestimmten Pakettypen erlaubt - die meisten können in Anrufanforderungen erscheinen, aber andere, zum Beispiel Gebühreninformationen, erscheinen in Clear Indication-Paketen und DCE Clear Confirmation-Paketen.
* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!
Daten letztmalig aktualisiert am 20.10.2018
Interessiert an mehr Information?
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.* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!
Daten letztmalig aktualisiert am 20.10.2018
Interessiert an mehr Information?
LAPB Frame Types
LAPB-Frames werden in drei Klassen eingeteilt:
| Unnummeriert: | DISC, SABM, SABME, UA, DM, FRMR |
| Überwachung: | RR, RNR, REJ |
| Information: | I-frames |
Die Infofelder enthalten zwei Sequenznummern:
- N(S) - die Sendesequenznummer
- N(R) - die Empfangssequenznummer, die der erwartete Wert dessen ist, was N(S) im nächsten zu empfangenden I-Frame aufnehmen wird.
Überwachungsbilder enthalten nur die Empfangs-Sequenznummer N(R).
Es überrascht nicht, dass nicht nummerierte Einzelbilder überhaupt keine Sequenznummern enthalten.
DISC - Trennungsbefehl (nicht nummeriert)Mit diesem Befehl wird eine Verbindung getrennt. Wenn sich die Verbindung in der Phase der Informationsübertragung befindet, wechselt sie zu Disconnect Phase.
SABM - Befehl Asynchronous Balanced Mode setzen (unnummeriert)
Der Befehlsrahmen, der den Verbindungsaufbau mit normalen (modulo-8) Sequenznummern einleitet. Es muss von einem UA-Frame bestätigt werden, damit der Link in den Informationstransfer eintritt.
SABME - Befehl Asynchronous Balanced Mode Extended setzen (nicht nummeriert)
Wie SABM, nur dass versucht wird, eine Verbindung mit erweiterten (modulo-128) Sequenznummern anstelle von modulo-8 Sequenznummern zu starten.
UA - Nicht nummerierte Acknowledgment-Response (Nicht nummeriert)
Der UA-Frame wird als Reaktion auf einen SABM- (oder SABME-) Frame gesendet, um die Verbindung zum Informationstransfer herzustellen.
DM - Reaktion auf unterbrochenen Modus (unnummeriert)
Dieser Response-Frame wird als Reaktion auf Befehlsrahmen in der Disconnected Phase gesendet, wenn die Verbindung nicht in der Lage ist, in die Informationsübertragung einzutreten (z.B. als Reaktion auf DISC).
FRMR - Frame Ablehnung der Antwort (nicht nummeriert)
Die Frame Reject Antwort wird gesendet, wenn ein Fehler auftritt, der nur durch Zurücksetzen der Datenverbindung behoben werden kann. Im Gegensatz zu anderen unnummerierten Rahmentypen enthält es ein Informationsfeld, das Details über den Rahmen enthält, der den Fehler verursacht hat.
RR - Receive Ready Befehl und Antwort (Überwachung)
RR-Frames können entweder Befehle oder Antworten sein. Response RRs werden verwendet, um empfangene Informationsrahmen zu bestätigen, sowie als Antwort auf Command RRs. Der Befehl RRs wird verwendet, wenn eine Antwort vom Kollegen erzwungen wird, und wird typischerweise verwendet, wenn die Verbindung im Leerlauf ist, um zu überprüfen, ob sie noch aktiv ist.
RNR - Receive Not Ready Befehl und Antwort (Überwachung)
RNR werden gesendet, wenn das lokale Ende der Verbindung vorübergehend nicht in der Lage ist, weitere Informationsframes zu empfangen, z.B. aufgrund eines Puffermangels. Ansonsten sind sie identisch mit RR-Rahmen. Das Erscheinen von RNR-Frames auf der Verbindung bedeutet in der Regel, dass etwas schief gelaufen ist, da die meisten X.25-Implementierungen die Ablaufsteuerung auf Schicht 3 statt auf Schicht 2 anwenden.
REJ - Befehl und Antwort ablehnen (Aufsicht)
Rejects werden verwendet, wenn ein I-Frame mit einer unerwarteten Sequenznummer empfangen wird - sie zeigen dem Peer an, dass I-Frames erneut übertragen werden müssen. Obwohl Rejects theoretisch sowohl Befehle als auch Antworten sein können, wird in der Praxis ein Reject Befehl fast nie gesehen.
INFO or I-frame - Information frame
I-Frames enthalten die X.25 PLP-Pakete und sind immer Befehle. Beachten Sie, dass I-Frames auch die Empfangs-Sequenznummer N(R) enthalten und somit empfangene I-Frames bestätigen können. Daher ist es in Zeiten der Datenübertragung üblich, dass die einzigen Frames, die auf dem Link zu sehen sind, I-Frames sind.
* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!
Daten letztmalig aktualisiert am 20.10.2018
Interessiert an mehr Information?
