-
Die
Erfindung bezieht sich auf ein Verfahren für die Ausführung einer Kommunikation auf TCP/IP-Basis über verschiedene
Kommunikationsnetze.
-
In
den letzten Jahrzehnten wurde TCP/IP zu einem der wichtigsten Kommunikationsstandards. Zunächst wurde
TCP/IP nur in Verbindung mit dem Internet verwendet. Inzwischen
wird TCP/IP jedoch auch in Verbindung mit anderen Arten von Kommunikationsnetzen,
wie etwa GSM-Netzen, GPRS-Netzen, DAB-Netzen, DVB-Netzen und dergleichen verwendet,
um alle diese Systeme in ein globales IP-Netz zu integrieren.
-
Ein
zentraler Teil der TCP/IP-Software-Architektur, d. h. der IP-Stapel,
ist die IP-Schicht, die die Routing-Logik für IP-Pakete bereitstellt, die über ein IP-Kommunikationsnetz
an einen bestimmten Ort zu senden sind. Die IP-Schicht kann entweder
als Teil eines Betriebssystems (wie etwa Windows oder Linux) oder
als eingebettete Hardware/Software-Lösung (beispielsweise in Routern
verwendet) implementiert sein. Jeder Schnittstelle des Kommunikationsnetzes
ist eine eindeutige IP-Adresse zugewiesen, die für das Routing von IP-Paketen
zwischen Knoten des Kommunikationsnetzes genutzt wird. Diese Schnittstellen
sind beispielsweise LAN-Netzkarten oder Token-Ring-Netzkarten. Router
und Benutzer-Endgeräte
stellen Knoten und Endknoten eines IP-Netzes dar. Router weisen
normalerweise mehr als eine IP-Schnittstelle auf (sind "multihomed"), während Benutzer-Endgeräte gewöhnlich nur
eine einzelne IP-Schnittstelle besitzen.
-
Jedoch
besteht das Problem, dass die derzeit verfügbaren Betriebssysteme in einer
solchen Weise konzipiert sind, dass Menge/Arten von Kommunikationsnetzen
feststehen, die während
der Laufzeit genutzt werden können.
Das bedeutet, Menge und Art von IP-Kommunikationsnetzen sind im
Kern des Betriebssystems (Linux oder eingebettete Router) normalerweise
statisch konfiguriert oder werden während des Bootens dynamisch
konfiguriert (Windows).
-
Infolgedessen
wird eine TCP/IP-Kommunikation schwierig, wenn sich Menge und/oder
Art der für
einen Kommunikationsprozess benötigten
Kommunikationsnetze während
der Laufzeit ändern.
-
Das
Dokument
US 5,499,343 offenbart
die Verwendung eines dynamisch konfigurierbaren Protokollstapels,
um eine Kommunikationsvorrichtung mit verschiedenen Kommunikationsnetzen
zu verbinden. Ein ähnliches
Kommunikationsverfahren ist im Dokument WO 01/35585 A1 offenbart.
-
Es
ist eine Aufgabe dieser Erfindung, ein Verfahren zu schaffen, das
es einer Kommunikationsvorrichtung ermöglicht, eine Kommunikation
auf TCP/IP-Basis auszuführen,
auch wenn sich Kommunikationsanforderungen während der Laufzeit ändern.
-
Um
diese Aufgabe zu lösen,
schafft diese Erfindung ein Verfahren für die Ausführung einer Kommunikation auf
TCP/IP-Basis über
verschiedene Kommunikationsnetze nach Anspruch 1. Ferner schafft
diese Erfindung eine IP-Schicht nach Anspruch 7. Weiterhin schafft
diese Erfindung ein Computerprogrammprodukt nach Anspruch 13. Schließlich wird
ein computerlesbares Speichermittel nach Anspruch 14 geschaffen.
Bevorzugte Ausführungsformen
und weitere Merkmale dieser Erfindung sind in entsprechenden Unteransprüchen vorgesehen.
-
Gemäß dieser
Erfindung wird ein Verfahren für
die Ausführung
einer Kommunikation auf TCP/IP-Basis über verschiedene Kommunikationsnetze
geschaffen, bei dem eine modifizierte IP-Schicht IP-Netzmodule bereitstellt
und/oder aktiviert, die auf Anforderung eine Kommunikationsvorrichtung
mit einem der Kommunikationsnetze über entsprechende IP-Netzschnittstellen
verbinden, die ihrerseits die Kommunikationsvorrichtung mit den entsprechenden
Kommunikationsnetzen physikalisch verbinden,
- – die Kommunikationsvorrichtung
unter Verwendung des entsprechenden bereitgestellten/aktivierten
IP-Netzmoduls eine Kommunikation auf TCP/IP-Basis über ein bestimmtes Kommunikationsnetz
ausführt,
- – wobei
auf Anforderung die Quelladresse abgehender IP-Pakete durch eine
einer IP-Netzschnittstelle zugewiesene IP-Adresse ersetzt wird,
die von der IP-Adresse
der IP-Netzschnittstelle, über die
die abgehenden IP-Pakete ausgegeben werden, verschieden ist.
-
Ein
wichtiger Aspekt dieser Erfindung besteht darin, dass die "normale" TCP/IP-Softwarearchitektur,
insbesondere die IP-Schicht-Architektur, durch eine modifizierte
TCP/IP-Softwarearchitektur ersetzt ist, die sich selbst dynamisch
an wechselnde Kommunikationsanforderungen anpassen kann. Die modifizierte
TCP/IP-Softwarearchitektur umfasst eine modifizierte IP-Schicht,
die durch Verwenden unterschiedlicher IP-Netzmodule auf verschiedene IP-Kommunikationsnetze
zugreift. Die IP-Netzmodule können
sämtlich
im Betriebssystem enthalten sein (die IP-Schicht-Architektur ist
ein "statischer
Softwareblock",
der unterschiedliche IP-Netzmodule umfasst) oder auf Anforderung
selektiv verknüpft
werden (die IP-Schicht-Architektur umfasst unterschiedliche IP-Netzmodule,
die nur auf Anforderung dynamisch miteinander verknüpft werden).
-
Die
modifizierte IP-Schicht kann ferner Mittel für die dynamische Bestimmung
aufweisen, mit welchen Kommunikationsnetzen die Kommunikationsvorrichtung
momentan verbunden werden kann. Anhand eines Ergebnisses dieses
Bestimmungsprozesses können
dann entsprechende IP-Netzmodule bereitgestellt/aktiviert werden.
-
Das
oben beschriebene Verfahren zeigt die folgenden Vorteile: Erstens
hat die Kommunikationsvorrichtung Zugriff auf eine beliebige Anzahl
von Kommunikationsnetzen. Zweitens kann die Kommunikationsvorrichtung über mehrere
Kommunikationsnetze kommunizieren, die sich physikalisch jeweils voneinander
unterscheiden (z. B. LAN, WLAN, DAB, DVB-T usw.) und unterschiedliche
Zugriffsmerkmale zeigen (unidirektional oder bidirektional, drahtlos oder
verdrahtet usw.). Drittens kann die Kommunikationsvorrichtung einen
Kommunikationsprozess auch dann aufrecht erhalten, wenn sich die
Verfügbarkeit von
Kommunikationsnetzen zeitlich oder örtlich ändert (z. B. Roaming in einem
Funknetz, in der Nähe eines
Hot-Spot-Kiosks usw.). Schließlich
kann die zum Handhaben verschiedener Kommunikationsnetze notwendige
Funktionalität
innerhalb der modifizierten IP-Schicht verborgen sein. Das bedeutet, dass
in Bezug auf Anwendungen, die für
die Ausführung
ihrer Kommunikationsaufgaben die modifizierte IP-Schicht nutzen,
keine Änderungen
vorgenommen werden müssen.
-
In
einer bevorzugten Ausführungsform
werden die IP-Netzmodule auf Anforderung verwendet, um entsprechende
IP-Netzschnittstellen dynamisch zu adres sieren, die die Kommunikationsvorrichtung physikalisch
mit den entsprechenden Kommunikationsnetzen verbinden. Weiterhin
können
den jeweiligen IP-Netzschnittstellen
verschiedene IP-Adressen dynamisch zugewiesen werden. Der Begriff "IP-Netzschnittstelle" bedeutet hier vorzugsweise
physikalische Netzschnittstellen wie etwa Netzkarten. Jedoch können die
IP-Netzschnittstellen jeweils auch als Softwaremodule realisiert
sein. Die oben beschriebene Ausführungsform
ermöglicht
es der Kommunikationsvorrichtung, den Kommunikationsprozess auf eine
solche Weise zu bestimmen, dass ein abgehender Pfad zum Senden von
IP-Paketen sich von einem ankommenden Pfad zum Empfangen von IP-Paketen
unterscheidet, wie später
deutlicher wird. Beispielsweise kann eine Informationsanforderung über einen
GPRS-Kanal gesendet werden, während
die Antwortinformationen über
einen Rundsendekanal empfangen werden können. Infolgedessen hat die Kommunikationsvorrichtung
einen Einfluss auf die Kommunikationskosten, da die Entscheidung,
welches Kommunikationsnetz (das sich in den Nutzungskosten unterscheiden
kann) beim Senden/Empfangen von IP-Paketen verwendet wird, von der
Kommunikationsvorrichtung (genauer gesagt, von der modifizierten
IP-Schicht) selbst übernommen wird.
-
In
einer bevorzugten Ausführungsform
werden die dynamische Verwendung der IP-Netzmodule und/oder die
Zuweisung unterschiedlicher IP-Adressen zu den IP-Netzschnittstellen
dynamisch ausgeführt,
in Abhängigkeit
von jeweiligen Kommunikationsnetzfähigkeiten, die mit den jeweiligen
Kommunikationsnetzen momentan verknüpft sind. Dies ermöglicht es,
eine höhere
Geschwindigkeit der Datenübertragung
zu erzielen.
-
Um
den Prozess der IP-Schnittstellen-/IP-Adressen-Zuweisung auszuführen, bearbeitet
ein Manipulationsprozess entsprechende Quelladressen abgehender
IP-Pakete, bevor er sie über ein
bestimmtes Kommunikationsnetz ausgibt. Beispielsweise kann der Manipulationsprozess
die Quelladresse abgehender IP-Pakete
durch eine einer IP-Netzschnittstelle zugewiesene IP-Adresse ersetzen,
die verschieden ist von der IP-Adresse der IP-Netzschnittstelle, über die
die abgehenden IP-Pakete ausgegeben werden. Dieser Manipulationsprozess
kann auch "manuell" (unter Verwendung
von Konfigurationsdateien) ausgeführt werden.
-
Die
Erfindung schafft ferner eine Kommunikationsvorrichtung, die eine
Kom munikation auf TCP/IP-Basis ausführt und eine IP-Schicht bereitstellt,
mit Mitteln zum dynamischen Bereitstellen und/oder Aktivieren von
IP-Netzmodulen, die eine TCP/IP-Verbindung zwischen einer Kommunikationsvorrichtung
und einem von mehreren Kommunikationsnetzen freigeben, sowie Mitteln
zum Ersetzen der Quelladresse abgehender IP-Pakete durch eine einer
IP-Netzschnittstelle zugewiesene IP-Adresse, die verschieden ist
von der IP-Adresse der IP-Netzschnittstelle, über die
die abgehenden IP-Pakete ausgegeben werden.
-
Die
Kommunikationsvorrichtung, die eine Kommunikation auf TCP/IP-Basis
ausführt,
stellt eine IP-Schicht bereit, vorzugsweise mit Mitteln zum dynamischen
Bestimmen, welche Kommunikationsnetze momentan verfügbar sind,
wobei die Mittel zum Bereitstellen und/oder Aktivieren von IP-Netzmodulen
IP-Netzmodule bereitstellen/aktivieren,
die momentan verfügbaren
Kommunikationsnetzen zugewiesen sind.
-
Weiterhin
kann die Kommunikationsvorrichtung, die eine Kommunikation auf TCP/IP-Basis
ausführt
und eine IP-Schicht bereitstellt, Mittel zum dynamischen Zuweisen
unterschiedlicher IP-Adressen an verschiedene IP-Netzschnittstellen
umfassen, wobei die IP-Netzschnittstellen die Kommunikationsvorrichtung
physikalisch mit den Kommunikationsnetzen verbinden und jeweils
durch entsprechende IP-Netzmodule adressierbar sind.
-
Die
Kommunikationsvorrichtung, die eine Kommunikation auf TCP/IP-Basis
ausführt
und eine IP-Schicht bereitstellt, kann ferner mit einem IP-Protokollstapel
API, z. B. Socket-API, verknüpft
sein, der eine Schnittstelle zwischen Anwendungen und dem IP-Protokollstapel
bereitstellt. Vorzugsweise umfasst die IP-Schicht Mittel zum dynamischen
Abbilden einer externen IP-Adresse, die als ein Parameter über den
IP-Protokollstapel API gegen eine interne IP-Adresse ausgetauscht
wird, die vom IP-Protokollstapel in einem Kommunikationsprozess
verwendet wird, zwischen den IP-Netzschnittstellen/IP-Netzmodulen
und den Kommunikationsnetzen. Das bedeutet, eine Anwendung kann
stets eine einzelne IP-Adresse verwenden, wenn sie über den
IP-Protokollstapel API den IP-Protokollstapel behandelt. Wenn während eines
einzelnen Kommunikationsprozesses unterschiedliche Netze und daher
unterschiedliche IP-Adressen verwendet werden müssen, wird die notwendige Bearbeitung
der IP-Adresse von der IP-Schicht selbst ausgeführt. Anders ausgedrückt: In
der "Realität" werden mehrere IP-Adressen verwendet,
während
zwischen der Anwendung und der IP- Schicht nur eine "virtuelle" IP-Adresse verwendet wird.
-
Die
Erfindung schafft ferner ein Computerprogrammprodukt, das Computerprogrammmittel enthält, die
so beschaffen sind, dass sie gemäß dieser
Erfindung das Verfahren/die IP-Schicht ausführen/verkörpern, wenn sie auf einem Computer,
einem digitalen Signalprozessor oder Ähnlichem ausgeführt werden.
-
Schließlich wird
ein computerlesbares Speichermittel geschaffen, das so beschaffen
ist, dass es ein Computerprogrammprodukt gemäß dieser Erfindung speichert.
-
Weitere
Merkmale und Ausführungsformen dieser
Erfindung sind in der nachfolgenden Beschreibung erläutert, die
mit Bezug auf die beigefügte Zeichnung
gegeben wird, in der:
-
1 schematisch
ein Kommunikationssystem zeigt, das das Verfahren der Erfindung
nutzt;
-
2 schematisch
Eingangs-IP-Adress-Schnittstellen und Ausgangs-IP-Adress-Schnittstellen von
IP-Hosts zeigt;
-
3 verschiedene
Zustände
der IP-Schicht gemäß dieser
Erfindung zeigt, die wechselnden Anzahlen möglicher Kommunikationsnetz-Zugriffe
entsprechen;
-
4A bis 4F schematisch
bevorzugte Ausführungsformen
von Datenstrukturen von IP-Paketen zeigen, die während des Kommunikationsprozesses
der Erfindung verwendet werden;
-
5a) bis 5c) schematisch
bevorzugte Ausführungsformen
von TCP/IP-Architekturen zeigen, die in Verbindung mit dem Kommunikationsverfahren
der Erfindung verwendet werden;
-
1 zeigt
einen Teil eines Kommunikationssystems 1, das eine Kommunikationsvorrichtung 2 umfasst,
die mit mehreren Kommunikationsnetzen verknüpft ist, und zwar einem GSM-Netz 5,
einem Internet-Netz 6, einem GPRS-Netz 7, einem
DAB-Netz 8 und einem DVB-Netz 9. Die Kommunikationsvorrichtung 2 umfasst/betreibt
eine Anwendung 3, beispielsweise eine Netzanwendung, und eine
dynamische IP-Schicht 4.
-
In
der nachfolgenden Beschreibung wird ein Beispiel dafür gegeben,
wie ein Kommunikationsprozess zwischen der Kommunikationsvorrichtung 2 und einem
Server ausgeführt
wird, der mit wenigstens zwei der Kommunikationsnetze 5 bis 9 verbunden
ist.
-
Die
Anwendung 3 (z. B. eine Browser-Software wie der Netscape
Communicator) kann beispielsweise Informationen anfordern, die etwa
von einem (nicht gezeigten) Server über das Internet-Netz 6 bereitgestellt
werden. Der Server kann in Reaktion darauf die angeforderten Informationen
dann beispielsweise über
das DAB-Netz 8 zur Anwendung 3 zurück senden.
Zur Ausführung
der Kommunikation werden von der IP-Schicht 4 zwei IP-Netzmodule
(einer für
das Internet-Netz 6 und einer für das DAB-Netz 8)
bereitgestellt/aktiviert. Diese IP-Netzmodule verbinden (über entsprechende
IP-Netzschnittstellen wie etwa Netzkarten) die Netzanwendung 3 mit
den verschiedenen Netzen 6 bzw. B. Falls das DAB-Netz 8 momentan
nicht verfügbar
ist (kein oder nur schlechter Empfang), erkennt die dynamische IP-Schicht 4 diese
Situation und bestimmt dynamisch, mit welchen Kommunikationsnetzen
die Kommunikationsvorrichtung 2 momentan alternativ verbunden
werden kann. Beispielsweise kann die dynamische IP-Schicht 4 entscheiden,
dass die vom Server zur Anwendung 3 zu übermittelnden Informationen
künftig über das
GSM-Netz 5 gesendet werden sollten. Um dies zu ermöglichen,
stellt die dynamische IP-Schicht 4 für das GSM-Netz 5 ein
entsprechendes IP-Netzmodul bereit (oder aktiviert es, wenn es schon
verfügbar
ist) und baut eine Verbindung zwischen der Anwendung 3 und
dem GSM-Netz 5 auf. Dann bestimmt die dynamische IP-Schicht 4, dass
das IP-GSM-Netzmodul künftig
für jeglichen
ankommenden Datenverkehr als der "IP-Paket-Eingang" anzusehen ist. Daher wird einer entsprechenden,
vom IP-GSM-Netzmodul
adressierten GSM-IP-Netzschnittstelle eine entsprechende IP-Adresse zugewiesen,
wobei der Server dann "angewiesen" wird, gewünschte Informationen über das GSM-Netz 5 und
die GSM-IP-Netzschnittstelle (zum Beispiel eine Netzkarte) zur Netzanwendung 3 zurück zu senden.
Diese "Anweisung" wird vorzugsweise
ausgeführt,
indem als die Quelladresse (hier: über das Internet-Netz 6)
abgehender IP-Pakete die der GSM-IP-Netzschnittstelle zugewiesene
IP-Adresse angesetzt wird. Der Server sendet angeforderte Informationen
dann "automatisch" über das GSM-Netz 5 zur
Kommunikationsvorrichtung 2/zur Netzanwendung 3 zurück.
-
2 zeigt
mögliche
Eingangs-IP-Adress-Schnittstellen und Ausgangs-IP-Adress-Schnittstellen
von IP-Hosts.
-
Die
IP-Hosts sind mit der Bezugsnummer 20 bezeichnet. In einem
ersten Beispiel sendet ein IP-Host IP-Pakete über eine GSM-Eingangs-Schnittstelle 21 und
empfängt
IP-Pakete über
eine GSM-Ausgangs-Schnittstelle 22. Dadurch benötigt der
entsprechende IP-Host nur eine Netzkarte.
-
In
einem zweiten Beispiel sendet ein IP-Host IP-Pakete über eine
LAN-Ausgangs-Schnittstelle 23 und empfängt IP-Pakete über eine
Digital-Broadcast-Eingangs-Schnittstelle 24.
In diesem Fall benötigt
der IP-Host zwei Netzkarten: eine für das LAN-Netz und eine für das Digital-Broadcast-Netz. Daher
kann dieser IP-Host als in einem "Multihomed"-Zustand befindlich bezeichnet werden.
-
In
einem dritten Beispiel sendet ein IP-Host IP-Pakete über eine
WLAN-Ausgangs-Schnittstelle 25 und empfängt IP-Pakete über eine
LAN-Eingangs-Schnittstelle 26.
Der entsprechende IP-Host benötigt
daher zwei Netzkarten: eine LAN- und eine WLAN-Netzkarte.
-
3 zeigt
mögliche
Zustände
der IP-Schicht dieser Erfindung, die durch wechselnde Kommunikationsnetz-Zugriffsbedingungen
erzeugt werden.
-
In
einem ersten Zustand A sind verfügbare Kommunikationsnetze
ein Bluetooth-Kommunikationsnetz 10, ein ISDN-Kommunikationsnetz 11 und ein
DAB-Kommunikationsnetz 8. Diese Situation ist dann typisch,
wenn sich die Kommunikationsvorrichtung, die die IP-Schicht 4 verwendet,
in einem Wohnhaus befindet. Wird die Kommunikationsvorrichtung dann
beispielsweise in einem Auto angebracht und durch die Stadt transportiert,
sind das Bluetooth-Kommunikationsnetz 10 und
das ISDN-Kommunikationsnetz 11 nicht mehr verfügbar. Stattdessen
sind ein DVB-Kommunikationsnetz 9, ein WLAN-Kommunikationsnetz 12 und
ein UMTS-Kommunikationsnetz 13 zusätzlich verfügbar, neben dem DAB-Kommunikationsnetz 8.
Die IP-Schicht 4 erkennt die Situation automatisch und
deaktiviert IP-Netzmodule, die dem Bluetooth-Kommunikationsnetz 10 bzw.
dem ISDN-Kommunikationsnetz 11 entsprechen. Dann werden
durch die IP-Schicht 4 die IP-Netzmodule bereitgestellt/aktiviert,
die den oben beschriebenen, zusätzlich
verfügbaren
Kommunikationsnetzen entsprechen. Dieser Zustand der IP-Schicht 4 ist
mit Bezugszeichen B bezeich net. Dann aktiviert/deaktiviert in einem
dritten Zustand C die IP-Schicht 4 die IP-Netzmodule, sodass
Verbindungen zu einem Bluetooth-Kommunikationsnetz 10, einem
WLAN-Kommunikationsnetz 12 und einem DRM-Kommunikationsnetz 14 aufgebaut
werden. Eine die IP-Schicht 4 verwendende Anwendung "sieht" von der Veränderung
der zugänglichen
Kommunikationsnetze nichts. Daher ermöglicht es die IP-Schicht 4 der
Erfindung, auf TCP/IP-Basis kommunizierende Anwendungen in dem Fall
wiederzuverwenden, dass sich Kommunikationsnetz-Zugriffsbedingungen
zeitlich ändern.
Die in 3 erläuterte Situation
der Änderung
von Netzzugriffen ist ein allgemeiner Fall und umfasst mehrfache
Netze; jedoch kann das gleiche Konzept auch auf ein einzelnes IP-Netz
angewandt werden, das unter verschiedenen IP-Netzen automatisch
wechselt.
-
In
der nachfolgenden Beschreibung, die auf 4A bis 4F Bezug
nimmt, werden bevorzugte Datenstrukturen von IP-Paketen erläutert, die
verwendet werden, um den Kommunikationsprozess der Erfindung auszuführen.
-
4A zeigt
die Datenstruktur eines IP-Pakets 60, das einen Kopfabschnitt 61 und
ein Datenabschnitt 62 umfasst. Der Kopfabschnitt 61 umfasst
einen Kopfinformationsblock 63, einen Quell-IP-Adressblock 64,
einen Ziel-IP-Adressblock 65 und einen Optionenblock 66.
Die eigentlichen, zwischen Kommunikationsvorrichtungen auszutauschenden
Daten befinden sich im Datenabschnitt 62, während der
Kopfabschnitt 61 hauptsächlich
Routing-Informationen enthält.
-
Die
allgemeine Adressstruktur des Quell-IP-Adressblocks 64 und
des Ziel-IP-Adressblocks 65 sind
in 4B gezeigt: Jeder der Adressblöcke 64, 65 umfasst
einen Netzabschnitt 67, der eine Netzadresse enthält, und
einen Host-Abschnitt 68, der eine Subnet-Adresse und eine
Host-Adresse enthält.
-
4C bis 4E zeigen
entsprechende Beispiele der in 4B dargestellten
allgemeinen Adressstruktur. 4C zeigt
ein Beispiel, das ein Byte für
den Netzabschnitt 67 und drei Bytes für den Host-Abschnitt 68 verwendet.
Um diese Art der Adressstruktur anzugeben, ist das erste Bit des
Netzabschnitts 67 auf "0" gesetzt. 4D zeigt
eine Adressstruktur, die zwei Bytes für den Netzabschnitt 67 und
zwei Bytes für
den Host-Abschnitt 68 verwendet, wobei diese Art der Adressstruktur
durch die ersten zwei Bits des Netzabschnitts 67 angegeben
wird, die auf "10" gesetzt sind. 4E zeigt
ein drittes mögliches
Beispiel einer Adressstruktur, die drei Bytes verwendet, um den
Netzabschnitt 67 anzugeben, und ein Byte, um den Host-Abschnitt 68 anzugeben.
-
4F zeigt
ein konkretes Beispiel einer IP-Adresse, das die in 4D gezeigte
Adressstruktur verwendet.
-
5a) zeigt eine TCP/IP-Architektur nach dem Stand
der Technik. Eine TCP/IP-Architektur 30 umfasst eine IP-Schicht 31,
eine TCP-Schicht 32 und eine UDP-Schicht 33. Eine
Socket-API 34 stellt die Schnittstelle zwischen einer Anwendung
(z. B. einer Browser-Software) und der TCP/IP-Architektur 30 bereit.
Beim derzeitigen Stand der Technik besteht das Problem, dass die
Socket-API nicht
auf eine solche Weise strukturiert ist, dass die Funktionalität der TCP-Schicht 32,
der UDP-Schicht 33 und der IP-Schicht 31 vollständig hinter
der Socket-API 34 verborgen ist. Stattdessen enthält/bearbeitet
die Socket-API 34 Daten, die von einer Anwendung verwendet
werden können,
jedoch zur TCP-Schicht 32, zur
UDP-Schicht 33 oder zur IP-Schicht 31 gehören (z.
B. TCP-Port und IP-Adressen). Mit anderen Worten: Da die Socket-API 34 durch
die IP-Quelle, das IP-Ziel,
die TCP-Quelle und das TCP-Ziel eindeutig identifiziert ist, bestehen
Probleme, wenn sich diese Parameter auf Grund variabler Kommunikationsnetz-Zugriffsbedingungen ändern.
-
In 5b) ist eine TCP/IP-Architektur 40 gezeigt,
die eine mögliche
Lösung
dieses Problems darstellen kann. Hier ist eine Socket-API 44 durch
eine virtuelle IP-Quelle, ein IP-Ziel, eine TCP-Quelle und ein TCP-Ziel
eindeutig identifiziert. Die TCP/IP-Architektur 40 umfasst
außerdem
eine IP-Schicht 41, eine TCP-Schicht 42 und eine
UDP-Schicht 43. Innerhalb der IP-Schicht 41 ist
eine IP-virtuelle Adresse 46, die von der TPC-Schicht 42 und
der UDP-Schicht 43" gesehen" wird (oder eine
Anwendung, die die Socket-API 44 verwendet) auf "modifizierte" IP-Adressen abgebildet
(wahre IP-Adressen, d. h. zwischen den IP-Netzschnittstellen bzw. den verschiedenen Kommunikationsnetzen
verwendete IP-Adressen). Folglich darf eine Anwendung, die die Socket-API 44 verwendet,
nur eine IP-Adresse (und zwar die IP-virtuelle Adresse 46)
verwenden, während
die Bearbeitung unterschiedlicher IP-Adressen, die verschiedenen
Kommunikationsnetzen zugewiesen sind, durch die IP-Schicht 41 intern
selbst durchgeführt
wird. Wenn beispielsweise drei Kommunikationsnetze momentan verfügbar sind,
weist die IP-Schicht 41 drei IP-Adressen gleichzeitig zu,
wobei jede IP-Adresse einem
verfügbaren
Kommunikationsnetz bzw. einer IP-Netzschnittstelle entspricht. Dies
ist in 5b) durch die IP-Adressen angedeutet,
die mit den Bezugsnummern 47, 48 und 49 bezeichnet
sind und von denen jede einem Kommunikationsnetz bzw. einer IP-Netzschnittstelle
entspricht.
-
Eine
alternative Lösung
ist in 5c) gezeigt. Hier umfasst eine
TCP/IP-Architektur 50 eine modifizierte IP-Schicht 51,
eine TCP-Schicht 52 und eine UDP-Schicht 53. In dieser Ausführungsform
ist eine Socket-API 54 von den darunter liegenden Schichten 51, 52 und 53 unabhängig. Das
bedeutet, dass die Socket-API 54 nicht
durch die IP-Quelle, das IP-Ziel, die TCP-Quelle und das TCP-Ziel
identifiziert wird. Daher hat diese Realisierung den Nachteil, dass Änderungen
vorzunehmen sind, so weit die TPC-Schicht 52 und die UDP-Schicht 53 betroffen sind.
Infolgedessen ist diese Lösung
nicht rückwärts-kompatibel.
-
Wie
offenbar geworden ist, besteht das Problem, dass die Socket-API 34 entgegen
einer streng geschichteten Architektur ausgeführt ist: Die Socket-API 34 enthält Anwendungsebenen-Daten
aus tieferen Ebenen (TCP-Port und IP-Adressen). Dadurch treten Probleme
auf, da IP-Host-Adressen für jeden
Host mehrfach auftreten und sich in der Anzahl und im Wert dynamisch ändern können (Roaming zwischen
verschiedenen zellenbasierten Netzen kann zu unterschiedlichen IP-Netzadressen
für den Host
führen,
der mit den Netzen verbunden ist).
-
In 5b) wird dieses Problem gelöst durch "Virtualisieren" der Verwendung von IP-Adressen in der
Socket-API-Ebene (für
die Rückwärts-Kompatibilität) auf der
Client-Seite und durch Verwenden der dynamischen IP-Schicht 41 mit
wahren IP-Schnittstellen-Adressen. In diesem Fall bleibt die Rückwärts-Kompatibilität erhalten.
Eine solche Virtualisierung der IP-Quelladresse für die Socket-Schicht 44 muss
in der IP-Schicht 41 ausgeführt werden, um Inkompatibilitäten zu verringern.
Im Einzelnen öffnet eine
Anwendung, die Kommunikationsnetze zu verwenden beabsichtigt, einen
Socket mit einer bestimmten lokalen IP-Adresse und einem bestimmten TCP-Port
(UDP). Eine solche IP-Adresse ist eine virtuelle, was bedeutet,
dass es keine reelle IP-Adresse ist, die einer bestimmten Netzkarte
zugewiesen ist. Die darunter liegende IP-Schicht 41 handhabt
IP-virtuelle Adressen, um den IP-Paketverkehr (unter Verwendung
anderer IP-Adressen) ordnungsgemäß umzuleiten.
Im Gegensatz dazu wird in 5c) eine neue
Socket-API 54 verwendet, die einen unabhängigeren
Mechanismus zum eindeutigen Adressieren von Sockets aufweist. In
diesem Fall ist keine Rückwärts-Kompatibilität mit der
derzeitigen TCP-(UDP-)Implementierung zu erzielen. Eine solche Lösung macht
die TCP-Suite zu einer reinen Schichtarchitektur.
-
Selbstverständlich sind
für eine
modifizierte IP-Schicht auch andere praktische Implementierungen
möglich.
-
Innerhalb
der IP-Schicht 4, 41, 51 kann ein anspruchsvoller
Algorithmus (ein Algorithmus zur Wahl eines bezüglich der Kostenfunktion optimalen Pfades,
der die verfügbare
Bandbreite, die Kosten pro Kb oder Ähnliches misst) dazu dienen,
mehrfache IP-Pakete auf die derzeitigen optimalen Netze zu multiplexen.
Weiterhin kann ein Algorithmus verwendet werden, der unterschiedliche
mögliche
Pfade für IP-Pakete
definiert (der Algorithmus berechnet beispielsweise die kumulierte
Bandbreite der Kombination unterschiedlicher Netze (z. B. Broadcast
und GSM)).
-
Wie
offenbar geworden ist, beeinflusst die neue Konzeption der dynamischen
IP-Schicht 4, 41, 51 nicht die TCP/IP-Architektur
anderer Elemente. Die von der Kommunikationsvorrichtung 2 (oder,
genauer gesagt, von der Netzanwendung 3) erzeugten IP-Pakete
werden bei den IP-Standard-Spezifikationen reklamiert. Auf dem Pfad
zu einem Ziel (zum Beispiel dem Server) wird nur die IP-Zieladresse für Routing-Zwecke
verwendet; sobald das IP-Paket vom Server empfangen ist, dient die
IP-Quelladresse dazu, die anfordernde Kommunikationsvorrichtung 2 zu
adressieren.
-
Die
Socket-API (Anwendungsprotokoll-Schnittstelle) ist eine Anwendungs-API,
die auf dem TCP/IP-Protokollstapel beruht. Die Socket-Implementierung
unterstützt
während
einer einzelnen Verbindung keinen Austauschprozess von IP-Adressen. Ein Socket
ist durch vier Parameter eindeutig identifiziert: IP-Quelle und
IP-Ziel, TCP-(UDP-)Quelle und Ziel-Port. Diese Parameter bleiben
während
der TCP- oder UDP-Sitzung unverändert.
Es ist darauf hinzuweisen, dass dies das oben beschriebene Erfindungskonzept
nicht beeinflusst.
-
Ein
Anwendungsbeispiel des dynamischen IP-Protokollstapels gemäß dieser
Erfindung ist in der parallelen europäischen Patentanmeldung "IP based communication
system using uni- and bi-directional networks" der Anmelder beschrieben, die am gleichen
Tag wie diese Anmeldung eingereicht wurde und deren Inhalt hiermit
in diese Anmeldung einbezogen wird.
-
Glossar
-
- DAB. Digital Audio Broadcasting: ein digitaler Standard
für Audio-Rundsendungen.
- DVB. Digital Video Broadcasting: ein Standard für digitale
Video-Rundsendungen.
- DRM. Digital Radio Mundial: ein Standard für digitalen Funk mit weit reichenden
Wellen.
- DR. Digital Radio: dieser Begriff wird zuweilen für sämtliche
neuen Digitalstandards für
das Audio-Broadcasting (DAB, DRM, digitale FM) verwendet.
- GSM. Global System for Mobile Communication: globales System
zur Mobilkommunikation
- GPRS. General Packet Radio Service: allgemeiner Funkdienst mit
Paketübertragung
- WLAN. Wireless Local Area Network: drahtloses LAN
- LAN. Local Area Network: lokal ausgeführtes Netz
- UDP. User Datagram Protocol: Benutzer-Datagramm-Protokoll
-
Literaturhinweise:
-
- a. TCP/IP Illustrated, Band 1: The Protocols, Addison-Wesley
1994, ISBN 0-201-63346-9
- b. TCP/IP Illustrated, Band 2: The Implementation, Addison-Wesley,
1995, ISBN 0-201-63354-X
- c. "Mobility
Support in IPv6" von
Charles E. Perkins
- d. Mobile Networking Through Mobile IP von Charles E. Perkins
(http://computer: org/internet/vn2n1/perkins.htm)
- e. Multi homed Host Support in IPv6 (http://onoe2.sm.sony.co.jp/ipv6/id/draft-shand-ipv6-multi-homing-01.txt)
- f. IP Router Architectures: An Overview (James Aweya) (http://citeseer.nj.nec.com/432651.htm1)
- g. Invention report: aus "IP
based broadcasting communication system"
- h. "I-TCP: Indirect
TCP for Mobile Hosts" von
Ajay Bakre B.R. Badrinath, Department of Computer Science, Rutgers
University, Piscataway. NJ 08855. DCS-TR-314, Oktober 1994
- i. Transport Protocols for IP Traffic over DVB-T von Jonas Haggård Ljungquist
(Master-Arbeit am Royal Institute of Technology) (http://www.e.kth.se/~e92j1j/Exjobb/xrapport.pdf)