DE60127276T2

DE60127276T2 - Verfahren und vorrichtung zur erleichterung der peer-zu-peer anwendungskommunikation

Info

Publication number: DE60127276T2
Application number: DE60127276T
Authority: DE
Inventors: Andrew T. Arden Hills MOLITOR
Original assignee: Alcatel USA Sourcing Inc
Current assignee: Nokia of America Corp
Priority date: 2000-09-13
Filing date: 2001-09-04
Publication date: 2007-12-20
Anticipated expiration: 2021-09-05
Also published as: CN1531801A; WO2002023822A1; EP2068499A1; DE60138058D1; JP2004509517A; EP1323261A1; EP1793533B1; JP4908724B2; EP2068499B1; EP1793533A1; AU2001287054A1; CN101668051B; CN100512165C; EP1323261A4; EP1793533B8; USRE43057E1; US6661799B1; DE60127276D1; CN101668051A; USRE44593E1

Description

HINTERGRUND DER ERFINDUNG
1. GEBIET DER ERFINDUNG
Diese Erfindung betrifft Einrichtungen zum Verarbeiten von Kommunikationen zwischen Anwendungen, die Daten über das Internet austauschen. Insbesondere betrifft diese Erfindung eine Netzadressen-Übersetzungseinrichtung (NAT = Network Address Translation) sowie ein System und ein Verfahren, die eine solche NAT-Einrichtung zum Erleichtern der Peer-zu-Peer Kommunikation von Daten über das Internet benutzen.
2. BESCHREIBUNG DES STANDES DER TECHNIK
Wie in 1 gezeigt ist, wird eine Netzadressen-Übersetzungseinrichtung (NAT-Einrichtung) 20 der herkömmlichen Art normalerweise innerhalb eines Internetprotokollnetzes (IU-Netz) an die Grenze zwischen zwei disparaten Adressenbereichen 50 und 30 positioniert. Ein Bereich 50 kann das private Internnetz 10 einer Organisation sein, und der andere Bereich 30 kann das öffentliche globale Internet sein. Das von einer solchen herkömmlichen Einrichtung angegriffene Problem besteht darin, dass eine Organisation ein großes Internnetz benötigen kann, das viele Einrichtungen enthält, wobei jede Einrichtung eine eindeutige IU-Adresse benötigt. Im Hinblick auf den gegenwärtig verfügbaren Raum für eindeutige IP-Adressen (2³² verfügbare Adressen) und gegenwärtige Adressenzuteilungsmuster, kann es dieser Organisation unmöglich sein, von den solche Adressen zuweisenden Behörden eine ausreichende Anzahl von offiziellen IU-Adressen zugeteilt zu bekommen. Deshalb wird die Organisation effektiv dazu gezwungen, intern gültige Adressen für ihr eigenes Internnetz zu bilden. Das ermöglicht dem Internnetz, korrekt zu funktionieren; es ist nicht erforderlich, in einem solchen Zusammenhang offiziell zugewiesene IU-Adressen zu verwenden. Die Schwierigkeit ergibt sich, wenn Einrichtungen oder Anwendungen (Programme, die auf einer bestimmten Einrichtung laufen) im großen Internnetz mit dem Globalen Internet (darunter verstehen wir irgendein IU-Netz, privat oder öffentlich, das offiziell zugewiesene IP-Adressen benutzt) kommunizieren müssen. Da die von der Organisation intern zugewiesenen IU-Adressen entweder mit offiziell zugewiesenen Adressen einer anderen Organisation überlappen oder offiziell nicht zugewiesen sind, kann das Globale Internet sie nicht benutzen, um Daten korrekt in das Internnetz der Organisation zu senden. Um beispielsweise Daten an eine netzverbundene Einrichtung zu senden, muss die versendende Anwendung eine Adresse für die Zielanwendung haben, und das die Daten empfangende Netz selbst muss wissen, wie die Zielanwendung lokalisiert wird. Diese Operationen funktionieren nur dann, wenn alle beteiligten Anwendungen darin übereinstimmen, welche Adressen zu welchen Einrichtungen und Anwendungen gehören.
Eine Lösung besteht für die Organisation darin, sich eine Menge offizieller IU-Adressen zuteilen zu lassen. Diese Adressen sind eindeutig. Jede Anwendung auf dem Globalen Internet, die Daten an diese Adressen sendet, kann sich darauf verlassen, dass diese Daten am Eingang zum Internnetz der Organisation ankommen. Das heißt, dass die Infrastruktur des Globalen Internets Daten korrekt an die Organisation liefert und sich dann (was für IP der Normalfall ist) auf die Organisation verlässt, die korrekte Endpunktanwendung für die Endlieferung innerhalb der Organisation zu lokalisieren.
Die Organisation könnte dann jede der irh zugewiesenen offiziellen IU-Adressen für einen unbestimmten Zeitraum einer einzelnen Anwendung zuteilen und einigen wenigen bevorzugten Anwendungen Internetzugriff erlauben. Eine bessere Lösung, die ausgedehnteren Zugriff erlaubt, besteht in der Verwendung einer Einrichtung, die effektiv die offiziell zugeteilten IP-Adressen jedweder Anwendung dynamisch zuweist, die zu einem gegebenen Zeitpunkt Zugriff auf das Globale Internet benötigt. Adressen werden von Anwendungen, die sie nicht mehr verwenden, zurückgewonnen und für Wiederzuweisung verfügbar gemacht. Dieses System der gemeinsamen Nutzung funktioniert sehr gut und ist in der einfachsten Form genau das, was ein herkömmlicher Netzadressen-Übersetzer (NAT) normalerweise macht. (Siehe RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations, veröffentlicht von der Internet Engineering Task Force (IETF). Das ist das IETF-Grunddokument, das den Betrieb und die Probleme beschreibt, die die NAT-Einrichtungen betreffen.) Einer Organisation wird oft eine sehr kleine Anzahl von offiziellen IP-Adressen zugewiesen. Einer Organisation werden vielleicht nur 31 oder 255 solcher Adresse gegeben. Für eine Organisation mit Tausenden von Anwendungen auf ihrem Internnetz kann ein naiver NAT, der nur offizielle IP-Adressen zuweisen kann, möglicherweise nicht ausreichen. Können nur 31 von sagen wir mal 5000 Anwendungen (von denen jede einem einzelnen Mitarbeiter entsprechen könnte) das Globale Internet gleichzeitig benutzen, könnte man das Problem als nicht ausreichend gelöst ansehen.
Um die nützliche Größe des offiziell zugeteilten Adressenpools wirkungsvoll zu vergrößern, wird der NAT der Organisation normalerweise in der Lage sein, dieselbe offizielle IP-Adresse für mehrfache interne Anwendungen zu verwenden. An eine bestimmte offizielle IP-Adresse, sagen wir mal X, gerichtete Daten können weiter unterschieden werden, indem sie zu einem von mehreren Datenströmen gehören, sagen wir mal A, B und C. Der NAT kann die Adresse X, Strom A einem spezifischen Datenstrom für eine Anwendung zugewiesen haben, während Adresse X, Ströme B und C zwei verschiedenen anderen Anwendungen gehören.
Die Stromkennungen werden Portnummern genannt. Ein Datenstrom in einem IP-Netz ist eindeutig durch das sogenannte „5-Tupel" identifiziert, das aus 5 separaten numerischen Quantitäten besteht:

1) Quell-IP-Adresse
2) Ziel-IP-Adresse
3) Quellportnummer
4) Zielportnummer
5) Transportprotokoll

Jedes Datenstück (Paket) in einem IP-Netz enthält diese 5 numerischen Kennungen. Die beiden IP-Adressen (die obigen Posten 1 und 2) identifizieren mehr oder weniger die Quell- und Zielanwendungen. Das Protokoll identifiziert, welche der Mechanismen zum Sichern eines zuverlässigen Transports benutzt werden. Für die gegenwärtigen Zwecke wird das Protokoll ignoriert, weil es von einem NAT nicht viel genutzt wird. Die Quell- und Zielports (die obigen Posten 3 und 4) identifizieren, welche Anwendung innerhalb des Netzes dieses Paket gesendet hat bzw. empfangen wird.
Ein herkömmlicher Netzadressenübersetzer (z. B. ein Private Internet Exchange (PLX), hergestellt von Cisco Systems, Inc., in San Jose, CA), wie er in diesem Dokument gesehen wird, arbeitet durch Änderung dieser fünf numerischen Kennungen innerhalb eines Pakets. Wie oben bemerkt, befindet sich eine NAT-Einrichtung an der Grenze zwischen zwei Adressenbereichen, und zwar normalerweise, aber nicht immer, dem Globalen Internet und dem privaten Netz einer Organisation, wo diese beiden Netze nichtkompatible IP-Adressenschemata haben. Eine NAT-Einrichtung benutzt intelligentes Neuschreiben der vier Quell-/Zielelemente innerhalb eines jeden sie durchlaufenden Pakets, um jedem der beiden Netze eine falsche, aber kompatible Ansicht des IP-Adressenschemas des anderen Netzes anzuzeigen. Jeder NAT muss eine Menge von Regeln haben, das die Paarung der Intern- und Externadressen definiert, die er für die Adressenübersetzung benutzten wird. Ein nützlicher NAT muss diese Paarungen aufbauen, um internen Anwendungen zu ermöglichen, die verfügbaren Externadressen wirkungsvoll zu benutzen, die begrenzt sein werden, wenn der externe Bereich offizielle IP-Adressen benötigt.
Eine mit einem Internnetz assoziierte herkömmliche NAT-Einrichtung unterstützt im Wesentlichen zwei gleichzeitige Modi Operandi. Der erste ermöglicht Datentransaktionen von Anwendungen auf dem Internnetz nach außen an das Globale Internet (beispielsweise ein Geschäftsbenutzer, der auf eine Webseite zugreift). Dies ist der Zugriff eines Internen Clienten auf einen Externen Server. Der zweite ermöglicht Anwendungen auf dem Globalen Internet auf spezifische Dienste auf spezifischen Einrichtungen auf dem Internnetz zuzugreifen (beispielsweise ein Kunde, der auf die Website einer Organisation zugreift). Dies ist der Zugriff eines Externen Clienten auf einen Internen Server. Die herkömmliche NAT-Einrichtung baut diese Adressenpaarung, die die erste und zweite Zugriffsart ermöglicht, auf etwas verschiedene Weisen auf.
Eine herkömmliche NAT-Einrichtung implementiert den ersten Modus wie folgt: Wenn das erste Datenpaket auf der NAT-Einrichtung ausgehend ankommt, untersucht die NAT-Einrichtung die Quelladresse und den Port (die die interne Einrichtung und die Anwendung identifizieren, die das Paket erzeugt haben). Der NAT wählt dann aus seinem Pool von verfügbaren offiziellen Adressen und Ports eine extern gültige IP-Adresse und einen Port aus, die anstelle der intern gültigen Quelladresse und des Ports im Paket benutzt werden. Die Figur von der intern gültigen Quelladresse und dem Port auf die extern gültige Quelladresse und den Port wird irgendwie im NAT gepflegt, beispielsweise in einer Tabelle, die die Zuordnungsregel definiert. Schließlich modifiziert der NAT die intern gültigen Quelladressen- und Portfelder im ausgehenden Paket und leitet es weiter. Wenn ein eingehendes Antwortpaket, das auf das erste Paket antwortet, von außen beim NAT ankommt, dann passen die Zieladresse und der Port im Antwortpaket zu der extern gültigen Quelladresse und dem Port (da in einer Antwort die Absenderadresse und Empfängeradresse natürlich ganz wie sagen wir mal bei einem Postbrief, ausgetauscht werden). Der NAT benutzt diese eingehende extern gültige Quelladresse und den Port, um die intern gültige Quelladresse und den Port aus dem ersten ausgehenden Paket zu lokalisieren. Der NAT benutzt dann die lokalisierte, intern gültige Quelladresse und den Port, um die Zieladresse und den Port in diesem eingehenden Antwortpaket zu ersetzen. Jetzt hat das eingehende Antwortpaket die korrekte intern gültige Zieladresse und den Port zur Lieferung an die Einrichtung und Anwendung, die das erste ausgehende Paket gesendet haben.
Eine herkömmliche NAT-Einrichtung implementiert den zweiten Modus unter Verwendung der vom NAT-Administrator definierten festen Konfigurationsinformation zur Zuordnung von Intern- und Externadressen. Für diesen Modus ist das erste Paket eingehend, es kommt von außen am NAT mit etwas Zielinformation an, die eine der offiziell zugeordneten IP-Adressen enthält, weil diese extern gültigen Adressen die einzigen IP-Adressen sind, die das Globale Internet benutzen kann, um Pakete mit dem NAT an die Zielorganisation zu liefern. Der NAT in der Zielorganisation zieht seine Konfigurationsinformation zurate, um zu bestimmen, welche (feste) intern gültige Ziel-IP-Adresse und welchen Port er benutzen sollte, um die im eingehenden Paket enthaltene extern gültige Zieladresse und den Port zu ersetzen. Wenn im Effekt eine Anwendung (sagen wir mal ein Webserver) bei der Zielorganisation auf der internen Einrichtung A (eine inoffizielle, aber intern gültige IP-Adresse) vorhanden ist, die Pakete am Port X erwartet, könnte der NAT dazu konfiguriert sein, zu erkennen, dass an IP-Adresse M (offiziell zugewiesen und extern gültig), Port Y adressierte Pakete an die intern gültige Adresse Einrichtung A/Port X zu readressieren sind. Eine andere Anwendung in der Zielorganisation könnte auf einer anderen internen Einrichtung laufen, die extern als Einrichtung B bei Port Z identifiziert ist, und der NAT könnte eine Paarung von Intern- und Extemadressen für diese Anwendung benutzen unter Verwendung derselben internen Adresse A und eines anderen Ports, wiederum gemäß einigen festen, vordefinierten Konfigurationsdaten.
Die Schwierigkeit besteht darin, dass der erste Modus nur Internen Clienten erlaubt, Daten an Externe Server zu senden (und danach von ihnen zu empfangen), während der zweite Modus Externen Clienten nur erlaubt, Daten an eine kleine Menge von Internen Servern an festen IP-Adressen und Ports zu senden (und danach von ihnen Antworten zu empfangen), die im NAT als mit den Internen Servern assoziiert vordefiniert sind. Transaktionen, in denen sich ein Externer Client an einen gerade erzeugten Internen Server an einer gerade zugeordneten Portnummer anbindet, werden nicht unterstützt.
Eine Vielfalt von Referenzen zum Stand der Technik erörtern NAT-Einrichtungen und Variationen ihrer elementaren Adressenübersetzungsfunktionen: U.S. Patent 6055236 betitelt „Method And System For Loacating Network Services With Distributed Network Address Translation" behandelt Verfahren, um einen Dienst auf sichere Weise effektiv bekannt zu machen. U.S. Patent 6055236 äußert sich nicht zum Symmetrieproblem des Bereitstellens von Adressen für clientseitige Information und konzentriert sich völlig auf die externe Bekanntmachung von nützlichen Adressen für Server, ohne etwas über die von Clienten zu benutzenden externen Adressen auszusagen.
U.S. Patent 5793763 betitelt „Security System For Network Address Translation Systems" ist ein Patent für eine Art von NAT-Einrichtung, die allerdings nur IP-Adressen übersetzt und sich mit Sicherheitsüberlegungen beschäftigt. Die Lehre enthält nichts zum Thema des Portnummerngebrauchs, um den verfügbaren „logischen" Adressenraum zu erweitern.
In „An Expanded NAT with Server Connection Ability" beschreiben Lee et al. einen erweiterten NAT, der die Anbindung von einem Externnetz an einen spezifischen internen Server ermöglicht, wobei nur eine Modifikation der NAT-Tabelle verwendet wird. Die NAT-Tabelle ist durch Konfigurieren der Portnummern modifiziert, sodass die externe Portnummer für jede in der NAT-Tabelle registrierte Anwendung mit der internen Portnummer übereinstimmt. So müssen verschiedene interne IP-Adressen verschiedene Portnummern für eine Anwendung benutzen, um einen Konflikt zu vermeiden. Inter-private Netzanbindung ist nur durch vorheriges Übereinkommen zwischen Netzmanagern unter Verwendung einer Verbindungstabelle für das inter-private Netz, virtueller IP-Köpfe und des erweiterten NAT-Algorithmus verfügbar.
SOCKS. SOCKS ist ein Standard der Internet Engineering Task Force (IETF), der einen Mechanismus bereitstellt, mit dem eine Anwendung eine Anwendungs-Firewall hinsichtlich einer extern nützlichen Adresse befragen kann, die sie einer Fernclientanwendung bekannt machen kann. SOCKS ist der Proxy dieser Anwendung, der ähnliche Dienste wie ein NAT bereitstellt, aber ganz anders funktioniert. SOCKS schreibt den durch die Einrichtung fließenden Paketinhalt nicht neu, sondern wird (wie jeder Anwendungsproxy) zwei Kommunikationskanäle schließen und auf höherer Ebene in sich selbst logisch miteinander verbinden. Beispielsweise könnte ein Server auf der Innenseite eines Netzes seinen Dienst starten und dann am Rande des Netzes an eine SOCKS-Anwendung eine Anforderung richten. Die SOCKS-Anwendung wird auf ihrem Host einen „dünnen" Server starten und dann dem ursprünglichen Server Adresse und Port mitteilen, wo der „dünne" Server aufgefunden werden kann. Der ursprüngliche Server kann diese Information an den Clienten weiterleiten, der an den „dünnen" Server anbindet, den SOCKS bedient. SOCKS wird dann an den ursprünglichen Server als Client anbinden und dann vom externen Clienten empfangene Daten an den ursprünglichen Server kopieren und außerdem vom ursprünglichen Server empfangene Daten nach außen zum externen Clienten zurückzukopieren. Insbesondere ist SOCKS kein NAT und arbeitet nicht Paket um Paket, was bestimmte Leistungs- und Skalierungsimplikationen hat. Für weitere Informationen über SOCKS siehe http://www.socks.nec.com.
Es wird eine Zunahme im Gebrauch von IP-Netzen erwartet, um Daten zu senden, die aus digitalisierter Sprache, Sound oder Video („Medien"-Inhalt) bestehen. Es besteht Bedarf an einem Verfahren und einer Vorrichtung für Netzadressenübersetzung, die den Peer-zu-Peer Datenaustausch erleichtert, einschließlich der Mediensendung über das Internet und andere IP-Netze.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Aspekt der vorliegenden Erfindung stellte eine Netzadressen-Übersetzungseinrichtung bereit zum Erleichtern der Nachrichtenpaketkommunikation zwischen einer ersten Anwendung mit einer in einem Internadressenbereich gültigen Internadresse und einer oder mehreren Anwendungen in einem Externadressenbereich, wobei die Netzadressen-Übersetzungseinrichtung über eine Menge von verfügbaren Adressen verfügt, die zum Gebrauch im Externadressenbereich gültig sind, umfassend:
einen Adressenübersetzer zum Übersetzen von Adressen, die in den Köpfen von in den Internadressenbereich eingehenden und von ihm ausgehenden Nachrichtenpaketen enthalten sind, gemäß Übersetzungsregeln, die die Unvereinbarkeit der Adressenschemata der Intern- und Externadressenbereiche auflösen;
einen Adressenmanager zum Festlegen und Abspeichern der Übersetzungsregeln, wobei der Adressenmanager auf die Menge der verfügbaren Adressen Zugriff hat, die zum Gebrauch im Externadressenbereich gültig sind;
dadurch gekennzeichnet, dass die Netzadressen-Übersetzungseinrichtung außerdem Folgendes umfasst:
ein im Adressenmanager enthaltenes Mittel zur Kommunikation mit der ersten Anwendung über einen Steuerkanal, wobei die Kommunikation einschließt, dass der Adressenmanager von der ersten Anwendung eine Dienstanforderungsnachricht empfängt, die das Festlegen einer von der ersten Anwendung spezifizierten Adressenübersetzungsregel anfordert;
worin der Adressenmanager Logik umfasst zum Bereitstellen von Diensten als Reaktion auf die Dienstanforderung der ersten Anwendung, eine von der ersten Anwendung in der Dienstanforderungsnachricht spezifizierte Übersetzungsregel festzulegen.
Ein weiterer Aspekt der vorliegenden Erfindung stellt ein Verfahren bereit zum Erleichtern der Nachrichtenpaketkommunikation zwischen einer ersten Anwendung mit einer in einem Internadressenbereich gültigen Internadresse und einer oder mehreren Anwendungen in einem Externadressenbereich, wobei die Netzadressen-Übersetzungseinrichtung über eine Menge von Adressen verfügt, die zum Gebrauch im Externadressenbereich gültig sind, die folgenden Verfahrensschritte umfassend:
eine Netzadressen-Übersetzungseinrichtung im Internadressenbereich, Adressen übersetzend, die in den Köpfen von in den Internadressenbereich eingehenden und von ihm ausgehenden Nachrichtenpaketen enthalten sind, gemäß Übersetzungsregeln, die die Unvereinbarkeit der Adressenschemata der Intern- und Externadressenbereiche auflösen; und
einen Adressenmanager, der die Übersetzungsregeln festlegt und abspeichert, wobei der Adressenmanager auf die Menge der verfügbaren Adressen Zugriff hat, die zum Gebrauch im Externadressenbereich gültig sind;
gekennzeichnet durch:
den Adressenmanager, mit der ersten Anwendung über einen Steuerkanal kommunizierend, wobei die Kommunikation einschließt, dass der Adressenmanager von der ersten Anwendung eine Dienstanforderungsnachricht empfängt, die das Festlegen einer von der ersten Anwendung spezifizierten Adressenübersetzungsregel anfordert; und
worin die Logik des Adressenmanagers als Reaktion auf die Dienstanforderung der ersten Anwendung eine Übersetzungsregel festlegt, die durch die erste Anwendung in der Dienstanforderungsnachricht spezifiziert ist.
In einer erfindungsgemäßen Ausführungsart sind die Anwendungen für IP-Telefonie verbundene Entitäten. In einer anderen erfindungsgemäßen Ausführungsart legt der Adressenmanager komplexere Übersetzungsregeln fest, sodass eine extern gültige Zieladresse in eine intern gültige Adresse eines Werts oder eines anderen Werts übersetzt werden könnte, was von der eingehenden Quelladresse abhängt. Bestimmte Fernadressen, größere Mengen von Fernadressen oder irgendeine Fernadresse könnten als Auslöser zur Verwendung spezieller komplexerer NAT-Regeln benutzt werden. In einer weiteren Ausführungsart ist eine Anwendung dazu programmiert, die vom Adressenmanager festgelegten Übersetzungsregeln innerhalb spezifizierter Bereiche zu steuern.
BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm, das eine NAT-Einrichtung zeigt, wie sie in einem dem Stand der Technik entsprechenden Netz benutzt wird, um ein Internnetz mit mehrfachen Einrichtungen oder Anwendungen an das Internet anzubinden.
2 ist ein Blockdiagramm, das eine NAT-Einrichtung zeigt, die Adressenübersetzung nach dem Stand der Technik ausführt.
3 ist ein Blockdiagramm, das eine NAT-Einrichtung nach einer Ausführungsart der vorliegenden Erfindung zeigt zum Erleichtern der Kommunikation zwischen einer Anwendung in dem vom NAT bedienten Adressenbereich und einer Anwendung in einem anderen Adressenbereich.
DETAILLIERTE BESCHREIBUNG
I. PEER-ZU-PEER ANWENDUNGEN
Ein System, das die vorliegende Erfindung benutzt, ist nützlich zumindest für die neue Klasse von Internetanwendungen, die auf eine Peer-zu-Peer Weise (zwei oder mehrere beliebig positionierte Einrichtungen, die im Wesentlichen symmetrisch kommunizieren) arbeitet, im Gegensatz zum traditionellen Modell, in dem eine Einrichtung einen bekannten Standort (IP-Adresse) hat und die andere einen bekannten Standort (IP-Adresse) haben kann, aber nicht haben muss.
Die neue Generation von Internetanwendungen wie IP-Telefonie, Instant Messaging usw. erlaubt Benutzern auf Netzen in verschiedenen Adressenbereichen, wechselseitig ihre Computer direkt zu verbinden, um Daten gemeinsam zu nutzen oder zusammenzuarbeiten oder nur in einer kontinuierlichen, echtzeitlichen Interaktion zu chatten. In diesen Protokollen wird jeder Benutzer eine Anwendung installieren, die als Mikroserver bezeichnet werden könnte, und dann an den anderen Computer, der in einem anderen Adressenbereich positioniert ist, eine IP-Adresse und einen Port kommunizieren, wo dieser Mikroserver erreicht werden kann. (Das ist der „gerade installierte interne Server" an der „gerade zugeordneten Portnummer", den eine herkömmliche NAT-Einrichtung nicht verarbeitet.) Um die Peer-zu-Peer Verbindung fertig zu stellen, lanciert dann der Computer eines jeden Benutzers eine Clientanwendung, um an den Mikroserver im Adressenbereich des anderen Computers anzubinden. Den jeweiligen Clientanwendungen muss dann eine Adresse gegeben werden, an der der Mikroserver auf dem anderen Computer im anderen Adressenbereich erreicht werden kann. Danach kann die Zweiwegkommunikation zwischen den zwei Client/Mikroserver-Paaren beginnen unter Verwendung des NAT zum Verarbeiten der verschiedenen Adressenbereiche.
Wie oben bemerkt ist, zeigt 1 den Kontext, in dem ein herkömmlicher NAT benutzt wird. Das normalerweise zu lösende Problem ist das eines großen Internnetzes 10, das in einem Bereich 50 inoffizieller oder nicht zugewiesener IP-Adressen existiert, die dem Globalen Internet nicht bekannt sind oder von ihm nicht korrekt geroutet werden. Die NAT-Einrichtung 20 wird am Interkonnektionspunkt (oder Punkten) des Internnetzes 10 an das Globale Internet 30 eingesetzt. Unter Verwendung eines kleinen Pools von offiziell zugewiesenen Adressen erzeugt der NAT 20 für das Globale Internet 30 die Illusion eines kleinen Netzes von Einrichtungen, das die offiziell zugewiesenen IP- Adressen benutzt, und gewährt vielen oder allen Einrichtungen innerhalb des Internnetzes 10 etwas Zugriff auf das Globale Internet 30.
Peer-zu-Peer Anwendungen werden nicht in der Lage sein, über eine NAT-Einrichtung der gegenwärtigen Generation zu arbeiten, teilweise wegen der beschränkten Weise, in der eine Anwendung und ihr entsprechender NAT kommunizieren. Normalerweise befasst sich eine NAT-Einrichtung nur mit den IP-Adressenfeldern von Nachrichtenpaketen und führt die Adressenübersetzung gemäß einer begrenzten Menge von Regeln aus. 2 zeigt die elementaren Adressenübersetzungsfunktionen eines herkömmlichen NAT 120. Der Host A 110 ist Teil eines Adressenbereichs 100, der vom herkömmlichen NAT 120 bedient wird. Die Anwendung A1 121 läuft auf dem Host A. Sie hat eine Ziel- oder Endadresse, die intern gültig ist und benutzt wird, um eingehende Nachrichten zu ihr zu routen. Anwendung A1 kann auch eine Ursprungsadresse haben, die dazu benutzt wird, Anwendung A1 als Quelle von Nachrichtenpaketen zu identifizieren, die Anwendung A1 erzeugt. Wie oben erörtert, enthält ein IP-Nachrichtenpaket einen fünfteiligen IP-Kopf. So enthält ein ausgehendes Paket 130, das Anwendung A1 an Rost R 210 in einem fernen Externadressenbereich senden will, die folgenden Komponenten in seinem IP-Kopf 140:

Diesem IP-Kopf folgen Daten 142, bei denen es sich um Medien handeln kann. Wenn Anwendung A1 dem NAT 120 die ausgehende Nachricht 130 präsentiert, muss der NAT 120 irgendwelche intern gültigen Adressen und Portnummern durch extern gültige Adressen und Portnummern ersetzen. Der NAT 120 kann Hardware und Software 122 haben, die seine Übersetzungsregeln anwenden, die in einer beliebigen Form gespeichert sind, beispielsweise in einer Zuordnungstabelle 124. Typischerweise besitzt Anwendung A1 121 nur ihre intern gültige Quell-IP-Adresse und Quellportnummer (ihre Ursprungsadresse), und der NAT 120 muss diese als bei jeder ausgehenden Nachricht 130 in einen extern gültigen Adressenkopf 240 des Pakets 230 eingesetzt übersetzen, bevor er sie an den Host R 210 weiterleitet. Wenn wir der Einfachheit halber annehmen, dass sich der Host R in einem Adressenbereich 200 befindet, der offizielle IP-Adressen benutzt, dann werden NAT oder Adressenübersetzung nicht gebraucht, um das Paket 230 mit der extern gültigen Adresse 240 an die spezifizierte Ziel-IP-Adresse und den Port im Adressenbereich 200 von Host R zu liefern.
Das Antwortpaket 250 von Host R wird in seinem Adressenkopf 260 extern gültige IP-Adressen benutzen. Der NAT 120 wird diese extern gültigen Adressen in intern gültige IP-Adressen für seinen Adressenbereich 100 übersetzen müssen. Wieder wird der NAT Hardware und Software 122 benutzen, die seine Übersetzungsregeln anwenden, die in beliebiger Form gespeichert sind, beispielsweise als eine Zuordnungstabelle 124. Das von Host R an Host A gesendete Resultat ist ein intern gültiges Paket 150 mit passend übersetztem Adressenkopf 160, der eine intern gültige Zieladresse und einen Port hat (d. h. die Endadresse für Anwendung A1). Das ermöglicht dem intern gültigen Paket 150 mit Dateninhalt 162, die Anwendung A1 zu erreichen.
Die Mikroserver für die von der vorliegenden Erfindung erleichterte Peer-zu-Peer Kommunikation befinden sich potentiell auf irgendeiner Hosteinrichtung im Internnetz einer Organisation. Diesen Mikroservern werden im Allgemeinen vom unterliegenden Betriebssystem (auf eine für das Betriebssystem spezifischen Weise) eine stochastische, verfügbare Portnummer als Port zugewiesen, den er für seinen Dienst benutzt; dies wird eine Nummer sein, die gegenwärtig von keiner anderen Anwendung auf der Hosteinrichtung, wo der Mikroserver läuft, benutzt wird. Tatsächlich besteht kein Grund, dass sich der Mikroserver auf derselben Einrichtung befindet wie die Anwendung, die die Adresse des Mikroservers kommuniziert, und es ist auch nicht nötig, dass sich der Client des Mikroservers im anderen Adressenbereich auf derselben Einrichtung befindet wie die Einrichtung, an die die Adresse des Mikroservers kommuniziert werden soll, um Datenaustausch einzurichten. Wenn jedoch diese Trennung stattfindet, muss etwas Intranetzkommunikation stattfinden, damit alle Anwendungen alle Adressen- und Portinformationen kennen, die sie kennen müssen.
Wir werden uns auf die hierin erörterte Klasse der Anwendungen als „Peer-zu-Peer Anwendungen" beziehen, was alle Anwendungen einbeziehen soll, in denen zwei Anwendungen über ein Netz auf eine im Wesentlichen symmetrische Weise kommunizieren, wo keine der beiden Anwendungen eindeutig ein Server oder ein Client ist in dem Sinne, dass eine Anwendung einen Dienst gewährt bzw. empfängt; sondern beide Anwendungen führen dieselben oder ähnliche Funktionen für die andere aus. Man beachte, dass wir im Rest dieses Dokuments unter dem Terminus „Client" eine Anwendung verstehen, die eine Datenübertragungssitzung aufbaut und unter dem Terminus „Server" eine Anwendung verstehen, die den Aufbau einer Datenübertragungssitzung von einem Clienten annimmt. Das ist eine nützliche Terminologie, die dabei hilft, die Richtung zu definieren, in der das erste zwischen den beiden Anwendungen übergebene Datenpaket übergeben wird. Dieser Aufbauschritt ist wichtig für eine Erörterung des NAT-Verhaltens. Für unsere Zwecke soll der Terminus „Client", falls nicht anders interpretiert, die Anwendung oder Einrichtung bedeuten, die das erste Sitzungspaket einer Datenübertragung sendet, und „Server" bedeutet die Anwendung oder Einrichtung, an die das erste Paket gerichtet ist.
IP-Telefonie ist ein wichtiges Beispiel für eine Peer-zu-Peer Anwendung. In diesem Beispiel fungiert jede Endpunktanwendung als ein Client, indem sie eine so genannte „Medien"-Verbindung aufbaut, um digitalisierte Sprache enthaltende Pakete an die andere zu senden, die die digitalisierte Sprache enthaltenden Pakete als Server empfängt. Das Verhältnis ist mehr oder weniger symmetrisch, da digitalisierte Sprache normalerweise in beiden Richtungen übergeben wird.
In IP-Telefonie wird ein Mikroserver auf einem Internnetz (sagen wir mal einem IP-Telefon, das einen Strom von digitalisierten Sprachpaketen von einem entfernten Telefon erwartet) normalerweise die IP-Adresse seiner Hosteinrichtung an einen entfernten Clienten (das andere IP-Telefon oder eine andere für das andere Telefon agierende Einrichtung wie beispielsweise eine virtuelle PBX-Anlage oder ein anderes IP-Telefonie-Gateway) kommunizieren müssen. Die intern gültige Netzadresse des Mikroservers funktioniert nicht für einen Clienten im Globalen Internet, da diese Adresse keine offiziell zugewiesene IP-Adresse ist. Im Falle, dass der Mikroserver irgendwie selbständig eine offizielle IP-Adresse detektieren oder berechnen könnte, die er dem entfernten Clienten im ersten Paket mitteilen könnte, hätte der herkömmliche NAT immer noch keine Verfahren oder Regeln, um zu wissen, was er mit dem von der entfernten Clientanwendung geschickten ersten Antwortpaket anfangen soll. D. h. es sei denn, der NAT selbst beteiligt sich an dieser Detektion oder Berechnung der offiziellen IP-Adresse im ersten Paket, wird der NAT keine Übersetzungsregel haben, die die Internnetzadresse und irgendeine offizielle IP-Adresse in einer eingehenden Nachricht assoziiert.
II. EINE VERBESSERTE PEER-ZU-PEER NETZADRESSEN-ÜBERSETZUNGSEINRICHTUNG
Die folgende Diskussion bezieht sich auf 3, um zu beschreiben, wie die vorliegende Erfindung eine verbesserte NAT-Einrichtung und ein Verfahren benutzt, um Peer-zu-Peer Internetkommunikationen aufzubauen.
Effiziente Peer-zu-Peer Anwendungskommunikation zwischen verschiedenen Adressenbereichen erfordert, dass die Anwendungen (der Einfachheit halber beschränken wir unsere Diskussion auf zwei Anwendungen, die Daten untereinander austauschen, im Gegensatz zu einem einmehrdeutigem oder mehrmehrdeutigen Austausch) Zugriff auf die offizielle, extern gültige IP-Adresseninformation haben, die in ihrer Kommunikation benutzt werden wird. Im einfachsten Fall muss eine erste Anwendung Zugriff haben auf (1) die extern gültige Adresseninformation, die andere benutzen, um sie zu erreichen, sodass eine solche erste Anwendung diese Adresseninformation an eine zweite Anwendung in einem anderen Adressenbereich kommunizieren kann, und (2) die extern gültige Adresse der zweiten Anwendung. Wegen der Symmetrie und zum Erleichtern der Sicherheit und anderer Funktionen ist es tatsächlich besser, dass jede der ersten und zweiten Anwendungen zwei Adressen hat: eine Ursprungsadresse A_O, die zum Identifizieren von Einrichtung und Port einer sendenden Anwendung als der Quelle eines ausgehenden Nachrichtenpakets benutzt wird, und eine separate Endadresse A_T, die dazu benutzt wird, eine andere Einrichtung und einen Port zu identifizieren, von denen eingehende Nachrichtpakete empfangen werden. Idealerweise wird also die Kommunikation von jeder der ersten und zweiten Anwendungen aufgebaut, die zwei assoziierte offizielle Adressen haben und kommunizieren: die Ursprungs- und Endadressen. Außerdem hat jede der ersten und zweiten Anwendungen Zugriff auf die Ursprungs- und Endadressen des Pendants, mit dem sie Peer-zu-Peer Kommunikation aufnehmen will.
3 zeigt ein System zum Erleichtern verbesserter Kommunikation zwischen zwei Peeranwendungen in verschiedenen Adressenbereichen. Host A 110 und Host B 310 sind beide Teil des Adressenbereichs 100. Auf Host A laufen eine oder mehrere Anwendungen. Um ein Beispiel zu geben, werden Anwendungen A1 121 und Anwendung A2 122 gezeigt. Jede hat eine intern gültige Endadresse und eine intern gültige Ursprungsadresse. Auf Host B können auch eine oder mehre Anwendungen laufen. Um ein Beispiel zu geben, werden Anwendungen B1 321 und Anwendung B2 322 gezeigt. Host A und Host B können auf demselben Netz sein oder anderweitig verbunden sein, sodass es einen Kanal 370 (z. B. Verbindung an ein gemeinsames Kommunikationsnetz) zur Kommunikation zwischen Host A und Host B gibt. In diesem Adressenbereich 100 können noch weitere Hosts vorhanden sein, werden aber nicht gezeigt.
Der verbesserte NAT 320 bedient den Adressenbereich 100. Der verbesserte NAT 320 hat zwei funktionale Abschnitte. Einer ist der Adressenübersetzungsabschnitt 322, der die herkömmlichen Adressenübersetzungsfunktionen ausübt, wie mit Bezug auf den NAT 120 in 2 erörtert ist. Der andere ist der Adressenmanagerabschnitt 324. Ein IP-Nachrichtenkanal 360 verbindet Host A 110 an den Adressenübersetzungsabschnitt. Dieser Kanal 360 wird benutzt, wenn eine Anwendung auf Host A oder irgendeinem anderen von NAT 320 bedienten Host eine ausgehende Nachricht senden muss und die Übersetzung intern gültiger Adressen in extern gültige Adressen benötigt. Der Kanal 360 wird auch benutzt, wenn eine eingehende Nachricht mit einer extern gültigen Adresse angekommen ist, der NAT 320 die extern gültigen Adressen in einer eingehenden Nachricht in intern gültige Adressen übersetzt hat und die Nachricht an die passende Anwendung im Adressenbereich 100 weiterleiten muss.
Der Adressenübersetzungsabschnitt 322 ist an die „Außen"-Adressenbereiche angebunden. 3 zeigt exemplarisch einen Globalen Internetbereich 400, der an den Adressenübersetzungsabschnitt 322 angebunden ist. Innerhalb des Adressenbereichs 400 befindet sich ein anderer Adressenbereich 200, der Host R 410 und Host S 510 enthält, die andere Anwendungen (Anwendungen R1, R2, S1 und S2 sind exemplarisch gezeigt) hosten können, mit denen Host A oder Host B kommunizieren kann. Kanal 470 (z. B. eine gemeinsame Netzverbindung) stellt Kommunikation zwischen Host R 410 und Host S 510 zur Verfügung.
Ein Steuerkanal 350 bindet Host A 110 (und indirekt Host B 310) an den Adressenmanagerabschnitt 324 an. Der Steuerkanal 350 wird benutzt, wenn eine Anwendung auf Host A oder irgendeinem anderen vom NAT 320 bedienten Host mit dem NAT 320 kommunizieren muss, um Dienste des Adressenmanagers 324 anzufordern. Der Adressenmanager kann für eine anfordernde Anwendung mehrere Dienste ausführen. Erstens kann eine anfordernde Anwendung eine intern gültige Adresse präsentieren (entweder eine Ursprungsadresse oder eine Endadresse) und den Adressenmanager 324 auffordern, eine extern gültige Adresse gepaart mit einer intern gültigen Adresse bereitzustellen und dem Adressenübersetzungsabschnitt 322 Zugriff auf diese Paarung zu geben. Dies kann so erfolgen, dass der Adressenübersetzungsbereich 322 diese Zuordnung als seine Übersetzungsregel für eingehende und ausgehende Nachrichtenpakete benutzen wird.
Zweitens kann eine Anwendung bewirken, dass der Adressenmanager 324 weitere oder komplexere Übersetzungsregeln, die über einfache Intern-Extern-Paarungen hinausgehen, den im NAT 320 benutzten hinzufügt. Anstatt beispielsweise nur eine in einer eingehenden Nachricht aufgefundene spezifizierte extern gültige Adresse oder einen Port durch eine entsprechende intern gültige Zieladresse oder einen Port bedingungslos zu ersetzen, kann der Adressenmanager 324 auf Aufforderung einer Anwendung eine komplexere Übersetzungsregel aufbauen. Eine Regel könnte formuliert werden, sodass der Adressenübersetzungsabschnitt 322 die eingehende Quelladresse und/oder den Port prüft und in Abhängigkeit vom Inhalt dieses Felds eine verschiedene Übersetzungsregel anwendet. Z. B. wird eine extern gültige Adresse A_E in einem am NAT 320 empfangenen Paket in eine intern gültige Adresse A_I1 übersetzt, wenn eine bestimmte Quelladresse im Paket vorhanden ist; die Übersetzung wird jedoch nicht ausgeführt und das Paket wird verworfen, falls diese Quelladresse nicht vorhanden ist. Das kann der Sicherheit nützen. Als Alternative könnte eine extern gültige Zielportnummer P_E in Abhängigkeit von der eingehenden Quelladresse in eine intern gültige Portnummer eines Werts P_I1 oder eines verschiedenen Werts P_I2 übersetzt werden. Spezifische Fernadressen, größere Mengen von Fernadressen oder irgendeine beliebige Fernadresse könnten als Auslöser für den Gebrauch spezieller NAT-Regeln benutzt werden.
Drittens könnte eine Anwendung dem Adressenmanager 324 erforderliche oder erwünschte Charakteristiken für eine extern gültige Adresse zur Assoziation mit einer intern gültigen Adresse spezifizieren. Dies könnte nützlich sein, damit eine Anwendung spezifiziert, dass die externe LP-Adresse, die aus der Übersetzung resultieren soll, eine bestimmte IP-Adresse sein muss oder innerhalb eines spezifizierten Bereichs von IP-Adressen sein muss. So könnte bei passender Anforderung die Anwendung eine NAT-Regel festlegen, die verlangen würde, dass das Nachrichtenpaket zu einem bestimmten externen Server im Globalen Internet geschickt oder gezwungen wird, der seinerseits die Nachricht zu einem bestimmten privaten Netz leitet, wo eine bestimmte Art von Übertragung oder Fakturierung stattfinden könnte, bevor das Paket wieder in ein öffentliches Globales Internet weitergeleitet wird.
Man kann dann erkennen, dass der Steuerkanal 350 und der Adressenmanagerabschnitt 324 eine flexible Einrichtung darstellen, um Anwendungen sowohl Information zur Verfügung zu stellen, die sie bei einem herkömmlichen NAT nicht erhalten, als auch die Fähigkeit, bestimmte Übersetzungsregeln für den Adressenübersetzungsabschnitt 322 des NAT festzulegen. Der Adressenmanager 324 kann als Hardware oder Software oder eine Kombination aus beiden implementiert werden. Beispielsweise könnte wünschenswert sein, dass der Adressenmanager 324 seinen eigenen Mikroprozessor und Speicher zum Speichern des Codes hat, der bestimmt, welche Dienste und Funktionen als Reaktion auf Steuernachrichten von einer Anwendung verfügbar sind. Man wird außerdem erkennen, dass jede Anwendung, die mit dem Adressenmanager 324 kommuniziert, Hardware und/oder Software benötigt, die es ermöglicht, Anforderungen über den Steuerkanal 350 zu machen und angeforderte Information oder Statusinformation an die Anwendung zurückzusenden.
III. MUSTER ZUM PEER-ZU-PEER AUSTAUSCH UNTER VERWENDUNG DES STEUERKANALS
Die obige Diskussion der Server- und Clientrelationen wird wieder aufgenommen. Die Funktion des Steuerkanals 350 und Kommunikationen zwischen einer Anwendung und dem Adressenmanagerabschnitt 324 und Adressenübersetzungsabschnitt 322 können in mehreren verschiedenen Beispielsituationen erklärt werden. Jedes Beispiel wird mit Bezug auf 3 vorgetragen.
BEISPIEL ZUR ZUORDNUNG UND DETEKTION VON SERVERADRESSE/PORT:
Host A 110 im Adressenbereich 100 startet einen Mikroserver, eine Anwendung A1 121, die den Zweck hat, Adresseninformation an Host R 410 im Adressenbereich 200 außerhalb des Adressenbereichs 100 zu kommunizieren, wobei Host R 410 die Adresseninformation dazu benutzen kann, um an den Mikroserver, Anwendung A1 anzubinden. Um den Host R mit nützlicher Adresseninformation zu versorgen, finden folgende Schritte statt:

1. Anwendung A1 121 kontaktiert die NAT-Einrichtung 320 über den Steuerkanal 350, um den Adressenmanager 324 über die intern gültige IP-Adresse und den Port zu informieren, die von Anwendung A1 benutzt werden.
2. Anwendung A1 121 empfängt vom Adressenmanager 324 als Antwort eine extern gültige IP-Adresse und Portnummer, die die NAT-Einrichtung 320 in die intern gültige Endadresse übersetzt, die Anwendung A1 in ihrer Anforderung bereitgestellt hat.
3. Anwendung A1 (von der wir annehmen müssen, dass sie die Fähigkeit hat, ein IP-Nachrichtenpaket an Host R, Anwendung R1 421 zu adressieren) schickt dann ein IP-Nachrichtenpaket über den Adressenübersetzungsabschnitt 322 des NAT 320. Der Datenteil des Pakets enthält die extern gültige IP-Adresse und eine Portnummer, um Host R 410, Anwendung R1 421 mitzuteilen, wie Pakete an Anwendung A1 zu senden sind.
4. Anwendung R1 421 in Host R 410 sendet eine Verbindungsanforderung über die extern gültige IP-Adresse und eine Portnummer, die ihr Anwendung A1 gegeben hat, die (da korrekt an eine offizielle IP-Adresse adressiert) beim NAT 320 ankommt, wo die extern gültige Adresse in die intern gültige Adresse und den Port der Anwendung A1 übersetzt wird.
5. NAT 320 sendet das Antwortpaket von Anwendung R1 421 weiter an Anwendung A1 121 auf Host A.

BEISPIEL ZUR ZUORDNUNG UND DETEKTION VON CLIENTADRESSE/PORT:
Der externe Host R 410 im Adressenbereich 200 startet einen Mikroserver, z. B. eine Anwendung R1 421. Anwendung A1 hat die Absicht, Adresseninformation an Host R im Adressenbereich 200 außerhalb des Adressenbereichs 100 zu kommunizieren, wobei Host R die Adresseninformation dazu benutzen kann, eine eingehende Verbindung von Host A zu validieren. Um Host R 420 mit nützlicher Adresseninformation zu versorgen, finden folgende Schritte statt:

1. Anwendung R1 421 sendet ein Paket an Host A, Anwendung A1 121, um Information darüber anzufordern, von welcher IP-Adresse und welchem Port die Verbindung von Anwendung A1 121 ausgehen wird. Diese Ursprungsadresseninformation nützt der Sicherheit und kann von Anwendung R1 für ihre eigenen Zwecke, beispielsweise Compliance mit einem Kommunikationsprotokoll, angefordert werden.
2. Anwendung A1 121 auf Host A kontaktiert die NAT-Einrichtung 320 über den Steuerkanal 350, um den Adressenmanager 324 über die intern gültige IP-Adresse und den Port zu informieren, die Anwendung A1 benutzen wird, um mit dem Mikroserver auf Host R zu kommunizieren.
3. Anwendung A1 121 empfängt vom Adressenmanager 324 als Antwort eine extern gültige IP-Adresse und eine Portnummer, in die die NAT-Einrichtung 320 die intern gültige Ursprungsadresse übersetzen wird, die von der Anwendung A1 in ihrer Anforderung geliefert wurde.
4. Anwendung A1 121 (von der wir annehmen müssen, dass sie die Fähigkeit hat, ein IP-Nachrichtenpaket an Host R, Anwendung R1 zu adressieren) sendet dann ein IP-Nachrichtenpaket über den Adressenübersetzungsabschnitt 322 des NAT 320. Der Datenteil des Pakets enthält die extern gültige IP-Adresse und eine Portnummer, um Host R, Anwendung R1 421 zu informieren, von welcher IP-Adresse und welchem Port Pakete von Anwendung A1 121 ankommen werden.
5. Anwendung A1 121 baut dann die Verbindung auf durch Senden eines ausgehenden Pakets, das an Host R, Anwendung R1 421 adressiert ist, wobei das Paket am Adressenübersetzungsabschnitt 322 der NAT-Einrichtung 320 ankommt.
6. Der Adressenübersetzungsabschnitt 322 der NAT-Einrichtung 320 übersetzt die Quelladresse und den Port des Pakets (die die interne IP-Adresse und den Port der Anwendung A1 angeben) in deren extern gültige Version (die in Schritt 3 an Anwendung A1 weitergeleitet wurde und die Anwendung A1 in Schritt 4 an Anwendung R1 gesendet hat).
7. Der Adressenübersetzungsabschnitt 322 sendet das Paket an Host R, Anwendung R1 mit der Quellinformation, die Anwendung R1 jetzt erwartet.

BEISPIEL ZUR ZUORDNUNG UND DETEKTION VON SERVERADRESSE/PORT MIT SEPARATEM ANFORDERER/SERVER:
In diesem Beispiel nutzen Host A und Host B einen zwischen ihnen verlaufenden Kommunikationskanal 370. Dies erlaubt einer Anwendung auf Host A als Proxy für eine Anwendung auf Host B zu fungieren. Wenn beispielsweise Anwendungen auf Host B wenig intelligente IP-Telefone sind, dann könnte Host A eine virtuelle PBX-Anlage mit Anwendungen sein, die eine Reihe von Diensten adressieren könnten (z. B. Fernsprechauskunft, Assoziation von Telefonnummer mit IP-Adresse), die von einem IP-Telefon benötigt werden oder könnte eine andere Form von IP-Telefonie-Gateway sein. Durch den Gebrauch eines Proxy wird deutlich, dass es kein Verhältnis zwischen den Adressen und Ports, die der anfordernden Entität tatsächlich gehören oder von ihr benutzt werden, und den in der Anforderung an den Adressenmanager 324 abgerufenen Adressen und Ports geben muss.
Host B 310 im Adressenbereich 100 startet einen Mikroserver, z. B. eine Anwendung B1 321, die den Zweck hat, Adresseninformation an den Host R im Adressenbereich 200 außerhalb des Adressenbereichs 100 zu kommunizieren, wobei Host R (der auch als der Client dient) die Adresseninformation dazu benutzen kann, um an den Mikroserver, Anwendung B1 anzubinden. Um Host R mit nützlicher Adresseninformation zu versorgen, finden folgende Schritte statt:

1. Anwendung A1 121 kommuniziert mit Anwendung B1 über Kanal 370, um zu detektieren, welche intern gültige Adresse und welcher Port benutzt werden können, um Anwendung B1 321 zu kontaktieren.
2. Anwendung A1 121 muss Anwendung R1 im Adressenbereich 200 kontaktieren, um die Anwendung R1 mit extern gültiger Adresseninformation für Anwendung B1 zu versorgen. Anwendung A1 kontaktiert die NAT-Einrichtung 320 über den Steuerkanal 350, um den Adressenmanager 324 über die intern gültige IP-Adresse und den Port zu informieren, die von Anwendung B1 benutzt werden.
3. Anwendung A1 121 empfangt vom Adressenmanager 324 als Antwort eine extern gültige IP-Adresse und eine Portnummer, die die NAT-Einrichtung 320 in die von Anwendung A1 in ihrer Anforderung bereitgestellte intern gültige Endadresse für Anwendung B1 übersetzten wird.
4. Anwendung A1 121 (von der wir annehmen müssen, dass sie die Fähigkeit hat, ein IP-Nachrichtenpaket an Host R, Anwendung R1 421 zu adressieren) sendet dann ein IP-Nachrichtenpaket über den Adressenübersetzungsabschnitt 322 des NAT 320. Der Datenteil des Pakets enthält die extern gültige IP-Adresse und eine Portnummer, um Host R, Anwendung R1 421 zu informieren, wie Pakete an Anwendung B1 321 zu senden sind.
5. Anwendung R1 421 in Host R sendet ein Verbindungsanforderung über die extern gültige LP-Adresse und eine Portnummer, die ihr Anwendung A1 121 gegeben hat, die (da korrekt an eine offizielle LP-Adresse adressiert) beim NAT 320 ankommt, wo die extern gültige Adresse in die intern gültige Adresse und den Port der Anwendung B1 übersetzt wird.
6. NAT 320 leitet die Antwort von Anwendung R1 weiter an Anwendung B1 auf Host B.

BEISPIEL ZUR ZUORDNUNG UND DETEKTION VON CLIENTADRESSEN/PORT MIT VON VERHANDELNDEN ENTITÄTEN SEPARIERTEN CLIENT/SERVERN:
In diesem Beispiel nutzen Host R 410 und Host S 510 einen zwischen ihnen verlaufenden Kommunikationskanal 470. Dadurch wird einer Anwendung auf Host R 410 ermöglicht, als Proxy für eine Anwendung auf Host S 510 zu fungieren. Wenn beispielsweise Anwendungen auf Host S wenig intelligente IP-Telefone sind, dann könnte Host R 410 eine virtuelle PBX-Anlage mit Anwendungen sein, die eine Reihe von Diensten adressieren könnten (z. B. Fernsprechauskunft, Assoziation von Telefonnummer mit IP-Adresse), die von einem IP-Telefon benötigt werden oder könnte eine andere Form von IP-Telefonie-Gateway sein.
Host S 510 im Adressenbereich 100 startet einen Mikroserver, z. B. eine Anwendung S1. Anwendung B1 hat die Absicht, Adresseninformation an Host S 510 im Adressenbereich 200 außerhalb des Adressenbereichs 100 zu kommunizieren, wobei Host S 510 die Adresseninformation dazu benutzen kann, eine eingehende Verbindung von Host B zu validieren. Um Host S 510 mit nützlicher Adresseninformation zu versorgen, finden folgende Schritte statt:

1. Anwendung R1 421 sendet ein Paket an Host A 110, das von Host A, Anwendung A1 121 Information anfordert, von welcher IP-Adresse und welchem Port die Verbindung mit Anwendung B1 321 ausgehen wird. Diese Ursprungsadresseninformation nützt der Sicherheit und kann von Anwendung S1 für ihre eigenen Zwecke, beispielsweise Compliance mit einem Kommunikationsprotokoll, angefordert werden.
2. Anwendung A1 121 kommuniziert mit Anwendung B1 321 über Kanal 370, um zu detektieren, welche intern gültige Adresse und welcher Port von Anwendung B1 321 benutzt werden wird, um Anwendung S1 521 zu kontaktieren.
3. Anwendung A1 121 auf Host A kontaktiert die NAT-Einrichtung 320 über den Steuerkanal 350, um den Adressenmanager 324 darüber zu unterrichten, welche IP-Adresse und welcher Port von Anwendung B1 benutzt werden wird, um mit dem Mikroserver auf Host S 510 zu kommunizieren.
4. Anwendung A1 121 empfängt als Antwort vom Adressenmanager 324 eine extern gültige IP-Adresse und eine Portnummer, in die die NAT-Einrichtung 320 die in ihrer Anforderung von Anwendung A1 121 bereitgestellte intern gültige Ursprungsadresse übersetzt.
5. Anwendung A1 121 (von der wir annehmen müssen, dass sie die Fähigkeit hat, ein IP-Nachrichtenpaket an Host R, Anwendung R1 421 zu adressieren) sendet dann ein IP-Nachrichtenpaket über den Adressenübersetzungsabschnitt 322 des NAT 320. Der Datenteil des Pakets enthält die extern gültige IP-Adresse und eine Portnummer, um Host R, Anwendung R1 421 zu informieren, von welcher IP-Adresse und welchem Port Pakete von Anwendung B1 321 ausgehen werden.
6. Anwendung R1 421 wird mit Anwendung S1 521 über Kommunikationskanal 470 kommunizieren, um Anwendung S1 521 die IP-Adresse und den Port zu kommunizieren, die Anwendung B1 321 benutzen wird, um an Anwendung S1 521 zu kommunizieren.
7. Anwendung B1 321 baut dann die Verbindung auf, indem sie ein an Host S, Anwendung S1 521 adressiertes ausgehendes Paket sendet, wobei das Paket am Adressenübersetzungsabschnitt 322 der NAT-Einrichtung 320 ankommt.
8. Der Adressenübersetzungsabschnitt 322 der NAT-Einrichtung 320 übersetzt die Quelladresse und den Port (die die interne IP-Adresse und den Port der Anwendung B1 bezeichnen) in deren extern gültige Version (die in Schritt 4 an Anwendung A1 121 weitergeleitet wurde und die Anwendung A1 in Schritt 5 an Anwendung R1 421 gesendet hat).
9. Der Adressenübersetzungsabschnitt 322 sendet das Paket über Host R 410 an Host S, Anwendung S1 521 mit der Quellinformation, die Anwendung S1 jetzt erwartet.

IV. EINE SPRACHKOMMUNIKATIONSANWENDUNG
A. OHNE NAT
Um die Anwendung der vorliegenden Erfindung auf IP-Telefonie detaillierter zu erklären, hilft eine Erklärung, wie ein einfacher Telefonanruf unter Verwendung eines SIP genannten Protokolls funktionieren könnte. SIP ist das Protokoll zum Aufbau einer Sitzung (Session Initiation Protocol), es wird aber allgemein als eine Kurzbezeichnung für SIP und alle dazugehörigen Protokolle akzeptiert, die zusammenarbeiten, um Benutzern zu ermöglichen, Telefonie (und einige andere Sachen) über Datennetze wie IP zu betreiben.
In einem einfachen Beispiel gibt es im Wesentlichen zwei Nachrichten, die gesendet werden, um einen Telefonanruf aufzubauen. (Diese Erörterung unterdrückt gewisse Details; tatsächlich könnte sich sehr viel mehr abspielen.) Die zwei Nachrichten, mit denen wir befasst sind, sind die INVITE-Nachricht und die OK-Antwort darauf.
Man nehme an, dass jemand unter Verwendung eines als Telefon A bezeichneten SIP-Telefons jemand anders anrufen will, der möglicherweise durch eine Telefonnummer oder eine andere Kennung wie beispielsweise eine Emailadresse identifiziert ist. Die anrufende Person würde den erwünschten Zielteilnehmer durch Eintippen der Telefonnummer oder anderen Kennung eingeben. Natürlich weiß Telefon A nicht, wo der Zielteilnehmer ist, aber es weiß, wo eine intelligentere Einrichtung, Proxyserver genannt, ist. Telefon A formuliert deshalb eine INVITE-Nachricht, die Information darüber enthält, wer das Ziel ist, einige andere Informationen und – bezeichnenderweise – Zielinformation darüber, wo Telefon A Medienpakete vom Ziel zu empfangen erwartet jedes Mal, wenn das Ziel lokalisiert ist, angerufen wird und das Telefon abnimmt. Telefon A wird typischerweise diese Information in Form von seiner eigenen IP-Adresse und einer Portnummer zur Verfügung stellen. Nehmen wir an, dass dies 1.1.1.1 bzw. 1111 ist.
Der durch Telefon A kontaktierte Proxyserver wird wahrscheinlich das INVITE an andere Proxyservereinrichtungen weiterleiten, wobei einem Netzsuchpfad gefolgt wird, bis das Ziel lokalisiert ist. An dieser Stelle wird die ursprünglich von Telefon A formulierte INVITE-Nachricht an das Ziel geliefert, das wir mit Telefon B bezeichnen wollen. Telefon B wird wahrscheinlich eine Weile rufen und wird dann (wenn alles gut geht) von jemandem abgenommen. An dieser Stelle antwortet Telefon B mit einer OK-Nachricht, die eine Vielfalt von Informationen enthält, einschließlich der Zieladresse, an der Telefon B die Medien zu empfangen erwartet. Nehmen wir an, dass es sich dabei um die IP-Adresse 2.2.2.2 bzw. Portnummer 2222 handelt.
Telefon B kann damit beginnen, Medienpakete mit digitalisierter Sprache sofort an 1.1.1.1/1111 zu senden, weil es diese Information in der INVITE-Nachricht erhalten hat. Kommt die OK-Nachricht (durch die Proxyserver) zurück zu Telefon A, dann kann dieses Telefon damit beginnen, ähnliche Medienpakete an 2.2.2.2/2222 zu schicken. Digitale Audiodaten werden an dieser Stelle in beiden Richtungen gesendet, und vermutlich folgt darauf ein Gespräch.
B. MIT NAT
Beim Betrachten einer NAT-Einrichtung müssen wir drei Fälle erörtern. Im ersten Fall wird das Zieltelefon schließlich durch den Proxyserver innerhalb einer NAT-Einrichtung lokalisiert. Im zweiten Fall wird das Quelltelefon innerhalb einer NAT-Einrichtung lokalisiert. Im dritten Fall wird keines der Telefone „innerhalb" einer NAT-Einrichtung lokalisiert, aber der Medienverkehr zwischen beiden muss ein innerhalb der NAT-Einrichtung lokalisiertes Netz durchqueren. In den unten erörterten Beispielen sind alle NAT-Einrichtungen von der in 3 erörterten Art.
Die verschiedenen Fälle können natürlich kombiniert werden. Im Allgemeinen wird irgendein Proxyserver anderen Proxyservern im Netz sowie den beteiligten Telefonen die Illusion geben, dass es keine NAT-Einrichtungen gibt. Weil dies erfolgreich gemacht werden kann, kann man tatsächlich viele NAT-Einrichtungen mit vielen Proxyservern arbeiten lassen und alle davon überzeugt sind, der einzige NAT zu sein und alle den Rest des Netzes davon überzeugen, dass es im Effekt „hier keinen NAT gibt".
1. DAS ZIELTELEFON IST IM INNEREN EINES NAT
In diesem Fall hat das Zieltelefon, Telefon B, das innerhalb des Adressenbereichs eines NAT ist, keine Schwierigkeiten, Daten an das Ursprungstelefon zu senden, weil der NAT im Allgemeinen Objekte „im Inneren” mit der Fähigkeit ausstattet, Verkehr an jedes Ziel einfach durch Adressieren an die Außenadresse nach draußen zu schicken. Die Schwierigkeit besteht darin, zu klären, was dem Ursprungstelefon mitzuteilen ist; da das das Zieltelefon „im Inneren" des NAT ist, kann es nicht ohne etwas Hilfe vom NAT von außen erreicht werden. Das Zieltelefon benutzt keine global routbare IP-Adresse; es benutzt wahrscheinlich eine private IP-Adresse, eine Adresse, von der der Rest der Welt nicht weiß, wie man ein Paket dorthin schicken kann. Nur Einrichtungen auf dem Lokalnetz des Zieltelefons können Daten an die tatsächliche IP-Adresse des Zieltelefons adressieren und dürfen dabei hoffen, dass die Daten dort hingeschickt werden.
In diesem Fall muss ein Proxyserver innerhalb des Zieltelefonnetzes beteiligt werden. Natürlich wird er ja immer beteiligt sein, weil er für das Routen des INVITE an das richtige Telefon innerhalb des Lokalnetzes verantwortlich ist, um den Ruf fertig zu stellen. Dieser Proxyserver wird auch die OK-Antwort des Zieltelefons verarbeiten. Man erinnere sich daran, dass das Zieltelefon seine Adresse und seinen Port 2.2.2.2/2222 in diese OK-Nachricht schreibt. In diesem Fall ist 2.2.2.2, weil privat und nur intern gültig, für das Ursprungstelefon keine nützliche Adresse. Der Proxyserver muss deshalb eine verschiedene, extern gültige Adresse beschaffen und die in der OK-Nachricht enthaltene Adresse (und möglicherweise den Port) vor dem Zurücksenden an das Ursprungstelefon ersetzen.
Der Proxyserver wird eine Anforderung an die NAT-Einrichtung des Zieltelefons richten, eine „Serveradresse/Portzuweisung/Detektion"-Anforderung. Der NAT wird darauf mit einer Adresse und einem Port antworten, sagen wir mal mit 3.3.3.3/3333, womit Einrichtungen auf der andere Seite (der „Außenseite") der NAT-Einrichtung eine Einrichtung bei 2.2.2.2/2222 (dem Zieltelefon) erreichen können. Der Proxyserver schreibt die OK-Nachricht neu, um 3.3.3.3/3333 anstelle von 2.2.2.2/2222 anzugeben, und schickt diese neue OK-Nachricht an Telefon A ab.
Wenn jetzt Telefon B ein Medienpaket an Telefon A sendet, ist es an 1.1.1.1/1111 adressiert, und der NAT lässt das ohne weiteres funktionieren – Außenverkehr kann einfach an die „richtige", extern gültige Adresse adressiert werden. Wenn jedoch Telefon A ein Medienpaket an Telefon B sendet, wird es dieses an 3.3.3.3/3333 senden – die Zielendpunktinformation, die es in der OK-Nachricht empfangen hat. Geht man davon aus, dass die Konfiguration korrekt ist, wird dieses Paket bei der NAT-Einrichtung eintreffen, die es so übersetzt, dass es jetzt gemäß der Anforderung durch den Proxyserver an 2.2.2.2/2222 adressiert ist und ins Netzinnere gesendet wird. Das Medienpaket ist jetzt korrekt adressiert und befindet sich im Lokalnetz, das weiß, wie dieses „privat adressierte" Medienpaket zu verschicken ist, sodass das Medienpaket wie erwünscht am Telefon B ankommt.
2. DAS ZIELTELEFON IST AUSSERHALB DES NAT
Dies ist fast mit dem vorhergehenden Beispiel identisch, bis auf den Proxyserver in der Nähe von Telefon A (das jetzt das Telefon im Inneren" des NAT ist und eine private IP-Adresse hat, die nur in seinem Lokalnetz nützlich ist), der in diesem Fall die INVITE-Nachricht neu schreiben muss, nachdem er die NAT-Einrichtung nach einer extern gültigen Adresse abgefragt hat. Vielleicht wird die Adresse 1.1.1.1/1111 gemäß der angeforderten NAT-Regel als 4.4.4.4/4444 neu geschrieben (es wird angenommen, dass 1.1.1.1 eine private IP-Adresse ist, während 4.4.4.4 das in diesem Fall nicht ist).
Ein Medienpaket von Telefon A geht durch die NAT-Einrichtung unverändert nach außen ab, während ein Medienpaket von Telefon B außerhalb des NAT an 4.4.4.4/4444 adressiert wird, an der NAT- Einrichtung eintrifft und in 1.1.1.1/1111 übersetzt wird und schließlich im Inneren an Telefon A abgeliefert wird.
3. BEIDE TELEFONE SIND AUSSERHALB – DAS TRANSITNETZ HAT NATS
In diesem Fall nehmen wir an, dass beide Telefone irgendwo „da draußen" sind und das Netz mit den NAT-Einrichtungen ein Transitnetz ist – vielleicht ein Fernnetzbetreiber für IP-Telefone. Wir nehmen außerdem an, dass dieses Netz am Verarbeiten und Routen von INVITE- und OK-Nachrichten beteiligt ist. Vielleicht stellt dieses Netz sowohl Personenortungsdienste als auch Medienverarbeitung zur Verfügung.
Wir belassen Telefon A und Telefon B bei 1.1.1.1/1111 bzw. 2.2.2.2/2222.
Man nehme an, dass das INIVTE von Telefon A bei einem Proxyserver in dem mit NAT ausgerüsteten Transitnetz ankommt, das in Betracht gezogen wird. Wir können diesen den Eingangs-Proxyserver nennen, weil er in unserem Beispiel das „eingehende" INVITE verarbeitet. Der Eingangs-Proxyserver führt dieselbe „Serveradressen-/Portdetektion" aus wie in vorhergehenden Beispielen, um eine Adresse zu detektieren, die eine Einrichtung innerhalb des Transitnetzes benutzen könnte, um das Telefon A zu erreichen. Wir wollen annehmen, dass er diese Operation auf einer spezifischen, als NAT A bezeichneten NAT-Einrichtung ausführt, die sich am Ausgangspunkt vom Transitnetz zum Telefon A befindet. Sagen wir mal NAT A gibt eine Adresse/Port zurück, und zwar 10.10.10.10/1010. Dies ist eine innerhalb des Transitnetzes nützliche private Adresse, die Objekte innerhalb dieses Transitnetzes benutzen könnten, um Telefon A zu erreichen. Das heißt irgendwelche Nachrichtenpakete innerhalb des Transitnetzes, die an 10.10.10.10/1010 adressiert sind, würden vom Netz nach NAT A geroutet werden, der die Adresse in 1.1.1.1/1111 übersetzen und die Nachrichtenpakete an das Telefon A senden würde.
Die INVITE-Nachricht (die jetzt angibt, dass Telefon A an 10.10.10.10/1010 Medien empfangen will) wird über das Transitnetz weitergeschickt. An einer gewissen Stelle wird ein anderer Proxyserver, den wir Ausgangs-Proxyserver nennen wollen, weil er das INVITE auf dem Weg aus dem Transitnetz heraus verarbeitet, dieses INVITE empfangen. Dieser Ausgangs-Proxyserver wird noch eine andere Anforderung auf einer anderen NAT-Einrichtung (sagen wir mal NAT B) ausführen, die für das Bereitstellen von Verkehr nach und von Telefon B gut platziert ist, um eine Adresse zu detektieren, über die Objekte „außerhalb" NAT B den gegenwärtig im INVITE enthaltenen Endpunkt erreichen können – 10.10.10.10/1010. NAT B sollte darauf mit einer Adresse antworten, sagen wir mal mit 20.20.20.20/2020. Der Zweck dieser Adresse ist, dass Pakete, die von Außenobjekten (sagen wir mal beispielsweise von Telefon B) an 20.20.20.20/2020 adressiert gesendet werden und am NAT B ankommen, neu adressiert werden, genau gesagt übersetzt werden, um an 10.10.10.10/1010 adressiert zu sein. Dann wird das Transitnetz diese Daten (weil es eingerichtet ist, auf diese Weise zu routen) an NAT A routen, der die Daten wieder an 1.1.1.1/1111 neu adressiert, wie im vorigen Absatz angegeben ist.
Das INVITE wird dann an Telefon B weitergeleitet, das Medienpakete an die Adresse 20.20.20.20/2020 sendet gemäß dem Inhalt des INVITE. Die Medienpakete werden an die Adresse 20.20.20.20 gehen, die dafür sorgt, dass sie, korrekte Netzkonfiguration vorausgesetzt, bei NAT B ankommt, wo sie in 10.10.10.10/1010 übersetzt wird und dann nach NAT A geht. NAT A wird sie in 1.1.1.1/1111 übersetzen und an Telefon A weiterleiten.
Genau dieselbe Gruppe von Operationen, wenn auch in verschiedene Adressen resultierend, wird auf das OK angewendet, das von Telefon B zurückkommt, aber in der entgegengesetzten Richtung. Zuerst wird der Ausgangs-Proxyserver von NAT B eine Adresse abfragen, mit der Objekte innerhalb des Transitnetzes Telefon B (bei 2.2.2.2/2222) erreichen können. Vielleicht wird NAT B die Adresse 40.40.40.40/4040 zurückschicken. Die OK-Nachricht wird durch den Ausgangs-Proxyserver neu geschrieben, um dies zu kennzeichnen, und an den Eingangs-Proxyserver weitergeleitet. Dieser Proxyserver wird von NAT A eine Adresse abfragen, mit der Außenobjekte (sagen wir mal Telefon A) die Adresse 40.40.40.40/4040 erreichen können. NAT A könnte die Adresse 50.50.50.50/5050 zurückgeben. Das OK wird wieder neu geschrieben, um dies anzuzeigen, und an Telefon A weiterleitet, das dann alle seine Medienpakete an die Adresse 50.50.50.50/5050 senden wird.
Daraus ergibt sich, dass Telefon B seine Medienpakete an 20.20.20.20/2020 sendet und Telefon A seine Medienpakete an 50.50.50.50/5050 sendet, und dass alle Adressen schließlich so übersetzt werden, dass die Medienpakete zu guter Letzt am richtigen Ort ankommen.
Die Vorteile dieser Handhabung liegen darin, dass IP-Adressen wie 20.20.20.20 und 50.50.50.50 von Anwendungen mit der Fähigkeit, einen NAT zu steuern, gezwungen werden können, als Adressen ausgewählt zu werden, die zum Transitnetz selbst gehören, wodurch garantiert wird, dass die Pakete von den beiden Telefonen an passenden Eingangpunkten zum Transitnetz selbst ankommen, wodurch garantiert wird, dass das Transitnetz die Mediendaten tatsächlich verarbeit, und wodurch außerdem der Eingangpunkt für jeden Medienstrom garantiert wird. Ohne dies ist es unmöglich, dass das Transitnetz über eine A-priori-Steuerung verfügt, wie die Medienpakete von einem der Telefone zum anderen gelangen.
IV. SCHLUSSFOLGERUNG UND ALTERNATIVE AUSFÜHRUNGSARTEN
Fachleuten wird deutlich sein, dass unzählige Variationen, Modifikationen, Anwendungen und Erweiterungen dieser Ausführungsarten und Grundsätze geschaffen werden können. Dementsprechend ist beabsichtigt, dass der Schutzbereich der Erfindung nur beschränkt ist, wie es die beigefügten Patenansprüche erfordern.

Claims

Netzadressen-Übersetzungsvorrichtung (320) zum Erleichtern der Nachrichtenpaketkommunikation zwischen einer ersten Anwendung (121) mit einer in einem Internadressenbereich (100) gültigen Internadresse und einer oder mehreren Anwendungen (421) in einem Externadressenbereich (200), wobei die Netzadressen-Übersetzungsvorrichtung über eine Menge von verfügbaren Adressen verfügt, die zum Gebrauch im Extemadressenbereich (200) gültig sind, umfassend: einen Adressenübersetzer (322) zum Übersetzen von Adressen, die in den Köpfen von in den Internadressenbereich (100) eingehenden und von ihm ausgehenden Nachrichtenpaketen enthaltenen sind, gemäß den Übersetzungsregeln, die die Unvereinbarkeit der Adressenschemata der Intern- und Externadressenbereiche auflösen; einen Adressenmanager (324) zum Festlegen und Abspeichern der Übersetzungsregeln, wobei der Adressenmanager auf die Menge der verfügbaren Adressen Zugriff hat, die zum Gebrauch im Externadressenbereich gültig sind; dadurch gekennzeichnet, dass die Netzadressen-Übersetzungsvorrichtung außerdem Folgendes umfasst: ein im Adressenmanager (324) enthaltenes Mittel zur Kommunikation mit der ersten Anwendung über einen Steuerkanal, wobei die Kommunikation einschließt, dass der Adressenmanager von der ersten Anwendung (121) eine Dienstanforderungsnachricht empfängt, die das Festlegen einer von der ersten Anwendung spezifizierten Adressenübersetzungsregel anfordert; worin der Adressenmanager (324) Logik umfasst zum Bereitstellen von Diensten als Reaktion auf die Dienstanforderung der ersten Anwendung, eine von der ersten Anwendung in der Dienstanforderungsnachricht spezifizierte Übersetzungsregel festzulegen.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin die Logik im Adressenmanager dazu konfiguriert ist, die Internadresse der ersten Anwendung mit einer verfügbaren Externadresse zu assoziieren und der ersten Anwendung Zugriff zu gewähren auf die assoziierte verfügbare Externadresse zum Gebrauch als Daten für ein ausgehendes Nachrichtenpaket.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin die Logik im Adressenmanager dazu konfiguriert ist, die Internadresse der ersten Anwendung mit einer verfügbaren Externadresse zu assoziieren, die eine bestimmte IP-Adresse ist oder in einem spezifizierten Bereich von IP-Adressen liegt.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin die Logik im Adressenmanager dazu konfiguriert ist, eine Übersetzungsregel festzulegen, was die Auswahl einer Übersetzungsregel aus zwei oder mehreren auf ein eingehendes Nachrichtenpaket anwendbaren Übersetzungsregeln umfasst, wobei die Auswahl der Übersetzungsregel, die angewandt wird, von Adresseninformation im eingehenden Nachrichtenpaket abhängt.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 2, worin die von der ersten Anwendung angeforderte verfügbare Externadresse eine Zieladresse ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 2, worin die von der ersten Anwendung angeforderte verfügbare Externadresse eine Ursprungsadresse ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin der Internadressenbereich ein Privatnetz ist und der Extemadressenbereich das Internet ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin der Internadressenbereich ein Privatnetz ist und der Externadressenbereich das Internet ist und der Adressenmanager eine Übersetzungsregel festlegt, indem er eine im Privatnetzbereich gültige Adresse mit einer im Internet gültigen Adresse assoziiert.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 4, worin die Auswahl der Übersetzungsregel, die angewandt wird, als Reaktion auf das Vorhandensein oder Nichtvorhandensein spezifizierter Ursprungsadresseninformation in der eingehenden Nachricht getroffen wird.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin die erleichterte Kommunikation eine Peer-zu-Peer Anwendungskommunikation ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 1, worin die erleichterte Kommunikation eine Peer-zu-Peer Telefonkommunikation ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 3, worin die festzulegende Übersetzungsregel das ausgehende Nachrichtenpaket dazu zwingt, eine Zieladresse in einem Transitnetz zu haben.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 3, worin die festzulegende Übersetzungsregel mindesten einen Teil der Paketkommunikation zwischen der ersten Anwendung und der zweiten Anwendung dazu zwingt, über ein spezifiziertes Netz zu laufen.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 2, worin das ausgehende Nachrichtenpaket eine SIP-Nachricht ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin die SIP-Nachricht eine SIP-INVITE-Nachricht ist.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin die erste Anwendung veranlasst, dass die SIP-Nachricht an eine zweite Anwendung im Externadressenbereich gesendet wird.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin der ersten Anwendung Zugriff auf eine assoziierte Externadresse gewährt wird, die eine IP-Adresse und eine Portnummer enthält.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin beim Senden der SIP-Nachricht an eine zweite Anwendung im Externadressenbereich ein SIP-Proxyserver aufgerufen wird.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin die SIP-Nachricht dazu benutzt wird, eine Peer-zu-Peer Kommunikationssitzung aufzubauen.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin die SIP-Nachricht dazu benutzt wird, eine IP-Telefon Kommunikationssitzung aufzubauen.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin die SIP-Nachricht dazu benutzt wird, eine Instant-Messaging-Sitzung aufzubauen.
Netzadressen-Übersetzungsvorrichtung nach Anspruch 14, worin die SIP-Nachricht eine SIP-OK-Nachricht ist.
Verfahren zum Erleichtern der Nachrichtenpaketkommunikation zwischen einer ersten Anwendung (121) mit einer in einem Internadressenbereich (100) gültigen ersten Internadresse und einer oder mehreren Anwendungen (421) in einem Extemadressenbereich (200), wobei die Netzadressen-Übersetzungsvorrichtung über eine Menge von Adressen verfügt, die zum Gebrauch im Extemadressenbereich (200) gültig sind, die folgenden Verfahrensschritte umfassend: eine Netzadressen-Übersetzungsvorrichtung (320) im Internadressenbereich (100), Adressen übersetzend, die in den Köpfen von in den Internadressenbereich eingehenden und von ihm ausgehenden Nachrichtenpaketen enthalten sind, gemäß Übersetzungsregeln, die die Unvereinbarkeit der Adressenschemata der Intern- und Externadressenbereiche auflösen; und einen Adressenmanager (324), der die Übersetzungsregeln festlegt und abspeichert, wobei der Adressenmanager auf die Menge der verfügbaren Adressen Zugriff hat, die zum Gebrauch im Extemadressenbereich gültig sind; gekennzeichnet durch: den Adressenmanager (324), mit der ersten Anwendung über einen Steuerkanal (350) kommunizierend, wobei die Kommunikation einschließt, dass der Adressenmanager von der ersten Anwendung (121) eine Dienstanforderungsnachricht empfängt, die das Festlegen einer von der ersten Anwendung spezifiziertren Adressenübersetzungsregel anfordert; und worin die Logik des Adressenmanagers (324) als Reaktion auf die Dienstanforderung der ersten Anwendung eine Übersetzungsregel festlegt, die durch die erste Anwendung in der Dienstanforderungsnachricht spezifiziert ist.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung empfängt, die spezifiziert, dass die festzulegende Übersetzungsregel die Internadresse der ersten Anwendung mit einer verfügbaren Externadresse assoziiert und der ersten Anwendung Zugriff gewährt auf die assoziierte verfügbare Externadresse als Daten für ein ausgehendes Nachrichtenpaket.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung empfängt und eine Übersetzungsregel festlegt, die die Internadresse der ersten Anwendung mit einer verfügbaren Externadresse assoziiert, die eine bestimmte IP-Adresse ist oder in einem spezifizierten Bereich von IP-Adressen liegt.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung empfängt und eine Übersetzungsregel festlegt, die eine Übersetzungsregel von zwei oder mehreren auf ein eingehendes Nachrichtenpaket anwendbaren Übersetzungsregeln ist, wobei die Auswahl der Übersetzungsregel, die angewandt wird, von Adresseninformation im eingehenden Nachrichtenpaket abhängt.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung nach einer Übersetzungsregel für eine Zieladresse empfängt.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung nach einer Übersetzungsregel für eine Ursprungsadresse empfängt.
Verfahren nach Anspruch 23, worin der Internadressenbereich ein Privatnetz ist und der Adressenmanager auf eine Menge von verfügbaren, im Internet gültigen Adressen zugreift.
Verfahren nach Anspruch 23, worin der Internadressenbereich ein Privatnetz ist und der Extemadressenbereich das Internet ist und der Adressenmanager eine Übersetzungsregel festlegt, indem er eine im Privatnetzbereich gültige Adresse mit einer im Internet gültigen Adresse assoziiert.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung empfängt und eine Übersetzungsregel festlegt, die eine Übersetzungsregel von zwei oder mehreren auf eine eingehende Nachricht anwendbare Übersetzungsregeln ist, wobei die Auswahl der Übersetzungsregel, die angewandt wird, als Reaktion auf das Vorhandensein oder Nichtvorhandensein spezifizierter Ursprungsadresseninformation in der eingehenden Nachricht getroffen wird.
Verfahren nach Anspruch 23, worin die erleichterte Kommunikation eine Peer-zu-Peer Anwendungskommunikation ist.
Verfahren nach Anspruch 23, worin die erleichterte Kommunikation eine Peer-zu-Peer Telefonkommunikation ist.
Verfahren nach Anspruch 24, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung empfängt und eine Übersetzungsregel festlegt, die das ausgehende Nachrichtenpaket dazu zwingt, eine Zieladresse in einem Transitnetz zu haben.
Verfahren nach Anspruch 23, worin die Logik im Adressenmanager von der ersten Anwendung eine Anforderung empfängt und eine Übersetzungsregel festlegt, die mindesten einen Teil der Paketkommunikation zwischen der ersten Anwendung und der zweiten Anwendung dazu zwingt, über ein spezifiziertes Netz zu laufen.
Verfahren nach Anspruch 24, worin das an den Externadressenbereich gesendete ausgehende Nachrichtpaket eine SIP-Nachricht ist.
Verfahren nach Anspruch 36, worin die SIP-Nachricht eine SIP-INVITE-Nachricht ist.
Verfahren nach Anspruch 24, worin die verfügbare Externadresse im ausgehenden Nachrichtenpaket an eine SIP-bewusste Anwendung im Externadressenbereich gesendet wird.
Verfahren nach Anspruch 24, worin die verfügbare Externadresse eine IP-Adresse und eine Portnummer enthält.
Verfahren nach Anspruch 24, worin beim Senden der verfügbaren Externadresse an eine SIP-bewusste Anwendung im Extemadressenbereich ein SIP-Proxyserver aufgerufen wird.
Verfahren nach Anspruch 36, worin die SIP-Nachricht dazu benutzt wird, eine Peer-zu-Peer Kommunikationssitzung aufzubauen.
Verfahren nach Anspruch 36, worin die SIP-Nachricht dazu benutzt wird, eine IP-Telefon Kommunikationssitzung aufzubauen.
Verfahren nach Anspruch 36, worin die SIP-Nachricht dazu benutzt wird, eine Instant-Messaging-Sitzung aufzubauen.
Verfahren nach Anspruch 36, worin die SIP-Nachricht eine SIP-OK-Nachricht ist.