-
Die
vorliegende Erfindung betrifft den Bereich Computerkommunikationsnetze
und spezifischer ein(e) verbesserte(s) Vorrichtung und ein Verfahren
zum Erhöhen
der Übertragungseffizienz
von Nachrichten über
ein Netz, das für
paketgeschaltete Netzwerksteuerung das X.25-Protokoll benutzt.
-
Kommunikationsnetze
zwischen Computern werden immer größer und der Nachrichtenverkehr auf
diesen Netzen nimmt exponentiell zu. Es ist daher wünschenswert,
die Nachrichtenübertragung
auf diesen Netzen so effizient wie möglich zu machen.
-
In
der Vergangenheit wurden Versuche unternommen, spezialisierte Protokolle
zu entwickeln, die das bei der Übertragung
von Daten über
ein lokales Netz („LAN") benötigte Overhead
begrenzt und bestimmte, einem bestimmten Netzwerktyp eigene Eigenschaften
nutzt, um das Nachrichtenoverhead in einer bestimmten Kommunikationssitzung
minimal zu halten. Nachrichten-Overhead sind die Kopfinformationen,
die an den Datenteil einer Nachricht angehängt werden. Solche Kopfinformationen
(Header) werden benötigt,
damit verschiedene Teile eines Netzwerks die administrativen und
verfahrenstechnischen Aufgaben verfolgen können, die zum Senden von Daten
von einem Computer zu einem anderen notwendig sind. Ein Maß für die Overhead-Effizienz ist
das Verhältnis
zwischen DATEN und DATEN + HEADER. Das heißt, je kleiner die Menge an
benötigten
Header-Informationen, desto effizienter ist das Netzwerkprotokoll.
Ein Versuch, die Effizienz eines Protokolls zu verbessern, ist die
Header-Kompressionsmethodik, die in „Compressing TCP/IP Headers for
Low-Speed Serial Links" von
V. Jacobson in Network Working Group Request for Comments: 1144, Februar
1990 (nachfolgend „Van
Jacobson" oder alternativ „RFC 1144" genannt) beschrieben
wurde, hiermit insgesamt durch Bezugnahme eingeschlossen. Hinweis:
TCP/IP ist eine Abkürzung
für Transmission
Control Protocol/Internet Protocol, ein Satz von Protokollen, die
sich mit Kommunikationen zwischen heterogenen Computern befassen.
TCP ist dafür
verantwortlich, die zu übertragenden
Nachrichten in Datagramme (d. h. eine Sammlung von Daten, die als
eine einzelne Nachricht gesendet werden) zu unterteilen, sie am
anderen Ende des Kommunikationsnetzes wieder zusammenzusetzen, eventuell
verloren gegangene Teile neu zu senden und alles wieder in der richtigen
Reihenfolge zusammenzusetzen. Das IP ist für das Routing individueller
Datagramme verantwortlich. Das TCP übergibt einfach dem IP ein Datagramm
mit einem Zielort. Das IP weiß nicht,
wie sich dieses Datagramm auf ein anderes Datagramm davor oder dahinter
bezieht. Um Details wie Quell- und Zielportnummern, Datagramm-Sequenznummer, Prüfsummen
und andere Steuerdaten nachvollziehen zu können, hängt das TCP einen Header an jedes
Datagramm an und leitet eine Kombination aus Header + Datagramm
an das IP weiter. Das IP fügt dann
seinen eigenen Header an diese Kombination aus „TCPHeader + Datagramm" an, so dass das
resultierende Datenpaket aussieht wie „IPHeader + TCPHeader + Datagramm". Wenn die Anwendung zeichengestützt ist,
z. B. telnet, rlogin oder xterm oder ftp-Control-Channel, da können die
Header eine Länge
von 40 Byte oder mehr für
jedes übertragene Byte
Daten haben. Die Wörter
Datagramm und Paket werden häufig
austauschbar verwendet, obwohl „Datagramm" korrekterweise als eine Dateneinheit
definiert wird, und damit befassen sich die Protokolle. Ein „Paket" ist eine physische
Sache, die auf dem Ethernet oder irgendeiner Leitung erscheint.
In den meisten Fällen
enthält
ein Paket ein Datagramm. Wenn jedoch ein LAN mit einem anderen Netzwerk
wie z. B. Ethernet oder mit einem PDN verbunden ist, dann wird das
TCP/IP-Datagramm in kleinere Stücke
unterteilt (beispielsweise dann, wenn das Datagramm eine große Datei
ist), und ein anderer Header wird an jedes Stück oder „Paket" angehängt. Wenn beispielsweise TCP/IP
zusätzlich
zu X.25 verwendet wird (CCITT-Standard für die Protokolle und Nachrichtenformate,
die die Schnittstelle zwischen einem Terminal und einem PDN-Paketschaltnetz
definieren), dann unterteilt die X.25-Schnittstelle die Datagramme
in 128-Byte-Pakete, jedes mit einem zusätzlichen X.25-Header. Dies
ist für
das IP unsichtbar, weil die Pakete am anderen Ende der Kommunikationsverbindung
wieder zusammengesetzt werden, bevor das Datagramm zurück zum TCP/IP
geleitet wird. Trotzdem können
viele weitere „Header" an solchen Übertragungen
beteiligt sein, die die TCP/IP-Header-Kompressionstechnik nicht anwenden.
Im Falle der oben beschriebenen Zeichenanwendungen wird an die TCP/IP-Header
+ Daten ein weiterer X.25-Header angehängt. In Bezug auf Grundinformationen über TCP/IP
wird verwiesen auf „Introduction to
Internet Protocols" von
Charles L. Hedrick, Computer Sciences Facilities Group, Rutgers
University, Juli 1987.
-
Heutige
Computer verbinden LANs mit weltweiten Netzen und arbeiten typischerweise
mit einem PDN in irgendeinem Teil der Netzverbindung. Mietleitungen
(die primäre
Alternative zum X.25-Dienst) sind teurer und außerhalb der Vereinigten Staaten schwerer
erhältlich
und sind häufig über einige
nationale Grenzen hin nicht existent. Da X.25 in Europa und im Fernen
Osten weiter verbreitet ist als in den Vereinigten Staaten, wird
es von kleineren Unternehmen wie auch von großen internationalen Konzernen mit
Dienststellen in der ganzen Welt immer häufiger eingesetzt, wenn diese
in immer stärkerem
Maße von der
weltweiten Telekommunikationstechnik abhängig werden. Es gibt zwei Hauptcharakteristiken,
die die Kosten für
die Verwendung von öffentlichen
X.25 Netzen bestimmen:
- 1. die Gebühr für die Verwendung
des Netzwerkes basiert gewöhnlich
auf der Menge der gesendeten Daten; und
- 2. die Mietkosten für
die Verbindung steigen rapide für
schnellere Verbindungen. Daraus folgt, dass zunehmende TCP/IP-Effizienz
bei der Verwendung der PDN X.25 Netze Kosten dadurch reduzieren
würde,
dass 1) die Gesamtmenge der gesendeten Daten reduziert wird, und
2) eventuell eine billigere X.25 Verbindung verwendet wird, weil
die benötigte
Gesamtbandbreite aufgrund der Header-Kompression unter Verwendung
des Van Jacobson Schemas verringert wird.
-
Leider
wird bisher das Van Jacobson Header-Kompressionsschema nicht angewendet,
wenn zwei Systeme über
ein X.25 Netz kommunizieren, weil es normalerweise nicht möglich ist,
a priori zu ermitteln, ob ein fernes System das Van Jacobson Kompressionssystem
unterstützt,
wenn ein Paketschaltsystem verwendet wird. Daher wird ein Mittel benötigt, um
dessen Nutzbarkeit vorher abzusprechen.
-
Aus
der US-A-5293379 ist ein Datenverarbeitungssystem bekannt, bei dem
Informationen in Datenpaketen vor der Übertragung der Pakete zwischen
lokalen Netzen komprimiert werden, wobei dieses System Datenpakete
verwendet, die statische und dynamische Felder beinhalten, wobei
die statischen Felder Informationen enthalten, die häufig während eines
Mehrpaketkommunikationsintervalls konstant bleiben, und die dynamischen
Felder Informationen enthalten, die sich für jedes Paket ändern. Es
wird ein Kompressionsverfahren beschrieben, das Folgendes umfasst:
Umformatieren jedes Datenpakets durch Assoziieren seiner statischen
Felder mit einer ersten Paketregion und seiner dynamischen Felder
mit einer zweiten Paketregion. Das Verfahren stellt dann eine statische
Tabelle zusammen, die statische Informationen von wenigstens der
ersten Paketregion eines anfänglichen
Datenpakets enthält. Es
identifiziert dann mit den Informationen in der statischen Tabelle
gemeinsame statische Feldinformationen in der ersten Paketregion
eines nachfolgenden Datenpakets. Solche gemeinsamen Informationen werden
so codiert, dass ihre Datenlänge
reduziert wird. Die gemeinsamen statischen Informationen werden
dann wieder in das modifizierte Datenpaket mit den codierten gemeinsamen
statischen Informationen gesetzt, und das modifizierte Datenpaket
wird dann übertragen.
Eine ähnliche
Tätigkeit
erfolgt in Bezug auf Benutzerdateninformationen.
-
Ferner
ist aus der US-A-5258983 ein System zur Übertragung von Daten in Paketen
bekannt, bei dem bestimmte Datenaustauschverbindungen eine Übertragungskette
benutzen, die zwei Sender/Empfanger-Terminals und wenigstens zwei
Zwischeneinheiten umfassen und bei dem jedes Paket mit der Übertragung
von Daten assoziiert wird, die nur zu einer Verbindung gehören, wobei
wenigstens einige der Zwischeneinheiten Mittel zur Kompression und/oder
Dekompression, in wenigstens einer Übertragungsrichtung, der Datenelemente
enthalten, die in den Datenfeldern der übertragenen Pakete enthalten
sind, gemäß wenigstens
einem Kompressionsalgorithmus. Der adaptive Kompressionsalgorithmus, der
in diesem Patent gelehrt wird, ist so konfiguriert, dass er die
Kompression auf virtuellen Schaltungen deaktiviert, wenn die Kompressionsrate
geringer ist als ein Mindestwert. Insbesondere wird die Kompression
auf der/den virtuellen Schaltung(en) deaktiviert, für die die
Effizienz der Kompression am geringsten ist. Daher erfolgt die Aktivierung
und/oder Deaktivierung der Kompression unabhängig davon, ob die Ferndatenendeinrichtung
(DTE) Header-Kompression/Dekompression
unterstützen
kann.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum
Anwenden von TCP/IP-Header-Kompression/Dekompression in einem Kommunikationsnetzwerk
bereitgestellt, das mit einer X.25 Paketschaltverbindung arbeitet
und das ein oder mehrere Knoten, die die genannte Header-Kompression/Dekompression
unterstützen,
sowie einen oder mehrere Knoten beinhaltet, die die genannte Header-Kompression/Dekompression
nicht unterstützen,
wobei ein Knoten ein Computersystem beinhaltet, das einen Prozessor,
Speicher und Progammanweisungen beinhaltet, wobei das Verfahren durch
die genannten Programmanweisungen implementiert wird und die folgenden
Schritte umfasst:
Einleiten einer ersten Rufanforderung zu
einer fernen Datenendeinrichtung (DTE) über eine TCP/IP/X.25-Netzwerkverbindung,
wobei die genannte erste Rufanforderung von einer lokalen DTE ausgegeben
wird, bevor die lokale DTE eine Mehrzahl von komprimierten Header-Daten
zu der genannten fernen DTE sendet;
Verwenden einer spezifischen
Protokollkennung (PID) in einem Benutzerdatenfeld eines Rufanforderungspaketes,
das die genannte erste Rufanforderung enthält, um anzuzeigen, dass die
genannte lokale, DTE Header-Kompression/Dekompression
verwenden kann;
Zurückgeben
einer Meldung durch die genannte ferne DTE zu der genannten lokalen
DTE, um anzuzeigen, ob die genannte ferne DTE TCP/IP-Header-Kompression/Dekompression
unterstützen
kann; und
Verwenden der genannten TCP/IP-Header-Kompression/Dekompression
in der genannten TCP/IP X.25 Netzwerkverbindung, wenn die genannte
ferne DTE anzeigt, dass die genannte ferne DTE die genannte Header-Kompression/Dekompression
unterstützen
kann.
-
Gemäß einem
zweiten Aspekt der vorliegenden Erfindung wird ein Telekommunikationssystem bereitgestellt,
das Folgendes umfasst:
eine lokale Datenendeinrichtung DTE,
umfassend einen Prozessor, einen Speicher, ein Programm in dem genannten
Speicher, wobei das genannte Programm Anweisungen zum Steuern von
Kommunikationen beinhaltet;
eine ferne DTE, die mit der genannten
lokalen DTE durch eine TCP/IP/X.25 Netzwerkverbindung verbunden
ist, wobei die genannte Netzwerkverbindung ein oder mehrere DTEs
umfasst, die die Verwendung von TCP/IP-Header-Kompression/Dekompression unterstützen kann/können, und
ein oder mehrere Terminals, die die genannte Verwendung von TCP/IP-Header-Kompression/Dekompression
nicht unterstützen
kann/können;
ein
erstes Gerät
in der genannten lokalen DTE, das die Aufgabe hat, eine erste Rufanforderung
zu der genannten fernen DTE über
die genannte TCP/IP/X.25 Netzwerkverbindung zu übertragen, bevor die lokale
DTE eine Mehrzahl von komprimierten Header-Daten zu der genannten
fernen DTE sendet, wobei die genannte erste Rufanforderung eine
spezifische Protokollkennung PID in einem Benutzerdatenfeld enthält, wobei
die genannte spezifische PID anzeigt, dass die genannte lokale DTE
die Verwendung von TCPI/P-Header-Kompression/Dekompression unterstützen kann;
ein
zweites Gerät
in der genannten fernen DTE mit der Aufgabe, die genannte spezifische
PID in der genannten ersten Rufanforderung zu erkennen und auf die
genannte lokale DTE mit einer Nachricht zu antworten, die anzeigt,
ob die genannte ferne DTE die Verwendung von TCP/IP-Header-Kompression/Dekompression
unterstützt
oder nicht.
-
Es
werden ein Verfahren und eine Vorrichtung offenbart, wobei eine
lokale Datenendeinrichtung („DTE"), die die Fähigkeit
hat, RFC 1144 TCP/IP-Header-Kompression/Dekompression
zu verwenden, mit einer unbekannten fernen DTE kommunizieren kann,
die sich am anderen Ende einer TCP/IP/X.25 Netzwerkverbindung befindet,
um zu ermitteln, ob die ferne DTE ebenfalls RFC 1144 TCP/IP-Header-Kompression/Dekompression
unterstützt.
Diese(s) offenbarte Vorrichtung und Verfahren erlauben es einem
Benutzer, die lokale DTE darüber zu
informieren, dass bekannt ist, dass eine ferne DTE TCP/IP-Header-Kompression/Dekompression
unterstützt,
so dass die lokale DTE ihre Routing-Informationen zum Aufzeichnen
dieser Informationen einstellt. Alternativ kann die lokale DTE eine
unbekannte ferne DTE automatisch abfragen, um zu ermitteln, ob sie TCP/IP-Header-Kompression/Dekompression
unterstützt,
und ihre Routing-Informationen entsprechend einstellen.
-
Das
Verfahren zur Verwendung von TCP/IP-Header-Kompression/Dekompression in einem Kommunikationsnetz,
das eine X.25 Paketschaltverbindung im Netzwerk verwendet, beinhaltet ein
Verfahren, bei dem eine erste DTE in einem Netzwerk eine erste Rufanforderung
zu einer fernen DTE ausgibt. Diese erste Rufanforderung enthält eine spezifische
Kommunikationsprotokollkennung („PID") in einem Benutzerdatenfeld, die angibt,
dass die erste DTE TCPI/P-Header-Kompression/Dekompression
anwenden wird. Die ferne DTE gibt nach dem Erfassen dieser PID eine
Rufannahmemeldung zurück,
die anzeigt, dass sie ebenfalls in der Lage ist, TCP/IP-Header-Kompression/Dekompression
anzuwenden, oder sie gibt eine Rufaufhebungsmeldung aus, die besagt,
dass sie TCP/IP-Header-Kompression/Dekompression
nicht unterstützen
kann. Je nach dem, welches Rückgabesignal
die erste DTE von der fernen DTE erhält, stellt die erste DTE ihre
internen Controls entsprechend auf Anwendung oder Nichtanwendung
von TCP/IP-Header-Kompression/Dekompression
ein.
-
Die
Erfindung beinhaltet ein Telekommunikationssystem und eine DTE,
die TCP/IP/X.25-Netzwerke benutzt und die Fähigkeit hat, automatisch zu ermitteln,
ob eine ferne DTE TCP/IP-Header-Kompression/Dekompression unterstützen kann
oder nicht.
-
Es
wird nachfolgend beispielhaft eine spezifische Ausgestaltung der
vorliegenden Erfindung mit Bezug auf die Begleitzeichnungen beschrieben.
Dabei zeigt:
-
1 eine
typische Workstation, die als Datenendeinrichtung (DTE) in einem
Telekommunikationsnetz verwendet werden kann;
-
2 eine
typische TCP/IP-LAN-Verbindung;
-
3 eine
typische LAN/X.25-Netzkonfiguration;
-
4 eine
typische TCP/IP/X.25-Protokollstapelanordnung;
-
5 die
möglichen
TCP/IP/X.25-Header-Daten-Konfigurationen;
-
6a das
Rufanforderungsverfahren von DTE A zu DTE B, wobei DTE B die angeforderte
Konfiguration akzeptiert;
-
6b das
Rufanforderungsverfahren von DTE A zu DTE B, wobei DTE B die erste
Rufanforderung zurückweist,
aber die zweite Rufanforderung akzeptiert;
-
7 den
Ort der vorliegenden Erfindung in der Umgebung des Systems SunLink
X.25 Version 9.0;
-
8 ein
Blockdiagramm des RFC 1144 und des Rufsteuerungssystems der vorliegenden
Erfindung;
-
9 ein
Blockdiagramm des Rufanforderungs- und -beantwortungsverfahrens
der vorliegenden Erfindung;
-
10 ein
Diagramm eines X.25-Paketformats.
-
Die
nachfolgenden ausführlichen
Beschreibungen befassen sich größtenteils
mit Verfahren und symbolischen Darstellungen von Operationen an
Datenbits innerhalb eines Computerspeichers. Diese Verfahrensbeschreibungen
und Darstellungen sind das Mittel, mit dem die Fachperson in der
Datenverarbeitungstechnik anderen Fachpersonen die Substanz ihrer
Arbeit auf effektivste Weise übermittelt.
-
Ein
Verfahren wird hier, und allgemein, als eine in sich einheitliche
Abfolge von Schritten angesehen, die zu einem gewünschten
Ergebnis führen. Diese
Schritte sind diejenigen, die physische Manipulationen physischer
Größen erfordern.
Diese Größen haben
gewöhnlich,
aber nicht unbedingt, die Form von elektrischen oder magnetischen
Signalen, die gespeichert, übertragen,
kombiniert, verglichen oder auf andere Weise bearbeitet werden können. Es ist
zuweilen praktisch, hauptsächlich
für den
gemeinsamen Gebrauch, diese Signale als Bits, Werte, Elemente, Symbole,
Zeichen, Terme, Zahlen oder dergleichen zu bezeichnen. Dabei sollte
jedoch beachtet werden, dass alle diese und ähnliche Begriffe mit den entsprechenden
physikalischen Größen in Zusammenhang
stehen müssen
und lediglich praktische Bezeichnungen sind, die sich auf diese
Größen beziehen.
-
Die
durchgeführten
Bearbeitungen werden häufig
mit Begriffen wie Addieren oder Vergleichen bezeichnet, die gewöhnlich mit
Kopfrechenvorgängen
assoziiert werden, die von einem menschlichen Operator durchgeführt werden.
Es ist in keiner der hierin beschriebenen Operationen, die Bestandteil der
vorliegenden Erfindung sind, eine solche Fähigkeit eines menschlichen
Operators notwendig und in den meisten Fällen auch nicht wünschenswert;
die Operationen sind Maschinenoperationen. Nützliche Maschinen zum Durchführen der
Operationen der vorliegenden Erfindung sind u. a. digitale Universalcomputer
oder ähnliche
Geräte.
In allen Fällen
ist zwischen den Verfahrensoperationen beim Betreiben eines Computers
und dem Rechenverfahren selbst zu unterscheiden. Die vorliegende
Erfindung betrifft Verfahrensschritte zum Betreiben eines Computers beim
Verarbeiten elektrischer oder anderer (z. B. mechanischer, chemischer)
physikalischer Signale zum Erzeugen anderer gewünschter physikalischer Signale.
-
Die
vorliegende Erfindung betrifft auch eine Vorrichtung zum Durchführen dieser
Operationen. Diese Vorrichtung kann speziell für die benötigten Zwecke konstruiert sein
oder sie kann einen Universalcomputer umfassen, der von einem in
dem Computer gespeicherten Computerprogramm selektiv aktiviert oder
umkonfiguriert wird. Die hierin dargestellten Prozesse beziehen
sich nicht von Natur aus auf einen bestimmten Computer oder eine
andere Vorrichtung. Insbesondere können verschiedene Universalmaschinen
mit Programmen verwendet werden, die gemäß den hierin gegebenen Lehren
geschrieben wurden, oder es kann sich als praktischer erweisen,
spezialisiertere Vorrichtungen zu konstruieren, die die benötigten Verfahrensschritte
durchführen. Die
für eine
Vielfalt dieser Maschinen benötigte
Konstruktion werden aus der nachfolgenden Beschreibung hervorgehen.
-
Das
Van Jacobson Header-Kompressionssystem (in RFC 1144 definiert, hierin
durch Bezugnahme eingeschlossen) ist ein Verfahren zum Verbessern
der Effizienz von Anwendungen auf TCP/IP-Basis durch Codieren des
Paket-Headers und Reduzieren seiner Größe. Dies ergibt eine Verbesserung
des Verhältnisses
der Zahl der Datenbytes gegenüber
der Gesamtzahl der Bytes, die über ein
Netzwerk gesendet werden.
-
Dieses
System ist zwar gleichermaßen
auf jede TCP/IP-Anwendung anwendbar, aber der Effekt ist besonders
ausgeprägt,
wenn zeichengestützte Anwendungen
wie telnet, rlogin oder xtern oder der ftp-Control-Channel verwendet
werden. In diesen Fällen
können
40 Bytes Protokollinformationen im IP-Header für jedes übertragene Datenbyte gesendet werden.
Bei Tests hat sich herausgestellt, dass dieses Header-Kompressionssystem
die Effizienz einer typischen Telnet-Session bis auf das Sechsfache verbessern
kann. Bisher wurde RFC 1144 für
IP/SLIP und IP/PPP vorgegeben, aber es gab bisher kein nachvollziehbares
Verfahren für
die Verwendung von RFC 1144 in einem Netzwerk, bei dem eine PDN X.25
Paketschaltverbindung einen Anschlussteil der Netzverbindung bildet,
wobei einige Terminals Header-Kompression/Dekompression unterstützen können und
andere nicht.
-
Es
werden hierin ein Verfahren und eine Vorrichtung offenbart, bei
denen ein lokaler DTE-(Datenendeinrichtungs)-Knoten, der RFC 1144 TCP/IP-Header-Kompression/Dekompression
unterstützt,
mit einer unbekannten fernen DTE am anderen Ende einer TCP/IP/X.25-Netzverbindung
kommuniziert, um zu ermitteln, ob die ferne DTE ebenfalls RFC 1144
TCP/IP-Header-Kompression/Dekompression unterstützt. Die/das offenbarte Vorrichtung
und Verfahren erlauben es einem Benutzer (wie z. B. einem Systemadministrator),
der lokalen DTE mitzuteilen, dass bekannt ist, dass eine ferne DTE TCP/IP-Header-Kompression/Dekompression
unterstützen
kann, so dass die lokale DTE ihre Routing-Informationen zum Aufzeichnen
dieser Information einstellt, wie nachfolgend ausführlicher
beschrieben wird. Alternativ kann die lokale DTE eine unbekannte ferne
DTE automatisch abfragen, um zu ermitteln, ob sie TCP/IP-Header-Kompression/Dekompression unterstützt, und
kann ihre Routing-Informationen entsprechend einstellen. Die Erfindung
kann zwar in jedem relevanten TCP/IP/X.25-Netzwerkkontext mit jedem beliebigen
Computerprogrammprodukt ausgeführt
werden, das als DTE dient, wird aber hier zur Veranschaulichung
im Zusammenhang mit einem bestimmten Typ von Netzwerksteuersystem
und beispielhaften Programmiersystemen beschrieben. Es werden jedoch
von der Fachperson keine spezifischen Kenntnisse über das
illustrierte System verlangt, um das in dieser Offenbarung beschriebene Verfahren
und System zu verstehen und unter Verwendung verschiedener anderer
Netzwerksysteme und zugehöriger
Tools zu implementieren. Die vorliegende Erfindung kann auf jedem
beliebigen Netzwerk mit einigen Terminals ausgeführt werden, die Header-Kompression/Dekompression
unterstützen, und
anderen, die dies nicht tun.
-
Betriebsumgebung
-
Die
Umgebung, in der die vorliegende Erfindung zum Einsatz kommt, umfasst
das allgemeine verteilte Rechensystem, bei dem Universalcomputer, Workstations
oder Personal Computer über
Kommunikationsverbindungen verschiedener Typen in einer Client-Server-Anordnung
zusammengeschlossen sind, wobei Programme und Daten, viele in der
Form von Objekten, von verschiedenen Elementen des Systems zur Ausführung und
für den
Zugriff durch andere Elemente des Systems zur Verfügung gestellt und
gemeinsam genutzt werden. Einige der Elemente eines Universal-Workstation-Computers 20 sind
in 1 dargestellt, wo ein Prozessor 1 mit
einem Ein/Ausgabe-(„E/A")Teil 2,
einer Zentraleinheit („CPU") 3 und
einem Speicherteil 4 dargestellt ist. Der E/A-Teil 2 ist
mit einer Tastatur 5, einem Display 6, einem Plattenspeichergerät 9 und
einem CD-ROM-Laufwerk 7 verbunden. Das CD-ROM-Laufwerk 7 kann
ein CD-ROM-Medium 8 lesen, das gewöhnlich Programme 10 und
Daten enthält.
Ein Computerdisplay-Icon 11 ist auf dem Anzeigegerät 6 zu
sehen. Ähnliche
Workstations können über einen
Kommunikationspfad zur Bildung eines verteilten Computersystems
zusammengeschlossen werden und werden allgemein als Datenendeinrichtungen
(„DTEs") bezeichnet.
-
Die
vorliegende Erfindung wird nachfolgend im Sinne von grundlegendem
Hintergrund und zugrunde liegender Technik erörtert, um zusammenfassend das
Wesen und die Funktionsweise der Erfindung zu beschreiben. Danach
folgt eine ausführliche Beschreibung
der Ausnutzung der Erfindung.
-
Zugrunde liegende Technik
-
Das X.25-Protokoll
-
X.25
ist ein Datenkommunikationsprotokoll, das vom Comité Consultatif
International de Téléphone
et Télégraphe
(CCITT) erstellt wurde, eine Standardisierungskörperschaft, die zur International Communications
Union gehört.
X.25 stammt aus dem Jahr 1976 und ist als das Protokoll definiert,
das die Verbindung zwischen Paketmodus-Datenendeinrichtungen (DTE,
das Gerät
am Benutzerende) und Datenschaltungsendeinrichtungen (DCE, das Gerät am Netzwerkende)
regelt. X.25 gibt, wie jedes andere Datenkommunikationsprotokoll,
vor, wie Daten zwischen beliebigen zwei Systemen auf eine zuverlässige und
ablaufgesteuerte Weise ausgetauscht werden können. Das Protokoll definiert
Mechanismen für
eine Rufeinrichtung und Terminierung („Clearing" genannt) sowie andere Funktionen, die
für einen
reibungslosen Betrieb einer Datenkommunikationsverbindung notwendig
sind. Die CCITT X.25 Spezifikation beschreibt ein bestimmtes Protokoll,
das von einer DCE ausgeführt
wird, und ein separates Protokoll, das von einer DTE ausgeführt wird.
Im Allgemeinen bieten öffentliche/private
Datennetze („PDNs") DCE-Implementationen
von X.25, während Computerhersteller
DTE-Implementationen von X.25 bieten. Die CCITT X.25 Empfehlung
gibt eine Vollbeschreibung des X.25-Protokolls. Die Beschreibung der
in der vorliegenden Erfindung verwendeten beispielhaften Protokolle
basiert auf Systemen gemäß der CCITT
X.25 Spezifikation von 1988.
-
Das TCP/IP-Protokoll
-
Das
TCP/IP-Protokoll wurde kurz im Hintergrundteil definiert und wird
ausführlicher
in verschiedenen RFCs beschriebeg von denen das wichtigste Dokument
in einem dreibändigen
Satz mit dem Titel DDN Protokol Handbook gesammelt ist, veröffentlicht von
der SRI International, Menlo Park, Kalifornien 94025 und die hier
allgemein über
anonyme FTP von sri-nie.arpa in Dateien rfc:rfc-index.txt und rfc:rfcxxxxtxt
erhältlich
sind.
-
2 zeigt
ein typisches TCP/IP-System 20, um anzuzeigen, wie TCP
und TP für
Kommunikationen konfiguriert sind, und um zu illustrieren, dass
die gesamte Kommunikationseinrichtung aus mehreren Netzwerken („Subnetzen") besteht, Eine Art
von Netzwerkzugangsprotokoll, wie z. B. Token Ring oder FDDI usw.,
wird zum Anschließen
der DTE an ein Subnetz verwendet. In 2 enthält ein als
DTE dienender Host-Computer 22 ein Betriebssystem („OS") 30, Anwendungsprogramme 24,
das Host-zu-Host-Protokoll
(„TCP") 26, eine
Kopie der Internetprotokollimplementation („IP") 28 und ein erstes Netzzugangsprotokoll
(NAP1) 32. Dieses erste Netzzugangsprotokoll 32 ermöglicht es
dem Host 22, Daten über
ein erstes Subnetz 34 zum Router 36 zu senden,
der eine Implementation von IP 38, eine Kopie von NAP1 40 des
ersten Netzzugangsprotokolls 32 und eine Kopie von NAP2 42 eines
zweiten Netzzugangsprotokolls 48 enthält, das sich auf einem zweiten
Host 58 befindet und es dem Host 58 im Allgemeinen
gestattet, mit dem Router 36 über ein anderes Subnetz 44 zu
kommunizieren. Der zweite Host 58 hat auch ein OS 46,
Anwendungen 56, eine TCP-Layer 52 und eine IP-Layer 50.
Das IP wird in allen Endsystemen und den Routern implementiert.
Es dient als Relais zum Verschieben eines Datenblocks von einem
Host durch einen oder mehrere Router zu einem anderen Host. Das
TCP wird nur in den Endsystemen implementiert, wo es die Datenblöcke verfolgt,
um zu gewährleisten,
dass alle zuverlässig
zu der jeweiligen Anwendung geliefert werden.
-
Eines
der Subnetze, das verschiedene Hosts in einem Kommunikationssystem
verbindet, könnte ein
PDN X.25 Paketschaltnetz sein. So ist beispielsweise in 3 ein
Fremdhost 62 mit einem X.25 Subnetz 64 verbunden,
das wiederum mit einem SunLink X.25 Gateway 68, das mit
einem Ethernet-Subnetz 78 verbunden ist, und einem anderen, mit
einem anderen Ethernet-Subnetz 76 verbundenen SunLink X.25
Gateway 74 verbunden ist. In jedem dieser Systeme (d. h.
Fremdhost 62, SunLink X.25 Gateway 68 und SunLink
X.25 Gateway 74) könnte
der Protokollstapel 80 wie in 4 gezeigt aussehen.
In 4 beinhaltet Host1 82 sein OS 84, Anwendungen 86,
eine TCP-Layer 88, eine IP-Layer 90 und eine X.25
Netzzugangsprotokoll-Layer 92 für die Kommunikation mit einem
PDN X.25 Netzwerk 94. Host2 96 hat ebenfalls sein
OS 98, Anwendungen 100, TCP-Layer 102,
IP-Layer 104 und seine X.25 Netzzugangsprotokoll-Layer 106.
Ein Gateway bräuchte
nur eine IP-Layer und eine X.25-Protokoll-Layer haben.
-
In
der TCP/IP/X.25 Netzwerkverbindung von 4 würden die
vom Host (oder der DTE) zum Host (DTE) gesendeten Datenpakete allgemein
wie in 5 gezeigt konfiguriert. Im Datenkonfigurationssystem 110 von 5 ist
ein Block von Benutzerdaten 112 (als „Datagramm" bezeichnet, eventuell mit einer Länge von
einem Zeichen bis zu 1500 Oktetts, wobei ein „Oktett" ein Begriff ist. der in der Internet-Dokumentation zum
Bezeichnen von 8 Bits verwendet wird, weil in einigen Systemen „Byte" mehr als 8 Bit bedeutet)
zu sehen. An dieses Datagramm 112 wird ein TCP-Header 116 angehängt und
es wird zu einem TCP-Segment 114. An dieses TCP-Segment 114 wird
ein IP-Header 120 angehängt
und es wird zu einem IP-Datagramm 118. Wenn das IP-Datagramm 114 kleiner
als 128 Byte ist, dann wird ein X.25 Header 124 daran angehängt und
es wird zu einem X.25 Paket 122. Wenn das IP-Datagramm 128 jedoch
größer ist
als 128 Byte, dann wird es in 128-Byte-Pakete 130–136 jeweils
mit eigenem X.25-Header untergliedert.
-
Wie
oben angedeutet, können
die Header in Fällen,
bei denen die Anwendung zeichengestützt ist, wie z. B. telnet,
rlogin oder xterm oder der ftp-Control-Channel, eine Länge von
40 Byte oder mehr für jedes
Byte an übertragenen
Daten betragen. Effizienz und Kostenkontrolle verlangen somit, dass
diese Header möglichst
minimal gehalten werden, und das derzeit effektivste bekannte TCP-Header-Kompressionsschema
ist das Van Jacobson Schema. Somit besteht Bedarf an einem Verfahren,
mit dem zwei unbekannte Hosts auf einer TCP/IP/X.25 Verbindung so oft
wie möglich
das Van Jacobson TCP-Header-Kompression/Dekompressionsschema benutzen
können.
-
Die Erfindung
-
In
der bevorzugten Ausgestaltung werden ein Verfahren und eine Vorrichtung
für eine
Absprache zwischen zwei Hosts/DTEs im Rahmen des Systems mit der
Bezeichnung SunLink® X.25 implementiert, einem
Produkt von Sun Microsystems Inc., der Zessionarin der vorliegenden
Erfindung (SUN, SUN MICROSYSTEMS und SUNLINK sind eingetragene Warenzeichen
von Sun Microsystems Inc.). Die Fachperson wird jedoch erkennen,
dass das Verfahren der vorliegenden Erfindung in jeder beliebigen Programmiersprache,
in jedem beliebigen Computer, in jeder DTE, in jedem Kommunikationssystem und/oder
Netzzugriffsverfahren unter Verwendung der TCP/IP und X.25-Protokolle
oder einem beliebigen Netzwerk implementiert werden kann, in dem
einige Terminals Header-Kompression/Dekompression unterstützen können und
andere nicht.
-
Es
gibt zwei Verfahren zum Ermitteln der Verwendung oder Nichtverwendung
der Van Jacobson TCP-Header-Kompression/Dekompression durch eine
ferne DTE auf einer TCP/IP/X.25-Netzwerkverbindung:
- 1. Im Rahmen der in einem lokalen Host (d. h. einer DTE) enthaltenen
Routing-Informationen wird angegeben, ob bekannt ist, ob ein fernes
System das TCP-Header-Kompression/Dekompressionsschema
unterstützt
oder nicht. In der bevorzugten Ausgestaltung werden diese Informationen
in einer Routing-Tabelle gespeichert, die zum Auswählen von
Verbindungen und SNPA-Adressen auf der Basis von Higher-Level-Adressen verwendet
wird. Alternativ könnten
solche Daten in einer existierenden Routing-Tabelle für X.25 oder
in einer speziellen Routing-Tabelle nur für diesen Zweck gespeichert
werden. Diese Informationen können
von einem Systemadministrator geliefert oder automatisch wie nachfolgend
angegeben ermittelt werden.
- 2. In der bevorzugten Ausgestaltung verwendet das/die einen
Ruf einleitende System/DTE eine vorgegebene Protokollkennung („PID") im Benutzerdatenfeld
(516 in 10) des Rufanforderungspakets 500,
um anzuzeigen, dass das IP unter Anwendung von RFC 1144 (dem Van
Jacobson Schema) im Gebrauch ist. Die PID belegt die ersten ein
oder mehreren Bytes des Benutzerdatenfeldes 516. So könnten beispielsweise
im Falle von PID = CC die Benutzerdaten nur ein einziges Byte lang
sein, das CC enthält.
In einer bevorzugten Ausgestaltung hat die spezifische PID den Wert
0XEF. Wenn diese Rufanforderung, die die spezifische PID enthält, von
dem/der fernen System/DTE zurückgewiesen
wird, dann wird eine zweite Rufanforderung versucht, mit der PID
auf 0XCC gesetzt, der Standard-PID für unkomprimiertes TCP/IP. Unabhängig davon,
ob die Verwendung des Kompressionsschemas vereinbart wird oder nicht,
sollte die unter 1) oben vorgegebene Routing-Tabelle aktualisiert
werden. Der Abspracheprozess 150 in 6 veranschaulicht
das soeben beschriebene Verfahren. In 6a sendet
ein(e) erste(s) System/DTE 152 ein eine spezifische PID 154 enthaltendes
Rufanforderungspaket zu einem/r fernen System/DTE 156.
Wenn das/die ferne System/DTE 156 die spezifische PID erfasst
und feststellt, dass sie anzeigt, dass TCP/IP-Header-Kompression/Dekompression unterstützt wird,
dann wird ein Rufannahmepaket 158 zu dem/der Ursprungssystem/DTE 152 zurückgegeben.
In 6b sendet wiederum ein(e) erste(s) System/DTE 152 ein
die spezifische PID 154 enthaltendes Rufanforderungspaket
zu einem/r fernen System/DTE 160. Diese(s) ferne System/DTE 160 versteht
die spezifische PID 154 nicht und gibt daher ein Rufaufhebungspaket 162 zurück. Nach
dem Erhalt des Rufaufhebungspakets 162 erkennt das/die
erste System/DTE 152, dass das/die ferne System/DTE 16
TCP/IP-Header-Kompression/Dekompression nicht unterstützen kann,
und beschließt
daher zu prüfen,
ob das/die ferne System/DTE 160 unkomprimierte TCP/IP-Daten über diese
X.25 Netzwerkverbindung akzeptieren kann. Das/die Ursprungssystem/DTE 152 ersetzt
die spezifische PID (PID = 0xEF) durch die Standard-PID (PID = 0xCC)
und sendet ein weiteres Rufanforderungspaket 164. Wenn
das/die ferne System/DTE 160 unkomprimierte TCP/IP-Daten über diese
X.25 Netzwerkverbindung akzeptieren kann, dann gibt das/die ferne
System/DTE 160 ein Rufannahmepaket 166 zurück und die
Verbindung wird hergestellt.
-
In
einer bevorzugten Ausgestaltung wird diese Rufsteuerabsprache mit
RFC 1144 Control als eine Erweiterung eines „IP to X.25 Encapsulation" Moduls („IXE") implementiert. 7 illustriert
die bevorzugte Ausgestaltung der vorliegenden Erfindung in Zusammenhang
mit einer SunLink X.25 Version 9.0 200. In 7 sendet
ein IP-Modul 206 Daten über die
Verbindung 208 zum IXE-Modul 212. Das IXE-Modul 212 erlaubt
unter Verwendung der Routing-Tabelle 216 und des Konfigurationstools 214, dass
das IP über
X.25 läuft,
und beinhaltet Unterstützung
für den
X.25 Standard Service des Defense Data Network („DDN"). Das IXE-Modul 212 ist mit dem „RFC 1144
and Call Control" Modul 218 verbunden,
das nach Bedarf die Van Jacobson Header-Kompression/Dekompression durchführt und nach
einer Meldungseinleitung ermittelt, ob der Jacobson Header-Kompression/Dekompressionsprozess
zwischen zwei bestimmten Kommunikationsstellen geeignet ist. Das
RFC 1144 und Call Control Modul 218 ist mit dem „X.25 Packet
Layer Protocol" Modul 220 verbunden,
das wiederum Verbindungen zu einem „Link Access Procedure-Balanced" („LAPB") Modul 238 und
einem „Logical
Link Control, Typ 2" („LLC2") Modul 240 hat.
Das LAPB-Modul 238 bildet Schicht 2 von X.25 für Weitverkehrsnetze („WAN"), und das LLC2-Modul 240 bietet
einen „verbindungsorientierten" Betrieb, der einen
X.25 Betrieb über
Ortsnetze („LAN") zulässt.
-
Die
Module IXE, X.25 PLP, LAPB und LLC2 implementieren Protokolle und
Prozeduren, die in der Technik bekannt sind und hier allgemein ohne
spezifisches Detail beschrieben werden.
-
IXE (IP to X.25 Encapsulation)
-
Dieses
Modul ist grundsätzlich
ein M-zu-N-Multiplexer ("Mux"). Dieser Mux lässt es zu, dass
das IP über
X.25 läuft,
und ermöglicht
sowohl statische als auch dynamische Verbindungen. Statische Verbindungen
sind solche, bei denen X.25-Verbindungen
immer stehen, während
dynamische Verbindungen solche sind, bei denen die X.25-Verbindung
nach Ablauf einer vom Benutzer vorgegebenen Untätigkeitszeit abgebrochen wird.
Im oberen Teil des IXE-Moduls (212 in 7)
befindet sich ein Strom für
jedes mit X.25 arbeitende IP-Subnetz 208, 210.
Unten ist ein Strom pro „virtuelle
Schaltung" („VC") 236, 234.
Die STREAMS-Schnittstellen zu diesem Modul sind „ConnectionLess Data Link
Provider Interface" („DLPI") (Schnittstelle
zu Schicht 2 von UNIX International) am oberen Ende des Moduls 208, 210,
und eine „Network
Layer Interface" („NLI") (eine Schnittstelle
zu Schicht 3 von Sun Microsystems, Inc.) 236, 234 wird
am unteren Ende des IXE-Moduls 212 verwendet. Es kann jede
geeignete Schnittstelle zu Protokollschicht 3, die in der Technik hinlänglich bekannt
ist, anstelle von NLI verwendet werden. STREAMS oder das Stream-E/A-System wurde
ursprünglich
für die
8th Edition of Research UNIX von Dennis Richie entwickelt und ist
in der Technik hinlänglich
bekannt und wird daher hier nicht näher beschrieben (siehe z. B. „UNIX Network
Programming" von
W. Richard Stevens, PTR Prentice Hall, 1990, Seiten 374–378).
-
X.25 PLP (Packet Layer
Protocol)
-
Das
X.25 PLP-Modul 220 ist ein M-zu-N-Mux. Am oberen Ende 236, 234 befindet
sich ein Strom pro virtuelle Schaltung. (Es können auch Ströme vorhanden
sein, die für
Managementzwecke verwendet werden). Am unteren Ende des X.25 PLP-Moduls 220 ist
ein Strom pro Verbindung (WAN oder LAN) 242, 244.
Die Streams- Schnittstellen
sind NLI am oberen Ende 234, 236 und „Link Layer
Interface von Sun Microsystems, Inc." („SLI") am unteren Ende 242, 244 des
Moduls. SLI ist eine Schnittstelle zu Protocol Layer 2. Diese Protocol
Layer 2 ist in der Technik hinlänglich
bekannt, und es wäre
jeder beliebige Schnittstellenmechanismus äquivalent, der eine Schnittstelle
zwischen dem X.25 PLP-Modul 220 und Layer 2 erzeugt. DLPI
wäre eine
hinlänglich
bekannte alternative Schnittstelle zu SLI.
-
LAPB
-
Das
LAPB-Modul 238 ist ein Streams-Mux. Dieser Mux unterstützt sowohl
das LAP- als auch das LAPB-Protokoll. Am oberen Ende 242 befindet
sich ein Strom pro WAN-Verbindung, unten (in 7 nicht dargestellt)
ist ebenfalls ein Strom pro Link. In diesem Modul erfolgt kein Multiplexieren.
Es kann am oberen Ende auch zusätzliche
Ströme
zur Verfolgung und zum Sammeln von Statistiken geben. Die STREAMS-Schnittstellen sind:
SLI am oberen Ende 242 und die WAN-Treiberschnittstelle
von Sun unten (nicht dargestellt). Dieser Mux kann auch in der Zukunft
so adaptiert werden, dass er die verbindungsorientierte DLPI-Schnittstelle
am oberen Ende verwendet, und kann so adaptiert werden, dass er
unter dem ISDN B-Kanal-Protokollstapel sowie unter dem X.25 PLP
läuft.
-
LLC1/2
-
Dieser
STREAMS-Treiber (ein M-zu-I-Mux) unterstützt sowohl LLC1 als auch LLC2.
Es wird nur LLC2 für
X.25 benötigt,
aber LLC1 wird zum Abarbeiten des ConnectionLess Network Protocol
(„CLNP") über LANs
benötigt.
Das CLNP und sein ConnectionLess Network Service („CLNS") bilden das mit
dem IP äquivalente
Open Systems Interconnection („OSI") Protokoll. Am oberen
Ende des Mux 244 kann sich ein Strom pro Service Access
Point („SAP")/LAN-Verbindungspaar
befinden. Wenn beispielsweise nur ein Protokoll wie X.25 vorhanden
ist, das mit einem LLC an einem SAP registriert ist, und wenn es
zwei LAN-Geräte
darunter gibt, dann gibt es zwei aktive obere Ströme zum LLC-Mux.
Es gibt separate Ströme
für LLC1
und LLC2 pro SAP. Am unteren Ende gibt es einen Strom pro LAN-Treiber.
Wenn es mehrere LAN-Treiber gibt, dann ist LLC1/2 ein M-zu-N-Mux.
Die STREAMS-Schnittstellen lauten: SLI und DLPI (verbindungsorientiert
für LLC2
und verbindungslos für
LLC1) am oberen Ende, und verbindungslose DLPI unten. Die Unterstützung für die SLI-Schnittstelle
kann durch den an DLPI angepassten X.25-Mux ersetzt werden.
-
Die Einzelheiten der Erfindung
-
Nachfolgend
wird, mit Bezug auf die 8 und 9, ein Fließschema
der derzeit bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens 300 beschrieben,
während
dies im RFC 1144 und im Call Control Modul arbeitet. In 8 beginnt
der Prozess, wenn IP/X.25-Verkehr erfasst wird (302). Zunächst wird
ermittelt, ob eine existierende geeignete X.25-Verbindung für diese
Meldung existiert (304). Wenn ja (306), dann wird
die existierende Verbindung verwendet (308) und der Datentransfer
erfolgt (356), mit der anschließenden Bearbeitung wie bei
einem normalen X.25-Anruf. Wenn es keine existierende geeignete
X.25-Verbindung für
diese Meldung gibt (312), dann wird die „Config"-Datei geprüft (314),
um zu ermitteln, ob in dieser Datei ein „use of compression" (Kompression erfolgt)
angezeigt wird. Die „Config"-Datei ist die globale
Hauptkonfigurationsdatei für sämtliches
IP über
X.25-Verbindungen. Wenn keine Kompression in der Config-Datei angezeigt
wird (316), dann wird versucht, eine standardmäßige (d. h.
ohne Header-Kompression) X.25-Verbindung mit der Standard-PID „CC" herzustellen (346).
Wenn der Fernterminal die „CC"-Verbindung akzeptiert
(350), dann wird diese Tatsache in der Routing-Tabelle
vermerkt und der Datentransfer wird fortgesetzt (356). Wenn
Kompression in der Config-Datei angezeigt wird (320), dann
erfolgt ein weiterer Test, um zu ermitteln, ob der „Kompression
immer versuchen" Flag in
der Config-Datei gesetzt ist (322). Wenn ja (324), dann
wird versucht, eine Verbindung mit einer auf „EF" gesetzten PID herzustellen (334).
Wenn die Verbindung akzeptiert wird (342), dann wird die „Routing"-Datei aktualisiert
(344), um dieser Datei einen Eintrag hinzuzufügen, wenn
keiner für
den Fern-Host existiert, oder um den existierenden Eintrag für diesen
Host zu überschreiben,
wenn einer existiert. Auch hier wird der Datentransferschritt 356 wieder wie
zuvor ausgeführt.
Wenn der ferne Host die Verbindung mit der PID = EF nicht akzeptiert
(338), dann wird die Routing-Tabelle so aktualisiert, dass
sie diese Tatsache reflektiert (340), die PID wird auf „CC" geändert und
die Verbindung wird erneut versucht (346). Dieser Zweig
des Prozesses wird wie zuvor beschrieben fortgesetzt. Wieder zurück zu Schritt 322,
wenn der Flag „Kompression
immer versuchen" in
der Config-Datei nicht gesetzt ist (326), dann wird die „Routing"-Datei getestet (328).
Diese „Routing"-Datei enthält Informationen über Routen
zu individuellen Hosts, einschließlich der Information, ob ein bestimmter
Host Kompression unterstützt
oder nicht. Wenn die Routing-Datei anzeigt, dass der jeweilige Host
Kompression unterstützt
(332), dann setzt das System die PID auf EF und die Verbindung
wird wie oben beschrieben versucht (334). Wenn die Routing-Datei
anzeigt, dass der jeweilige Host Kompression nicht unterstützt (330),
dann setzt das System die PID auf CC und die Verbindung wird wie
oben beschrieben versucht (346). In solchen Fällen, wo
die CC-Verbindung, d. h. die standardmäßige kompressionslose X.25-Verbindung, nicht
akzeptiert wird (352), gibt das System einen Signalfehler 354 zum anfordernden
Host zurück,
der anzeigt, dass die Verbindung nicht hergestellt werden kann.
-
Auf
der Basis der PID-Einstellungen und zugehörigen Flags in der Routing-Tabelle beinhaltet
der Datentransferprozess 356 dann Prozesse, die prüfen, ob
die Meldung eingeht, und in diesem Fall kann der Header dekomprimiert
werden, oder wenn die Meldung abgeht, dann würde der Header komprimiert
oder auch nicht, je nach dem von den Flags angegebenen Kompressionssupport.
Dies geschieht wie folgt: im Datentransferteil 356 wird
der Flag „Kompression
erfolgt" geprüft (360),
und wenn er auf „ja" gesetzt ist (362)
und die Daten von X.25 Daten eingehen (368), dann wird
der Header dekomprimiert (380) und zum IP geleitet (384).
Wenn der Flag „Kompression
erfolgt" auf „ja" gesetzt ist (362)
und die Daten zu X.25 Daten abgehen (370), dann wird der
Header komprimiert (382) und zur X.25-Verarbeitung geleitet
(390). Wenn der Flag „Kompression
erfolgt" geprüft ist (360),
und wenn er auf „nein" gesetzt ist (364) und
die Daten von X.25 Daten eingehen (386), dann werden die
Daten zum IP geleitet (384). Wenn der Flag „Kompression
erfolgt" auf „nein" gesetzt ist (364) und
die Daten nicht von X.25 Daten eingehen (388), dann werden
die Daten zur X.25-Verarbeitung geleitet (390).
-
Die
vorliegende Erfindung wurde zwar mit Bezug auf die 1–10 beschrieben,
aber man wird verstehen, dass die Figuren lediglich zur Illustration
dienen und nicht als die vorliegende Erfindung beschränkend anzusehen
sind. Ebenso wurde die vorliegende Ausgestaltung der Erfindung im
Hinblick auf spezifische Programme, Module, Protokollschnittstellen
zwischen Modulen und andere spezifische Implementationen beschrieben,
und die Fachperson in diesen Netzwerksystemen wird verstehen, dass
diese spezifischen Einzelheiten nur illustrativ sind und dass sie
nicht als die vorliegende Erfindung beschränkend anzusehen sind.