JP2003298635A - ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 - Google Patents

ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法

Info

Publication number
JP2003298635A
JP2003298635A JP2002097652A JP2002097652A JP2003298635A JP 2003298635 A JP2003298635 A JP 2003298635A JP 2002097652 A JP2002097652 A JP 2002097652A JP 2002097652 A JP2002097652 A JP 2002097652A JP 2003298635 A JP2003298635 A JP 2003298635A
Authority
JP
Japan
Prior art keywords
packet
source address
communication node
internet service
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2002097652A
Other languages
English (en)
Other versions
JP3665622B2 (ja
Inventor
Masahiro Ishiyama
政浩 石山
Tatsuya Shinmyo
達哉 神明
Yuzo Tamada
雄三 玉田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2002097652A priority Critical patent/JP3665622B2/ja
Priority to EP20030252002 priority patent/EP1349323B1/en
Priority to CNB031083919A priority patent/CN1242593C/zh
Priority to KR20030019560A priority patent/KR100693320B1/ko
Priority to DE2003600299 priority patent/DE60300299T2/de
Priority to US10/401,874 priority patent/US7680949B2/en
Publication of JP2003298635A publication Critical patent/JP2003298635A/ja
Application granted granted Critical
Publication of JP3665622B2 publication Critical patent/JP3665622B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

(57)【要約】 【課題】 マルチホーム環境を有効に利用することを可
能とするソースアドレス選択システムを提供すること。 【解決手段】 通信ノードＮは、ルータＲ１へパケット
を送信し、ルータＲ１は、受信パケットのソースアドレ
スのプレフィクスに対応するＩＳＰａの接続性が確認で
きていない場合には、該パケットの転送を行わず、ノー
ドＮ宛に該パケットを転送しなかった旨と接続性が確認
できているＩＳＰｂに対応するプレフィクスとを通知
し、ノードＮは、パケットのソースアドレスを、受信し
たプレフィクスに基づいて生成されたネットワークアド
レスに変更して再度送信する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、家庭やＳＯＨＯな
どがＩＰｖ６を用いて複数のＩＳＰを介してインターネ
ットで常時接続された場合において、適切に出口ルータ
を選択するためのソースアドレス選択システム、ルータ
装置、通信ノード及びソースアドレス選択方法に関す
る。
【０００２】
【従来の技術】近年、世界最大のコンピュータネットワ
ーク「インターネット（Ｉｎｔｅｒｎｅｔ）」の利用が
普及しており、このインターネットと接続し、公開され
た情報、サービスを利用したり、逆にインターネットを
通してアクセスしてくる外部ユーザに対し、情報、サー
ビスを提供することで、新たなコンピュータビジネスが
開拓されている。また、インターネット利用に関して、
新たな技術開発、展開がなされている。インターネット
では、各計算機がＩＰアドレスと呼ばれる識別子を持
ち、このＩＰアドレスをもとに、パケットの交換が行わ
れる。通常、インターネットに接続する場合には、ＩＳ
Ｐ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄ
ｅｒ）と契約してアドレスの割り当てを受けることにな
る。
【０００３】現在のＩＰｖ６のアドレスの割り当ては、
プロバイダ・ベース（ｒｏｖｉｄｅｒ Ｂａｓｅ）であ
る。すなわち、あるプロバイダと契約した場合に、その
プロバイダがすでに割り当てられているアドレスの部分
集合を、割り当ててもらうことになる。
【０００４】今後、家庭やＳＯＨＯなど小規模なネット
ワークであっても、インターネットの安定した利用等を
目的として、複数のプロバイダと契約をすることが考え
られる。この場合、このネットワークとインターネット
との接続点は複数となり、このような状況をマルチホー
ムと呼ぶ。
【０００５】図１２に示すように、ノードＮがプロバイ
ダＡとＢを介してインターネットと接続しているとす
る。ＩＰｖ６では、ノードが複数のアドレスを持てるた
め、この場合、ノードＮは、プロバイダＡにより割り当
てられたアドレスと、プロバイダＢにより割り当てられ
たアドレスとを使うことが可能である。
【０００６】
【発明が解決しようとする課題】ここで、図１２におい
て、プロバイダＡで障害が発生し、インターネットから
Ａを経由してノードＮにパケットを届けることができな
くなったとする。
【０００７】もし、ノードＮが、プロバイダＡに属する
アドレスをソースアドレス（送信元アドレス）（ｓｏｕ
ｒｃｅ ａｄｄｒｅｓｓ）に使ってサーバＳと通信しよ
うとした場合には、サーバＳと通信することはできない
ことになる。ノードＮから、プロバイダＡに属するアド
レスをソースアドレスとして、パケットを送信すると、
プロバイダＡ側は障害が発生しているため、サーバＳへ
の経路が絶たれてしまっているからである。
【０００８】そこで、例えば、現在のＩＰｖ４プロトコ
ルが行なっているように、プロバイダＡに属するアドレ
ス宛のパケットをプロバイダＢを経由して届くように経
路を変更することができれば解決可能であるが、このよ
うな変更は経路表の大幅な増加につながり、アドレス空
間が広大なＩＰｖ６プロトコルでの実現は、従来の技術
では極めて困難である。
【０００９】なお、かりに、上記のプロバイダＡに属す
るアドレスをソースアドレスとしたパケットがプロバイ
ダＢの経路を経由してサーバＳへ到達したと仮定する。
この場合、サーバＳは、前述したプロバイダＡに属する
アドレスをソースアドレスとして持つパケットを受信す
ると、このソースアドレスに基づいて送信元ノードと通
信しようと試みるため、プロバイダＡの経路を経由した
通信を確立しようとする。しかしながら、サーバＳから
の返信パケットは、プロバイダＡに障害があるためノー
ドＮに到達することができず、通信ができない。加え
て、ＩＰｖ６では、ｉｎｇｒｅｓｓ ｆｉｌｔｅｒ（イ
ングレス・フィルタ）（ＩＥＴＦ ＲＦＣ２２６７、Ｒ
ＦＣ２８２７）が導入される場合が非常に多いが、それ
が導入されるている場合には、そもそもプロバイダＡに
属するするアドレスを宛先に持つパケットがプロバイダ
Ｂを通ることが許されず、サーバＳにパケットが届かな
い。
【００１０】ＳＯＨＯなどにおいて、このような問題の
ためにマルチホームが効率的に利用出来ない場合、イン
ターネットの信頼性を向上させることは困難である。
【００１１】以上のように、従来の技術では、ＩＰｖ６
環境でマルチホームを有効に利用することは困難であっ
た。
【００１２】本発明は、上記事情を考慮してなされたも
ので、マルチホーム環境を有効に利用することを可能と
するソースアドレス選択システム、ルータ装置、通信ノ
ード及びソースアドレス選択方法を提供することを目的
とする。
【００１３】
【課題を解決するための手段】本発明は、複数のインタ
ーネットサービスプロバイダに接続されたルータ装置
と、このルータに接続された通信ノードとを含むソース
アドレス選択システムにおいて、前記ルータ装置は、前
記インターネットサービスプロバイダとの接続性を確認
する第１の確認手段と、前記確認手段により接続性が確
認できた前記インターネットサービスプロバイダが提供
するネットワークプレフィクスを受信する第１の受信手
段と、前記受信したネットワークプレフィクスを通知す
る通知手段とを具備し、前記通信ノードは、前記ルータ
から前記ネットワークプレフィクスを受信する第２の受
信手段と、前記ネットワークプレフィクスと自通信ノー
ド固有の識別子に基づいてネットワークアドレスを生成
する生成手段と、パケットを送信する際に前記ネットワ
ークアドレスをソースアドレスとしてヘッダに付与して
送信する送信手段とを具備し、前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置
が接続性を確認できているインターネットサービスプロ
バイダから受信したネットワークプレフィクスを持つソ
ースアドレスか否かを確認する第２の確認手段と、前記
ソースアドレスが、自ルータ装置が接続性を確認できて
いるインターネットサービスプロバイダから受信したネ
ットワークプレフィクスを持っているソースアドレスで
あった場合は、該ネットワークプレフィクスを受信した
インターネットサービスプロバイダ宛に該パケットを転
送し、前記ソースアドレスが、自ルータ装置が接続性を
確認できているインターネットサービスプロバイダから
受信したネットワークプレフィクスを持っているソース
アドレスではなかった場合は、該パケットの転送を行わ
ず、前記通信ノード宛に該パケットの転送を行わなかっ
たことを通知する制御手段とを具備したことを特徴とす
る。
【００１４】好ましくは、前記ルータ装置の前記制御手
段は、前記ソースアドレスが、自ルータ装置が接続性を
確認できているインターネットサービスプロバイダから
受信したネットワークプレフィクスを持っているソース
アドレスではなかった場合は、該パケットの転送を行わ
ず、前記通信ノード宛に該パケットの転送を行わなかっ
たことを通知するとともに、前記確認手段により接続性
が確認できた前記インターネットサービスプロバイダが
提供するネットワークプレフィクスを前記通信ノード宛
に通知する機能を更に具備するようにしてもよい。
【００１５】好ましくは、前記通信ノードは、送信した
パケットに対し前記ルータから転送を行わなかった通知
を受けるとともに接続性が確認できた前記インターネッ
トサービスプロバイダのネットワークプレフィクスの通
知を受けた場合には、前記パケットのソースアドレス
を、新たに前記通知を受けたネットワークプレフィクス
と自通信ノード固有の識別子に基づいて生成されたネッ
トワークアドレスに変更し、前記パケットを再度送信す
るようにしてもよい。
【００１６】好ましくは、前記通信ノードは、送信した
パケットに対し前記ルータから転送を行わなかった通知
を受けるとともに接続性が確認できた前記インターネッ
トサービスプロバイダのネットワークプレフィクスの通
知を受けた場合に、該ネットワークプレフィクスに基づ
く前記ネットワークアドレスを、当該パケットの再送信
についてのみ使用するようにしてもよい。
【００１７】好ましくは、前記通信ノードは、送信した
パケットに対し前記ルータから転送を行わなかった通知
を受けるとともに接続性が確認できた前記インターネッ
トサービスプロバイダのネットワークプレフィクスの通
知を受けた場合に、該ネットワークプレフィクスに基づ
く前記ネットワークアドレスを、それが無効になるまで
使用するようにしてもよい。
【００１８】好ましくは、前記ルータ装置の前記制御手
段は、前記ソースアドレスが、自ルータ装置が接続性を
確認できているインターネットサービスプロバイダから
受信したネットワークプレフィクスを持っているソース
アドレスではなかった場合に、前記確認手段により接続
性が確認できている前記インターネットサービスプロバ
イダがその時点で存在しないならば、該パケットの転送
を行わず、前記通信ノード宛に該パケットの転送を行わ
なかったことを通知するとともに、前記パケットの送信
先とすべき他のルータ装置を前記通信ノード宛に通知す
る機能を更に具備するようにしてもよい。
【００１９】好ましくは、前記ルータ装置の前記制御手
段は、前記ソースアドレスが、自ルータ装置が接続性を
確認できているインターネットサービスプロバイダから
受信したネットワークプレフィクスを持っているソース
アドレスであっても、所定の条件を満たす場合には、前
記通信ノード宛に該パケットの転送を行わなかったこと
を通知するとともに、使用すべき前記インターネットサ
ービスプロバイダが提供するネットワークプレフィクス
を前記通信ノード宛に通知する機能を更に具備するよう
にしてもよい。
【００２０】本発明は、複数のインターネットサービス
プロバイダに接続されるとともに、ローカルネットワー
クに接続され、このローカルネットネットワークに接続
された通信ノードのパケットを転送するルータ装置にお
いて、前記インターネットサービスプロバイダとの接続
性を確認する第１の確認手段と、前記確認手段により接
続性が確認できた前記インターネットサービスプロバイ
ダが提供するネットワークプレフィクスを受信する第１
の受信手段と、前記受信したネットワークプレフィクス
を前記ローカルネットワークに対し通知する通知手段
と、前記通信ノードから受信したパケットが、自ルータ
装置が接続性を確認できているインターネットサービス
プロバイダから受信したネットワークプレフィクスを持
つソースアドレスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認で
きているインターネットサービスプロバイダから受信し
たネットワークプレフィクスを持っているソースアドレ
スであった場合は、該ネットワークプレフィクスを受信
したインターネットサービスプロバイダ宛に該パケット
を転送し、前記ソースアドレスが、自ルータ装置が接続
性を確認できているインターネットサービスプロバイダ
から受信したネットワークプレフィクスを持っているソ
ースアドレスではなかった場合は、該パケットの転送を
行わず、前記通信ノード宛に該パケットの転送を行わな
かったことを通知する制御手段とを具備したことを特徴
とする。
【００２１】本発明は、複数のインターネットサービス
プロバイダに接続されたルータ装置を介して所望の通信
ノードとの通信を行う通信ノードにおいて、前記ルータ
から、インターネットサービスプロバイダが提供するネ
ットワークプレフィクスを受信する受信手段と、前記ネ
ットワークプレフィクスと自通信ノード固有の識別子に
基づいてネットワークアドレスを生成する生成手段と、
パケットを送信する際に前記ネットワークアドレスをソ
ースアドレスとしてヘッダに付与して送信する送信手段
とを具備し、前記送信手段にて送信したパケットに対し
前記ルータから転送を行わなかった通知を受けるととも
に接続性が確認できた前記インターネットサービスプロ
バイダのネットワークプレフィクスの通知を受けた場合
には、前記パケットのソースアドレスを、新たに前記通
知を受けたネットワークプレフィクスと自通信ノード固
有の識別子に基づいて生成されたネットワークアドレス
に変更し、前記パケットを再度送信することを特徴とす
る。
【００２２】本発明は、複数のインターネットサービス
プロバイダに接続されるとともに、ローカルネットワー
クに接続され、このローカルネットネットワークに接続
された通信ノードのパケットを転送するルータ装置にお
けるソースアドレス選択方法であって、前記インターネ
ットサービスプロバイダとの接続性を確認し、接続性が
確認できた前記インターネットサービスプロバイダが提
供するネットワークプレフィクスを受信し、前記受信し
たネットワークプレフィクスを前記ローカルネットワー
クに対し通知し、前記通信ノードから受信したパケット
が、自ルータ装置が接続性を確認できているインターネ
ットサービスプロバイダから受信したネットワークプレ
フィクスを持つソースアドレスか否かを確認し、前記ソ
ースアドレスが、自ルータ装置が接続性を確認できてい
るインターネットサービスプロバイダから受信したネッ
トワークプレフィクスを持っているソースアドレスであ
った場合は、該ネットワークプレフィクスを受信したイ
ンターネットサービスプロバイダ宛に該パケットを転送
し、前記ソースアドレスが、自ルータ装置が接続性を確
認できているインターネットサービスプロバイダから受
信したネットワークプレフィクスを持っているソースア
ドレスではなかった場合は、該パケットの転送を行わ
ず、前記通信ノード宛に該パケットの転送を行わなかっ
たことを通知することを特徴とする。
【００２３】本発明は、複数のインターネットサービス
プロバイダに接続されるとともに、ローカルネットワー
クに接続され、このローカルネットネットワークに接続
された通信ノードのパケットを転送するルータ装置とし
てコンピュータを機能させるためのプログラムであっ
て、前記インターネットサービスプロバイダとの接続性
を確認する第１の確認機能と、前記確認手段により接続
性が確認できた前記インターネットサービスプロバイダ
が提供するネットワークプレフィクスを受信する第１の
受信機能と、前記受信したネットワークプレフィクスを
前記ローカルネットワークに対し通知する通知機能と、
前記通信ノードから受信したパケットが、自ルータ装置
が接続性を確認できているインターネットサービスプロ
バイダから受信したネットワークプレフィクスを持つソ
ースアドレスか否かを確認する第２の確認機能と、前記
ソースアドレスが、自ルータ装置が接続性を確認できて
いるインターネットサービスプロバイダから受信したネ
ットワークプレフィクスを持っているソースアドレスで
あった場合は、該ネットワークプレフィクスを受信した
インターネットサービスプロバイダ宛に該パケットを転
送し、前記ソースアドレスが、自ルータ装置が接続性を
確認できているインターネットサービスプロバイダから
受信したネットワークプレフィクスを持っているソース
アドレスではなかった場合は、該パケットの転送を行わ
ず、前記通信ノード宛に該パケットの転送を行わなかっ
たことを通知する制御機能とをコンピュータに実現させ
るためのプログラムである。
【００２４】本発明は、複数のインターネットサービス
プロバイダに接続されたルータ装置を介して所望の通信
ノードとの通信を行う通信ノードにおけるソースアドレ
ス選択方法であって、前記ルータから、インターネット
サービスプロバイダが提供するネットワークプレフィク
スを受信するを受信し、前記ネットワークプレフィクス
と自通信ノード固有の識別子に基づいてネットワークア
ドレスを生成し、パケットを送信する際に前記ネットワ
ークアドレスをソースアドレスとしてヘッダに付与して
送信し、送信した前記パケットに対し前記ルータから転
送を行わなかった通知を受けるとともに接続性が確認で
きた前記インターネットサービスプロバイダのネットワ
ークプレフィクスの通知を受けた場合には、前記パケッ
トのソースアドレスを、新たに前記通知を受けたネット
ワークプレフィクスと自通信ノード固有の識別子に基づ
いて生成されたネットワークアドレスに変更し、前記パ
ケットを再度送信することを特徴とする通信ノードにお
ける。
【００２５】本発明は、複数のインターネットサービス
プロバイダに接続されたルータ装置を介して所望の通信
ノードとの通信を行う通信ノードとしてコンピュータを
機能させるためのプログラムであって、前記ルータか
ら、インターネットサービスプロバイダが提供するネッ
トワークプレフィクスを受信する受信機能と、前記ネッ
トワークプレフィクスと自通信ノード固有の識別子に基
づいてネットワークアドレスを生成する生成機能と、パ
ケットを送信する際に前記ネットワークアドレスをソー
スアドレスとしてヘッダに付与して送信する送信機能
と、前記送信機能にて送信したパケットに対し前記ルー
タから転送を行わなかった通知を受けるとともに接続性
が確認できた前記インターネットサービスプロバイダの
ネットワークプレフィクスの通知を受けた場合には、前
記パケットのソースアドレスを、新たに前記通知を受け
たネットワークプレフィクスと自通信ノード固有の識別
子に基づいて生成されたネットワークアドレスに変更
し、前記パケットを再度送信する機能とをコンピュータ
に実現させるためのプログラムである。
【００２６】本発明は、複数のインターネットサービス
プロバイダに接続されたルータ装置と、このルータに接
続された通信ノードとを含むソースアドレス選択システ
ムにおけるソースアドレス選択方法であって、前記ルー
タ装置は、前記インターネットサービスプロバイダとの
接続性を確認し、前記確認手段により接続性が確認でき
た前記インターネットサービスプロバイダが提供するネ
ットワークプレフィクスを受信し、前記受信したネット
ワークプレフィクスを通知し、前記通信ノードは、前記
ルータから前記ネットワークプレフィクスを受信し、前
記ネットワークプレフィクスと自通信ノード固有の識別
子に基づいてネットワークアドレスを生成し、パケット
を送信する際に前記ネットワークアドレスをソースアド
レスとしてヘッダに付与して送信し、前記ルータ装置は
更に、前記通信ノードから受信したパケットが、自ルー
タ装置が接続性を確認できているインターネットサービ
スプロバイダから受信したネットワークプレフィクスを
持つソースアドレスか否かを確認し、前記ソースアドレ
スが、自ルータ装置が接続性を確認できているインター
ネットサービスプロバイダから受信したネットワークプ
レフィクスを持っているソースアドレスであった場合
は、該ネットワークプレフィクスを受信したインターネ
ットサービスプロバイダ宛に該パケットを転送し、前記
ソースアドレスが、自ルータ装置が接続性を確認できて
いるインターネットサービスプロバイダから受信したネ
ットワークプレフィクスを持っているソースアドレスで
はなかった場合は、該パケットの転送を行わず、前記通
信ノード宛に該パケットの転送を行わなかったことを通
知することと特徴とする。
【００２７】なお、装置に係る本発明は方法に係る発明
としても成立し、方法に係る本発明は装置に係る発明と
しても成立する。また、装置または方法に係る本発明
は、コンピュータに当該発明に相当する手順を実行させ
るための（あるいはコンピュータを当該発明に相当する
手段として機能させるための、あるいはコンピュータに
当該発明に相当する機能を実現させるための）プログラ
ムとしても成立し、該プログラムを記録したコンピュー
タ読取り可能な記録媒体としても成立する。
【００２８】本発明によれば、インターネットサービス
プロバイダとの接続状況を考慮し、インターネットへの
出口ルータに応じたソースアドレスの選択ができるよう
にすることで、マルチホーム環境を有効に利用可能とす
ることができる。
【００２９】
【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。
【００３０】図１に、本発明の一実施形態に係るマルチ
ホーム環境を含むネットワーク・システムの構成例を示
す。図１では、家庭内やＳＯＨＯなどにおかれたネット
ワーク構成の例を示している。
【００３１】図１において、Ｎは、ＩＰｖ６アドレスを
持つ通信ノードである。通信ノードＮは、典型的には、
計算機であるが、これに限らず、複数のインターネット
サービスプロバイダをそれぞれ介してインターネットに
接続することが可能なものであれば、携帯電話端末や情
報家電等、どのような形態のものでもよい。
【００３２】Ｉは、インターネットである。
【００３３】Ｓは、インターネットに接続されたサーバ
であり、本実施形態では、通信ノードＮの通信相手の一
例として示している。もちろん、通信ノードＮの通信相
手は、サーバ以外の種類の通信ノードであっても構わな
い。
【００３４】Ｒ１，Ｒ２は、いずれも、ルータであり、
通信ノードＮからみたインターネットへの出口ルータで
ある。
【００３５】ＩＳＰａとＩＳＰｂは、いずれも、インタ
ーネットへ接続され、通信ノードに対してインターネッ
トへの接続サービスを提供するインターネットサービス
プロバイダ（のネットワーク）であり、通信ノードＮか
らみると、ルータＲ１側に接続されている。
【００３６】ＩＳＰｃとＩＳＰｄは、いずれも、インタ
ーネットへ接続され、通信ノードに対してインターネッ
トへの接続サービスを提供するインターネットサービス
プロバイダ（のネットワーク）であり、通信ノードＮか
らみると、ルータＲ２側に接続されている。
【００３７】本例では、各インターネットサービスプロ
バイダＩＳＰａ〜ＩＳＰｄは、通信ノードＮへ、インタ
ーネット上のサーバＳとの通信を可能とするサービスを
提供している（以下、インターネットサービスプロバイ
ダを、適宜、プロバイダあるいはＩＳＰと記述する）。
【００３８】ここで、プロバイダＩＳＰａとルータＲ１
との間は、専用線での常時接続のような接続形態であっ
てもよいし、ダイヤルアップのような接続形態であって
もよい。プロバイダＩＳＰｂとルータＲ１との間の接続
形態、プロバイダＩＳＰｃとルータＲ２との間の接続形
態、プロバイダＩＳＰｄとルータＲ２との間の接続形態
のいずれについても、同様である。
【００３９】なお、“Ｐａ”は、プロバイダＩＳＰａが
提供するプレフィクス（ネットワークプレフィクス）を
示すものとする。同様に、“Ｐｂ”，“Ｐｃ”，“Ｐ
ｄ”は、それぞれ、プロバイダＩＳＰｂ，ＩＳＰｃ，Ｉ
ＳＰｄが提供するプレフィクスを示す。
【００４０】また、通信ノードＮが各プロバイダＩＳＰ
ａ，ＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄからそれぞれプレフ
ィクスをもらうとすると、通信ノードＮのインターフェ
ースＩＤ（Ｉｎｔｅｒｆａｃｅ ＩＤ）（通信ノードＮ
に固有の識別子）をＮとすれば、通信ノードＮは、“Ｐ
ａ：：Ｎ”，“Ｐｂ：：Ｎ”，“Ｐｃ：：Ｎ”，“Ｐ
ｄ：：Ｎ”の４つのネットワークアドレス（この場合、
グローバルアドレス）を持つことになる。ここでは、１
２８ｂｉｔのＩＰｖ６アドレスのうち、「上位６４ｂｉ
ｔ」は「プロバイダからもらうプレフィクス」からな
り、「下位６４ｂｉｔ」は「インタフェースＩＤ」から
なるものと仮定する。なお、ネットワークアドレスは、
通常、各インタフェースに付与されることになる。
【００４１】なお、図１の構成例では、通信ノードＮ
は、２台のルータのいずれかを介して４つのＩＳＰを利
用可能としているが、もちろん、何台のルータであって
もよいし、幾つのＩＳＰが利用可能でもよい。また、１
台のルータを介して幾つのＩＳＰが利用可能でもよい。
【００４２】また、図１の構成例では、通信ノードを１
台のみ示しているが、通信ノードＮと同一のサブネット
に他の通信ノードが存在しても構わない。
【００４３】また、図１の構成例では、通信ノードＮの
通信相手を１台のみ示しているが、もちろん、それ以外
にも存在し得る。また、通信ノードＮの通信相手は、直
接、インターネットに接続されていてもよいし、通信ノ
ードＮとは異なるＩＳＰを介して接続されていてもよい
し、通信ノードＮと同一のＩＳＰを介して接続されてい
てもよいし、ＩＳＰ以外のサブネットを介して接続され
ていてもよい。また、通信ノードＮの通信相手が、本発
明を適用したマルチホームの利用者であってもよいし、
そうでなくてもよい。
【００４４】以下では、主にルータＲ１を例にとってそ
の構成・動作について説明するが、ルータＲ１のみにつ
いて説明している部分は、ルータＲ２についても基本的
には同様である。
【００４５】図２に、本発明の一実施形態に係るルータ
（Ｒ１，Ｒ２）の構成例を示す。
【００４６】図２に示されるように、本実施形態のルー
タは、通信ノードＮ（に繋がる各回線）側またはＩＳＰ
（に繋がる各回線）側からパケットを受信するための受
信部３１、通信ノードＮ（に繋がる各回線）側またはＩ
ＳＰ（に繋がる各回線）側へパケットを送信するための
送信部３２、通常のルータの役割であるパケットを転送
するために必要な処理とともに、詳しくは後述するよう
に、ＩＳＰとの接続性に基づく通信ノードからのパケッ
トのＩＳＰへの転送の可否の判断、パケットを転送しな
かった際の通信ノードＮへの通知、通信ノードへの使用
すべきプレフィクスの通知等の処理を行うためのパケッ
ト転送処理部３３、対象となるＩＳＰの状態を管理（接
続性を確認）するためのＩＳＰ状態管理部３４、対象と
なるＩＳＰから提供されたプレフィクスを管理するため
のプレフィクス管理部３５を備えている。なお、ＩＳＰ
の状態に関する情報（例えば、接続性が確認されている
か否かを示す情報）や割当てられたプレフィクス等の必
要な情報は、適当な記憶装置に格納される。また、図２
では、通信ノードＮが接続されたサブネットに接続する
ための通信インタフェースや、各々のＩＳＰに繋がる回
線に接続するための各々の通信インタフェースは、省略
している。
【００４７】なお、本ルータＲ１は、コンピュータを使
用して実現可能であり、また、処理の全部又は一部をプ
ログラムによって実施することが可能であるし、処理の
全部又は一部を専用の半導体集積回路によって実施する
ことも可能である。
【００４８】図３に、本発明の一実施形態に係る通信ノ
ードＮの構成例を示す。
【００４９】図３に示されるように、本実施形態の通信
ノードは、ルータＲ１，Ｒ２が接続されたサブネットか
らパケットを受信するための受信部１１、該サブネット
へパケットを送信するための送信部１２、通信相手との
間でパケットのやり取りを行うために必要な処理ととも
に、詳しくは後述するように、使用すべきＩＳＰの選択
や、ルータ（Ｒ１，Ｒ２）からの通知に対する処理等の
処理を行うためのパケット転送処理部１３、ルータ（Ｒ
１，Ｒ２）から通知されたプレフィクスを管理するため
のプレフィクス管理部１４、ルータ（Ｒ１，Ｒ２）から
通知されたプレフィクスと自通信ノードのインタフェー
スＩＤとに基づいてネットワークアドレスを生成するた
めのネットワークアドレス生成部１５を備えている。な
お、それらプレフィクスやネットワークアドレス等の必
要な情報は、適当な記憶装置に格納される。また、図３
では、通信インタフェースは、省略している。
【００５０】なお、本通信ノードは、処理の全部又は一
部をプログラムによって実施することが可能であるし、
処理の全部又は一部を専用の半導体集積回路によって実
施することも可能である。
【００５１】以下、本実施形態の動作について説明す
る。
【００５２】まず、初期の段階について説明する。
【００５３】ルータＲ１は、ＩＳＰａ，ＩＳＰｂとの接
続性を確認し、接続性が確認できたＩＳＰが提供するプ
レフィクスを受信し、受信したプレフィクスを格納して
管理するとともに、その全部又は一部を通信ノードＮに
通知する（あるいは、サブネット内に広告する）。
【００５４】同様に、ルータＲ２は、ＩＳＰｃ，ＩＳＰ
ｄとの接続性を確認し、接続性が確認できたＩＳＰが提
供するプレフィクスを受信し、受信したプレフィクスを
格納して管理するとともに、その全部又は一部を通信ノ
ードＮに通知する（あるいは、サブネット内に広告す
る）。
【００５５】一方、通信ノードＮは、ルータＲ１やルー
タＲ２からプレフィクスを受信し、受信したプレフィク
スを格納するとともに、プレフィクスと自通信ノードの
インタフェースＩＤとに基づいてネットワークアドレス
を生成して、該当するインタフェースへ付与する。例え
ば、先に例示したように、“Ｐａ：：Ｎ”，“Ｐｂ：：
Ｎ”，“Ｐｃ：：Ｎ”，“Ｐｄ：：Ｎ”の４つのネット
ワークアドレスが生成され、（インタフェースに）付与
される。
【００５６】通信ノードＮは、１つ以上のネットワーク
アドレスが生成された後に、（当該ＩＳＰに接続性があ
れば）サーバＳと通信可能になる。
【００５７】また、通信ノードＮは、２つ以上のネット
ワークアドレスが生成され同一のインタフェースに付与
された後には、該インタフェースについて、ソースアド
レスとして使用すべきネットワークアドレスを適宜選択
すればよい。なお、選択の方法は、例えば、ランダムに
選択する方法、何らかの順番で選択するという基準、プ
レフィクスがライフタイムを持つ場合には、最も遅く期
限が切れるライフタイムを持つものを選択する、など、
種々のバリエーションがある。また、通信を行う通信主
体（例えば、アプリケーションソフトウェア等）によっ
ては、使用すべきＩＳＰの属性（例えば、転送速度、サ
ービス内容、料金等）に応じて優先順位が指定される場
合もある。また、通信主体によっては、使用すべきＩＳ
Ｐの属性が指定される場合もある。
【００５８】次に、ルータによる各ＩＳＰとの接続性の
定期的な確認について説明する。
【００５９】なお、ルータＲ１は、ＩＳＰａ，ＩＳＰｂ
との接続性を定期的に確認し、接続性に変化があれば、
プレフィクスの管理内容を更新する。例えば、それまで
接続性が確認されていたＩＳＰの接続性が確認できなか
った場合には、接続性の確認されたＩＳＰから割当てを
受けたプレフィクスを保持した管理情報において、その
接続性が確認できないものに転じたＩＳＰから割当てを
受けていたプレフィクスを使用不可に更新し、あるいは
該管理情報から、そのプレフィクスを削除する。また、
例えば、それまで接続性が確認されていなかったＩＳＰ
の接続性が確認できた場合には、接続性の確認されたＩ
ＳＰから割当てを受けたプレフィクスを保持した管理情
報において、その接続性が確認でるものに転じたＩＳＰ
から割当てを受けたプレフィクスを使用可能に更新し、
あるいはそのＩＳＰからプレフィクスを受信して該管理
情報に追加する。接続性に変化があった場合に、通信ノ
ードＮに通知（あるいは、サブネット内に広告）しても
よいが、それ以降に通信ノードＮからパケットを受信し
た際に必要に応じて（例えば、受信パケットのソースア
ドレスのプレフィクスに基づいて判断して必要があれ
ば）通信ノードＮに通知するようにしてもよい。
【００６０】ルータＲ１が各ＩＳＰの接続性を定期的に
確認する方法は、特に限定されないが、例えば、所定の
間隔で、確認したいＩＳＰを介して近接探索パケットを
所望の通信ノード宛に送信するようにしてもよい。ま
た、例えば、ＩＳＰ側から定期的に、接続が正常である
通知を受け取るようにしてもよいし、接続されたＩＳＰ
よりもさらに上流の通信路の状態を受け取るようにして
もよい。
【００６１】次に、図４に、ルータＲ１が通信ノードＮ
からパケットを受信した場合の処理手順の一例を示す。
【００６２】ルータＲ１は、通信ノードＮからのパケッ
トを受け取ると（ステップＳ１）、そのパケットのヘッ
ダ部にあるソースアドレス（ｓｒｃ ａｄｄｒ）が所定
の条件を満たすかどうか確認する（ステップＳ２）。
【００６３】ここで、所定の条件とは、受信パケットの
ソースアドレスのプレフィクスが、接続性を確認できて
いるＩＳＰから提供されたプレフィクスであること、で
ある。すなわち、例えば、ＩＳＰａとＩＳＰｂの接続性
が確認されている場合には、ルータＲ１は、そのソース
アドレスが、現在、自ルータが接続しているＩＳＰａか
ら割当てを受けているプレフィクスとＩＳＰｂから割当
てを受けているプレフィクスのいずれかに該当するプレ
フィクスが付いているアドレスであるか否か確認する。
また、例えば、ＩＳＰａのみの接続性が確認されている
場合には、ルータＲ１は、そのソースアドレスが、現
在、自ルータが接続しているＩＳＰａから割当てを受け
ているプレフィクスのいずれかに該当するプレフィクス
が付いているアドレスであるか否か確認する。
【００６４】通信ノードＮからの受信パケットのソース
アドレスが、現在、自ルータが接続しているＩＳＰから
割当てを受けているプレフィクスのいずれかに該当する
プレフィクスが付いているアドレスであった場合（ステ
ップＳ３）、ルータＲ１は、該受信パケットを該当する
ＩＳＰに向けて転送する（ステップＳ４）。
【００６５】一方、そのソースアドレスが、現在、自ル
ータが接続しているＩＳＰから割当てを受けているプレ
フィクスのいずれかにも該当しないプレフィクスが付い
ているアドレスであった場合（ステップＳ３）、そのパ
ケットを送信してきた通信ノードＮに対し、例えばＩＣ
ＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａ
ｇｅ Ｐｒｏｔｏｃｏｌ）を用いて、パケットの転送を
行わなかった旨（すなわち、そのソースアドレスが持つ
プレフィクスは使用できない旨）を示す情報（ｐｒｅｆ
ｉｘ−ｉｎｃｏｒｒｅｃｔ）を送信する（ステップＳ
５）。
【００６６】次に、図５に、通信ノードＮがサーバＳを
宛先とするパケットを送信し、これがルータＲ１へ転送
され、ルータＲ１が該パケットを転送しなかった場合の
処理手順の一例を示す。
【００６７】まず、通信ノードＮが、サーバＳを宛先と
するパケットを送信する（ステップＳ１１）。
【００６８】その際、ソースアドレスとして選択したア
ドレスのプレフィクスが、ルータＲ１により現在接続性
が確認されていない状態になったＩＳＰに係るものであ
ったとする。この場合、前述のように、ルータＲ１は、
通信ノードＮに対し、パケットの転送を行わなかった旨
を含む通知メッセージを送信することになる。
【００６９】しかして、通信ノードＮは、ルータＲ１か
ら、パケットの転送を行わなかった旨の通知を受信した
場合（ステップＳ１２）、その通知を受けた当該パケッ
トについて送信時に使用したソースアドレスのプレフィ
クスとは異なるプレフィクスによるネットワークアドレ
スが、サーバＳを宛先とするパケットのソースアドレス
として使用可能かどうか調べる（ステップＳ１３）。
【００７０】使用可能であれば（ステップＳ１４）、そ
の使用可能なネットワークアドレスをソースアドレスと
してヘッダに付与して、サーバＳを宛先とするパケット
を、再度、送信する（ステップＳ１５）。
【００７１】一方、使用不可（異なるプレフィクスによ
るネットワークアドレスがない場合の他に、それがあっ
ても何らかに理由によって当該通信には使用できない場
合がある）であれば（ステップＳ１４）、エラー処理を
行う（ステップＳ１６）。エラー処理としては、何もし
ない、上位レイヤに通信に失敗した旨（当該ソースアド
レスが持つプレフィクスは使用できない旨）を通知す
る、一定時間待ってステップＳ１３に戻る、など、種々
のバリエーションが考えられる。
【００７２】なお、ステップＳ１３で、上記の代わり
に、その通知を受けた当該パケットについて送信時に使
用したソースアドレスのプレフィクスに係るＩＳＰとは
異なるＩＳＰに係るプレフィクスによるネットワークア
ドレスが、サーバＳを宛先とするパケットのソースアド
レスとして使用可能かどうか調べるようにしてもよい。
【００７３】また、ステップＳ１２で、ルータＲ１か
ら、パケットの転送を行わなかった旨の通知を受信した
場合には、直ちに、エラー処理（例えば、何もしない、
上位レイヤに通信に失敗した旨（当該ソースアドレスが
持つプレフィクスは使用できない旨）を通知する、通信
に失敗した旨及びその際に使用したプレフィクスを通知
する、など）に移行してしまう方法もある（後は、例え
ば、上位レイヤによる処理あるいはユーザによる対処が
なされる）。
【００７４】次に、図６に、ルータＲ１が通信ノードＮ
からパケットを受信した場合の処理手順の他の例を示
す。
【００７５】図４の手順例では、受信パケットのソース
アドレスが所定の条件を満たさないために該パケットを
転送しなかった場合には、ルータＲ１は、通信ノードＮ
に対し、パケットの転送を行わなかった旨を通知した
が、この手順例では、その際に、この通知（例えば、Ｉ
ＣＭＰメッセージ）に、現在接続性が確認されているＩ
ＳＰから提供されたプレフィクスをも含めて、通信ノー
ドＮへ通知するようにするものである（ステップＳ２
３，Ｓ２５）。
【００７６】例えば、ＩＳＰａが何らかの理由で接続が
絶たれており、ＩＳＰｂのみの接続が確認されている場
合に、通信ノードＮからＩＳＰｂに係るプレフィクス以
外のプレフィクス（例えば、ＩＳＰａに係るプレフィク
ス）によるソースアドレスを持つパケットを受信したな
らば、ＩＳＰｂから提供されたプレフィクスＰｂのみを
通信ノードＮに通知する。
【００７７】また、例えば、ＩＳＰａ及びＩＳＰｂの両
方の接続性が確認されてる場合に、通信ノードＮからＩ
ＳＰａ及びＩＳＰｂに係るプレフィクス以外のプレフィ
クスによるソースアドレスを持つパケットを受信したな
らば、ＩＳＰａから提供されたプレフィクスＰａ及びＩ
ＳＰｂから提供されたプレフィクスＰｂを通信ノードＮ
に通知する。
【００７８】図７に、この場合のＩＣＭＰ（ｐｒｅｆｉ
ｘ−ｉｎｃｏｒｒｅｃｔ）メッセージの構成例を示す。
【００７９】図７において、「ＩＰｖ６ヘッダ」（図
中、２１）は、ＩＰｖ６パケットであること示すヘッ
ダ、「ＩＣＭＰヘッダ」（図中、２２）は、ＩＣＭＰメ
ッセージであることを示すヘッダ、「ｔａｒｇｅｔ ｄ
ｓｔ ｐｒｅｆｉｘｌｅｎ（対象宛先プレフィクス
長）」（図中、２３）は、このＩＣＭＰメッセージに含
まれるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフ
ィクス）が有効な宛先（ｄｅｓｔｉｎａｔｉｏｎ）とな
るアドレスレンジを示すためのフィールド、「ｎｕｍｂ
ｅｒ ｏｆ ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨
プレフィクス数）」（図中、２４）は、このＩＣＭＰメ
ッセージに含まれるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ
の数を示すためのフィールド、「ｐｒｅｆｅｒｒｅｄ−
ｐｒｅｆｉｘ（推奨プレフィクス）」（図中、２５〜２
７）は、それぞれ、使用を推奨するプレフィクスを示す
ためのフィールド、「原因パケット」（図中、２８）
は、このＩＣＭＰメッセージがルータＲ１から発せられ
る原因となったパケットである。
【００８０】ここで、「ｔａｒｇｅｔ ｄｓｔ ｐｒｅ
ｆｉｘｌｅｎ」は、例えば１２８なら“／１２８”とい
う意味であり、上位１２８ビットで有効なアドレスレン
ジを指定している。通常、原因となったパケットの宛先
そのものにしか有効でないが、例えば、この値が６４な
ら、上位６４ｂｉｔのプレフィクスが一致する場合に限
り、このｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘを使用する
ことで、有効なＩＳＰを介してパケットを送信すること
ができる。ルータＲ１は、何らかの方法でこの値を得ら
れる場合には、得られた適切な値を入れる。そうでなけ
れば、−１を入れる（１２８が入るのは、明らかなホス
トルータ（ｈｏｓｔ ｒｏｕｔｅ）を持っている場合で
ある）。
【００８１】次に、図８に、通信ノードＮの処理手順の
他の例（図６の手順例に対応する例）を示す。
【００８２】まず、通信ノードＮが、サーバＳを宛先と
するパケットを送信する（ステップＳ３１）。
【００８３】その際、ソースアドレスとして選択したア
ドレスのプレフィクスが、ルータＲ１により現在接続性
が確認されていない状態になったＩＳＰに係るものであ
ったとすると、ルータＲ１は、通信ノードＮに対し、パ
ケットの転送を行わなかった旨及び現在接続性が確認さ
れているＩＳＰから提供されたプレフィクスを含む通知
を含む通知メッセージを送信することになる。
【００８４】しかして、通信ノードＮは、ルータＲ１か
ら、パケットの転送を行わなかった旨及び現在接続性が
確認されているＩＳＰから提供されたプレフィクスを含
む通知を受信する（ステップＳ３２）。
【００８５】この場合、通信ノードＮは、必要に応じ
て、その通知を受けたプレフィクスとプレフィクスと自
通信ノードのインタフェースＩＤとに基づいてネットワ
ークアドレスを生成し（ステップＳ３３）、その通知を
受けたパケットについて、ソースアドレスを、この生成
されたアドレスに変更して（生成されたアドレスを、ソ
ースアドレスとしてヘッダに付与して）、再度、送信す
る（ステップＳ３４）。
【００８６】なお、該当するアドレスが既に生成され
て、インタフェースに付与されている場合には、ステッ
プＳ３３はスキップしても構わない。
【００８７】また、複数のプレフィクスが通知された場
合には、複数のネットワークアドレスが生成可能である
が、この場合に、ソースアドレスとして使用すべきネッ
トワークアドレスを先に例示した選択方法などで適宜選
択すればよい。
【００８８】また、アプリケーションソフトウェア等の
通信主体によっては、通知されたプレフィクスによるネ
ットワークアドレスがソースアドレスとして使用できな
い場合もあり得る。
【００８９】ところで、ルータＲ１において、どのよう
なパケット転送制御を行うか、あるいはどのようにｐｒ
ｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）の
通知の仕方をするかについては、種々のバリエーション
が考えられる。
【００９０】例えば、ルータＲ１は、ＩＳＰａ側の回線
の帯域が広いことを予め知っており、デフォルトでＩＳ
Ｐａ側を使用する設定であったとしても、通信ノードＮ
側から受信したパケットのソースアドレスにＩＳＰｂ側
のプレフィクスＰｂが使われている場合には、この指示
を優先しＩＳＰｂ側にそのパケットを転送するように制
御してもよい。
【００９１】また、例えば、ＩＳＰａ側の回線の帯域が
ＩＳＰｂよりも大幅に広い場合で通信ノードＮから受信
したパケットがＩＳＰｂ側のプレフィクスを使用したソ
ースアドレスであった場合には、（たとえＩＳＰｂの接
続性が確認されていても）ＩＣＭＰ（ｐｒｅｆｉｘ−ｉ
ｎｃｏｒｒｅｃｔ）等のメッセージを通信ノードＮに通
知すると同時にＩＳＰａのプレフィクスを使用するよう
に通知するようにしてもよい。これにより、通信ノード
Ｎは、最初に送信したパケットではＩＳＰｂを使用して
いたが、ルータＲ１よりＩＳＰａ側のプレフィクスの通
知を受けることにより、より帯域の広いＩＳＰａを介し
た通信が可能となる。
【００９２】また、例えば、ルータＲ１は、自通信ノー
ドが接続されるＩＳＰａ，ＩＳＰｂに係るプレフィクス
を通信ノードＮに通知する代わりに、ルータＲ２へのリ
ダイレクトを応答する制御も考えられる。
【００９３】さて、以下では、図９及び図１０のシーケ
ンス例を参照しながら、ルータＲ１の動作例について説
明する。
【００９４】まず、図１の構成例において、ルータＲ１
が通信ノードＮからパケットを受信した際にＩＳＰａの
接続性が確認されている場合を考える。
【００９５】この場合に、通信ノードＮが、図９（ａ）
のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アド
レス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ，
ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする
（Ｓ１０１）。ここで、ＩＳＰａがルータＲ１において
優先すべきＩＳＰであると予め定められていたとする
と、この場合には、ルータＲ１は、通信ノードＮから受
信したパケットをＩＳＰａに転送する（Ｓ１０２）。
【００９６】次に、ルータＲ１が通信ノードＮからパケ
ットを受信した際にＩＳＰａの接続性が絶たれていた場
合を考える。
【００９７】この場合に、通信ノードＮが、図９（ｂ）
のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アド
レス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ，
ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする
（Ｓ１２１）。
【００９８】ここで、受信したパケットを接続性が保た
れている他のＩＳＰｂに転送してもｉｎｇｒｅｓｓ ｆ
ｉｌｔｅｒが導入されていることが多く、ＩＳＰｂにて
このパケットの転送を拒絶されることが予めわかってい
るので、ルータＲ１は、通信ノードＮに対し、ＩＣＭＰ
メッセージ（図７参照）を送信するものとする（Ｓ１２
２）。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎ
ｃｏｒｒｅｃｔと、推奨するｐｒｅｆｆｅｒｅｄ Ｐｒ
ｅｆｉｘ：Ｐｂを含む。
【００９９】通信ノードＮは、この通知を受けて、ソー
スアドレス＝“Ｐｂ：：Ｎ”、宛先アドレス＝“Ｓ”と
するパケット（ｓｒｃ＝Ｐｂ：：Ｎ ， ｄｓｔ＝Ｓ）
をルータＲ１に向けて送信すると（Ｓ１２３）、この場
合には、ルータＲ１は、通信ノードＮから受信したパケ
ットをＩＳＰｂに転送する（Ｓ１２４）。
【０１００】次に、通信ノードＮが、図９（ｃ）のよう
に、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝
“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓ
ｔ＝Ｓ）をルータＲ２に向けて送信した場合を考える
（Ｓ１３１）。
【０１０１】この場合には、ルータＲ２は、基本的に
は、上記のルータＲ１と同じ動作をすることになる。
【０１０２】すなわち、通信ノードＮから、上記のパケ
ットを受信したルータＲ２は、受信したパケットのソー
スアドレスに付与されたプレフィクスＰａが自ルータＲ
２と接続しているＩＳＰから通知されたプレフィクスか
どうかを確認する。
【０１０３】このプレフィクスＰａは、自ルータＲ２と
接続しているＩＳＰから通知されたプレフィクスではな
いので、通信ノードＮに向けてＩＣＭＰメッセージを送
信する（Ｓ１３２）。このＩＣＭＰメッセージは、ｐｒ
ｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、ルータＲ２が推奨す
るｐｒｅｆｆｅｒｄ Ｐｒｅｆｉｘ：Ｐｃ，Ｐｄ（ただ
し、ＩＳＰｃとＩＳＰｄの接続性がいずれも確認できて
いる場合）を含む。ここで、ＩＳＰｃ，ＩＳＰｄの接続
性は予め確認しておくものとする。
【０１０４】通信ノードＮは、この通知を受けて、例え
ば、Ｐｃを選択して、ソースアドレス＝“Ｐｃ：：
Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝
Ｐｃ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送
信し（Ｓ１３３）、ルータＲ２は、通信ノードＮから受
信したパケットをＩＳＰｃに転送する（Ｓ１３４）。
【０１０５】次に、ＩＳＰａ，ＩＳＰｂの両方の接続が
絶たれている場合を想定する。この場合、ルータＲ１
は、インターネットへの接続性を果たさない。
【０１０６】ここで、通信ノードＮが、図１０のよう
に、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝
“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓ
ｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１４
１）。
【０１０７】この場合、ルータＲ１は、ＩＳＰａ，ＩＳ
Ｐｂの接続が絶たれているため、通信ノードＮに対し、
ＩＣＭＰメッセージとしてｒｅｄｉｒｅｃｔ（リダイレ
クト）を送信し、これにより、通信ノードＮに対し、パ
ケットの送信先としてルータＲ２を選択させるよう指示
を行うようにしてもよい（Ｓ１４２）。
【０１０８】なお、ルータＲ１は、（例えば、ルータ間
の情報交換等により）リダイレクトの対象となる他のル
ータとしてルータＲ２が存在することを知っている（あ
るいは知ることができる）ものとする。
【０１０９】通信ノードＮは、このＩＣＭＰメッセージ
に基づいて、まず、ソースアドレス＝“Ｐａ：：Ｎ”、
宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐ
ａ：：Ｎ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信す
る（Ｓ１４３）。
【０１１０】ここで、ルータＲ２は、自ルータＲ２が接
続されていないＩＳＰのプレフィクスであることから、
ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、ルータＲ２が推
奨するｐｒｅｆｆｅｒｄ Ｐｒｅｆｉｘ：Ｐｃ，Ｐｄ
（ただし、ＩＳＰｃとＩＳＰｄの接続性がいずれも確認
できている場合）を含むＩＣＭＰメッセージを送信する
（Ｓ１４４）。
【０１１１】通信ノードＮは、この通知を受けて、例え
ば、Ｐｃを選択して、ソースアドレス＝“Ｐｃ：：
Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝
Ｐｃ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送
信し（Ｓ１４５）、ルータＲ２は、通信ノードＮから受
信したパケットをＩＳＰｃに転送する（Ｓ１４６）。
【０１１２】なお、ＩＳＰａ，ＩＳＰｂの両方の接続が
絶たれている場合において、ルータＲ１は、リダイレク
トの対象となるルータが複数存在するならば、通信ノー
ドＮに対して、それらから適宜選択した１つのルータを
返すようにしてもよい。
【０１１３】また、ＩＳＰａ，ＩＳＰｂの両方の接続が
絶たれている場合において、ルータＲ１は、リダイレク
トの対象となるルータがもともと存在しないか、または
リダイレクトの対象となるルータがすべてダウンしてい
るとを知っているならば、通信ノードＮに対して、エラ
ーを返すようにすると好ましい。
【０１１４】次に、以下では、図９及び図１０のシーケ
ンス例を参照しながら、通信ノードＮの動作例について
説明する。
【０１１５】まず、前述のように通信ノードＮがＩＣＭ
Ｐメッセージを受信する場合について説明する。
【０１１６】通信ノードＮは、ソースアドレス＝“Ｐ
ａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓ
ｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向
けて送信する（図９（ｂ）のＳ１２１参照）。
【０１１７】ここで、ソースアドレスとして用いられる
プレフィクスは、例えば、デフォルトルータであるルー
タＲ１から予め通知を受けているものとする。
【０１１８】次に、前述したようにこの受信したパケッ
トが指定しているＩＳＰａの接続が絶たれていた場合を
想定する。この場合は、ルータＲ１から図７に示すＩＣ
ＭＰメッセージが届く。このＩＣＭＰメッセージは、ｐ
ｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、推奨するｐｒｅｆ
ｆｅｒｅｄ Ｐｒｅｆｉｘ：Ｐｂを含む（図９（ｂ）の
Ｓ１２２参照）。
【０１１９】通信ノードＮは、このＩＣＭＰメッセージ
を受信すると、このメッセージがどのパケットの送信に
対するメッセージであるのかを、図７の原因となるパケ
ット（２８）から判断する。
【０１２０】次に、このメッセージに含まれるｐｒｅｆ
ｆｅｒｅｄ ｐｒｅｆｉｘ（ここでは、Ｐｂ）から原因
となった先のパケットのソースアドレスを書き換えて再
度送信する。
【０１２１】その際、ｐｒｅｆｆｅｒｄ ｐｒｅｆｉｘ
として受信したプレフィクス（Ｐｂ）と通信ノードＮが
持つインターフェースＩＤとの組合せにより作成したネ
ットワークアドレス“Ｐｂ：：Ｎ”が予め用意されてい
なければ、これを作成して使用する。
【０１２２】また、ここで、原因となるパケットを調
べ、それに対応しているコネクションが現在あるかどう
かどうかを調べてからパケットを再送信するよう制御し
てもよい。
【０１２３】原因となるパケットに関連するコネクショ
ンがある場合、それが確立前、すなわち発呼中であるか
を調べる。例えば、ＴＣＰ上でＳＹＮ＿ＳＥＮＴの状態
かどうかを調べることにより実現できる。
【０１２４】発呼中である場合、そのコネクションのソ
ースアドレスを先のＩＣＭＰメッセージで受信したプレ
フィックスを付与したソースアドレスにより再度コネク
ションの設定を行う。ただし、アプリケーションがソー
スアドレスを明示的に指定している場合には、再設定を
行わないように制御してもよい。一例として、一般的な
ソケットを使っている場合には、ｃｏｎｎｅｃｔ（）を
呼ぶ前にｂｉｎｄ（）を呼び、そこでソースアドレスを
明示的に指定してきた場合などである。
【０１２５】さらに、ルータＲ１またはＲ２から受信し
たＩＣＭＰメッセージを、図１１に例示するようなプレ
フィクス管理テーブルとして保持するようにしてもよ
い。ここでは、ＩＣＭＰメッセージを受信したら、その
結果を、宛先のアドレスまたはアドレスレンジと、ｐｒ
ｅｆｅｒｒｅｄ−ｐｒｅｆｉｘとの組で、記憶する。
【０１２６】一例として、“Ｓ：：ａ”にパケットを送
信して、これに対しルータＲ１からｐｒｅｆｉｃ−ｉｎ
ｃｏｒｒｅｃｔのＩＣＭＰメッセージを受信した場合に
ついて説明する。
【０１２７】このＩＣＭＰメッセージの中には、ｐｒｅ
ｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）とし
て“Ｐａ”が記載されている。この結果を、アドレスま
たはアドレスレンジと、プレフィクスとの組で記憶して
おくことにより、次回、“Ｓ：：ａ”宛にパケットを送
信する際に、このテーブルを参照し、ソースアドレスを
推奨プレフィクスである“Ｐａ：：ａ”と変更してパケ
ットを送信する。
【０１２８】また、“Ｓ：：／６４”というプレフィク
スを持つアドレスの場合、このテーブルを参照し、Ｐａ
を優先的に使用するように制御してもよい。これによ
り、予め推奨のプレフィクスを優先的に使用することが
できるため、ルータからＩＣＭＰメッセージを受信する
回数を少なくすることができる。さらに、このテーブル
の記憶は、デフォルトルータが変更になったり、通信ノ
ードＮにおけるパケット送信先のルールが変更になった
場合は、破棄するようにしてもよい。
【０１２９】次に、通信ノードＮが、ソースアドレス＝
“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット
（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２
に向けて送信した場合について説明する（図１０のＳ１
３１参照）。このパケットは、例えば、ＴＣＰコネクシ
ョン設定のためのパケットである場合を想定する。
【０１３０】このパケットを受信したルータＲ２は、こ
のパケットのソースアドレスに含まれるＰａのプレフィ
クスを検出することにより、このＰａのプレフィクスは
ルータＲ２の上流のＩＳＰからは割り当てられていない
ことがわかる。
【０１３１】これにより、ルータＲ２は、このパケット
を送信した通信ノードＮに対して、ＩＣＭＰメッセージ
（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）を送信する（図
１０のＳ１３２参照）。このＩＣＭＰメッセージには、
ルータＲ２が推奨するプレフィクスであるｐｒｅｆｅｒ
ｒｅｄ−ｐｒｅｆｉｘ：Ｐｃ，Ｐｄが含まれている。
【０１３２】通信ノードＮは、このＩＣＭＰメッセージ
を受信すると、まず、自通信ノードＮ（通信ノードＮの
インターフェースであるインターフェースＮ）に設定さ
れているアドレスと受信したｐｒｅｆｅｒｒｅｄ−ｐｒ
ｅｆｉｘとを比較する。通信ノードＮは、ＰｃとＰｄの
プレフィクスをもつアドレスも保持しているため、いず
れかを選択してソースアドレスとする。ここでは、Ｐｃ
を選択し、ソースアドレスを“Ｐｃ：：Ｎ”とする。
【０１３３】次に、ＩＣＭＰメッセージの中の原因とな
ったパケットを調べる。この際、原因となったパケット
のソースアドレス（ｓｒｃ ａｄｄｒ）、宛先アドレス
（ｄｓｔ ａｄｄｒ）、ソースポート（ｓｒｃ ｐｏｒ
ｔ）、宛先ポート（ｄｓｔｐｏｒｔ）の４つの組を調べ
ることにより、どの接続先へのどのような要求かがわか
る。次に、前述したようにこの要求が確立前、すなわち
発呼中であるかを調べる。その後、確立前であった場合
には、ソースアドレスを“Ｐｃ：：Ｎ”に変更してパケ
ットを再度送信する。
【０１３４】以下では、通信ノードＮにおける、ルータ
からＩＣＭＰメッセージ等で通知されたプレフィクスの
管理方法について説明する。
【０１３５】ルータからＩＣＭＰメッセージ等で通知さ
れたプレフィクスを、いつまで使用するか、あるいはい
つ破棄するかについては、種々のバリエーションがあ
る。
【０１３６】なお、プレフィクス管理テーブルを、キャ
ッシュとすれば、基本的には、いつ破棄しても通信に支
障はない。
【０１３７】以下、幾つかのバリエーションを示す。
【０１３８】（１）通知されたプレフィクスは、そのと
きのパケットの再送にのみ使用して、破棄する。メモリ
の量が少ない通信ノードが通信する場合には、このよう
にすると、好ましい。同じ通信相手に対して、再度、新
しいコネクションを張ろうとする場合には、同じ手順が
繰り返される。
【０１３９】（２）通知されたプレフィクスは、予め定
められたイベントが起きるまで、保持し、予め定められ
たイベントが起きたら、その全部又は一部を破棄する、
という処理を、定常的に行う。例えば、テーブルの大き
さを決めて、データが溢れたならば、その時点で、（例
えば、最後に参照したエントリを）順次捨てる。
【０１４０】（３）基本的には、定常的な処理として
は、破棄は行わず、破棄すべき状況になった際に、通知
されたプレフィクスの全部又は一部を破棄する。破棄す
べき状況とは、例えば、 （３−１）Ｒｅｄｉｒｅｃｔを受けた （３−２）使っていたルータが（今さっき）ダウンした などである。
【０１４１】上記の（３−１）のＲｅｄｉｒｅｃｔを受
けた場合について説明する。例えば、ノードＮが、ルー
タＲ１とルータＲ２を介してインターネットに接続可能
な状況で、過去にルータＲ２から、Ｐｒｅｆｉｘ−ｉｎ
ｃｏｒｒｅｃｔを受けて、ｐｒｅｆｉｘ：ｐｄを通知さ
れたとする。すると、通信ノードＮは、Ｒ２から「Ｓに
ついてはプレフィクスｐｄを推奨する」という通知を受
けたことを記憶する。しばらく、ｐｄによって通信可能
であったが、ある時点で、ルータＲ２から「Ｓについて
は、ルータＲ１を推奨する」と通知された（ＩＣＭＰ
ｒｅｄｉｒｅｃｔ）とする。このような場合に、ｐｄ
は、ルータＲ２に依存したプレフィクスなので、少なく
ともこれは破棄する。また、いままで使ってた経路で突
然ｒｅｄｉｒｅｃｔを受けるのは、ルータＲ１，Ｒ２を
取り巻く状況が大きく変化した可能性が高いので（例え
ば、ルータＲ２の先のｌｉｎｋが全部落ちたなど）、プ
レフィクスを全て破棄するようにしてもよい。
【０１４２】上記の（３−２）の使っていたルータが
（今さっき）ダウンした場合について説明する。「Ｓに
ついてはルータＲ２に転送する」という情報を保持して
いる場合に、ルータＲ２がダウンしたことがわかったな
らば（例えば、ＩＰｖ６ノードは、定期的に自分が使っ
てるルータに対して、生存確認を行うので（ＮＵＤ，Ｒ
ＦＣ２４６１）、これによって知ることができる）、か
なり状況が変わっているので、保持しているプレフィク
スは、無意味であり、それらを全て廃棄するようにして
もよい。
【０１４３】この（３）の処理は、（１）のケースでな
い限り、実施するのが望ましい（無駄な手順の増加を回
避できる）。
【０１４４】（４）ライフタイム（ｌｉｆｅｔｉｍｅ）
を使う 通信ノードＮは、プレフィクスをテーブル等に登録する
際に、そのライフタイム（例えば、ｎ秒）を、（例えば
通信ノードＮが独自に）決定して、該プレフィクスに対
応付けて登録するようにしてもよい。この場合には、そ
の時間が経過した際に、破棄する。
【０１４５】なお、以上の各機能は、ソフトウェアとし
て実現可能である。また、本実施形態は、コンピュータ
に所定の手段を実行させるための（あるいはコンピュー
タを所定の手段として機能させるための、あるいはコン
ピュータに所定の機能を実現させるための）プログラム
として実施することもでき、該プログラムを記録したコ
ンピュータ読取り可能な記録媒体として実施することも
できる。
【０１４６】なお、この発明の実施の形態で例示した構
成は一例であって、それ以外の構成を排除する趣旨のも
のではなく、例示した構成の一部を他のもので置き換え
たり、例示した構成の一部を省いたり、例示した構成に
別の機能あるいは要素を付加したり、それらを組み合わ
せたりすることなどによって得られる別の構成も可能で
ある。また、例示した構成と論理的に等価な別の構成、
例示した構成と論理的に等価な部分を含む別の構成、例
示した構成の要部と論理的に等価な別の構成なども可能
である。また、例示した構成と同一もしくは類似の目的
を達成する別の構成、例示した構成と同一もしくは類似
の効果を奏する別の構成なども可能である。また、この
発明の実施の形態で例示した各種構成部分についての各
種バリエーションは、適宜組み合わせて実施することが
可能である。また、この発明の実施の形態は、個別装置
としての発明、関連を持つ２以上の装置についての発
明、システム全体としての発明、個別装置内部の構成部
分についての発明、またはそれらに対応する方法の発明
等、種々の観点、段階、概念またはカテゴリに係る発明
を包含・内在するものである。従って、この発明の実施
の形態に開示した内容からは、例示した構成に限定され
ることなく発明を抽出することができるものである。
【０１４７】本発明は、上述した実施の形態に限定され
るものではなく、その技術的範囲において種々変形して
実施することができる。
【０１４８】
【発明の効果】本発明によれば、マルチホーム環境を有
効に利用することが可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るネットワーク・シス
テムの構成例を示す図
【図２】同実施形態に係るルータの構成例を示す図
【図３】同実施形態に係る通信ノードの構成例を示す図
【図４】同実施形態に係るルータの処理手順の一例を示
すフローチャート
【図５】同実施形態に係る通信ノードの処理手順の一例
を示すフローチャート
【図６】同実施形態に係るルータの処理手順の他の例を
示すフローチャート
【図７】同実施形態に係るＩＣＭＰメッセージの構成例
を示す図
【図８】同実施形態に係る通信ノードの処理手順の他の
例を示すフローチャート
【図９】同実施形態に係るネットワーク・システムのシ
ーケンス例を示す図
【図１０】同実施形態に係るネットワーク・システムの
シーケンス例を示す図
【図１１】同実施形態に係るプレフィクス管理テーブル
の構成例を示す図
【図１２】従来のマルチホーム環境のネットワーク・シ
ステムについて説明するための図
【符号の説明】
Ｎ…通信ノード Ｒ１，Ｒ２…ルータ Ｉ…インターネット ＩＳＰａ，ＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄ…インターネ
ットサービスプロバイダ Ｓ…サーバ １１，３１…受信部 １２，３２…送信部 １３，３３…パケット転送処理部 １４，３５…プレフィクス管理部 １５…ネットワークアドレス生成部 ３４…ＩＳＰ状態管理部
フロントページの続き (72)発明者 玉田 雄三 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5K030 GA12 HA08 HD03 KA05 KX23 LB08 MA07

Claims (19)

    【特許請求の範囲】
  1. 【請求項１】複数のインターネットサービスプロバイダ
    に接続されたルータ装置と、このルータに接続された通
    信ノードとを含むソースアドレス選択システムにおい
    て、 前記ルータ装置は、 前記インターネットサービスプロバイダとの接続性を確
    認する第１の確認手段と、 前記確認手段により接続性が確認できた前記インターネ
    ットサービスプロバイダが提供するネットワークプレフ
    ィクスを受信する第１の受信手段と、 前記受信したネットワークプレフィクスを通知する通知
    手段とを具備し、 前記通信ノードは、 前記ルータから前記ネットワークプレフィクスを受信す
    る第２の受信手段と、 前記ネットワークプレフィクスと自通信ノード固有の識
    別子に基づいてネットワークアドレスを生成する生成手
    段と、 パケットを送信する際に前記ネットワークアドレスをソ
    ースアドレスとしてヘッダに付与して送信する送信手段
    とを具備し、 前記ルータ装置は更に、 前記通信ノードから受信したパケットが、自ルータ装置
    が接続性を確認できているインターネットサービスプロ
    バイダから受信したネットワークプレフィクスを持つソ
    ースアドレスか否かを確認する第２の確認手段と、 前記ソースアドレスが、自ルータ装置が接続性を確認で
    きているインターネットサービスプロバイダから受信し
    たネットワークプレフィクスを持っているソースアドレ
    スであった場合は、該ネットワークプレフィクスを受信
    したインターネットサービスプロバイダ宛に該パケット
    を転送し、前記ソースアドレスが、自ルータ装置が接続
    性を確認できているインターネットサービスプロバイダ
    から受信したネットワークプレフィクスを持っているソ
    ースアドレスではなかった場合は、該パケットの転送を
    行わず、前記通信ノード宛に該パケットの転送を行わな
    かったことを通知する制御手段とを具備したことを特徴
    とするソースアドレス選択システム。
  2. 【請求項２】前記ルータ装置の前記制御手段は、前記ソ
    ースアドレスが、自ルータ装置が接続性を確認できてい
    るインターネットサービスプロバイダから受信したネッ
    トワークプレフィクスを持っているソースアドレスでは
    なかった場合は、該パケットの転送を行わず、前記通信
    ノード宛に該パケットの転送を行わなかったことを通知
    するとともに、前記確認手段により接続性が確認できた
    前記インターネットサービスプロバイダが提供するネッ
    トワークプレフィクスを前記通信ノード宛に通知する機
    能を更に具備することを特徴とする請求項１に記載のソ
    ースアドレス選択システム。
  3. 【請求項３】前記通信ノードは、送信したパケットに対
    し前記ルータから転送を行わなかった通知を受けるとと
    もに接続性が確認できた前記インターネットサービスプ
    ロバイダのネットワークプレフィクスの通知を受けた場
    合には、前記パケットのソースアドレスを、新たに前記
    通知を受けたネットワークプレフィクスと自通信ノード
    固有の識別子に基づいて生成されたネットワークアドレ
    スに変更し、前記パケットを再度送信することを特徴と
    する請求項２に記載のソースアドレス選択システム。
  4. 【請求項４】前記通信ノードは、送信したパケットに対
    し前記ルータから転送を行わなかった通知を受けるとと
    もに接続性が確認できた前記インターネットサービスプ
    ロバイダのネットワークプレフィクスの通知を受けた場
    合に、該ネットワークプレフィクスに基づく前記ネット
    ワークアドレスを、当該パケットの再送信についてのみ
    使用することを特徴と請求項３に記載のソースアドレス
    選択システム。
  5. 【請求項５】前記通信ノードは、送信したパケットに対
    し前記ルータから転送を行わなかった通知を受けるとと
    もに接続性が確認できた前記インターネットサービスプ
    ロバイダのネットワークプレフィクスの通知を受けた場
    合に、該ネットワークプレフィクスに基づく前記ネット
    ワークアドレスを、それが無効になるまで使用すること
    を特徴と請求項３に記載のソースアドレス選択システ
    ム。
  6. 【請求項６】前記ルータ装置の前記制御手段は、前記ソ
    ースアドレスが、自ルータ装置が接続性を確認できてい
    るインターネットサービスプロバイダから受信したネッ
    トワークプレフィクスを持っているソースアドレスでは
    なかった場合に、前記確認手段により接続性が確認でき
    ている前記インターネットサービスプロバイダがその時
    点で存在しないならば、該パケットの転送を行わず、前
    記通信ノード宛に該パケットの転送を行わなかったこと
    を通知するとともに、前記パケットの送信先とすべき他
    のルータ装置を前記通信ノード宛に通知する機能を更に
    具備することを特徴とする請求項１に記載のソースアド
    レス選択システム。
  7. 【請求項７】前記ルータ装置の前記制御手段は、前記ソ
    ースアドレスが、自ルータ装置が接続性を確認できてい
    るインターネットサービスプロバイダから受信したネッ
    トワークプレフィクスを持っているソースアドレスであ
    っても、所定の条件を満たす場合には、前記通信ノード
    宛に該パケットの転送を行わなかったことを通知すると
    ともに、使用すべき前記インターネットサービスプロバ
    イダが提供するネットワークプレフィクスを前記通信ノ
    ード宛に通知する機能を更に具備することを特徴とする
    請求項１に記載のソースアドレス選択システム。
  8. 【請求項８】複数のインターネットサービスプロバイダ
    に接続されるとともに、ローカルネットワークに接続さ
    れ、このローカルネットネットワークに接続された通信
    ノードのパケットを転送するルータ装置において、 前記インターネットサービスプロバイダとの接続性を確
    認する第１の確認手段と、 前記確認手段により接続性が確認できた前記インターネ
    ットサービスプロバイダが提供するネットワークプレフ
    ィクスを受信する第１の受信手段と、 前記受信したネットワークプレフィクスを前記ローカル
    ネットワークに対し通知する通知手段と、 前記通信ノードから受信したパケットが、自ルータ装置
    が接続性を確認できているインターネットサービスプロ
    バイダから受信したネットワークプレフィクスを持つソ
    ースアドレスか否かを確認する第２の確認手段と、 前記ソースアドレスが、自ルータ装置が接続性を確認で
    きているインターネットサービスプロバイダから受信し
    たネットワークプレフィクスを持っているソースアドレ
    スであった場合は、該ネットワークプレフィクスを受信
    したインターネットサービスプロバイダ宛に該パケット
    を転送し、前記ソースアドレスが、自ルータ装置が接続
    性を確認できているインターネットサービスプロバイダ
    から受信したネットワークプレフィクスを持っているソ
    ースアドレスではなかった場合は、該パケットの転送を
    行わず、前記通信ノード宛に該パケットの転送を行わな
    かったことを通知する制御手段とを具備したことを特徴
    とするルータ装置。
  9. 【請求項９】前記制御手段は、前記ソースアドレスが、
    自ルータ装置が接続性を確認できているインターネット
    サービスプロバイダから受信したネットワークプレフィ
    クスを持っているソースアドレスではなかった場合は、
    該パケットの転送を行わず、前記通信ノード宛に該パケ
    ットの転送を行わなかったことを通知するとともに、前
    記確認手段により接続性が確認できた前記インターネッ
    トサービスプロバイダが提供するネットワークプレフィ
    クスを前記通信ノード宛に通知する機能を更に具備する
    ことを特徴とする請求項８に記載のルータ装置。
  10. 【請求項１０】前記制御手段は、前記ソースアドレス
    が、自ルータ装置が接続性を確認できているインターネ
    ットサービスプロバイダから受信したネットワークプレ
    フィクスを持っているソースアドレスではなかった場合
    に、前記確認手段により接続性が確認できている前記イ
    ンターネットサービスプロバイダがその時点で存在しな
    いならば、該パケットの転送を行わず、前記通信ノード
    宛に該パケットの転送を行わなかったことを通知すると
    ともに、前記パケットの送信先とすべき他のルータ装置
    を前記通信ノード宛に通知する機能を更に具備すること
    を特徴とする請求項８に記載のソースアドレス選択シス
    テム。
  11. 【請求項１１】前記ルータ装置の前記制御手段は、前記
    ソースアドレスが、自ルータ装置が接続性を確認できて
    いるインターネットサービスプロバイダから受信したネ
    ットワークプレフィクスを持っているソースアドレスで
    あっても、所定の条件を満たす場合には、前記通信ノー
    ド宛に該パケットの転送を行わなかったことを通知する
    とともに、使用すべき前記インターネットサービスプロ
    バイダが提供するネットワークプレフィクスを前記通信
    ノード宛に通知する機能を更に具備することを特徴とす
    る請求項８に記載のソースアドレス選択システム。
  12. 【請求項１２】複数のインターネットサービスプロバイ
    ダに接続されたルータ装置を介して所望の通信ノードと
    の通信を行う通信ノードにおいて、 前記ルータから、インターネットサービスプロバイダが
    提供するネットワークプレフィクスを受信する受信手段
    と、 前記ネットワークプレフィクスと自通信ノード固有の識
    別子に基づいてネットワークアドレスを生成する生成手
    段と、 パケットを送信する際に前記ネットワークアドレスをソ
    ースアドレスとしてヘッダに付与して送信する送信手段
    とを具備し、 前記送信手段にて送信したパケットに対し前記ルータか
    ら転送を行わなかった通知を受けるとともに接続性が確
    認できた前記インターネットサービスプロバイダのネッ
    トワークプレフィクスの通知を受けた場合には、前記パ
    ケットのソースアドレスを、新たに前記通知を受けたネ
    ットワークプレフィクスと自通信ノード固有の識別子に
    基づいて生成されたネットワークアドレスに変更し、前
    記パケットを再度送信することを特徴とする通信ノー
    ド。
  13. 【請求項１３】前記通信ノードは、送信したパケットに
    対し前記ルータから転送を行わなかった通知を受けると
    ともに接続性が確認できた前記インターネットサービス
    プロバイダのネットワークプレフィクスの通知を受けた
    場合に、該ネットワークプレフィクスに基づく前記ネッ
    トワークアドレスを、当該パケットの再送信についての
    み使用することを特徴と請求項１２に記載のソースアド
    レス選択システム。
  14. 【請求項１４】前記通信ノードは、送信したパケットに
    対し前記ルータから転送を行わなかった通知を受けると
    ともに接続性が確認できた前記インターネットサービス
    プロバイダのネットワークプレフィクスの通知を受けた
    場合に、該ネットワークプレフィクスに基づく前記ネッ
    トワークアドレスを、それが無効になるまで使用するこ
    とを特徴と請求項１２に記載のソースアドレス選択シス
    テム。
  15. 【請求項１５】複数のインターネットサービスプロバイ
    ダに接続されるとともに、ローカルネットワークに接続
    され、このローカルネットネットワークに接続された通
    信ノードのパケットを転送するルータ装置におけるソー
    スアドレス選択方法であって、 前記インターネットサービスプロバイダとの接続性を確
    認し、 接続性が確認できた前記インターネットサービスプロバ
    イダが提供するネットワークプレフィクスを受信し、 前記受信したネットワークプレフィクスを前記ローカル
    ネットワークに対し通知し、 前記通信ノードから受信したパケットが、自ルータ装置
    が接続性を確認できているインターネットサービスプロ
    バイダから受信したネットワークプレフィクスを持つソ
    ースアドレスか否かを確認し、 前記ソースアドレスが、自ルータ装置が接続性を確認で
    きているインターネットサービスプロバイダから受信し
    たネットワークプレフィクスを持っているソースアドレ
    スであった場合は、該ネットワークプレフィクスを受信
    したインターネットサービスプロバイダ宛に該パケット
    を転送し、前記ソースアドレスが、自ルータ装置が接続
    性を確認できているインターネットサービスプロバイダ
    から受信したネットワークプレフィクスを持っているソ
    ースアドレスではなかった場合は、該パケットの転送を
    行わず、前記通信ノード宛に該パケットの転送を行わな
    かったことを通知することを特徴とするソースアドレス
    選択方法。
  16. 【請求項１６】複数のインターネットサービスプロバイ
    ダに接続されるとともに、ローカルネットワークに接続
    され、このローカルネットネットワークに接続された通
    信ノードのパケットを転送するルータ装置としてコンピ
    ュータを機能させるためのプログラムであって、 前記インターネットサービスプロバイダとの接続性を確
    認する第１の確認機能と、 前記確認手段により接続性が確認できた前記インターネ
    ットサービスプロバイダが提供するネットワークプレフ
    ィクスを受信する第１の受信機能と、 前記受信したネットワークプレフィクスを前記ローカル
    ネットワークに対し通知する通知機能と、 前記通信ノードから受信したパケットが、自ルータ装置
    が接続性を確認できているインターネットサービスプロ
    バイダから受信したネットワークプレフィクスを持つソ
    ースアドレスか否かを確認する第２の確認機能と、 前記ソースアドレスが、自ルータ装置が接続性を確認で
    きているインターネットサービスプロバイダから受信し
    たネットワークプレフィクスを持っているソースアドレ
    スであった場合は、該ネットワークプレフィクスを受信
    したインターネットサービスプロバイダ宛に該パケット
    を転送し、前記ソースアドレスが、自ルータ装置が接続
    性を確認できているインターネットサービスプロバイダ
    から受信したネットワークプレフィクスを持っているソ
    ースアドレスではなかった場合は、該パケットの転送を
    行わず、前記通信ノード宛に該パケットの転送を行わな
    かったことを通知する制御機能とをコンピュータに実現
    させるためのプログラム。
  17. 【請求項１７】複数のインターネットサービスプロバイ
    ダに接続されたルータ装置を介して所望の通信ノードと
    の通信を行う通信ノードにおけるソースアドレス選択方
    法であって、 前記ルータから、インターネットサービスプロバイダが
    提供するネットワークプレフィクスを受信するを受信
    し、 前記ネットワークプレフィクスと自通信ノード固有の識
    別子に基づいてネットワークアドレスを生成し、 パケットを送信する際に前記ネットワークアドレスをソ
    ースアドレスとしてヘッダに付与して送信し、 送信した前記パケットに対し前記ルータから転送を行わ
    なかった通知を受けるとともに接続性が確認できた前記
    インターネットサービスプロバイダのネットワークプレ
    フィクスの通知を受けた場合には、前記パケットのソー
    スアドレスを、新たに前記通知を受けたネットワークプ
    レフィクスと自通信ノード固有の識別子に基づいて生成
    されたネットワークアドレスに変更し、前記パケットを
    再度送信することを特徴とする通信ノードにおけるソー
    スアドレス選択方法。
  18. 【請求項１８】複数のインターネットサービスプロバイ
    ダに接続されたルータ装置を介して所望の通信ノードと
    の通信を行う通信ノードとしてコンピュータを機能させ
    るためのプログラムであって、 前記ルータから、インターネットサービスプロバイダが
    提供するネットワークプレフィクスを受信する受信機能
    と、 前記ネットワークプレフィクスと自通信ノード固有の識
    別子に基づいてネットワークアドレスを生成する生成機
    能と、 パケットを送信する際に前記ネットワークアドレスをソ
    ースアドレスとしてヘッダに付与して送信する送信機能
    と、 前記送信機能にて送信したパケットに対し前記ルータか
    ら転送を行わなかった通知を受けるとともに接続性が確
    認できた前記インターネットサービスプロバイダのネッ
    トワークプレフィクスの通知を受けた場合には、前記パ
    ケットのソースアドレスを、新たに前記通知を受けたネ
    ットワークプレフィクスと自通信ノード固有の識別子に
    基づいて生成されたネットワークアドレスに変更し、前
    記パケットを再度送信する機能とをコンピュータに実現
    させるためのプログラム。
  19. 【請求項１９】複数のインターネットサービスプロバイ
    ダに接続されたルータ装置と、このルータに接続された
    通信ノードとを含むソースアドレス選択システムにおけ
    るソースアドレス選択方法であって、 前記ルータ装置は、 前記インターネットサービスプロバイダとの接続性を確
    認し、 前記確認手段により接続性が確認できた前記インターネ
    ットサービスプロバイダが提供するネットワークプレフ
    ィクスを受信し、 前記受信したネットワークプレフィクスを通知し、 前記通信ノードは、 前記ルータから前記ネットワークプレフィクスを受信
    し、 前記ネットワークプレフィクスと自通信ノード固有の識
    別子に基づいてネットワークアドレスを生成し、 パケットを送信する際に前記ネットワークアドレスをソ
    ースアドレスとしてヘッダに付与して送信し、 前記ルータ装置は更に、 前記通信ノードから受信したパケットが、自ルータ装置
    が接続性を確認できているインターネットサービスプロ
    バイダから受信したネットワークプレフィクスを持つソ
    ースアドレスか否かを確認し、 前記ソースアドレスが、自ルータ装置が接続性を確認で
    きているインターネットサービスプロバイダから受信し
    たネットワークプレフィクスを持っているソースアドレ
    スであった場合は、該ネットワークプレフィクスを受信
    したインターネットサービスプロバイダ宛に該パケット
    を転送し、前記ソースアドレスが、自ルータ装置が接続
    性を確認できているインターネットサービスプロバイダ
    から受信したネットワークプレフィクスを持っているソ
    ースアドレスではなかった場合は、該パケットの転送を
    行わず、前記通信ノード宛に該パケットの転送を行わな
    かったことを通知することと特徴とするソースアドレス
    選択方法。
JP2002097652A 2002-03-29 2002-03-29 ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 Expired - Fee Related JP3665622B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2002097652A JP3665622B2 (ja) 2002-03-29 2002-03-29 ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法
EP20030252002 EP1349323B1 (en) 2002-03-29 2003-03-28 Source address selection system suitable for a multi-home environment
CNB031083919A CN1242593C (zh) 2002-03-29 2003-03-28 源地址选择系统、路由器装置、通信节点和源地址选择方法
KR20030019560A KR100693320B1 (ko) 2002-03-29 2003-03-28 소스 어드레스 선택시스템, 라우터장치, 라우터장치로서 컴퓨터를 기능시키기 위한 프로그램을 기록한 컴퓨터 독출가능한 기록매체, 통신노드 및 소스 어드레스 선택방법
DE2003600299 DE60300299T2 (de) 2002-03-29 2003-03-28 System zur Auswahl von Quell-Adressen geeignet für eine Umgebung mit mehreren Heimatnetzen
US10/401,874 US7680949B2 (en) 2002-03-29 2003-03-31 Source address selection scheme suitable for multi-home environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002097652A JP3665622B2 (ja) 2002-03-29 2002-03-29 ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法

Publications (2)

Publication Number Publication Date
JP2003298635A true JP2003298635A (ja) 2003-10-17
JP3665622B2 JP3665622B2 (ja) 2005-06-29

Family

ID=27800582

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002097652A Expired - Fee Related JP3665622B2 (ja) 2002-03-29 2002-03-29 ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法

Country Status (6)

Country Link
US (1) US7680949B2 (ja)
EP (1) EP1349323B1 (ja)
JP (1) JP3665622B2 (ja)
KR (1) KR100693320B1 (ja)
CN (1) CN1242593C (ja)
DE (1) DE60300299T2 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006104202A1 (ja) * 2005-03-29 2006-10-05 Matsushita Electric Industrial Co., Ltd. 通信制御方法及びアドレス管理ノード並びにモバイルノード
JP2007089138A (ja) * 2005-08-24 2007-04-05 Ricoh Co Ltd 通信機器、通信方法および通信プログラム
JP2007288315A (ja) * 2006-04-13 2007-11-01 Nec Corp アドレス管理装置、アドレス管理システムおよびアドレス管理方法
JP2008524911A (ja) * 2004-12-17 2008-07-10 エヌエイチエヌ コーポレーション バス型ネットワーク構造の通信ネットワークシステムにおけるサブシステム間のロードを調節する方法
JP2013214982A (ja) * 2013-06-03 2013-10-17 Brother Ind Ltd アドレス情報提供装置
US8819189B2 (en) 2009-06-29 2014-08-26 Brother Kogyo Kabushiki Kaisha Address information providing device

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100580169B1 (ko) * 2003-06-05 2006-05-15 삼성전자주식회사 복수 ｉｓｐ들을 유동적으로 선택하여 라우팅하는 장치 및방법
JP2004364109A (ja) * 2003-06-06 2004-12-24 Canon Inc テンポラリアドレス通信装置、プログラム、記録媒体、および方法
US20050021782A1 (en) * 2003-06-16 2005-01-27 Malik Dale W. Validating user information prior to switching internet service providers
US20040254991A1 (en) * 2003-06-16 2004-12-16 Malik Dale W. Switching Internet service providers
US20040254976A1 (en) * 2003-06-16 2004-12-16 Malik Dale W. Migrating from an old instant messaging (IM) platform to a new IM platform
US7574524B2 (en) * 2003-09-30 2009-08-11 International Business Machines Corporation Method and system for on-demand allocation of a dynamic network of services
CN100454882C (zh) * 2003-12-19 2009-01-21 华为技术有限公司 多isp局域网的出口选择方法及装置
US7440451B2 (en) * 2004-04-16 2008-10-21 The Boeing Company Global internet protocol prefix number mobility
US20050286490A1 (en) * 2004-06-23 2005-12-29 Inventec Appliances Corporation Method for automatically selecting lowest rate for dialing phone call via wireless telecommunication device
JP2006261768A (ja) * 2005-03-15 2006-09-28 Toshiba Corp 通信装置、通信方法および通信プログラム
US7894433B2 (en) * 2005-08-08 2011-02-22 Cisco Technology, Inc. Default gateway router supplying IP address prefixes ordered for source address selection by host device
US7953868B2 (en) * 2007-01-31 2011-05-31 International Business Machines Corporation Method and system for preventing web crawling detection
EP2048857A1 (en) * 2007-10-12 2009-04-15 PacketFront Systems AB Method of configuring routers using external servers
CN101753419B (zh) * 2008-12-08 2012-08-15 华为技术有限公司 发送数据、转发数据的方法、设备和多地址空间移动网络
JP5638063B2 (ja) * 2010-03-23 2014-12-10 キヤノン株式会社 通信装置、通信装置の制御方法、プログラム
JP5105124B2 (ja) * 2011-02-24 2012-12-19 Ｎｅｃアクセステクニカ株式会社 ルータ装置、プレフィクス管理にもとづくパケット制御方法およびプログラム
US10405365B2 (en) 2015-12-16 2019-09-03 At&T Intellectual Property I, L.P. Method and apparatus for web browsing on multihomed mobile devices
CN107734528B (zh) * 2017-11-03 2021-01-15 Oppo广东移动通信有限公司 无线网络检测方法、装置、存储介质及终端
US10812445B2 (en) * 2018-02-13 2020-10-20 Sling Media Pvt Ltd Cloud access to local network addresses

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5790548A (en) * 1996-04-18 1998-08-04 Bell Atlantic Network Services, Inc. Universal access multimedia data network
AU8995898A (en) * 1998-09-02 2000-03-27 N.C.C. Export Systems 1995 Ltd. Apparatus and methods for connecting a network user to a network service provider
JP3463607B2 (ja) 1999-05-24 2003-11-05 日本電気株式会社 通信ネットワークシステムにおける始点アドレスの選択方法、選択装置および同方法が記録された記録媒体
FI107421B (fi) * 1999-06-28 2001-07-31 Stonesoft Oy Yhteyksien valintamenetelmä
US6603758B1 (en) * 1999-10-01 2003-08-05 Webtv Networks, Inc. System for supporting multiple internet service providers on a single network
AU2001250888A1 (en) * 2000-03-20 2001-10-03 At And T Corp. Service selection in a shared access network using policy routing
US6981055B1 (en) * 2000-08-22 2005-12-27 Internap Network Services Corporation Method and system for optimizing routing through multiple available internet route providers
US20030172170A1 (en) * 2002-03-08 2003-09-11 Johnson Gerald R. Providing multiple ISP access to devices behind NAT
KR100424614B1 (ko) * 2002-04-27 2004-03-27 삼성전자주식회사 인터넷 프로토콜 기반 통신 시스템 및 그의 호스트 주소설정 및 소스 주소 선택 방법
US20040111529A1 (en) * 2002-12-10 2004-06-10 Intel Corporation (A Delaware Corporation) Dynamic host based load balancing of a multihomed network

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008524911A (ja) * 2004-12-17 2008-07-10 エヌエイチエヌ コーポレーション バス型ネットワーク構造の通信ネットワークシステムにおけるサブシステム間のロードを調節する方法
JP4808731B2 (ja) * 2004-12-17 2011-11-02 エヌエイチエヌ コーポレーション 通信ネットワークシステムにおけるサブシステム間のロードを調節する方法
US8260894B2 (en) 2004-12-17 2012-09-04 Nhn Corporation Method for balancing load among subsystems in communication network system of bus network structure
WO2006104202A1 (ja) * 2005-03-29 2006-10-05 Matsushita Electric Industrial Co., Ltd. 通信制御方法及びアドレス管理ノード並びにモバイルノード
JPWO2006104202A1 (ja) * 2005-03-29 2008-09-11 松下電器産業株式会社 通信制御方法及びアドレス管理ノード並びにモバイルノード
US7742396B2 (en) 2005-03-29 2010-06-22 Panasonic Corporation Communication control method, address management node, and mobile node
JP4616882B2 (ja) * 2005-03-29 2011-01-19 パナソニック株式会社 通信制御方法及びアドレス管理ノード並びにモバイルノード
JP2007089138A (ja) * 2005-08-24 2007-04-05 Ricoh Co Ltd 通信機器、通信方法および通信プログラム
JP2007288315A (ja) * 2006-04-13 2007-11-01 Nec Corp アドレス管理装置、アドレス管理システムおよびアドレス管理方法
US8819189B2 (en) 2009-06-29 2014-08-26 Brother Kogyo Kabushiki Kaisha Address information providing device
JP2013214982A (ja) * 2013-06-03 2013-10-17 Brother Ind Ltd アドレス情報提供装置

Also Published As

Publication number Publication date
DE60300299T2 (de) 2006-05-11
CN1242593C (zh) 2006-02-15
EP1349323B1 (en) 2005-02-02
KR100693320B1 (ko) 2007-03-13
DE60300299D1 (de) 2005-03-10
JP3665622B2 (ja) 2005-06-29
US7680949B2 (en) 2010-03-16
EP1349323A1 (en) 2003-10-01
KR20030078770A (ko) 2003-10-08
US20050102415A1 (en) 2005-05-12
CN1455555A (zh) 2003-11-12

Similar Documents

Publication Publication Date Title
JP3665622B2 (ja) ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法
CN113014562B (zh) 用于建立媒体会话的方法和装置
JP4226553B2 (ja) データ通信ネットワークにおけるルーティング
JP4020576B2 (ja) パケット転送方法、移動端末装置及びルータ装置
US7639681B2 (en) System and method for a distributed server for peer-to-peer networks
US7729312B2 (en) Router apparatus, route information distributing method, and communications system
KR100811890B1 (ko) 인터넷 시스템에서 서비스 플로우를 보장하는 애니캐스트라우팅 방법 및 장치
JP2006086800A (ja) ソースアドレスを選択する通信装置
JP2001244957A (ja) Ｔｃｐ終端機能付きｉｐルータ装置および媒体
JP2002281564A (ja) モバイルネットワーク内で一定のサービス品質でルート確立する方法
JP2008510385A (ja) 効率的なｖｐｎサーバインターフェース、アドレス割り当て、及びローカルアドレスドメインとのシグナリングのための方法及び装置
JP2009296084A (ja) マルチパス通信システム
US20120182994A1 (en) Address compatibility in a network device reload
US20140317296A1 (en) Allocating internet protocol (ip) addresses to nodes in communications networks which use integrated is-is
JP2005244366A (ja) ゲートウェイ装置及び移動端末機とｌａｎ間接続方法
KR101410510B1 (ko) Ｓｃｔｐ를 이용한 데이터 전송 방법 및 장치
JP3965201B1 (ja) ネットワーク通信機器および双方向リング型ネットワーク用通信プログラム。
JP2004135108A (ja) 通信制御方法、通信端末、ルータ、通信端末の制御プログラム、およびルータの制御プログラム
JP2005286944A (ja) ネットワーク通信装置及びその通信方法
JP5866811B2 (ja) ネットワーク装置、送信先問合せ方法および送信先問合せプログラム
JP2004248257A (ja) 通信システム及び端末
JP2009231986A (ja) 通信装置
JP2008295082A (ja) ゲートウェイ装置、送信方法、受信方法および情報記録媒体

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20041209

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20041214

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20050329

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050401

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080408

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090408

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100408

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100408

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110408

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130408

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140408

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees