DE60320042T2 - Verfahren und system zur zentralen zuweisung von adressen und portnummern - Google Patents

Verfahren und system zur zentralen zuweisung von adressen und portnummern Download PDF

Info

Publication number
DE60320042T2
DE60320042T2 DE60320042T DE60320042T DE60320042T2 DE 60320042 T2 DE60320042 T2 DE 60320042T2 DE 60320042 T DE60320042 T DE 60320042T DE 60320042 T DE60320042 T DE 60320042T DE 60320042 T2 DE60320042 T2 DE 60320042T2
Authority
DE
Germany
Prior art keywords
gateway
node
address
port number
indoor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60320042T
Other languages
English (en)
Other versions
DE60320042D1 (de
Inventor
Björn Menai Landfeldt
Aruna Lane Cove SENEVIRATNE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE60320042D1 publication Critical patent/DE60320042D1/de
Application granted granted Critical
Publication of DE60320042T2 publication Critical patent/DE60320042T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5061—Pools of addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2525—Translation at a client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2582—NAT traversal through control of the NAT server, e.g. using universal plug and play [UPnP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Small-Scale Networks (AREA)

Description

  • Technisches Gebiet
  • Die vorliegende Erfindung betrifft eine Netzwerkkommunikation und insbesondere das Thema eines Bereitstellens von Konnektivität zwischen Netzwerken unterschiedlicher Adressbereiche.
  • Hintergrund
  • In einer Netzwerkkommunikation gibt es eine allgemeine Nachfrage nach einem Bereitstellen von Konnektivität zwischen unterschiedlichen Netzwerken, insbesondere wenn die Netzwerke unterschiedliche Adressbereiche aufweisen. Normalerweise würde dies zum Beispiel der Fall sein, wenn sich ein Knoten in einem privaten Netzwerk mit einem Host in einem öffentlichen Netzwerk verbinden möchte. Das private Netzwerk weist gewöhnlicher Weise interne Adressen auf, die nicht außerhalb des Netzwerkes aus Geheimhaltungsgründen verwendet werden können oder einfach, da die internen Adressen zur Verwendung außerhalb des privaten Netzwerkes ungültig sind. Andere Beispiele schließen eine Konnektivität zwischen Netzwerken unterschiedlichen, öffentlichen Domänen, zwischen unterschiedlichen, privaten Netzwerken und zwischen Netzwerken mit unterschiedlichem Adressschemata ein, wie zum Beispiel IP-Version 4 und IP-Version 6.
  • Die Nachfrage nach einer Netzwerkkonnektivität ist ein allgemeines Thema. Jedoch gibt es eine gegenwärtige Situation, die in der nahen Zukunft eine Lösung erfordert. Mit dem explosiven Wachstum von Internet-Protokoll-(IP)-Netzwerken, wie zum Beispiel dem Internet, Intranet oder anderen Netzwerken, wird der begrenzte IP-Adressraum, der von der gegenwärtigen Version des IP-Protokolls, I2v4, angeboten wird, eine echte Herausforderung. Mit einem 32-Bit-Adressfeld ist es möglich 232 unterschiedliche Adressen zuzuordnen, was ungefähr 4 Milliarden global eindeutige Adressen sind. Die nächste Version des IP-Protokolls, IPv6, weist ein 128-Bit-Adressfeld auf, wodurch eine bedeutend höhere Anzahl global eindeutiger IP-Adressen bereitgestellt wird. Die Herausforderung ist, dass es eine begrenzte Anzahl von IPv4-Adressen gibt, die für die Betreiber für ihre neuen Netzwerke verfügbar sind und IPv6 noch nicht von mehr als einem sehr begrenzten Satz an Knoten innerhalb des Internets unterstützt wird. Ebenso verwenden wahrscheinlich eine große Anzahl alter Netzwerke, einschließlich Internet-Subnetze, wahrscheinlich IPv4 oder ältere Versionen des IP-Protokolls für viele weitere Jahre.
  • Für Mobil- oder zellulare Netzwerke stehen Telekom-Anbieter und -Betreiber einer großen Herausforderung gegenüber, die eine Unterstützung für eine erwartete, große Anzahl von IP-ermöglichten Mobilgeräten in 2.5- und 3G-Netzwerken verwendet. Der IPv4-Adressraum ist offensichtlich nicht groß genug, die Anforderungen abzudecken, wenn eine massive Entwicklung von 2.5- und 3G-Netzwerken innerhalb der nahen Zukunft stattfindet. Heute empfangen Netzwerkbetreiber, die sich für Adressbereiche für ihre neuen zellularen Netzwerke bewerben, Adressräume, die weit unter der erwarteten Anzahl von Benutzern liegen. Das Verhältnis kann so niedrig sein wie wenige Tausend Adressen für eine erwartete Kundenbasis von Millionen an Teilnehmern.
  • Um die Nachfrage nach Adressen zu erfüllen, treiben die Telekom-Hersteller die Einführung von IPv6 in Endgeräten als das Standardprotokoll voran, das innerhalb von zellularen Netzwerken der nächsten Generation zu verwenden ist. Ein voll entwickeltes IPv6 würde natürlich das Adressraumproblem lösen, jedoch wird leider IPv6 noch nicht weit im Internet verwendet und es wird erwartet, dass diese Verwendung ziemlich langsam stattfindet, zumindest in der nahen Zukunft.
  • IPv6 ist nicht direkt IPv4 kompatibel und daher gibt es, wenn ein IPv6-Host mit einem IPv4-Host kommunizieren möchte, Kompatibilitätsprobleme. Die einzige Weise in der ein IPv6-Host mit einem Host kommunizieren kann, der lediglich IPv4 unterstützt, ist mittels in irgendeiner Weise eine IPv4-Adresse zu verwenden. Daher wird durch Einführen von IPv6 in 3G-Endgeräte das Adressraumproblem lediglich teilweise gelöst.
  • Dies stellt eine potentielle, ernste Bedrohung für die erfolgreiche Verwendung von 3G-Netzwerken und ihren Erfolg bei Kunden dar. Es ist von höchster Wichtigkeit, einen Zugang zu Diensten und Anwendungen nicht zu begrenzen, die in dem Internet verwendet werden, um eine Verminderung der Wertschätzung von potentiellen Kunden zu vermeiden.
  • Da IPv6 im Internet nicht voll verwendet wird, müssen Händler Migrationsschemata zum Bereitstellen einer Konnektivität zwischen unterschiedlichen Netzwerken bereitstellen.
  • Es gibt eine Anzahl von existierenden Schemata für sowohl ein Ausdehnen eines Adressbereiches als auch für ein Übersetzen zwischen unterschiedlichen Adressbereichen.
  • Zum Beispiel gibt es eine Anzahl existierender Vorschläge, die Adressübersetzungen zwischen unterschiedlichen Adressbereichen durchführen. Diese Lösungen, alle unterschiedlichen Versionen von Netzwerkadress-Übersetzern (NATs – Network Address Translators), haben gemeinsam, dass Hosts in einem (z. B. privaten) Adressraum temporär Adressen zugeordnet werden, die zu einem anderen (z. B. öffentlichen) Adressraum gehören. Eine Übersicht dieser unterschiedlichen Schemata kann in [1] gefunden werden und eine Erläuterung von Implementierungsthemen kann in [2] gefunden werden.
  • Das Problem bei den gegenwärtig vorgeschlagenen NAT-Schemata ist, dass sie alle eine Dienst-Bereitstellung in einer gewissen Weise begrenzen [1]. Entweder skalieren sie schlecht und lösen daher nicht das Problem des begrenzten Adressraumes oder sie erlauben nicht, dass eine Kommunikation sowohl zu als auch von 3G-Hosts initiiert wird oder sie erfordern eine Entwicklung spezifischer Softwaremodule, genannt Anwendungslevel-Gateways (ALGs – Application Level Gateways).
  • Die ALGs sind Module, die in dem Netzwerk innewohnen und die die Nutzlast in IP-Paketen parsen und Anwendungslevel-Information neu schreiben, um die NAT-Funktionalität wiederzuspiegeln. Selbst obwohl ALGs für einige Anwendungen verfügbar sind, primär zur Verwendung mit Firewall-Software auf LINUX-Plattformen, sind sie unmöglich in einer Betreiberumgebung zu verwenden und aufrechtzuerhalten, da niemand eine Verantwortlichkeit für diese Module annehmen kann. In einem 3G-Netzwerk würden die NATs typischerweise von Telecom-Anbietern hergestellt und bereitgestellt. Diese Hardware- und Softwareumgebung ist hoch spezialisiert und es gibt eine kleine oder keine Korrelation zwischen Plattformen für unterschiedliche Hersteller. Daher müssen ALGs für jede Plattform entwickelt werden.
  • Es ist hoch unwahrscheinlich, dass die Anwendungsentwickler die erforderlichen Fertigkeiten aufweisen oder diese Entwicklung durchführen und eine Verteilung von Versionsaktualisierungen bereitstellen möchten, da Anwendungsversionen den ALG-Betrieb ändern. In ähnlicher Weise können die Ausrüstungshersteller nicht die notwendigen Ressourcen durchmustern, um das Internet nach aller neuen Software zu durchsuchen, die herausgegeben wird und entweder Spezifikationen oder Reverese-Engineering-Anwendungen zu erhalten, um ALGs für ihre eigene Ausrüstung zu errichten und mit Software-Überarbeitungen Schritt zu halten. Schließlich möchten die Betreiber und ISPs (Internet Service Provider – Internet-Dienstanbieter) keine großen Entwicklungsorganisationen aufbauen, um diese Aufgabe zu übernehmen, statt einem Kaufen funktionierender Konzepte von Anbietern und sich auf ihr Kerngeschäft konzentrieren.
  • Bereichsspezifische-IP (RSIP – Realm Specific IP) unternimmt einen unterschiedlichen Ansatz als NAT, um Konnektivität zwischen unterschiedlichen Bereichen bereitzustellen [3,4]. RSIP verwendet einen speziellen Knoten, der die unterschiedlichen Bereiche kennt und den zwischen den Beiden unterscheiden kann. In allgemeinen Begriffen verwendet RSIP zwei Einrichtungen, einen RSIP-Server und einen RSIP-Client. Der RSIP-Server ist in beiden Bereichen präsent und kann eine Router-Funktionalität zwischen den Bereichen bereitstellen. Dieser kann ebenso der Knoten sein, der öffentliche Adressen zu privaten Hosts zuordnet. Der RSIP-Client ist ein Knoten innerhalb des privaten Bereichs, der temporär eine öffentliche Adresse verwenden kann, wenn dieser mit öffentlichen Hosts kommuniziert. Daher verwendet RSIP öffentliche Adressen für beide Parteien, wenn zwischen den privaten und öffentlichen Bereichen kommuniziert wird und führt keine Adressübersetzung durch. Ein Vorteil von RSIP ist, dass es keine Notwendigkeit gibt, ALGs für Anwendungen zu verwenden, da öffentliche Bereichsadressen selbst für private Clients verwendet werden. Jedoch erlaubt einfaches RSIP keine vom öffentlichen Bereich initiierten Verbindungen. Zum Beispiel können Bereichs-spezifische Adress- und Port-IPs (RSIP-IP – Realm Specific Address and Port IP) keine vom öffentlichen Bereich initiierte Kommunikation handhaben, da eine Portübersetzung erforderlich ist. RSAP-IP ordnet temporär einen freien Port auf dem RSIP-Server zu jedem Privatbereichsclient zu, der mit dem öffentlichen Bereich kommunizieren möchte. Da es keine Korrelation zwischen dem temporär zugeordneten Port und dem Port gibt, auf dem der private Client nach Verbindungsanfragen hören würde und es keinen Mechanismus zum Verteilen von Information zu Hosts eines öffentlichen Bereichs über irgendwelche alten Portnummern entsprechend zu spezifischen Diensten gibt, ist es für Hosts eines öffentlichen Bereiches unmöglich, sich mit dem korrekten Port auf dem RSIP-Server zu verbinden.
  • Ein neue Ansatz, genannt REBEKAH-IP, beruht auf zwei früheren Vorschlägen, RSIP und bidirektionales NAT, und fügt zusätzliche Erweiterungen zum Erfüllen dreier Anforderungen hinzu, Skalierbarkeit, Vermeiden eines Verwenden von ALGs und Zulassen Privatbereichs-initiierter Kommunikation sowie Öffentlichkeitsbereich-initiierter Kommunikation [5, 6]. Diese Lösung ist ebenso Thema unserer gemeinsam anhängigen, vorläufigen US-Patentanmeldung 60/370,812 und entsprechenden Internationalen Patentanmeldung PCT/US03/09834. Jedoch zeigt die REBEKAH-IP-Lösung die unerwünschte Eigenschaft möglicher, unauflösbarer Zweideutigkeiten und eines Verbindungsblockierens.
  • Es gibt ebenso eine andauernde Arbeit an der Columbia University [7] mit einem Schema, das IP-Adressen in ein neues Headerformat einkapselt. Jedoch erfordert dieses Schema, das alle Hosts im Internet aktualisiert werden müssen, was keine mögliche Lösung ist.
  • Das US-Patent 6,353,614 beschreibt ein Verfahren und ein Protokoll für eine Adressübersetzung in einem verteilten Netzwerk (DNAT – Distributed Network Address Translation). DNAT wird bei kleinen Büro- oder Heimbüro-Netzwerken verwendet, die mehrere Netzwerkgeräte aufweisen, die eine gemeinsame Netzwerkadresse verwenden, um mit einem externen Netzwerk zu kommunizieren. Das Protokoll schließt ein Portallokationsprotokoll ein, um global eindeutige Ports zu Netzwerkgeräten auf dem lokalen, kleinen oder Heimbüro-Netzwerk zu allozieren. Die global eindeutigen Ports werden in einer Kombinationsnetzwerkadresse mit der allgemeinen, externen Netzwerkadresse verwendet, um mehrere Netzwerkgeräte auf einem lokalen Netzwerk gegenüber einem externen Netzwerk zu identifizieren.
  • Zusammenenfassung der Erfindung
  • Die vorliegende Erfindung überwindet diese und andere Nachteile von Anordnungen gemäß dem Stand der Technik.
  • Es ist ein allgemeines Ziel der Erfindung, ein verbessertes Schema zum Unterstützen einer Konnektivität zwischen Netzwerken unterschiedlicher Adressbereiche bereitzustellen.
  • Es ist besonders wichtig, ein Verbindungs-Blockieren zu minimieren. Es ist wichtig, eine verbesserte Skalierbarkeit bereitzustellen, zum Beispiel eine große Anzahl privater Knoten mittels einer begrenzten Anzahl von verfügbaren öffentlichen Adressen zu ermöglichen. Mit anderen Worten ist es wünschenswert, die Multiplexeigenschaften eines Zwischenkommunikations-Gateways zu verbessern.
  • Es ist ein Ziel der Erfindung, ein verbessertes Verfahren und System zum Ermöglichen einer Herstellung einer Verbindung zwischen unterschiedlichen Adressbereichen bereitzustellen, die im Allgemeinen als ein Außenadressbereich und ein Innenadressbereich bezeichnet werden, über ein Zwischenkommunikations-Gateway.
  • Noch ein anderes Ziel der Erfindung ist, einen Gateway-Ressourcenmanager zum Unterstützen eines minimierten Verbindungs-Blockierens und/oder verbesserter Skalierbarkeit bereitzustellen.
  • Noch ein anderes Ziel der Erfindung ist, ein Kommunikationsendgerät bereitzustellen, das eine verbesserte Konnektivität zwischen Netzwerken unterschiedlicher Adressbereiche unterstützt.
  • Es ist ebenso ein Ziel der Erfindung, ein verbessertes Verfahren eines Konfigurierens eines Innenbereichs-Kommunikationsknotens bereitzustellen.
  • Diese und andere Ziele werden von der Erfindung erfüllt, wie in den begleitenden Patentansprüchen definiert.
  • Die Erfindung betrifft im Allgemeinen das Thema eines Bereitstellens von Konnektivität zwischen unterschiedlichen Adressbereichen, die im Allgemeinen als ein Innenbereich und ein Außenbereich bezeichnet werden. Wenn eine Anwendung, im Allgemeinen bezeichnet als ein Prozess, in einem Innenbereichsknoten mit einem anderen Prozess in einem Anßenbereichsknoten kommunizieren möchte, öffnet dieser einen Kommunikationsport, oft bezeichnet als ein Sockel/Socket, der Parameter einschließt, wie zum Beispiel Quelladresse und Port und Zieladresse und Port. Die Adressen identifizieren die Kommunikations-Netzwerkschnittstellen der Knoten und die Portnummern identifizieren die Prozesse in den Knoten, berücksichtigend, dass ein gegebener Knoten eine Vielzahl von gleichzeitig kommunizierenden Prozessen aufweisen kann. Im Stand der Technik, einschließlich der REBEKAH-IP-Lösung, wählen die Innenbereichsknoten selbst zufällig und unabhängig voneinander eine Portnummer zur Kommunikation mit dem Außenbereich aus. Es ist erkannt worden, dass dieser Ansatz gemäß dem Stand der Technik zu einem Verbindungs-Blockieren führen kann, da es ein Risiko gibt, dass zwei Innenbereichsknoten mit der gleich allozierten Außenbereichsadresse die gleiche Portnummer zur Kommunikation mit dem gleichen Außenbereichsprozess auswählen, was in einer Kollision oder einem Zusammenstoß resultieren würde, was das Gateway zwingt, eine der Verbindungen zu blockieren.
  • Die Grundidee gemäß der vorliegenden Erfindung, ist es alle Adressierungs-Zweideutigkeiten zu vermeiden und einen Gateway-Ressourcenmanager oder eine äquivalente Zentraleinheit (ein zentraler Konfigurationsserver), nicht nur die Adresse zuweisen zu lassen, sondern ebenso welche Quellportnummer für jede Kommunikation oder Fluss zu verwenden ist. Dies bedeutet, dass der Fokus verschoben ist von a) einem Zuordnen von Adressen zu Innenbereichsknoten zu b) einem zentralen Adressieren verteilter Prozesse in den Innenbereichsknoten. Folglich finden wir im Kern einen zentralisierten Portnummer-Allokationsmechanismus im klaren Gegensatz zu den Anordnungen gemäß dem Stand der Technik, in dem die Portnummer-Information zur Zeit einer Adresszuordnung nicht bekannt ist.
  • Wenn ein Innenbereichsknoten, z. B. ein Privatbereichsendgerät sich mit einem Anßenbereichsknoten verbinden möchte, z. B. einem Host auf dem öffentlichen Internet, beginnt der Innenbereichsknoten vorzugsweise durch Anfordern einer Konfiguration. Es wird angenommen, dass die Verbindung über ein Zwischen-Gateway hergestellt werden soll, das einen Pool so genannter Außenbereichs-Gatewayadressen zum Ermöglichen einer Außenbereichsdarstellung von Innenbereichsknoten aufweist. In Reaktion auf die Konfigurationsanfrage, die von dem Innenbereichsknoten initiiert wird, werden eine Außenbereichs-Gatewayadresse und eine Innenknoten-Portnummer zentral zu dem Innenbereichsknoten alloziert und eine Herstellung der Verbindung wird zumindest teilweise basierend auf der allozierten Adresse und Portnummer initiiert. Die allozierte Adresse und Portnummer werden zurück zu dem anfragenden Innenbereichsknoten in einer Konfigurationsantwort signalisiert, was es dem Innenbereichsknoten erlaubt, seine Kommunikationsschnittstelle demgemäß zu konfigurieren.
  • Alternativ wird die Allokation zentral ohne die Notwendigkeit für irgendeine Anfrage von dem Innenbereichsknoten initiiert, z. B. falls das Gateway-System den Innenbereichsknoten „zwingen" möchte, einen spezifischen Port zu öffnen.
  • Vorzugsweise wird die zentrale Adress- und Portnummerallokation durch Identifizieren einer Außenbereichs-Gatewayadresse und einer Innenknoten (Quell)-Portnummer durchgeführt, die zusammen mit vorbestimmter Verbindungsinformation, die typischerweise aus der Konfigurationsanfrage ableitbar ist, eine eindeutige Socket-Parameterkombination definieren, die ebenso als eine Außenbereichs-Gatewayzustands-Darstellung bezeichnet wird, die kein Gegenstück in irgendeinem existierenden Gateway-Verbindungszustand aufweist. Die vorbestimmte Verbindungsinformation schließt im Allgemeinen Außenknoten(Ziel)-Adressinformation ein, z. B. bekannt über eine DNS(Domain Name Server – Domänennamenserver)-Abfrage, und/oder Außenknoten-(Ziel)-Portinformation ein, z. B. eine wohlbekannte Standardportnummer. In dieser Weise ist der zentrale Gateway-Ressourcenmanager in der Lage, Kombinationen von Socket-Adressen und Ports zu allozieren, so dass Kollisionen vermieden werden. Insbesondere können alle Quellportnummern für eine gegebene Außenbereichsadresse nun zum Unterscheiden unterschiedlicher Verbindungen verwendet werden, was ein großer Vorteil verglichen mit Lösungen gemäß dem Stand der Technik ist.
  • Obwohl jeder allgemeine Signalprotokoll/-Mechanismus von der Erfindung verwendet werden kann, ist es erkannt worden, dass es vorteilhaft sein kann, die Konfigurationsparameter in einem speziellen Datensatz vom DNS-Typ zu übertragen oder durch ein vorsichtiges Neuverwenden eines existierenden Datensatzes vom DNS-Typ.
  • Die Erfindung stellt die folgenden Vorteile bereit:
    • – die Erfindung vermeidet die Aggregation, die im Stand der Technik auftritt, wenn alle möglichen Portnummern für eine gegebene Adresse zu einem einzelnen Knoten alloziert werden. Stattdessen eröffnet die Erfindung eine Verwendung aller dieser Portnummern zum Unterscheiden unterschiedlicher Verbindungen, wodurch eine Unterstützung für eine viel größere Anzahl von gleichzeitigen Verbindungen verglichen mit dem Stand der Technik bereitgestellt wird.
    • – Die Erfindung ist voll robust: es gibt kein Risiko eines Verbindungs-Blockierens aufgrund von Adress-Zweideutigkeiten.
    • – Die Erfindung skaliert extrem gut, da alle möglichen Socket-Parameterkombinationen in Verwendung sein müssen, bevor ein Verbindungs-Blockieren erfahren wird. Diese skaliert daher linear zu der theoretischen oberen Grenze der Anzahl an unterstützten Flüssen. Selbst obwohl die theoretische obere Grenze 262 weit von jener von IPv6 (2128) liegt, sollte der Adressraumzuwachs von 232 wie in IPv4 groß genug sein, um die Anforderungen der Industrie für einen beträchtlichen Zeitraum abzudecken.
  • Andere Vorteile, die von der vorliegenden Erfindung angeboten werden, werden bei Lesen der unteren Beschreibung der Ausführungsformen der Erfindung erkannt.
  • Kurze Beschreibung der Zeichnungen
  • Die Erfindung wird zusammen mit anderen Zielen und Vorteilen von dieser durch Bezug auf die folgende Beschreibung zusammengenommen mit den begleitenden Zeichnungen am besten verstanden, in denen:
  • 1 ein Grundmodell eines beispielhaften Gateway darstellt, das eine Konnektivität zwischen einem Innenbereichsnetzwerk und einem Außenbereichsnetzwerk bereitstellt;
  • 2 ein schematisches Diagramm einer beispielhaften Signalsequenz für eine Innenbereichs-initiierte Kommunikation über ein Gateway vom weiterleitenden Stil ist;
  • 3 ein schematisches Flussdiagramm einer beispielhaften Grundausführungsform der Erfindung ist;
  • 4 ein schematisches Diagramm einer beispielhaften Signalsequenz für eine Innenbereichs-initiierte Kommunikation basierend auf einer zentralisierten Quellportzuordnung ist;
  • 5 ein schematisches Blockdiagramm ist, das ein Beispiel einer Systemimplementierung gemäß einer bestimmten Ausführungsform der Erfindung darstellt;
  • 6 ein schematisches Blockdiagramm ist, das ein Beispiel einer allgemeinen Systemimplementierung gemäß einer anderen bestimmten Ausführungsform der Erfindung darstellt;
  • 7 ein schematisches Blockdiagramm ist, das ein Beispiel einer allgemeinen Systemimplementierung gemäß noch einer anderen bestimmten Ausführungsform der Erfindung darstellt;
  • 8 ein schematisches Diagramm ist, das ein detailliertes Beispiel einer Systemimplementierung gemäß einer bevorzugten Ausführungsform der Erfindung darstellt;
  • 9 ein beispielhaftes Endgeräteflussdiagramm gemäß einer beispielhaften Ausführungsform der Erfindung ist; und
  • 10 ein beispielhaftes Flussdiagramm eines Gateway-Ressourcenmanagers gemäß einer beispielhaften Ausführungsform der Erfindung ist.
  • Detaillierte Beschreibung von Ausführungsformen der Erfindung
  • Allgemeine Übersicht
  • Im Allgemeinen gibt es eine Nachfrage nach einem Bereitstellen von Konnektivität zwischen unterschiedlichen Adressbereichen, im Allgemeineren bezeichnet als ein Außenbereich und ein Innenbereich. Zu diesem Zweck wird normalerweise ein Zwischenkommunikations-Gateway bereitgestellt, dem ein Pool von Außenbereichs-Gatewayadressen zum Ermöglichen einer Außenbereichsdarstellung von Innenbereichsknoten zugeordnet worden ist. In vielen praktischen Anwendungen ist der Innenbereich ein privater Adressbereich, wohingegen der Außenbereich ein öffentlicher Adressbereich ist. In anderen Anwendungen jedoch können der Innenbereich und der Außenbereich beide unterschiedliche private Adressbereiche, unterschiedliche öffentliche Bereiche oder unterschiedliche Protokollbereiche sein.
  • In dieser Hinsicht ist ein öffentliches Bereichsnetzwerk im Allgemeinen ein Netzwerk mit Kommunikationsknoten zusammen mit einem verknüpften Netzwerkadressraum, der aus global eindeutigen Netzwerkadressen besteht. Ein privates Bereichsnetzwerk ist andererseits ein Netzwerk mit Knoten zusammen mit einem verknüpften Netzwerkadressraum, der aus möglicherweise nicht-eindeutigen Netzwerkadressen besteht, in dem Sinn, dass zwei Knoten in unterschiedlichen Fällen eines privaten Bereichs die gleiche Netzwerkadresse zugeordnet sein kann. Es ist ebenso möglich, dass der private Bereich ein unterschiedliches Protokoll und/oder Adressschema als der öffentliche Bereich verwendet. Zum Beispiel kann der Privatbereich IPv6-Adressen verwenden und der öffentliche Bereich kann IPv4-Adressen verwenden. In dem Kontext dieser Erfindung erweist sich sogar als wahr, dass zwei oder mehr Knoten innerhalb des gleichen privaten Bereiches die gleiche Netzwerkadresse zugewiesen werden kann, die ebenso zu anderen Knoten in anderen Netzwerken zugewiesen werden kann. Jedoch erweist sich als wahr, dass das Adressieren innerhalb eines bestimmten Bereiches ermöglicht, dass Verkehr innerhalb des Bereiches übermittelt wird.
  • Ein Kommunikations-Gateway ist daher im Allgemeinen ein Netzwerkelement, das sowohl mit einem Innenbereich als auch einem Außenbereich verknüpft ist. Wie zuvor erwähnt, gibt es unterschiedliche Typen von Gateways, insbesondere Gateways vom Substitutions-Stil (einschließlich z. B. unterschiedlicher Varianten NAT) und Gateways vom weiterleitenden Stil (einschließlich z. B. unterschiedlicher Varianten von RSIP). Es sollte ebenso selbstverständlich sein, dass die gesamte Gateway-Funktion ein Paketweiterleiten auf jeder Netzwerkschicht oder Kombination von Netzwerkschichten einschließen kann.
  • Für ein besseres Verständnis der Erfindung kann es nützlich sein, mit einer kurzen Einführung eines Grundmodells eines beispielhaften Gateways zu beginnen, das Konnektivität zwischen einem Innenbereich und einem Außenbereich bereitstellt, bezugnehmend auf 1.
  • 1 stellt ein Grundmodell eines beispielhaften Gateways 30 dar, das einen Innenbereich 10 und einen Außenbereich 20 verbindet. Das Gateway 30 ist mit einem Gateway-Ressourcenmanager 40 verknüpft, der unter anderen Dingen den Pool von Außenbereichs-Netzwerkadressen verwaltet, die zu dem Gateway zugeordnet worden sind. In dem Gateway 30 werden die Grundgatewayfunktionen durch ein Außenangebundenes Prozesselement 32, ein Innen-angebundenes Prozesselement 34 und ein Paket-weiterleitendes Element 36 unterstützt. Das Gateway 30 und der Gateway-Ressourcenmanager 40 können in getrennten jedoch verbundenen Knoten implementiert sein. Alternativ kann der Gateway- Ressourcenmanager 40 zusammen mit dem Gateway 30 aufgestellt sein, sogar in dem Gateway integriert sein. Dieser ist ebenso mit unterschiedlichen Kombinationen an Verteilung der Prozesse 30 und 40 über unterschiedliche Knoten möglich. Darüber hinaus kann das Außen-angebundene Prozesselement 32, das Innen-angebundene Prozesselement 34, das Paketweiterleitende Element 36 und der Gateway-Ressourcenmanager 40 alle in getrennten Prozessen, einem einzelnen Prozess oder irgendeiner Kombination aus diesen implementiert sein.
  • Für ein Gateway vom weiterleitenden Ziel ist ein Gateway-Verbindungszustand normalerweise durch ein Außen-n-Tupel und eine virtuelle Punkt-zu-Punkt-Schnittstelle zu einem Kommunikationsknoten auf dem Außenbereich definiert. Im Allgemeinen ist ein n-Tupel ein Satz von n Informationselementen, die typischerweise einschließen: (eine Quellnetzwerkadresse, eine Quellportnummer, eine Zielnetzwerkadresse, eine Zielportnummer und eine Protokollnummer). Ein Außen-n-Tupel ist typischerweise ein n-Tupel mit den Quell- und den Zielnetzwerkadressen, die zu dem Außenbereich gehören. Ein Beispiel einer virtuellen Punkt-zu-Punkt-Schnittstelle ist ein IP-in-IP-Tunnel, in dem in der innen-angebundenen Richtung ein Paket in einem anderen Paket verkapselt ist, mit der Zieladresse gleich der privaten Adresse des Innenknotens und der Quelladresse gleich zu der Innengatewayadresse und in der außen-angebundenen Richtung das eingehende Paket entkapselt wird, wodurch ein inneres Paket extrahiert wird. In einem anderen Beispiel könnte es statt einer IP-Verkapselung und -Entkapselung eine Schicht-2-Punkt-zu-Punkt-Verbindung zwischen dem Gateway und dem Kommunikationsknoten des Innenbereiches geben (zum Beispiel in einem GPRS-System, die PDP-Kontextschicht). Es sollte selbstverständlich sein, dass andere Mechanismen zum Herstellen eines Innenbereichs-Routing/Schalt-Wegs zwischen dem Gateway und dem Innenbereichsknoten von der Erfindung verwendet werden können. Zum Beispiel ist es möglich, eine geteilte Medienschnittstelle zusammen mit Routing- oder Schaltmechanismen zu verwenden, die in der Lage sind, Verkehr zu einem Innenbereichsknoten weiterzuleiten.
  • In einem Gateway vom weiterleitenden Stil sind die zwei Grundprozesse zum Ermöglichen eines geeigneten Paket-Weiterleitens für Kommunikationsflüsse definiert als:
    • – der innen-angebundene Prozess, in dem jedes innenangebundene Paket gegen die Außen-n-Tupel der Gateway-Verbindungszustände in dem Gateway abgeglichen wird und wenn ein passendes Außen-n-Tupel gefunden wird, wird das Paket zu der virtuellen Punkt-zu-Punkt-Schnittstelle entsprechend dem identifizierten Außen-n-Tupel gesendet.
    • – der außen-angebundene Prozess, in den jedes außen-angebundene Paket auf einer virtuellen Punkt-zu-Punkt-Schnittstelle eingeht und von dem Gateway zu dem Außenbereich weitergeleitet wird.
  • Es kann teilweise vollständige Gateway-Verbindungszustände geben, d. h. Zustände, die Verbindungen darstellen, die gegenwärtig in dem Prozess hergestellt zu werden sind, die jedoch nicht in einem vollständigen Gateway-Verbindungszustand für eine Gateway-Sitzung kollabiert sind. Derartige teilweise vollständige Gateway-Zustände werden manchmal als Gateway-Tore oder kleine Löcher/Pinholes bezeichnet.
  • In einem Gateway vom weiterleitenden Stil ist ein Gateway-Tor ein Gateway-Verbindungszustand mit einem Außenbereichs-n-Tupel, das eine oder mehrere unspezifizierte Verbindungsvariablen aufweist. Wenn das Gateway ein innen-angebundenes Paket empfängt, das mit den spezifizierten Werten des teilweise vollständigen Außen-n-Tupels übereinstimmt, wird jenes n-Tupel in dem Sinne vervollständigt, dass die bis jetzt unspezifizierten Werte des teilweise vollständigen n-Tupels auf die entsprechenden Werte fixiert werden, die mit dem Paket verknüpft sind.
  • Problemanalyse
  • Die Erfinder haben erkannt, dass, obwohl der REBEKAH-IP-Vorschlag, der in den Referenzen [5, 6] offenbart ist, in der Tat eine ausgezeichnete Skalierbarkeit bereitstellt und ebenso Öffentlichkeitsbereich-initiierte Kommunikation erlaubt, es ein Risiko von Adresskollisionen gibt, die darin resultieren, dass Verbindungen blockiert werden. Selbst obwohl diese Kollisionen selten sind, bilden diese einen unerwünschten Seiteneffekt der ansonsten genialen REBEKAH-IP-Lösung.
  • In REBEKAH-IP gibt es eine Möglichkeit, dass unauflösbare Zweideutigkeiten auftreten, wenn Innenbereichs-(private)-Knoten eine Kommunikation zu den Außenbereichs-(öffentlichen)-Knoten initiieren. Falls eine derartige Zweideutigkeit auftritt, wäre die resultierende Aktion, einige Kommunikationsversuche zu blockieren. Diese würden wiederum einen negativen Einfluss auf den wahrgenommenen Dienstlevel von den Endbenutzern haben.
  • Insbesondere können diese Zweideutigkeiten oder Kollisionen für eine Innenbereichs-initiierte Kommunikation auftreten, wenn Gateways vom weiterleitenden oder tunnelnden Stil basierend auf zum Beispiel RSIP verwendet werden. Wenn ein Innenbereichsknoten eine Kommunikation mit einem Außenbereichsknoten initiieren will, sendet dieser die Zieladresse (oder normalerweise den Domänennamen des Zielknotens) und/oder die Portnummer in einer Ressourcen-Allokationsanfrage an die Gesamt-Gateway-Funktion, die dann versucht, eine Außen-Gateway-Adresse für den Innenbereichsknoten zu identifizieren, die in Kombination mit der empfangenen Zieladresse und/oder Portnummer eindeutig ist. Falls es für darstellerische Zwecke angenommen wird, dass alle Gateway-Adressen in dem Gateway-Adresspool durchlaufen worden sind, ohne eine vollständige „freie" Adresse zu finden, kann es notwendig sein, eine Außenbereichs-Gatewayadresse auszuwählen, die zuvor zu einem anderen Innenbereichsknoten alloziert worden ist, der mit dem gleichen Außenbereichsknoten alloziert. Der einzige Parameter, der übrig ist, die zwei Verbindungen zu unterscheiden, wäre dann die Portnummer für die Innenbereichsknoten. Im Stand der Technik ist die Portnummer für einen Innenbereichsknoten zur Zeit der Adresszuordnung unbekannt und wird dem Gateway später bekannt gemacht, wenn das erste Datenpaket ankommt. Folglich gibt es eine Kollision oder einen Zusammenstoß, falls es passiert, dass zwei Innenbereichsknoten zufällig die gleiche Portnummer auswählen, was bedeutet, dass das Gateway die letztere der zwei Verbindungen blocken muss und den entsprechenden Innenbereichsknoten auffordern muss, das Socket mit einer neuen Portnummer neu zu öffnen.
  • Für ein detailliertes Verständnis der obigen Ereigniskette wird auf 2 Bezug genommen, die ein schematisches Diagramm einer beispielhaften Signalsequenz für eine Innenbereichs-initiierte Kommunikation über einen Gateway vom weiterleitenden Stil ist.
  • Eine beispielhafte Sequenz zum Unterstützen eines Kommunikationsflusses von Innenbereichsknoten A1 und A2 zu Außenknoten B über das Gateway könnte sein:
    • 1. Knoten A1 möchte einen Kommunikationsfluss zu Knoten B initiieren, der zu dem Außenbereich gehört. Knoten A1 sendet eine Anfrage, die die Zielnetzwerkadresse aOB und Zielportnummer pB einschließt, zu dem Gateway (GW). In dem IETF RSIP-Rahmen (RFC3103) könnte diese Nachricht das Anschlusszeichen „ASSIGN REQUEST RSA-IP" sein. Zum Zwecke einer Einfachheit wird hier angenommen, dass die Zieladresse bereits bekannt ist.
    • 2. Das Gateway sendet eine Anfrage an den Gateway-Ressourcenmanager (GRM). In Prozess X alloziert der GRM-Manager eine Netzwerkadresse aOG aus dem Gateway-Adresspool. Das Gateway führt typischerweise die Zieladresse und/oder den Zielport als vorbestimmte Verbindungsinformation an den Gateway-Ressourcenmanager zu. In diesem Beispiel sind sowohl eine Zieladressinformation als auch Portinformation in der Anfrage eingeschlossen. Um die Multiplexfähigkeit zu erhöhen, führt der Gateway-Ressourcenmanager einen Algorithmus aus, der bei gegebenem aOB und pB versucht ein aOG derart auszuwählen, dass ein Außen-n-Tupel (src: (aOB, pB); dest(aOG, *); ...) kein Außen-n-Tupel eines bereits existierenden Gateway-Verbindungszustandes ist. Falls dies nicht möglich ist (alle möglichen Gateway-Adressen aOG werden bereits verwendet), wähle die Gateway-Adresse aus, die in der geringsten Anzahl von Gateway-Verbindungszuständen verwendet wird.
    • 3. Die allozierte Gateway-Adresse aOG wird zurück zu dem Gateway gesendet.
    • 4. In einem Prozess a erzeugt das Gateway einen neuen teilweise vollständigen Gateway-Verbindungszustand basierend auf der verfügbaren Verbindungsinformation. Die Innenbereichsdarstellung wird mit A1 bezeichnet und stellt z. B. eine virtuelle Punkt-zu-Punkt-Verbindung zu dem Innenbereichsknoten A1 dar, wohingegen das Außen-n-Tupel die Werte: (aOB, pB; aOG, *) erhält. Das „*" bedeutet, dass dieses Feld zurzeit unspezifiziert ist. Eine Antwort wird zurück zu Knoten A1 gesendet, die die allozierte Gateway-Adresse aOG einschließt.
    • 5. Knoten A2 möchte ebenso einen Kommunikationsfluss zu Knoten B initiieren und sendet eine Anfrage einschließlich der Zielnetzwerkadresse aOB und Portnummer pB an das Gateway (GW).
    • 6. Das Gateway sendet eine entsprechende Anfrage an den Gateway-Ressourcenmanager (GRM). Im Prozess Y alloziert der GRM-Manager eine Netzwerkadresse aOG aus dem Gateway-Adresspool vorzugsweise durch Verwenden des gleichen Algorithmus wie in dem oben beschriebenen Prozess X. Unter der Annahme für darstellerische Zwecke, dass alle Gateway-Adressen in dem Gateway-Adresspool durchgegangen worden sind, ohne eine vollständige „freie" Adresse zu finden, erzwingt der Ressourcenmanager, die am wenigsten verwendete Gateway-Adresse auszuwählen. Weiter nehmen wir in diesem Beispiel an, dass die am wenigsten verwendete Adresse die gleiche Adresse aOG ist, die zuvor zu Knoten A1 alloziert wurde.
    • 7. Die allozierte Gateway-Adresse aOG wird zurück zu dem Gateway gesendet.
    • 8. In Prozess b erzeugt das Gateway weiter einen teilweise vollständigen Gateway-Verbindungszustand. Die Innenbereichsdarstellung wird mit A2 bezeichnet und stellt z. B. eine virtuelle Punkt-zu-Punkt-Verbindung zu dem Innenbereichsknoten A2 dar, wohingegen das Außen-n-Tupel die Werte: (aOB, pB; aOG, *) erhält. Das „*" bedeutet, dass dieses Feld zurzeit unspezifiziert ist. Eine Antwort wird zurück zu Knoten A2 gesendet, einschließlich der allozierten Gateway-Adresse aOG.
    • 9. Knoten A1 wählt einen Quellport pA1 (einen so genannten ephemeren Port) für den Kommunikationsfluss aus und sendet das als Paket. Dieses Paket wird von dem Gateway empfangen. Bei Prozess c kollabiert das entsprechende teilweise vollständige Außen-n-Tupel in ein vollständiges Außen-n-Tupel (aOB, pB; aOG, pA1), wodurch der bis jetzt unspezifizierte Wert in dem Außen-n-Tupel mit dem Wert pA1 ausgefüllt wird.
    • 10. Das Paket wird von dem außen-angebundenen Prozess verarbeitet und durch das Gateway zu dem Außenbereichsknoten B weitergeleitet.
    • 11. Ein Antwortpaket in dem Kommunikationsfluss wird von dem Gateway von Knoten B empfangen.
    • 12. Das Paket wird von dem innen-angebundenen Prozess des Gateways verarbeitet und an Knoten A1 geliefert.
    • 13. Knoten A2 wählt einen Quellport pA2 (einen so genannten ephemeren Port) für den Kommunikationsfluss aus und sendet das erste Paket. Dieses Paket wird von dem Gateway empfangen. Bei Prozess Z wird es untersucht, ob pA2 gleich zu pA1 ist. Falls pA2 = pA1, gibt es eine Kollision und der zweite teilweise vollständige Gateway-Verbindungszustand (in Box c) sollte nicht kollabiert sein. Stattdessen sollte das Gateway vorzugsweise versuchen Knoten A2 zu beeinflussen, eine andere pA2 auszuwählen, durch ein Zurücksetzen des Kommunikationsflusses, z. B. durch Senden eines TCP-Zurücksetzungssignals.
  • Beispielhafte Grundlösung
  • Um dieses Problem zu beseitigen ist eine Grundidee gemäß der Erfindung, den Konfigurationsserver/Gateway-Ressourcenmanager nicht nur die Außenbereichs-Gatewayadresse zuordnen zu lassen, sondern ebenso welche Quellportnummer für die Kommunikation zu verwenden ist, wodurch alle Adresszweideutigkeiten für Innenbereichs-initiierte Kommunikation vermieden werden. Dies wird vorzugsweise in der folgenden darstellerischen Weise erreicht, die sich auf das beispielhafte Flussdiagramm aus 3 bezieht. In Reaktion auf eine Verbindungsanfrage (S1), die von einem Innenbereichsknoten initiiert wird, der mit einem Anßenbereichsknoten kommunizieren will, alloziert (S2) der Gateway-Ressourcenmanager eindeutig eine Socket-Adresse und Quellportnummer zu dem Innenbereichsknoten. Zumindest die allozierte Socket-Adresse und Portnummer werden zurück zu dem anfragenden Innenbereichsknoten in einer Konfigurationsantwort signalisiert (S3), was es dem Innenbereichsknoten erlaubt, seine Kommunikationsschnittstelle mit der allozierten Socket-Adresse zu konfigurieren und die allozierte Portnummer für das geöffnete Socket zu verwenden. Die Konfigurationsanfrage, die von dem Innenbereichsknoten initiiert wird, kann, falls geeignet, von dem Gateway und/oder einem DNS-Server auf ihrem Weg weitergeleitet werden und Information kann übersetzt/zu der Anfrage angehängt werden.
  • Es ist vorgesehen, dass das zentrale Gateway-System einen Innenbereichsknoten zwingen wollen kann, einen bestimmten Port zu Kommunikation zu öffnen, ohne die Notwendigkeit einer expliziten Anfrage von dem Innenbereichsknoten. In jenem Fall initiiert der Gateway-Ressourcenmanager selbst den zentralen Port und die Adressallokation.
  • Der Gateway-Ressourcenmanager identifiziert vorzugsweise eine Außenbereichs-Socket-Adresse und eine Quellportnummer, die in Kombination mit einer vorbestimmten Verbindungsinformation, die in der anfänglichen Konfigurierungsanfrage eingeschlossen ist und/oder aus dieser ableitbar ist, einen Satz von Socket-Parametern definieren, der kein Gegenstück in irgendeinem existierenden Gateway-Verbindungszustand aufweist. Dieser eindeutige Satz von Socket-Parametern, einschließlich der allozierten Socket-Adresse und Quellportnummer, wird allgemein als eine Außenbereichs-Gateway-Zustandsdarstellung bezeichnet und bildet die Basis zum Herstellen eines neuen Gateway-Verbindungszustandes (S4). Insbesondere wird der neue Gateway-Verbindungszustand basierend auf der Außenbereichs-Gateway-Zustandsdarstellung identifiziert und einer entsprechenden Innenbereichs-Gateway-Zustandsdarstellung, wie zum Beispiel einer virtuellen Punkt-zu-Punkt-Schnittstelle zwischen dem Gateway und dem Innenbereichsknoten.
  • Der Gateway-Ressourcenmanager sollte in der Lage sein, sowohl eine Konfigurationsanfrage einschließlich einer Zielnetzwerkadresse, wie zum Beispiel einer IP-Adresse, sowie eine Konfigurationsanfrage einschließlich eines Zielnamens zu handhaben, wie zum Beispiel ein FQDN (Fully Qualified Domgin Name – voll qualifizierter Domänenname). In dem letzteren Fall kann eine DNS-Abfrage oder eine ähnliche Identifikator-zu-Adress-Abfrage durchgeführt werden, um die Zieladresse zu erhalten, die von dem Gateway-Ressourcenmanager bei dem Allokationsverfahren verwendet werden soll.
  • In einer typischen Implementierung fordert der Ressourcenmanager an, dass das Gateway einen neuen Verbindungszustand basierend auf einer vollständigen Außenbereichsdarstellung und einem entsprechenden Innenbereichsknotenidentifikator herstellt. Alternativ fordert der Ressourcenmanager eine Herstellung eines teilweise vollständigen Verbindungszustandes an, der nachfolgend vervollständigt wird, wenn der Innenbereichsknoten konfiguriert worden ist, die virtuelle Punkt-zu-Punkt-Schnittstelle auf dem Innenbereich hergestellt worden ist und der Innenbereichsknoten tatsächlich komplementäre Verbindungs-(Socket)-Information an das Gateway in dem ersten Paket übermittelt hat. In dem letzteren Fall muss die Zielportnummer noch nicht einmal zur Zeit einer Allokation einer Socket-Adresse und Quellportnummer bekannt sein. Der Gateway-Ressourcenmanager kann immer noch sicherstellen, dass es keine Kollisionen gibt, selbst ohne Information der Zielportnummer, einfach durch Nichtzuweisen des gleichen Quelladress-/Port-Paares zu Endgeräten, die einen Kontakt mit den gleichen Ziel-Hosts herstellen möchten. Mit anderen Worten entspricht dies einem Behandeln der Situation in der gleich Weise wie wenn die Zielportnummer die gleiche in beiden Konfigurationsanfragen ist.
  • Die Idee, nicht nur die Adressen zuzuweisen sondern ebenso welche Quellportnummern für die Kommunikation zu verwenden sind, impliziert, dass der erfindungsgemäße Mechanismus im gewissen Sinn als zentral zugeordnetes Prozessadressieren (CAPA – Centrally Assigned Process Addressing) betrachtet werden kann, da die zentralisierte Portzuordnung in Kombination mit der zentralisierten Adresszuordnung einzelne Prozesse in den Innenbereichsknoten genau festlegt.
  • Die größeren Änderungen, die von der Erfindung bezüglich des zuvor beschriebenen Signalsequenzdiagramms aus 2 beschrieben werden, werden durch Referenz auf das beispielhafte Signalsequenzdiagramm aus 4 erkannt:
    In diesem Beispiel wird es angenommen, dass jeder Innenbereichsknoten bereits die Zielnetzwerkadresse kennt, so dass die Konfigurationsanfrage bereits vorbestimmte Verbindungsinformation in der Form einer Zielnetzwerkadresse aOB und/oder einer Zielportnummer pB einschließt, typischerweise sowohl eine Zieladresse als auch eine Zielportnummer, wie in 4 dargestellt. Es wird ebenso angenommen, dass die Konfigurationsanfrage zu dem Gateway-Ressourcenmanager (GRM) über das Gateway (GW) weitergeleitet wird.
    • 1. Eine Konfigurationsanfrage, ebenso bezeichnet als eine Ressourcenanfrage, wird von dem Innenbereichsknoten A1 initiiert: Anfrage (aOB, pB).
    • 2. Das Gateway (GW) leitet die Anfrage weiter an den Ressourcenmanager (GRM). Bei Prozess X alloziert der GRM nun gemeinsam eine Außennetzwerkadresse aOG und eine Innenknotenportnummer pA1 basierend auf aOB und pB derart, dass ein eindeutiges Außen-n-Tupel definiert wird.
    • 3. Die allozierte Gateway-Adresse aOB und Portnummer pA1 werden zurück zu dem Gateway gesendet: Antwort (aOG, pA1).
    • 4. Eine Konfigurationsantwort wird zurück zu Knoten A1 gesendet, die die allozierte Gateway-Adresse aOG und Portnummer pA1 einschließt: Antwort (aOG, pA1). In Prozess a erzeugt das Gateway einen neuen Gateway-Verbindungszustand basierend auf der verfügbaren Verbindungsinformation. Die Innenbereichsdarstellung wird mit A1 bezeichnet und stellt z. B. eine virtuelle Punkt-zu-Punkt-Verbindung zu dem Innenbereichsknoten A1 dar, wohingegen das Außen-n-Tupel definiert als: (aOB, pB; aOG, pA1).
    • 5. Eine Konfigurationsanfrage, ebenso bezeichnet als eine Ressourcenanfrage, wird von dem Innenbereichsknoten A2 initiiert: Anfrage (aOB, pB).
    • 6. Das Gateway (GW) leitet die Anfrage an den Gateway-Ressourcenmanager (GRM) weiter. In Prozess Y alloziert der GRM gemeinsam eine Netzwerkadresse aOG und eine Portnummer pA2 basierend auf aOB und pB derart, dass ein eindeutiges Außen-n-Tupel definiert wird.
    • 7. De allozierte Gateway-Adresse aOG und Portnummer pA2 werden zurück zu dem Gateway gesendet: Antwort (aOG, pA2).
    • 8. Eine Konfigurationsantwort wird zurück zu Knoten A2 gesendet, einschließlich der allozierten Gateway-Adresse aOG und Portnummer pA2: Antwort (aOG, pA2). In Prozess b erzeugt das Gateway einen weiteren Gateway-Verbindungszustand. Die Innenbereichsdarstellung ist mit A2 bezeichnet und stellt z. B. eine virtuelle Punkt-zu-Punkt-Verbindung zu dem Innenbereichsknoten A2 dar, wohingegen das Außen-n-Tupel definiert ist als: (aOB, pB; aOG, pA2). Selbst obwohl A1 und A2 die gleiche Gateway-Adresse aOG zugeordnet wird, ist es immer noch möglich, die zwei Verbindungen mittels der unterschiedlichen Portnummern pA1 und pA2 zu unterscheiden, die intelligent von dem Ressourcenmanager zugeordnet werden.
    • 9. Der Innenbereichsknoten A1 sendet das erste Paket.
    • 10. Das Paket wird von dem Gateway empfangen, von dem außen-angebundenen Prozess verarbeitet und schließlich über das Gateway an den Außenbereichsknoten B weitergeleitet.
    • 11. Ein Antwortpaket in dem Kommunikationsfluss wird von dem Gateway von Knoten B empfangen.
    • 12. Das Antwortpaket wird von dem innen-angebundenen Prozess des Gateways verarbeitet und an Knoten A1 geliefert.
    • 13. Der Innenbereichsknoten A2 sendet das erste Paket.
  • Vorausgesetzt, dass sowohl eine Zieladresse aOB als auch eine Zielportnummer pB von dem Gateway-Ressourcenmanager bekannt sind, kann der schrittweise Zustandsaufbau in dem Gateway beseitigt werden, falls gewünscht und daher gibt es nicht länger eine Notwendigkeit für Prozess c.
  • In einem Sinn ist die Idee, gemeinsam basierend auf vorbestimmten Verbindungsdaten eine Außenbereichs-Gatewayadresse und eine Innenknoten-(Quell)-Portnummer zu allozieren, die in Kombination mit der vorbestimmten Verbindungsinformation ein Außen-n-Tupel definieren, das kein Gegenstück in einem vorbestimmten Satz von existierenden Gateway-Verbindungszuständen aufweist. Wie zuvor erwähnt schließt die vorbestimmte Verbindungsinformation typischerweise zumindest eine aus einer Außenknoten-(Ziel)-Adressinformation und Außenknoten-(Ziel)-Portinformation ein. Falls die Zieladresse und der Zielport in der vorbestimmten Verbindungsinformation eingeschlossen sind, ist das Außen-n-Tupel vollständig. Ansonsten ist dies teilweise vollständig. In dem Gateway wird ein Gateway-Verbindungszustand basierend auf dem zumindest teilweise vollständigen Außen-n-Tupel hergestellt. Die allozierte Gateway-Adresse und Portnummer werden zurück zu dem Innenbereichsknoten in einer Konfigurations-/Allokationsantwort gesendet. Nach einer Konfiguration kann der Innenbereichsknoten die tatsächliche Datenpaketübertragung zu dem beabsichtigten Außenbereichsknoten über das Zwischen-Gateway starten.
  • Allgemeine Erläuterung
  • Für darstellerische Zwecke betrachten wir das Folgende. Der Portbereich für einen einzelnen Host ist 216 – die ersten 1024 Ports, die von der IANA reserviert sind [8]. In einem schlimmsten Fallszenario versuchen alle privaten Hosts in einem Netzwerk sich mit der gleichen öffentlichen IP-Adresse auf der gleichen Portnummer (dem gleichen Prozess) zu verbinden. In diesem Fall erlaubt der CAPA-Mechanismus unzweideutig (216-1024) × N (die Anzahl verfügbarer, öffentlicher IPv4-Adressen zu dem GW) gleichzeitige Flüsse. Im besten Fallszenario sind alle Verbindungen von privaten Hosts zu getrennten Kombinationen von öffentlichen IP-Adressen und Portnummern. In diesem Fall unterstützt CAPA unzweideutig (216 – 1024) × N × (232 – N) × (216 – 1024) gleichzeitige Flüsse. Eine einfache partielle Ableitung mit Bezug auf N, um das Maximum zu finden, ergibt einen theoretischen Wert von ~262 gleichzeitigen Flüssen über ein einzelnes CAPA-Gateway.
  • Jedoch ist dies ein unrealistischer Wert, da dieser auftritt, wenn ein einzelnes CAPA-Gateway eine Hälfte des IPv4-32Bit-Adressraumes aufweist, jedoch ist bei einem realistischeren Wert von Tausend Adressen (für einen zellularen 3G-Betreiber zum Beispiel) das Ergebnis ~1.8 × 1022 gleichzeitig, eindeutig unterscheidbare Flüsse.
  • Bemerke jedoch, dass es eine weitere Begrenzung für die Anzahl von Flüssen gibt, die unterstützt werden können. CAPA ist nicht als eine global dauerhafte Lösung gemeint und bereits verwendete Hosts in dem öffentlichen Internet belegen alle eine IP-Adresse. Diese Hosts können nicht den Vorteil des erhöhten Adressraumes nutzen, wie durch CAPA eingeführt. Daher gibt es eine Begrenzung von 216 × N möglicher Verbindungen für diese Hosts. Für Hosts in CAPA-Domgins jedoch geht die Skalierbarkeit weit über diese Begrenzung hinaus.
  • Zum Beispiel könnte ein IPv6-System unter Verwendung von CAPA wie folgt konfiguriert sein. Zur Kommunikation zwischen zwei CAPA-Domänen verwende IPv6 und IP-in-IP-Tunneln über jede IPv4-Domäne. Verwende Standard-IPv6-Routingmechanismen und die IPv6-Stapel in den Hosts. Für Endgerät-initiierte (von dem Innenbereich) Kommunikation zu dem öffentlichen IPv4-Bereich verwende CAPA und weise IPv4-Adressen und Senderportnummern zentral zu, um Zweideutigkeiten zu vermeiden und eine optimale Skalierbarkeit zu erzielen.
  • Für Netzwerk-initiierten Verkehr (von dem Außenbereich) verwende REBEKAH-IP und ordne IPv4-Adressen zu den Endgeräten zu, wodurch alle Formen von Push-Diensten, Benachrichtigungsdiensten und Sofortnachrichtendiensten unter anderen Diensten erlaubt werden. In dem letzteren Fall benötigt, da der Innenbereichs-Host bereits mit einer Netzwerkadresse konfiguriert sein muss, um eingehende Verbindungsanfragen zu akzeptieren, der gesamte Gateway-Ressourcenmanager ebenso einen Mechanismus, durch den Innenbereichs-Host erlaubt wird, lediglich eine IP-Adresse von dem Gateway-Ressourcenmanager anzufordern.
  • Kommunikation von Hosts mit eindeutigen, öffentlichen IPv4-Adressen unterliegen keinen Adresszweideutigkeiten, da der Senderport niemals der gleiche für zwei gleichzeitige Flüsse von dem gleichen Host ist. Darüber hinaus gibt es keine Möglichkeit von Adresszweideutigkeiten von Hosts hinter unterschiedlichen Formen von NATs, da beim Verwenden dieser Schemata entweder der Sender-IP-Adresse, Portnummer oder Adress-/Portnummer eindeutig sind.
  • Implementierungsbeispiele
  • 5 ist ein schematisches Blockdiagramm, das ein Beispiel einer Systemimplementierung gemäß einer bestimmten Ausführungsform der Erfindung zeigt. Der Innenbereichsknoten A, wie zum Beispiel ein Kommunikationsendgerät, ist allgemein angeordnet zur Kommunikation mit jedem einer Anzahl von Außenbereichsknoten. Der Innenbereichsknoten A fordert eine Konfiguration von dem zentralen Gateway-System an und insbesondere von dem Gateway-Ressourcenmanager (GRM) 40. In diesem Beispiel schließt die Konfigurationsanfrage einen Zielknotenidentifikator ein, wie zum Beispiel einen FQDN sowie eine gut bekannte Importnummer. Die Anfrage wird von dem Gateway-Ressourcenmanager 40 empfangen, der eine Abfrage einschließlich des Zielknotenidentifikators an einen Namen-zu-Adress-(N/A)-Übersetzer 50 sendet, wie zum Beispiel einen DNS-Server. Der N/A-Übersetzer 50 bestimmt die Netzwerkadresse des Zielknotens B und gibt diese Adressinformation an den Gateway-Ressourcenmanager 40 zurück. Der Gateway-Ressourcenmanager 40 hat nun Information über sowohl eine Zieladresse als auch einen Zielport und eine Ressourcen-Allokationslogik 42 innerhalb des Ressourcenmanagers alloziert eindeutig eine Außenbereichsadresse und eine Quellportnummer für den Innenbereichsknoten A. Der Ressourcenmanager 40 sendet die allozierte Socket-Adresse und Portnummer vorzugsweise zusammen mit der abgerufenen Netzwerkadresse des Zielknotens zurück zu dem anfordernden Knoten A in einer Konfigurationsantwort. Der Gateway-Ressourcenmanager 40 initiiert ebenso eine Herstellung der Verbindung mittels eines geeigneten Signalisierens mit dem Gateway 30.
  • Wie zuvor erwähnt werden die Grund-Gateway-Funktionen in dem Gateway 30 von außen-angebundenen und innen-angebundenen Prozessen 32, 34 und dem Paket-weiterleitenden Element 36 unterstützt. Die Gateway-Verbindungszustände des Gateways 30 können in einer Zustandsdatenbank 38 implementiert sein, die als die Gateway-Routing-Tabelle arbeitet.
  • Der obige Prozess eines Erhöhens der Multiplexeigenschaften des Gateways durch eine zentrale und intelligente Allokation von Socket-Adresse und Quellportnummer kann auf einem Vergleich in Bezug auf existierende Gateway-Verbindungszustände basieren. Bezugnehmend auf das vereinfachte Blockdiagramm aus 5 könnte dieser Vergleich durch den Gateway-Ressourcenmanager 40 direkt in Bezug auf das Gateway 30 durchgeführt werden, das die relevanten Gateway-Zustände von der Zustandsdatenbank 38 in dem Gateway anfordert und extrahiert, wie und wann erforderlich. Um jedoch das Signalisieren zwischen dem Gateway 30 und dem Ressourcenmanager 40 zu vermindern, wird die Analyse vorzugsweise in Bezug auf eine oder mehrere getrennte Listendarstellungen der relevanten Gateway-Verbindungszustände durchgeführt. Derartige Listendarstellungen 42 werden geeignet in dem Ressourcenmanager 40 oder an einem externen Ort aufrechterhalten, der es für eine Ressourcen-Allokationslogik 44 in dem Ressourcenmanager ermöglicht, effektiv auf die Information zuzugreifen.
  • 6 ist ein schematisches Blockdiagramm, das ein Beispiel einer allgemeinen Systemimplementierung gemäß einer anderen bestimmten Ausführungsform der Erfindung darstellt. In diesem Beispiel sendet der Innenbereichsknoten eine Konfigurationsanfrage, die eine Zielknotenportnummer und einen Zielknotenidentifikator, wie zum Beispiel den FQDN, direkt an den N/A-Übersetzer 50 sendet, der nach einer geeigneten Bestimmung der Zielknotennetzwerkadresse die Konfigurationsanfrage an den Gateway-Ressourcenmanager 40 weiterleitet. In der Systemimplementierung aus 6 sind das Gateway 30 und der Gateway-Ressourcenmanager 40 zusammen in einem modifizierten Firewall-/Gateway-Knoten implementiert und der N/A-Übersetzer 50 ist als modifizierter DNS-Server implementiert. Dies bedeutet, dass der Gateway-Ressourcenmanager gemeinsam mit dem Gateway 30 lokalisiert ist und vielleicht sogar in dem Gateway integriert ist.
  • 7 ist ein schematisches Blockdiagramm, das ein Beispiel einer allgemeinen Systemimplementierung gemäß noch einer anderen bestimmten Ausführungsform der Erfindung zeigt. In diesem Beispiel sind der Gateway-Ressourcenmanager 40 und der N/A-Übersetzer 50 in einem modifizierten DNS-Server implementiert.
  • Es sollte klar sein, dass die Weise, in der die Konfigurationsanfrage zu dem Gateway-Ressourcenmanager übertragen wird (direkt über das Gateway und/oder den DNS-Server und so weiter) nicht kritisch ist, so lange der zentrale Gateway-Ressourcenmanager tatsächlich die Verbindungsinformation empfängt, die zum Identifizieren einer eindeutigen Kombination von Socket-Parametern erforderlich ist. Das Gleiche gilt für die Kommunikationsantwort so lange die relevanten Socket-Parameter tatsächlich an dem anfragenden Innenbereichsknoten übertragen werden. Unter anderem hängt die Weise, in der die Erfindung ausgeführt ist, von anderen System-Designkriterien ab, wie zum Beispiel der Abfolge von Schritten zum Öffnen von Sockets in einer bestimmten Programmier-API. Daher kann die Client-Konfiguration gemeinsam mit dem Namensauflösungsschritt (DNS-Nachschlag) lokalisiert sein oder vollständig getrennt sein.
  • Es sollte ebenso aus den obigen Beispielen selbstverständlich sein, dass die Verwaltungs- und Allokationsfunktionen in dem Gesamt-Gateway-System in einem oder mehreren Prozessen implementiert sein können, die auf einem einzelnen Knoten laufen oder physikalisch getrennt in mehreren Knoten. Zum Beispiel kann das Gateway und der verknüpfte Ressourcenmanager getrennt oder gemeinsam lokalisiert sein, was alles von dem bestimmten System-Designspezifikationen abhängt. Die Gateway-Ressourcenmanager-Funktion und die verknüpfte DNS-Funktion können in getrennten Knoten implementiert sein oder alternativ zusammen implementiert sein, zum Beispiel in einem modifizierten DNS-Server.
  • Im Allgemeinen kann der Gateway-Ressourcenmanager als Software, Hardware, Firmware oder jeder Kombination aus diesen implementiert sein. In dem Falle einer Software-Implementierung werden die Schritte, Funktionen und Aktionen, die sich auf den Ressourcenmanager beziehen, in einem Computerprogramm abgebildet, das, wenn es von einem Computer oder äquivalenten Verarbeitungssystem ausgeführt wird, die relevante Ressourcen-Allokation bewirkt.
  • Beispiel einer detaillierteren Systemimplementierung
  • 8 ist ein schematisches Diagramm, das ein detaillierteres Beispiel einer Systemimplementierung gemäß einer bevorzugten Ausführungsform der Erfindung darstellt. In diesem bestimmten Beispiel werden die Gesamtverwaltungsfunktionen als zwei getrennte Prozesse implementiert, die physikalisch in zwei Servern und/oder Knoten getrennt sind, den Gateway-Ressourcenmanager (GRM) 40 und einen DNS-Server 50 oder einen ähnlichen Identifikator-zu-Adress-Übersetzer. Es wird ebenso angenommen, dass ein Privatbereichs-Host oder ein Endgerät sich mit einem Host in dem öffentlichen Bereich verbinden möchte, wie zum Beispiel dem Internet. Das Kommunikationsendgerät könnte jedes geeignete Endgerät einschließlich Benutzerendgerät sein, wie zum Beispiel moderne Mobiltelefone, Personal Computer, Kommunikatoren, persönliche digitale Assistenten und so weiter, jedoch ebenso einschließlich von Endgeräten in Basisstationen, mobilen Vermittlungsstellen und anderen Netzwerkknoten.
  • Endgeräteimplementierung
  • Es hat sich nun als vorteilhaft herausgestellt, einen neuen CAPA-spezifischen DNS-Datensatztyp zu definieren, der zum Übermitteln der Socket-Parameter an die Endgeräte während einer Konfiguration verwendet wird. Jedoch könnte alternativ zum Minimieren des Einflusses auf die Endgeräte ein existierender Datensatztyp, wie zum Beispiel der SRV-Datensatz [9], verwendet werden. Jedoch ist es in diesem letzteren Fall wichtig, zu betonen, dass der SRV-Datensatz ein existierender Datensatztyp ist, der einen anderen Zweck aufweist als eine Verwendung mit CAPA. Es gibt eine Möglichkeit, dass ein Verwenden eines existierenden Datensatzes, wie zum Beispiel dem SRV-Datensatz, Probleme erzeugen kann, wenn Endgeräte die Daten falsch interpretieren oder DNS-Server den SRV-Datensatz in einer unterschiedlichen Weise verwenden. Dieses Problem könnte durch Definieren eines Feldes in dem SRV-Datensatztyp verringert werden, das klar die Verwendung des Datensatzes zum CAPA-Signalisieren unterscheidet, wodurch tatsächlich dieser temporär zu einem CAPA-spezifischen Datensatz gemacht wird. Es sollte ebenso betont werden, dass die Implementierung des zurückgegebenen DNS-Datensatzes als das Signalverfahren nicht mit allen Mitteln die einzige Weise ist, in der ein CAPA-Signalisieren realisiert werden kann. Es ist möglich, modifiziertes RSIP-Signalisieren oder jedes andere Signalprotokoll/Mechanismus zu verwenden, um die Konfigurationsparameter zu erhalten. Tatsächlich ist dies ein Thema zum Implementieren von CAPA in spezifischen Umgebungen, bei denen die Signalisierung auf anderen Signalisierungen Huckepack sein kann, wodurch eine Gesamtanrufaufbaulatenz verringert wird oder andere Vorteile erhalten werden.
  • Natürlich muss jede praktische Implementierung Kunden angepasst werden und in Bezug auf die System-spezifischen Umstände und Designkriterien optimiert werden.
  • Die Abfrage zu dem GRM/DNS von dem privaten Endgerät kann dann den CAPA-Datensatztyp abfragen. In dem zurückgegebenen Datensatz gibt es tatsächlich Felder, die identifizieren, welche Quell-IP-Adresse und Portnummer zu verwenden ist, sowie Information über die Zieladresse.
  • Das Folgende ist eine Beispielausgabe von dem DNS unter Verwendung eines neuen CAPA-Datensatzes sowie einer Datensatzinformation, wenn das Endgerät den Host apricot.ee.unsw.edu.au kontaktieren möchte:
    Trying „apricot.ee.unsw.edu.au"

    ;; ->>HEADER<<-opcode:QUERY, status: NOERROR, id: 22135
    ;; Flags: qr aa red ra; QUERY:1, ANSWER:1, AUTHORITY:1, ADDITIONAL:3

    ;; QUESTION SECTION/Frageabschnitt:
    ; apricot.ee.unsw.edu.au. IN CAPA

    ;; ANSWER SECTION/Antwortabschnitt:
    apricot.ee.unsw.edu.au.86400 IN CAPA 0 08500 129.94.230.85

    ;; AUTHORITY SECTION/Autoritätsabschnitt:
    ee.unsw.edu.au.86400 IN NS cool.mydomain.cxm.

    ;; ADITIONAL SECTION/zusätzlicher Abschnitt:
    apricot.ee.unsw.edu.au.86400 IN A 129.94.230.79
    cool.mydomain.cxm. 86400 IN A 129.94.230.94
    cool.mydomain.cxm. 86400 IN A 192.168.10.2.
  • Diese Antwort wird von dem Auflöser interpretiert als "Konfiguriere deine Schnittstelle mit der IP-Adresse 129.94.230.94 und verwende Portnummer 8500 für das geöffnete Socket. Die IP-Adresse des ferngelegenen Hosts (apricot) ist „129.94.230.79".
  • Ein beispielhafter Prozessfluss für einen Innenbereichs-Host/Endgerät ist in dem schematischen Flussdiagramm aus 9 gezeigt. In Schritt S11 wird eine Abfrage an den GRM/DNS erzeugt, einschließlich des FQDN oder eines ähnlichen Identifikators des Ziel-Hosts. Eine Antwort von dem GRM/DNS wird in Schritt S12 empfangen. In Schritt S13 wird es untersucht, ob die Auflösung ein CAPA-Datensatz ist. Falls dem so ist, liest das Innenbereichsendgerät die Parameter, die zu verwenden sind, aus dem CAPA-Datensatz in der DNS-Antwort, konfiguriert seine IP-Adresse gemäß dem Datensatz und öffnet ein Socket unter Verwendung der zurückgegebenen Quellportnummer, wie in Schritt S14 angezeigt. Ist das Endgerät einmal konfiguriert worden, signalisiert dieser das dem Server und baut einen IP-Tunnel über die private Domäne auf, wie in Schritt S15 angezeigt. Falls die Auflösung kein CAPA-Datensatz ist (falsch), wird es geprüft, ob die Auflösung ein Standard A- oder AAAA-Datensatz in Schritt 16 ist. Falls dem so ist, wird ein Socket zu dem Ziel-Host in der gewöhnlichen, herkömmlichen Weise in Schritt S17 geöffnet.
  • In dieser bestimmten Implementierung verwendet die Interaktion zwischen Endgerät und Server die Standard-DNS-Funktion statt einem Einführen eines expliziten Signalisierens.
  • Das zweite ausgewählte darstellerische Verfahren erfordert lediglich moderate Änderungen gegenüber dem Endgerät, da die lediglich strenge Anforderung ist, dass der DNS-Auflöser (eine Anwendung, die einen DNS abfragt) nach CAPA-Datensätzen fragen und diese zusätzlich zu den gewöhnlichen A- oder AAAA-Datensätzen verstehen kann. Das Erfassen der Sender-IP-Adresse und Portnummer kann ebenso unter Verwendung eines expliziten Signalisierens mit dem GRM implementiert sein. Beim Verwenden eines expliziten Signalisierens ist es möglich, den Informationsabruf entweder durch Modifizieren des Auflösers oder durch Modifizieren der Socket-API-Implementierung zu implementieren, um die Signalphase einzuschließen, wenn Anwendungen Sockets öffnen. Jedoch würde eine derartige Weise einer Implementierung einen größeren Einfluss auf die Endgeräte aufweisen, da das Betriebssystem wesentliche Änderungen benötigen würde.
  • Gateway-Ressourcenmanager-Implementierung
  • Eine beispielhafte Implementierung des Gateway-Ressourcenmanagers, der ebenso als ein Prozess-Adress-Manager bezeichnet werden kann, basiert auf einer Standard-Implementierung von DNS mit Erweiterungen, um die dynamischen Adress- und Portzuweisungen und das Signalisieren mit dem Gateway zu verwalten. In einer beispielhaften Implementierung verwendet das Gateway eine Standardschicht drei und/oder vier Schaltfunktionen zum Abbilden der Adressen und Portnummern auf Tunnel.
  • Ein Beispiel eines Entscheidungsprozesses in dem Gateway-Ressourcenmanager ist in dem schematischen Flussdiagramm aus 10 gezeigt.
  • In Schritt S21 empfängt der Gateway-Ressourcenmanager eine Ziel-FQDN und eine Quell-IP-Adresse. Der Ressourcenmanager verwendet DNS-Funktionalität für einen DNS-Nachschlag um die Ziel-IP-Adresse zu erhalten, die dem FQDN entspricht, wie in Schritt S22 angezeigt. Zum Beispiel könnte die DNS-Funktionalität in dem Gateway-Ressourcenmanager integriert sein oder in der Form eines getrennten DNS-Servers bereitgestellt werden, mit dem der Ressourcenmanager kommuniziert, um die Ziel-IP-Adresse zu erhalten. Auf eine Abfrage hin bestimmt der Ressourcenmanager, ob die Abfrage von innerhalb der privaten Domäne oder von der öffentlichen Domäne kam, wie in Schritten S23/S27 angezeigt. In Schritt S23 wird es untersucht, ob die Anfrage von dem privaten Bereich stammt. Falls dem so ist, ist der nächste Schritt S24, eine Adresse und ebenso eine Portnummer zur Verwendung für den privaten Host/Endgerät zuzuweisen. Der Auswahlprozess kann unter Verwendung einer Anzahl unterschiedlicher Algorithmen zur Optimierung einer Geschwindigkeit und so weiter implementiert werden. In der beispielhaften Implementierung, entschieden wir uns für eine rotierende IP-Adressliste und die erste freie Portnummer wie folgt:
    Falls dem privaten Host bereits eine IP-Adresse zugewiesen worden ist, verwende diese. Ansonsten wähle die erste IP-Adresse auf der List und verschiebe jene Adresse an das Ende der Liste derart, dass dieser nicht erneut ausgewählt wird, bis alle anderen IP-Adressen in der Liste einmal ausgewählt worden sind. Dies spreizt die Zuweisung von IP-Adressen gleichförmig über den verfügbaren Bereich. Zweitens wähle eine erste nicht verwendete Portnummer für die ausgewählte IP-Adresse. Falls keine freie Portnummer verfügbar ist, wiederhole mit der nächsten Adresse in einer Liste.
  • Der nächste Schritt S25 ist, um das Grenz-Gateway von der ausgewählten Kombination von Quell- und Ziel-IP-Adresse und der entsprechenden privaten Adresse derart zu informieren, dass das Gateway seine Routing-Tabelle mit einer Abbildung auf den korrekten Tunnel aktualisieren kann. Dieser Prozess kann in mehreren Weisen unter Verwendung unterschiedlicher Algorithmen in Abhängigkeit einer Optimierung für Hardware und so weiter implementiert werden.
  • In dieser Beispielimplementierung aktualisieren wir die Routing-Tabelle tatsächlich nicht, bis das Endgerät geeignet konfiguriert worden ist, die entsprechende Punkt-zu-Punkt-Schnittstelle in dem privaten Bereich hergestellt worden ist und das erste Paket von dem Gateway empfangen wird.
  • Stattdessen verwenden wir eine getrennte Liste für anhängige Verbindungen (mit teilweise vollständigen Verbindungszuständen), bis ein Tunnel hergestellt worden ist und die Quell- und Zielports in dem Paketfluss signalisiert sind.
  • Als nächstes gibt in Schritt S26 der Ressourcenmanager den Datensatz an das abfragende Quell-Host/Endgerät zurück und die Kombination bekannter Parameter (Socket-Adresse und Ports) werden als belegt markiert.
  • Wenn das erste Datagramm/Paket, das zu der Sitzung gehört, an dem Grenz-Gateway ankommt, werden der ausstehende Parameter/die ausstehenden Parameter identifiziert und die Kombination aller vier (Sender- und Empfängeradresse und Portnummern) werden eindeutig auf den verknüpften Tunnel abgebildet.
  • Falls es in Schritt S23 bestimmt wird, dass die Anfrage nicht von dem privaten Bereich stammt (falsch), schreitet der Fluss mit Schritt S27 voran. In Schritt S27 wird es untersucht, ob die Anfrage von dem öffentlichen Bereich stammt und das Zielendgerät innerhalb des privaten Bereichs ist. Falls dem so ist, wird eine öffentliche Adresse zum Darstellen des privaten Zielendgerätes in Schritt S28 zugewiesen und eine Bindung wird mit dem öffentlichen Quell-Host durchgeführt. Der nächste Schritt S29 ist, um das Gateway von der Bindung zu benachrichtigen. In Schritt S30 gibt der Ressourcenmanager den Datensatz an den abfragenden, öffentlichen Quell-Host zurück.
  • Schritt S31 stellt eine Standard-DNS-Situation mit einem regulären DNS-Nachschlag und -Antwort dar, wenn ein privates Endgerät mit einem anderen privaten Endgerät kommunizieren möchte.
  • In Kürze entsprechen Schritte S24–26 dem CAPA-Mechanismus, wohingegen Schritte S28–30 mehr oder weniger dem REBEKAH-IP-Mechmanismus entsprechen.
  • Falls die Abfrage von dem öffentlichen Bereich stammt (z. B. Internet), ist die Kombination von Senderadresse und Portnummer eindeutig und falls von dem privaten Bereich stammt, macht der oben erklärte Parameterauswahlprozess die Kombination ebenso eindeutig, so dass das Gateway leicht den nächsten Fluss identifizieren kann.
  • Während dem Rest der Sitzung liest das Grenz-Gateway die Kombination von Sender- und Empfängeradressen und Portnummern und basiert sein Routing/Weiterleiten auf dieser Kombination für Verkehr, der von der öffentlichen Domäne kommt. Verkehr von der privaten Domäne wird einfach gemäß Standard-IP-weiterleitenden Mechanismen weitergeleitet.
  • Unter Bezug erneut auf 8 kann der Gesamtprozess in einer beispielhaften Systemimplementierung wie folgt zusammengefasst werden:
    • 1. Der private Host sendet eine Konfigurationsanfrage einschließlich eines FQDN zusammen mit Zielportinformation (z. B. einem gut bekannten Port) an den Gateway-Ressourcenmanager (GRM) 40.
    • 2. Der Gateway-Ressourcenmanager 40 kontaktiert den DNS-Server 50, der die IP-Adresse entsprechend dem FQDN des gesuchten Ziel-Hosts nachschlägt und einen herkömmlichen A- oder AAAA-Datensatz an den Gateway-Ressourcenmanager 40 zurückgibt.
    • 3. Der Gateway-Ressourcenmanager 40 ordnet eine öffentliche IP-Adresse aus dem Pool öffentlicher IP-Adressen, die zu dem Gateway alloziert sind und eine Portnummer von dem entsprechenden Pool an Portnummern basierend auf der Ziel-IP-Adresse und der Zielportnummer zu. Vorzugsweise wird der DNS nachfolgend von der Bindung zwischen FQDN und der zugeordneten, öffentlichen IP-Adresse informiert.
    • 4. Benachrichtige das Gateway der ausgewählten/bekannten Kombination von Socket-Parametern in einer Anfrage zum Herstellen eines Gateway-Verbindungszustandes.
    • 5. Informiere den privaten Host/Endgerät von einer zugewiesenen, öffentlichen IP-Adresse, Quellportnummer und IP-Adresse für FQDN in einem CAPA-Datensatz (möglicherweise in Kombination mit einem A-Datensatz), um eine geeignete Konfiguration der Kommunikationsschnittstelle des Endgerätes zu ermöglichen.
    • 6. Erzeuge einen Tunnel zwischen dem privaten Endgerät und dem Gateway über den privaten Bereich. In der Tat funktioniert jeder Mechanismus zum Ermöglichen eines Weiterleitens von Paketen zwischen dem Gateway und dem Endgerät so lange die Weiterleitungsentscheidungen auf der privaten Adresse des privaten Hosts getroffen werden.
    • 7. Führe eine vollständige Bindung zwischen der Quell-IP-Adresse und -Portnummer, Ziel-IP-Adresse und -Portnummer und dem erzeugten Tunnel durch.
    • 8. Leite Daten unter Verwendung von IP-Adressen und Ports zu einer Tunnelabbildung weiter.
  • Die oben beschriebenen Ausführungen werden lediglich als Beispiel gegeben und es sollte selbstverständlich sein, dass die vorliegende Erfindung nicht auf diese begrenzt ist. Weitere Modifikationen, Änderungen und Verbesserungen, die die zugrunde liegenden Grundprinzipien enthalten, die hierin offenbart und beansprucht sind, liegen innerhalb des Umfangs der Erfindung.
    • [1] "IP Network Address Translator (NAT) Terminology and Considerations". P. Srisuresh, M. Holdrege, RFC 2663 der Internet Engineering Task Force, August 1999.
    • [2] "Architectural Implications of NAT", T. Hain, RFC 2993 der Internet Engineering Task Force, November 2000.
    • [3] "Realm Specific IP: Framework", M. Borella, J. Lo, D. Grabelsky, G. Montenegro, RFC 3102 der Internet Engineering Task Force, October 2001.
    • [4] "Realm Specific IP: Protocol Specification", M. Borella, D. Grabelsky, J. Lo, K. Taniguchi, RFC 3103 der Internet Engineering Task Force, October 2001.
    • [5] "Expanding the Address space through REBEKAH-IP: An Architectural View", B. Landfeldt, S. Rattananon und A. Seneviratne, ICITA02, Bathurst NSW, November 2002.
    • [6] "Providing Scalable and Deployable Addressing in Third Generation Cellular Networks", B. Landfeldt, S. Rattananon and A. Seneviratne, IEEE Wireless Communications Magazine, Vol. 10, Nr. 1, S. 36–42, Feb 2003.
    • [7] "IPv4+4,"Zolt n Turanyi, Andras Valu6, 10th International Conference an Network Protocols (ICNP 2002), Paris, November 2002.
    • [8] http://www. iana. org/numbers. html, gedruckt 28. Mai, 2003.
    • [9] "A DNS RR for specifying the location of service (DNS SRV)", A. Gulbrandsen, P. Vixie, L. Esibov, IETF RFC 2782, Februar 2000.

Claims (23)

  1. Verfahren zum Ermöglichen einer Herstellung einer Verbindung zwischen einem Knoten (A) eines Innenadressbereiches (10) und einem Knoten (B) eines Außenadressbereiches (20) über ein Zwischenkommunikations-Gateway (30) mit einem Pool von Außenbereichs-Gatewayadressen zur Außenbereichsdarstellung von Innenbereichsknoten, wobei das Verfahren die Schritte umfasst: – zentrales Allozieren in Reaktion auf eine Konfigurationsanfrage, die von dem Innenbereichsknoten (A) initiiert wird, einer Außenbereichs-Gatewayadresse aus dem Pool von Gatewayadressen und einer Innenknoten-Portnummer für den Innenbereichsknoten, wobei der Schritt eines zentralen Allozierens den Schritt eines Identifizierens umfasst, basierend auf einer vorbestimmten Verbindungsinformation, die aus der Konfigurationsanfrage ableitbar ist, einer Außenbereichs-Gatewayadresse und einer Innenknoten-Portnummer, die in Kombination mit der vorbestimmten Verbindungsinformation einen Satz von Sockelparametern definieren, der sich auf den Teil der Gateway-Zustandsdarstellung bezieht, die sich auf den Außenbereich bezieht, die kein Gegenstück in irgendeinem existierenden Gateway-Verbindungszustand besitzt; – Initiieren einer Herstellung der Verbindung zumindest teilweise basierend auf der allozierten Außenbereichs-Gatewayadresse und der Innenknoten-Portnummer; und – Übertragen der allozierten Außenbereichs-Gatewayadresse und Innenknoten-Portnummer zu dem anfragenden Innenbereichsknoten (A) in einer Konfigurationsantwort.
  2. Verfahren nach Anspruch 1, wobei die vorbestimmte Verbindungsinformation zumindest eines aus einer Außenknoten-Adressinformation und einer Außenknoten-Portinformation umfasst.
  3. Verfahren nach Anspruch 1, wobei ein Gateway-Verbindungszustand in dem Gateway (30) basierend auf der Außenbereichs-Gateway-Zustandsdarstellung und einer Darstellung eines Innenbereichs-Weiterleitungspfades zwischen dem Gateway (30) und dem Innenbereichsknoten (A) hergestellt wird.
  4. Verfahren nach Anspruch 1, wobei die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer durch eine allozierte Sockel-Netzwerkadresse und eine Quellportnummer dargestellt werden und die vorbestimmte Verbindungsinformation eine Zielnetzwerkadresse und eine Zielportnummer einschließt und die Außenbereichs-Gateway-Zustandsdarstellung durch einen eindeutigen Satz von Sockelparametern definiert wird, die die allozierte Sockel-Netzwerkadresse und eine Quellportnummer einschließen, die Zielnetzwerkadresse und die Zielportnummer.
  5. Verfahren nach Anspruch 1, wobei die Konfigurationsantwort eine DNS-Antwort (DNS – Domain Name Server) ist.
  6. Verfahren nach Anspruch 5, wobei die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer in einem dedizierten DNS-Satz in der DNS-Antwort übermittelt werden.
  7. Verfahren nach Anspruch 1, weiter mit dem Schritt des Innenbereichs-Knotens eines Konfigurierens einer Kommunikationsschnittstelle gemäß der allozierten Außenbereichs-Gatewayadresse und Innenknoten-Portnummer.
  8. Verfahren nach Anspruch 1, weiter mit dem Schritt eines Herstellens eines Innenbereichs-Weiterleitungspfades zwischen dem Gateway (30) und dem Innenbereichsknoten (A).
  9. System zum Ermöglichen einer Herstellung einer Verbindung zwischen einem Knoten (A) eines Innenadressbereiches (10) und einem Knoten (B) eines Außenadressbereiches (20) über ein Zwischenkommunikations-Gateway (30) mit einem Pool von Außenbereichs-Gatewayadressen zur Außenbereichsdarstellung von Innenbereichsknoten, wobei das System umfasst: – eine Vorrichtung (42) zum zentralen Allozieren in Reaktion auf eine Konfigurationsanfrage, die von dem Innenbereichsknoten (A) initiiert wird, einer Außenbereichs-Gatewayadresse aus dem Pool von Gatewayadressen und einer Innenknoten-Portnummer für den Innenbereichsknoten, wobei die Vorrichtung (42) zum zentralen Allozieren eine Vorrichtung zum Identifizieren umfasst, basierend auf einer vorbestimmten Verbindungsinformation, die aus der Konfigurationsanfrage ableitbar ist, einer Außenbereichs-Gatewayadresse und einer Innenknoten-Portnummer, die in Kombination mit der vorbestimmten Verbindungsinformation einen Satz von Sockelparametern definieren, der sich auf den Teil der Gateway-Zustandsdarstellung bezieht, die sich auf den Außenbereich bezieht, die kein Gegenstück in irgendeinem existierenden Gateway-Verbindungszustand besitzt; – eine Vorrichtung (40) zum Initiieren einer Herstellung der Verbindung zumindest teilweise basierend auf der allozierten Außenbereichs-Gatewayadresse und der Innenknoten-Portnummer; und – eine Vorrichtung (40) zum Übertragen der allozierten Außenbereichs-Gatewayadresse und Innenknoten-Portnummer zu dem anfragenden Innenbereichsknoten (A) in einer Konfigurationsantwort.
  10. System nach Anspruch 9, wobei die vorbestimmte Verbindungsinformation zumindest eines aus einer Außenknoten-Adressinformation und einer Außenknoten-Portinformation umfasst.
  11. System nach Anspruch 9, wobei ein Gateway-Verbindungszustand in dem Gateway (30) basierend auf der Außenbereichs-Gateway-Zustandsdarstellung und einer Darstellung eines Innenbereichs-Weiterleitungspfades zwischen dem Gateway (30) und dem Innenbereichsknoten (A) hergestellt wird.
  12. System nach Anspruch 9, wobei die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer durch eine allozierte Sockel-Netzwerkadresse und eine Quellportnummer dargestellt werden und die vorbestimmte Verbindungsinformation eine Zielnetzwerkadresse und eine Zielportnummer einschließt und die Außenbereichs-Gateway-Zustandsdarstellung durch einen eindeutigen Satz von Sockelparametern definiert wird, die die allozierte Sockel-Netzwerkadresse und eine Quellportnummer einschließen, die Zielnetzwerkadresse und die Zielportnummer.
  13. System nach Anspruch 9, wobei die Konfigurationsantwort eine DNS-Antwort (DNS – Domain Name Server) ist.
  14. System nach Anspruch 13, wobei die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer in einem dedizierten DNS-Satz in der DNS-Antwort übermittelt werden.
  15. System nach Anspruch 9, weiter mit einer Vorrichtung zum Herstellen eines Innenbereichs-Weiterleitungspfades zwischen dem Gateway (30) und dem Innenbereichsknoten (A).
  16. Gateway-Ressourcen-Manager (40) für ein Kommunikations-Gateway (30), wobei das Kommunikations-Gateway (30) einen Pool von Außenbereichs-Gatewayadressen zur Außenbereichsdarstellung von Innenbereichsknoten aufweist, wobei der Gateway-Ressourcen-Manager (40) umfasst: – eine Vorrichtung (42) zum zentralen Allozieren in Reaktion auf eine Konfigurationsanfrage, die von dem Innenbereichsknoten (A) initiiert wird, einer Außenbereichs-Gatewayadresse aus dem Pool von Gatewayadressen und einer Innenknoten-Portnummer für den Innenbereichsknoten, wobei die Vorrichtung (42) zum zentralen Allozieren eine Vorrichtung zum Identifizieren umfasst, basierend auf einer vorbestimmten Verbindungsinformation, die aus der Konfigurationsanfrage ableitbar ist, einer Außenbereichs-Gatewayadresse und einer Innenknoten-Portnummer, die in Kombination mit der vorbestimmten Verbindungsinformation einen Satz von Sockelparametern definieren, der sich auf den Teil der Gateway-Zustandsdarstellung bezieht, die sich auf den Außenbereich bezieht, die kein Gegenstück in irgendeinem existierenden Gateway-Verbindungszustand besitzt; – eine Vorrichtung (40) zum Initiieren einer Herstellung der Verbindung zumindest teilweise basierend auf der allozierten Außenbereichs-Gatewayadresse und der Innenknoten-Portnummer; und – eine Vorrichtung (40) zum Übertragen der allozierten Außenbereichs-Gatewayadresse und Innenknoten-Portnummer zu dem anfragenden Innenbereichsknoten (A) in einer Konfigurationsantwort.
  17. Gateway-Ressourcen-Manager nach Anspruch 16, wobei die vorbestimmte Verbindungsinformation zumindest eines aus einer Außenknoten-Adressinformation und einer Außenknoten-Portinformation umfasst.
  18. Gateway-Ressourcen-Manager nach Anspruch 16, wobei die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer durch eine allozierte Sockel-Netzwerkadresse und eine Quellportnummer dargestellt werden und die vorbestimmte Verbindungsinformation eine Zielnetzwerkadresse und eine Zielportnummer einschließt und die Außenbereichs-Gateway-Zustandsdarstellung durch einen eindeutigen Satz von Sockelparametern definiert wird, die die allozierte Sockel-Netzwerkadresse und eine Quellportnummer einschließen, die Zielnetzwerkadresse und die Zielportnummer.
  19. Gateway-Ressourcen-Manager nach Anspruch 16, wobei die Vorrichtung zum Initiieren einer Herstellung des Gateway-Verbindungszustand eine Vorrichtung zum Anfordern umfasst, dass das Gateway (30) einen Gateway-Verbindungszustand basierend auf der Außenbereichs-Gateway-Zustandsdarstellung und einer Darstellung eines Innenbereichs-Weiterleitungspfades zwischen dem Gateway (30) und dem Innenbereichsknoten (A) hergestellt.
  20. Gateway-Ressourcen-Manager nach Anspruch 16, wobei die allozierende Vorrichtung (42) eine Allokation in Reaktion auf eine Konfigurationsanfrage durchführt, die von dem Innenbereichsknoten (A) initiiert wird und die übertragende Vorrichtung (40) die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer zu dem Innenbereichsknoten (A) in einer Konfigurationsantwort überträgt.
  21. Gateway-Ressourcen-Manager nach Anspruch 20, wobei die Konfigurationsantwort eine DNS-Antwort (DNS – Domain Name Server) ist.
  22. Gateway-Ressourcen-Manager nach Anspruch 21, wobei die allozierte Außenbereichs-Gatewayadresse und Innenknoten-Portnummer in einem dedizierten DNS-Satz in der DNS-Antwort übermittelt werden.
  23. Verfahren eines Konfigurierens eines Innenbereichs-Kommunikationsknotens (A) zur Kommunikation mit einem Außenbereichs-Kommunikationsknoten (B) über ein Kommunikationsgateway (30) mit einem Pool von Außenbereichs-Gatewayadressen zur Außenbereichsdarstellung von Innenbereichsknoten, wobei das Verfahren die Schritte umfasst: – zentrales Allozieren einer Außenbereichs-Gatewayadresse aus dem Pool von Gatewayadressen und einer Innenknoten-Portnummer für den Innenbereichsknoten (A), wobei der Schritt eines zentralen Allozierens den Schritt eines Identifizierens umfasst, basierend auf einer vorbestimmten Verbindungsinformation, die aus der Konfigurationsanfrage ableitbar ist, einer Außenbereichs-Gatewayadresse und einer Innenknoten-Portnummer, die in Kombination mit der vorbestimmten Verbindungsinformation einen Satz von Sockelparametern definieren, der sich auf den Teil der Gateway-Zustandsdarstellung bezieht, die sich auf den Außenbereich bezieht, die kein Gegenstück in irgendeinem existierenden Gateway-Verbindungszustand besitzt; – Übertragen der allozierten Außenbereichs-Gatewayadresse und Innenknoten-Portnummer zu dem anfragenden Innenbereichsknoten (A); und – Konfigurieren des Innenbereichs-Kommunikationsknoten (A) gemäß der allozierten Außenbereichs-Gatewayadresse und Innenknoten-Portnummer.
DE60320042T 2003-04-01 2003-08-08 Verfahren und system zur zentralen zuweisung von adressen und portnummern Expired - Lifetime DE60320042T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US45934603P 2003-04-01 2003-04-01
US459346P 2003-04-01
PCT/SE2003/001261 WO2004088923A1 (en) 2003-04-01 2003-08-08 Method and system for centrally allocating addresses and port numbers

Publications (2)

Publication Number Publication Date
DE60320042D1 DE60320042D1 (de) 2008-05-08
DE60320042T2 true DE60320042T2 (de) 2009-05-14

Family

ID=33131881

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60320042T Expired - Lifetime DE60320042T2 (de) 2003-04-01 2003-08-08 Verfahren und system zur zentralen zuweisung von adressen und portnummern

Country Status (8)

Country Link
US (1) US20060259625A1 (de)
EP (1) EP1614252B1 (de)
CN (1) CN100431299C (de)
AT (1) ATE390776T1 (de)
AU (1) AU2003251265A1 (de)
BR (1) BR0318156A (de)
DE (1) DE60320042T2 (de)
WO (1) WO2004088923A1 (de)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8176006B2 (en) * 2003-12-10 2012-05-08 Cisco Technology, Inc. Maintaining and distributing relevant routing information base updates to subscribing clients in a device
JP4279135B2 (ja) * 2003-12-26 2009-06-17 パナソニック株式会社 ホームゲートウェイ装置
CN1926840A (zh) * 2004-03-02 2007-03-07 皇家飞利浦电子股份有限公司 在至少两台计算设备间建立连接时的地址和端口号提取
JP2005303914A (ja) * 2004-04-15 2005-10-27 Murata Mach Ltd 通信装置及びプログラム
DE502004002250D1 (de) * 2004-10-04 2007-01-18 Cit Alcatel Vorrichtungen und Verfahren zum Führen von bidirektionellen Verbindungen über eine zwischengeschaltete Firewall mit Adresstransformationsgerät
US7600011B1 (en) * 2004-11-04 2009-10-06 Sprint Spectrum L.P. Use of a domain name server to direct web communications to an intermediation platform
KR100705564B1 (ko) * 2004-12-10 2007-04-10 삼성전자주식회사 네트워크에서의 자원 관리 장치 및 방법
EP1694034B1 (de) * 2005-02-16 2014-05-21 Alcatel Lucent Methode zum Aufbau einer Peer-to-Peer Verbindung zwischen zwei Benutzer-Agenten die hinter symmetrischen NATs angeordnet sind
EP1894371A1 (de) * 2005-05-18 2008-03-05 Ninety9.com PTY Ltd. Dynamische adressenabbildung
US8396981B1 (en) * 2005-06-07 2013-03-12 Oracle America, Inc. Gateway for connecting storage clients and storage servers
JP4635855B2 (ja) * 2005-12-13 2011-02-23 株式会社日立製作所 データ通信方法およびシステム
WO2007147424A1 (de) * 2006-06-21 2007-12-27 Siemens Home And Office Communication Devices Gmbh & Co. Kg Vorrichtung und verfahren zum adress-mapping
US20110209000A1 (en) * 2008-10-07 2011-08-25 Telefonaktiebolaget L M Ericsson (Publ) Systems and Methods for Allocating Network Resources From One Address Realm to Clients in a Different Address Realm
WO2010053413A1 (en) 2008-11-05 2010-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for improved configuration of a network device
CN102428690B (zh) * 2009-05-13 2015-04-15 皇家飞利浦电子股份有限公司 在分段网络中分配网络地址以用于通信的方法
US8990424B2 (en) * 2009-09-08 2015-03-24 Wichorus, Inc. Network address translation based on recorded application state
US8942233B2 (en) * 2009-09-08 2015-01-27 Wichorus, Inc. Method and apparatus for performing network address translation
US7965630B1 (en) 2009-09-08 2011-06-21 Southern Company Services, Inc. Load balancing port proxy for dynamically controlling routing of query requests
US9013992B2 (en) * 2009-09-08 2015-04-21 Wichorus, Inc. Method and apparatus for network address translation
FI124455B (fi) * 2010-04-20 2014-09-15 Tellabs Oy Menetelmä ja laite verkko-osoitteiden konfiguroimiseksi
WO2012131287A1 (en) * 2011-04-01 2012-10-04 British Telecommunications Plc. Selection of service nodes for provision of services
US9385990B2 (en) * 2011-11-30 2016-07-05 Murata Machinery, Ltd. Relay server and relay communication system
WO2014079050A1 (zh) * 2012-11-23 2014-05-30 华为技术有限公司 一种逻辑对象部署方法、相关装置及系统
US9009353B1 (en) * 2014-04-11 2015-04-14 Cable Television Laboratories, Inc. Split network address translation
CN105453488B (zh) * 2014-04-22 2019-01-18 柏思科技有限公司 用于处理dns请求的方法和系统
CN104519062A (zh) * 2014-12-17 2015-04-15 深圳市航盛电子股份有限公司 一种创建多对socket端口连接的方法及系统
US10135916B1 (en) 2016-09-19 2018-11-20 Amazon Technologies, Inc. Integration of service scaling and external health checking systems
US10182033B1 (en) * 2016-09-19 2019-01-15 Amazon Technologies, Inc. Integration of service scaling and service discovery systems
US10944804B1 (en) * 2017-11-22 2021-03-09 Amazon Technologies, Inc. Fragmentation of time-associated data streams
US11025691B1 (en) 2017-11-22 2021-06-01 Amazon Technologies, Inc. Consuming fragments of time-associated data streams
US10878028B1 (en) 2017-11-22 2020-12-29 Amazon Technologies, Inc. Replicating and indexing fragments of time-associated data streams
US10764347B1 (en) 2017-11-22 2020-09-01 Amazon Technologies, Inc. Framework for time-associated data stream storage, processing, and replication
US11146528B2 (en) 2019-11-13 2021-10-12 Sprint Communications Company L.P. Wireless communication service delivery over co-located gateway user planes
US10951575B1 (en) 2019-11-13 2021-03-16 Sprint Communications Company L.P. Domain name system (DNS) translations for co-located Gateway User Planes in wireless communication networks
CN111083666B (zh) * 2019-12-17 2024-02-23 联合汽车电子有限公司 网络节点标序方法、网络节点和网络系统
CN113014691B (zh) * 2021-03-16 2022-05-13 中国科学技术大学 节点地址的分配方法及装置
US11765238B1 (en) * 2022-06-21 2023-09-19 Juniper Networks, Inc. Non-translated port oversubscribing for a proxy device

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100248674B1 (ko) * 1997-12-29 2000-03-15 이계철 위성 멀티미디어 서비스 제공 방법 및 시스템
US6119171A (en) * 1998-01-29 2000-09-12 Ip Dynamics, Inc. Domain name routing
US6353614B1 (en) * 1998-03-05 2002-03-05 3Com Corporation Method and protocol for distributed network address translation
US7299294B1 (en) * 1999-11-10 2007-11-20 Emc Corporation Distributed traffic controller for network data
KR100689034B1 (ko) * 2000-08-26 2007-03-08 삼성전자주식회사 외부 네트워크에서 사설 아이피주소를 갖는 노드에접속하기 위한 네트워크 주소변환시스템과 방법 및 그방법을 기록한 컴퓨터로 읽을수 있는 기록매체
JP2002353996A (ja) * 2001-05-30 2002-12-06 Nec Corp ネットワーク、ブリッジ装置及びそれに用いるフィルタリングデータベース構築方法並びにそのプログラム
JP3800038B2 (ja) * 2001-06-08 2006-07-19 ティアック株式会社 ネットワーク装置及びサーバ装置及びクライアント装置及びネットワークのｉｐアドレス付与方法及びプログラム
US20030084162A1 (en) * 2001-10-31 2003-05-01 Johnson Bruce L. Managing peer-to-peer access to a device behind a firewall
KR100423500B1 (ko) * 2002-01-29 2004-03-18 삼성전자주식회사 인터넷 프로토콜 주소 변환장치 및 이를 이용한홈네트워크 시스템
US20080045267A1 (en) * 2003-03-19 2008-02-21 Research In Motion Limited System and Method for Pushing Information from a Host System to a Mobile Data Communication Device in a Wireless Data Network
US20040210663A1 (en) * 2003-04-15 2004-10-21 Paul Phillips Object-aware transport-layer network processing engine
US7624195B1 (en) * 2003-05-08 2009-11-24 Cisco Technology, Inc. Method and apparatus for distributed network address translation processing

Also Published As

Publication number Publication date
WO2004088923A1 (en) 2004-10-14
US20060259625A1 (en) 2006-11-16
EP1614252A1 (de) 2006-01-11
EP1614252B1 (de) 2008-03-26
DE60320042D1 (de) 2008-05-08
BR0318156A (pt) 2006-02-21
ATE390776T1 (de) 2008-04-15
CN100431299C (zh) 2008-11-05
CN1765081A (zh) 2006-04-26
AU2003251265A1 (en) 2004-10-25

Similar Documents

Publication Publication Date Title
DE60320042T2 (de) Verfahren und system zur zentralen zuweisung von adressen und portnummern
DE10392494B4 (de) Mechanismen zum Bereitstellen von Verbindbarkeit zwischen Netzen unterschiedlicher Adressbereiche
DE60211897T2 (de) Verfahren, Speichermedium, Netwerk und Apparat für eine biderektional initierte Datenkommunikation mit einer drahtlosen Einrichtung
US8451844B2 (en) Method of receiving a data packet coming from an IPv4 domain in an IPv6 domain, an associated device, and associated access equipment
US8451845B2 (en) Method of receiving a data packet in an IPv6 domain, an associated device and an associated home gateway
DE60223264T2 (de) System und verfahren zur adressierung eines mobilen gerätes in einem ip-basierten drahtlosen netzwerk
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE60033162T2 (de) Erleichterung der datenübertragung
KR101210388B1 (ko) Ｉｐ 터널링 기술을 이용한 폐쇄 사용자 네트워크 구성 방법 및 폐쇄 사용자 네트워크 시스템
DE60024237T2 (de) Verfahren und system zur netzwerkadressübersetzung mit sicherheitseigenschaften
Huang et al. Dual-stack hosts using" bump-in-the-host"(BIH)
US20130013739A1 (en) DNS Server, Gateways and Methods for Managing an Identifier of a Port Range in the Transmission of Data
DE69827474T2 (de) Kommunikationsverfahren in einer gesamtheit von verteilten systemen über ein netzwerk vom typ internet
WO2009046729A1 (de) Verfahren und vorrichtung zur verbindung paketorientierter kommunikationsendgeräte
EP1897340B1 (de) Vorrichtung und verfahren zum adress-mapping
EP1593253A1 (de) Verfahren und anordnung zur transparenten vermittlung des datenverkehrs zwischen datenverarbeitungseinrichtungen sowie ein entsprechendes computerprogamm-erzeugnis und ein entsprechendes computerlesbares speichermedium
Turányi et al. IPv4+ 4
KR20050039880A (ko) 제 1 컴퓨터 네트워크로부터 제 2 컴퓨터 네트워크로의통신 세션들 개시
EP4096170B1 (de) Verfahren zur datenübertragung in einem netzwerksystem sowie netzwerksystem
US20230388397A1 (en) Resolving Overlapping IP Addresses in Multiple Locations
Davies TCP/IP Fundamentals for Microsoft Windows
Santos Private realm gateway
EP1429523A1 (de) Öffentliche Adressierung unterstützt von temporärer privaten Adressierung
Jamhour et al. Global mobile IPv6 addressing using transition mechanisms
Huang et al. RFC 6535: Dual-Stack Hosts Using" Bump-in-the-Host"(BIH)

Legal Events

Date Code Title Description
8364 No opposition during term of opposition