JP4610599B2 - ルータ装置および通信方法 - Google Patents

ルータ装置および通信方法 Download PDF

Info

Publication number
JP4610599B2
JP4610599B2 JP2007278513A JP2007278513A JP4610599B2 JP 4610599 B2 JP4610599 B2 JP 4610599B2 JP 2007278513 A JP2007278513 A JP 2007278513A JP 2007278513 A JP2007278513 A JP 2007278513A JP 4610599 B2 JP4610599 B2 JP 4610599B2
Authority
JP
Japan
Prior art keywords
router
mobile
prefix
network
default route
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007278513A
Other languages
English (en)
Other versions
JP2008035572A (ja
Inventor
俊博 鈴木
創 石田
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.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
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 NTT Docomo Inc filed Critical NTT Docomo Inc
Priority to JP2007278513A priority Critical patent/JP4610599B2/ja
Publication of JP2008035572A publication Critical patent/JP2008035572A/ja
Application granted granted Critical
Publication of JP4610599B2 publication Critical patent/JP4610599B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、IPv6マルチホームネットワークで用いられるルータ装置及びその装置における経路情報の配布方法並びに通信システムに関する。
IPネットワークでのマルチホームとは、企業や大学内ネットワークなどのエンドサイトが、複数のインターネットサービスプロバイダ(ISP)に接続する形態をいい、複数の上流へ接続を持つことで負荷分散や、信頼性向上などを図る技術である。
インターネット技術の標準化を推進する任意団体であるIETFで文書化されたRFC(Request For Comments)2260およびRFC3178では、マルチホームの実現方法の一例が記述されている。
ところで、インターネットプロトコルバージョン6(IPv6)は、従来のIPv4の4倍のビット長を持ち、極めて多数の機器にグローバルなIPアドレスの付与を可能としている。IPv6では、IPv4と異なり、ISPがエンドサイト(ここで、エンドサイトとは、ISPと契約関係を持つエンドユーザ(加入者)のサイトとして定義される、以下、"サイト"と略記)に48ビットのプレフィックスを割り当て、サイトは自サイト内の各LANに64ビットのプレフィックスを割り当てる事になっている。
図7は、IPv6におけるマルチホームの一般例を示す図である。同図に示すように、サイト100には、2つのインターネットサービスプロバイダ(ISP_a110,ISP_b120)と接続されている。サイト100内のホストa50はルータ(図示省略)を経由して、プロバイダISP_a110、ISP_b120と接続されている。
ホストa50は、プロバイダISP_a110、ISP_b120から割り当てられた以下のプレフィックスを持っている。
(1)ISP_a 2002:1000:1000::/48
(2)ISP_b 2002:2000:2000::/48
ここで、"/48"は、IPv6のプレフィックス長を表している。また、16ビット毎に分割され、コロン(:)を使用して16進数で表記されている。
図8は、サイト内のIPv6アドレスの構造を示す図で、
(1)ISPから割り当てられたプレフィックス(48ビット)
(2)サイト内でLANに付与するサブネットID(16ビット)
(3)LAN内で各ホストの区別に使用する識別ビット(64ビット)
で構成される。
したがって、サイト100内のホストa50は、以下の(1)〜(3)に示すように、異なるプレフィックスを持つIPアドレスを複数個持っていることになる(図7参照)。
FEC0:1000:1000:0001:0011:2233:4455:6677
2002:1000:1000:0001:0011:2233:4455:6677
2002:2000:2000:0001:0011:2233:4455:6677
ここで、「FEC0::」で始まるIPアドレスは、サイト管理者が付与するサイトローカルアドレス(「サイト」という一定範囲内で一意なアドレスである)である。
IPv6におけるマルチホーム環境では、ISPがサイトに割り当てるプレフィックスのビット数を48ビットに固定することで、サイトが接続するISPの変更を行った場合に、アドレス変更が最小になるよう配慮されている。
さて、多くのサイトでは、各ルータは、RIPng(RFC2080)やOSPF(RFC2740)などのルーティングプロトコルを使用して、ルーティングテーブルを作成している。この時、サイトの外に向かうパケットは、マルチホームサイトとISPの接続点となるGWルータに送ればよいので、まとめてデフォルトルート(経路情報が見当たらないときに使う汎用の経路)と呼ばれる長さが0ビット(0.0.0.0/0)の経路を用いている。
また、通常のサイト内の経路はリンクに隣接するルータで生成されてサイト内で配布されるのに対し、デフォルトルートはサイトとISPの接続点となるGWルータで生成し、ルーティングプロトコルを用いてサイト内の各ルータに配布される。ルータはパケットを受信すると、宛先アドレスを調べて、対応する経路があれば、つまり宛先がサイト内であれば、その方向ヘパケットを転送する。一方、対応する経路がない場合は、つまり宛先がサイト外であれば、デフォルトルートヘパケットを転送する。
上記のようにサイト内のルーティングでは、ISPと接続するそれぞれのGWルータがデフォルトルートを生成する。現在のIPルーティングプロトコルは、複数のデフォルトルートがある場合に、距離に基づいて経路を決めているため、サイト内からサイト外へのパケットは、送信者に最も近いGWルータへ転送される。
一方で、ISPがサイトから来るパケットのソースアドレスを検査し、ISPが与えたアドレスプレフィックスを使用していない場合にパケットを拒否する侵入フィルタ(イングレスフィルタ)がRFC2267で規定されている。この規定によれば、デフォルトルートに従ってサイト内を転送されたパケットがプレフィックスに対応しないGWルータに送られると侵入フィルタで捨てられてしまうことになる。図9は、このことを説明するための図である。図9中のサイト100内には、ISP_a110との接続ゲートウェイであるGW(ゲートウェイ)ルータa(GWa)51と、該GWルータa51と接続されるルータRa53と、ISP_b120との接続ゲートウェイであるGWルータb(GWb)52と、該GWルータb52と接続されるルータRb54、ルータRa53とGWルータb52と接続されるルータRb54と、ホストa50から構成されている。
ホストa50は、ISP_a110から指定されるプレフィックス2002:1000:1000::/48をソースアドレス(送信元アドレス)として生成(例:アドレスA)し、また、ISP_b120から指定されるプレフィックス2002:2000:2000::/48をソースアドレスとして生成(例:アドレスB)する。すなわち、ホストa50は、アドレスA、Bを持っており、いずれかをソースアドレスとして設定し、パケットを送り出す。
上記のような構成において、例えば、ホストa50からサイト100外へパケットを送る場合、ホストa50から送られたパケットは、ルータRb54でより距離の近いデフォルトルート(ここでは、距離1のデフォルトルート)のGWルータb52に向かって転送される。このときホストa50がソースアドレスにISP_a110から割り当てられたプレフィックスの2002:100:100::/48を使用した場合、このパケットはISP_b120の侵入フィルタで廃棄されてしまう。
このような問題に対して、マルチホームサイトとISP間で人手による交渉を行い、GWルータa51とISP_b120の問、およびGWルータb52とISP_a110の間で静的なIPトンネルを設定し、GWルータa51及びGWルータb52がソースアドレスをチェックし、適切なISPへパケット転送することで、侵入フィルタでのパケット廃棄を防ぐことのできる技術がRFC3178で規定されている(図10参照)。
一方で、ルーティングテーブルによるスイッチング動作の信頼性を向上させるため、ルータ起動時、ポートのリンクアップを契機に、仮のデフォルトルートを自動設定できるルータシステムの技術が開示されている(例えば、特許文献1参照)。
特開2002−359638号公報
しかしながら、上記のRFC3178に示される方法では、ホストa50がサイト外へパケットを送ろうとした場合(ホストb60宛にパケットを送信するケース)、図11に示すように、GWルータb52とISP_a110及びISP_b120間に設定されるIPトンネルを通ってパケットが送られる可能性がある。
すなわち、ホストa50がソースアドレスにISP_a110から割り当てられたプレフィックスを使用してホストb60宛にパケットを送信した場合、ホストa50からのパケットは、宛先までの距離の近いデフォルトルートのGWルータb52に向かってパケットが送り出される。GWルータb52とISP_a110間では、静的なトンネルが設定され、GWルータb52に送られたパケットはISP_b120からISP_a110に設定されたトンネルを通して転送されることになる。
このように従来の方法では、最適な(最短の)経路(同図ではISP_b120→ISP_c130→インターネット200→ホストb60)に比べて冗長な経路が発生するという問題があった。
また、移動ネットワークのようなマルチホームの場合、ISPへの接続ポイントが変わるたびにGWアドレスや、マルチホームサイトのアドレスプレフィックスが変化し、ISPとGW間でのIPトンネルを維持するのは困難である。
さらに、動的に変化したアドレスプレフィックスをサイト内のルータに自動的に通知する方法もない。
本発明は、上記のような問題点に鑑みてなされたもので、その課題とするところは、IPv6におけるマルチホームにおいて冗長な経路をとることなく、パケットの転送効率を向上させることのできるルータ装置及びその装置における経路情報の配布方法並びに通信システムを提供することである。
上記課題を解決するため、本発明は、インターネットサービスプロバイダ(ISP)と接続され、プレフィックスを経路情報として近隣のルータと交換するIPv6マルチホームネットワークにおけるルータ装置であって、前記ISPから割り当てられるプレフィックスと、デフォルトルートと、を関連付けて組にする組形成手段と、前記組形成手段により組にされたプレフィックスと、デフォルトルートをルーティングプロトコルで近隣のルータ装置に配布する組情報配布手段と、を備えることを特徴としている。
また、前記ルータ装置であって、前記プレフィックスの可能ビットと、前記デフォルトルートの可能ビットを経路テーブルの設定内容として設定する経路テーブル設定手段と、前記設定されたプレフィックスの可能ビットと、デフォルトルートの可能ビットを読み取り、その読取結果に基づいて、経路設定を行う経路設定手段と、を備えることを特徴としている。
また、前記ルータ装置であって、前記経路テーブル設定手段は、前記プレフィックスで表記されるアドレスの利用期限を前記経路テーブルに設定するアドレス利用期限設定手段を備えることを特徴としている。
また、前記ルータ装置であって、前記経路テーブル設定手段は、前記デフォルトルートと、前記プレフィックスと、パケットの転送先を前記経路テーブルに設定する転送先設定手段を備えることを特徴としている。
また、前記ルータ装置であって、受信したパケットのプレフィックスを確認し、このプレフィックスがデフォルトルートであれば、前記パケットのソースアドレスの上位所定ビットと、デフォルトルートとプレフィックスの組を比較し、一致したデフォルトルートにパケットを転送するルーティング手段を備えることを特徴としている。
上記本発明によれば、ソースアドレスのプレフィックスごとにデフォルトルートを設定できるようにしたので、ルータは、サイト内で使用できるプレフィックスを知ることができ、プレフィックスに対応するISPヘのパケット転送を行うことが可能となる。これにより、IPトンネルによる冗長な経路を通らずにパケットを転送することができるようになり、パケットの転送効率を向上させることができる。
以上、説明したように、本願発明によれば、ルータ装置は、ソースアドレスのプレフィックスごとにデフォルトルートを設定できるようにしたので、プレフィックスに対応するISPヘのパケット転送が可能となる。したがって、従来問題となっていたIPトンネルによる無駄な経路の転送が回避でき、パケットの転送効率を向上させることができる。
以下で、本発明の良好な実施形態について、図面を参照して説明する。
以下、本発明の実施の形態を図面に基づいて説明する。
(第1の実施形態)
まず、第1の実施形態における通信システムの構成を説明する。
本実施形態に係る通信システムは、図1に示すように、IPv6におけるマルチホームサイト(以下、サイトと略記)10と、このサイト10と接続されるISP(インターネットサービスプロバイダ)_a20、ISP_b30から構成される。
サイト10は、ISP_a20との接続ゲートウェイであるGWルータa(GWa)11と、ISP_b30との接続ゲートウェイであるGWルータb(GWb)12と、GWルータaと接続されるルータRa13と、GWルータbと接続されるルータRb14と、ホスト(IPv6アドレスを持つコンピュータ)Ha15から構成される。
サイト10は、各ISP(ISP_a20、ISP_b30)からそれぞれ48ビットのプレフィックス(=アドレスプレフィックス)が割り当てられる。本例では、ISP_a20から2002:1000:1000::/48のプレフィックスが、ISP_b30から2002:2000:2000::/48のプレフィックスが指定されているものとする。
また、サイト10内の各装置11〜15は、与えられた48ビットのプレフィックスに16ビットのLANを識別するビットと、64ビットの装置を識別するビット(インターフェースID)を追加して、サイト10が接続するISPの数だけ128ビットのグローバルIPv6アドレスを自動生成する。
本実施形態における通信システムでは、GWルータ(GWルータa11及びGWルータb12)は、デフォルトルートとアドレスプレフィックスを対にしてサイト10内でルーティングプロトコルにより近隣ルータに周知する機能を備える。GWルータa11及びGWルータb12は基本的に同機能であるので、以下では、GWルータa11を例にとり、説明を進める。
図2は、本実施形態におけるGWルータa11の概略構成図である。
同図において、このGWルータa11は、ルーティングプロトコル処理部51と、プレフィックス・デフォルトルート組記憶部52と、ルーティングテーブル53から構成される。
プレフィックス・デフォルトルート組記憶部52は、デフォルトルートに対して対応するプレフィックスを一対の組にして記憶する。ルーティングプロトコル処理部51は、デフォルトルートを使用する場合は、プレフィックス・デフォルトルート組記憶部52に記憶されている上記組の情報を参照してパケットのソースアドレスの検査を行い、最も適したデフォルトルートを使用するようにする。また、RFC2461で規定するルータ広告を用いて、プレフィックスを近隣ルータに通知する機能を備える。
ルーティングテーブル53には、RTE(Route Table Entry=経路テーブル項目)が格納され、本実施形態では、該RTEにデフォルトルート可能ビットと、アドレス生成利用可能ビットが設定される。詳細はRTEフォーマットの説明で触れる。
次に、上記のように構成されたGWルータa11の動作について説明する。図3は、GWルータa11での動作を示すフローチャートである。
図3において、ISP_a20に接続するGWルータa11のプレフィックス・デフォルトルート組記憶部52は、ISP_a20がDHCP等のメッセージを用いて通知する48ビットのアドレスプレフィックスを、ルーティングプロトコル処理部51を介して受けとる(ステップS1)。
プレフィックス・デフォルトルート組記憶部52は、受けとったアドレスプレフィックスをデフォルトルートと関連付け、組情報aとして所定のメモリに記憶させる(ステップS2)。このようにして関連付けられたアドレスプレフィックスとデフォルトルートの組情報は、ルーティングプロトコル処理部51に送られ、上記組情報を配布するためのメッセージが近隣のルータに配布(ステップS3)される。
このとき、ルーティングテーブル52のRTEにデフォルトルート利用可能ビットと、アドレス生成利用可能ビットの2つのビットを設定可能とすることで、デフォルトルートの機能とアドレスプレフィックス配布によるアドレス自動設定機能の一方だけで使えるようにすることも可能である。
図4は、RIPng型ルーティングプロトコルのRTEのパケットフォーマットを用いて、上記のデフォルトルート利用可能ビットと、アドレス生成利用可能ビットを表現した場合を示す図である。
同図において、RIPngのRTEのメトリック(Metric)フィールドや経路タグ(Route Tag)フィールドの使用していない値の中から、上記デフォルトルート利用可能及びアドレス生成利用可能を示す特定の値を決め、その値を設定することで、デフォルトルート利用可能ビットと、アドレス生成利用可能ビットを表現することが可能である。
また、同図で示されるように、アドレスプレフィックスに対してアドレスの利用期限や望ましい利用期限(それぞれ32ビット符号無し整数)を指定可能とすることで、RFC2461のルータ広告との整合をとることが可能である。
なお、ルーティングプロトコルで情報を得たルータは、RTEパケットフォーマットのメトリック(一例)の項目を参照し、デフォルトルート利用可能ビットが特定の値を示していれば、当該情報をデフォルトルートとして利用可能な情報と判断し、デフォルトルートと、次の転送先(通常は情報の送信元)と、さらに48ビツトのアドレスプレフィックスをルーティングテーブル53に登録する。なお、通常デフォルトルートは、ルーティングテーブル53上では長さが0のプレフィックスと扱われている。また、デフォルトルートは、対応する48ビットのアドレスプレフィックスが異なる限りいくつでもルーティングテーブル53に登録できるものとする。
このとき、既に同じ48ビットのアドレスプレフィックスのデフォルトルートが登録されている場合は、メトリックあるいはコストが小さい方だけが登録される。
次に、GWルータa11から配布されるアドレスプレフィックスとデフォルトルートの組情報を受けとったルータでの動作を、図5のフローチャートを用いて説明する。
同図において、サイト10内のルータは、パケットを受信(ステップS11)すると、アドレスプレフィックスを確認(ステップS12)し、宛先アドレスに最も長く一致するルーティングテーブルの項目を検索する。デフォルトルートは、長さが0のプレフィックスなので、他に一致するプレフィックスがない場合に最も長く一致する項目として見つかる。
上記の検索で見つかった項目がデフォルトルートでなければ(ステップS12でNO)、通常の方法でパケット転送が行われ(ステップS13)、デフォルトルートであれば(ステップS12でYES)、ルーティングテーブルに登録されている全てのデフォルトルートの中から、ソースアドレスの上位48ビットと一致するデフォルトルートを見つけ出し(ステップS14)、見つけ出されたデフォルトルートを使用してパケットを転送(ステップS15)する。すなわち、各サイト内のルータは、受信したパケットの転送先がデフォルトルート(GWルータへ向かうパケット)であると判断すると、パケットのソースアドレスの上位48ビットと、デフォルトルートとアドレスプレフィックスの対を比較し、一致したデフォルトルートを使用してパケットを転送する。
なお、ここでは48ビットのプレフィックスについて記載しているが、ISPから、他のビット数のプレフィックスをもらった場合であっても原理的に上記同様の動作をさせることが可能である。例えば、あるISPが複数の上位ISPと接続し、それぞれから40ビットのアドレスプレフィックスを得たり、複数のサイトの一部となっている部署が、それぞれのサイト管理者から52ビットのプレフィックスをもらったりするような場合に同様のことが可能である。
また、ルーティングプロトコルで情報を得たルータは、アドレスプレフィックスがアドレス生成に利用可能な情報であれば、このアドレスプレフィックスに基づくグローバルアドレスを生成し、サイト内の装置にグローバルアドレスの生成を促すことができる。例えば、アドレス生成は以下のようにして行うことが可能である。
まず、サイト管理者は、あらかじめサイト内の各リンクにRFC3513で規定するサイトローカルアドレスプレフィツクスを付与する。このアドレスプレフィックスは通常64ビットで、上位48ビットは、16進数でFECO:0000:0000であり、これに続く16ビットはサイト内で重複しないように設定される。
次に、サイト管理者は、ルータの各インターフェースに、接続するリンクのサイトローカルアドレスプレフィツクスを設定し、このプレフィックスをルータ広告でリンク内のホストに通知する。
そして、上記の通知で情報を得たルータは、各インターフェースのサイトローカルアドレスプレフィツクスの上位48ビットを置き換えて、リンク毎の64ビットのアドレスプレフィックスを生成する。その後、サイトローカルアドレスプレフィツクスに追加する形で、生成されたアドレスプレフィックスをルータ広告でリンク内のホストに通知する。
ところで、ルーティングプロトコルには、経路を取り消す手段が備えられている。例えば、RIPngの場合、メトリックに16以上の値を設定することで、経路が取り消される。これと同様の手段を用いることで、上記のアドレスプレフィックスとデフォルトルートの関連付けられた組情報を消去することができる。例えば、情報の消去を意味する情報が送られてきた場合に、ルータやホストは対応するルーティングテーブルの項目の消去や、対応する各リンクのプレフィックスの消去を行う。
また、サイト内の装置はRFC2462やRFC3041で規定されるルータ広告に基づくアドレス自動生成により、それぞれのIPv6アドレスを生成し、生成されたアドレスでの通信が可能となる。サイト内の装置は、新しいアドレスプレフィックスが追加されたルータ広告を受信すると、アドレスを自動生成し、追加する。これにより、ホストは、複数のIPv6アドレスを持つことになるので、サイト外のホストと通信を行う場合、どのアドレスを使用するか決定する必要がある。RFC3484は、複数のアドレスからどのソースアドレスを選択するかの方法を示しているが、他の方法を用いることも可能である。
また、ホストaは、RFC3484で記述されている以外に、以下の方法でソースアドレスの優先度を決定できる。
(1)それぞれのアドレスをソースアドレスとして、宛先ホストに対して遅延時間測定試験(ping)を行い、より早く応答が帰ってきた方を選択する。
(2)過去の通信履歴を保持し、転送成績のよいアドレスを優先して使用する。
以上説明したように、本実施形態では、デフォルトルートとアドレスプレフィックスを組にした経路情報がGWルータから下位(近隣)のルータに配布される。これにより、下位のルータは、デフォルトルートとプレフィックスの対応関係および、サイト内で使用できるプレフィックスを知ることができる。
また、下位のルータは、パケットのソースアドレスを見てデフォルトルートを選択するので、ソースアドレスがISP_aのプレフィックスに基づく場合は、サイト外へのパケットをISP_a経由で転送し、ソースアドレスがISP_bのプレフィックスに基づく場合は、サイト外へのパケットをISP_b経由で転送する。すなわち、ホストでのソースアドレスの選択を適切に行うことで、プレフィックスに対応するISPヘパケットが転送されるようになり、IPトンネルによる無駄な経路を通らずにパケットを転送することができ、パケットの転送効率の向上させることができる。
(第2の実施形態)
図6は、第2の実施形態における通信システムの構成を示す図である。
本実施形態に係る通信システムは、図6に示すように、コアネットワーク300内に複数のアクセスノード(ここでは、AR:Access Router(アクセスルータ)という)ARa310〜ARc330と、移動管理ルータAGR#a340とを備え、モバイルノード(MN:Mobile Node)a210と複数のMRa211〜MRc(移動ルータ)213によって構成される移動ネットワーク200が、ARa310と接続する状態から、ARb320と接続する状態に移動(ハンドオフ)している。また、本実施形態では、MNa210から送信されたパケットは、移動管理ルータAGR#a340を介して、コアネットワーク300と接続される通信相手CN(Corresponding Node)400宛に転送される。
ここで、移動管理ルータAGR#a340は、ロケーション固定なホームエージェントを介したパケット転送路のように冗長構成になってしまうことがないように構成されたパケット転送経路上に設けられている。
本実施形態において、移動ネットワーク200はMRa211及びMRb212を介してコアネットワーク300と接続されているマルチホーム状態であり、移動ネットワーク200内部には、MRc213も存在する形態である。MRc213には、各MNに割り当てるプレフィックス(prefix)がMRa211及びMRb212からルーティングプロトコルおよびルータ広告により提供され、各MNに2つのIPra(共通情報)を割り当てる。このとき、同時にデフォルトルート情報も提供される。
同図に示すように、コアネットワーク300、移動ネットワーク200及びMNa210には、アドレス変換を行うためのアドレス変換テーブル(ルーティングテーブル)が備えられる。同図中、○印は、アドレス変換ポイントを表し、□印は、ハンドオフ時に変更されるIPra(共通情報)を表している。
次に、図6の例において、MNa210からパケットを送信する場合と、MNa210の属する移動ネットワーク200がハンドオフする場合の動作について説明する。
(MNa210からパケットを送信する場合の動作)
図6の例において、MNa210からパケットを送信する場合、MRc213にてソースアドレスもIPraに変更するが、この変更したアドレスがMRa211から割り当てられたものであればMRa211経由で、MRb212から割当てたれたものであればMRb212経由でコアネットワーク300にパケットを転送することになる。これは、プレフィックスと同時にデフォルトルートを提供することで実現することが可能である。
(MNa210の属する移動ネットワーク500がハンドオフする場合の動作)
上記の状態を維持したまま移動ネットワーク200がハンドオフした際には、必要最小限の共通部分のみを各制御ポイントにて更新することでハンドオフが実現可能である。例えば、IPraARa(MRa/MRc)#MNaとは、ARa310からMRa211に割り当てられたプレフィックスから、階層的にMRc213に割り当てられたプレフィックスに従ったMNa210用のアドレスを示しており、ハンドオフが発生すると、IPraARb(MRa/MRc)#MNaのように、MRa211に割り当てられたプレフィックスは変更されるが、それ以降の階層部分は不変になるようにアドレッシングする。これにより、最小限の変更のみでハンドオフを実現することができる(同図点線参照)。
上述したように、MRa211とMRb212によるマルチ接続を行う移動ネットワーク200は、接続点の移動に伴い、複数のプレフィックスの追加と削除を繰り返しながら移動する。このような場合に、移動ネットワーク200内でプレフィックスを把握しておく必要があるが、本実施形態では、MRc213が、MRa211及びMRb212からプレフィックスの通知を受け、ルーティングテーブル上で管理する。これにより、移動ネットワーク200内の各MRにプレフィックスが周知されるようになり、移動ネットワーク200と接続点がハンドオフにより切り替っても、移動ネットワーク200内のプレフィックスをすみやかに、かつ適切に変更することができる。
また、移動ネットワーク200と接続ポイント間にIPトンネルがないので、移動ネットワーク200のハンドオフにより、接続ポイントの接続が変化した場合であっても、IPトンネルの再設定が必要ないという効果を奏す。
上記実施形態は、本発明をIP2(社団法人 電子情報通信学会 信学技報 Vol.103 No.201 NS−2003−58記載の移動ネットワークをサポートするネットワークシステム)に適用した態様を例示したが、モバイルIPにも本発明を適用することが可能である。
上記実施例において、プレフィックス・デフォルトルート組記憶部52の機能が組形成手段に対応し、ルーティングプロトコル処理部51の機能が組情報配布手段、ルーティング手段に対応する。ルーティングプロトコル処理部51とルーティングテーブル53の連携処理機能が経路設定手段、経路テーブル設定手段、アドレス利用期限設定手段、転送先設定手段に対応する。
また、第2の実施形態におけるルータMRc213の機能がプレフィックス変更手段に対応し、ゲートウェイに位置するMRa211及びMRb212の機能が配布手段に対応する。
以上、説明したように、本願発明によれば、ルータ装置は、ソースアドレスのプレフィックスごとにデフォルトルートを設定できるようにしたので、プレフィックスに対応するISPヘのパケット転送が可能となる。したがって、従来問題となっていたIPトンネルによる無駄な経路の転送が回避でき、パケットの転送効率を向上させることができる。
第1の実施の形態に係る経路情報の配布方法が適用される通信システムの構成図である。 本実施形態におけるGWルータaの概略構成図である。 本実施形態におけるGWルータaでの動作を示すフローチャートである。 RIPng型ルーティングプロトコルのRTEのパケットフォーマットを示す図である。 GWルータaから配布されるアドレスプレフィックスとデフォルトルートの組情報を受けとったルータでの動作を示すフローチャートである。 第2の実施形態における通信システムの構成を示す図である。 IPv6におけるマルチホームの実現例を示す図である。 サイト内のIPv6アドレスの構造を示す図である。 ISPの侵入フィルタでパケットが廃棄される原理を説明するための図である。 侵入フィルタでのパケット廃棄を防ぐことのできる技術を説明するための図である。 IPv6におけるマルチホームにおいて、冗長な経路でパケットが転送される原理を説明するための図である。
符号の説明
10、100 サイト
11、61 GWルータa(GWa)
12、62 GWルータa(GWa)
13、63 ルータRa
14、64 ルータRb
15、50 ホストHa
20、110 ISP_a(インターネットサービスプロバイダa)
30、120 ISP_b(インターネットサービスプロバイダb)
130 ISP_c(インターネットサービスプロバイダc)
40、200 インターネット
51 ルーティングプロトコル処理部
52 プレフィックス・デフォルトルート組記憶部
53 ルーティングテーブル
70 宛先ホストb
200 移動ネットワーク
210 MNa(モバイルノードa)
211〜213 MRa〜c(移動ルータa〜c)
300 コアネットワーク
310〜330 ARa〜ARc(アクセスルータa〜c)
340 AGR#a(移動管理ルータ)
400 CN(コレスポンデントノード)

Claims (5)

  1. コアネットワーク内の所定ノードに接続され、動的に移動する移動ネットワーク内で使用されるルータ装置であって、
    前記コアネットワークとの接続点に位置する第1の移動ルータから配布された、前記第1の移動ルータが生成する第1のデフォルトルートと、前記コアネットワークから前記第1の移動ルータに割り当てられたプレフィックスとを対にした第1の組情報と、前記コアネットワークとの接続点に位置する第2の移動ルータから配布された、前記第2の移動ルータが生成する第2のデフォルトルートと、前記コアネットワークから前記第2の移動ルータに割り当てられたプレフィックスとを対にした第2の組情報とを管理するルーティングテーブルと、
    前記移動ネットワークが移動し、接続点が切り替わる場合に、前記コアネットワークから前記第1の移動ルータおよび第2の移動ルータの各々を介して当該ルータ装置に割り当てられたプレフィックスに従って前記移動ネットワーク内の移動通信端末宛に階層的に割り当てられたアドレスのうち、前記コアネットワークから前記第1の移動ルータおよび第2の移動ルータの各々に割り当てられたプレフィックス部分のみを前記ルーティングテーブル上で変更するプレフィックス変更手段と
    を備えることを特徴とするルータ装置。
  2. 前記移動ネットワークは、モバイルIPネットワークであることを特徴とする請求項1に記載のルータ装置。
  3. 前記移動ネットワークは、IPv6マルチホームネットワークであることを特徴とする請求項1に記載のルータ装置。
  4. 前記移動通信端末からパケットを受信したときに、前記パケットが前記第1の移動ルータに割り当てられた前記第1のプリフィックスを含む場合は、前記ルーティングテーブルにしたがって、前記第1のデフォルトルートで前記パケットを前記コアネットワークに転送する転送先設定手段、
    をさらに備えることを特徴とする請求項1に記載のルータ装置。
  5. コアネットワーク内の所定ノードに接続され、動的に移動する移動ネットワークにおける通信方法であって、
    前記コアネットワークから前記移動ネットワークの接続点に位置する第1の移動ルータに第1のプレフィックスを割り当て、前記コアネットワークから前記移動ネットワークの接続点に位置する第2の移動ルータに第2のプレフィックスを割り当て、
    前記第1の移動ルータにおいて第1のデフォルトルートを生成し、前記第1のデフォルトルートと前記第1のプレフィックスを組にした第1の組情報を、前記移動ネットワーク内のルータ装置に配布し、
    前記第2の移動ルータにおいて第2のデフォルトルートを生成し、前記第2のデフォルトルートと前記第2のプレフィックスを組にした第2の組情報を、前記移動ネットワーク内の前記ルータ装置に配布し、
    前記コアネットワークから、前記第1の移動ルータと前記ルータ装置を介して前記移動ネットワーク内の移動通信端末に第1の階層的なアドレスを割り当てるとともに前記第2の移動ルータと前記ルータ装置を介して、前記移移動通信端末に第2の階層的なアドレスを割り当て、
    前記ルータ装置において前記第1の組情報および前記第2の組情報を管理し、前記移動ネットワークが移動して前記接続点が切り替わる場合に、前記移動ネットワーク内の前記ルータ装置において、前記移動通信端末に割り当てられた前記第1の階層的なアドレスのうち、前記コアネットワークから前記第1の移動ルータに割り当てられたプレフィックス部分と、前記第2の階層的なアドレスのうち、前記第2の移動ルータに割り当てられたプレフィックス部分のみを変更する、
    ことを特徴とする通信方法。
JP2007278513A 2007-10-26 2007-10-26 ルータ装置および通信方法 Expired - Fee Related JP4610599B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007278513A JP4610599B2 (ja) 2007-10-26 2007-10-26 ルータ装置および通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007278513A JP4610599B2 (ja) 2007-10-26 2007-10-26 ルータ装置および通信方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2003209144A Division JP2005072685A (ja) 2003-08-27 2003-08-27 ルータ装置及びその装置における経路情報の配布方法並びに通信システム

Publications (2)

Publication Number Publication Date
JP2008035572A JP2008035572A (ja) 2008-02-14
JP4610599B2 true JP4610599B2 (ja) 2011-01-12

Family

ID=39124420

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007278513A Expired - Fee Related JP4610599B2 (ja) 2007-10-26 2007-10-26 ルータ装置および通信方法

Country Status (1)

Country Link
JP (1) JP4610599B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5279633B2 (ja) * 2009-06-29 2013-09-04 キヤノン株式会社 通信装置及びその制御方法、並びにプログラム
JP5611422B2 (ja) * 2013-06-27 2014-10-22 キヤノン株式会社 通信装置、通信装置の制御方法、プログラム、及びシステム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000341330A (ja) * 1999-05-27 2000-12-08 Ntt Docomo Inc 通信プロトコル代行処理方法、通信プロトコル代行処理装置、及び通信プロトコル代行処理サービス装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000341330A (ja) * 1999-05-27 2000-12-08 Ntt Docomo Inc 通信プロトコル代行処理方法、通信プロトコル代行処理装置、及び通信プロトコル代行処理サービス装置

Also Published As

Publication number Publication date
JP2008035572A (ja) 2008-02-14

Similar Documents

Publication Publication Date Title
JP2005072685A (ja) ルータ装置及びその装置における経路情報の配布方法並びに通信システム
US7123599B2 (en) Mobile communication system
JP5495926B2 (ja) プロキシ・モバイルipネットワークにおけるプライベート・アドレッシングの方法
EP1473900B1 (en) Wireless local area network system capable of supporting host mobility and an operation method therefor
EP1011241B1 (en) Wireless access to packet-based networks
KR100930269B1 (ko) 이동성 관리에서 vpn 지원을 위한 방법 및 장치
US7760666B2 (en) Method of generating and managing connection identifiers for supporting multicast for each group in IPv6-based wireless network and network interface using the method
KR100531623B1 (ko) NAT-PT 환경에서의 모바일 IPv6를 이용한 통신방법 및 이를 저장한 기록매체
CA2422715A1 (en) Methods and apparatus for supporting mobility within a radio access network
KR20030084471A (ko) 인터넷 프로토콜 기반 통신 시스템 및 그의 호스트 주소설정 및 소스 주소 선택 방법
JP2003283578A (ja) プロトコル変換方法及び装置
US20110216680A1 (en) Method And Apparatus For Use In A Communications Network
JP2009529267A (ja) 移動通信システムでの移動ノード用のデフォルト・ルータの高速構成
US20080112414A1 (en) Mobility management system and method for mobile internet protocol network
JPWO2009066438A1 (ja) アドレス割り当て方法、アドレス割り当てシステム、モバイルノード及び代理ノード
JP2004112727A (ja) 移動通信制御システム、移動通信制御方法、これらに用いて好適なルータ装置、サーバ装置及びデータ構造
JP2008510440A (ja) モバイルIPv6ノードとIPv4通信パートナーとの間の通信を実施する方法
JP2004260463A (ja) ルータ装置、通信装置、ネットワークアドレス管理システム、ネットワークアドレス管理方法及びネットワークアドレス管理プログラム
EP2482585B1 (en) Method and system for realizing terminal handover
Ishiyama et al. An analysis of mobility handling in LIN6
JP4519720B2 (ja) ハンドオーバ方法
JP4610599B2 (ja) ルータ装置および通信方法
JP3589089B2 (ja) 通信プロトコル代行処理方法、通信プロトコル代行処理装置、及び通信プロトコル代行処理サービス装置
JP4938842B2 (ja) ルーティングマネージャの階層構造
JP3928443B2 (ja) 移動体通信システム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100126

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100304

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100831

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100922

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: 20101012

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101012

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

Free format text: PAYMENT UNTIL: 20131022

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees