JP2002185520A - 移動端末対応ルータおよびホームエージェント・ルータ - Google Patents
移動端末対応ルータおよびホームエージェント・ルータInfo
- Publication number
- JP2002185520A JP2002185520A JP2000377628A JP2000377628A JP2002185520A JP 2002185520 A JP2002185520 A JP 2002185520A JP 2000377628 A JP2000377628 A JP 2000377628A JP 2000377628 A JP2000377628 A JP 2000377628A JP 2002185520 A JP2002185520 A JP 2002185520A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- address
- router
- mobile terminal
- home
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/08—Mobility data transfer
- H04W8/082—Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/34—Modification of an existing route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/005—Data network PoA devices
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
Abstract
し、移動端末の現在アドレス更新に要する時間を短縮し
て転送ルートの切替えを高速化すると共に、同プロトコ
ルをサポートしない端末については、毎回ホームエージ
ェントを経由しない転送ルートを提供する。 【解決手段】 相手端末CNが記憶すべき移動端末MN
の現在アドレスを、該相手端末に代わって、記憶する記
憶手段11と、移動端末MNのホームアドレス宛てに送
信されたパケットを受信したとき、記憶手段11を参照
し、現在アドレス宛てに変換してそのパケットを送信す
る転送手段12と、を備える移動端末対応ルータ10で
ある。
Description
動端末のうち少なくとも移動端末をサポートするパケッ
ト通信システムを構成する移動端末対応ルータおよびホ
ームエージェント・ルータに関する。
トワーク上の接続位置を変えても通信を行うことを可能
とする移動端末対応のプロトコルとして、米国の標準化
団体IETF(Internet Engineering Task Force )に
おいて、Mobile IP(文献〔1〕RFC200
2)が標準化されている(注:本明細書中にて引用する
各文献は巻末にまとめて掲記する)。
端末数の急増により、IPアドレスの枯渇の問題が深刻
化しており、より多くのIPアドレスを使用することが
可能なIPv6(文献〔2〕RFC2460)を使用し
たネットワークへの移行が本格化している。このため、
これまでのIPv4ネットワークにおけるMobile
IPだけでなく、IPv6ネットワーク上での端末の
移動をサポートするプロトコルとしてMobile I
Pv6(文献〔3〕)の標準化が進められており、上記
IETFにおいてRFC(Request For Comments)化の
ための審議が行われている。
Mobile−IPv6では、ネットワークの構成や端
末の位置によっては、移動端末(Mobile Node :以下、
MNとも称す)が移動した際に行われる転送ルートの切
替えに時間がかかる場合がある。このような場合、移動
端末MNの移動前に接続していたネットワークに他の端
末からパケットが送られるとパケット損失(ロス)が発
生し、通信品質が劣化する、という問題がある。
は、移動端末MNのみならず、この移動端末MNと通信
を行う相手端末(Correspondent Node:以下、CNとも
称す)でもMobile−IPv6のプロトコルが動作
している必要がある。したがってもしこの相手端末CN
においてMobile−IPv6プロトコルをサポート
していない場合には、MNへ送信すべきパケットは、通
常MNが接続しているホームリンクに連係するホームエ
ージェント(Home Agent:以下、HAとも称す)を経由
してMNへ転送される。このため、転送遅延の増大やH
Aにおけるトラフィックの集中等が起こる可能性があ
る、という問題がある。なお、これらの問題は後に図を
参照して詳しく説明する。
転送ルートの切替えに要する時間を短縮してパケット転
送ルートの切替えを高速化し、また、IPv6プロトコ
ルをサポートしてない相手端末CNから移動端末MNへ
のパケット転送についてはその転送ルートを短縮化し
て、通信品質の劣化の原因となるパケット損失、転送遅
延の増大、ホームエージェントHAにおけるトラフィッ
クの集中等を抑制することのできる、移動端末対応ルー
タならびにホームエージェント・ルータを提供すること
を目的とするものである。
端末対応ルータの基本構成を示す図である。本図におい
て、本発明に係る移動端末対応ルータ10は、図示する
記憶手段11と、転送手段12を含んで構成される。ま
ずこの移動端末対応ルータ10は、少なくとも移動端末
MNのパケット通信をサポートするネットワークを構成
する移動端末対応ルータである。したがってこのネット
ワークは固定端末のパケット通信もサポート可能であ
る。
信の相手端末CNが記憶すべき移動端末MNの現在アド
レスを、この相手端末CNに代わって、記憶する。ま
た、転送手段12は、相手端末CNから移動端末MNの
ホームアドレス宛てに送信されたパケットを受信したと
き、記憶手段11を参照し、そのホームアドレス宛てを
現在アドレス宛てに変換してそのパケットを送信する。
ルータの基本構成を示す図である。このホームエージェ
ント・ルータ20は、図1の移動端末対応ルータ10と
同様に、少なくとも移動端末MNの通信をサポートする
ネットワークを構成するホームエージェント・ルータで
ある。ここに、受信手段21は、移動端末MNの移動に
より現在アドレスを変更したことに伴いホームエージェ
ント・ルータに対し当該アドレスの更新を通知するため
に送信される更新通知情報を受信する。
通知情報を受信したときに、その更新後の現在アドレス
を、ネットワークを構成する他のルータに送信する。こ
のホームエージェント・ルータ20は、通常のホームエ
ージェントとしての機能に加え、本発明に基づき、上記
の記憶手段11に上記現在アドレスを通知する機能を併
せ持つものである。ただし、その現在アドレスを通知す
る機能はこれに限るものではない(後述)。
末CNが本来実行すべき、移動端末MNの移動後のアド
レス更新操作を、この移動端末MNにこの相手端末CN
より近くに位置する移動端末対応ルータ10が先取りし
て行ってしまうので、前述した転送ルートの切替えに要
する時間は短縮され、したがって問題となっているパケ
ット損失は大幅に減少する。
CNから移動端末MNに送信されるパケットは、当該移
動端末対応ルータ10を経由してホームエージェントH
Aに至り、ここでMNの現在アドレスに書き換えられて
送信先のMNに送られる、という従来の手順は不要とな
り、上記パケットはその移動端末対応ルータ10から、
HAを介さずに、直接送信先のMNに送られるので、問
題となっているパケットの転送遅延やHAでのトラフィ
ックの集中は大幅に改善される。
拠する場合のみならず、このIPv6プロトコル相当の
プロトコルに準拠する場合にも適用可能であるが、以下
の説明は主として現状のIPv6プロトコルに準拠する
場合を例にとって行う。そこでまず、本発明の実施例を
説明する前に、本発明の理解を容易にするため従来の移
動端末対応ルータ10について説明しておく。また上記
ホームエージェント・ルータ20に相当する従来のホー
ムエージェントHAについても併せて説明しておく。
図(その1)であり、図4は同図(その2)である。な
お、これら図3および図4は、相手端末CNにおいてM
obile−IPv6プロトコルをサポートしている場
合の例を示す。まず図3を参照すると、前提として、通
常はホームリンクであるネットワーク1に接続している
移動端末MN(ホームアドレス=A)は、ネットワーク
3に移動したものとする。すると、このネットワーク3
において新たにアドレスBを生成する。この生成したア
ドレスBをCoA(Care-of Address )として、ホーム
エージェントHAおよび相手端末CN1に図示しないル
ートで通知する。HAおよびCN1は、その通知に基づ
き、Binding Cache (MNのホームアドレスと、通知さ
れたMNのCoAおよびその有効時間等を記憶する情
報:文献〔3〕で定義)を生成する。なお、CN1は上
述のとおりMobile−IPv6をサポートしている
端末である。つまりBinding Update(B.U.)を受信
・処理して、Binding Cache を生成する能力を持つ端末
である。
としてアドレスCを生成する。 〔3〕:MNは、HAおよびCN1にそれぞれBinding
Update(CoAを通知するパケット:文献〔3〕で定
義)を図中のB.U.として送信し、CoA(=アドレ
スC)を通知する。
Update(B.U.)をCN1が受信するよりも前に、C
N1からMN宛てに、パケットP1,P2,P3を送信
したものとする。このとき、パケットの宛先アドレスで
あるCoAはまだBとなったままである。 〔5〕:HAおよびCN1はそれぞれ、MNから〔3〕
にて送信されたBinding Update(B.U.)を受信し、
Binding Cache として記憶しているMNのCoAを、ア
ドレスBからアドレスCへ更新する(図中の、A→B,
A→C)。続いてHAおよびCN1はそれぞれ、Bindin
g Acknowledgement (Binding Update受信の確認を通知
するためのパケット。文献〔3〕で定義)を、図示しな
いルートでMNへ送信する。
てCN1より送信されたパケットP1,P2,P3は、
MNの移動前におけるネットワーク3のCoA(=アド
レスB)へ送信されている。このため、移動後のMNに
受信されることはなく、パケット損失(ロス)となる。
しかしCoAの更新後にCN1から送信されるパケット
P4は、ネットワーク4へ移動後のMNのCoA(=ア
ドレスC)へ送信され、ルータR1→R2→R4を経由
してMNにて受信される。
ットワーク5,6の2つのネットワークが存在するが、
さらに多くのネットワークを経由するような場合には、
MNからBinding Updateが送信されてから、CN1でこ
れを受信しCoAが更新されるまでの所要時間(上記の
例では図3の〔3〕〜〔5〕)がより一層長くなること
が予想される。このような場合、図3の〔4〕で示した
ように、CN1がMNの移動前のCoA(=アドレス
B)宛てに多くのパケットを転送してしまうことにな
り、より多くのパケット損失(ロス)が発生する可能性
がある。
表す図(その1)であり、図6は同図(その2)であ
る。なお、これら図5および図6は、相手端末CNにお
いてMobile−IPv6プロトコルをサポートして
いない場合の例を示す。まず図5を参照すると、前提と
して、通常はホームリンクであるネットワーク1に接続
している移動端末MN(ホームアドレス=A)は、ネッ
トワーク3に移動したものとする。すると、このネット
ワーク3において新たにアドレスBを生成する。この生
成したアドレスBをCoAとして、HAおよびCN2に
通知する。この通知により、HAではBinding Cache を
生成するが、CN2はMobile−IPv6をサポー
トしていないためにBinding Cache が生成されていない
状態、つまり通知されたCoA(=アドレスB)を記憶
していない状態にある。
としてアドレスCを生成する。 〔3〕:MNは、HAおよびCN2にそれぞれBinding
Updateを図中のB.U.として送信し、CoA(=アド
レスC)を通知する。ただし通信の相手端末CNがMo
bile−IPv6をサポートしている/いない(CN
1/CN2)に拘わらず、MNはCN(CN1/CN
2)へBinding Updateを送信する場合がある。
(=A)宛てに送信されたパケットP5,P6は、ネッ
トワーク2内を転送される。ただしMobile−IP
v6をサポートしていない相手端末は、常にMNのホー
ムアドレスA宛てにパケットを送信する。 〔5〕:〔3〕にてHAおよびCN2はそれぞれ、MN
から送信されたBinding Update(B.U.)を受信し
て、HAは、Binding Cache として記憶しているMNに
ついてのCoAをBからCへ更新(図中の、A→B,A
→C)するが、CN2は、Mobile−IPv6プロ
トコルをサポートしていないため、受信したBinding Up
dateを処理することができない。つまりCN2には、M
NのCoA(=アドレスA)は記憶されない。
いルートでBinding Acknowledgement をMNへ返送す
る。次に図6を参照する。図5の〔4〕にて、MNのホ
ームアドレス(=A)宛てに転送されていたパケットP
5,P6は、HAによってインタセプト(代理応答)さ
れる。すなわちこのHAにて、そのパケットはIP−i
n−IPカプセル化され(図のP6)、MNのCoA
(=アドレスC)へトンネリングされる。
アドレスB)へトンネリングされたため、MNに受信さ
れることはなく、パケット損失(ロス)となる。一方パ
ケットP6は、更新後のCoA(=アドレスC)へトン
ネリングされ、MNに受信される。以降、CN2からM
NのホームアドレスA宛てに送信されたパケットP7
は、ルータR1→R2→HA→R4を経由してMNにて
受信される。つまり、Mobile−IPv6をサポー
トしていない相手端末から送信されるパケットは、受信
者であるMNが、そのホームリンクから外部リンクへ移
動中である場合には、必ずHAを経由してMNへ転送さ
れることになる。これはパケット転送遅延の増大やHA
へのパケットトラフィックの集中等を引き起こすことに
なる。また、MNとHAが離れている場合には、図3お
よび図4で示した場合と同様に、HAにおけるCoAの
更新に時間がかかることから、HAから、MNの移動前
のCoA(=アドレスB)にパケットをトンネリングし
てしまい、パケット損失(ロス)が発生する。
基づく実施例を以下に詳述する。本発明に基づく実施例
は、移動端末MNのCoA(Care-of Address )の更新
に要する時間を短縮してパケット転送ルートの切替えを
高速化するものであり、また、Mobile−IPv6
をサポートしていない相手端末CNからMNへのパケッ
ト転送ルートを、毎回ホームエージェントHAを経由し
ないように、最適化するものである。これにより、通信
品質の劣化の原因となるパケット転送遅延やパケット損
失(ロス)の増大を防ぐことを可能とする。
10のさらに具体的な構成を示す図である。この構成は
図1の構成にさらに登録手段13を付加したものであ
る。この登録手段13は、移動端末MNの移動により現
在アドレスを変更したことに伴い通信の相手端末CNに
対し当該アドレスの更新を通知するために送信される更
新通知情報を受信したとき、この受信をトリガとして、
記憶手段11におけるホームアドレスと現在アドレスと
の対応関係を新たに登録するものである。
・ルータ20のさらに具体的な構成を示す図である。こ
の構成は図2の構成にさらに登録手段23を付加したも
のである。ネットワーク2は、移動端末MNをこのホー
ムアドレスにおいて収容するホームエージェント・ルー
タ20を含んでおり、登録手段23は、移動端末MNの
移動により現在アドレスを変更したことに伴いホームエ
ージェント・ルータ20に対し当該アドレスの更新を通
知するために送信される更新通知情報を受信したときに
ホームエージェント・ルータ20からの当該更新アドレ
スの転送をトリガとして、記憶手段11におけるホーム
アドレスと現在アドレスとの対応関係を新たに登録する
ものである。
0を含むパケット通信システムの具体例を示す図(その
1)であり、図10は同図(その2)である。まず図9
を参照すると、本図中の10および20が、それぞれ本
発明に係る移動端末対応ルータ(図のR2)およびホー
ムエージェント・ルータ(図のHA)である。以下、R
2およびHAと略称する。
から送信されるBinding Update(B.U.)を、相手端
末CN1またはCN2の代わりに受信する(本図の
〔1〕)。あるいは、ホームエージェント・ルータHA
がR2へアドレスの更新を通知し、R2がこれを受信す
る(本図の〔2〕)。〔1〕または〔2〕により、MN
についてのCoA(現在アドレス)を記憶する(本図の
〔3〕)。
e−IPv6をサポートしているが、MNからのBindin
g Update(B.U.)はR2で受信され、CN1には到
達しない。したがって、CN1はMNがホームリンクの
外へ移動中であることを知ることがない。このためMo
bile−IPv6をサポートしていないCN2のみな
らずCN1も、MNのホームアドレス(=アドレスA)
宛てにパケットを送信する。
1/CN2)へのBinding Update(B.U.)の送信、
およびHAまたはCNからMNへのBinding Acknowledg
ement の送信のためには、MNとHA、およびMNとC
Nのそれぞれの間で、認証ヘッダ(文献〔4〕RFC2
402)による認証を行うための情報を持っている必要
がある。この情報は、セキュリティパラメータインデッ
クス、認証アルゴリズム、認証鍵等からなる。
からBinding Updateが送信されないため、本図のルータ
R2は〔1〕のBinding UpdateからCoAを更新するこ
とができない。このような場合には、図の〔2〕に示す
ように、HAからR2に対してMNのCoAを通知する
ことが有効である。なおこのようなHAからR2へのC
oAの通知は、Mobile−IPv6プロトコルでは
定義されていない。
は、MNのCoA(=アドレスC)を記憶しているの
で、CN1またはCN2から送信されたパケット(宛先
はMNのホームアドレスA)をR2で受信した場合に、
R2はそのパケットをMNのホームアドレスAに向けて
転送するのではなく、MNのCoA(=アドレスC)へ
向けてダイレクトに転送することができる。
は、ルータ10およびルータ20)により、MNのCo
Aの更新に要する時間を短縮し、MNへのパケット転送
ルートの切替えを高速化することができる。またMob
ile−IPv6をサポートしていない相手端末CN2
からMNへのパケット送信があったときは、その転送ル
ートを、HAを毎回経由しないように、最適化する。こ
れにより、通信品質の劣化の原因となるパケット転送遅
延やパケット損失(ロス)の増大を防ぐことが可能にな
る。
を説明する。図11は図9および図10のシステムの第
1の詳細例を示す図(その1)であり、図12は同図
(その2)である。まず前提として、図11および図1
2に示されるルータ(R1,R2,R3,R4)および
端末(MN,CN1)についての詳しい説明を以下に示
す。
ルをサポートする移動端末である。通常はそのMNのホ
ームリンクであるネットワーク1に接続され、ホームア
ドレスAを使用して通信を行う。ホームリンク(ネット
ワーク1)以外のネットワークに移動した場合は、移動
先のネットワークにおいて使用するCoA(Care-of Ad
dress)を生成する。さらにMobile−IPv6プ
ロトコルにより、HA20およびCN1に対し、Bindin
g Updateを送信する。またこのMNは、HA20との認
証情報であるSA1と、CN1との認証情報であるSA
2とをそれぞれ保持しているものとする。SA1および
2は、Security Association 1および2である。
ワーク1において、Mobile−IPv6プロトコル
でのホームエージェント機能を提供するルータあるいは
サーバである。ここの例では、HA20のアドレスをD
とする。またMNとの認証情報であるSA1を保持して
いるものとする。
U.)をHAが受信すると、HAはBinding Cache を生
成しこれを保持する。Binding Cache を生成した場合に
は、HAはMNに対し、Binding Acknowledgement
(B.A.)を返送する。このBinding Cache の有効時
間内に、HAはMN宛てに送信されたパケットをインタ
セプトし、MNのCoA(=アドレスB)へ向けてその
パケットをIP−in−IPカプセル化して転送する。
り、Mobile−IPv6プロトコルをサポートす
る。ここの例では、CN1のアドレスをEとする。また
MNとの認証情報であるSA2を保持しているものとす
る。MNから送信されたBinding Updateを受信した場合
には、上記のHAと同様に、Binding Cache を生成し、
これを保持する。このBinding Cache の有効時間内に、
MN宛てにパケットを送信する際は、IPv6拡張ヘッ
ダであるルーティングオプションヘッダを使用して、M
NのCoA(=アドレスB)にダイレクトにそのパケッ
トを転送する。ただしこれはIPv6での通常の場合の
動作であり、本発明では、ルータR2が、CN1に代わ
って、Binding Updateの受信と、CoA(=アドレス
B)へのパケットの転送とを行う。
タである。 <R2>通常のIPv6ルータの機能に加え、上述した
本発明の機能を有する移動端末対応ルータである。ここ
の例では、CN1と同様に、MNとの認証情報であるS
A2を保持しているものとする。
ーク1から、ネットワーク3へ移動したものとする。 〔2〕:MNは、ネットワーク3において、ルータR3
がネットワーク3の内部にブロードキャストするRouter
Advertisementに含まれるネットワークプレフィクス
(どのネットワークであるかを示す固定のコード)の情
報を受信して、今自分(MN)がネットワーク1の外部
へ移動したことを認識すると共に、CoA(ここではア
ドレスBとする)を生成する。
teを送信し、CoA(=アドレスB)を現在アドレスと
して通知する。 〔4〕:HA20は、その受信したBinding Updateに基
づき、MNのホームアドレス(=A)とCoA(=B)
等とを、Binding Cache として記憶する。そして、MN
に対して図示しないルートでBinding Acknowledgement
を返送する。
送信するものとする。CN1は、MNがネットワーク3
へ向かって移動中であることを未だ知らないため、パケ
ットはMNのホームアドレス(=A)宛てに送信され
る。このパケットはルータR1→R2を経由して、MN
のホームアドレス(=A)であるネットワーク1へ転送
される。このときHA20はそのパケットをインタセプ
トし、このパケットをIP−in−IPカプセル化し
て、移動中のMNへ転送する。この時のパケットの内容
を図で示す。
ケットのフォーマットを示す図である。CN1が送信し
たオリジナルのパケット(宛先アドレス=A、送信元ア
ドレス=E)に加え、HAにてもう一つのIPヘッダ
(宛先アドレス=B、送信元アドレス=D)が付加され
ている。これがIP−in−IPカプセル化されたパケ
ットである。
−in−IPカプセル化されたパケットを受信すると、
オリジナルのパケットの送信元であるCN1に対してBi
nding Update(B.U.)を送信する。この時のパケッ
トの内容を図で示す。図14は図11中の〔6〕で転送
されるパケットのフォーマットを示す図である。
(宛先アドレス=E、送信元アドレス=B)に、Bindin
g Updateオプション(Binding Update Option :文献
〔3〕)、Home Addressオプション(Home Address Opt
ion :文献〔3〕)、および認証ヘッダ(Authenticati
on Header :文献〔4〕)を付加した形のパケットとな
る。
オプションは、IPv6拡張ヘッダ(IPv6 Extension H
eader :文献〔2〕)の1つである宛先オプションヘッ
ダ(Destination Options Header. 文献〔2〕)として
定義されており、それぞれOption Type の値は、Bindin
g Updateオプション=C6(16進)、Home Addressオ
プション=C9(16進)である。
v6プロトコルに基づいた通常の動作である。 〔7〕:上記〔6〕にて、MNからCN1宛てに送信さ
れた図14のBindingUpdate(B.U.)を、本発明に
係るルータ(R2)10が受信する。R2では、受信し
たB.U.パケットの内容のチェックを行う。
ンが含まれていることを、R2の登録手段13(図7)
で検出し、このパケットがMobile−IPv6のBi
nding Update信号であると判断する。次に、図14のI
Pv6ヘッダの宛先アドレスがCN1のアドレス(=
E)であることから、このBinding Update信号がCN1
へ送信されたものであると判断する。
を使用して、図14の認証ヘッダのチェックを行う。そ
して、その認証ヘッダのチェックが成功した場合には、
当該パケットに含まれる図14のHome Addressオプショ
ンから得られる、MNのホームアドレス(=A)と、I
Pv6ヘッダの送信元アドレスであるMNのCoA(=
アドレスB)と、Binding Updateオプションに含まれる
有効時間等の情報とから、Binding Cache を生成し、こ
れをR2の記憶手段11(図7)に記憶する。
Binding Updateオプションにおいて、Acknowledge ビッ
ト(いわゆるAビット)がセットされている場合には、
R2は転送手段12(図7)により、MNへBinding Ac
knowledgement (B.A.)を返送する。(もしそのAc
knowledge (A)ビットがセットされていないならば、
Binding Acknowledgement を返送しなくても良い)。こ
の時のパケットの内容を図で示す。
ケットのフォーマットを示す図である。Binding Acknow
ledgement (B.A.)は、図15に示すように、IP
v6ヘッダ(宛先アドレス=B、送信元アドレス=E)
に、ルーティングヘッダ(Routing Header:文献
〔2〕)(宛先アドレス=A)、Binding Acknowledgem
ent オプション(Binding Acknowledgement Option:文
献〔3〕)および認証ヘッダを付加した形のパケットと
なる。
IPv6拡張ヘッダの1つである宛先オプションヘッダ
として定義されており、Option Type の値は、07(1
6進)である。ルーティングヘッダは、宛先オプション
ヘッダと同様に、IPv6拡張ヘッダの1つとして定義
されており、転送中のIPv6パケットの宛先アドレス
を定めるものである。
と、相手端末CNがIPv6プロトコルをサポートする
端末CN1であるとき、図7の現在アドレスはCare-of
Address であり、また図7の更新通知情報はBinding Up
date信号である。これらをCN1に代わって受信する。
このとき図7の転送手段12は、移動端末MNとの間で
定めた認証情報を保持すると共に、Binding Update信号
の送信元である移動端末MNに対しこのBinding Update
信号の受信に対するBinding Acknowledgement 信号を返
送する。これらをCN1に代わって実行する。
ものとする。このときR2は上記〔7〕にて、MNから
CN1へのBinding Updateを受信し保持しているため、
CN1はMNがネットワーク3に移動していることを知
らない。したがってCN1は通常通りMNのホームアド
レス(=A)を宛先としてそのパケットを送信する。
ットをR2が受信すると、R2の転送手段12(図7)
は、宛先アドレスのチェックを行う。すなわち、記憶手
段11(図7)を参照して、宛先アドレスであるMNの
ホームアドレス(=A)についてのBinding Cache が存
在し、かつ有効時間内である場合には、R2は、受信し
たそのパケットをMNのホームアドレス(=A)ではな
く、CoA(=アドレスB)へ転送する。R2がMNの
CoA(=アドレスB)へ転送するパケットの形態に
は、次の(I)および(II)がある。
ーティングヘッダを使用する。 (II)IP−in−IPカプセル化を行う。 また、CN1が送信したパケットに認証ヘッダが含まれ
ているかどうかにより、以下の1)および2)のような
処理を行うことができる。 1)ルーティングヘッダを使用する場合 この場合の説明のために、図12の他に、図16〜図1
9も参照する。
ケット(第1例)のフォーマットを示す図であり、図1
7は図12中の〔10〕で転送されるパケット(第1
例)のフォーマットを示す図であり、図18は図12中
の
トを示す図であり、図19は図12中の〔10〕で転送
されるパケット(第2例)のフォーマットを示す図であ
る。
い場合のパケット、図18は認証ヘッダが有る場合のパ
ケット、図17はIPv6ルーティングヘッダを用いる
場合で、かつ、認証ヘッダが無い場合のパケット、図1
9はIPv6ルーティングヘッダを用いる場合で、か
つ、認証ヘッダが有る場合のパケット、である。
と、 1−a)CN1が送信したパケットが、図16のよう
に、認証ヘッダを含んでいない場合には、R2の転送手
段12(図7)からMNのCoA(=アドレスB)への
転送パケットは、図17のようになる。図17のパケッ
トはIPv6ヘッダ(宛先アドレス=B、送信元アドレ
ス=E)に、ルーティングヘッダ(宛先アドレス=A)
を付加した形のパケットとなる。
18のように認証ヘッダを含んでいる場合には、R2の
転送手段12(図7)からMNのCoA(=アドレス
B)への転送パケットは、図19のようになる。つま
り、IPv6ヘッダ(宛先アドレス=B、送信元アドレ
ス=E)に、ルーティングヘッダ(宛先アドレス=A)
と認証ヘッダを付加した形のパケットとなる。
ていたものをそのまま付加するのではなく、CN1とM
Nとの間の認証情報SA2を使用して、R2が再計算し
たものを付加する。この理由は次のとおりである。認証
ヘッダにおける認証データの計算には通常IPパケット
の内容そのものを使用している。このため、図18のパ
ケットの内容を使用して計算した認証データは、図19
のようにR2によってパケットの内容が変更された場合
の認証データとは異なったものとなり、認証が確立しな
いから、受信端末であるMNにおいて、〔10〕のパケ
ットが廃棄されてしまう。このため、図19の変更され
たパケットの内容を用いて、R2が改めて認証データの
計算(再計算)をし直す必要がある。これが図19にお
ける、認証ヘッダ(再計算)の意味である。
合 この場合の説明のために、図12の他に、図20および
図21も参照する。図20は図12中の〔10〕で転送
されるパケット(第3例)で認証ヘッダ無しのときのフ
ォーマットを示す図であり、図21は図20のパケット
(第3例)で認証ヘッダ有りのときのフォーマットを示
す図である。
Pカプセル化を行い、かつ、認証ヘッダが無い場合のパ
ケット、図21はIP−in−IPカプセル化を行い、
かつ、認証ヘッダが有る場合のパケット、である。
すると、 2−a)CN1が送信したパケットが、前述した図16
のように認証ヘッダを含んでいない場合には、R2の転
送手段12(図7)からMNのCoA(=アドレスB)
への転送パケットは、図20のようになる。図20のパ
ケットは、図16のパケットそのものに、転送手段12
により、新たにIPv6ヘッダ(宛先アドレス=B、送
信元アドレス=E)を付加した形のパケットとなる。
18のように認証ヘッダを含んでいる場合には、R2の
転送手段12から、MNのCoA(=アドレスB)への
転送パケットは、図21のようになる。図21のパケッ
トは、上記の2−a)の場合と同様に、図18のパケッ
トそのものに、転送手段12により、新たにIPv6ヘ
ッダ(宛先アドレス=B、送信元アドレス=E)を付加
した形のパケットとなる。この場合、上記の1−b)で
行ったような認証ヘッダにおける認証データの再計算
(図19)は不要である。R2によるパケットの内容の
変更はないからである。
6ヘッダの送信元アドレスを、オリジナルパケット
いる理由を以下に述べる。Mobile−IPv6プロ
トコルでは、MNがIP−in−IPカプセル化された
パケットを受信した際に、そのパケットに対していくつ
かの適合性判定を行い、適合した場合には、IP−in
−IPカプセル化されたオリジナルパケットの送信元へ
Binding Update(B.U.)を送信することが定義され
ている。通常は、まだMNのCoAを知らないCN1か
ら、MNのホームアドレス(=A)へ送信されたパケッ
トをHAがインタセプトしてIP−in−IPカプセル
化し、MNに転送する。このカプセル化パケットを受信
したMNがCNへBinding Updateを送信する。これは上
記の定義に基づいた動作である。
のように、R2からMNへのパケットを転送する際、上
記の2−a)および2−b)に示すように、IP−in
−IPカプセル化したパケットを用いると、このIP−
in−IPカプセル化パケットを受信する度に、MNか
らCN1へのBinding Updateが送信されることになる。
そうすると、特にパケットが連続して送信されたような
場合には、Binding Updateも同様に連続して送信されて
しまう。この問題は、上記のMNにおけるIP−in−
IPカプセル化パケットの受信の際に行われる適合性判
定において、不適合となるようなパケットに意図的にす
ることで解決できる。
として、「オリジナルパケットのIPv6ヘッダの送信
元アドレスと、IP−in−IPカプセル化IPv6ヘ
ッダの送信元アドレスとが異なっていること」という条
件がある(文献〔3〕10.8.Sending Binding Updates t
o Correspondent Nodes参照)。このことを逆に利用し
て、R2からMNへパケットを送信する際にIP−in
−IPカプセル化パケットを使用する場合に、図21に
示すように、IP−in−IPカプセル化パケットのヘ
ッダにおける送信元アドレスを、意図的にオリジナルパ
ケットの送信元アドレスと同じCN1のアドレス(=
E)にしてしまう。MNにおいて適合性判定の条件を満
たさなくなるから、上記のようにBinding Updateを連続
して送信するという問題はなくなる。ただし、一番最初
のパケットだけについては、R2の登録手段13(図
7)を起動するために、そのBinding UpdateをR2に送
信しなければならない。このための対策は種々考えられ
るが、その1つを図39も参照しながら後に説明する。
と、転送手段12は、相手端末CNからのパケットを移
動端末MNに転送するに際し、このパケット内に、ホー
ムアドレス(=A)を記述したIPv6ルーティングヘ
ッダ(図17、図19)を形成するようにする。また、
転送手段12は、相手端末CNからのパケットを移動端
末MNに転送するに際し、現在アドレス(CoA)を含
むIPv6ヘッダによりこのパケットをIP−in−I
Pカプセル化して(図20、図21)、転送するように
する。
2の詳細例を示す図である。前述の第1の詳細例(図1
1および図12)は、本発明に係る移動端末対応ルータ
(R2)10に重点を置いたものであるが、第2の詳細
例(図22)は、本発明に係るホームエージェント・ル
ータ(HA)20に重点を置く。まず前提として、図2
2に示されるホームエージェント・ルータ(HA)20
およびR2と端末(MN,CN2)とについての説明を
以下に示す。
と同じ。ただし、MNとCN2はこれらの間の認証情報
(前述のSA2相当)を保持していない。<HA20>
第1の詳細例に示す通常のMobile−IPv6 H
A機能に加え、本発明に基づく機能を有するホームエー
ジェント・ルータである。ここの例ではR2との認証情
報SA3を保持しているものとする。
るが、Mobile−IPv6プロトコルをサポートし
ていない。ここの例では、CN2のアドレスをFとす
る。MN宛てにパケットを送信する際は、常に宛先アド
レスをMNのホームアドレス(=A)として通常のパケ
ットの転送を行う。
タである。 <R2>通常のIPv6ルータの機能に加え、前述した
本発明に基づく機能を有するルータである。ここの例で
は、R2のアドレスをGとする。またR2は、第1の詳
細例に示したCN1との認証情報SA2は保持しておら
ず、HA20との間の認証情報SA3を保持しているも
のとする。
〔4〕と同じである。 〔5〕:CN2はMNへ向けてパケットを送信する。こ
こではCN2はMobile−IPv6をサポートして
いないため、そのパケットは常にMNのホームアドレス
(=A)宛てに送信される。
bile−IPv6プロトコルに基づいた通常の動作で
ある。 〔6〕:上記〔5〕にて送信されたパケットをR2が受
信すると、R2の登録手段13(図17)は、この受信
したパケットの宛先アドレス(=A)をチェックする。
nding Cache を記憶していない場合には、R2はパケッ
トをIP−in−IPカプセル化してHAへ転送する。
この時のパケットの内容を図で示す。図23は図22中
の〔6〕で転送されるパケットのフォーマットを示す図
である。
パケットに、新たにもう1つのIPv6パケットヘッダ
(宛先アドレス=A、送信元であるR2のアドレス=
G)を付加した形のパケットとなる。 〔7〕:上記〔6〕にて、R2から転送されたパケット
をHA20が受信する。このHAでは登録手段23(図
8)にて、その受信したパケットのチェックを行う。す
なわちHAはまずIP−in−IPカプセル化されてい
るパケットであることを検出する。
に示す外側のIPv6パケットヘッダの内側にあるオリ
ジナルパケット(上記〔5〕にてCN2から送信された
パケット)のチェックを行い、宛先となるMNのホーム
アドレス(=A)を検出する。次に、HA20は登録手
段23にて、MNについてのBinding Cache の存在およ
び有効時間をチェックする。このチェックによりMNに
ついてのBinding Cache が存在し、かつそれが有効時間
内であると判定された場合には、HAはこのオリジナル
パケットを、MNのCoA(=アドレスB)宛てに再カ
プセル化して転送する。この時のパケットの内容を図で
示す。
ケットのフォーマットを示す図である。CN2が送信し
たオリジナルのパケット〔5〕(宛先アドレス=A、送
信元アドレス=F)に加え、もう1つのIPv6ヘッダ
(宛先アドレス=B、送信元のHAのアドレス=D)
が、HAにより付加される。
て受信した図23に示すパケットの外側のIPv6パケ
ットヘッダに含まれる送信元アドレス(G)をチェック
し、このIP−in−IPカプセル化パケットの送信元
(=アドレスG)であるR2に対して、アドレス更新通
知手段22(図8)により、MNのCoA(=アドレス
B)を通知する。
コルとは独立した手順であるから、どのような手法でC
oAをR2に通知しても良い。ここの例ではMobil
e−IPv6のBinding Updateを利用して通知すること
とする。この時のパケットの内容を図で示す。図25は
図22中の〔8〕で転送されるパケットのフォーマット
を示す図である。すなわち、HA20からR2へCoA
を通知するパケットの内容を示す。
IPv6ヘッダ(宛先アドレス=G、送信元アドレス=
D)に、Binding Updateオプション、Home Addressオプ
ション、認証ヘッダ、およびCoAオプションを付加し
た形のパケットとなる。Binding Updateオプション、Ho
me Addressオプション、認証ヘッダは、第1の詳細例
(図11)の〔6〕で示したものと同様に、Mobil
e−IPv6およびIPSECで定義されているもので
ある。
HA20とR2との間の認証情報SA3と本パケットの
内容とを使用して計算により算出される。またCoAオ
プションは、Mobile−IPv6で定義されていな
いため、新規オプションとして定義することができる。
この新規オプションの内容を図で示す。
のフォーマットの一例を示す図である。本図において、
CoAオプションはBinding Updateオプションと同様
に、IPv6拡張ヘッダの1つである宛先オプションヘ
ッダとして、IPv6ヘッダ(図25)の宛先アドレス
で示された受信側端末(ここではルータR2)の登録手
段13(図7)によって処理される。
Type (8ビット)には、このオプションがCoAアド
レスであることを示す数値が入る。Option Length (8
ビット)には、本オプションの長さ(Option Type およ
びOption Length を除く)を8オクテット単位で示した
数値が入る。Care-of Address (128ビット)には、
通知すべきMNのCoA(ここではアドレスB)が入
る。
て、HA20から送信されたCoA通知パケットをR2
が受信手段13(図7)で受信する。R2では、受信し
たパケットの内容のチェックを登録手段13(図7)に
て行う。まずBinding Updateオプションが含まれている
ことを検出すると、このパケットがCoA通知パケット
であると判断する。
ドレスが自分のアドレス(=G)であり、送信元アドレ
スがHAのアドレス(D)であって、このパケットがH
Aから自分自身(R2)へ送信されたものであると判断
する。次に、HAとの間の認証情報SA3に基づき、認
証ヘッダ(図25)のチェックを行う。そして、この認
証ヘッダのチェックに成功した場合には、該パケットに
含まれるHome Addressオプション(図25)から得られ
るMNのホームアドレス(=A)と、CoAオプション
から得られるMNのCoA(=アドレスB)と、Bindin
g Updateオプションに含まれる有効時間等の情報を、Bi
nding Cache として、記憶手段11(図7)に記憶す
る。
6)が含まれるため、IPv6ヘッダの送信元アドレス
(=D)からMNのCoAを得るのではなく、CoAオ
プション(=アドレスB)からCoAを得ることにな
る。このCoAオプションに隣接する図25の認証ヘッ
ダの計算は、送信・受信側それぞれにおいて、パケット
の送信元アドレス(Mobile IPv6メッセージ
ではHome Addressオプションに格納されたアドレス)と
その送信元との間で確立しているSAを使用して行う。
HAからR2へMNのCoAを通知する場合、通常のM
obile−IPv6のB.U.メッセージフォーマッ
トに基づいたパケット、例えば〔F〕〔B〕〔B.
U.〕〔A〕〔認証〕、で通知しようとしても、もとも
とCN−MNについてのSAが無いため、HAは認証ヘ
ッダを計算して付与することができない。
し、HAとR2の間でSA3を確立しておくことで、H
AとR2との間で認証ヘッダを計算し、HAとR2にお
いて通知パケットをチェックすることが可能となる。以
上の動作により、R2においてMNについてのBinding
Cache が生成され、以降CN2からMNへ送信されるパ
ケットは、第1の詳細例(図12)の〔10〕と同様
に、HAを経由せずに、CN2→R1→R2→R3→M
Nの経路で転送される。
はMNについての認証情報を保持していないとしている
ので、CN2からMNへ送信されるパケットに認証ヘッ
ダが含まれることはない。この場合、パケットは、第1
の詳細例における上記〔10〕に示す1−a)または2
−a)の方法で転送される。もし、CN2がMNについ
ての認証情報を保持していると仮定すると、CN2から
MNへ送信されるパケットに認証ヘッダが含まれること
になる。このように認証ヘッダが含まれる場合は、その
パケットは、第1の詳細例における上記〔10〕に示す
1−b)または2−b)の方法で転送されることにな
る。
様に、MNからCN2へBinding Updateが送信されるこ
とになる。この場合は、第1の詳細例における上記
〔7〕〜〔10〕と同様に、R2がCN2宛てのBindin
g Updateを受信して、R2からMNのCoAにダイレク
トにパケットを転送することになる。以上述べたことの
ポイントを図8との関連で要約すると、ホームエージェ
ント・ルータ(HA)と連係する他のルータ(R2)
が、IPv6プロトコルをサポートする移動端末端末M
Nと通信可能な移動体端末対応ルータであるとき、アド
レス更新通知手段22(図8)は、現在アドレスを示す
Care-of Address (CoA)を、IPv6拡張ヘッダの
1つである宛先オプション(図25、図26)としてそ
の移動体端末対応ルータ(R2)に通知するようにす
る。
に通知されるパケット〔8〕(図22)内には認証ヘッ
ダ(図25)を含み、この認証ヘッダ内の認証データ
は、ホームエージェント・ルータ(HA)と該移動体端
末対応ルータ(R2)との間で定めた認証情報SA3と
当該パケットの内容とを用いた計算による算出結果から
なるようにしている。
(R2)10およびホームエージェント・ルータ(H
A)20の詳細例について補足説明する。図7および図
8に示すこれらのルータ(R2)10および(HA)2
0は、実際にはソフトウェアによって実現可能である
が、これを機能ブロックで構成した場合について以下に
説明する。
第1の詳細例(図11、図12)と第2の詳細例(図2
2)とを1つに統合して表現し直す。図27は図11,
12および22で示すシステムを1つに統合して表す図
である。本図において、MN1(ホームアドレス=A
1)は図11、図12のMNに相当し、MN2(ホーム
アドレス=A2)は、図22のMNに相当する。このた
め、ホームアドレスやセキュリティ情報も再度定義し直
している。後述する説明に現れるテーブルの内容(図2
9、図30)や、パケットおよび処理ルートは、全て図
27に示す設定値に準じている。
ティ情報SA12を確立しているため、MN1は移動時
にHAへのB.U.11以外にCNへのB.U.12も
送信する。なおB.U.12は、CNの代わりにR2が
受信し、R2からMN1へB.A.12を送信する。ま
た、MN2とCNはセキュリティ情報を確立していない
ため、MN2は移動時にHAへのB.U.21のみ送信
する。
A3を確立しており、HAはR2へMN2のCoA通知
であるB.U.3を送信する。なお、CNのSA12
は、R2が代わりに持っているので、CNは持たなくて
も良い。図28は本発明に係るルータ(10,20)の
機能ブロックを表す図である。
ルータ(HA)20も実質的に同一の機能ブロックで表
すことができる。ただし、テーブルの内容が、ルータ1
0とルータ20とで相違する(後述)。また、パケット
の上りの処理と下りの処理は共通である。モバイルテー
ブル31は、MNのCoAの記憶や最適化ルートでパケ
ットを転送するために必要な情報を格納したテーブルで
ある。なお、このテーブルの内容例は図29および図3
0に示す。
タが持つルーティングテーブルと同様であり、パケット
のルーティング決定を行う際に参照する情報を格納した
テーブルである。なお、このテーブルの内容例は図31
および図32に示す。プロトコル処理部手段33は、図
示するとおり、Mobile−IPv6処理部331
と、ルーティング処理部332と、ルーティングプロト
コル処理部333と、その他のプロトコル処理部334
と、を含んでなり、プロトコル(Mobile IPv
6,ICMP等)に応じてパケットの内容を理解し、こ
の理解に基づいてメッセージの処理を行う。
定を行い、プロトコル処理手段33へプロトコル処理を
引き渡す。またプロトコル処理手段33からの指示に基
づきパケットの修正・生成、及び送信部への入力を行
う。受信部35は、ネットワークをなす伝送路からの信
号を受信し、フレームの組み立てや、データの正常性の
チェック等を行う。
送出パケットを伝送フレームに載せて上記伝送路に送出
する。図29はルータ(R2)10についてのモバイル
テーブルの内容の一例を示す図である。図28のモバイ
ルテーブル31は、ルータ(R2)10についてはこの
ような内容を記憶する。
消去される。また、実際には1つのCNについて複数の
MNについての情報が記憶されていてもよい。モバイル
テーブル−MN情報について見ると、この情報は、HA
から通知されてキャッシュされる。そして有効時間が切
れると、MNホームアドレス、CoA、有効時間の全て
のエントリが消去される。
バイルテーブルの内容の一例を示す図である。図28の
モバイルテーブル31は、ルータ(HA)20について
はこのような内容を記憶する。モバイルテーブル−MN
情報は、MNの各CoAについての有効時間が切れると
消去される。
ーティングテーブルの内容の一例を示す図である。図2
8のルーティングテーブル32は、ルータ(R2)10
についてはこのような内容を記憶する。図32はルータ
(HA)20についてのルーティングテーブルの内容の
一例を示す図である。
(HA)20についてはこのような内容を記憶する。図
33はルータ(R2)としてのパケット処理部34(図
28)の処理を示すフローチャート(その1)であり、
図34は同フローチャート(その2)である。
ート上における各パケット(P1〜P4)の流れを示す
図であり、図36は図35における各パケット(P1〜
P4)のフォーマットを示す図である。図33について
説明を付け加えると、ステップS19の「判定1」は、
前の判定で一致したCNアドレスについて、CN情報の
MNホームアドレスと受信パケットの宛先アドレスが一
致するか否か、の判定を行う。
ルート41において、MN1のCoA無しのとき、受信
パケットをそのままHAへ送信する。そしてHAは、図
39に示すパケットP5の処理を行う。また図35のル
ート42において、MN2のCoA無しのとき、受信パ
ケットをカプセル化してHAへ送信し、HAは図39に
示すパケットP6の処理を行う。
処理部34(図28)の処理を示すフローチャート(そ
の1)であり、図38は同フローチャート(その2)で
ある。図39は図37および図38のフローチャート上
における各パケット(P5〜P8)の流れを示す図であ
り、図40は図39における各パケット(P5〜P8)
のフォーマットを示す図である。
ップS39の「判定2」は、送信元アドレスが通知先ル
ータ情報のルータアドレスと一致するか否か、かつ、カ
プセル化ヘッダ(外側)の宛先アドレスとオリジナルヘ
ッダ(内側)の宛先アドレスとが一致するか否か、の判
定を行う。また図39について説明を付け加えると、ル
ート43において、HAがMN1のCoA宛てにカプセ
ル化して転送したパケットをMN1が受信すると、MN
1はCNへB.U12を送信する。
5のP2のパケットをMN2のCoAへ転送するととも
に、図35のP4のパケットをR2へ送信する。さらに
ルート45においては、HAはMN1およびMN2から
のB.U.を受信し、B.A.を返信する。これは通常
の登録動作である。以上がルータ10および20につい
ての詳細な説明であるが、その中の2−b)の終わり
に、「MNにおいて適合性判定の条件を満たさなくなる
と、BindingUpdateを連続して送信するという問題はな
くなる」としている。ただし、一番最初のパケットだけ
については、登録手段13(図17)を起動するため
に、そのBinding UpdateをR2に送信する対策を講じな
ければならない。これについては図39も参照しながら
後述する、としたので、ここで説明する。
2にてCoAが記憶されていないため、図39のP5ま
たはP6のパケットの形でMNのホームアドレスへ送信
される。そしてHAがこのパケットを受信し、これを図
13のようにカプセル化して、HAからMNへ送信す
る。この時、カプセル化したパケットの外側ヘッダの送
信元アドレスはHAのアドレスであり、図20や図21
に示すパケットのように、R2がパケットをIP−in
−IPカプセル化する場合と異なる。MNが前述のMN
1、すなわちCNとのセキュリティ情報を持つMNの場
合、HA経由のカプセル化パケットを受信した際には、
2−b)で記述した適合性判定の条件を満たすため、C
NへB.U.を送信することができる。
付記のとおりである。 (付記1)少なくとも移動端末のパケット通信をサポー
トするネットワークを構成する移動端末対応ルータであ
って、前記パケット通信の相手端末が記憶すべき前記移
動端末の現在アドレスを、該相手端末に代わって、記憶
する記憶手段と、前記相手端末から前記移動端末のホー
ムアドレス宛てに送信されたパケットを受信したとき、
前記記憶手段を参照し、該ホームアドレス宛てを前記現
在アドレス宛てに変換して該パケットを送信する転送手
段と、を具備することを特徴とする移動端末対応ルー
タ。 (付記2)前記移動端末の移動により前記現在アドレス
を変更したことに伴い前記通信の相手端末に対し当該ア
ドレスの更新を通知するために送信される更新通知情報
を受信したとき、この受信をトリガとして、前記記憶手
段における前記ホームアドレスと前記現在アドレスとの
対応関係を新たに登録する登録手段を有することを特徴
とする付記1に記載の移動端末対応ルータ。 (付記3)前記ネットワークは、前記移動端末をこのホ
ームアドレスにおいて収容するホームエージェント・ル
ータを含み、前記移動端末の移動により前記現在アドレ
スを変更したことに伴い該ホームエージェント・ルータ
に対し当該アドレスの更新を通知するために送信される
更新通知情報を受信したときに該ホームエージェント・
ルータからの当該更新アドレスの転送をトリガとして、
前記記憶手段における前記ホームアドレスと前記現在ア
ドレスとの対応関係を新たに登録する登録手段を有する
ことを特徴とする付記1に記載の移動端末対応ルータ。 (付記4)少なくとも移動端末の通信をサポートするネ
ットワークを構成するホームエージェント・ルータであ
って、前記移動端末の移動により前記現在アドレスを変
更したことに伴い前記ホームエージェント・ルータに対
し当該アドレスの更新を通知するために送信される更新
通知情報を受信する受信手段と、該更新通知情報を受信
したときに、その更新後の前記現在アドレスを、前記ネ
ットワークを構成する他のルータに送信するアドレス更
新通知手段、を具備することを特徴とするホームエージ
ェント・ルータ。 (付記5)前記相手端末がIPv6プロトコルをサポートす
る端末であるとき、前記現在アドレスはCare-of Addres
s であり、前記更新通知情報はBinding Update信号であ
ることを特徴とする付記2に記載の移動端末対応ルー
タ。
との間で定めた認証情報を保持すると共に、前記Bindin
g Update信号の送信元である該移動端末に対し該Bindin
g Update信号の受信に対するBinding Acknowledgement
信号を返送することを特徴とする付記5に記載の移動端
末対応ルータ。 (付記7)前記転送手段は、前記相手端末からの前記パ
ケットを前記移動端末に転送するに際し、該パケット内
に、前記ホームアドレスを記述したIPv6ルーティングヘ
ッダを形成することを特徴とする付記5に記載の移動端
末対応ルータ。
からの前記パケットを前記移動端末に転送するに際し、
前記現在アドレスを含むIPv6ヘッダにより該パケットを
IP-in-IPカプセル化して転送することを特徴とする付記
5に記載の移動端末対応ルータ。 (付記9)前記他のルータが、IPv6プロトコルをサポー
トする移動端末端末と通信可能な移動体端末対応ルータ
であって、前記アドレス更新通知手段は、前記現在アド
レスを示すCare-of Address を、IPv6拡張ヘッダの1つ
である宛先オプションとして該移動体端末対応ルータに
通知することを特徴とする付記4に記載のホームエージ
ェント・ルータ。
通知されるパケット内には認証ヘッダを含み、該認証ヘ
ッダ内の認証データは、前記ホームエージェント・ルー
タと該移動体端末対応ルータとの間で定めた認証情報と
当該パケットの内容とを用いた計算による結果からなる
ことを特徴とする付記9に記載のホームエージェント・
ルータ。
は、次のとおりである。 文献〔1〕(Mobile IP ) http://www.ietf.org/rfc/
rfc2002.txt 文献〔2〕(IPv6) http://www.ietf.org/rfc/
rfc2460.txt 文献〔3〕(Mobile IPv6 )http://www.ietf.org/inte
rnet-drafts/draft-ietf-mobileip-ipv6-12.txt 文献〔4〕(認証ヘッダ) http://www.ietf.org/rfc/
rfc2402.txt
移動端末MNの移動に伴うCoA更新に要する時間を短
縮可能とし、パケット転送ルートの切替えが高速化され
る。またMobile−IPv6をサポートしていない
相手端末CNからMNへのパケット転送ルートを、ホー
ムエージェントHAを経由することなく、最適化するこ
とができる。
パケット転送遅延やパケット損失(ロス)の増大を防ぐ
ことが可能となる。
示す図である。
本構成を示す図である。
1)である。
2)である。
の1)である。
の2)である。
に具体的な構成を示す図である。
0のさらに具体的な構成を示す図である。
ケット通信システムの具体例を示す図(その1)であ
る。
パケット通信システムの具体例を示す図(その2)であ
る。
を示す図(その1)である。
を示す図(その2)である。
ォーマットを示す図である。
ォーマットを示す図である。
ォーマットを示す図である。
1例)のフォーマットを示す図である。
(第1例)のフォーマットを示す図である。
2例)のフォーマットを示す図である。
(第2例)のフォーマットを示す図である。
(第3例)で認証ヘッダ無しのときのフォーマットを示
す図である。
(第3例)で認証ヘッダ有りのときのフォーマットを示
す図である。
を示す図である。
ォーマットを示す図である。
ォーマットを示す図である。
ォーマットを示す図である。
ットの一例を示す図である。
つに統合して表す図である。
ロックを表す図である。
ブルの内容の一例を示す図である。
ブルの内容の一例を示す図である。
テーブルの内容の一例を示す図である。
テーブルの内容の一例を示す図である。
(図28)の処理を示すフローチャート(その1)であ
る。
(図28)の処理を示すフローチャート(その2)であ
る。
ける各パケット(P1〜P4)の流れを示す図である。
フォーマットを示す図である。
(図28)の処理を示すフローチャート(その1)であ
る。
(図28)の処理を示すフローチャート(その2)であ
る。
ける各パケット(P5〜P8)の流れを示す図である。
フォーマットを示す図である。
Claims (4)
- 【請求項1】 少なくとも移動端末のパケット通信をサ
ポートするネットワークを構成する移動端末対応ルータ
であって、 前記パケット通信の相手端末が記憶すべき前記移動端末
の現在アドレスを、該相手端末に代わって、記憶する記
憶手段と、 前記相手端末から前記移動端末のホームアドレス宛てに
送信されたパケットを受信したとき、前記記憶手段を参
照し、該ホームアドレス宛てを前記現在アドレス宛てに
変換して該パケットを送信する転送手段と、 を具備することを特徴とする移動端末対応ルータ。 - 【請求項2】 前記移動端末の移動により前記現在アド
レスを変更したことに伴い前記通信の相手端末に対し当
該アドレスの更新を通知するために送信される更新通知
情報を受信したとき、この受信をトリガとして、前記記
憶手段における前記ホームアドレスと前記現在アドレス
との対応関係を新たに登録する登録手段を有することを
特徴とする請求項1に記載の移動端末対応ルータ。 - 【請求項3】 前記ネットワークは、前記移動端末をこ
のホームアドレスにおいて収容するホームエージェント
・ルータを含み、前記移動端末の移動により前記現在ア
ドレスを変更したことに伴い該ホームエージェント・ル
ータに対し当該アドレスの更新を通知するために送信さ
れる更新通知情報を受信したときに該ホームエージェン
ト・ルータからの当該更新アドレスの転送をトリガとし
て、前記記憶手段における前記ホームアドレスと前記現
在アドレスとの対応関係を新たに登録する登録手段を有
することを特徴とする請求項1に記載の移動端末対応ル
ータ。 - 【請求項4】 少なくとも移動端末の通信をサポートす
るネットワークを構成するホームエージェント・ルータ
であって、 前記移動端末の移動により前記現在アドレスを変更した
ことに伴い前記ホームエージェント・ルータに対し当該
アドレスの更新を通知するために送信される更新通知情
報を受信する受信手段と、 該更新通知情報を受信したときに、その更新後の前記現
在アドレスを、前記ネットワークを構成する他のルータ
に送信するアドレス更新通知手段、 を具備することを特徴とするホームエージェント・ルー
タ。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000377628A JP2002185520A (ja) | 2000-12-12 | 2000-12-12 | 移動端末対応ルータおよびホームエージェント・ルータ |
US09/918,271 US7136365B2 (en) | 2000-12-12 | 2001-07-30 | Mobile node adapted router and home agent router |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000377628A JP2002185520A (ja) | 2000-12-12 | 2000-12-12 | 移動端末対応ルータおよびホームエージェント・ルータ |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2002185520A true JP2002185520A (ja) | 2002-06-28 |
Family
ID=18846320
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000377628A Pending JP2002185520A (ja) | 2000-12-12 | 2000-12-12 | 移動端末対応ルータおよびホームエージェント・ルータ |
Country Status (2)
Country | Link |
---|---|
US (1) | US7136365B2 (ja) |
JP (1) | JP2002185520A (ja) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004039116A1 (ja) * | 2002-10-25 | 2004-05-06 | Matsushita Electric Industrial Co., Ltd. | 無線通信管理方法及び無線通信管理サーバ |
WO2005006674A1 (ja) * | 2003-07-09 | 2005-01-20 | Hitachi Communication Technologies, Ltd. | 端末及び通信システム |
JP2007096932A (ja) * | 2005-09-29 | 2007-04-12 | Mitsubishi Electric Corp | 無線通信システム |
CN1331337C (zh) * | 2003-09-04 | 2007-08-08 | 株式会社Ntt都科摩 | 通信系统和通信控制方法 |
US7301957B2 (en) | 2003-03-21 | 2007-11-27 | Samsung Electronics Co., Ltd. | Multi-home agent control apparatus and method |
US7515590B2 (en) | 2003-05-13 | 2009-04-07 | Fujitsu Limited | Mobile communication system and method thereof |
US7710956B2 (en) | 2003-02-05 | 2010-05-04 | Ntt Docomo, Inc. | Mobile communication control system, network management server, mobile node, access node and anchor node |
JP2010521908A (ja) * | 2007-03-23 | 2010-06-24 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | プロキシ・モバイルipルーティング |
US8284670B2 (en) | 2003-03-12 | 2012-10-09 | Ntt Docomo, Inc. | Mobile communications system, mobile communications method, server, transfer device, and mobile communications terminal |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7339903B2 (en) | 2001-06-14 | 2008-03-04 | Qualcomm Incorporated | Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address |
US7474650B2 (en) * | 2001-06-26 | 2009-01-06 | Qualcomm Incorporated | Methods and apparatus for controlling resource allocation where tunneling and access link packet aggregation are used in combination |
US7027400B2 (en) * | 2001-06-26 | 2006-04-11 | Flarion Technologies, Inc. | Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system |
US8000241B2 (en) * | 2001-06-26 | 2011-08-16 | Qualcomm Incorporated | Methods and apparatus for controlling access link packet flow aggregation and resource allocation in a mobile communications system |
WO2003017586A1 (en) * | 2001-08-16 | 2003-02-27 | Nokia Corporation | Device, method and system for enhanced routing in mobile ip networking |
JP3984053B2 (ja) * | 2002-01-09 | 2007-09-26 | 富士通株式会社 | ホームエージェント |
US8649352B2 (en) * | 2002-02-04 | 2014-02-11 | Qualcomm Incorporated | Packet forwarding methods for use in handoffs |
US7564824B2 (en) * | 2002-02-04 | 2009-07-21 | Qualcomm Incorporated | Methods and apparatus for aggregating MIP and AAA messages |
US20030193952A1 (en) * | 2002-02-04 | 2003-10-16 | O'neill Alan | Mobile node handoff methods and apparatus |
US6785256B2 (en) * | 2002-02-04 | 2004-08-31 | Flarion Technologies, Inc. | Method for extending mobile IP and AAA to enable integrated support for local access and roaming access connectivity |
US7356020B2 (en) * | 2002-04-08 | 2008-04-08 | Qualcomm Incorporated | Support of disparate addressing plans and dynamic HA address allocation in mobile IP |
JP3952860B2 (ja) * | 2002-05-30 | 2007-08-01 | 株式会社日立製作所 | プロトコル変換装置 |
US20030236914A1 (en) * | 2002-06-25 | 2003-12-25 | Intel Corporation | Connection of next generation mobile nodes across previous generation networks to next generation networks |
AU2003273340A1 (en) * | 2002-09-18 | 2004-04-08 | Flarion Technologies, Inc. | Methods and apparatus for using a care of address option |
JP3887640B2 (ja) * | 2002-10-18 | 2007-02-28 | 松下電器産業株式会社 | グローバル・ネットワークにおけるローミング接続方法及び装置 |
KR100547110B1 (ko) * | 2002-12-17 | 2006-01-26 | 삼성전자주식회사 | 바인딩 업데이트 메시지 전송 방법 및 바인딩액크놀리지먼트 메시지 전송 방법 |
KR100524069B1 (ko) * | 2003-04-04 | 2005-10-26 | 삼성전자주식회사 | 홈 에이전트 관리장치 및 관리방법 |
ES2222084B1 (es) * | 2003-05-09 | 2006-03-01 | Tempel, S.A. | Equipo y metodo para unir dos redes aereas locales lan distantes mediante telefonia movil e internet. |
GB2403097A (en) * | 2003-06-16 | 2004-12-22 | Orange Personal Comm Serv Ltd | Communicating internet packets having care-of-address as destination address to a mobile node |
JP2005160053A (ja) * | 2003-11-04 | 2005-06-16 | Matsushita Electric Ind Co Ltd | 移動通信方法、移動通信装置、ホームエージェント装置、アクセスルータ情報サーバ装置、および移動通信システム |
US7697501B2 (en) | 2004-02-06 | 2010-04-13 | Qualcomm Incorporated | Methods and apparatus for separating home agent functionality |
US20090122723A1 (en) * | 2004-03-25 | 2009-05-14 | Matsushita Electric Industrial Co., Ltd | Dynamic Network Management System, Dynamic Network Management Device, and Dynamic Network Management Method |
JP2005295036A (ja) * | 2004-03-31 | 2005-10-20 | Fujitsu Ltd | ホームエージェントシステム |
US20060029014A1 (en) * | 2004-08-04 | 2006-02-09 | Jagadish Maturi | System and method for establishing dynamic home agent addresses and home addresses using the mobile IPv6 protocol |
EP2262295A1 (en) * | 2004-12-14 | 2010-12-15 | Panasonic Corporation | Communication route optimization system and nodes |
KR100594773B1 (ko) * | 2004-12-20 | 2006-06-30 | 한국전자통신연구원 | 다중 네트워크 인터페이스를 가진 노드의 이기종 네트워크연동 방법 |
JP4718216B2 (ja) * | 2005-03-24 | 2011-07-06 | 富士通株式会社 | プログラム、クライアント認証要求方法、サーバ認証要求処理方法、クライアント及びサーバ |
JP4466434B2 (ja) * | 2005-03-30 | 2010-05-26 | パナソニック株式会社 | 経路制御方法およびホームエージェント |
US8218484B2 (en) * | 2008-06-02 | 2012-07-10 | Media Patents, S.L. | Methods and apparatus for sending data packets to and from mobile nodes in a data network |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH1023068A (ja) | 1996-07-04 | 1998-01-23 | Matsushita Electric Ind Co Ltd | 移動通信方法と移動通信装置 |
JP3581251B2 (ja) | 1998-06-16 | 2004-10-27 | 株式会社東芝 | 通信システム、データパケット転送方法、ルータ装置及びパケット中継装置 |
US6501746B1 (en) * | 1999-01-08 | 2002-12-31 | Cisco Technology, Inc. | Mobile IP dynamic home address resolution |
FR2789249A1 (fr) | 1999-01-29 | 2000-08-04 | St Microelectronics Sa | Systeme de gestion d'emissions numeriques concourantes par scrutation cyclique |
EP1032178B1 (en) * | 1999-02-26 | 2005-05-25 | Lucent Technologies Inc. | Non-encapsulation mobile IP |
JP3498210B2 (ja) | 1999-12-06 | 2004-02-16 | 日本電信電話株式会社 | 位置情報管理システム |
JP2002016636A (ja) | 2000-06-28 | 2002-01-18 | Mitsubishi Electric Corp | 移動通信システム、データ転送方法、およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体 |
JP3648139B2 (ja) | 2000-08-15 | 2005-05-18 | 日本電信電話株式会社 | 分散型ルート設定方法 |
JP3496641B2 (ja) | 2000-12-07 | 2004-02-16 | 日本電信電話株式会社 | 端末位置情報管理方法,この方法を用いる端末位置情報管理システム、並びにこのシステムに用いるホームエージェントおよびボーダゲートウェイ |
-
2000
- 2000-12-12 JP JP2000377628A patent/JP2002185520A/ja active Pending
-
2001
- 2001-07-30 US US09/918,271 patent/US7136365B2/en not_active Expired - Fee Related
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004039116A1 (ja) * | 2002-10-25 | 2004-05-06 | Matsushita Electric Industrial Co., Ltd. | 無線通信管理方法及び無線通信管理サーバ |
US7710956B2 (en) | 2003-02-05 | 2010-05-04 | Ntt Docomo, Inc. | Mobile communication control system, network management server, mobile node, access node and anchor node |
US8284670B2 (en) | 2003-03-12 | 2012-10-09 | Ntt Docomo, Inc. | Mobile communications system, mobile communications method, server, transfer device, and mobile communications terminal |
US7301957B2 (en) | 2003-03-21 | 2007-11-27 | Samsung Electronics Co., Ltd. | Multi-home agent control apparatus and method |
US7515590B2 (en) | 2003-05-13 | 2009-04-07 | Fujitsu Limited | Mobile communication system and method thereof |
WO2005006674A1 (ja) * | 2003-07-09 | 2005-01-20 | Hitachi Communication Technologies, Ltd. | 端末及び通信システム |
KR100847167B1 (ko) * | 2003-07-09 | 2008-07-17 | 히다찌 커뮤니케이션 테크놀로지 | 단말기 및 통신 시스템 |
US8437345B2 (en) | 2003-07-09 | 2013-05-07 | Hitachi, Ltd. | Terminal and communication system |
CN1331337C (zh) * | 2003-09-04 | 2007-08-08 | 株式会社Ntt都科摩 | 通信系统和通信控制方法 |
JP2007096932A (ja) * | 2005-09-29 | 2007-04-12 | Mitsubishi Electric Corp | 無線通信システム |
JP4606985B2 (ja) * | 2005-09-29 | 2011-01-05 | 三菱電機株式会社 | 無線通信システム |
JP2010521908A (ja) * | 2007-03-23 | 2010-06-24 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | プロキシ・モバイルipルーティング |
Also Published As
Publication number | Publication date |
---|---|
US20020071417A1 (en) | 2002-06-13 |
US7136365B2 (en) | 2006-11-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2002185520A (ja) | 移動端末対応ルータおよびホームエージェント・ルータ | |
JP5205468B2 (ja) | ネットワーク・ベース・モビリティからホスト・ベース・モビリティへのハンドオーバ時におけるルート最適化の継続性 | |
US7539159B2 (en) | Maintaining reachability of a mobile node | |
JP5349466B2 (ja) | トンネルオーバヘッドの削減 | |
US7489667B2 (en) | Dynamic re-routing of mobile node support in home servers | |
US20060133337A1 (en) | Route optimization method for network mobile service in IPv6 networks | |
US20100202355A1 (en) | METHOD FOR SUPPORTING ROUTE OPTIMIZATION IN 6LoWPAN BASED MANEMO ENVIRONMENT | |
US8780922B2 (en) | Method for the transmission of ethernet transmission protocol-based data packets between at least one mobile communication unit and a communication system | |
EP1956755A1 (en) | Network controlled overhead reduction of data packets by route optimization procedure | |
US7508793B2 (en) | Micro mobility management | |
EP1588534B1 (en) | Provision of mobility for ipv4 traffic in an ipv6 network | |
JP2005072685A (ja) | ルータ装置及びその装置における経路情報の配布方法並びに通信システム | |
JP2008546222A (ja) | パケット転送制御方法及びパケット転送制御装置並びに通信ノード | |
EP1804463B1 (en) | Method for route optimization with dual mobile IPv4 node in IPv6-only network | |
US7539773B2 (en) | Network system using IPv4/IPv6 translator | |
JPWO2008132780A1 (ja) | オーバレイネットワークノード及びモバイルノード並びにモバイルルータ | |
KR100915513B1 (ko) | 프락시 모바일 IPv6에서 패킷 손실을 줄이기 위한 패킷버퍼링 장치 및 방법 | |
JP2008543120A (ja) | パケット転送制御方法及びパケット転送制御装置 | |
JP2008541516A (ja) | IPv6通信相手ノード及び移動IPv6ノード間の通信方法、並びに通信相手ノードプロキシーゲートウエイ | |
US20020154613A1 (en) | Method and system for a low-overhead mobility management protocol in the internet protocol layer | |
JP3536822B2 (ja) | 移動端末管理システム、移動端末、エージェント及びプログラム | |
JP3928443B2 (ja) | 移動体通信システム | |
KR20030030329A (ko) | 이동 인터넷 환경에서의 라우팅 성능 개선방법 | |
Nada | On Using Mobile IP Protocols | |
JP4228817B2 (ja) | ネットワークシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040805 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060309 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060704 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060904 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070116 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070814 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071004 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080311 |