Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

TCPIP-Lösung für Unix-Rechner der SNI


04.10.1991 - 

Der IP-Transfer erfolgt für den Anwender transparent via X.25

TCP/IP hat als Transport- und Netzwerkprotokoll in lokalen Netzen vor allem im Bereich offener Systeme große Verbreitung gefunden. Trotz der Popularität des De-facto-Standards bereitet die Verbindung weit entfernter Netze noch Schwierigkeit. Klaus Mähringer* stellt mit CXIP eine Sinix-Lösung vor, die lokale Netze auf TCP/IP-Basis über Wide Area Networks (WAN) unter X.25 verbindet.

Je mehr lokale Netze aufgebaut werden, desto interessanter wird auch die Möglichkeit, bisher voneinander unabhängig existierende LANs auch über weite Distanzen miteinander zu verbinden. Während aber die Kopplung räumlich nahe beieinanderliegender LANs technisch und organisatorisch keine Schwierigkeiten bereitet, steckt die Verbindung lokaler Netze über große Distanzen noch in den Kinderschuhen.

CXIP wurde für MX300-Rechner der SNI unter dem Unix-Betriebssystem Sinix mit dem Ziel entwickelt, durch die Übertragung von IP-Datagrammen über X.25 entfernte LANs über X.25 transparent zu verbinden. Das heißt, der Anwender soll funktional keinen Unterschied zwischen der Kommunikation innerhalb eines oder mehrerer direkt gekoppelter LANs und der Kommunikation zwischen entfernten LANs über CXIP sehen.

Um mögliche Lösungen beurteilen zu können, ist es sinnvoll, sich die Unterschiede der Protokolle X.25 und IP genauer vor Augen zu führen.

- Adressierung:

X.25: Numerierung variabler Längen,

IP: Numerierung fester Längen,

- Paketlänge:

X.25: 128 Byte (änderbar), IP: 576 Byte (änderbar),

- Flußkontrolle:

X.25: besitzt sowohl in der Data-Link-Schicht als auch in der Paket-Schicht eigene Flußkontrollen

IP: eigene Flußkontrolle ist erst in TCP vorhanden,

- Verbindungs-Management:

X.25: zwischen zwei Rechnern können mehrere parallele Verbindungen mit jeweils eigener Flußkontrolle existieren,

IP: nicht verbindungsorientiert.

Die Adreßkonvertierung reduziert sich in jedem Fall auf die Bereitstellung von Übersetzungstabellen, wobei nur die Art der Tabellen und damit die Qualität der Konfigurierbarkeit für den Benutzer von Bedeutung ist. Von der Länge der Pakete ist die Methode der Fragmentierung und Reassemblierung der Datenpakete abhängig, da ein IP-Datagramm im Normalfall nicht vollständig in einem X.25-Paket untergebracht werden kann. Diese Thematik hat unmittelbar Auswirkungen auf die Performance der Datenübertragung.

Da sowohl TCP als auch X.25 jeweils eigene Mechanismen zur Flußkontrolle haben, ist eine gegenseitige Beeinflussung nie ganz auszuschließen. Die Problematik liegt hier in der Tatsache, daß TCP/IP ursprünglich für vergleichsweise schnelle LANs konzipiert wurde, X.25 dagegen für langsamere WANs. Die gegenseitige Beeinflussung wird um so geringer, je besser sich TCP auch auf "langsame" Netze einstellen kann.

Kernpunkte des Verbindungs-Managements sind das Auf- und das Abbauen von X.25-Verbindungen. Mit Hilfe der Adreßkonvertierung wird festgestellt. ob für ein zur Übertragung anstehendes Datagramm schon eine X.25-Verbindung existiert. Gegebenenfalls kann nun eine Verbindung aufgebaut werden. Da IP nicht verbindungsorientiert ist, läßt sich feststellen, ob noch weitere Datagramme von einer Adresse eines Absenders an einen Zieladressaten gesandt werden sollen. Es kann also kein exakter Zeitpunkt für einen Abbau der X.25-Verbindung angegeben werden.

Erste Ansätze für eine Übertragung von IP-Datagrammen über X.25 wurden im RFC 877 von J.T. Korb besprochen. Die darin vorgeschlagenen Konventionen werden im allgemeinen als Grundlage eines möglichen Standards anerkannt:

- Eine virtuelle X.25-Verbindung wird bei Bedarf geöffnet, wenn ein IP-Datagramm zur Übertragung ansteht, und nach einer bestimmten Zeit ohne Datenübertragung wieder geschlossen.

- Das erste Byte im "Call User Data Field" (das erste Daten-Byte im X.25-"Call Request-Paket" wird verwendet, um den Protokoll-Typ anzugeben, Hex CC bedeutet IP.

- IP-Datagramme werden als vollständige X.25-Paketsequenzen versandt. Das heißt, jedes Datagramm wird in einem eigenen Paket übertragen; ist ein Datagramm länger als ein maximales Paket, wird M-Bit verwendet, um die folgenden Teile ohne zusätzlichen IP-Header nachzureichen. Bis auf das letzte Paket eines Datagramms müssen alle in maximaler Größe aufgebaut werden.

- Datagramme dürfen nur dann länger als 576 Bytes sein, wenn beide Seiten zustimmen.

- Jede Seite kann eine virtuelle Verbindung beenden. Wird ein Datagramm gerade gesendet, während die andere Seite die Verbindung abbricht, ist dieses Datagramm verloren.

Eine der ersten bekanntgewordenen praktischen Lösungen ist in "CSNET Protocol Software" von D. Comer und J.T.Korb beschrieben. Diese Lösung hatte richtungsweisenden Charakter, da hier unter Zugrundelegung eines Schichtenmodells unterhalb von IP eine protokollabhängige Interface-Schicht eingeführt wurde. In dieser Interface-Schicht wurde dann parallel zur Schnittstelle für das 1822-Protokoll ein Interface für das X.25-Protokoll implementiert. Bis heute haben eine Reihe weiterer "Interfaces" Verbreitung gefunden, wozu zum Beispiel das Serial Line Internet Protocol (SLIP) zählt.

CXIP als Lösung für die Rechnerserie MX300 der SNI hält folgende Vorgaben ein:

- weitestgehende Einhaltung des Quasi-Standards RFC 877,

- Verwendung vorhandener Sinix-Komponenten,

- möglichst sparsamer Umgang mit den System-Ressourcen,

- möglichst effiziente Ausnutzung des X.25-Netzes,

- Berücksichtigung von Sicherheitsinteressen.

Da sich die einzelnen Forderungen teilweise diametral entgegenstehen war ein sinnvoller Ausgleich zwischen den einzelnen Demands notwendig. Um aber den Benutzer in seinen individuellen Belangen nicht einzuschränken, kam im Laufe der Entwicklung die freie Konfigurierbarkeit durch den Anwender als weitere wichtige Forderung hinzu:

"CXIP" stellt ein Bindeglied zwischen der TCP/IP-basierten Sinix-Komponente "Remos" und "CCP-WAN3" dar. Zu Remos gehören unter anderem die aus BSD-Systemen bekannten "Remote-Funktionen" rlogin, rsh, rcp, das Filetransfer-Programm FTP oder die Terminalemulation Telnet. CXIP wird in das Sinix-Produkt CMX - den "Communication Manager für Sinix" - integriert. CMX bietet eine gemeinsame Plattform für Sinix-Kommunikationsprodukte und einen allgemeinen Zugriff zu den Transport System Services mit Hilfe von Application Program Interfaces (API), Command Line Interfaces (CLI) und Menu Driven Interfaces (MDI).

Eine möglichst einheitliche Adressierung der Kommunikationspartner gewährleistet der "Transport Name Service" (TNS). CCP-WAN3 ist das Communication Control Program für WAN3, eine Realisierung des X.25-Protokolls.

Unter Berücksichtigung der vorhandenen Komponenten, die fast alle im Sinix-Kernel angesiedelt sind aber Schnittstellen zum User-Bereich haben ,sind prinzipiell drei Lösungsstrategien vorstellbar (siehe Abbildungen). Es wird hier nach einer Lokalisierung der beteiligten Programme im System-Kernel oder im User-Bereich unterschieden. Grundsätzlich kann man davon ausgehen, daß eine Kernel-Lösung sehr leistungsfähig ist, während sich "normale" Anwendungsprogramme flexibler, wartbarer und leichter konfigurierbar darstellen.

Abbildung 1 zeigt eine Implementierung, die nur geringfügige Eingriffe im Betriebssystem-Kern bedingt. Lediglich eine Komponente zum "Anzapfen" des IP wäre an der entsprechenden Stelle im Kernel zu plazieren. Sowohl die Verbindungssteuerung als auch die Datenübertragung laufen in einer normalen Anwendung ab. In Abbildung 2 wird eine Möglichkeit demonstriert, alle Teile der Übertragung IP-X.25 im Kernel zu programmieren . Da diese beiden Alternativen nicht allen gestellten Anforderungen gerecht werden können, ist CXIP, wie in Bild 3 zu sehen, als Mischlösung konzipiert.

Der Kernel-Anteil von CXIP besteht aus zwei Komponenten, einem speziellen IP-Interface und einem Treiber, der die Verbindung zu CMX innerhalb des Kernels bildet. Der Anschluß an IP und an CMX wurde über bereits vorhandene Schnittstellen realisiert. Die Steuerung des gesamten Ablaufs wird von einem Anwendungsprozeß, dem CXIP-Dämon, vorgenommen.

Bevor näher auf die Übertragung IP über X.25 eingegangen werden kann, muß die notwendige Konfigurierung einer Sinix-Maschine mit CXIP beschrieben werden.

Typischerweise enthält ein LAN einen CXIP-Rechner als X.25-Gateway, wie in Abbildung 1 dargestellt. Das IP-Routing in diesem Netz ist nun mit den zu Remos gehörenden Tools so einzustellen, daß alle Datagramme an das zugehörige IP-Interface des ensprechenden CXIP-Zielrechners gerouted werden, die nur über eine CXIP-Verbindung erreichbar sind. Das ist auf einfache Weise möglich, wenn ein CXIP-Host mindestens zwei Internet-Adressen hat. Dabei stellt die eine die normale LAN-Adresse dieses Hosts dar, die zweite, die des CXIP-Interfaces, ist die Internet-Adresse in einem virtuellen LAN, dessen Netzknoten alle erreichbaren CXIP-Hosts sind und dessen "Übertragungsmedium" X.25 ist.

Diese Vorgehensweise stellt eine Realisierung des üblichen TCP/IP-Gateway-Mechanismus dar. Mit Hilfe der Möglichkeiten des TNS wird eine Zuordnung von Internet- zu X.25-Adressen vorgenommen. Dabei lassen sich einzelne Hosts, Domänen oder ganze Netzwerke einer X.25-Adresse zuordnen.

Schließlich ist noch der CXIP-Dämon durch die Übergabe von Parametern beim Programmstart zu konfigurieren. Folgende Optionen sind dabei gegeben:

- Datagramm-Länge für CXIP-Interface,

- Länge der IP-Ausgabe-Warteschlange,

- maximale Inaktivzeit vor dem X.25-Verbindungsabbau,

- bevorzugte Behandlung von CMX oder IP,

- Anzahl der möglichen parallelen Verbindungen etc.

Eine Übertragung "IP über X.25" beginnt damit, daß ein Datagramm am CXIP-Interface zum Senden ansteht. Mit Hilfe einer aktuellen Verbindungstabelle kann festgestellt werden, daß zu dem im Datagramm angegebenen Empfänger noch keine Verbindung besteht. Über den CXIP-Treiber erhält der CXIP-Dämon die Information, daß eine neue Übertragung beginnt.

Der Dämon ermittelt über TNS die X.25-Adresse des entfernten CXIP-Hosts, der den Zugang zum empfangenden LAN herstellt. Über CMX baut der CXIP-Dämon nun eine X.25 -Verbindung zum Partner auf und gibt die Information über diese Verbindung an den Treiber weiter.

Der CXIP-Treiber übernimmt daraufhin das Datagramm vom Interface und übergibt es direkt an den im Sinix-Kernel residierenden Teil von CMX, von wo aus es über die bestehende X.25-Verbindung übertragen wird. Jedes weitere Datagramm derselben TCP-Verbindung läßt sich jetzt direkt vom CXIP-Interface über den CXIP-Treiber an CMX übergeben. Dieser Übertragungsvorgang läuft innerhalb des Kernels ab, es ist dazu nur ein einziger Systemaufruf nötig.

Auf der Empfängerseite sieht der eben geschilderte Vorgang folgendermaßen aus:

Der CXIP-Dämon erhält von CMX einen Befehl zum Verbildungsaufbau für eine X.25-Verbindung zugestellt. Der Dämon interpretiert die zugehörigen Call-User-Daten. Ist hier die Kennzeichnung für eine CXIP-Übertragung gegeben und besteht die angegebene Internet-Absenderadresse eine Sicherheitsüberprüfung, wird die Verbindung angenommen. Der Dämon meldet die Information CXIP-Treiber, der nun alle ankommenden Daten dieser X.25-Verbindung direkt innerhalb des Kernels an das CXIP Interface weitergeben kann.

Den Abbau der X.25-Verbindung initiert nach Ablauf einer voreingestellten Inaktivzeit eine der beiden Seiten. Auf dieser Seite wird dem Dämon der Zeitablauf und der Verbindungsabbau mitgeteilt, diese Information gibt er an den Treiber wird eine Meldung über den "Verbindungsabbau auf Wunsch des Partners" ebenfalls von CMX an den Dämon und von dort an den Treiber übermittelt.

Auf diesem stark schematisiert dargestellten Vorgang der Datenübertragung via CXIP kann mit Hilfe oben erwähnter Parameter Einfluß genommen werden.

Die Länge der IP-Datagramme und der IP-Ausgabe-Warteschlange steuern den Durchsatz von IP sowie die Wahrscheinlichkeit mit der ein Datagramm verworfen wird. Diese beiden Parameter müssen an die Geschwindigkeit des X.25-Netzes angepaßt werden.

Inaktivzeit beeinflußt die Karten im X.25-Netz

Die maximale Inaktivzeit vor einem Verbindungsabbau hat großen Einfluß auf die im X.25-Netz entstehenden Kosten und ist abhängig von den aktuellen Kosten für das Aufbauen sowie das Vorhalten einer X.25-Verbindung zu wählen.

Mit der bevorzugten Behandlung von IP oder CMX kann auf die durchschnittliche Auslastung von CMX und IP auf jedem einzelnen Rechner reagiert werden.

Mit der Anzahl der möglichen parallelen X.25-Verbindungen zwischen zwei CXIP-Hosts ist unter Berücksichtigung der Netzgeschwindigkeit und der verwendeten DFÜ-Hardware die Performance einer TCP-Übertragung steigerbar.

Ausblick: In einer ersten Version wurde CXIP als Prototyp realisiert. Auf dieser Basis konnte aus den in den Grafõken dargestellten Möglichkeiten die Lösung in Abbildung 3 als die beste Berücksichtigung aller gestellten Anforderungen ausgewählt werden.

Im CSNET Protocol Software wird für die Performance einer Datenübertragung "IP über X.25" noch eine tatsächliche Transferrate von rund 17 Prozent der X.25-Leitung angegeben - auf einer Leitung mit 9600 Baud.

Die für CXIP ermittelten Werte liegen brutto bei etwa 80 Prozent für die reisen Nutzdaten, also abzüglich der TCP/IP-Protokolldaten, bei über 70 Prozent ebenfalls auf einer 9600-Baud-Leitung. Wenn CXIP auf den SNI-Rechnern MX300 und MX300i unter den Systemen Sinix 5.24 und 5.41 als Produkt verfügbar ist, sollten diese Werte noch etwas höher liegen und CXIP zu einem sinnvollen Werkzeug zur Verbindung entfernter LANs über X.25, speziell Datex-P, machen.

Literatur

RFC 877, J.T.Korb, 9/83.

CSNET Protocol Software: The IP-to-X.25 Interface, D.Comer, J.T.Korb, ACM 1983.

Internetworking with TCP/IP, D.Comer, Prentice Hall, 1988.

The Design and Implementation of the 4.3 BSD Unix Operating System, Leffler, McKusick, Karels, Quaterman, Addison-Wesley, 1989.