-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung bezieht sich auf ein Quelladressauswahlsystem,
eine Routereinrichtung, einen Kommunikationsknoten und ein Quelladressauswahlverfahren
zum geeigneten Auswählen eines
Ausgangsknotens in dem Fall, wo die Wohnstätten (homes), SOHOs, etc. beständig mit
dem Internet durch eine Vielzahl von ISPs durch Verwenden von IPv6
verbunden sind.
-
HINTERGRUND
DER ERFINDUNG
-
In
den letzten Jahren hat sich die Nutzung des größten Computernetzes der Welt "Internet" ausgebreitet, und
es wurden neue Computergeschäfte durch
Zugriff auf das Internet und Nutzung offengelegter Information oder
Dienste entwickelt, oder durch Vorsehen von Information oder Diensten
für externe
Benutzer, die Zugriffe durch das Internet durchführen. Auch sind neue technologische
Entwicklungen hinsichtlich der Internetnutzung im Gange. In dem
Internet hat jeder Computer einen Identifikator, der IP-Adresse
genannt wird, und der Paketaustausch wird gemäß dieser IP-Adresse ausgeführt. Gewöhnlich kann
der Benutzer in dem Fall eines Zugriffs auf das Internet eine Adresse
durch Abschluss eines Vertrages mit einem ISP (Internet Service
Provider, Internetdienstanbieter) zugeordnet haben.
-
Gegenwärtig wird
die IPv6-Adresse auf der Anbieterbasis zugeordnet. Es wird nämlich eine
Teilmenge der Adressen, die dem Anbieter bereits zugeordnet sind,
dem Benutzer zugeordnet, wenn der Benutzer einen Vertrag mit diesem
Anbieter abschließt.
-
In
der Zukunft wird erwartet, dass sogar ein Netz kleinen Maßstabs,
wie etwa das der Wohnung oder das SOHO, Verträge mit einer Vielzahl von Anbietern
für den
Zweck einer stabilen Nutzung des Internet oder dergleichen abschließen wird.
In einem derartigen Fall wird es eine Vielzahl von Zugriffspunkten
zwischen diesem Netz und dem Internet geben, und diese Situation
wird als eine Multi-Wohnstätte
(multi-home) bezeichnet.
-
Wie
in 12 gezeigt, wird angenommen, dass ein Knoten N
mit dem Internet durch Anbieter A und B verbunden ist. In dem IPv6
kann der Knoten eine Vielzahl von Adressen haben, sodass in diesem Fall
der Knoten N eine Adresse, die durch den Anbieter A zugeordnet ist,
und eine Adresse, die durch den Anbieter B zugeordnet ist, verwenden
kann.
-
Hier
in 12 wird angenommen, dass bei dem Anbieter A eine
Störung
derart auftritt, dass es unmöglich
geworden ist, Pakete von dem Internet zu dem Knoten N über den
Anbieter A zuzustellen.
-
Selbst
wenn der Knoten N versucht, Kommunikation mit einem Server S durch
Verwenden einer Adresse, die zu dem Anbieter A gehört, als
eine Quelladresse auszuführen,
ist es unmöglich,
eine Kommunikation mit dem Server S auszuführen. Dies ist so, da selbst
wenn ein Paket von dem Knoten N durch Verwenden einer Adresse, die
zu dem Anbieter A gehört,
als eine Quelladresse übertragen
wird, eine Route zu dem Server S wegen der Störung unterbrochen ist, die
auf der Seite von Anbieter A auftritt.
-
Dies
kann gelöst
werden, falls es möglich
ist, eine Route derart zu ändern,
dass das Paket, das zu einer Adresse bestimmt ist, die zu dem Anbieter
A gehört, über den
Anbieter B erreichen kann, wie es in dem gegenwärtigen Ipv4-Protokoll geschickt.
Eine derartige Änderung
einer Route kann jedoch zu einer beträchtlichen Erweiterung der Weiterleitungstabelle führen, und
ihre Realisierung ist in dem IPv6-Protokoll, welches einen riesigen
Adressraum hat, durch Verwenden des Standes der Technik ziemlich schwierig.
-
Angenommen
nun, dass das Paket mit einer Adresse, die zu dem Anbieter A gehört, als
eine Quelladresse den Server S über
eine Route des Anbieters B erreicht. Wenn das Paket mit einer Adresse, die
zu dem Anbieter A gehört,
als eine Quelladresse empfangen wird, versucht der Server S in diesem Fall,
eine Kommunikation über
eine Route des Anbieters A in einem Versuch, eine Kommunikation
mit einem Quellknoten gemäß dieser
Quelladresse auszuführen,
herzustellen. Das Antwortpaket von dem Server S kann den Knoten
N jedoch nicht erreichen, da der Anbieter A eine Störung hat,
und eine Kommunikation kann nicht ausgeführt werden. Außerdem wird in
dem IPv6 sehr häufig
ein Eingangsfilter (IETF RFC 2267 und RFC 2827) eingesetzt, aber
wenn er eingesetzt wird, wird dem Paket mit einer Adresse, die zu dem
Anbieter A gehört,
nicht erlaubt, den Anbieter B an erster Stelle zu passieren, sodass
das Paket den Server S nicht erreichen wird.
-
In
dem SOHO oder dergleichen ist es, falls die Multi-Wohnstätte wegen
einem derartigen Problem nicht effizient genutzt werden kann, schwierig, die
Zuverlässigkeit
des Internet zu verbessern.
-
Wie
beschrieben war es im Stand der Technik schwierig, die Multi-Wohnstätte in der
IPv6-Umgebung effizient zu nutzen.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Es
ist deshalb ein Ziel der vorliegenden Erfindung, ein Quelladressauswahlsystem,
eine Routereinrichtung, einen Kommunikationsknoten und ein Quelladressauswahlverfahren
vorzusehen, die zum effektiven Nutzen der Multi-Wohnstätten-Umgebung fähig sind.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird ein Quelladressauswahlsystem
vorgesehen, umfassend eine Routereinrichtung, die mit einer Vielzahl
von Internetdienstanbietern verbunden ist, und einen Kommunikationsknoten,
der mit der Routereinrichtung verbunden ist, wobei: die Routereinrichtung
aufweist: eine erste Prüfeinheit,
die konfiguriert ist, Konnektivitäten mit den Internetdienstanbietern
zu prüfen;
eine erste Empfangseinheit, die konfiguriert ist, einen Netzpräfix zu empfangen,
der durch einen Internetdienstanbieter bereitgestellt wird, für den eine
Konnektivität
durch die erste Prüfeinheit bestätigt ist;
und eine Bekanntgabeeinheit, die konfiguriert ist, den Netzpräfix bekannt
zu geben, der durch die erste Empfangseinheit empfangen wird; der
Kommunikationsknoten aufweist: eine zweite Empfangseinheit, die
konfiguriert ist, den Netzpräfix von
der Routereinrichtung zu empfangen; eine Generierungseinheit, die
konfiguriert ist, eine Netzadresse gemäß dem Netzpräfix und
einem Identifikator, der für
den Kommunikationsknoten eindeutig ist, zu generieren; und eine Übertragungseinheit,
die konfiguriert ist, ein Paket durch Anbringen der Netzadresse als
eine Quelladresse zu einem Header zu übertragen; und die Routereinrichtung
auch aufweist: eine zweite Prüfeinheit,
die konfiguriert ist zu prüfen,
ob das Paket, das von dem Kommunikationsknoten empfangen wird, die
Quelladresse mit dem Netzpräfix
hat, der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist, oder nicht; und eine Steuereinheit, die konfiguriert ist, das
Paket zu dem Internetdienstanbieter zu transferieren, von dem der Netzpräfix empfangen
wird, wenn die Quelladresse den Netzpräfix hat, der von dem Internetdienstanbieter
empfangen wird, für
den die Konnektivität
durch die Routereinrichtung bestätigt
ist, oder dem Kommunikationsknoten bekannt zu geben, dass ein Transfer
des Pakets nicht ausgeführt
wurde, ohne Ausführen
des Transfers des Pakets, wenn die Quelladresse nicht den Netzpräfix hat,
der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird eine Routereinrichtung
vorgesehen, die mit einer Vielzahl von Internetdienstanbietern und
einem lokalen Netz verbunden ist, zum Transferieren eines Pakets
von einem Kommunikationsknoten, der mit dem lokalen Netz verbunden
ist, die Routereinrichtung umfassend: eine erste Prüfeinheit,
die konfiguriert ist, Konnektivitäten mit den Internetdienstanbietern
zu prüfen;
eine Empfangseinheit, die konfiguriert ist, einen Netzpräfix zu empfangen, der
durch einen Internetdienstanbieter bereitgestellt wird, für den eine
Konnektivität
durch die erste Prüfeinheit
bestätigt
ist; eine Bekanntgabeeinheit, die konfiguriert ist, den Netzpräfix, der
durch die Empfangseinheit empfangen wird, zu dem lokalen Netz bekannt
zu geben; eine zweite Prüfeinheit,
die konfiguriert ist zu prüfen,
ob das Paket, das von dem Kommunikationsknoten empfangen wird, eine
Quelladresse mit dem Netzpräfix
hat, der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist, oder nicht; und eine Steuereinheit, die konfiguriert ist, das
Paket zu dem Internetdienstanbieter zu transferieren, von dem der
Netzpräfix
empfangen wird, wenn die Quelladresse den Netzpräfix hat, der von dem Internetdienstanbieter
empfangen wird, für
den die Konnektivität
durch die Routereinrichtung bestätigt
ist, oder dem Kommunikationsknoten bekannt zu geben, dass ein Transfer
des Pakets nicht ausgeführt wurde,
ohne Ausführen
des Transfers des Pakets, wenn die Quelladresse nicht den Netzpräfix hat,
der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird ein Kommunikationsknoten vorgesehen
zum Ausführen
von Kommunikationen mit einem gewünschten korrespondierenden
Knoten durch eine Routereinrichtung, die mit einer Vielzahl von
Internetdienstanbietern verbunden ist, der Kommunikationsknoten
umfassend: eine Empfangseinheit, die konfiguriert ist, einen Netzpräfix, der
durch einen Internetdienstanbieter bereitgestellt wird, von der
Routereinrichtung zu empfangen; eine Generierungseinheit, die konfiguriert
ist, eine Netzadresse gemäß dem Netzpräfix und
einem Identifikator, der für
den Kommunikationsknoten eindeutig ist, zu generieren; und eine Übertragungseinheit,
die konfiguriert ist, ein Paket durch Anbringen der Netzadresse als
eine Quelladresse zu einem Header zu übertragen; wobei der Kommunikationsknoten
die Quelladresse des Pakets zu einer anderen Netzadresse, die gemäß einem
neu bekannt gegebenen Netzpräfix generiert
ist, und dem Identifikator, der für den Kommunikationsknoten
eindeutig ist, ändert
und das Paket erneut überträgt, wenn
eine Bekanntgabe, dass der Transfer des Pakets nicht ausgeführt wurde,
von der Routereinrichtung in Bezug auf das Paket, das durch die Übertragungseinheit übertragen
wird, empfangen wird und eine Bekanntgabe des Netzpräfixes des
Internetdienstanbieters, für
den die Konnektivität bestätigt ist,
empfangen wird.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird ein Quelladressauswahlverfahren
in einer Routereinrichtung, die mit einer Vielzahl von Internetdienstanbietern
und einem lokalen Netz verbunden ist, zum Transferieren eines Pakets von
einem Kommunikationsknoten, der mit dem lokalen Netz verbunden ist,
vorgesehen, das Quelladressauswahlverfahren umfassend: Prüfen von
Konnektivitäten
mit den Internetdienstanbietern; Empfangen eines Netzpräfixes, der
durch einen Internetdienstanbieter bereitgestellt wird, für den eine
Konnektivität bestätigt ist;
Bekannt geben des empfangenen Netzpräfixes zu dem lokalen Netz;
Prüfen,
ob das Paket, das von dem Kommunikationsknoten empfangen wird, eine
Quelladresse mit dem Netzpräfix
hat, der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist, oder nicht; und Transferieren des Pakets zu dem Internetdienstanbieter,
von dem der Netzpräfix
empfangen ist, wenn die Quelladresse den Netzpräfix hat, der von dem Internetdienstanbieter
empfangen ist, für
den die Konnektivität
durch die Routereinrichtung bestätigt
ist, oder Bekannt geben zu dem Kommunikationsknoten, dass ein Transfer
des Pakets nicht ausgeführt
wurde, ohne Ausführen
des Transfers des Pakets, wenn die Quelladresse nicht den Netzpräfix hat,
der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird ein Computerprogrammprodukt
vorgesehen zum Veranlassen eines Computers, als eine Routereinrichtung
zu funktionieren, verbunden mit einer Vielzahl von Internetdienstanbietern und
einem lokalen Netz, zum Transferieren eines Pakets eines Kommunikationsknotens,
der mit dem lokalen Netz verbunden ist, das Computerprogrammprodukt
umfassend: einen ersten Computerprogrammcode zum Veranlassen des
Computers, Konnektivitäten
mit den Internetdienstanbietern zu prüfen; einen zweiten Computerprogrammcode
zum Veranlassen des Computers, einen Netzpräfix zu empfangen, der durch
einen Internetdienstanbieter bereitgestellt wird, für den eine
Konnektivität
durch den ersten Computerprogrammcode bestätigt ist; einen dritten Compu terprogrammcode
zum Veranlassen des Computers, den Netzpräfix, der durch den zweiten
Computerprogrammcode empfangen wird, zu dem lokalen Netz bekannt
zu geben; einen vierten Computerprogrammcode zum Veranlassen des Computers
zu prüfen,
ob das Paket, das von dem Kommunikationsknoten empfangen wird, eine
Quelladresse mit dem Netzpräfix
hat, der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist, oder nicht; und einen fünften
Computerprogrammcode zum Veranlassen des Computers, das Paket zu dem
Internetdienstanbieter zu transferieren, von dem der Netzpräfix empfangen
wird, wenn die Quelladresse den Netzpräfix hat, der von dem Internetdienstanbieter
empfangen wird, für
den die Konnektivität durch
die Routereinrichtung bestätigt
ist, oder zu dem Kommunikationsknoten bekannt zu geben, dass ein Transfer
des Pakets nicht ausgeführt
wurde, ohne Ausführen
des Transfers des Pakets, wenn die Quelladresse nicht den Netzpräfix hat,
der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird ein Quelladressauswahlverfahren
vorgesehen in einem Kommunikationsknoten zum Ausführen von
Kommunikationen mit einem gewünschten
korrespondierenden Knoten durch eine Routereinrichtung, die mit
einer Vielzahl von Internetdienstanbietern verbunden ist, das Quelladressauswahlverfahren
umfassend: Empfangen eines Netzpräfixes, der durch einen Internetdienstanbieter
bereitgestellt wird, von der Routereinrichtung; Generieren einer
Netzadresse entsprechend dem Netzpräfix und einem Identifikator,
der für
den Kommunikationsknoten eindeutig ist; Übertragen eines Pakets durch Anbringen
der Netzadresse als eine Quelladresse an einen Header; und Ändern der
Quelladresse des Pakets zu einer anderen Netzadresse, die gemäß einem
neu bekannt gegebenen Netzpräfix
generiert ist, und dem Identifikator, der für den Kommunikationsknoten
eindeutig ist, und erneutes Übertragen
des Pakets, wenn eine Bekanntgabe, dass der Transfer des Pakets
nicht ausgeführt
wurde, von der Routereinrichtung mit Bezug auf das übertragene
Paket empfangen wird, und eine Bekanntgabe des Netzpräfixes des
Internetdienstanbieters, für
den die Konnektivität
bestätigt
ist, empfangen wird.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird ein Computerprogrammprodukt
vorgesehen zum Veranlassen eines Computers, als ein Kommunikationsknoten
zu funktionieren, zum Ausführen
von Kommunikationen mit einem gewünschten korrespondierenden
Knoten durch eine Routereinrichtung, die mit einer Vielzahl von
Internetdienstanbietern verbunden ist, das Computerprogrammprodukt
umfassend: einen ersten Computerprogrammcode zum Veranlassen des
Computers, einen Netzpräfix,
der durch einen Internetdienstanbieter bereitgestellt wird, von
der Routereinrichtung zu empfangen; einen zweiten Computerprogrammcode zum
Veranlassen des Computers, eine Netzadresse gemäß dem Netzpräfix und
einem Identifikator, der für
den Kommunikationsknoten eindeutig ist, zu generieren; einen dritten
Computerprogrammcode zum Veranlassen des Computers, ein Paket durch
Anbringen der Netzadresse als eine Quelladresse an einem Header
zu übertragen;
und einen vierten Computerprogrammcode zum Veranlassen des Computers, die
Quelladresse des Pakets zu einer anderen Netzadresse, die gemäß einem
neu bekannt gegebenen Netzpräfix
generiert wird, und dem Identifikator, der für den Kommunikationsknoten
eindeutig ist, zu ändern
und das Paket erneut zu übertragen,
wenn eine Bekanntgabe, dass der Transfer des Pakets nicht ausgeführt wurde,
von der Routereinrichtung mit Bezug auf das Paket, das durch den
dritten Computerprogrammcode übertragen
wird, empfangen wird, und eine Bekanntgabe des Netzpräfixes des
Internetdienstanbieters, für
den die Konnektivität
bestätigt ist,
empfangen wird.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung wird ein Quelladressauswahlverfahren
vorgesehen in einem Quelladressauswahlsystem, enthaltend eine Routereinrichtung,
die mit einer Vielzahl von Internetdienstanbietern verbunden ist, und
einen Kommunikationsknoten, der mit der Routereinrichtung verbunden
ist, das Quelladressauswahlverfahren umfassend: Prüfen von
Konnektivitäten
mit den Internetdienstanbietern in der Routereinrichtung; Empfangen
eines Netzpräfixes,
der durch einen Internetdienstanbieter bereitgestellt wird, für den eine
Konnektivität
bestätigt
ist, in der Routereinrichtung; Bekannt geben des empfangenen Netzpräfixes in
der Routereinrichtung; Empfangen des Netzpräfixes von der Routereinrichtung
in dem Kommunikationsknoten; Generieren einer Netzadresse gemäß dem Netzpräfix und
einem Identifikator, der für
den Kommunikationsknoten eindeutig ist, in dem Kommunikationsknoten; Übertragen
eines Pakets durch Anbringen der Netzadresse als eine Quelladresse
an einem Header indem Kommunikationsknoten; Prüfen, ob das Paket, das von
dem Kommunikationsknoten empfangen wird, die Quelladresse mit dem
Netzpräfix
hat, der von dem Internetdienstanbieter empfangen wird, für den die
Konnektivität
durch die Routereinrichtung bestätigt
ist, oder nicht, in der Routereinrichtung; und Transferieren des
Pakets zu dem Internetdienstanbieter, von dem der Netzpräfix empfangen
wird, wenn die Quelladresse den Netzpräfix hat, der von dem Internetdienstanbieter
empfangen wird, für
den die Konnektivität
durch die Routereinrichtung bestätigt
ist, in der Routereinrichtung, oder Bekannt geben zu dem Kommunikationsknoten, dass
ein Transfer des Pakets nicht ausgeführt wurde, ohne Ausführen des
Transfer des Pakets, wenn die Quelladresse nicht den Netzpräfix hat,
der von dem Internetdienstanbieter empfangen wird, für den die Konnektivität durch
die Routereinrichtung bestätigt ist,
in der Routereinrichtung.
-
Die
vorliegende Erfindung kann entweder in Hardware oder in Software
in einem Mehrzweckcomputer implementiert werden. Ferner kann die
vorliegende Erfindung in einer Kombination von Hardware und Software
implementiert werden. Die vorliegende Erfindung kann auch durch
eine einzelne Verarbeitungsvorrichtung oder ein verteiltes Netz
von Verarbeitungsvorrichtungen implementiert werden.
-
Da
die vorliegende Erfindung durch Software implementiert werden kann,
schließt
die vorliegende Erfindung Computercode ein, der zu einem Mehrzweckcomputer
auf einem beliebigen geeigneten Trägermedium bereitgestellt wird.
Das Trägermedium
kann ein beliebiges Speichermedium umfassen, wie etwa eine Floppy-Disk,
eine CD-ROM, eine magnetische Einrichtung oder eine programmierbare Speichereinrichtung
oder ein beliebiges transientes Medium, wie etwa ein beliebiges
Signal, z.B. ein elektrisches, optisches oder Mikrowellensignal.
-
Andere
Merkmale und Vorteile der vorliegenden Erfindung werden aus der
folgenden Beschreibung, genommen in Verbindung mit den begleitenden
Zeichnungen, offensichtlich.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
ein schematisches Diagramm, das eine beispielhafte Konfiguration
eines Netzsystems gemäß einer
Ausführungsform
der vorliegenden Erfindung zeigt.
-
2 ist
ein Blockdiagramm, das eine beispielhafte Konfiguration eines Routers
gemäß einer Ausführungsform
der vorliegenden Erfindung zeigt.
-
3 ist
ein Blockdiagramm, das eine beispielhafte Konfiguration eines Kommunikationsknotens
gemäß einer
Ausführungsform
der vorliegenden Erfindung zeigt.
-
4.
ist ein Flussdiagramm, das eine beispielhafte Verarbeitungsprozedur
des Routers von 2 zeigt.
-
5 ist
ein Flussdiagramm, das eine beispielhafte Verarbeitungsprozedur
des Kommunikationsknotens von 3 zeigt.
-
6 ist
ein Flussdiagramm, das eine andere beispielhafte Verarbeitungsprozedur
des Routers von 2 zeigt.
-
7 ist
ein Diagramm, das eine beispielhafte Konfiguration einer ICMP-Nachricht
gemäß einer
Ausführungsform
der vorliegenden Erfindung zeigt.
-
8 ist
ein Flussdiagramm, das eine andere beispielhafte Verarbeitungsprozedur
des Kommunikationsknotens von 3 zeigt.
-
9A, 9B und 9C sind
Sequenzdiagramme, die beispielhafte Operationssequenzen für das Netzsystem
von 1 zeigen.
-
10 ist
ein Sequenzdiagramm, das eine andere beispielhafte Operationssequenz
für das Netzsystem
von 1 zeigt.
-
11 ist
ein Diagramm, das eine beispielhafte Konfiguration einer Präfixmanagementtabelle gemäß einer
Ausführungsform
der vorliegenden Erfindung zeigt.
-
12 ist
ein schematisches Diagramm, das ein konventionelles Netzsystem in
einer Multi-Wohnstätten-Umgebung
zeigt.
-
DETAILLIERTE
BESCHREIBUNG
-
Bezug
nehmend nun auf 1 bis 11 wird
eine Ausführungsform
der vorliegenden Erfindung detailliert beschrieben.
-
1 zeigt
eine beispielhafte Konfiguration eines Netzsystems, das die Multi-Wohnstätten-Umgebung
involviert, gemäß einer
Ausführungsform
der vorliegenden Erfindung.
-
Das
Netzsystem von 1 hat einen Kommunikationsknoten
N mit einer IPv6-Adresse, der typischerweise ein Computer ist, aber
nicht notwendigerweise darauf begrenzt ist, und kann etwas beliebiges
sein, inkludierend ein tragbares Telefonendgerät, eine Informationsheimelektronikeinrichtung
etc., solange wie es zum Zugriff auf das Internet durch eine Vielzahl
von Internetdienstanbietern fähig
ist.
-
Das
Netzsystem von 1 hat auch das Internet I und
einen Server S, der mit dem Internet verbunden ist, was als eine
beispielhafte Entsprechung des Kommunikationsknotens N verwendet
wird. Natürlich
kann die Entsprechung des Kommunikationsknotens N ein Kommunikationsknoten
eines Typs anders als der Server sein.
-
Das
Netzsystem von 1 hat auch Router R1 und R2,
die Eingangsrouter zu dem Internet aus einer Sicht des Kommunikationsknotens
N sind. Das Netzsystem von 1 hat auch
(Netze von) Internetdienstanbieter(n) ISPa und ISPb, die mit dem
Internet verbunden sind und Internetzugriffsdienste für Kommunikationsknoten
vorsehen, und die mit der Seite vom Router R1 aus Sicht des Kommunikationsknotens
N verbunden sind. Das Netzsystem von 1 hat auch
(Netze von) Internetdienstanbieter(n) ISPc und ISPd, die mit dem
Internet verbunden sind und Internetzugriffsdienste für Kommunikationsknoten vorsehen,
die mit der Seite vom Router R2 aus Sicht des Kommunikationsknotens
N verbunden sind.
-
In
diesem Beispiel sieht jeder der Internetdienstanbieter ISPa bis
ISPd den Dienst zum Ermöglichen
von Kommunikationen mit dem Server S in dem Internet zu dem Kommunikationsknoten
N vor (der Internetdienstanbieter wird im folgenden auch als Anbieter
oder ISP bezeichnet).
-
Hier
können
der Anbieter ISPa und der Router R1 durch eine beständige Verbindung
unter Verwendung einer dedizierten Leitung oder durch eine Wählverbindung
verbunden sein. Die gleiche Bemerkung trifft auch auf die Verbindung
zwischen dem Anbieter ISPb und dem Router R1, die Verbindung zwischen
dem Anbieter ISPc und dem Router R2 und die Verbindung zwischen
dem Anbieter ISPd und dem Router R2 zu.
-
Es
wird vermerkt, dass "Pa" einen Präfix (Netzpräfix) bezeichnet,
der durch Anbieter ISPa bereitgestellt wird, und ähnlich "Pb", "Pc" und "Pd" die Präfixe bezeichnen,
die durch die Anbieter ISPb, ISPc bzw. ISPd bereitgestellt werden.
-
Angenommen
auch, dass dem Kommunikationsknoten N die jeweiligen Präfixe von
den Anbietern ISPa, ISPb, ISPc und ISPd gegeben werden und die Schnittstellen-ID
des Kommunikationsknotens N (ein Identifikator, der für den Kommunikationsknoten N
eindeutig ist) N ist, hat der Kommunikationsknoten N vier Netzadressen
(in diesem Fall globale Adressen), inkludierend "Pa::N", "Pb::N", "Pc::N" und "Pd::N". Hier wird angenommen,
dass die IPv6-Adresse in 128 Bits die oberen 64 Bits für den Präfix, der
von dem Anbieter gegeben wird, und die unteren 64 Bits für die Schnittstellen-ID
inkludiert. Es wird vermerkt, dass die Netzadresse gewöhnlich jeder
Schnittstelle zugewiesen wird.
-
Es
wird vermerkt, dass in der beispielhaften Konfiguration von 1 der
Kommunikationsknoten N die vier ISPs durch einen beliebigen der
zwei Router nutzen kann, es ist aber natürlich möglich ist, eine beliebige Zahl
von Routern zu verwenden, um eine beliebige Zahl von ISPs zu nutzen.
Es ist auch möglich,
eine beliebige Zahl von ISPs durch einen Router zu nutzen.
-
Auch
wird in der beispielhaften Konfiguration von 1 nur ein
Kommunikationsknoten gezeigt, es können aber auch andere Kommunikationsknoten
in dem gleichen Teilnetz existieren, zu dem der Kommunikationsknoten
N gehört.
-
Auch
wird in der beispielhaften Konfiguration von 1 nur eine
Entsprechung des Kommunikationsknotens N gezeigt, natürlich können aber
auch die anderen Entsprechungen existieren. Auch kann die Entsprechung
des Kommunikationsknotens N mit dem Internet verbunden sein, direkt
oder durch ISPs, die sich von jenen unterscheiden, die durch den Kommunikationsknoten
N verwendet werden, oder durch die gleichen ISPs, die durch den
Kommunikationsknoten N verwendet werden, oder durch Teilnetze außer jenen
der ISPs. Auch kann die Entsprechung des Kommunikationsknotens N
ein Benutzer einer Multi-Wohnstätte
sein oder nicht, auf die die vorliegende Erfindung angewendet wird.
-
Im
folgenden werden hauptsächlich
die Konfiguration und der Betrieb des Routers R1 beschrieben, aber
die Beschreibung hinsichtlich des Routers R1 trifft im wesentlichen
auch auf den Router R2 zu.
-
2 zeigt
eine beispielhafte Konfiguration des Routers R1 oder R2 gemäß einer
Ausführungsform
der vorliegenden Erfindung.
-
Wie
in 2 gezeigt, hat der Router dieser Ausführungsform
eine Empfangseinheit 31 zum Empfangen von Paketen von (Kanälen, verbunden mit)
der Seite des Kommunikationsknotens N oder (Kanälen, verbunden mit) der ISP-Seite,
eine Übertragungseinheit 32 zum Übertragen
von Paketen zu (Kanälen,
ver bunden mit) dem Kommunikationsknoten N oder (Kanälen, verbunden
mit) der ISP-Seite, und eine Pakettransfer-Verarbeitungseinheit 33 zum Ausführen einer
Verarbeitung, die beim Transfer von Paketen notwendig ist, was eine
gewöhnliche
Rolle des Routers ist, und einer Verarbeitung, wie etwa eine Beurteilung
bezüglich
dessen, ob der Transfer des Pakets von dem Kommunikationsknoten
zu dem ISP möglich
ist oder nicht gemäß der Konnektivität mit dem
ISP, einer Bekanntgabe zu dem Kommunikationsknoten N, wenn das Paket
nicht transferiert wird, und einer Bekanntgabe eines Präfixes, der
zu verwenden ist, zu dem Kommunikationsknoten N, was nachstehend
detailliert beschrieben wird. Der Router dieser Ausführungsform
hat auch eine ISP-Zustandsmanagementeinheit 34 zum Managen
eines Zustands eines Ziel-ISP (Prüfen der Konnektivität) und eine
Präfixmanagementeinheit 35 zum
Managen eines Präfixes,
der von einem Ziel-ISP bereitgestellt wird.
-
Es
wird vermerkt, dass die notwendige Information, wie etwa Information
hinsichtlich eines Zustands des ISP (Information, die z.B. anzeigt,
ob die Konnektivität
bestätigt
ist oder nicht), der zugewiesene Präfix etc. in einer geeigneten
Speichereinrichtung gespeichert wird. Auch werden eine Kommunikationsschnittstelle
zum Durchführen
einer Verbindung mit dem Teilnetz, mit dem der Kommunikationsknoten
N verbunden ist, und Kommunikationsschnittstellen zum Durchführen von
Verbindungen mit Kanälen,
die mit den ISPs verbunden sind, weggelassen, um in 2 gezeigt
zu werden.
-
Es
wird auch vermerkt, dass der Router R1 durch Verwenden eines Computers
realisiert werden kann, und die gesamte oder ein Teil seiner Verarbeitung
durch ein Programm oder eine dedizierte integrierte Halbleiterschaltung
realisiert werden kann.
-
3 zeigt
eine beispielhafte Konfiguration des Kommunikationsknotens N gemäß einer
Ausführungsform
der vorliegenden Erfindung.
-
Wie
in 3 gezeigt, hat der Kommunikationsknoten dieser
Ausführungsform
eine Empfangseinheit 11 zum Empfangen von Paketen von dem Teilnetz,
mit dem die Router R1 und R2 verbunden sind, eine Übertragungseinheit 12 zum Übertragen von
Paketen zu dem Teilnetz und eine Kommunikationsverarbeitungseinheit 13 zum
Ausführen
einer Verarbeitung, die beim Austausch von Paketen mit einer Entsprechung
notwendig ist, und einer Verarbeitung, wie etwa einer Auswahl des
ISP, der zu verwenden ist, und einer Handhabung der Bekanntgabe von
dem Router R1 oder R2 etc., was nachstehend detailliert beschrieben
wird. Der Kommunikationsknoten dieser Ausführungsform hat auch eine Präfixmanagementeinheit 14 zum
Managen eines Präfixes,
der von dem Router R1 oder R2 bekannt gegeben wird, und eine Netzadressgenerierungseinheit 15 zum
Generieren einer Netzadresse gemäß dem Präfix, der
von dem Router R1 oder R2 bekannt gegeben wird, und der Schnittstellen-ID
des Kommunikationsknotens selbst. Es wird vermerkt, dass die notwendige
Information, wie etwa der Präfix,
die Netzadresse etc. in einer geeigneten Speichereinrichtung gespeichert
wird. Auch wird eine Kommunikationsschnittstelle weggelassen, um
in 3 gezeigt zu werden.
-
Es
wird auch vermerkt, dass die gesamte oder ein Teil der Verarbeitung
dieses Kommunikationsknotens durch ein Programm oder eine dedizierte integrierte
Halbleiterschaltung realisiert werden kann.
-
Im
folgenden wird der Betrieb gemäß dieser Ausführungsform
beschrieben.
-
Zuerst
wird die Anfangsstufe des Betriebs beschrieben.
-
Der
Router R1 prüft
die Konnektivitäten
mit dem ISPa und ISPb, empfängt
die Präfixe,
die durch die ISPs bereitgestellt werden, für die die Konnektivität bestätigt ist,
und speichert und managt die empfangenen Präfixe, während auch alle eines Teils
von ihnen dem Kommunikationsknoten N bekannt gegeben werden (oder
sie innerhalb des Teilnetzes angekündigt werden).
-
Ähnlich prüft der Router
R2 die Konnektivität mit
dem ISPc und ISPd, empfängt
die Präfixe,
die durch die ISPs bereitgestellt werden, für die die Konnektivität bestätigt ist,
und speichert und managt die empfangenen Präfixe, während auch alle eines Teils von
ihnen dem Kommunikationsknoten N bekannt gegeben werden (oder sie
innerhalb des Teilnetzes angekündigt
werden).
-
Andererseits
empfängt
der Kommunikationsknoten N den Präfix von dem Router R1 oder
dem Router R2, speichert den empfangenen Präfix, generiert die Netzadresse
gemäß dem Präfix und
der Schnittstellen-ID des Kommunikationsknotens selbst und weist
die Netzadresse einer entsprechenden Schnittstelle zu. Z.B. werden
wie in dem früheren
Beispiel vier Netzadressen "Pa::N", "Pb::N", "Pc::N" und "Pd::N" generiert und zugewiesen
(den Schnittstellen).
-
Nachdem
eine oder mehr Netzadressen generiert sind, wird es dem Kommunikationsknoten
N möglich,
Kommunikationen mit dem Server S auszuführen (vorausgesetzt, dass der
entsprechende ISP die Konnektivität hat).
-
Nachdem
zwei oder mehr Netzadressen generiert und der gleichen Schnittstelle
zugewiesen sind, kann auch die Netzadresse, die als eine Quelladresse
zu verwenden ist, für
diese Schnittstelle geeignet ausgewählt werden. Es gibt viele Vari ationen für das Auswahlverfahren,
wie etwa ein Verfahren zum zufälligen
Auswählen,
ein Verfahren zum Auswählen
gemäß einer
beliebigen Reihenfolge und ein Verfahren zum Auswählen einer,
die eine Lebensdauer hat, die zuletzt abläuft, wenn der Präfix eine Lebensdauer
hat. Es kann auch die Fälle
geben, wo die Prioritätsreihenfolge
gemäß dem Attribut
(z.B. Transfergeschwindigkeit, Dienstinhalt und Gebühr) des
zu verwendenden ISP abhängig
von einer Entität (z.B.
Anwendungssoftware), die die Kommunikationen ausführt, spezifiziert
wird.
-
Als
Nächstes
wird die periodische Prüfung der
Konnektivität
mit jedem ISP durch den Router beschrieben.
-
Der
Router R1 prüft
periodisch die Konnektivitäten
mit dem ISPa und dem ISPb, und aktualisiert den gemanagten Inhalt
des Präfixes,
wenn es eine Änderung
in der Konnektivität
gibt. Wenn z.B. die Konnektivität
des ISP, für
den die Konnektivität
bis dann bestätigt
wurde, nicht bestätigt
werden kann, wird der Präfix,
der von dem ISP zugeordnet wird, für den die Konnektivität unbestätigt wird,
aktualisiert, in der Managementinformation nicht verfügbar zu
sein, die den Präfix
unterhält,
der von dem ISP zugeordnet wurde, für den die Konnektivität bestätigt wurde,
oder dieser Präfix
wird aus dieser Managementinformation gelöscht. Wenn die Konnektivität des ISP,
für den die
Konnektivität
bis dann nicht bestätigt
wurde, bestätigt
werden kann, wird auch der Präfix,
der von dem ISP zugeordnet wird, für den die Konnektivität bestätigt wird,
aktualisiert, in der Managementinformation verfügbar zu sein, die den Präfix unterhält, der von
dem ISP zugeordnet wurde, für
den die Konnektivität
bestätigt
wurde, oder der Präfix
wird von diesem ISP empfangen und dieser Managementinformation hinzugefügt.
-
Wenn
es eine Änderung
in der Konnektivität gibt,
kann diese Tatsache dem Kommunikationsknoten N zu diesem Punkt bekannt gegeben
werden (oder innerhalb des Teilnetzes angekündigt werden), oder diese Tatsache
kann dem Kommunikationsknoten N bekannt gegeben werden, wenn ein
Paket von dem Kommunikationsknoten N danach empfangen wird, je nach
Notwendigkeit (falls es z.B. beurteilt wird notwendig zu sein gemäß dem Präfix der
Quelladresse des empfangenen Pakets).
-
Das
Verfahren, durch das der Router R1 die Konnektivität von jedem
ISP periodisch prüft,
ist nicht auf ein beliebiges spezifisches Verfahren begrenzt, und
es ist möglich,
z.B. in einem vorgeschriebenen Intervall ein Nachbarschaftssondierungspaket
zu einem gewünschten
Kommunikationsknoten durch den ISP zu übertragen, dessen Konnektivität zu prüfen ist.
Es ist auch z.B. möglich,
eine Bekanntgabe periodisch von der ISP-Seite zu empfangen, die anzeigt, dass
die Verbindung normal ist, oder einen Zustand des Kommunikationspfades
zu empfangen, der weiter stromaufwärts von dem verbundenen ISP
ist.
-
Als
Nächstes
zeigt 4 eine beispielhafte Verarbeitungsprozedur in
dem Fall, wo der Router R1 ein Paket von dem Kommunikationsknoten
N empfängt.
-
Der
Router R1 empfängt
ein Paket von dem Kommunikationsknoten N (Schritt S1) und prüft, ob die
Quelladresse (src addr) in einem Header-Abschnitt von diesem Paket
eine vorgeschriebene Bedingung erfüllt oder nicht (Schritt S2).
-
Hier
besteht die vorgeschriebene Bedingung darin, dass der Präfix der
Quelladresse des empfangenen Paketes ein Präfix ist, der durch den ISP
bereitgestellt wird, für
den die Konnektivität
bestätigt
ist. Wenn nämlich
z.B. die Konnektivitäten
des ISPa und ISPb bestätigt
sind, prüft
der Router R1, ob die Quelladresse eine Adresse mit dem Präfix ist
oder nicht, der entweder ein Präfix
ist, der von dem ISPa zugeordnet ist, oder ein Präfix, der
von dem ISPb zugeordnet ist, mit denen der Router R1 gegenwärtig verbunden
ist. Auch wenn z.B. die Konnektivität des ISPa allein bestätigt ist,
prüft der
Router R1, ob die Quelladresse eine Adresse mit dem Präfix ist
oder nicht, der ein Präfix
ist, der von dem ISPa zugeordnet ist, mit dem der Router R1 gegenwärtig verbunden ist.
-
Wenn
die Quelladresse des empfangenen Pakets von dem Kommunikationsknoten
N eine Adresse mit dem Präfix
ist, der ein Präfix
ist, der von dem ISP zugeordnet ist, mit dem der Router R1 gegenwärtig verbunden
ist (Schritt S3 JA), transferiert der Router R1 dieses empfangene
Paket zu dem entsprechenden ISP (Schritt S4).
-
Wenn
andererseits die Quelladresse eine Adresse mit dem Präfix ist,
der nicht ein Präfix
ist, der von dem ISP zugeordnet ist, mit dem der Router R1 gegenwärtig verbunden
ist (Schritt S3 NEIN), wird Information (Präfix-inkorrekt), die anzeigt,
dass der Transfer des Pakets nicht ausgeführt wurde (d.h. der Präfix dieser
Quelladresse nicht verwendet werden kann) zu dem Kommunikationsknoten
N übertragen, der
dieses Paket übertragen
hat, z.B. durch Verwendung einer ICMP (Internet-Steuernachrichtenprotokoll,
Internet Control Message Protocol) (Schritt S5).
-
Als
Nächstes
zeigt 5 eine beispielhafte Verarbeitungsprozedur in
dem Fall, wo der Kommunikationsknoten N ein Paket überträgt, das
für den Server
S bestimmt ist, und dieses Paket zu dem Router R1 transferiert wird,
aber dieses Paket durch den Router R1 nicht transferiert wird.
-
Zuerst überträgt der Kommunikationsknoten N
ein Paket, das für
den Server S bestimmt ist (Schritt S11).
-
Angenommen,
dass der Präfix
der Adresse, die als die Quelladresse zu diesem Punkt ausgewählt ist,
eine Adresse in Bezug auf den ISP ist, dessen Zustand der geworden
ist, in dem die Konnektivität durch
den Router R1 gegenwärtig
nicht bestätigt
ist. In diesem Fall überträgt, wie
oben beschrieben, der Router R1 eine Ankündigungsnachricht, die anzeigt, das
der Transfer des Pakets nicht ausgeführt wurde.
-
Wenn
die Ankündigung,
die anzeigt, dass der Transfer des Pakets nicht ausgeführt wurde,
von dem Router R1 empfangen wird (Schritt S12), prüft der Kommunikationsknoten
N, ob die Netzadresse mit einem Präfix, der sich von dem Präfix der
Quelladresse unterscheidet, die bei Übertragung dieses Pakets verwendet
wird, wofür
die Ankündigung
empfangen ist, als die Quelladresse des Pakets verwendet werden
kann, das für
den Server S bestimmt ist, oder nicht (Schritt S13).
-
Falls
sie verwendet werden kann (Schritt S14 JA), wird diese Netzadresse,
die verwendet werden kann, dem Header als die Quelladresse beigefügt, und
das Paket, das für
den Server S bestimmt ist, wird erneut übertragen (Schritt S15).
-
Falls
sie andererseits nicht verwendet werden kann (der Fall, wo die Netzadresse
mit einem anderen Präfix
nicht existiert, oder der Fall, wo die Netzadresse mit einem anderen
Präfix
existiert, aber für diese
Kommunikation aus irgendeinem Grund nicht verwendet werden kann)
(Schritt S14 NEIN), wird die Fehlerverarbeitung ausgeführt (Schritt
S16). Es gibt viele Variationen für die Fehlerverarbeitung, wie
etwa nichts zu tun, den Fehler der Kommunikation der oberen Schicht
mitzuteilen (der Präfix
dieser Quelladresse kann nicht verwendet werden), nach einer vorgeschriebenen
Zeitperiode zurück
zu dem Schritt S13 zu gehen etc.
-
Es
wird vermerkt, dass in dem Schritt S13 an Stelle dessen, was oben
beschrieben wird, es auch möglich
ist zu prüfen,
ob die Netzadresse basierend auf dem Präfix in Bezug auf einen ISP
im Unterschied zu dem ISP in Bezug auf den Präfix der Quelladresse, die beim Übertragen
dieses Pakets verwendet wird, wofür die Ankündigung empfangen ist, als
die Quelladresse des Pakets verwendet werden kann, das für den Server
S bestimmt ist, oder nicht.
-
Wenn
die Ankündigung
empfangen wird, dass der Transfer des Pakets nicht ausgeführt wurde, ist
es in dem Schritt S12 auch möglich,
unverzüglich zu
der Fehlerverarbeitung fortzufahren (wie etwa z.B. nichts zu tun,
den Fehler der Kommunikation der oberen Schicht bekannt zu geben
(der Präfix
dieser Quelladresse kann nicht verwendet werden), Bekanntgeben des
Fehlers der Kommunikation und des Präfixes, der zu dieser Zeit verwendet
wird etc.) (danach wird z.B. die Verarbeitung durch die obere Schicht
oder die Handhabung durch den Benutzer ausgeführt).
-
Als
Nächstes
zeigt 6 eine andere beispielhafte Verarbeitungsprozedur
in dem Fall, wo der Router R1 ein Paket von dem Kommunikationsknoten
empfängt.
-
In
der beispielhaften Prozedur von 4 gibt der
Router R1 dem Kommunikationsknoten N bekannt, dass der Transfer
des Pakets nicht ausgeführt wurde,
wenn das Paket nicht transferiert wurde, da die Quelladresse des
empfangenen Pakets nicht die vorgeschriebene Bedingung erfüllt. In
einem derartigen Fall wird jedoch in dieser beispielhaften Prozedur die
Ankündigung
(z.B. ICMP-Nachricht), die auch den Präfix enthält, der von dem ISP bereitgestellt wird,
für den
die Konnektivität
gegenwärtig
bestätigt ist,
dem Kommunikationsknoten N bekannt gegeben (Schritte S23 und S25).
-
Wenn
z.B. der ISPa aus irgendeinem Grund getrennt ist, und allein die
Konnektivität
des ISPb bestätigt
ist, wird, falls das Paket mit der Quelladresse mit dem Präfix anders
als der Präfix
in Bezug auf den ISPb (z.B. der Präfix in Bezug auf den ISPa)
von dem Kommunikationsknoten N empfangen wird, der Präfix Pb,
der von dem ISPb bereitgestellt wird, allein dem Kommunikationsknoten
N bekannt gegeben.
-
Auch
wenn z.B. die Konnektivitäten
von sowohl ISPa als auch ISPb bestätigt sind, werden, falls ein
Paket mit einer Quelladresse basierend auf dem Präfix anders
als die Präfixe
der ISPa und ISPb von dem Kommunikationsknoten N empfangen wird,
der Präfix
Pa, der von dem ISPa bereitgestellt wird, und der Präfix Pb,
der von dem ISPb bereitgestellt wird, dem Kommunikationsknoten N
bekannt gegeben.
-
7 zeigt
eine beispielhafte Konfiguration einer ICMP-(Präfix-inkorrekt)Nachricht
in diesem Fall.
-
In 7 ist
ein "IPv6-Header" 21 ein
Header, der anzeigt, dass es ein IPv6-Paket ist, ein "ICMP-Header" 22 ist
ein Header, der anzeigt, dass es eine ICMP-Nachricht ist, ein "target dst prefixlen (Zielbestimmungs-Präfix-Länge)" 23 ist
ein Feld, das einen Adressbereich anzeigt, in dem der "bevorzugte-Präfix", der in dieser ICMP-Nachricht
enthalten ist, ein gültiges
Ziel wird, eine "Zahl
vom bevorzugten-Präfix" 24 ist
ein Feld, das die Zahl vom "bevorzugten-Präfix" anzeigt, der in
dieser ICMP-Nachricht enthalten ist, "bevorzugter-Präfix" 25 bis 27 sind Felder,
die Präfixe
anzeigen, die für
eine Verwendung empfohlen werden, und ein "zuständiges
Paket" 28 ist
ein Paket, das veranlasst wird, diese ICMP-Nachricht von dem Router
R1 zuzustellen.
-
Hier
zeigt die "target
dst prefixlen" "/128" an, falls es z.B.
128 ist, und impliziert, dass der gültige Adressbereich durch die
oberen 128 Bits spezifiziert wird. Gewöhnlich ist er nur für die Bestimmung
des zuständigen
Pakets gültig,
aber falls dieser Wert z.B. 64 ist, kann das Paket durch den gül tigen ISP
durch Verwenden nur dieses "bevorzugten-Präfixes" übertragen werden, wenn der
Präfix
in den oberen 64 Bits übereinstimmt.
Wenn dieser Wert durch irgendein Verfahren erhalten werden kann,
gibt der Router R1 den erhaltenen geeigneten Wert ein. Anderenfalls gibt
der Router R1 "–1" ein ("128" wird eingegeben, wenn
es einen offensichtlichen Host-Router
gibt).
-
Als
Nächstes
zeigt 8 eine andere beispielhafte Verarbeitungsprozedur
des Kommunikationsknotens N (ein Beispiel entsprechend der beispielhaften
Prozedur von 6).
-
Zuerst überträgt der Kommunikationsknoten N
ein Paket, das für
den Server S bestimmt ist (Schritt S31).
-
Angenommen,
dass der Präfix
der Adresse, die als die Quelladresse in diesem Punkt ausgewählt ist,
eine Adresse in Bezug auf den ISP ist, dessen Zustand der geworden
ist, in dem die Konnektivität durch
den Router R1 gegenwärtig
nicht bestätigt
ist. In diesem Fall überträgt der Router
R1 eine Ankündigungsnachricht,
die anzeigt, dass der Transfer des Pakets nicht ausgeführt wurde,
und eine Bekanntgabe des Präfixes
inkludiert, der von dem ISP bereitgestellt wird, für den die
Konnektivität
gegenwärtig
bestätigt
ist.
-
Dann
empfängt
der Kommunikationsknoten N die Ankündigung, die anzeigt, dass
der Transfer des Pakets nicht ausgeführt wurde, und eine Bekanntgabe
des Präfixes
inkludiert, der von dem ISP bereitgestellt wird, für den die
Konnektivität
gegenwärtig
bestätigt
ist, von dem Router R1 (Schritt S32).
-
In
diesem Fall generiert der Kommunikationsknoten N die Netzadresse
gemäß dem Präfix, der durch
diese Ankündigung
empfangen wird, und der Schnittstellen-ID des Kommunikationsknotens
N selbst, ändert
gemäß Erfordernis
(Schritt S33) die Quell adresse des Pakets, für das die Ankündigung empfangen
wurde, zu dieser generierten Adresse (fügt die generierte Adresse dem
Header als die Quelladresse bei) und überträgt das Paket erneut (Schritt
S34).
-
Es
wird vermerkt, dass wenn die entsprechende Adresse bereits generiert
und der Schnittstelle zugewiesen ist, der Schritt S33 übersprungen
werden kann.
-
Wenn
eine Vielzahl von Präfixen
bekannt gegeben wird, ist es auch möglich, eine Vielzahl von Netzadressen
zu generieren, und in diesem Fall kann die Netzadresse, die als
die Quelladresse zu verwenden ist, geeignet durch das oben beschriebene
Auswahlverfahren ausgewählt
werden.
-
Auch
kann es Fälle
geben, wo die Netzadresse basierend auf dem bekannt gegebenen Präfix als
die Quelladresse nicht verwendet werden kann, abhängig von
einer Entität,
die die Kommunikation ausführt,
wie etwa Anwendungssoftware.
-
Nun
gibt es viele Variationen bezüglich
dessen, welche Pakettransfersteuerung ausgeführt werden sollte oder wie
der "bevorzugte-Präfix" bekannt gegeben
werden sollte.
-
Selbst
wenn z.B. der Router R1 im voraus weiß, dass die Bandbreite des
Kanals auf der ISPa-Seite breit ist und die Einstellung, die ISPa-Seite
als eine Vorgabe zu verwenden, durchgeführt ist, ist es, falls der
Präfix
Pb der ISPb-Seite in der Quelladresse des Pakets verwendet wird,
das von der Seite des Kommunikationsknotens N empfangen wird, möglich, dieser
Anzeige eine höhere
Priorität
zu geben und die Steuerung derart auszuführen, dass dieses Paket zu
der ISPb-Seite transferiert wird.
-
Auch
wenn z.B. die Bandbreite des Kanals auf der ISPa-Seite beträchtlich
breiter ist und falls das Paket, das von dem Kommunikationsknoten
N empfangen wird, die Quelladresse hat, die den Präfix auf
der ISPb-Seite verwendet, ist es möglich, eine Nachricht, wie
etwa ICMP (Präfix-inkorrekt)
dem Kommunikationsknoten N bekannt zu geben (selbst wenn die Konnektivität des ISPb
bestätigt
wurde) und zur gleichen Zeit bekannt zu geben, dass der Präfix des
ISPa verwendet werden sollte. Selbst wenn der Kommunikationsknoten
N den ISPb in dem anfangs übertragenen
Paket verwendet hat, wird es auf diese Weise möglich, Kommunikationen durch
den ISPa mit der breiteren Bandbreite auf Empfang der Ankündigung
des Präfixes
auf der ISPa-Seite von dem Router R1 hin auszuführen.
-
Auch
kann z.B. der Router R1 die Steuerung derart ausführen, dass
eine Antwort, zu dem Router R2 umzulenken zurückgegeben wird, an Stelle einer Bekanntgabe
der Präfixe
in Bezug auf den ISPa und den ISPb, mit denen der Kommunikationsknoten selbst
zu verbinden ist.
-
Im
folgenden wird nun der beispielhafte Betrieb des Routers R1 mit
Bezug auf die beispielhaften Sequenzen von 9A, 9B, 9C und 10 beschrieben.
-
Zuerst
wird der Fall betrachtet, wo Konnektivität des ISPa bereits bestätigt ist,
wenn der Router R1 ein Paket von dem Kommunikationsknoten N empfängt.
-
In
diesem Fall wird angenommen, dass der Kommunikationsknoten N ein
Paket mit der Quelladresse = "Pa::N" und der Zieladresse
= "S" (src = Pa::N, dst
= S) zu dem Router R1 übertragen
hat, wie in 9A gezeigt (Schritt S101). Falls
hier der ISPa im voraus als ein ISP bestimmt ist, dem eine höhere Priorität in dem
Router R1 zu geben ist, transferiert der Router R1 in diesem Fall
das Paket, das von dem Kommunikationsknoten N empfangen wird, zu
dem ISPa (Schritt S102).
-
Als
Nächstes
wird der Fall betrachtet, wo die Konnektivität des ISPa verloren gegangen
ist, wenn der Router R1 ein Paket von dem Kommunikationsknoten N
empfängt.
-
In
diesem Fall wird angenommen, dass der Kommunikationsknoten N ein
Paket mit der Quelladresse = "Pa::N" und der Zieladresse
= "S" (src = Pa::N, dst
= S) zu dem Router R1 übertragen
hat, wie in 9B gezeigt (Schritt S121).
-
Hier
wird angenommen, das der Router R1 eine ICMP-Nachricht überträgt (siehe 7),
da der Eingangsfilter höchstwahrscheinlich
so eingeführt
ist, dass er im voraus weiß,
dass der Transfer dieses Pakets in dem ISPb zurückgewiesen wird, selbst wenn das
empfangene Paket zu dem anderen ISPb transferiert wird, für den die
Konnektivität
aufrecht erhalten ist (Schritt S122). Diese ICMP-Nachricht enthält "Präfix-inkorrekt" und "bevorzugter Präfix: Pb".
-
Auf
Empfang dieser Ankündigung
hin transferiert, wenn der Kommunikationsknoten N ein Paket mit
der Quelladresse = "Pb::N" und der Zieladresse
= "S" (src = Pb::N, dst
= S) überträgt (Schritt
S123), der Router R1 in diesem Fall das Paket, das von dem Kommunikationsknoten
N empfangen wird, zu dem ISPb (Schritt S124).
-
Als
Nächstes
wird der Fall betrachtet, wo der Kommunikationsknoten N ein Paket
mit der Quelladresse "Pa::N" und der Zieladresse "S" (src = Pa::N, dst = S) zu dem Router
R2 übertragen
hat, wie in 9C gezeigt (Schritt S131).
-
In
diesem Fall führt
der Router R2 im wesentlichen die gleiche Operation wie der oben
beschriebene Router R1 aus.
-
Der
Router R2, der das oben beschriebene Paket von dem Kommunikationsknoten
N empfangen hat, prüft
nämlich,
ob der Präfix
Pa, der der Quelladresse des empfangen Pakets gegeben ist, ein Präfix ist,
der von dem ISP bekannt gegeben ist, mit dem Router R2 verbunden
ist.
-
Dieser
Präfix
Pa ist nicht ein Präfix,
der von dem ISP bekannt gegeben ist, mit dem der Router R2 verbunden
ist, sodass der Router R2 die ICMP-Nachricht zu dem Kommunikationsknoten
N überträgt (Schritt
S132). Diese ICMP-Nachricht enthält
den "Präfix-inkorrekt" und den "bevorzugter Präfix: Pc, Pd", der durch den Router
R2 empfohlen wird (vorausgesetzt, dass die Konnektivitäten des
ISPc und des ISPd beide bestätigt
sind). Hier wird angenommen, dass die Konnektivitäten des
ISPc und des ISPd im voraus geprüft
sind.
-
Auf
Empfang dieser Ankündigung
hin überträgt der Kommunikationsknoten
N ein Paket mit der Quelladresse = "Pc::N" und der Zieladresse = "S" (src = Pc::N, dst = S) z.B. zu dem
Router R2 (Schritt S133), und der Router R2 transferiert das Paket,
das von dem Kommunikationsknoten N empfangen wird, zu dem ISPc (Schritt
S134).
-
Als
Nächstes
wird angenommen, dass die Konnektivitäten von sowohl dem ISPa als
auch dem ISPb verloren gegangen sind. In diesem Fall hat der Router
R1 keine Konnektivität
mit dem Internet.
-
Hier
wird, wie in 10 gezeigt, angenommen, dass
der Kommunikationsknoten N ein Paket mit der Quelladresse = "Pa::N" und der Zieladresse
= "S" (src = Pa::N, dst
= S) z.B. zu dem Router R1 übertragen
hat (Schritt S141).
-
In
diesem Fall hat der Router R1 die Konnektivitäten von dem ISPa und dem ISPb
verloren, sodass der Router R1 eine Umlenkungsnachricht als die
ICMP-Nachricht zu dem Kommunikationsknoten N übertragen kann, um den Kommunikationsknoten N
anzuweisen, den Router R2 als ein Paketübertragungsziel auszuwählen (Schritt
S142).
-
Hier
wird angenommen, dass der Router R1 weiß (oder wissen kann), dass
der Router R2 als ein anderer Router existiert, der ein Umlenkungsziel
sein kann (z.B. durch den Informationsaustausch zwischen Routern).
-
Gemäß dieser
ICMP-Nachricht überträgt der Kommunikationsknoten
N zuerst ein Paket mit der Quelladresse = "Pa::N" und der Zieladresse = "S" (src = Pa::N, dst = S) zu dem Router
R2 (Schritt S143).
-
Da
es hier der Präfix
des ISP ist, mit dem der Router R2 selbst nicht verbunden ist, überträgt der Router
R2 die ICMP-Nachricht,
die den "Präfix-inkorrekt" und den "bevorzugter Präfix: Pc,
Pd" enthält, empfohlen
durch den Router R2 (vorausgesetzt, dass die Konnektivitäten von
sowohl dem ISPc als auch dem ISPd bestätigt sind) (Schritt S144).
-
Auf
Empfang dieser Ankündigung
hin wählt der
Kommunikationsknoten N Pc und überträgt ein Paket
mit der Quelladresse = "Pc::N" und der Zieladresse
= "S" (src = Pc::N, dst
= S) z.B. zu dem Router R2 (Schritt S145), und der Router R2 transferiert das
Paket, das von dem Kommunikationsknoten N empfangen wird, zu dem
ISPc (Schritt S146).
-
Es
wird vermerkt, dass wenn die Konnektivitäten von sowohl dem ISPa als
auch dem ISPb verloren sind und es eine Vielzahl von Routern gibt,
die das Umlenkungsziel sein können,
der Router R1 einen Router, der aus ihnen geeignet ausgewählt wird, zu
dem Kommunikationsknoten N zurückgeben kann.
-
Wenn
die Konnektivitäten
von sowohl dem ISPa als auch dem ISPb verloren sind und es keinen Router
gibt, der das Umlenkungsziel sein kann, mit dem zu beginnen ist,
oder es bekannt ist, dass die Router, die das Umlenkungsziel sein
können,
alle unten sind, ist es auch wünschenswert,
einen Fehler zu dem Kommunikationsknoten N zurückzugeben.
-
Als
Nächstes
wird der beispielhafte Betrieb des Kommunikationsknotens N mit Bezug
auf 9A bis 9C und 10 beschrieben.
-
Zuerst
wird der Fall beschrieben, wo der Kommunikationsknoten N die ICMP-Nachricht
wie oben beschrieben empfängt.
-
Der
Kommunikationsknoten N überträgt ein Paket
mit der Quelladresse = "Pa::N" und der Zieladresse
= "S" (src = Pa::N, dst
= S) zu dem Router R1 (Schritt S121 von 9B).
-
Hier
wird angenommen, dass der Präfix,
der für
die Quelladresse verwendet wird, im voraus von dem Router R1 bekannt
gegeben wird, der z.B. ein Vorgabe-Router ist.
-
Als
Nächstes
wird angenommen, dass die Konnektivität des ISPa, der durch das empfangene Paket
spezifiziert ist, wie oben beschrieben verloren ist. In diesem Fall
kommt die ICMP-Nachricht,
wie in 7 gezeigt, von dem Router R1. Diese ICMP-Nachricht
enthält
den "Präfix-inkorrekt" und den "bevorzugter Präfix: Pb" (Schritt S122 von 9B).
-
Auf
Empfang dieser ICMP-Nachricht hin beurteilt der Kommunikationsknoten
N die Übertragung, über deren
Paket diese Nach richt ist, gemäß dem zuständigen Paket 28,
das in 7 gezeigt wird.
-
Als
Nächstes
wird angenommen, dass diese Nachricht durch Umschreiben der Quelladresse
des Pakets, welches früher
wegen dem "bevorzugten Präfix" (der hier Pb ist),
der in dieser Nachricht enthalten ist, zuständig wurde, erneut übertragen
wird.
-
Falls
zu diesem Punkt die Netzadresse "Pb::N" gemäß einer
Kombination des Präfixes
(Pb), der als der "bevorzugte
Präfix" empfangen wird,
und der Schnittstellen-ID, die im Besitz durch den Kommunikationsknoten
N ist, nicht im voraus bereitgestellt wird, wird diese Adresse generiert
und verwendet.
-
Es
ist auch möglich,
derart zu steuern, dass das Paket erneut übertragen wird, nachdem das
zuständige
Paket geprüft
ist um zu sehen, ob es gegenwärtig
eine Verbindung dem gemäß gibt oder
nicht.
-
Wenn
es eine Verbindung gibt, die auf das zuständige Paket bezogen ist, wird
geprüft,
ob sie zuvor hergestellt ist oder nicht, d.h. ob sie in einem Prozess
einer Rufveranlassung ist oder nicht. Z.B. wird geprüft, ob sie
in einem Zustand von SYN_SENT in dem TCP ist oder nicht.
-
In
dem Fall, wo sie einen Ruf veranlasst, wird die Verbindung durch
die Quelladresse, zu der der Präfix,
der durch die frühere
ICMP-Nachricht empfangen wird, zugewiesen ist, als die Quelladresse dieser
Verbindung erneut eingerichtet. Wenn jedoch die Anwendung die Quelladresse
explizit spezifiziert, ist es auch möglich, die Steuerung auszuführen, die die
erneute Einstellung nicht ausführt.
Der beispielhafte Fall davon ist, wenn bind () aufgerufen wird,
bevor connect () aufgerufen wird und die Quelladresse dort explizit
spezifiziert ist, in dem Fall, wo ein Socket im allgemeinen verwendet
wird.
-
Außerdem ist
es auch möglich,
die ICMP-Nachricht, die von dem Router R1 oder R2 empfangen wird,
als eine Präfixmanagementtabelle zu
speichern, wie in 11 gezeigt. Wenn die ICMP-Nachricht empfangen
wird, wird hier ihr Ergebnis als eine Menge der Zieladresse oder
ihr Adressbereich und der "bevorzugte-Präfix" gespeichert.
-
Als
ein Beispiel wird der Fall beschrieben, wo das Paket zu "S::a" übertragen wird und die ICMP-Nachricht,
die "Präfix-inkorrekt" anzeigt, von dem
Router R1 als Antwort empfangen wird.
-
In
dieser ICMP-Nachricht ist der "bevorzugte-Präfix" als "Pa" beschrieben. Durch
Speichern dieses Ergebnisses als eine Menge der Adresse oder den
Adressbereich und den Präfix
wird das Paket durch Ändern
der Quelladresse zu dem empfohlenen Präfix "Pa::a" durch Bezug auf diese Tabelle zu einer Zeit
einer Übertragung
des Pakets, das zu "S::a" bestimmt ist, das
nächste
Mal transferiert.
-
Es
ist auch möglich,
derart zu steuern, dass "Pa" bei einer höheren Priorität verwendet
wird, durch Verweis auf diese Tabelle, wenn die Adresse den Präfix von "S::/64" hat. Auf diese Weise
wird es möglich,
den Präfix,
der im voraus empfohlen wird, bei einer höheren Priorität zu verwenden,
sodass es möglich
wird, die Zahl von Malen für
einen Empfang der ICMP-Nachricht
von dem Router zu reduzieren. Außerdem kann das Speichern diese
Tabelle ausgesetzt werden, falls der Vorgabe-Router geändert wird oder die Regeln
des Paketübertragungsziels
in dem Kommunikationsknoten N geändert
werden.
-
Als
Nächstes
wird der Fall beschrieben, wo der Kommunikationsknoten N ein Paket
mit der Quelladresse = "Pa::N" und der Zieladresse
= "S" (src = Pa::N, dst
= S) zu dem Router R2 überträgt (Schritt
S131 von 10). Dieses Paket wird z.B.
angenommen, ein Paket für
die TCP-Verbindungseinrichtung zu sein.
-
Der
Router R2, der dieses Paket empfangen hat, ermittelt, dass dieser
Präfix "Pa" nicht von dem ISP
auf der stromaufwärtigen
Seite des Routers R2 zugeordnet ist, durch Erfassen des Präfixes "Pa", der in der Quelladresse
dieses Paket enthalten ist.
-
Auf
diese Weise überträgt der Router
R2 die ICMP-Nachricht (Präfix-inkorrekt)
zu dem Kommunikationsknoten N, der dieses Paket übertragen hat (Schritt S132
von 10). Diese ICMP-Nachricht enthält den "bevorzugten-Präfix: Pc und Pd", die die Präfixe sind,
die durch den Router R2 empfohlen werden.
-
Auf
Empfang dieser ICMP-Nachricht hin vergleicht der Kommunikationsknoten
N zuerst den empfangenen "bevorzugten-Präfix" mit der Adresse, die
in dem Kommunikationsknoten N selbst eingestellt ist (in der Schnittstelle
N, die eine Schnittstelle des Kommunikationsknotens N ist). Der
Kommunikationsknoten N hat auch Adressen mit Pc und Pd als Präfixe, sodass
er eine von ihnen als die Quelladresse auswählt. Hier wird angenommen,
dass Pc ausgewählt
wird, sodass die Quelladresse eingestellt wird, "Pc::N" zu sein.
-
Als
Nächstes
wird das zuständige
Paket in der ICMP-Nachricht geprüft.
Zu diesem Punkt kann ermittelt werden, welche Art einer Anforderung
zu welchem Verbindungsziel es ist, durch Prüfen einer Menge der Quelladresse
(src adr), der Zieladresse (dst addr), des Quellports (src port)
und des Zielports (dst port) des zuständigen Pakets. Als Nächstes wird wie
oben erwähnt
geprüft,
ob diese Anforderung gerade hergestellt wird oder nicht, d.h. ob
es in dem Prozess einer Rufveranlassung ist oder nicht. Danach,
es ist vor einer Herstellung, wird das Paket durch Ändern der
Quelladresse zu "Pc::N" erneut übertragen.
-
Im
folgenden wird ein Verfahren zum Managen des Präfixes, der durch die ICMP-Nachricht
oder dergleichen von dem Router bekannt gegeben wird, in dem Kommunikationsknoten
N beschrieben.
-
Es
gibt viele Variationen bezüglich
dessen, wie lange der Präfix,
der durch die ICMP-Nachricht oder dergleichen von dem Router bekannt
gegeben wird, verwendet werden sollte, oder wann er verworfen werden
sollte.
-
Es
wird vermerkt, dass falls die Präfixmanagementtabelle
ein Zwischenspeicher (Cache) ist, für die Kommunikationen im Grunde
kein Problem verursacht wird, wenn er verworfen wird. Einige dieser
Variationen sind wie folgt.
-
(1)
Der bekannt gegebene Präfix
wird nur für die
erneute Übertragung
des Pakets zu dieser Zeit verwendet und dann verworfen.
-
In
dem Fall, wo der Kommunikationsknoten mit einer kleinen Speicherkapazität die Kommunikation
ausführt,
ist es wünschenswert,
diese Richtlinie anzunehmen. Die gleiche Prozedur wird in dem Fall einer
Einrichtung einer neuen Verbindung erneut mit Bezug auf die gleiche
Entsprechung wiederholt.
-
(2)
Der bekannt gegebene Präfix
wird aufrechterhalten, bis ein vorgeschriebenes Ereignis auftritt
und ein ganzes oder ein Teil von ihm wird verworfen, wenn das vorgeschriebene
Er eignis auftritt, und diese Verarbeitung wird regelmäßig ausgeführt.
-
Z.B.
wird eine Größe der Tabelle
bestimmt, und falls die Daten überlaufen,
werden Daten (ein Eintrag, auf den z.B. das letzte Mal verwiesen
wird) zu diesem Punkt sequenziell verworfen.
-
(3)
Das Verwerfen wird im Grunde nicht als eine reguläre Verarbeitung
durchgeführt,
sondern ein ganzes oder ein Teil des bekannt gegebenen Präfixes wird
verworfen, wenn es zu einer Situation kommt, wo das Verwerfen ausgeführt werden
sollte.
-
Die
Situation, wo das Verwerfen ausgeführt werden sollte, inkludiert:
- (3-1) den Fall, wo die Umlenkung empfangen wird;
und
- (3-2) den Fall, wo der Router, der bis dann verwendet wurde,
zusammenbricht (kurz zuvor).
-
Es
wird der oben beschriebene Fall (3-1) beschrieben, wo die Umlenkung
empfangen wird.
-
Angenommen
z.B., dass der "Präfix-inkorrekt" von dem Router R2
im vergangenen empfangen wurde und der Präfix: Pa unter dem Umstand bekannt
gegeben wurde, wo der Kommunikationsknoten N zu dem Internet über den
Router R1 und den Router R2 zugreifbar ist. Dann speichert der Kommunikationsknoten
N die Tatsache, dass die Ankündigung
empfangen wurde, die anzeigt, dass "es empfohlen wird, den Präfix Pd für S" zu verwenden. Angenommen
nun, dass es möglich
war, die Kommunikation durch Verwenden von Pd für eine Weile auszuführen, aber
zu irgend einem Punkt eine Ankündigung
(ICMP-Umlenkung) empfangen wird, die anzeigt, dass "es empfohlen wird,
den Router R1 für
S zu verwenden".
In einem derartigen Fall ist Pd der Präfix abhän gig von dem Router R2, sodass
mindestens dieser Präfix
verworfen wird. Wenn die Umlenkung plötzlich für den Router empfangen wird,
der bis dann verwendet wurde, gibt es eine hohe Wahrscheinlichkeit,
dass sich die Situation, die die Router R1 und R2 umgibt, stark
geändert
hat (alle Verknüpfungen über den
Router R2 hinaus sind z.B. herunter gegangen), sodass es auch möglich ist,
alle Präfixe zu
verwerfen.
-
Es
wird der oben beschriebene Fall (3-2) beschrieben, wo der Router,
der bis dann verwendet wurde, zusammenbricht (kurz zuvor).
-
Wenn
die Information, die anzeigt, dass "das Paket zu dem Router R2 für S transferiert
werden sollte",
aufrechterhalten wird, ändert
sich, falls ermittelt wird, dass der Router R2 zusammengebrochen ist
(der IPv6-Knoten führt
regelmäßig die Überlebensprüfung (z.B.
NUD, RFC 2481) in Bezug auf den Router aus, der durch diesen Knoten
verwendet wird, sodass es z.B. dadurch ermittelt werden kann), die Situation
beträchtlich,
sodass die aufrechterhaltenen Präfixe
ohne Bedeutung sind und es möglich
ist, sie alle zu verwerfen.
-
Diese
Verarbeitung von (3) sollte vorzugsweise ausgeführt werden, wenn es nicht der
Fall von (1) ist (sodass die bedeutungslose Erhöhung der Prozedur vermieden
werden kann).
-
(4)
Es wird die Lebensdauer verwendet.
-
Der
Kommunikationsknoten N kann die Lebensdauer (z.B. in Sekunden) des
Präfixes
zur Zeit einer Registrierung des Präfixes in die Tabelle oder dergleichen
(z.B. durch den Kommunikationsknoten N selbst) bestimmen, und die
Lebensdauer in Entsprechung zu dem Präfix registrieren. In diesem
Fall wird der Präfix
verworfen, wenn die Lebensdauer abläuft.
-
Wie
beschrieben, wird es gemäß der vorliegenden
Erfindung möglich,
die Multi-Wohnstätten-Umgebung
effektiv zu nutzen, durch Ermöglichen der
Auswahl der Quelladresse gemäß dem Eingangsrouter
in Bezug auf das Internet durch Berücksichtigung des Zustands einer
Verbindung mit dem Internetdienstanbieter.
-
Es
ist zu vermerken, dass die oben beschriebenen Ausführungsformen
gemäß der vorliegenden Erfindung
unter Verwendung eines konventionellen Mehrzweck-Digital-Computers
zweckdienlich implementiert werden können, der gemäß den Unterweisungen
der vorliegenden Beschreibung programmiert ist, wie einem Durchschnittsfachmann
in der Computertechnik offensichtlich sein wird. Geeignete Softwarekodierung
kann durch geübte
Programmierer basierend auf den Unterweisungen der vorliegenden
Offenlegung leicht vorbereitet werden, wie einem Durchschnittsfachmann
in der Softwaretechnik offensichtlich sein wird.
-
Insbesondere
kann jeder von dem Router und dem Kommunikationsknoten der oben
beschriebenen Ausführungsformen
zweckdienlich in einer Form eines Softwarepakets implementiert werden.
-
Ein
derartiges Softwarepaket kann ein Computerprogrammprodukt sein,
welches ein Speichermedium einsetzt, inkludierend gespeicherten
Computercode, der verwendet wird, um einen Computer zu programmieren,
um die offengelegte Funktion und den Prozess der vorliegenden Erfindung
durchzuführen.
Das Speichermedium kann inkludieren, ist aber nicht darauf begrenzt,
einen beliebigen Typ von konventionellen Floppy-Disks, optische
Platten, CD-ROMs, magneto-optische Platten, ROMs, RAMs, EPROMs,
EEPROMs, magnetische oder optische Karten oder beliebige andere
geeignete Medien zum Speichern elektronischer Instruktionen.
-
Es
ist auch zu vermerken, dass neben jenen bereits oben erwähnten viele
Modifikationen und Variationen der obigen Aus führungsformen durchgeführt werden
können,
ohne von den neuartigen und vorteilhaften Merkmalen der vorliegenden
Erfindung abzuweichen. Entsprechend sind alle derartigen Modifikationen
und Variationen gedacht, innerhalb des Bereichs der angefügten Ansprüche inkludiert
zu sein.