bayashidayo @Wiki

HMIP

最終更新:

匿名ユーザー

- view
だれでも歓迎! 編集
    階層型MobileIPv6移動性制御(HMIPv6)

Abstract

このドラフトローカルで移動性を認めるためのMIPv6やIPv6近隣発見(NDP?)拡
張を紹介します。階層型移動性制御はMIPv6においてMNやCN,HA間で送信した信号
が到達するように導く。この文章で記述されるMAPは、MIPv6におけるハンドオフ
時間の長さのパフォーマンスを改善するために利用できる。

目次

1、技術用語
2、イントロ
3、HMIPv6概要
4、MIPv6拡張
5、近隣発見拡張MAPオプション
6、プロトコル要求
  6-1、MN要求
  6-2、MAP要求
  6-3、HA要求
  6-4、CN要求
  6-5、ローカル移動制御要求及びMAPドメイン
  6-6、位置機密性
7、MAPの発見
  7-1、動的MAP発見
  7-2、ルータ最探索を利用しMAPを発見
  7-3、MNオプション
8、以前のAnchorPointへのアップロード
9、BU送信のための特別な最適化
10、MNでのMAP選択
11、MAP機能停止の探知を回復
12、セキュリティの考慮
13、謝辞
14、正当な知的特性についての注意
15、参考文献
16,17 略


1、技術用語

Access Router
MNのデフォルトルータ、ARは外部へ向かうトラフィックを集約する

MAP
MNが滞在するネットワークに位置するルータ、MNがローカルのHAとして用する、
MAPは訪問先のネットワークに複数存在できる

RCoA
RCoAはMNが訪問先のネットワークから得るアドレスでMAPのサブネットを示す。
これはMNがMAP情報を入手することで自動生成される。

HMIPv6-aware MN
MNは、デフォルトルータからMAP情報を受信し加工することができる。MNはロー
カルBUを行うこともできなければならない。

LCoA
LCoAはMNのインタフェースを基にデフォルトルータのプレフィックス情報から生
成されますが、単にCoAを基にしています。しかしながら、この文章ではRCoAと
分けて利用しています。

Local BU
MNがMAPにBUを行う間隔はRCoAとLCoAの関係が定着する間である


2、イントロ

このドラフトはHMIPネットワークのコンセプトを紹介するもので、新たに追加す
るノードをMAPと呼ぶ

MIPv6はノードのインターネットトポロジー内の移動を行う際に、CNとMN間の到
達性とコネクションを維持する。MNは移動を行うたびに、HAや通信を行っている
全てのCNにBUを行う。BUリクエストは、MNとCNの間で約1.5ラウンドトリップタ
イムで認証される(ベストケースで)。HAにBUを行うには1ラウンドトリップタ
イム必要なのに加え、これを同時にCNに対して行うことができる。HomeCookies
を利用場合、CNにBUを行うのに必要なラウンドトリップタイム数を減少させるこ
とはない。ラウンドトリップに遅延があると、機能しているAPにハンドオフを行
うたびに、既存の通信に混乱が生じる。この余計な遅延要素を削除するためには、
MIPv6の時間に厳密なハンドオーバーの時間を注意深く改良する必要がある。そ
の上、無線の場合、そのような問題解決方法は、複数のメッセージとして無線イ
ンタフェースから全てのCNとHAに送信される。ローカルのポイントは、さらに外
部のネットワークとの間で、移動の信号を送信することでMIPv6の利益となる。

新しいMIPノードの理由として、ARを含む階層型ネットワークの複数の階層のル
ータの中でMAPを利用することで位置を定めることができる。IPv4のFAとは異な
りMAPは各々のサブネットにおいて要求を行わない。MAPはローカルドメインの外
からのMIPの信号を制限するだろう。MAPの導入は、以下のような概要について問
題解決方法を供給する。

MNはBUを遠くにあるHAやCNではなく、ローカルMAPに送信する

HAやCNから別ルートでトラフィックが到達する前に、新しい位置情報を一つのBU
メッセージで送信する必要がある。これはMNが通信を行っているCNの数に依存し
ない。

MAPは基本的にローカルのHAである。階層型移動モデル紹介のねらいは、MIPの性
能を高める際にMIPやIPに与える影響が少ないということです。また、シームレ
スな通信を提供するために高速ハンドオーバーのサポートをする。その上、経路
最適化を行ってる間は、HMIPv6はMNにCNやHAの位置を隠します。


3.HMIPの概要

HMIP体系は新たな機能としてMAPと、MNに小さな拡張を加えます。CNとHAは影響
されない。

MIPのように、この技術は基本的なアクセス方式に独立であり、異なるアクセス
ネットワーク間の移動を許容する。その上、HMIPv4からスムーズな移行が可能で
あり、階層型のv4とv6の共存が共存可能な仕様になっている。

MNはMAPドメインに入ると、一つのまたは複数のルータから広告メッセージに含
まれる情報を受信する。MNはLCoAとRCoAを結びつけることができる。ローカルの
HAのよう動作するMAPは、MNのためにMNの現在のアドレス宛に届いた全てのパケ
ットのカプセル化を解き直接転送する機能を供給する。もし、MNが現在のアドレ
ス(LCoA)をMAP内で変更した場合は、MAPにのみ登録を行えばよい。それゆえ、
CNとHAにのみ登録を行う必要がある。MNがMAPドメイン内を移動する長い間、
RCoAが変わることはない。これで、MNの移動性は通信を行っているCNから透明に
なる。

MAPドメインの境目は、AR広告メッセージのMAP情報からMNに結び付けられること
で定義される。異なるノードやMIPへの詳細な拡張はこの文章で説明されるだろ
う。

HMIPの概念がMIPへの簡単な拡張であることに注意すべき。MIPSHOULD実装のある
HMIPを利用できるMNは訪問先のネットワークでそのような性能を発見する際に使
用するMAPを選択する。しかしながら、いくつかの場合にMNは単純なMIPを使用す
ることを選ぶかも知れない。例えば、MNの現在の訪問ネットワークの位置がそれ
のHomeかもしれない。その場合、HAは訪問ネットワークの近隣に位置し、MAPの
代わりに使用できる。このシナリオでは、MNは移動を行うたびにHAにのみ登録を
おこなうだろう。この文章の範囲外でHAとMNが近隣(同じリンク内等)に存在す
るかを決定する方法がある。

3-1、HMIPの動作

ネットワーク構成は以下の図の例のようにネットワークでMAPを利用する。

           +-------+ 
           |  HA   |     
            +-------+  
                |
                |           +----+ 
                |           | CN |     
                |           +----+ 
                +-----+        | 
                      |        |  
                      |    +---+ 
                      |    | 
                    +-------+ 
                    |  MAP  |   RCoA 
                    +-------+ 
                     |     | 
                     |     +--------+ 
                     |              | 
                     |              | 
                 +-----+         +-----+ 
                 | AR1 |         | AR2 | 
                 +-----+         +-----+ 
                          
       
                +----+ 
                | MN | 
                +----+   ------------> 
                           Movement    

図1、HMIPドメイン

図1においては、MAPがCNと通信を行っているMNのAR1からAR2へのシームレスな移
動提供の手助けをすることができる。多階層モデルでは高いハンドオフ性能を要
求しない、したがってネットワークのどのような位置でも、1つかそれ以上のMAP
を配置すれば十分である。

訪問ネットワークに到達すると、MNはMAPのグローバルアドレスを発見するでし
ょう。このアドレスはARに格納され、そしてRA経由でMNに伝えられる。RAの新し
いオプションの仕様は後に提案される。これは、MNにMAPの存在を通知するのに
必要である。発見段階ではMNにMAPからMNまでの距離を通知だろう。例えば、MAP
機能は図1のように、AR1とAR2で同時に実行されるかもしれない。この場合、MN
は階層構造のルータの中からファーストホップか、もっとも早いMAPを選択でき
る。MAPの詳しい選択方法は10章でのべる。

MAP発見のプロセスが完了するとMNは次のサブネットに移動する。MNがMAPドメイ
ン内を移動する際に、ARは告知するためのアドレスを構成する。もし、告知する
MAPのアドレスの変化を受信した場合、MNは移動検出を行いHAとCN必要なBUを行
わなければならない。

もし、MNがHMIPを意識しない場合MAPの探索は機能しないだろう、結果、MNはMIP
を利用することで移動性を制御する。他の方法として、もしMNがHMIPを意識する
場合、MNはHMIP機能の実行を選択すべきである。もしそうなら、MNは初めに
HomaAddressとLCoAの入ったBUを送信しMAPに登録を行う必要がある。
HomaAddressはRCoAのBUに利用する。MAPはHAやCNからパケットを受信した時に最
終的な目的地に転送できるように、キャッシュに情報を記憶しなければならない。

MNが経路最適化を要求するならば、受信パケットの本来の送信先を常に知る必要
があると決定する。この情報は、MAPがパケットの内容を変更することが無いの
で、MNで利用することができる。通常の処理で受信されたパケットは必要な情報
をMNに与えるだろう。

より効率的な帯域利用を行うために、MNは特定のグループのCNに複数のMAPのそ
れぞれのアドレスを同時に登録することを決定してよい。例えば、図1において、
もし、CNとMNが同じリンクに存在することが起こった場合、それらの通信には最
初のホップのMAPを利用することが効率的である。これは、全てのパケットを階
層構造の最も高い位置のMAP経由を避けることができるため、結果として帯域の
有効利用ができる。また、MNはMIPで指定されるCoAとして現在のLCoAを利用する
ことができる。

もし、この文章の説明のようにルータ告知をMAP発見に利用するのならば、全て
のMAPに所属するARはMAPのIPアドレスを告知しなければならない。また、ルータ
の番号の付け直しの拡張はMAP発見の代わりとしてARとMAPにより提供される。今
後、MAP発見のほかの方法を提案するなら同じ概念(ドメイン中にMAPの広告を出
す)を利用すべきだ。


4.MIP拡張

このセクションの概要はBUやBAの拡張の提案を具体化することです。

4-1.ローカルBU
新たなフラグの追加:MAPへの登録を示すMフラグ。MNがMAPに登録を行おう時に、
この登録がHAへの登録なのか、CNへのBUの送信なのか区別するのにMやAのフラグ
を設定しなければならない。

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                   |            Sequence #         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|H|L|K|M|      Reserved       |            Lifetime           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   .                                                               . 
   .                        Mobility Options                       . 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   
  BUの拡張の図
  M:セットされていればMAPへ登録

HMIPにおいてBUを利用する際にはヘッダタイプが同じになることに注意しなけれ
ばならない。

4-2.LCoAアドレステストオプション
このセクションの新しいオプション、OCOTを紹介する。このメッセージは
BindingAck(BA)に含まれる。OPTIONALとSHOULDがMAPで構成可能ならこのオプ
ションが含まれる。しかしながら、MAPとMNはこのオプションをサポートしなけ
ればならない。

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |     Type      |    Length     |        Reserved               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                      sequence no                              | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type:オプションタイプ。TBA。
Length:8bit整数。オプションの部分の長さは8オクテットです(typeとlength
    を含む)。この部分は1をセットしなければならない。
Reserved:16bit。送信者は0を設定し、受信者は無視しなければならない。
Sequence no:32bit整数。MAを送信した時や、MNからの送信が1増加した時に、
       MAPにより任意に設定される。

5.近隣発見拡張(MAPオプションメッセージフォーマット)

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |     Type      |    Length     |  Dist |  Pref |R|I|P|V|  Res  | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                      Valid Lifetime                           | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               | 
     +                                                               + 
     |                                                               | 
     +                  Global IP Address for MAP                    + 
     |                                                               | 
     +                                                               + 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

GlobalAddress:MAPのアドレス。64bitのプレフィックスを作る基。MNのRCoA。

たとえMAPオプションが明白でなくても、64bit長のプレフィックスであるMAPア
ドレスを含まねばならない。このプレフィックスに64bitの識別子を追加するこ
とでMNが利用するRCoAを形成する。それゆえ、MAPサブネットのために静的なプ
レフィックスを持つ必要がある。

6.プロトコル要求

このセクションではHMIPの特徴を述べる。HMIPではMNは2つのアドレスを持ち、
MAPリンク上のRCoAとLCoAである。RCoAのフォーマットは、MNのインタフェース
情報と受信したサブネットプレフィックスを組み合わせて静的に形成される。

このセクションで説明するのは、このプロトコルはMobile Nodesimplementation
の更新のみを必要とすることです。HAやCNは変更しない。MAPはローカルのHAの
機能を提供し、MNのRCoAにLCoAを関連付ける。

6-1.MN要求

MAP間を移動する際にはRCoAとLCoAの2つのアドレスを生成する必要がある。アド
レスのへ静的な構成である。MAPオプションから受け取ったプレフィックスを基
にRCoAを生成し、MNはMAPにAフラグとMフラグをセットしたローカルBUを送信す
る。ローカルBUはHMIPで定義されたBUであり、HomeAddressオプションのなかに
MNのRCoAを含んでいる。alternate-CoAはこのメッセージでは不要である。LCoA
はBUのソースアドレスとして利用される。このBUはMNのRCoA(HomeAddress同様
に)とLCoAを関連付ける。MAP(HAのように振舞う)はリンク上のMNのRCoAに対
してDADの機能(新しい登録がなされたとき)を実行し、MNにBAを返す。この返
答の識別情報には登録が成功した、もしくは接続が失敗したことに当たるコード
が含まれる。この要求ではMNが新たなエラーコードのサポートをする必要が無い。
MNはMNのRCoAを含む場合、ルーティングヘッダタイプ2を含む静的な登録ACKを
無視しなければならない。

MAPはBAにOCOTオプションを含んでもよい。もし、このオプションが含まれれば、
OCOTオプションのシーケンスナンバーを1増加させた後に、MNはOCOTオプション
を含んだBAをMAPに返さなければならない。このオプションはMAPがMNの存在する
と主張するリンクや、その他のノードやリンクの方にフラッティング攻撃を試み
ないことの管理を保証することを、認めるために含まれている。

MAPに登録した後、MNはMIP同様に登録(RCoAとHAddress)を指定するBUを送信し、
HAに新たなRCoAを登録しなければならない。HomeAddressオプションはが
HomeAddressにセットされている場合、ソースアドレスフィールドかAlt-CoAオプ
ションからRCoAを見つけることができる。MNは通信相手のCNにも同様に、同じよ
うなBU(HomaAddressとRCoA間の対応を示す)を送信する。もしMAPオプションに
Iフラグがセットされた場合、MNはBUのソースアドレスのようにRCoAを利用する
かもしれない。もし、Pフラグがセットされたら、MNはRCoAをソースアドレスと
して利用しなければならない。

もし、MNがRCoAをソースアドレスとして使用すると、Alt-CoAオプションは必要
ない。もし、PとV両方のフラグがセットされていると、MNはRCoAをソースアドレ
スや全てのパケットをMAPに送出するトンネルとして利用しなければならない。
外側のヘッダのソースアドレスはMNのLCoAで、送信先アドレスはMAPアドレスと
なる。ネットワーク管理者がMNにRCoAをソースとして使用してほしい場合を考慮
するためにAPで入り口のフィルタ構成を維持します。MNSHOULDはHAに登録を行う
前に、MAPからのBAを待ちます。HAとCNにRCoAを登録する時、受信されるBA内の、
登録の寿命はMNのMAPへの登録寿命より長くするべきでないことに注意をするべ
きである。

MAP間のハンドオーバーを高速化するために、MNがローカルBUを新しいLCoAを指
定する前のMAPに送るかもしれない。パケットは新しいLCoAに送られる。

MAPは(HAやCNから)受信したパケットにMNのRCoAを指定するだろう。パケット
はMAPからMNのLCoAにトンネルされるだろう。MNは通常のプロセスとしてカプセ
ル化を解くでしょう。

MNが同じMAPドメイン内を移動する時、MAPに新たなLCoAのみを登録すべきです。
この場合、RCoAは変化しないままです。

MNが、同じリンクに接続されたCNにLCoA(RCoAの代わりに)を含むBUを送信する
かも知れないことに注意すべきです。パケットはMAPを通ることなく直接送信さ
れるだろう。

ネットワーク管理者は、MNのLCoAを外部のMAPドメインのノードから隠すことを
好むかもしれない。これを確信するために、MAPはPフラグをセットしたオプショ
ンを送信できる。この場合、MNはHAやCNへのBU(Alt-CoAは不要)のソースアド
レスをとしてRCoAを利用しなければならない。また、送出したパケットのソース
アドレスとしてRCoAを使用しなければならない。

他の方法として、MNはCNや通信を行っているHAから位置を隠す(意識させない)
ことを好むかもしれない。これを可能にするために、MNは、いずれのCNに対して
も身元と位置情報の両方を公開しないことを可能にすべきである。MNの存在の暗
示は、あらゆる経路最適化パケットに含まれるため、MNは正確な位置情報をHAや
CNに与えないことを確実にすべきだ。そのため、MNは全ての送出パケットにソー
スアドレスとしてRCoAを利用すべきである。もし、IかPのフラグが設定されれば
利用できる。さもなくば、この様な位置のプライバシーは提供できない。

(IかPフラグに加えて)もしVフラグがセットされているならば、MNは全ての送
出パケットをMAPにトンネルしなければならない。これは、ARでの入力フィルタ
の構成を保っている間、位置のプライバシーを取っておくのに必要です。

6-1-1.CNへのパケット送信

HMIPにおいて、MNがCNと、HAを経由する、または経路最適化による通信をする場
合について説明した。HAを経由して通信を行う時、HMIPではメッセージフォーマ
ットを再利用できる。しかしながら、MNは、送出したパケットのMAPオプション
のP,I,Vフラグの内容に基づいてソースアドレスを選択しなければならない。

もし、MNがCNと直接通信をするなら、MNはソースアドレス(RCoA)としてCNで登録
用のキャッシュエントリーを作成するために同じCoAを利用しなければならない。
HMIPに従い、MNは送出パケットにHomaAddressオプションを含まなければならな
い。HomeAddressオプションにはMNのHomeAddressを含まなければならない。

RCoAが送出したパケットのソースアドレスのように利用されるので、MNは、パケ
ットを直接ソースアドレスであるRCoAに送信するか、MAPにトンネルするかどう
かP,I,Vフラグの内容決定することを考慮しなければならない。MAPに送出パケッ
トをトンネルする際、外部ヘッダのソースアドレスはMNのLCoAで、宛先のアドレ
スはMAPアドレスです。

MAP要求

MAPはHAのように動作する。MAPは全てのパケットを取り出し、登録されたMNを宛
先として対象のCoAにトンネルを行う。

MAPにはMNのHAの情報は全く無い。MNはM,AフラグをセットしたローカルBUをMAP
に送るでしょう。このBUの目的はMNが形成したRCoAをMAPに知らせることです(
BUにはHAaddressが含まれる)。BUが完了した場合、MAPは登録が成功したことを
示す、BAをMNに返さなければならない。これはHMIPのHAオプションと同じです。
HMIPv6に新しいエラーを導入することはない。BAはMNのRCoAを含むタイプ2ルー
ティングヘッダを含まなければならない。

MNにBAを送信する時、MAPはOCOTオプションを含んでもよい。このオプションは、
要求するリンク上のMNの位置を確認するのに必要です。もし、このオプションを
含むならば、MAPはMNからBAが返ってくると予測すると、OCOTオプションのシー
ケンスナンバーに1を加算するだろう。MNがBAを返すまでMAPは、仮の情報をBC
に保存しておかなければならない。シーケンスナンバーに+1を含むBUをMNから
受け取った時、MAPは登録のライフタイムのためにMNのLCoAについてBUの情報を
確認し、パケットを送信し続けなければならない。

BAにOCOTオプションを含む構成にするべきであるが、MAPがサポートしなければ
ならない。

MAPはMNからトンネルされたパケットを受信できなければならなず、MNがトンネ
ルの入口でMAPが出口となる。これはP,IもしくはVフラグの設定により独立して
要求される。

RCoAに対してMAPはHAのように操作する。宛先がRCoAのパケットは代理近隣探索
を利用することでMAPに受信され、カプセル化されMNのLCoAに送信される。この
要求はHMIPで説明されたHAのものと同一である。

6-3,HA要求

HMIPv6のサポートはHAの要求に対して非常に明解です。MNのHAddress宛のパケッ
トはMIPのようにHAによってRCoAに転送される。

6-4,CN要求

HMIPv6はCNに対して非常に明確です。

6-5,MAPドメイン内でのローカル移動制御の最適化

MIPにおいて、短期的なコミュニケーション、特に失敗で容易に再試行されるか
もしれないコミュニケーションの状態の時、MNはパケットのソースとして利用す
る一つのCoAを選択するかもしれない、従ってパケットでHAddressオプションを
使う必要はない。そのようなCoAの利用は、追加オプションが全くないために各々
のパケットのオーバヘッドを減少させることができる。さらに、それはMNとCNの
間に最適のルートを提供するだろう。

HMIPv6では、もしMAPオプションにIかPフラグがセットされていれば、MNは
HAddressオプションを利用しないでRCoAをパケットのソースアドレスとして利用
できる。また、RCoAをLCoAとRCoA間の関係をローカルのMAPに登録するローカル
のBUのソースアドレスとして利用してもよい。その結果、MNはMAPドメイン内を
移動している間は、CNには固定ノードのように見える。

RCoAの使用は、MIPにとってコストを伴わない場合は有用であるが、依然として
MNにローカルの移動サポートを提供する(インターネット上に登録情報も
HAddressオプションも送信しない)。RCoAのそのような使用はグローバルな移動
性を提供できないけれども、MAPドメインのサイズやMNの移動速度に依存するい
くつかの複数の期間他のノード通信を行うようなアプリケーションの役に立つで
しょう。その上、MIPにおいてCNでのBUの処理方法が指示されていないので、こ
のメカニズムはBUの送信無しでルート最適化の方法を得ることをCNに提供するこ
とができる。

HMIPでは、MNはパケットのソースフィールドにRCoAを利用することで、CNやHAか
らLCoAを隠すことを選択するかもしれない。その結果、LCoAではなくRCoAのみを
認識しているので、CNやHAがMNの位置を追跡することは困難である。MNは6.1で
説明したような位置のプライバシーを達成するかもしれない。

7,MAPの発見

このセクションでは、MNがどのようにMAPアドレスと位置情報を入手するか、AR
がMAPを発見するかを説明する。MAP発見のための2つの異なる方法を以下に定義
する。

動的MAP発見は、階層型ルータ内においてMAPから信頼できるルータインタフェー
スを通りMNに宣伝されるRAに含まれるMAPオプションを基にしている。これは、
MAPやルータが受信するMAPオプションは、確かなインタフェースでオプションを
広めることを認めるためマニュアルの構成を求めるかもしれない。ルータ間の安
全な通信を保証するために、動的MAP発見のためにルータ間でRAを送信し、AHか
ESPを証明する。このマニュアルのように、ここではネットワーク管理者が手動
で全てのARからMAPオプションを送信するか、ルータの再構成メカニズムをMAP発
見に利用するため、この証明は不可能である。

著者の方法はルータの再構築が基になっており、7.2章のように説明される。こ
の方法では、ドメイン内でルータの手動でない構成が求められる。MAPドメイン
内において、MAPオプションは中心のノードから全てのARに直接送信される。階
層型の構成において、大規模なネットワークで手動で全てのルータの構成を明ら
かに簡単な方法で行える、最も適した方法である。他の方法として、この方法を
使っている時に、今後起こるいくつかのことを変更するために手動による仲介を
求めるかもしれない。

手動構成は、同じドメイン内のARや他のMAPのMAP情報のデフォルト機能です。ま
た、MAP発見のためにMAPやARで動的かルータ再構成メカニズムのどちらかの構成
を認めることを可能にすべきである。

7-1,動的MAP発見

多くの異なった方法でMAP発見のプロセスを実行することが可能である。RAは、
動的MAP発見に新たなオプションを紹介するために利用されます。アクセスルー
タがRAでのMAPオプションを送信するのに必要です。このオプションは、ホップ
数に関して本来の距離を含まない可能性があり、MNからのベクトルの距離を含み、
この特定のMAPを好み、MAPのグローバルIPアドレスとMAPのサブネットプレフィ
ックスを含む。これに加え、オプションはMAPの動作やその他の情報を表すフラ
グを含んでいる。

7-1-2,動的MAP発見のためのルータオプション

MAPドメイン内のARはMAPオプションを関連付ける情報によって動的に構成される
かもしれない。ARはこの情報を得るためにRAのMAPオプションを参照する。ネッ
トワークにおけるそれぞれのMAPは、このオプションを送信する正しいインタフ
ェースやIPアドレスをデフォルト優先で構成してもよい。”距離(Distance)”
フィールドの最初の値はデフォルトで0に設定してもよい。MAPドメイン内のル
ータは信頼できるインタフェースにMAPオプションを再送するために構成される
べきである。

MAPオプションによるRAの受け入れは、受信ルータでDistanceフィールドに1を
加えてから、オプションをコピーして再送しなければならない。また、受信した
ルータがMAPならば、受信したオプションの同じ広告と共に自身のオプションを
送信しなければならない。ルータが同じMAPのために1つ以上のMAPオプションを
2つの異なるインタフェースから受け取るならば、Distanceフィールドの小さい
オプションを選ばなければなりません。

この決まりでは、MAPの周辺情報によりMNは階層構造の特定のレベルを動的に通
過することができる。その上、この様に発見フェーズを行うことで、異なるMAP
ノードはノードオーバーロードか負荷分散方式を利用することで、ローカルポリ
シーに基づく優先度を変更することができる。

7-1-3,動的MAP発見のためのMAP要求

MAPは、MAPオプションか中継MAPオプションを所属する他のMAPの特定のインタフ
ェースに送信するでしょう。このインタフェースの選択はネットワーク管理者に
より行われ、ネットワークの形状に左右される。各ノードのデフォルトの優先度
として10が割り当てられるかもしれない。MAPはいつでも当然のように様々な理
由で優先度を変更することに注意が必要です。優先度が0の場合は、新しいMNで
のMAP SHOULDが選択されないことを意味する。この値は、ノードオーバーロード
か部分的なノードの故障の場合に得ることができる。

MAPオプションは階層構造の下側に伝搬される。アクセスルータへの経路に沿っ
たそれぞれのルータは、Distanceフィールドに1を加える。また、MAPであるル
ータが他のMAPからRAを受け取るなら、MAPは自身のMAPオプションを追加し、両
方のオプションを階層構造の下の階層に伝搬させなければならない。

7-2,MAP発見へのルータ再構成の利用

[2]で紹介されているルータ再構成メカニズム(RR)は、そのようなルータに手
動構成をすることなく、ルータのあるインタフェースに番号の付け替えをするの
に利用するメッセージを定義する。RRメッセージは再送攻撃に対して認証や保護
がされています。特定のインタフェースでMAPオプションを伝搬するためのルー
タの構成に、同じ概念を利用することができる。新しいPCOコマンド”PROPAGATE”
は後で定義されれる。このコマンドはPrefix Code Operation (PCO)の一部であ
り、MatchPrefix部分に含まれている。PROPAGATEコマンドと共にルータに送信さ
れたPCOメッセージは、一つないしはそれ以上のMAPオプションのメッセージ内の
UsePrefix内に含まれなければならない。


メッセージのレセプションにおいては、ルータは特定のインタフェースでMAPオ
プションを伝搬する。このメカニズムは一つ以上のMAPオプションの広告を出す
ためのARを構成するのに使用できる。これは大きなネットワーク、または、第三
者のネットワークがMAPとAR間に存在する場合に最適です。その上、以前に説明
された動的MAP発見と異なり、このメソッドは、MAPオプションを理解するために
MAPドメインでの各ルータを必要としない。

7-2-1,RRのMatchPrefix部分への拡張

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |    OpCode     |   OpLength    |    Ordinal    |   MatchLen    | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |    MinLen     |    MaxLen     |           reserved            | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               | 
     +                                                               + 
     |                                                               | 
     +                          MatchPrefix                          + 
     |                                                               | 
     +                                                               + 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   
拡張フィールド

OpCode:関連したMatchPrefixがインタフェースのプレフィックスかアドレスと
    マッチした時、実行する動作を指定する符号無しの8bitフィールド
値
1:加算(ADD)操作
2:変更(CHANGE)操作
3:SET-GLOBAL操作
4:PROPAGATE操作(新しいコード)

7-3,MN操作

HMIPv6を意識するMNがRAを受信する時、MAPオプションを探すべきです。一つ以
上のオプションが異なるIPアドレスかサブネットプレフィックスを見つけるかも
しれない。

MNは、MAPの持っている最も優先度の高い値を記録するべきである。MAPは優先度
を0にした新たなローカルBUを利用するべきでない。しかしながら、MNは、
Distanceフィールドで他の依存関係から受信した値によって、あるMAPと共に記
録するものを選ぶかもしれず、0より上の特定の値を提供する。

MAPオプションの正当なライフタイムの値が0の場合、MNがこのMAPを選択しては
ならないことをの意味する。正当なライフタイムが0はMAPの障害を表す。この
オプションを受信した時、MNは他のMAPを選択し新たな登録情報を作らねばなら
ない。このMAPとのどんな依存関係も失うと想定できる。

マルチホームMNがいくつかのARに同時に接続したら、現在のMAPの広告を出すAR
によって定義されたリンクのLCoAを利用すべきだ。

MNは登録と共に受信したオプションを格納し、少なくとも一つのMAPを選択しな
ければならない。オプションの記憶は、移動検出アルゴリズムの目的として後で
受け取った他のオプションと対比する時に必要です。

RAからMAPオプションを見つけられないなら、MNは[1]で指定されたMIPv6を利用
しなければならない。

Rフラグがセットされていれば、MNはMAP登録を行う時に、HAddressのようにRCoA
を利用しなければならない。RCoAはMAPのバインディングキャッシュでLCoAと結
び付けられる。

Iフラグがセットされていれば、MNは位置のプライバシー(CNやHAに対する)を
MNかユーザが要求するかどうかにより、送信したパケットのソースアドレスとし
てRCoAを利用するか選んでもよい。この選択はユーザによってMNか構成オプショ
ンのデフォルトポリシーで作ることができる。

Pフラグがセットされていれば、MNはRCoAをソースアドレスのように利用しなけ
ればならない。これは外部のインターネットに、ネットワークオペレータの要件
により特定のプレフィックスをさらさないようにしてしかるべきである。

Vフラグは、RCoAを外部向けパケットのソースアドレスとして利用するならば、
MAPへの外部通信を行うためのトンネルを行わなければならないことを示す。Pか
Iのフラグがセットされている時にだけこのフラグは役に立つ。このフラグの目
的は、ARの問題をフィルタリングするあらゆる潜在的進入を避けることです。

MNは、同時にPとIフラグの設定を提供する異なったCNのCoAがそのような選択を
許すように、同時に一つ以上のMAPと共に登録を行うか、MAPアドレスや自身のア
ドレスの両方を利用するか選ぶかもしれない。

8,以前のAnchor Pointへのアップロード

MNが新しいMAPドメインに入った時、MNは以前のMAPに対して転送するパケットの
宛先をMNの新たなCoAにするように要求をするBUを行うってもよい。管理者は、
MAPドメイン外部から転送されてくるLCoAへのパケットをMAPで制限してもよい。
しかしながら、MNが同じ管理ドメイン内に位置していれば、MAPが隣接するMAPド
メインのいくつかのARと連携しLCoAにパケットの転送を許可するのは推薦できる。
例えば、地理的にドメインの境界に位置するARが、ARと協力してLCoAにパケット
を転送するためにMAPを構成することができる。これにより、新たなMAPやHAやCN
に更新を行っている際に、MNがパケットを受信し続けることで滑らかなMAP間ハ
ンドオーバを許すでしょう。

9、BU送信のための特別な最適化

いくつかの階層では、MACの入手時間は重要であり、MNでHAへのBUのIPパケット
内側に含む、MAPへのBUのIPパケットにカプセル化したIPパケットは有用だろう。
この最適化が使用されるべきかどうかは、通信に利用される基本的なL2に依存す
るため、MNの実装に任せます。

しかしながら、それは注意されるべきで、HAかMAPに登録が拒否された場合に、
カプセル化のような余分な合図を利用する場合があります。それ以上に、MNはHA
から受け取るBAより短いライフタイムを含むBAを、MAPから受け取るかもしれな
い。そのため、この最適化を利用する時、MNは慎重になるべきだ。

したがって、通常のMNはMAPから積極的にローカルBUの承認を受信した後に、HA
とCNに対してRCoAを含むBUを送信する。この変化がプロトコルの動作に影響を与
えないと証明できるならば、変更を加えてもよい。

10,MNによるMAP選択についての注意

HMIPは滞在するネットワークのローカル移動制御に対して、融通の利く動作を提
供する。以前に説明されたように、ARを含むMAPはどんなレベルでも階層的に存
在できる。いくつかのMAPは、互いに独立して階層構造の中に位置することがで
きる。さらに、重複するMAPドメインもまた認められ、有効です。動的、静的階
層構造両方がサポートされる。

MNが受け取るRAの中にMAPオプションが含まれる時、移動検出メカニズムの動作
に従ってふるまうべきである。HMIPにおいては、ここの文書で説明されるように
MNはあるべきである:

  • 新たなバインディングを”希望(Eager)”する
  • 既存のバインディングを開放することに”怠慢(Lazy)”である

上の方法では、MNがARの出す、新たなMAP広告に登録を行うべきである(希望す
る)。MNがMAPが新しいMAPかどうか決定する方法はセクション5で説明される。
MAPオプションを受け取らない間か、または既存のバインディングの期限が切れ
ない間は、MNが既存のバインディングを解法するべきでない。上で説明されたこ
のEager-Lazyなアプローチは、あるMAPルータが故障した場合、MNがCNやHAに自
身の新たなCoAを通知するのに掛かる時間を短縮するかもしれない後退(
fallback)メカニズムを手助けする。

10-1,分散MAP環境におけるMAP選択

MNは、同じドメインにおいて複数のMAPが利用できる状態で、最適な一つ以上の
MAPを選択するためにいくつかの要因を考慮する必要がある。

一つ以上のMAPを選択して高位のMAPから階層構造のMAPを経由して送られるパケ
ット予見する利点はない。このアプローチは、高位のMAPとMN間に転送遅延を加
えることで、IPルーティングの利点を取り除くかもしれない。そのため、ネット
ワーク内のあるMAPを認めることで、MNが下位層のMAPに一連のパケットを送信す
ることを意図すべきでない。しかしながら、MNで経験する異なった移動シナリオ
のため、冗長かと最適化のためのbovethe ARとして、一つ以上のMAPを設置でき
る。MAPはMNにより、互いに独立して利用される。

いくつかのMAPとのネットワークでの距離(Distrance)を基にした選択によって、
MNは頻繁な再登録を避けるために最も遠いMAPに登録を行うかもしれない。これ
は、高速なMNの行う頻繁なハンドオフに特に重要である。この文章では、遠くの
MAPの選択は、全てのCNやHA通知、MAPを変更しなければならない確立を減少させ
るかもしれない。この仕様は、距離基準のMAP選択にアルゴリズムを提供しない。
しかしながら、下位層からの移動速度についての情報の利用はについては今後の
拡張でアルゴリズムを導入するかしれない。

MNによって、いくつかのMAPが一つのドメインで発見されるシナリオにおいて、
MNは適切なMAPを選択できる高度なアルゴリズムを必要としてもよい。これらの
アルゴリズムは、入力がMAPオプションの優先領域と結合したMNの移動速度を持
つかもしれない。しかしながら、この仕様では、他の最適化されたアルゴリズム
が利用できないかもしれない場で、MNがデフォルトとして以下のアルゴリズムを
利用することを提案する。以下のアルゴリズムは、優先度の値がゼロに達しなけ
れば、単にできる限り遠くのMAPを選択することを基にしている。MNの要件は以
下に示される:

1,全てのMAPオプションを受信、分析する
2,最も遠いMAPから始まり、降順に整列する
3,リストから最初のMAPを選択
4,優先度かライフタイムがゼロならば、リスト内から次のMAPを選択
5,新たなMAPオプションが存在する間、4の動作を繰り返す

上のステップを提供すると、MNはデフォルトで最も距離のあるか、
urthestavailableなMAPをデフォルトで選択するかもしれない。優先度をゼロに
減少させるまで繰り返される。これ以降、MNは別のMAPの選択を始めるだろう。

10-2,平坦な移動制御アーキテクチャにおけるMAP選択

ネットワーク管理者はMIPハンドオーバーはまれな事象であると考えられるいく
つかのケースでは平坦なアーキテクチャを選んでもよい。これらのシナリオでは、
管理者はARだけにMAP機能を含むことを選ぶかもしれない。ARでのMAP機能の内包
は、全てのCNやHAにアップデートを行うのに必要な時間を短縮するのに役立つ場
合がある。このシナリオで、ハンドオフを実行する時、MNはアンカーポイントと
してMAPを選択してもよい。この種類の動的な階層構造は、AR間の頻繁でない移
動の場合にのみ推薦される。

11,MAP障害からの回避と回復

この仕様では、滞在ネットワークでローカルのHAととらえることのできるMAPを
導入する。MAPは、HAのように、単一の障害点です。もしMAPが障害が起こると、
登録情報が失われ、結果としてMNとCN間の通信が失われる。この状況は、同じリ
ンクで一つ以上のMAP利用や、それらの間での何らかの転送プロトコルの利用を
回避してもよい。あるいは、VRRP(ルータ多重化プロトコル)の今後のバージョ
ンとして、ネットワークがMAPの故障からの回復を認めてもよい。

プロトコルがそのようなサポートを行わない場合、MNはMAPの障害を検出する必
要があるかもしれない。MNは受信したRA内のMAPオプションのライフタイムがゼ
ロの時、この状況を検出できる。MNはMAP発見プロセスと他のMAPへの登録の試み
を始めるべきでる。また、RCoAが変わるなら、CNやHAに通知をする必要があるだ
ろう。新しいMAPが同じRCoAをMNに与えることができることに注意しなさい。例
えば、もし両方のMAP広告のMAPオプションが同じプレフィックスの場合。これは、
MNがHAやCNにアップデートをするのを助けるでしょう。

ARは、MAPオプションのライフタイムがゼロの状態において、異なる方法で広告
を出すためのきっけとなれる。:

  • 手動による介入
  • 動的な方法

ICMPエコー要求メッセージを定期的にMAPに送ることで、MAP障害を動的に検出で
きる。どんな要求も受け入れられないなら、ARは短期間の間、積極的にエコー要
求をMAPに送信しようとするかもしれません。どんな返答も受け入れられないな
ら、有効なライフタイムがゼロのMAPオプションを送信するでしょう。

この仕様は、特定の回復メカニズムを指示しない。しかしながら、MAPとAR間の
いくつかの同様のメカニズムは、確実なプロテクトと再送攻撃からの保護をメッ
セージ認証を考慮することで安全であるべきです。

17,付録:高速MIPv6ハンドオーバとHMIP

高速ハンドオーバは、Layer3ハンドオーバ遅延を最小にするのに、必要であり、
その結果MNが2つのMAP間を移動する際に、通常起こるサービスの一時的な中断
を取り除くか最小にする。通常、この一時的なサービスの中断は、MNがAR間を移
動した後にBUを利用してHAに更新をかけるのに必要な時間のために起こる。この
期間中、MNは通信を続けることも再開することもできない。MIPv6と共に高速ハ
ンドオーバを達成するメカニズムは[12]とここで概要を簡潔に説明する。このメ
カニズムは、そこに移動を行う前に、MNの新しい位置にデータトラフィックを向
けなおすようにLayer3ハンドオーバを予測することを認める。

MNが古いAR(oAR)に接続され、新たなAR(nAR)に移動しようとしている場合、
MIPv6高速ハンドオーバは一連動作を必要とする。

1,MNはoARに接続した状態でnARでの新たなCoAを取得する。
2,nARで新しいCoAが利用される場合:MNは、まだoARに接続しながら、BCとMN
  の新たなCoAと共に更新を行うために、oARに対してF-BU(FastBU)を行う。
3,oARは、MNのためにnARのMNの新しいCoAに向けてパケットの転送を開始する。
4,nARで古いCoAが利用される場合:MNは、BCと共にMNの新たなCoAを更新する
  ために、nARに移動して接続してから、oARにF-BUを送信する。

MNかoARは、MNがすぐにoARとnARにそれぞれ付けられた2つのアクセスポイント
間を切り替えようとすると、無線リンク層情報かリンク層reggerswhich情報を利
用して高速ハンドオーバの手順を開始するかもしれない。もし、MNがriggerisを
受信したら、MNはProxyRouterSolicitationをoARに送信しLayer3ハンドオーバを
開始する。代わりに、riggerisはoARに受信され、要求の必要なしに、
ProxyRouterAdvertisementを適切なMNに伝送するだろう。基本的な高速ハンドオ
ーバメッセージ交換をFigure.A.1に示す。


                    +-----------+  1a. HI          +-----+ 
                    |           | ---------------->| nAR | 
                    |    oAR    |  1b. HAck        |     | 
                    +-----------+ <--------------- +-----+ 
                    ^  |        ^               
      (2a. RtSolPr) |  | 2b     |             
                    |  | Pr     | 3. Fast BU (F-BU) 
                    |  | RtAdv  | 4. Fast BA  (F-BACK)              
                    |  v        v 
                    +------------+                     
                    |    MN      |   
                    +------------+    - - - - - -> 
                                      Movement 
   
                   Figure A.1 MIPv6高速ハンドオーバプロトコル

MNはoARに接続されている間、nARからの情報を含むRAによって新しいCoAを入手
する。oARはHandoverInitiateメッセージをnARに送信することでMNの新しいCoA
を承認する。新しいCoAは、nARのプレフィックスにMNのurrentインタフェース識
別子を追加した形のHIメッセージを尊信する。HandoverAckメッセージで発生す
る応答に基づいて、MNの新たなCoAにトンネルを設定するか、またはnARのアドレ
スにトンネルを設定する。もし、アドレスが新たなサブネットで利用されている
なら、nARがMNのために古いCoAを利用しホストへのルートを設定するように、新
しいリンク上のCoAでMNを構成するのとは別のことを試みる時間は無いと思われ
る。メッセージ1a,1bの発生する順番に注意。

[12]においてHAはローカルのHAとして動作すると同時に、MNと受信したBUのため
にBCを管理する。これで、この文章で指定したようにARはMAPのように動作する。
また、ARが直接接続させないことも、かなり可能だが集合ルータを経由して通信
する。従ってそのような集合ルータもまたMAP機能のために理想的位置です。こ
れはHMIPv6と高速ハンドオーバメカニズムを統合する2つの方法です。一番目は、
通常のステップとして、ARの代わりにMAPを設置する必要があります。2番目の
方法は、集合ルータであるbovetheARを設置する必要があります。この場合、[12]
はoARとnAR間のパケット転送を指定する。パケットはMAP-oAP間のリンク2本を
妨害し、MNにとって不適切なパケットが到達するため、帯域幅の効率にとっては
遅延により効率が悪い。集合ルータ内でMAPを使い、高速ハンドオーバの効果の
改善と同時に、通信経路を向け直すために利用できるかもしれない、このように、
集合ルータとoAR間の帯域や遅延の抑制をする。

                                                +---------+ 
                                                |   MAP   | 
                                +-------------->|         | 
                                |               +---------+ 
                                |                 |     ^     
                                |          1a. HI |     | 
                                |                 |     | 
                                |                 |     | 1b. HAck 
                                |                 v     | 
                 +---------+    |               +---------+ 
                 |         |    |               |   nAR   | 
                 |   oAR   |    |               |         | 
                 +---------+    |               +---------+ 
                    ^  |        |              
      (2a. RtSolPr) |  | 2b     |             
                    |  | Pr     | 3. Fast BU (F-BU) from mobile node to  
                    |  |             MAP 
                    |  | RtAdv  | 4. Fast BA (F-BACK) from MAP to  
                    |  |        |    mobile node             
                    |  v        v 
                   +------------+                     
                   |     MN     |    Movement 
                   +------------+    - - - - - -> 
        Figure A.2 HMIv6でMIPv6高速ハンドオーバプロトコルを使う 
   
図A.2において、新しいCoAが有効でないなら、HI/HAckメッセージは現在新たに
要求された新しいCoAの妥当性と一時的なトンネルの設置を検証するために生じ
ます。それゆえ、高速ハンドオーバ手順と同じ機能は維持するが、アンカーポイ
ントはoARからMAPに移動する。

以前の高速ハンドオーバ手順のように、レイヤ2のネットワークに限定した場合、
oARはoARにMAPオプションと共に代理RAをMNに送信させるさろう。移動環境に限
定した場合、これはMNの代理RSに優先させる。同じレイヤ2においてoARとnARの
間で、Context Transferを開始することにネットワークが限定する場合、
riggerat oARを利用することができる。移動環境に限定した場合、oARのきっか
けを代理RSかF-BUの受信に置き換えることができる。ContextTransferはIETF
Seamoby WGで協議されている。

高速ハンドオーバとHMIPv6の組み合わせは、移動を行う以前に、効率的にMNの新
しい位置にデータ通信を向けなおすことができるようにレイヤ3ハンドオーバを
予期することを許す。しかしながら、MAPからMNの新しい位置へ転送を開始する
のに、影響力を持つスムーズなハンドオーバを行うための訂正時間を決定するの
は簡単でない。oARとnARの間で転送を開始する時に、[12]に関して同じ問題が発
生する。もしMNがoARを離れnARに接続するのに、時間に的に早すぎたり遅すぎた
りするとパケットロスがおこるだろう。MAPがnticipatedF-BUを受け取るのに登
録情報を更新するなら、そうやってパケットロスが発生するように、いつMNが
F-BUを送信したのかに比例して、いつnARへのハンドオーバが完了もしくは実行
したのかが認識されていない。また、なんらかの評価が、MNがレイヤ2ハンドオ
ーバに突然失敗したり、MNが頻繁にAR間を行ったりきたりする場合、サポートが
必要です。[13]の同時登録はこれらの解決策を示します。[13]では、新たに同時
登録フラグをF-BUメッセージと、F-BAckメッセージに新たに同時登録サブオプシ
ョンを追加する。この機能を高めたメカニズムを利用することで、レイヤ3ハン
ドオーバにおいて、ハンドオーバタイミングのようなレイヤ2の影響からMNを独
立させ、行ったり来たりかハンドオーバの失敗と連続通信をMNに提供することで、
MNへのトラフィックをMAPからoARとnAR両方に送るだろう。

コメント、訂正、まとめ等お願いします。

名前:
コメント:

タグ:

+ タグ編集
  • タグ:

このサイトはreCAPTCHAによって保護されており、Googleの プライバシーポリシー利用規約 が適用されます。

人気記事ランキング
目安箱バナー