(57)【要約】【課題】ＲＩＰｎｇを支援するＩＰｖ６ルータのインターフェースに多重ソースアドレスが指定される場合のルーティングテーブル管理において発生する混乱を防止できるようにする。【解決手段】各インターフェースごとに固有なインターフェースＩＤを用いてルーティングテーブルを管理する本発明によれば、ソースルータがルートエントリーの第１フィールドに所定値を指定し且つ第２フィールドにインターフェースＩＤ値を指定して生成されたルーティング情報を含んだルーティング情報パケットを受信ルータに伝送し、受信ルータでは、受信したルーティング情報パケットの第１フィールド値が所定値ならば、その第２フィールド値と同一なインターフェースＩＤ値を有するルートエントリーのルーティング情報を、受信されたルーティング情報パケットのルーティング情報に更新する。【選択図】図７
2004312683.tif 000002
【特許請求の範囲】
【請求項１】
複数個のルータと複数個のホストで構成されたネットワークに適用されるルーティングテーブル管理方法において、
ルートエントリーの第１フィールドに所定値を且つ第２フィールドにインターフェースＩＤ値を第１ルータにより各々指定して生成されたルーティング情報を含んだルーティング情報パケットを第２ルータに伝送する第１段階と、
前記第２ルータにより、前記第１ルータから受信したルーティング情報パケットの前記第１フィールド値を抽出して、該抽出された第１フィールド値が前記所定値ならば、当該ルーティング情報パケットから前記第２フィールド値を抽出する第２段階と、
前記抽出された第２フィールド値と同一なインターフェースＩＤ値を有するルートエントリーのルーティング情報を、前記受信されたルーティング情報パケットのルーティング情報に更新する第３段階と、を含むことを特徴とするルーティングテーブル管理方法。
【請求項２】
第２フィールドに指定されるインターフェースＩＤ値は、ＭＡＣアドレスを用いて生成される請求項１に記載のルーティングテーブル管理方法。
【請求項３】
第１段階は、
第１ルータがインターフェース情報からインターフェースＩＤを抽出する段階と、
前記第１ルータがルートエントリーの第１フィールドに所定値を指定する段階と、
前記第１ルータがルートエントリーの第２フィールドに前記抽出されたインターフェースＩＤ値を指定する段階と、
前記所定値が指定された第１フィールド及び前記インターフェースＩＤが指定された第２フィールドを含むルーティング情報を含んだルーティング情報パケットを生成する段階と、
前記第１ルータが当該生成したルーティング情報パケットを前記第２ルータに伝送する段階と、を含む請求項１に記載のルーティングテーブル管理方法。
【請求項４】
第３段階は、
第２フィールド値と同一なインターフェースＩＤ値と、該同一なインターフェースＩＤ値を有するルートエントリーがルーティングテーブルに存在するかを判断する段階と、
ａ）前記判断の結果、インターフェースＩＤ値の同じルートエントリーがルーティングテーブルに存在すれば、該ルートエントリーのルーティング情報を、受信されたルーティング情報パケットのルーティング情報でアップデートし、
ｂ）前記判断の結果、インターフェースＩＤ値の同じルートエントリーがルーティングテーブルに存在しなければ、受信されたインターフェースＩＤ値をソースルータのインターフェースＩＤ値に指定し、受信されたルーティング情報パケットのルーティング情報を利用してルートエントリーを生成する段階と、を含む請求項１に記載のルーティングテーブル管理方法。
【請求項５】
第１ルータと第２ルータとの間のルーティングプロトコルにＩＧＰが用いられる請求項１または請求項３に記載のルーティングテーブル管理方法。
【請求項６】
第１ルータと第２ルータとの間のルーティングプロトコルにＲＩＰｎｇが用いられる請求項１または請求項３に記載のルーティングテーブル管理方法。
【請求項７】
第１フィールドはメトリック指定フィールド、第２フィールドはプリフィクスフィールドである請求項１または請求項３に記載のルーティングテーブル管理方法。
【請求項８】
メトリック指定フィールドのフィールド値として１７〜２５５のうち少なくとも一つを用いる請求項７に記載のルーティングテーブル管理方法。
【請求項９】
メトリック指定フィールドのフィールド値として２５５を用いる請求項７に記載のルーティングテーブル管理方法。
【請求項１０】
ルーティングテーブル管理方法において、
ルートエントリーの第１フィールド値がルーティングプロトコルの受信パケットに対する所定値なのか否かを受信ルータにより決定する段階と、
前記第１フィールド値が所定値でない場合、現存のルーティングプロトコルのプロセスを前記受信ルータにより実行する段階と、
前記第１フィールド値が所定値である場合、ソースルータのインターフェースＩＤが指定される第２フィールドから第２フィールド値を抽出し、同一なインターフェースＩＤを有するルーティングテーブルの存在可否を前記受信ルータにより判断する段階と、
該判断の結果、同一なインターフェースＩＤがルーティングテーブルに存在する場合、該ルーティングテーブルを受信ルータによりアップデートする段階と、
同一なインターフェースＩＤがルーティングテーブルに存在しない場合、ソースルータのインターフェースＩＤとして抽出された前記第２フィールド値を受信ルータにより貯蔵する段階と、を含むことを特徴とするルーティングテーブル管理方法。
【請求項１１】
第２フィールドに指定されたインターフェースＩＤは、ＭＡＣアドレスを利用して生成される請求項１０に記載のルーティングテーブル管理方法。
【請求項１２】
ルーティングテーブル管理システムにおいて、
ルートエントリーの第１フィールドに所定値を且つ第２フィールドにインターフェースＩＤ値を各々指定して生成されたルーティング情報を含んだルーティング情報パケットを第２ルータに伝送する第１ルータと、
ａ）該第１ルータから受信された前記ルーティング情報パケットの第１フィールド値を抽出し、
ｂ）該抽出された第１フィールド値が所定値ならば、前記ルーティング情報パケットから前記第２フィールド値を抽出し、
ｃ）該抽出した第２フィールド値と同一なインターフェースＩＤ値を有するルートエントリーのルーティング情報を、前記受信されたルーティング情報パケットのルーティング情報に更新する、前記第１ルータと通信可能な第２ルータと、を備えることを特徴とするルーティングテーブル管理システム。
【請求項１３】
第１ルータは、
ａ）インターフェース情報からインターフェースＩＤを抽出し、
ｂ）ルートエントリーの第１フィールドに所定値を指定し、
ｃ）該ルートエントリーの第２フィールドに前記抽出されたインターフェースＩＤを指定し、
ｄ）前記所定値が指定された第１フィールドと前記インターフェースＩＤが指定された第２フィールドとを含むルーティング情報を含んだルーティング情報パケットを生成し、
ｅ）該生成したルーティング情報パケットを第２ルータに伝送する請求項１２に記載のルーティングテーブル管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＩＰｖ６（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ６）におけるルーティングテーブル管理方法及びシステムに係り、特に、ＲＩＰｎｇ（Ｒｏｕｔｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ｎｅｘｔ  ｇｅｎｅｒａｔｉｏｎ）を支援するＩＰｖ６ルータそれぞれのインターフェースごとに固有なインターフェースＩＤ（Ｉｎｔｅｒｆａｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を用いてルーティングテーブルを管理できるようにすることによって、多重ソースアドレスによるルーティングテーブル管理上の混乱を防止することができるようにする、ＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステムに関する。
【背景技術】
【０００２】
コンピュータのインターネット（Ｉｎｔｅｒｎｅｔ）通信を提供する標準プロトコルであるＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）は、他のネットワークプロトコルと同様に階層で構成されているが、これをプロトコルスタック（ｓｔａｃｋ）、プロトコルスート（ｓｕｉｔ）またはプロトコル構造という。
【０００３】
ＴＣＰ／ＩＰプロトコルスタックは、ＴＣＰとＩＰという２個の最も重要なプロトコルを基盤にして構成されているが、ＩＰプロトコルはＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ）階層３に該当するプロトコルであって現在バージョン４（ＩＰｖ４）が主に用いられており、物理的なサブネットワーキングの連結と目的地ＩＰアドレスを探していく経路を選択する機能がある。
【０００４】
このためにＩＰプロトコルは、インターネットに連結した多くの端末（ｔｅｒｍｉｎａｌｓ）やノード（ｎｏｄｅ；ＩＰプロトコルを具現する装置）の送信アドレスと受信アドレスを付与して解析する。現在インタネットワーク層では３２−ビットＩＰアドレスを用いてネットワーク上のホスト間相互通信を行う。ＩＰアドレスはネットワークＩＰとノードＩＰ（ホストＩＰ）を用いて特定ノードを区別する。
【０００５】
９０年代以後、インターネット使用の爆発的な増加によってＩＰｖ４プロトコルは割当可能な資源の不足、移動性（ｍｏｂｉｌｉｔｙ）欠如、保安性欠如などの短所によって改善の必要性が要求されて、このような短所を解決するための新しい標準プロトコルであるＩＰｖ６が開発された。
【０００６】
次世代ＩＰ（ＩＰｎｇ；Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｎｅｘｔ  ｇｅｎｅｒａｔｉｏｎ）とも呼ばれるＩＰｖ６プロトコルは、ＲＦＣ  ２４６０（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ２４６０）標準文書に記述されている。ＩＰｖ６プロトコルはＩＰアドレスの長さを既存の３２−ビットから１２８−ビットに拡張したことにより、インターネットアドレス資源枯渇問題を解決することができ、マルチメディアデータをリアルタイムに処理することができるようにするものである。ＩＰｖ６プロトコルは、ＩＰｖ４プロトコルでは保安機能のために'Ｉｐｓｅｃ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｉｔｙ  Ｐｒｏｔｏｃｏｌ）'というパッチ（ｐａｔｃｈ）形態のプロトコルを別途に設置しなければならなかった問題を解決して、ＩＰｓｅｃをプロトコル内に搭載することによって保安機能を強化できるようにする等の長所がある。
【０００７】
ところが、ＩＰｖ６プロトコルは、ＩＰｖ４プロトコルと相異なるヘッダー構造を有しているために、両者のプロトコル間には互換性がない。したがって、今後は、ＩＰｖ４網が徐々にＩＰｖ６網やＩＰｖ４とＩＰｖ６を同時に支援する網に代替される展望である。また、最近では、ＩＰｖ６プロトコルの使用が多様な試験網と一部商用網を通じて徐々に拡大されている。
【０００８】
ＩＰｖ６応用ＴＣＰ／ＩＰ標準プロトコルは、アプリケーション階層（Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｙｅｒ）、ＴＣＰまたはＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）で具現される伝送階層（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ）、ＩＰｖ６及び／またはＩＣＭＰｖ６（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  ＰｒｏｔｏｃｏｌｆｏｒＩＰｖ６）で具現されるインタネットワーク階層（Ｉｎｔｅｒｎｅｔｗｏｒｋ  Ｌａｙｅｒ）及び物理階層（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ）で構成される。
【０００９】
ＩＰｖ６データグラム（ｄａｔａｇｒａｍ）は、ＩＰｖ４と同様にヘッダーとペイロード（ｐａｙｌｏａｄ）２個部分で構成される。ペイロードは２個のホスト間で伝送されるデータを伝達する部分である。ＩＰｖ６ヘッダーは４０−バイトの固定サイズを有し、ＩＰｖ４で深刻なボトルネックとして明らかだったヘッダーチェック・サムフィールドをもたない。ＩＰｖ６プロトコルはＩＰｖ４プロトコルでは支援しない移動性支援、保安性支援、マルチメディア応用の品質保障などのためのヘッダー構造を有する。
【００１０】
そして、ＩＰｖ６標準プロトコルのヘッダーは、４−ビットのバージョンフィールド、８−ビットのトラフィッククラスフィールド、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）と関連した２０−ビットのストリームラベルフィールド、データの長さを示す１６−ビットの無符号整数ペイロード長フィールド、ＩＰｖ６ヘッダーから次に続くヘッダーの類型を定義する８−ビットのＮＨ（Ｎｅｘｔ  Ｈｅａｄｅｒ）フィールド、パケットをフォワードする各ノードで１ずつ減少する８−ビットの無符号整数ホップフィールド、パケット送信者の１２８−ビットアドレスを示す発信地アドレスフィールド、パケット受信者の１２８−ビットアドレスを示す目的地アドレスフィールドを、基本ヘッダーフィールドに含むことができる。
【００１１】
ＩＰｖ６を完壁に具現するために含まれる拡張ヘッダーフィールドは、ホップ−バイ−ホップ（Ｈｏｐ−ｂｙ−Ｈｏｐ）オプションフィールド、目的地オプションヘッダー、ルーティングヘッダー、フラグメント（Ｆｒａｇｍｅｎｔ）ヘッダー、認証ヘッダー、ＥＳＰ（Ｅｎｃａｐｓｕｌａｔｉｎｇ  Ｓｅｃｕｒｉｔｙ  Ｐａｙｌｏａｄ）ヘッダーなどを含むことができる。
【００１２】
ところが、このようなＩＰｖ６標準プロトコルは、主にＰＣを用いる環境に適しているようにソフトウェアで具現されており、普通はウィンドウズ（Ｗｉｎｄｏｗｓ）（登録商標）、リナックス（Ｌｉｎｕｘ）（登録商標）、リアルタイム（Ｒｅａｌ−ｔｉｍｅ）ＯＳ等のようなＯＳにより処理されている。
【００１３】
一方、ルーティングプロトコルは、２種の一般的な範ちゅう、すなわち内部ゲートウエープロトコル（ＩＧＰ：Ｉｎｔｅｒｉｏｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）と外部ゲートウエープロトコル（ＥＧＰ：Ｅｘｔｅｒｉｏｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）に分けることができる。
【００１４】
ＩＧＰは、一ドメイン内で用いられるルーティングプロトコルであって、ＩＰｖ４で現在用いられる代表的なＩＧＰ用プロトコルとしてはＲＩＰ（Ｒｏｕｔｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、ＯＳＰＦ（Ｏｐｅｎ  Ｓｈｏｒｔｅｓｔ  Ｐａｔｈ  Ｆｉｒｓｔ）、ＩＳ−ＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｓｙｓｔｅｍ  ｔｏ  Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｓｙｓｔｅｍ）などがある。
【００１５】
ＥＧＰは、相異なるドメイン間、特にＡＳｓ（Ａｕｔｏｎｏｍｏｕｓ  Ｓｙｓｔｅｍｓ）間でルーティング情報を交換するために用いられるプロトコルであって、ＩＰｖ４の代表的なＥＧＰ用プロトコルとしてはＢＧＰ（Ｂｏｒｄｅｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）等がある。
【００１６】
ＩＧＰは、ＥＧＰがルーティング情報を一つ以上のＡＳ間に伝達する期間、ＡＳ内でルーティング情報を伝達する。
【００１７】
原理的にＩＰｖ６ルーティング技術は、既存のＩＰｖ４と違う点がない。ただしルーティング政策面でＩＰｖ４よりはルート（ｒｏｕｔｅ）集合化（ａｇｇｒｅｇａｔｉｏｎ）等ＩＰｖ６アドレッシングによる厳格な規定を定義して、これに合うようにルーティングプロトコルを設定して運用しなければならないという点が違うだけである。
【００１８】
現在標準化されたり標準化中であるＩＰｖ６を支援するルーティングプロトコルは次の通りである。
【００１９】
ＩＰｖ６用ＩＧＰプロトコル：ＲＩＰｎｇ・ＯＳＰＦｖ６・ＩＰｖ６支援ＩＳ−ＩＳ
【００２０】
ＩＰｖ６用ＥＧＰプロトコル：ＢＧＰ４+
【００２１】
ＲＩＰは、距離ベクトル（ｄｉｓｔａｎｃｅ  Ｖｅｃｔｏｒ）基盤のアルゴリズムで具現された現在最も多く用いられているＩＧＰ用プロトコルである。
【００２２】
１９８８年に最初にこのプロトコルに対する定義が下されてＲＦＣ１０５８で標準化された。
【００２３】
ＲＩＰは、距離ベクトルアルゴリズムを基盤にしたプロトコルであって、プロトコル自体は簡単な反面、中小規模ネットワークのために設計されており、次のようなプロトコル自らの限界を有している。
【００２４】
第一に、最も長い経路が１５ホップであるネットワークに限定される。第二に、ルーティングループなどの状況を解決するために"無限大までカウンティング(counting unto infinity)"と呼ばれるプロセスを用いる。このプロセスは問題が解決される前に多量のネットワーク資源を消耗するようになる。
【００２５】
第三に、遅延、信頼度や負荷などのリアルタイムパラメーターに対する考慮はなく、代替経路を比較するために固定された測定基準を用いる。
【００２６】
ＲＩＰプロトコルは、ＲＦＣ  １７２３（ＲＩＰｖ２）に続いてＲＦＣ  ２０８０（ＩＰｖ６を支援するＲＩＰｎｇ規格）が定義されている。
【００２７】
図１は、一般的なＲＩＰｎｇのルーティングテーブルの構造を示した図面である。
【００２８】
図１に示したように、ＲＩＰｎｇが管理する一般的なＩＰｖ６用ルーティングテーブルエントリーは、目的地のＩＰｖ６プリフィクス（ｐｒｅｆｉｘ）１０、目的地までデータグラムを伝送するのに必要とされる全体費用（コスト）を表示するメトリック（ｍｅｔｒｉｃ）１６、ネクストホップ（ｎｅｘｔｈｏｐ）を示すｎｅｘｔ  ｒｏｕｔｅｒのＩＰｖ６アドレス（ｎｅｘｔｈｏｐ  ａｄｄｒｅｓｓ）２４、最近ルータが変化したか否かに対する情報を示す経路変化フラッグ（ｆｌａｇ）１８、ルーティングテーブル情報を隣のルータに伝送するのに必要な３０秒タイマー（ｔｉｍｅｏｕｔ  ｔｉｍｅｒ，ｇａｒｂａｇｅ  ｃｏｌｌｅｃｔｉｏｎ  ｔｉｍｅｒ）２０，２２の情報を有しなければならない。
【００２９】
ＲＩＰｎｇは、ＵＤＰ基盤のプロトコルであってＵＤＰポート番号５２１上でパケットを送受信する。ＲＩＰｎｇパケットはコマンド（要請または応答）、バージョンそして経路テーブルエントリーの３種のフィールドを含んでいる。
【００３０】
それぞれの経路テーブルエントリーは、ＩＰｖ６プリフィクス、外部ルータから内部ルータを分離させる経路タグ、プリフィクス内の重要なビット数を決定するプリフィクス長フィールド、そして現在の目的地メートルを定義するメーターを含んでいる。
【００３１】
この他にＲＩＰｎｇは、パケットのために即時に次のホップＩＰｖ６アドレスを明示する機能を提供する。次のホップは特定ＲＴＥ（Ｒｏｕｔｅ  Ｔａｂｌｅ  Ｅｎｔｒｙ）パケットとＮｅｘｔ  Ｈｏｐ  ＲＴＥ（Ｒｏｕｔｅ  Ｔａｂｌｅ  Ｅｎｔｒｙ）パケットを通じて指定される。
【００３２】
Ｎｅｘｔ  Ｈｏｐ  ＲＴＥ（Ｒｏｕｔｅ  Ｔａｂｌｅ  Ｅｎｔｒｙ）パケットは、メトリックフィールドでＦＦＨ値により識別される。経路タグとプリフィクス長さは送信時ゼロに設定して受信時には無視される。
【００３３】
この時ＲＩＰｎｇのネクストホップは、受信したＲＩＰｎｇパケットのネクストホップフィールド（ｆｉｅｌｄ）に明示される場合もあるしそうでない場合もある。
【００３４】
普通は０：０：０：０：０：０：０：０に指定され、受信したＲＩＰｎｇパケットのネクストホップが０：０：０：０：０：０：０：０である時、そのパケットを送信したルータのアドレスをネクストホップアドレスに指定する。
【００３５】
もしもネクストホップアドレスが明示されている場合、このアドレスは必ずリンクローカルアドレス（ｌｉｎｋ−ｌｏｃａｌ  ａｄｄｒｅｓｓ）でなければならない。
【００３６】
なぜならＲＩＰｎｇは、ＩＰｖ４バージョンであるＲＩＰがデザインされた時、内部ゲートウエープロトコル（ＩＧＰ：Ｉｎｔｅｒｉｏｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）でデザインされてｄｉｒｅｃｔｌｙ−ｃｏｎｎｅｃｔｅｄネットワークでだけその情報が有効で、リンクローカル範囲（ｌｉｎｋ−ｌｏｃａｌｓｃｏｐｅ）で用いられるためにリンクローカルアドレスだけを用いる。
【００３７】
すなわち、ＲＩＰｎｇではデータグラムのＩＰｖ６ソースアドレス（ｓｏｕｒｃｅ  ａｄｄｒｅｓｓ）は必ずリンクローカルアドレスでなければならない。
【００３８】
ＲＩＰｎｇバージョン１は、要請と応答という２種のコマンドを支援する。要請はルーティングテーブル全部または一部を要求するのに用いられる。大部分の場合要請はＲＩＰｎｇ（ポート５２１）からマルチキャスターとして送信される。
【００３９】
単にルータ一つに対する情報が必要である場合の要請は、ＲＩＰｎｇポート以外に他のポートからそのルータに直接送信されることになる。
【００４０】
応答には特定質疑に対する応答、すべての隣接したルータに３０秒ごとに送信される応答である規則的なアップデート、そしてルータ変化を起こすアップデートの３つの応答タイプがある。
【００４１】
要請と応答パケット処理に対する定義はＲＦＣ  ２０８０、ＲＦＣ  ２０８１で定義されている
【００４２】
ＲＦＣ  ２０８０によれば、ＲＩＰｎｇで応答メッセージを発生することにおいて、ＲＩＰｎｇポートでない他のポートのユニキャスト要求メッセージに対して応答する場合以外にはＩＰｖ６ソースアドレスとして送信側ルータインターフェースの使用可能なリンクローカルアドレスが用いられなければならない。
【００４３】
ユニキャスト要求メッセージに対する応答の場合に用いるソースアドレスは、グローバルに有効なアドレス（ｇｌｏｂａｌｙ  ｖａｌｉｄ  ａｄｄｒｅｓｓ）でなければならない。
【００４４】
そしてルータの使用可能なリンクローカルアドレスをＩＰｖ６ソースアドレスとして用いることは応答メッセージを受信した受信側ルータがルーティングテーブルの次のホップとしてソースアドレスを用いるためである。
【００４５】
もしも誤ったソースアドレスを用いれば、他のルータはデータグラムをルーティングできない。
【００４６】
時々ルータは、複数個のＩＰｖ６アドレスを一つの物理的なインターフェースのためのアドレスとして用いる。
【００４７】
通常これは、いくつかの論理的なＩＰｖ６のネットワークが一つの物理的な媒体により具現されることができるものを意味する。
【００４８】
一つのルータが一つの物理的なインターフェースのために複数のリンクローカルアドレスを用いることが可能である。
【００４９】
図２は、一般的なＩＰｖ６ルータのインターフェースに指定された多重ソースアドレスの例示図であって、ＩＰｖ６ルータの一つのインターフェースに多重のグローバルＩＰｖ６アドレス（ｍｕｌｔｉｐｌｅ  ｇｌｏｂａｌ  ＩＰｖ６  ａｄｄｒｅｓｓｅｓ）が指定されたり、多重のリンクローカルＩＰｖ６アドレス（ｍｕｌｔｉｐｌｅｌｉｎｋ−ｌｏｃａｌ  ＩＰｖ６  ａｄｄｒｅｓｓｅｓ）の指定が可能なものを示す。
【００５０】
図２を参照すれば、ＩＰｖ６ルータのインターフェースｅｔｈ０には多重のＩＰｖ６リンクローカルアドレスが、ＩＰｖ６ルータのインターフェースｅｔｈ１は多重のＩＰｖ６グローバルアドレスが指定されている。
【００５１】
このようにＩＰｖ６ルータ一つのインターフェースに多重ソースアドレスが指定される理由は、いくつかのソースアドレスと目的地アドレスのうち最適のアドレスを選択して用いることによって目的地までの最も効率的なルーティング経路を探すためである。
【００５２】
このために最適のソースアドレスと目的地アドレスを選択するための技法が現在活発に研究中にある。
【００５３】
一方、このように一つのルータが一つの物理的なインターフェースのために複数のリンクローカルアドレスを用いる場合にルータは、インターフェースのために定義されたリンクローカルアドレスのうちから一つのソースアドレスを用いて応答メッセージを生成しなければならない。
【００５４】
そして、現在使用中のローカルアドレスが有効でない場合に他のローカルアドレスに交替して用いるようになる。
【００５５】
そしてこのようなソースアドレスの交替は、応答メッセージを受信した受信側ノードがソースアドレスで送信側を区別するために用いるために必要である。
【００５６】
もしも同一ルータから他のソースアドレスを用いたマルチパケットをルータが受信するようになれば、ルータはマルチパケットが相異なるルータから受信されたと推測するようになって望ましくない動作を誘発するようになる。
【００５７】
すなわち、同じルータから受信したいくつかのパケットが各々他のリンクローカルアドレスをソースアドレスに指定しているならば、パケットを受信したＲＩＰｎｇルータはこのパケットを各々他のルータから受信したとして処理する。
【００５８】
そして、ネットワークプリフィクスを含んでいるパケットを伝送するルータがいままで用いたリンクローカルアドレスがこれ以上有効でなくなって新しいリンクローカルアドレスをソースアドレスに指定して伝送するとしても、受信するルータ側ではこのパケットを他のルータから受信したとして処理するようになる。
【００５９】
例えば、Ｒ１ルータがＩ１インターフェースに指定されたｆｅ８０：：１：２：３：４／１０というリンクローカルアドレスをソースアドレスとしてＲ２ルータにメトリックが３である１０．０．０．０／８に関するルーティング情報を伝送した後、次のアップデート周期内にｆｅ８０：：１：２：３：４／１０アドレスが有効でなくなってｆｅ８０：：５：６：７：８／１０アドレスをソースアドレスに選択し、メトリックが５に変えられてＲ２ルータに１０．０．０．０／８に関するアップデートパケットを伝送すると仮定する。
【００６０】
この時、Ｒ２ルータは、以前に受信したルーティング情報と二番目に受信したルーティング情報が相異なるソースルータから受信したものと考えて、これに対するＤｅｃｉｓｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ過程を遂行する。
【００６１】
その結果、二番目に受信したメトリックが５であってプリフィクスが１０．０．０．０／８であるルーティング情報は無視される。すなわち、ＩＰｖ６ルータは多重のリンクローカルアドレスを用いることによってソースアドレス選択において混とんをもたらす可能性があり、受信側ルータでは誤ったルーティング情報をルーティングテーブルにもつ可能性がある。
【００６２】
以上の例のように、ＲＩＰｎｇルータの誤った動作を防止するためにソースアドレス選択に関するいろいろなアルゴリズムが研究中にある。しかしこのアルゴリズムは多重のアドレスのうちどのアドレスをソースアドレスとして選択するかに関する技法であって、アルゴリズムによってソースアドレスを選択するうちにソースアドレスが変えられる場合には、同様にＲＩＰｎｇルータに混とんを引き起こす可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【００６３】
本発明は上記のような問題点を解決するために案出されたものであって、本発明の目的は、ＲＩＰｎｇを支援するＩＰｖ６ルータのインターフェースに多重ソースアドレスが指定されてルーティングテーブルを管理する際に発生する混乱を防止することができるようにした、ＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステムを提供することにある。
【００６４】
また本発明の他の目的は、一つのインターフェースに多重リンクローカルＩＰｖ６アドレスを指定することによるルーティング問題を防止することができるようにしたルーティングテーブル管理方法及びシステムを提供することにある。
【課題を解決するための手段】
【００６５】
このような目的を達成するための本発明によるＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法の一態様では、複数個のルータと複数個のホストで構成されたネットワークに適用されるルーティングテーブル管理方法において、ルートエントリーの第１フィールドに所定値を且つ第２フィールドにインターフェースＩＤ値を第１ルータにより各々指定して生成されたルーティング情報を含んだルーティング情報パケットを第２ルータに伝送する第１段階と、第２ルータにより、第１ルータから受信したルーティング情報パケットの第１フィールド値を抽出して、該抽出された第１フィールド値が所定値ならば当該ルーティング情報パケットから第２フィールド値を抽出する第２段階と、その抽出された第２フィールド値と同一なインターフェースＩＤ値を有するルートエントリーのルーティング情報を当該ルーティング情報パケットのルーティング情報に更新する第３段階と、を含むことを特徴とする。
【００６６】
その第２フィールドに指定されるインターフェースＩＤは、ＭＡＣアドレスを用いて生成可能である。
【００６７】
本方法の第１段階は、第１ルータがインターフェース情報からインターフェースＩＤを抽出する段階と、第１ルータがルートエントリーの第１フィールドに所定値を指定する段階と、第１ルータが、抽出されたインターフェースＩＤをルートエントリーの第２フィールドに指定する段階と、所定値が指定された第１フィールドとインターフェースＩＤが指定された第２フィールドとを含むルーティング情報を含んだルーティング情報パケットを生成する段階と、第１ルータが、生成したルーティング情報パケットを第２ルータに伝送する段階とを含む。
【００６８】
また、本方法の第３段階は、第２フィールド値と同一なインターフェースＩＤ値と、該同一なインターフェースＩＤ値を有するルートエントリーがルーティングテーブルに存在するかを判断する段階と、ａ）その判断の結果、インターフェースＩＤの同じルートエントリーがルーティングテーブルに存在すれば、該ルートエントリーのルーティング情報を、受信されたルーティング情報パケットのルーティング情報でアップデートし、ｂ）判断の結果、インターフェースＩＤの同じルートエントリーがルーティングテーブルに存在しなければ、受信されたインターフェースＩＤ値をソースルータのインターフェースＩＤ値に指定し、受信されたルーティング情報パケットのルーティング情報を利用してルートエントリーを生成する段階とを含む。
【００６９】
これら第１ルータと第２ルータとの間のルーティングプロトコルは、ＩＧＰ（Ｉｎｔｅｒｉｏｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）を用いることが可能である。そして、第１ルータと第２ルータとの間のルーティングプロトコルは、ＲＩＰｎｇを用いることが可能である。
【００７０】
また、第１フィールドはメトリック指定フィールド、第２フィールドはプリフィクスフィールドとすることができる。ここで、メトリック指定フィールドのフィールド値として１７〜２５５のうち少なくとも一つを用い、好ましくは２５５を用いることができる。
【００７１】
本発明によるルーティングテーブル管理方法の他の態様では、ルートエントリーの第１フィールド値がルーティングプロトコルの受信パケットに対する所定値なのか否かを受信ルータにより決定する段階と、第１フィールド値が所定値でない場合、現存のルーティングプロトコルのプロセスを受信ルータにより実行する段階と、第１フィールド値が所定値である場合、ソースルータのインターフェースＩＤが指定される第２フィールドから第２フィールド値を抽出し、同一なインターフェースＩＤを有するルーティングテーブルの存在可否を受信ルータにより判断する段階と、該判断の結果、同一なインターフェースＩＤがルーティングテーブルに存在する場合、該ルーティングテーブルを受信ルータによりアップデートする段階と、同一なインターフェースＩＤがルーティングテーブルに存在しない場合、ソースルータのインターフェースＩＤとして抽出された第２フィールド値を受信ルータにより貯蔵する段階とを含むことを特徴とする。
【００７２】
さらに、本発明によるルーティングテーブル管理システムの一態様によれば、ルートエントリーの第１フィールドに所定値を且つ第２フィールドにインターフェースＩＤ値を各々指定して生成されたルーティング情報を含んだルーティング情報パケットを第２ルータに伝送する第１ルータと、ａ）該第１ルータから受信されたルーティング情報パケットの第１フィールド値を抽出し、ｂ）該抽出された第１フィールド値が所定値ならば、ルーティング情報パケットから第２フィールド値を抽出し、ｃ）該抽出した第２フィールド値と同一なインターフェースＩＤ値を有するルートエントリーのルーティング情報を、受信されたルーティング情報パケットのルーティング情報に更新するようにした、第１ルータと通信可能な第２ルータとを備える事を特徴とする。
【００７３】
その第１ルータは、ａ）インターフェース情報からインターフェースＩＤを抽出し、ｂ）ルートエントリーの第１フィールドに所定値を指定し、ｃ）該ルートエントリーの第２フィールドに、抽出されたインターフェースＩＤを指定し、ｄ）所定値が指定された第１フィールドとインターフェースＩＤが指定された第２フィールドとを含むルーティング情報を含んだルーティング情報パケットを生成し、ｅ）該生成したルーティング情報パケットを第２ルータに伝送する構成とすることができる。
【発明の効果】
【００７４】
本発明によれば、一つのインターフェースに多重のＩＰｖ６リンクローカルアドレスが指定されることによって発生し得るルーティング問題を解決することができる効果がある。
【００７５】
また、本発明によれば、デフォルトアドレス選択技法（ｄｅｆａｕｌｔ  ａｄｄｒｅｓｓ  ｓｅｌｅｃｔｉｏｎ  ｍｅｃｈａｎｉｓｍ）においていまだにアプリケーションレベル（ａｐｐｌｉｃａｔｉｏｎ  ｌｅｖｅｌ）で解決するか否かに対する議論が続いている実情で、アプリケーションレベルより下位レベルでこれを制御するとしても物理的なインターフェース（ｐｈｙｓｉｃａｌ  ｉｎｔｅｒｆａｃｅ）の固有ＩＤを用いるならば、ソースアドレスが何であっても関係なくＲＩＰｎｇを用いることができるようにする効果がある。
【発明を実施するための最良の形態】
【００７６】
以下、本発明によるＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステムの実施形態につき、添附した図面を参照しながら詳細に説明する。
【００７７】
図３は、本発明が適用される複数のルータの連結状態図であって、多重のＩＰｖ６リンクローカルアドレスが指定されているインターフェースを有し、修正されたＲＩＰｎｇを搭載している複数のＩＰｖ６ルータRouterＡ〜Ｅと、これら複数のルータＡ〜Ｅに連結している複数のＩＰｖ６ホストHostＡ，Ｂとを備えている。ここで、ルータＡ〜ＥとホストＡ，Ｂは同じネットワーク上に設置されていなければならない。
【００７８】
修正されたＲＩＰｎｇを搭載しているソースルータＡ〜Ｅは、隣接するルータＡ〜Ｅにルーティング情報を含んだパケットを伝送する場合に、ソースアドレスの代りに用いるインターフェースＩＤを伝送する。
【００７９】
インターフェースＩＤは、各インターフェースごとに唯一のＩＤであって、一つのインターフェースに多重のＩＰｖ６リンクローカルアドレスが指定されているとしても、ＭＡＣアドレスを利用してインターフェースＩＤを生成することでインターフェースＩＤはただ一つだけ存在する。本発明においては説明の便宜のために、インターフェースＩＤを生成するのにＭＡＣアドレスを用いるイーサネット（登録商標）を例に挙げたが、イーサネット（登録商標）以外の他のリンクの場合にも標準で定義されている事項によってインターフェースＩＤを生成できる。たとえば、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ）の場合にはＲＦＣ２４９２に、トークンリングの場合にはＲＦＣ２４７０に、ＦｒａｍｅＲｅｌａｙの場合にはＲＦＣ２５９０に、ＦＤＤＩ（Ｆｉｂｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ）の場合にはＲＦＣ２４６７に、ＮＢＭＡ（Ｎｏｎ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉ  Ａｃｃｅｓｓ）の場合にはＲＦＣ２４９１に各々その標準が定義されている。
【００８０】
図１及び図２でインターフェースｅｔｈ０のリンクローカルアドレスは、２個が指定されているが、このうちｆｅ８０：：２０４：７６ｆｆ：ｆｅ６ｆ：７ｃ１ｆ／１０でｆｅ８０はプリフィクスアドレスであって、２０４：７６ｆｆ：ｆｅ６ｆ：７ｃ１ｆがインターフェースＩＤである。
【００８１】
図４Ａは、一般的なＲＩＰｎｇパケットフォーマットであって、図４Ｂはルートテーブルエントリーフォーマットである。
【００８２】
図４Ａに示したように、一般的なＲＩＰｎｇパケットフォーマットは、コマンド（ｃｏｍｍａｎｄ）３０、バージョン（ｖｅｒｓｉｏｎ）３２、複数のルートテーブルエントリー（ｒｏｕｔｅ  ｔａｂｌｅ  ｅｎｔｒｙ）４０ａ〜４０ｎで構成されており、ルートテーブルエントリー４０ａ〜４０ｎはＩＰｖ６プリフィクス５０、ルートタグ（Ｒｏｕｔｅ  Ｔａｇ）５２、メトリック（ｍｅｔｒｉｃ）５６で構成されている。また、各ルートテーブルエントリー４０ａ〜４０ｎはプリフィクス長フィールド（Ｐｒｅｆｉｘ  Ｌｅｎｇｔｈ  Ｆｉｅｌｄ）５４を含む。
【００８３】
ここでソースアドレスの代わりに用いるインターフェースＩＤは、パケット当たり一つだけあれば良いので、ＲＩＰｎｇパケットのメトリック値が０ｘＦＦの場合にプリフィクス５０にはインターフェースＩＤが指定されていることにすることができる。ここで０ｘＦＦ値を用いたことはメトリック値に１バイト（Ｂｙｔｅ）が使用可能であり、そのうちから０〜１６までが現在用いられているために１７〜２５５までが本発明と関連して使用可能であって１７〜２５５中から２５５を選択したのである。
【００８４】
一方、修正されたＲＩＰｎｇを搭載しているルータＡ〜Ｅのルーティングテーブルには、ソースルータＡ〜ＥのインターフェースＩＤ値を貯蔵するためにインターフェースＩＤフィールドを具備する。図５は修正されたＲＩＰｎｇのルーティングテーブル構造に、別途のインターフェースＩＤフィールドが備わっていることを示す。
【００８５】
図５に示したように、修正されたＲＩＰｎｇのルーティングテーブルには、目的地のＩＰｖ６プリフィクス６０、ルートタグ（ｒｏｕｔｅ  ｔａｇ）６２、プリフィクス長（Ｐｒｅｆｉｘ  ｌｅｎ）６４、目的地までの距離を示すメトリック（ｍｅｔｒｉｃ）６６、フラッグ（ｆｌａｇ）６８、タイマー（ｔｉｍｅｏｕｔ  ｔｉｍｅｒ，ｇａｒｂａｇｅ  ｃｏｌｌｅｃｔｉｏｎ  ｔｉｍｅｒ）７０，７２、ネクストホップを示すｎｅｘｔ  ｒｏｕｔｅｒのＩＰｖ６アドレス（ｎｅｘｔｈｏｐ  ａｄｄｒｅｓｓ）７４を有し、さらに、インターフェースＩＤ値を貯蔵するためのインターフェースＩＤフィールド（ｉｎｔｅｒｆａｃｅ  ＩＤ）７６を有している。
【００８６】
修正されたＲＩＰｎｇを搭載しているルータＡ〜Ｅは、ルーティング情報を含んでいるパケットが受信されると、受信されたパケットのルートテーブルエントリー４０ａ〜４０ｎのうちメトリック値が０ｘＦＦであるルートテーブルエントリーがある場合にそのプリフィクス５０にはインターフェースＩＤが貯蔵されているので、当該プリフィクスフィールドの値をそのパケットのソースルータＡ〜ＥのインターフェースＩＤフィールド７６に貯蔵する。
【００８７】
そして、ルータＡ〜Ｅは、ルートエントリーを処理する場合にインターフェースＩＤが同一であるか否かを比較して、同じ場合には同じソースルータＡ〜Ｅから受信したルートエントリーとして処理する。すなわち、インターフェースＩＤはインターフェースごとに唯一の値である。
【００８８】
この時、ルータＡ〜Ｅは、パケット受信時のソースアドレスが違う場合にインターフェースＩＤを比較し、同じ場合には、同じソースルータＡ〜Ｅから受信したエントリーとして処理する。その前には、ルーティングテーブルのネクストホップは新しいソースアドレスにアップデートする。
【００８９】
また、ルーティングテーブルを検索する時、インターフェースＩＤが同じエントリーをまず検索した後に一致するプリフィクスを選択し、この時ソースアドレスは検索する必要がない。
【００９０】
なぜならインターフェースＩＤが一致すればソースアドレスが違ったとしても同じルータＡ〜Ｅから受信したルートエントリー情報であるためである。
【００９１】
図６は、本発明に係る、送信側ルータのルーティング情報を含んだパケットの生成及び伝送過程を示すフローチャートである。
【００９２】
図６に示したように、送信側ルータはインターフェース情報から固有なインターフェースＩＤを抽出して（段階Ｓ１００）、パケット生成時の最上位ルートエントリーのメトリックフィールドに０ｘＦＦ値を指定して（段階Ｓ１０２）、ルートエントリーのプリフィクスにインターフェースＩＤが指定されていることを表示する。
【００９３】
次に、送信側ルータは、メトリックフィールドに０ｘＦＦ値が指定されているルートエントリーのプリフィクスにインターフェースＩＤ値を指定して（段階Ｓ１０４）、既存のＲＩＰｎｇパケット生成過程を経てパケット生成を完了し（段階Ｓ１０６）、生成されたＲＩＰｎｇパケットを他のルータに伝送する（段階Ｓ１０８）。
【００９４】
図７は、本発明に係る、受信側ルータのルーティング情報を含んだ受信パケットの処理過程を示すフローチャートである。
【００９５】
図７に示したように、受信側ルータは、ＲＩＰｎｇパケットが受信されると（段階Ｓ２１０）、ルートエントリーのメトリックフィールド値が０ｘＦＦなのかを判断する（段階Ｓ２１２）。
【００９６】
判断結果、メトリックフィールド値が０ｘＦＦ値でなければ既存ＲＩＰｎｇによるプロセスを進行し（段階Ｓ２１４）、メトリックフィールド値が０ｘＦＦ値ならばプリフィクスフィールドにソースルータのインターフェースＩＤ値が指定されているのでプリフィクス値を抽出して（段階Ｓ２１６）、インターフェースＩＤ値が同じルーティングテーブルが存在するかを判断する（段階Ｓ２１８）。
【００９７】
判断結果、インターフェースＩＤの同じルーティングテーブルが存在すれば当該ルーティングテーブルをアップデートして（段階Ｓ２２０）、インターフェースＩＤの同じルーティングテーブルが存在しなければソースルータのインターフェースＩＤ値で貯蔵する（段階Ｓ２２２）。
【００９８】
なお、本例ではＩＰｖ６のためのルーティングプロトコルとしてＲＩＰ（Ｒｏｕｔｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を取り扱ったが、ＯＳＰＦ（Ｏｐｅｎ  Ｓｈｏｒｔｅｓｔ  Ｐａｔｈ  Ｆｉｒｓｔ）とＩＳ−ＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｓｙｓｔｅｍ  ｔｏ  Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｓｙｓｔｅｍ）等、小規模のネットワークに用いられるＩＧＰでも使用可能である。
【００９９】
本発明の技術思想につき、上記の実施形態によって具体的に説明したが、上記実施形態は説明のためのものであり、制限のためのものでないことを注意しなければならない。また、本発明の技術分野の通常の専門家ならば本発明の技術思想の範囲で多様な実施例が可能なことを理解できるものである。
【図面の簡単な説明】
【０１００】
【図１】一般的なＲＩＰｎｇのルーティングテーブルの構造を示した図。
【図２】一般的なＩＰｖ６ルータのインターフェースに指定された多重ソースアドレスに対する一例を示した図面。
【図３】本発明が適用される複数のルータに対する連結状態を示した図。
【図４】図４Ａは一般的なＲＩＰｎｇパケットフォーマット、図４Ｂはルータテーブルエントリーフォーマット。
【図５】本発明による修正されたＲＩＰｎｇのルーティングテーブル構造を示した図。
【図６】本発明に係る送信側ルータのルーティング情報を含んだパケットの生成及び伝送過程を示すフローチャート。
【図７】本発明に係る受信側ルータのルーティング情報を含んだ受信パケットの処理過程を示すフローチャート。
【符号の説明】
【０１０１】
RouterＡ〜ＲＥ：ルータ
HostＡ，Ｂ：ホスト
【図１】
2004312683.tif 000003
【図２】
2004312683.tif 000004
【図４】
2004312683.tif 000005
【図５】
2004312683.tif 000006
【図６】
2004312683.tif 000007
【図７】
2004312683.tif 000008
【図３】
2004312683.tif 000009