(57)【特許請求の範囲】
【請求項１】
モバイル・ノードがホーム・ネットワーク内でホーム・アドレスを有し、かつ少なくとも１つのさらなるモバイル・ノードに関連するサポートする外部エージェントを有する外部ネットワーク内に一時的に接続可能である、通信ノードと前記モバイル・ノードの間でＩＰサービス品質セッションを確立する方法であって、ＩＰパケットが、前記ホーム・ネットワークを介して、前記通信ノードから前記モバイル・ノードにダイレクトされ、前記サービス品質セッションが、前記ＩＰパケット内のフロー識別情報に応じて維持され、この方法は、構成されるサービス品質セッションのフロー識別情報が、既存のサービス品質セッションのフロー識別情報と一致するかどうかを判定するステップと、一致に応じて、前記構成されるサービス品質セッションに一時ポート番号を割り振るステップとを含む方法。
【請求項２】
該一時ポート番号は、該ホーム・ネットワークと該外部ネットワークの間で割り振られる請求項１に記載の方法。
【請求項３】
該一致を判定するステップおよび該一時ポート番号を割り振るステップは、該外部ネットワーク内で実行される請求項１または２に記載の方法。
【請求項４】
該一時ポート番号は、該外部ネットワークによって該ホーム・ネットワークに通知される請求項３に記載の方法。
【請求項５】
該フロー識別情報は、該モバイル・ノードで提供されるアプリケーションの識別を含み、該一時ポート番号を割り振るステップは、前記アプリケーションの一時識別を割り振るステップを含む請求項１に記載の方法。
【請求項６】
該一時ポート番号は、該ホーム・ネットワーク内で代用され、該外部エージェントで置換される前記請求項のいずれかに記載の方法。
【請求項７】
モバイル・ノードがホーム・ネットワーク内でホーム・アドレスを有し、かつ少なくとも１つのさらなるモバイル・ノードに関連する外部エージェントを有する外部ネットワーク内に一時的に接続可能である、通信ノードと前記モバイル・ノードの間でＩＰサービス品質セッションを確立することのできるモバイルＩＰシステムであって、ＩＰパケットが、前記ホーム・ネットワークを介して、前記通信ノードから前記モバイル・ノードにダイレクトされ、前記サービス品質セッションが、前記ＩＰパケット内のフロー識別情報に応じて維持され、該モバイルＩＰシステムは、構成されるサービス品質セッションのフロー識別情報が、既存のサービス品質セッションのフロー識別情報と一致するかどうかを判定する手段と、一致に応じて、構成される前記サービス品質セッションに該一時ポート番号を割り振る手段とを備えるシステム。
【請求項８】
該手段は、該外部ネットワーク内で提供される請求項７に記載のモバイルＩＰシステム。
【請求項９】
２つのモバイル・ノードは、それぞれ、少なくとも２つの手段のそれぞれに関連し、前記手段は、前記モバイル・ノードの一方と通信ノードの間のサービス品質セッションのフロー識別情報が、前記モバイル・ノードの他方と通信ノードの間のサービス品質セッションのフロー識別情報に一致するかどうかを判定するようにさらに適合されている請求項８に記載のモバイルＩＰシステム。
【請求項１０】
該一時ポート番号を割り振る手段は、該外部ネットワーク内で提供される請求項７から９のいずれか一項に記載のモバイルＩＰシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、モバイル・インターネット・プロトコル（モバイルＩＰ）に準拠し、ネットワーク内のホスト・ノードからモバイル・ノードに送信されるメッセージに関し、詳細には、任意のモバイル・ホスト・ノードが、外部エージェントを含む外部ネットワーク内でそのネットワーク接続ポイントを変更するとき、所望のサービス品質を維持するために送信されるメッセージに関する。
【０００２】
（発明の背景）
現行のインターネット・プロトコル（ＩＰ）技術およびモバイルＩＰ技術は、特定のネットワーク（そのノードの「ホーム」ネットワーク）内で通常、接続されたホスト端末またはホスト・ノードが、異なるネットワーク内（「外部」ネットワーク）に一時的に接続し、それでも、ホーム・ネットワーク内でのそのアドレスでホスト端末に送信されたＩＰパケットまたはメッセージを受信することを可能にしている。そのネットワーク接続ポイントを変更するそのようなホスト端末は、モバイル・ノードとして知られている。
【０００３】
外部ネットワーク内でもやはりＩＰパケットを受信するためには、モバイル・ノードは、そのホーム・ネットワーク内のいわゆる「ホーム・エージェント」に登録しなければならない。そのホーム・エージェントに登録する上で、モバイル・ノードは、それを外部ネットワークにおける自らの宛先とすることができる「気付」アドレスをホーム・エージェントに提供する。次に、ホーム・エージェントは、ホーム・ネットワーク内におけるトラフィックを監視し、ホーム・エージェントが、ホーム・ネットワーク内におけるそのモバイル・ノードのホーム・アドレスに対応する宛先アドレスが付いたＩＰパケットを識別した場合、そのＩＰパケットを代行受信する。次に、ホーム・エージェントは、そのＩＰパケットを「再パック」して、外部ネットワーク内の「気付」アドレスでそのノードにそれを送信する。
【０００４】
「気付」アドレスは、共通で置かれた気付アドレスであるか、または外部気付アドレスであることが可能である。
【０００５】
ホーム・ネットワーク内のアドレスに宛てられたＩＰパケットを外部ネットワーク内の「気付」アドレスにダイレクトする技法は、モバイルＩＰで、「トンネル伝送」として知られている。「気付」アドレスにＩＰパケットをトンネル伝送する上で、元のＩＰパケットに関するある情報が、再パックされたＩＰパケット内に保持されることが重要である。例えば、ＩＰパケットの元のペイロード（つまり情報部分）を維持するのと同様に、「気付」アドレスでのモバイル・ノードは、やはり、「再パック」されたＩＰパケット内で、そのＩＰパケットが元々、そこから送信された送信元アドレスおよびホーム・ネットワーク内におけるそのモバイル・ノードのホーム・アドレスを識別できなければならない。
【０００６】
モバイル・ノードの「気付」アドレスにＩＰパケットを「トンネル伝送」するためにモバイルＩＰで知られている一技法では、元のＩＰパケットをＩＰパケット・ペイロードとして新しいＩＰパケットにカプセル化する。つまり、元のＩＰパケットは、その内容にどのような変更も加えることなく、新しいＩＰパケットのペイロード（つまり情報部分）として組み込まれる。「気付」アドレスは、新しい宛先アドレスとして新しいＩＰパケットに追加され、また新しいＩＰパケットの送信元アドレスは、ホーム・エージェントとして識別される。受信時に、「気付」アドレスでのモバイル・ノードは、新しいＩＰパケット上の「ラッピング」を取り除き、元のＩＰパケットを回復する。
【０００７】
この技法の１つの欠点は、再パックされたＩＰパケットでは、既存のＩＰサービス品質標準に準拠するサービス品質提供のサポートが容易ではないことである。
【０００８】
各ＩＰパケットは、それに関連し、またＩＰパケット内に含まれる、フロー識別情報を有し、これは、ＩＰパケット伝送に関連するサービス品質を識別する。このフロー識別情報はＩＰパケットの固定位置に存在し、そこでサービス品質（ＱｏＳ）対応経路指定／スイッチング要素がそれを探し出し、それに依存して動作することができる。ただし、カプセル化トンネル伝送技法では、ＩＰパケットを発信する送信元によってＩＰパケット内に含められたフロー識別情報は、ホーム・エージェントと「気付」アドレスの間で利用できない。
【０００９】
したがって、従来のモバイルＩＰでのカプセル化技法（そのうちの１つは、ＩＰ内ＩＰカプセル化として知られる）は、ホーム・エージェントからモバイル・ノードまで、送信元実アドレス（すなわち、通信ノードのアドレス）および宛先実アドレス（すなわち、モバイル・ノードのホーム・アドレス）、ならびにＩＰパケット内のプロトコルＩＤをシールドする。さらに、カプセル化モバイルＩＰは、ペイロード・インフラストラクチャも変更し（元のＩＰヘッダは、ペイロードの一部となる）、その改変または変更を検出できるようにそれに応じてルータが変更されていない場合、フロー区別を行うことができない。ルータを変更すること、またはたとえわずかでも改変することは、しばしば、既存のすべてのルータの大幅な再設計または再配置を必要とする。これは、ネットワークの制御および管理をはるかに複雑にする。また、これは、セキュリティ制御および相互運用性の点で問題を生じる可能性がある。
【００１０】
インターネットで使用することが提案されているサービス品質（ＱｏＳ）提供は、規格によって定義されており、ＩＰでは、サービス品質シグナリングの知られている１つの規格は、ＲＳＶＰと呼ばれる。ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、ＩＥＴＦによって定義されたＩｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｍｏｄｅｌ（ＩｎｔＳｅｒｖｅ）サービス品質フレームワーク内で使用される。Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｍｏｄｅｌは、あるタイプのトラフィックに関する特別な処置を提供し、そのトラフィックに対して複数レベルの送達サービスのなかからアプリケーションが選択を行うための機構を提供し、またＯＳＩ  ＲＭ内の層３でサービス品質パラメータに関するシグナリングを提供するように設計された。
【００１１】
ＩｎｔＳｅｒｖは、２つのクラスのサービスを定義する。Ｃｏｎｔｒｏｌｌｅｄ  Ｌｏａｄ  Ｃｌａｓｓは、ネットワークがアンロードされたとき（「それ以上ない最適の送達」と同じようにトラフィック送達を提供する。Ｇｕａｒａｎｔｅｅｄ  ＱｏＳ  Ｓｅｒｖｉｃｅ  Ｃｌａｓｓは、帯域幅保証および遅延制約を有するアプリケーションに対するトラフィックを送達する。
【００１２】
ＩｎｔＳｅｒｖは、アプリケーションとノードの間、ならびにノード間でＱｏＳ要件を通信するのに、ＱｏＳ対応ノードおよびシグナリング・プロトコルを必要とする。
【００１３】
ＲＳＶＰは、ＩｎＳｅｒｖによって使用されるＱｏＳシグナリング・プロトコルである。ＲＳＶＰは、トラフィックの通過パス上のすべてのルータ・ノードに受信側ＱｏＳ要求を提供し、ソフト状態（パス／予約状態）を維持し、この結果、各ルータ内でリソースが予約される。
【００１４】
ＲＳＶＰ／ＩｎｔＳｅｒｖサービス品質が動作するためには、フロー識別情報が、ＩＰパケット内の固定位置になければならない。ＲＳＶＰセッションは、データ伝送に先立っていわゆるパス・メッセージおよび予約メッセージを交換するホスト端末によって構成される。
【００１５】
ピア・ホスト端末間の通過パスにわたってサービス品質制御を可能にするためには、したがって、各ホスト端末は、必要なメッセージを構成し、ＲＳＶＰセッションに対応するサービス品質要求を認識する機能性を備えなければならない。
【００１６】
既存のＲＳＶＰは、モバイルＩＰに基づく移動性制御のシナリオにおいて、パス・メッセージおよび予約（Ｒｅｓｖ）メッセージをどのように具体的に処理するかを特定していない。さらに、標準モバイルＩＰの「トンネル伝送」（例えば、ＩＰ内ＩＰカプセル化）は、正しいフロー識別およびサービス・クラスの区別をできなくする。
【００１７】
したがって、本発明の目的は、モバイル・ノードが外部エージェントを含む外部ネットワーク内に一時的に接続されたとき、そのモバイル・ノードの「気付」アドレスに至るメッセージのルーティング全体にわたり、メッセージの送信元によって決定されたサービス品質要件がサポートされ得るようにする技法を提供することである。
【００１８】
（発明の概要）
本発明によれば、モバイル・ノードが、ホーム・ネットワーク内でホーム・アドレスを有し、かつ外部エージェントを有する外部ネットワーク内に一時的に接続可能である、通信ノードと前記モバイル・ノードの間でＩＰサービス品質セッションを確立する方法であって、ＩＰパケットが、前記ホーム・ネットワークを介して、前記通信ノードから前記モバイル・ノードにダイレクトされ、前記サービス品質セッションが、前記ＩＰパケット内のフロー識別情報に応じて維持され、方法は、構成されるサービス品質セッションのフロー識別情報が、既存のサービス品質セッションのフロー識別情報と一致するかどうかを判定するステップと、一致に応じて、構成される前記サービス品質セッションに一時フロー識別情報を割り振るステップとを含む方法が提供される。
【００１９】
一時フロー識別情報は、ホーム・ネットワークおよび外部ネットワークの間で割り振ることができる。一致を判定するステップおよび一時フロー識別情報を割り振るステップは、外部ネットワーク内で実行されることが可能である。この一時フロー識別情報は、ホーム・ネットワークに通知されることが可能である。フロー識別情報は、モバイル・ノードでアプリケーションによって使用されるポート番号の識別を含むことができ、そのようなポート番号間の一致に応じて、一時ポート番号が割り振られる。
【００２０】
また、本発明は、モバイル・ノードが、ホーム・ネットワーク内でホーム・アドレスを有し、かつ外部エージェントを有する外部ネットワーク内に一時的に接続可能である、通信ノードと前記モバイル・ノードの間でＩＰサービス品質セッションを確立することのできるモバイルＩＰ環境であって、ＩＰパケットが、前記ホーム・ネットワークを介して、前記通信ノードから前記モバイル・ノードにダイレクトされ、前記サービス品質セッションが、前記ＩＰパケット内のフロー識別情報に応じて維持され、モバイルＩＰ環境は、構成されるサービス品質セッションのフロー識別情報が、既存のサービス品質セッションのフロー識別情報と一致するかどうかを判定する手段と、一致に応じて、構成される前記サービス品質セッションに一時フロー識別情報を割り振る手段とを備える環境を提供する。
【００２１】
これらの手段は、外部ネットワーク内で提供されることが可能である。各モバイル・ノードが、外部エージェントおよび少なくとも２つの手段のそれぞれと関連する少なくとも２つのモバイル・ノードが、外部ネットワーク内に一時的に位置することができ、前記手段は、前記モバイル・ノードの一方と通信ノードの間のサービス品質セッションのフロー識別情報が、前記モバイル・ノードの他方と通信ノードの間のサービス品質セッションのフロー識別情報に一致するかどうかを判定するようにさらに適合されていることが可能である。少なくとも２つのモバイル・ノードは、外部ネットワーク内に一時的に接続され、前記手段は、各モバイル・ノードと関連している。
【００２２】
また、本発明は、有利には、モバイル・ノードにインターネット・プロトコルＩＰパケットをダイレクトする方法であって、前記ＩＰパケットは、前記ＩＰパケットがそこに送信される宛先アドレスを含むヘッダ部分を含み、方法は、ホーム・ネットワーク内で、前記モバイル・ノードのホーム・アドレスに対応する宛先アドレスを含む前記ＩＰパケットを受信するステップと、前記ＩＰパケットの前記ヘッダ部分から前記モバイル・ノードの前記ホーム・アドレスを取り除き、それを外部エージェント気付アドレスで置き換えることによって前記ＩＰパケットを変更するステップと、前記ＩＰパケットにモバイル・ノード識別子を付加するステップと、前記変更したＩＰパケットを伝送するステップとを含む方法をさらに含むことができる。
【００２３】
本発明は、有利には、外部ネットワーク内で、モバイル・ノードの気付アドレスの送信元アドレスおよび通信ノードの宛先アドレスを有する変更した応答メッセージを生成するステップと、前記変更した応答メッセージを伝送するステップとをさらに含むことができる。
【００２４】
（好ましい実施形態の説明）
図１を参照すると、通常のネットワーク・セットアップが示されている。メッセージがそこに送信されるモバイル・ノードＭＮ８は、通常、ホーム・ネットワーク２内に位置している。モバイル・ノードＭＮ８は、通常、特定のアドレスで、ホーム・ネットワーク２内に常駐する。このアドレスは、必ずしも静的ＩＰアドレスではない。すなわち、モバイル・ノードは、ネットワーク内の任意の物理ポイントに位置することも可能であるが、そのモバイル・ノード自体（物理接続ポイントではなく）に特定のＩＰアドレスが関連している。ホーム・ネットワークは、スモール・オフィス環境を物理的にその範囲とすることも、いくつかの国をその範囲とすることも可能である。
【００２５】
モバイル・ノードＭＮ８は、ワイヤレスＬＡＮ、赤外線リンク、ワイヤレス電話リンクにより、あるいは直接イーサネット（登録商標）またはトークン・リング・ネットワーク接続を介してホーム・ネットワーク２に接続することが可能である。「モバイル・ノード」という用語は、ワイヤレス・リンクを介してノードがネットワークに接続されていることを意味しない。そうではなく、下記にさらに詳細に議論するとおり、モバイル・ノードがホーム・ネットワーク２外部に移動して、図１の外部ネットワーク６のような外部ネットワーク内に入ることを意味している。
【００２６】
また、図１の構成は、通信ノードＣＮ１０を含む通信ネットワーク４も示している。本発明を例示するため、通信ネットワークの通信ノードＣＮ１０は、ホーム・ネットワーク２のモバイル・ノード８にメッセージを送信するものと想定する。通信ノードは、外部ネットワーク、つまりホーム・ネットワーク２とは独立で別個のネットワーク内にあることも可能である。ただし、外部ネットワークという用語は、通常は、別のネットワーク（そのホーム・ネットワーク）内に常駐するモバイル・ノードをホストするネットワークを指すのにだけ使用する。この説明の例では、ホーム・ネットワーク２のモバイル・ノード８は、外部ネットワーク６に移動している。したがって、モバイル・ノードＭＮ８は、それが通常そこにあるのを示すため、ホーム・ネットワーク２内に破線で示し、それが外部ネットワーク６内に一時的に存在するのを示すため、外部ネットワークＦＮ６内に実線で示している。
【００２７】
通信ノードおよび通信ネットワークという用語は、モバイル・ノード８の通信ピアを表すのにだけ使用する。通信ノードは、モバイル・ノードが現在、ＩＰパケットを受信するか、またはＩＰパケットを伝送して、それと通信を行っているノード（これは、別のモバイル・ノードであり得る）である。通信ネットワークは、通信ノードがそこに接続されているネットワークを指すのに使用する。モバイル・ノードは、それ自身のホーム・ネットワーク内の通信ノードと通信していることが可能であり、したがって、通信ネットワークは、ホーム・ネットワーク自体である可能性があることを理解されたい。
【００２８】
図１から知ることができ、下記にさらに説明するとおり、ホーム・ネットワーク２は、ホーム・エージェント１２をさらに含む。
【００２９】
次に、通信ノードＣＮ１０とモバイル・ノードＭＮ８の間における「通常」通信の簡単な例を提供する。図２（ａ）を参照すると、通信ノードＣＮ１０によってモバイル・ノードＭＮ８に送信されるＩＰパケット１４の一般的構造が示されている。
【００３０】
参照番号１４で指定し、図２（ａ）に示すネットワーク間で伝送されるＩＰパケットは、ＩＰヘッダ３０およびＩＰペイロード２２を含む。ＩＰペイロード２２は、モバイル・ノード８に送達されるＩＰパケットの情報部分である。本議論に関係のあるＩＰパケットのこれらの部分を図２（ｂ）および２（ｃ）に示している。図２（ｂ）に示すＩＰヘッダ３０は、送信元アドレス部分１６、宛先アドレス部分１８、およびプロトコルＩＤ部分２０を含む。ＩＰヘッダ３０は、本説明には関係がないので図２（ｂ）では示さない他のフィールドも含む。
【００３１】
図２（ｃ）を参照すると、ＩＰペイロード３２が、送信元ポート番号３４および宛先ポート番号３６を含んでいる。この場合も、ＩＰペイロードは、本説明の目的には関係のない他のフィールドも含む。
【００３２】
送信元アドレス１６は、ＩＰパケットがそこから送信されたホスト端末（通信ノード）のＩＰアドレスであり、また宛先アドレス１８は、ＩＰパケットがそこに送信されるホスト端末（モバイル・ノード）のＩＰホーム・アドレスである。送信元ポート番号３４は、ＩＰパケット１４に関連する通信ノード１０でアプリケーションによって使用されるポート番号である。宛先ポート番号は、ＩＰパケットがそこに送信されているモバイル・ノード８でアプリケーションによって使用されるポート番号である。他にも用途はあるが、プロトコルＩＤ２０は、送信元アプリケーションから宛先アプリケーションにＩＰパケットを伝送する上でサポートされるサービス品質の指示のうちの１つである。当分野の技術者には理解されるとおり、送信元アドレスおよび宛先アドレスは、ＩＰパケットをその宛先に経路指定するため、通信ノードとホーム・ネットワーク内のモバイル・ノードの間にある経路指定スイッチによって使用される。
【００３３】
ルータまたは経路指定スイッチが、ＲＳＶＰやＩｎｔＳｅｒｖなど、何らかのＱｏＳ制御提供におけるサービス品質（ＱｏＳ）をサポートするとき、フロー間の区別を行い、必要なＱｏＳ制御を課すため、送信元アドレス１６および宛先アドレス１８、さらに、終端アプリケーションの通信ポート番号（すなわち、送信元ポート番号３４および宛先ポート番号３６）と合せてプロトコルＩＤ２０が使用される。
【００３４】
中間ルータでデータ・トラフィック・フローに課されるＱｏＳ制御は、システムに依存する。例えば、この制御は、いわゆるＷＦＱ（Ｗｅｉｇｈｔｅｄ  Ｆａｉｒ  Ｑｕｅｕｉｎｇ）またはＣＢＱ（Ｃｌａｓｓｅｄ  Ｂａｓｅｄ  Ｑｕｅｕｉｎｇ）であることが可能である。これらは、標準ではなく、ベンダ固有のものであるが、通常、実際のユーザのプロトコルＩＤとは独立している。
【００３５】
ＩＥＦＴのＩｎｔＳｅｒ／ＲＳＶＰ規格は、ＱｏＳ制御機構ではなくＱｏＳ仕様およびシグナリング機構を提供するように定義されている。Ｉｎｔｓｅｒｖｅ／ＲＳＶＰは、ＷＦＱ、ＣＢＱなどの実際のＱｏＳ制御機構とは独立している。
【００３６】
ＱｏＳ制御がそれに基づいて行われるステータスは、ＲＳＶＰなど、特定のサービス品質シグナリング・プロトコルを使用して、データ伝送に先立ち、経路指定スイッチ内でセットアップされる。
【００３７】
次に、通信ノードからモバイル・ノードＭＮ８に、このノードが外部ネットワーク内の位置に移動したとき、ＩＰパケットを経路指定する知られている方式を説明する。モバイル・ノードＭＮ８は、外部ネットワークに移動したとき、その外部ネットワーク内に在留している間もやはりそのメッセージを受信できるように、ホーム・ネットワークのホーム・エージェントＨＡ１２に登録しなければならない。これは、モバイル・ノードが、外部ネットワーク内で位置を占めた後、ホーム・エージェントＨＡ１２に登録メッセージを送信することによって実現され得る。モバイル・ノードは、外部ネットワークに接続され、気付アドレスを割り振られると、外部ネットワーク内で位置を占めたと考えることができる。
【００３８】
図３を参照すると、ホーム・エージェントＨＡ１２は、参照番号２４によって一般的に指定されるメモリまたはルックアップ・テーブルを含んでいる。メモリの１つの列内では、ホーム・エージェントＨＡ１２は、外部ネットワーク内に一時的に在留していることをホーム・エージェントで登録した、通常はホーム・ネットワーク内に常駐するモバイル・ノードのアドレスを格納する。メモリ２４の別の列２８内に、ホーム・エージェントは、モバイル・ノードが外部ネットワーク内でそこに移動した「気付」アドレス、およびＳＰＩ（Ｓｅｃｕｒｉｔｙ  Ｐａｒａｍｅｔｅｒ  Ｉｎｄｅｘ）などの他の関連状態を格納している。
【００３９】
ホーム・エージェントがそれにより、モバイル・ノードの現在の気付アドレスおよびそのホーム・アドレス（すなわち、ホーム・ネットワーク内のモバイル・ノード・アドレス）を記録する技法は、通常、実施形態に依存する。本発明は、ホーム・エージェントにおけるモバイル・ノードの位置認識を実現するための別の手法を除外しない。
【００４０】
次に、知られている現行の一技法による、通信ノードから外部ネットワーク内のモバイル・ノードにＩＰパケットをダイレクトする際のホーム・エージェントの動作を説明する。
【００４１】
通信ノードＣＮ１０は、図２（ａ）に示したのと同一の形式を有するＩＰパケットを構成する。通信ノードからこれにより構成されたＩＰパケットが、図４（ａ）のＩＰパケット５０によって示され、これは、通信ノード・アドレスを識別する送信元アドレス６０、ホーム・ネットワーク内におけるモバイル・ノードのホーム・アドレスを識別する宛先アドレス６２、およびプロトコル「Ａ」という名称で呼ぶプロトコルＩＤ６６を含む。送信元ポート番号および宛先ポート番号は、本説明には関係がないので、図４および５では示していない。
【００４２】
図１に示す例では、外部ネットワーク６に移動した後、モバイル・ノード８には、それ独自の固有「気付」アドレスが割り振られ、このノードは、ホーム・ネットワーク内のホーム・エージェント１２に直接に登録する。これは、ＣＯ−ＣＯＡ（共通に置かれた気付アドレス）作業モードとして知られる。代替の作業モードは、ＦＡ−ＣＯＡ（外部エージェント気付アドレス）作業モードとして知られる。モバイル・ノードがそれによりホーム・エージェントに登録できる方式は、モバイルＩＰではよく知られており、本発明にとって重要ではなく、したがって、本明細書では議論しない。
【００４３】
通信ノード１０によって構成されるＩＰパケットは、モバイル・ノードが、ホーム・ネットワーク２内に位置しようと、外部ネットワーク６内に位置しようと同一である。というのは、通信ノードは、モバイル・ノードの移動の知識を有する必要がないからである。ただし、経路最適化を備えたモバイルＩＰは、通信ノードが、モバイル・ノードの現在の位置を認識している必要がある。
【００４４】
モバイル・ノードが、その現在の気付アドレスを使用してホーム・エージェントに登録した後、ホーム・エージェントは、モバイル・ノードが外部ネットワーク内にあるものと見なし、そのモバイル・ノード・ホーム・アドレスに宛てられたＩＰパケット５０の代行受信して、これらのＩＰパケットをモバイル・ノードの現在の気付アドレスにトンネル伝送することを開始する。
【００４５】
ホーム・エージェントは、ホーム・ネットワーク内に入ってくるすべてのＩＰパケットを監視して、ホーム・ネットワーク内のその宛先アドレス（ＩＰヘッダ・フィールド５２の部分６２）が、ホーム・エージェント・メモリ２４の列２６内に格納されたモバイル・ノード・ホーム・アドレスのうちの１つに一致するかどうかを調べる。
【００４６】
一致が検出された場合、ホーム・エージェントは、図４（ｂ）に示される新しいＩＰパケットを作成する。宛先アドレス、送信元アドレス、プロトコルＩＤ、およびその他のＩＰヘッダ・フィールドおよびペイロードを含め、通信ノードからの元のＩＰパケットが、この新しいＩＰパケットのペイロード部分を形成するのに使用される。つまり、元のＩＰパケットは、ホーム・エージェントによっては全く処理されず、全く変更なしに新しいＩＰパケット３０のペイロード３２として単に組み込まれる。
【００４７】
次に、ホーム・エージェントは、宛先アドレス３６、送信元アドレス３８、プロトコルＩＤ４０を新しいＩＰパケット３０に追加する。
【００４８】
宛先アドレス３６は、ＩＰパケットがそこに送信される外部ネットワーク内のアドレス、つまりモバイル・ノードＭＮ８の「気付」アドレスである。送信元アドレス３８は、新しい宛先アドレス３０がそこから送信されているホーム・エージェントのアドレス、すなわち、ホーム・エージェントである。
【００４９】
ホーム・エージェント・プロトコルＩＤは、ホーム・アドレス自体によって決定されるプロトコルＩＤである。ホーム・アドレスは、通信ノードによって元のＩＰパケット内に含められたプロトコルＩＤ２０とは無関係に、常に同一のプロトコルＩＤを新しいＩＰパケット３０に付加する。というのは、ホーム・アドレスは、元のＩＰパケット１４のプロトコルＩＤ２０を参照しないからである。プロトコルＩＤ４０は、プロトコル「Ｘ」という名称で呼ばれる。従来のモバイルＩＰのＩＰ内ＩＰカプセル化では、プロトコルＩＤは、ホーム・エージェントによって常に「１」に変更される。
【００５０】
したがって、送信元「実」アドレスおよび宛先「実」アドレス（図４（ａ）の６０および６２）は、新しいＩＰパケットのペイロード内に移され、元のＩＰペイロード内の送信元ポート番号および宛先ポート番号などの必要なその他のフロー識別情報も同様に、新しいＩＰパケットのペイロード内にラッピングされている。
【００５１】
したがって、ホーム・エージェントから外部ネットワークにＩＰパケットが経路指定されると、通信ノードからモバイル・ノードに対するフローの元の識別が失われ、サービス品質がうまく行かない。
【００５２】
次に、ＩＰパケット３０は、ホーム・エージェントによって送信され、外部ネットワーク内のモバイル・ノードの「気付」アドレスに着信するように経路指定される。ＩＰパケット３０が、「気付」アドレスに着信した後、モバイル・ノードは、この新しいＩＰパケット３０の外側層を取り除き、元のＩＰパケット５０を表出させる。
【００５３】
したがって、この知られている構成では、元のＩＰパケット内のプロトコルＩＤを含む必要なフロー識別情報が、ホーム・エージェントによってシールドされ、これにより、経路指定スイッチ（またはＩＰルータ）によるホーム・エージェントとモバイル・ノードの「気付」アドレスの間におけるＱｏＳ提供のための認識が不可能になることが理解できよう。
【００５４】
次に、その技法を非カプセル化モバイルＩＰと呼ぶことができる、代替の好ましい実施形態による通信ノードからモバイル・ノードの「気付」アドレスに対するＩＰパケットの経路指定を説明する。この代替の好ましい実施形態によるスキームでは、通信ノードによって元のＩＰパケット内に入れられた元の送信元アドレス、元の送信元ポート番号および宛先ポート番号、ならびに送信元プロトコルＩＤなどのフロー識別情報および区別情報は、そのまま変更されず、したがって、通信ノードとモバイル・ノードの「気付」アドレスの間にあるすべての経路指定スイッチにとって、有利に利用可能である。
【００５５】
通信ノードは、図５（ａ）で先に示したのと同一にＩＰパケット５０を構成する。ホーム・ネットワークに着信したとき、ホーム・エージェント１２は、前と同様にそのメモリ２４の内容を検査することにより、このＩＰパケットがその宛先とするモバイル・ノードが、外部ネットワークに移動したことを登録しているかどうかを判定する。そのメモリ列２６内で宛先アドレスを検出すると、ホーム・エージェントは、そのＩＰパケットを代行受信する。
【００５６】
この実施形態では、ホーム・エージェントＨＡは、ホーム・ネットワーク２内におけるモバイル・ノード８の宛先アドレス６２を除去し、外部ネットワーク６内におけるそのモバイル・ノードＭＮ８の宛先アドレス（すなわち、「気付」アドレス）でそれを置き換えることにより、このＩＰパケット１４を適合させる。これにより、新しいＩＰパケット４２は、元のＩＰパケット５０のペイロード６３、元のＩＰパケット５０の送信元アドレス６０、および元のＩＰパケット５０のプロトコルＩＤ６６を含む。元のＩＰパケットの宛先アドレス６２は、新しい宛先アドレス４１（モバイル・ノードの気付アドレス）によって置き換えられる。
【００５７】
もちろん、宛先ＩＰアドレスの変更に鑑みて、元のＩＰパケット５０内で提供される何らかのエラー検査の補正が必要となり得ることが、当分野の技術者には理解されよう。こうして構成された新しいＩＰパケットが、外部ネットワーク内の「気付」アドレスに送信される。したがって、ＩＰパケットは、通信ノードの送信元アドレス、元のプロトコルＩＤ、およびその他すべての元のフロー識別情報を含むフロー情報とともに、モバイル・ノードに経路指定される。すなわち、ペイロードはそのまま変更されていないので、前と同様にＩＰパケット内の同じ位置で送信元ポート番号および宛先ポート番号が入手可能なことが理解できよう。
【００５８】
これにより、フロー識別情報は、モバイル・ノードの移動に関係なく、ホーム・エージェントと「気付」アドレスの間、ならびに通信ノードとホーム・エージェントの間にあるルータに対する同じＱｏＳ要件を呈する同一の通信ノードからのＩＰパケットであると認識される。有利には、この構成（共通で置かれた気付アドレス作業モード）では、本発明によるホーム・エージェントによって構成された新しいＩＰパケット４２は、通信ノードによって提供される元のＩＰパケットと同一の長さである。
【００５９】
図６を参照すると、図１のネットワーク・セットアップに対する代替のネットワーク・セットアップが示されている。このネットワーク・セットアップは、外部ネットワーク６が外部エージェント７を備えていること以外は、図１のセットアップと同じである。したがって、図６は、外部エージェントの気付アドレス作業モードを示している。次に、この外部エージェントの気付アドレス作業モードにおける非カプセル化モバイルＩＰ技法の適用の説明を提供する。
【００６０】
この構成では、モバイル・ノードは、外部ネットワーク内に位置するとき、外部エージェントに登録する。外部エージェントにモバイル・ノードが登録することは、標準モバイルＩＰに従う。モバイル・ノードは、外部エージェントがその存在を同報通信することにより、またはモバイル・ノードが外部エージェントからその存在の肯定応答を求めることにより、外部ネットワークが外部エージェントを有することを認識する。
【００６１】
モバイル・ノードは、外部エージェントの存在を認識すると、標準モバイルＩＰに従って外部エージェントに登録する。外部エージェント自体は、メモリまたはルックアップ・テーブルを有する。図８を参照すると、外部エージェントのメモリ７０は、外部ネットワーク内に一時的に接続されたモバイル・ノードの実際のホームＩＰアドレスを格納する列７４を有する。外部エージェントは、それに登録した各モバイル・ノードに、固有モバイル・ノード識別子（ＭＮＩＤ）を割り振り、これは、外部エージェントに登録している多数のモバイル・ノードを互いに区別するのに使用することができる。外部エージェントのメモリ７０は、各モバイル・ノードのホーム・アドレスに関連する固有モバイル・ノード識別子（ＭＮＩＤ）がそこに格納される追加の列７２も有する。
【００６２】
モバイル・ノードが、外部エージェントに登録し、ＭＮＩＤが割り振られると、そのモバイル・ノードのホーム・アドレスに基づいて、外部エージェントは、モバイル・ノード登録要求をそのホーム・エージェントに送達し、これにより、ホーム・エージェントは、モバイル・ノードの現在の気付アドレスおよびモバイル・ノードのＭＮＩＤを通知される。
【００６３】
次に、ホーム・エージェントは、そのメモリ２４内に、外部ネットワーク内のモバイル・ノードのアドレスとして外部エージェントのアドレスを格納し、また、そのようなアドレスとともに、外部エージェントによってさらに通信される固有モバイル・ノード識別子も格納する。これにより、ホーム・エージェントのメモリ２４は、図９に示されるとおり変更されて、さらなる列２９内にＭＮＩＤを格納する。
【００６４】
通信ノードは、図７（ａ）に示されるのと同じにＩＰパケット５０を構成する。ホーム・ネットワークに着信すると、ホーム・エージェント１２は、前と同様にそのメモリ２４の内容を検査することにより、このＩＰパケットがその宛先とするモバイル・ノードが、外部ネットワークに移動したことを登録しているかどうかを判定する。そのメモリ列２６内で宛先アドレスを検出すると、ホーム・エージェントは、そのＩＰパケットを代行受信する。
【００６５】
この実施形態では、ホーム・エージェントＨＡは、ホーム・ネットワーク２内におけるモバイル・ノード８の宛先アドレス６２を除去し、外部ネットワーク６内におけるそのモバイル・ノードＭＮ８の宛先アドレス（すなわち、外部エージェント「気付」アドレス）でそれを置き換えることにより、このＩＰパケット１４を適合させる。この宛先アドレスは、外部ネットワーク内の外部エージェントのアドレスとなり、モバイル・ノードがそこで現在、接続されている実際のアドレスではない。これにより、新しいＩＰパケット４２は、元のＩＰパケット５０のペイロード６３、元のＩＰパケット５０の送信元アドレス６０、および元のＩＰパケット５０のプロトコルＩＤを含む。元のＩＰパケットの宛先アドレス６２は、新しい宛先アドレス４１（外部エージェント気付アドレス）によって置き換えられる。
【００６６】
さらに、ホーム・エージェントは、メッセージ４２に対するエクストラ・フィールド４３として、モバイル・ノードに関するモバイル・ノード識別子を付加する。非カプセル化モバイルＩＰでは、ＩＰパケットを外部ネットワークの外部エージェントにリダイレクトするとき、モバイル・ノードに関する固有識別子を含めることが必要不可欠である。宛先アドレス４１は、外部エージェントのアドレスであり、モバイル・ノードのアドレスではない。モバイル・ノード識別子なしでは、外部エージェントは、ＩＰパケットがどのモバイル・ノードを宛先としているのか、見分けることができない。
【００６７】
こうして構成された新しいＩＰパケット４２が、外部ネットワーク内の外部エージェント「気付」アドレスに送信される。外部エージェントは、ＩＰパケットを受信し、そこから、ＩＰパケット４２内に含まれるモバイル・ノード識別子４３を検索する。外部エージェントは、ＩＰパケット内のモバイル・ノード識別子をそのメモリの列７２内のモバイル・ノード識別子と比較し、列７４からそのモバイル・ノードのホーム・アドレスを検索する。外部エージェントは、このモバイル・ノード・ホーム・アドレスでＩＰパケット内の宛先アドレス（外部エージェントの気付アドレス）を置き換えて、このメッセージを外部ネットワーク内のモバイル・ノードに転送する。
【００６８】
トンネル伝送の前述した非カプセル化モバイルＩＰ技法では、フロー情報は隠されず、したがって、見たところ、サービス品質がサポートされる。ただし、ＲＳＶＰサービス品質の場合、これはそうではない。その理由は、ＲＳＶＰが正しく機能するためには、いわゆる予約（Ｒｅｓｖ）メッセージ（いわゆるパス・メッセージによって示されるのと同じホップに沿ってホップごとに順に経路指定される）辿る通過パスが、パス・メッセージと同一パスではあるが、それとは逆方向でなければならないことである。つまり、パス・メッセージの送信元アドレスは、予約（Ｒｅｓｖ）メッセージの宛先アドレスと一致しなければならず、またパス・メッセージの宛先アドレスは、予約メッセージの送信元アドレスと一致しなければならない。図１のネットワーク構造内でＲＳＶＰセッションをセットアップする下記の例が、前述したように非カプセル化モバイルＩＰが、なぜサービス品質をサポートするのに十分でないのかを示す。
【００６９】
図１に示すとおりモバイル・ノードが外部ネットワーク内に移動したとき、ＲＳＶＰセッションをサポートするには、２セクションのＲＳＶＰセッションがセットアップされなければならない。すなわち、通信ノード１０とホーム・エージェント１２の間のＲＳＶＰセッションの第１セクション（「セクション１」）、およびホーム・エージェントとモバイル・ノード８の間のＲＳＶＰセッションの第２セクション（「セクション２」）である。
【００７０】
この例では、モバイル・ノード８にメッセージを送信しているものと想定する通信ノード１０は、図１０（ａ）に示す一般形式を有するＩＰパケット７０を含む標準ＲＳＶＰパス・メッセージを回線１２８上で送信する。
【００７１】
ＲＳＶＰセッションで使用されるメッセージのＩＰパケットは、図２（ａ）から２（ｃ）に示す形式を有していない。図２（ａ）から２（ｃ）のＩＰパケットは、データ・メッセージのＩＰパケットである。図１０（ａ）のパス・メッセージのＩＰパケット７０は、通信ノードのアドレスに対応する送信元アドレス７８、およびホーム・ネットワーク内におけるモバイル・ノード８のアドレス（モバイル・ノード・ホーム・アドレス）に対応する宛先アドレス８０を有する。
【００７２】
パス・メッセージ（および他のＲＳＶＰメッセージ）のＩＰパケットは、ＩＰパケットのペイロード内にあるその他のフロー識別情報をさらに含む。当分野の技術者は、その他のフロー識別情報について精通しているであろう。
【００７３】
パス・メッセージのＩＰパケットは、経路指定スイッチ１３２ａによって表される複数の経路指定スイッチを介して、通信ノード１０からホーム・ネットワーク２に、回線１２８および１２４上で経路指定される。
【００７４】
経路指定スイッチ１３２ａは、サービス品質をサポートする場合には、パス・メッセージＩＰパケットのＩＰペイロード内にあるフロー識別情報を抽出して、このフロー識別情報を格納する。このフロー識別情報には、サービス品質セッションがセットアップされた後、送信元から宛先に伝送されるＩＰデータ・パケット内にすべて含まれることになる送信元アドレス、宛先アドレス、送信元ポート番号、宛先ポート番号、およびプロトコルＩＤが含まれる。経路指定スイッチ１３２ａは、パス・メッセージのＩＰパケットを別の経路指定スイッチに経路指定して、次に、このＩＰパケットから抽出したフロー識別情報とともに、それがそこにメッセージを送信する経路指定スイッチのアドレス（次のホップ）、およびそれがそこからメッセージを受信する経路指定スイッチのアドレス（前のホップ）をさらに格納する。
【００７５】
図１では、１つの経路指定スイッチ１３２ａを介してＩＰパケットがホーム・ネットワーク２に到達するのが示されているが、実際には、ＩＰパケットは、複数の経路指定スイッチを介してホーム・ネットワークに到達することができ、また各経路指定スイッチが、パス・メッセージのＩＰパケットから抽出したフロー識別情報を格納し、それと合せてＩＰパケットがそこから送信された経路指定スイッチの識別およびＩＰパケットがそこに送信された経路指定スイッチの識別も格納する。
【００７６】
したがって、パス・メッセージのＩＰパケットは、経路指定ネットワークを介して、通信ノードからホーム・ネットワークに伝送される。各経路指定スイッチは、ＩＰパケットがそこから送信された前のホップのアドレスを保持し、それとともに、ＩＰパケットがそこに送信された次のホップのアドレスを保持し、さらに、ＩＰパケットに関するフロー識別情報を保持する。また、経路指定スイッチは、パス・メッセージ内のその他のトラフィック関連情報も処理するが、それらの性質は、本発明の議論にとって重要ではない。
【００７７】
サービス品質セッションがセットアップされた後、経路指定スイッチ・メモリ内に格納されているのと同一のフロー識別情報を有する別のＩＰパケットが、特定の経路指定スイッチに着信したとき、その経路指定スイッチは、そのアドレスがメモリ内に格納されている全く同じ次のホップにそのパケットを転送する。
【００７８】
したがって、連続するホップで、各経路指定スイッチは（それがＲＳＶＰサービス品質をサポートするという前提で）、パス・メッセージのＩＰパケットの固定位置からフロー識別情報を検索して、次のホップおよび前のホップのアドレスとともにそれらをメモリ内に格納する。したがって、ＩＰパケット内のフロー識別情報は、メッセージ・フローを一意的に識別することを助け、そのメッセージ・フローに関連するすべてのＩＰパケットが、全く同じネットワーク・パスを介して、送信元から宛先に経路指定され得るようにする。
【００７９】
この場合、ホーム・エージェントが、モバイル・ノードを宛先とするパス・メッセージのＩＰパケットを代行受信する。ホーム・エージェントは、モバイル・ノード８を宛先とするパス・メッセージのＩＰパケットを代行受信したとき、それらを外部ネットワークにリダイレクトする。この例では、非カプセル化モバイルＩＰが利用され、新しいＩＰパケットは、新しいまたは変更されたパス・メッセージとして、外部ネットワークに対する伝送のために作成される。ホーム・エージェントによって送信される変更されたパス・メッセージのＩＰパケット７４を図１０（ｂ）に示している。ホーム・エージェントは、パス・メッセージのＩＰパケットの宛先アドレスを置き換えて、変更されたパス・メッセージのＩＰパケット７４の宛先アドレス１０６が、外部ネットワークにおけるモバイル・ノードの気付アドレスであるようにする。先に議論したとおり、非カプセル化モバイルＩＰでは、ＩＰパケット７０の他のすべての要素は、変更されないままである。
【００８０】
この変更されたパス・メッセージが、単一経路指定スイッチ１３２ｂによって表される経路指定スイッチを介して、モバイル・ノードの気付アドレスに回線１２６および１３０上で経路指定される。
【００８１】
第１セクションのパス・メッセージに関連して前述したとおり、第２セクションのパス・メッセージにおいても、変更されたパス・メッセージのＩＰパケットは、その中にあるフロー識別情報に基づいて同様に伝送される。次のホップおよび前のホップも、経路指定スイッチによって同様に格納される。
【００８２】
モバイル・ノードは、変更されたパス・メッセージを受信し、図１０（ｃ）に示す一般形式のＩＰパケット７６を有する予約メッセージを伝送のために作成することにより、第２セクションに関する予約（Ｒｅｓｖ）メッセージを開始する。
【００８３】
当分野の技術者には、予約（Ｒｅｓｖ）メッセージのＩＰパケットは、ホップごとに順に、パス・メッセージのＩＰパケットと同一のネットワーク・パスを逆に辿って伝送されることが理解されよう。したがって、予約メッセージのＩＰパケットの送信元アドレスおよび宛先アドレスは、実際は、次のホップおよび前のホップである。したがって、予約メッセージがそのパスを通過するにつれ、送信元アドレスおよび宛先アドレスの値が動的に判定される。したがって、図１０（ｃ）に示す予約メッセージのＩＰパケット７６の構造は、実際は、予約メッセージのトランスポート層を表すものである。したがって、図１０（ｃ）に示す構造は、予約メッセージの一般概念、つまり発信する送信元アドレスおよび最終の宛先アドレスを示している。予約メッセージのこの分析は、いくぶん不自然であるが、ＲＳＶＰの原理をよく例示するのに役立つ。
【００８４】
モバイル・ノード８は、モバイル・ノード・ホーム・アドレスとして送信元アドレス１１４を識別する。標準モバイルＩＰは、モバイル・ノード自体の上にあるアプリケーションが、モバイル・ノードのネットワーク接続ポイントの変更を認識していることを必要とすべきではないものとしている。したがって、モバイル・ノードが存在する場所に関わらず（そのホーム・ネットワーク内にあっても、または外部ネットワーク内にあっても）、モバイル・ノードは、常に、モバイル・ノードのホーム・アドレスであるものとして送信元アドレスを識別するＩＰパケットを生成する。モバイル・ノードは、通信ノード・アドレスの予約メッセージ内の宛先アドレスを含む。これは、標準モバイルＩＰに従えば、モバイル・ノードは、そのメッセージが通信ノードから来たことを認識しており、ホーム・エージェントを介するリダイレクションを認識していないからである。モバイル・ノードから通信ノードに標準モバイルＩＰで送信されるＩＰパケットに関しては、あたかもモバイル・ノードが、ホーム・ネットワーク内で「ホームにいる」かのように、通常のＩＰパケットとして経路指定される。
【００８５】
図１０（ｂ）および１０（ｃ）に示すパス・メッセージと予約メッセージのＩＰパケットを比較してみると、成功するＲＳＶＰセッションのための条件が存在しない。予約メッセージ７６の送信元アドレスは、パス・メッセージ７４の宛先アドレスのそれとは異なる。
【００８６】
これは、パス・メッセージのＩＰパケットによって設定されたのと同じネットワーク・パスをホップごとに順に辿る予約（Ｒｅｓｖ）メッセージの経路指定の失敗をもたらす。第２セクションが失敗するため、第１セクション（ホーム・エージェントと通信ノードの間の）に関する予約メッセージは、全く開始されない。
【００８７】
図１２を参照すると、非カプセル化モバイルＩＰがＲＳＶＰをサポートできるようにするように適合された図１のネットワーク構成が示されている。示される構成では、通信ネットワーク内および外部ネットワーク内にプロキシ・サーバが導入されている。ただし、下記の説明から、プロキシ・サーバの機能性は、実際には、プロキシ・サーバがそこに接続されたホスト端末に組み込まれ得ることを理解されたい。下記において、図１２の構成の説明に続き、さらなる説明を提供する。
【００８８】
図１２を参照すると、図１のネットワークが適合され、通信ネットワーク４が通信ネットワーク・プロキシ・サーバをさらに含み、また外部ネットワーク６が外部ネットワーク・プロキシ・サーバ１４４をさらに含むようになっている。通信ノード１０は、ネットワーク・リンク１３８を介して通信ノード・プロキシ・サーバ１４２に接続される。この通信ネットワーク・プロキシ・サーバは、ネットワーク・リンク１２８を介して経路指定スイッチに接続する。外部ネットワーク・プロキシ・サーバ１４４は、ネットワーク・リンク１４６を介して外部ネットワーク６内にあるモバイル・ノード８に接続する。この外部ネットワーク・プロキシ・サーバは、ネットワーク・リンク１３６を介して経路指定スイッチ１３２ｂに接続する。
【００８９】
次に、ＲＳＶＰがそこでサポートされた非カプセル化モバイルＩＰを使用して、通信ノード１０から外部ネットワーク内にあるモバイル・ノード８にメッセージを送信するために適合された図１２のネットワークの動作例を説明する。
【００９０】
それ自体のサービス品質機能を備えていないネットワーク内でサービス品質提供を必要とする各ホスト端末は、そのネットワーク内にプロキシ・サーバが存在しているのを認識している必要がある。つまり、ホスト端末がそれによりプロキシ・サーバを発見できるプロセスが存在しなければならない。実際に、これを行うことができる２つの方式が存在する。第１方式では、ネットワーク内のホスト端末が、サーバ請求メッセージ（ＳＳＭ）を同報通信する。ネットワーク内のプロキシ・サーバは、サーバ応答メッセージ（ＳＲＭ）をこのホスト端末に送り返すことによって応答する。第２方式では、ネットワーク内のプロキシ・サーバが、ローカル・ネットワークにクライアント要求メッセージ（ＣＲＱＭ）を同報通信する。それに応答して、ホスト端末（これは、プロキシ・サーバ・クライアントであると考えることができる）は、クライアント登録メッセージ（ＣＲＧＭ）を送り返す。このようにして、エージェント（ホーム・エージェント、外部エージェント）の存在が標準モバイルＩＰにおいて現在、登録されているのと同様に、ネットワーク内のプロキシ・サーバの存在が、ネットワーク内のホスト端末によって登録される。ノードがプロキシ・サーバに登録する技法の実施は、当分野の技術者が行うことのできる範囲内であろう。
【００９１】
上記に議論したとおり、通信ノードがメッセージをモバイル・ノードに送信するとき、通信ノードとモバイル・ノードの間でサービス品質セッションをうまく確立するには、２つのセクションを有するＲＳＶＰセッションを確立する必要がある。一般的に言って、サービス品質セッションの第１セクションは、通信ネットワークとモバイル・ノードのホーム・ネットワークの間で確立されなければならず、またサービス品質セッションの第２セクションは、ホーム・ネットワークと外部ネットワークの間で確立されなければならない。
【００９２】
次に、図１１の流れ図を利用して、図１２のネットワーク構成に関して、第１サービス品質セッション、特にモバイルＩＰでのＲＳＶＰセッションを確立する技法を説明する。
【００９３】
ステップ１５０で、サービス品質セッションを開始する通信ノード１４ａが、ネットワーク・リンク１３８上で通信ネットワーク・プロキシ・サーバ１４２にサービス品質要求を送信する。
【００９４】
このサービス品質要求は、暗黙的であることも、明示的であることも可能である。通信ノードからの明示的サービス品質要求は、正確なサービス品質要件を特定する。したがって、明示的サービス品質要求は、特定のサービス品質の明示的ステートメントをサポートする機能性を有する通信ノードによってのみ提供されることが可能である。通信ノードからの暗黙的サービス品質要求は、行われる伝送の性質だけを特定する。例えば、暗黙的サービス品質要求は、送信されるデータがビデオ・データであることを示すことができる。したがって、プロキシ・サーバは、データのタイプの指示に応じて適切なサービス品質を決定する。
【００９５】
次に、ステップ１５２で、通信ネットワーク・プロキシ・サーバ１４２が、標準ＲＳＶＰパス・メッセージを送信する。このパス・メッセージは、回線１２８および１２４上で、経路指定スイッチ１３２ａを介してホーム・ネットワーク・プロキシ・サーバに通信される。
【００９６】
通信ノード・プロキシ・サーバによって送信されるパス・メッセージのＩＰパケットは、図１０（ａ）のＩＰパケット７０に全く同じに対応し、経路指定スイッチ１３２を備えた経路指定ネットワークによってホーム・エージェント１２に経路指定される。この経路指定は、前述したのと全く同じ方式で行われる。
【００９７】
ステップ１５４で、ホーム・エージェントが、パス・メッセージのＩＰパケットを代行受信し、前述したとおりこのＩＰパケットを適合させ、変更されたパス・メッセージとしてのＩＰパケットを生成する。
【００９８】
変更されたパス・メッセージのＩＰパケットは、図１０（ｂ）のＩＰパケット７４に全く同じに対応する。ステップ１５６で、パス・メッセージ７４の第２セクションを含むＩＰパケット７４が、ホーム・エージェントによって伝送され、経路指定スイッチ１３２ｂによって表される経路指定ネットワークを介して、外部ネットワーク１４４に経路指定される。
【００９９】
外部ネットワーク・プロキシ・サーバが、第２セクションのパス・メッセージを受信し、ステップ１５８で、外部ネットワーク・プロキシ・サーバ１４４は、回線１４６上でサービス品質指示信号をモバイル・ノード８に送信して、通信ノード１０によって要求されたサービス品質を示す。モバイル端末が、通信ノードによって送信されたサービス品質指定を認識している場合、このモバイル端末は、ステップ１６０において、ネットワーク・リンク１４６上で、サービス品質応答を肯定応答として外部ネットワーク・プロキシ・サーバ１４４に送信する。
【０１００】
ステップ１６２で、次に、外部ネットワーク・プロキシ・サーバが、変更された予約メッセージ（すなわち、標準ＲＳＶＰで送信された予約メッセージに対して変更された）を送信して、サービス品質セッションを確認する。この変更された予約メッセージは、回線１３６および１２６を介するパス・メッセージと同一の経路を（逆方向に）辿る。
【０１０１】
外部ネットワーク・プロキシ・サーバによって送り返された、第２ＲＳＶＰセッションに関する変更された予約メッセージ７７の形式を図１０（ｄ）に示している。ここに見られるとおり、外部ネットワーク・プロキシ・サーバ１４４の使用のため、送信元アドレス１５５は、モバイル・ノードの気付アドレスであり、また宛先アドレスは、通信ノードのアドレスである。したがって、第２ＲＳＶＰセッションにおいては、パス・メッセージと予約メッセージの送信元アドレスと宛先アドレスの間で正しい相関が存在して、これによりＲＳＶＰセッションがサポートされる。
【０１０２】
この場合も、図１０（ｄ）に示すメッセージは、外部ネットワークとホーム・ネットワークの間の終端間メッセージを表すものである。図１０（ｄ）に示す形式は、前述したとおり、次のホップおよび前のホップに対応する送信元アドレスおよび宛先アドレスを有する予約メッセージのＩＰパケットを表すものではない。
【０１０３】
ステップ１６４で、ホーム・エージェントが、変更された予約メッセージを受信する。ホーム・エージェントは、この予約メッセージを図１０（ｅ）に示す形式に適合し、これはさらに変更された予約メッセージを形成する。この適合を行うため、ホーム・エージェントは、そこにプロキシ・サーバの機能性を備えている。別法では、通信ネットワーク・プロキシ・サーバおよび外部ネットワーク・プロキシ・サーバと等価のホーム・ネットワーク・プロキシ・サーバをホーム・ネットワーク内で提供して、ホーム・エージェントに関連付けることが可能である。
【０１０４】
ＲＳＶＰセッションは、ホーム・エージェントが経路指定スイッチ１３２ａならびにネットワーク・リンク１２４および１２８を介して前記さらに変更された予約メッセージを通信ネットワークに送り返すことによって完了する。図１０（ｅ）に示すとおり、この予約メッセージは、送信元アドレス８８としてモバイル・ノードのホーム・アドレスを有し、また宛先アドレスとして通信ノードのアドレスを有する。したがって、通信ネットワークとホーム・ネットワークの間におけるＲＳＶＰセッションのセクションは、標準の静的ＲＳＶＰセッションと等価である。ＲＳＶＰをサポートするのに経路指定ネットワーク内で経路指定スイッチが必要とするフロー情報は、完全に入手可能である。パス・メッセージに対して、前記さらに変更された予約メッセージでは、送信元アドレスおよび宛先アドレスが「入れ替え」られている。
【０１０５】
ステップ１６６で、次に、ホーム・エージェントが、第１セクションに関する予約メッセージを送信する。この場合、このさらに変更された予約メッセージは、通信ネットワーク４に送信され、そこで通信ネットワーク・プロキシ・サーバ１４２によって受信される。
【０１０６】
ステップ１６８で、次に、通信ネットワーク・プロキシ・サーバが、ネットワーク・リンク１３８上で、肯定応答として通信ノード１０にサービス品質確認メッセージを送信して、サービス品質セッションがセットアップされていることを示す。
【０１０７】
次に、通信ノード１０が、モバイル端末に対するデータ・メッセージ・パケットの送信を開始する。ただし、このデータ・メッセージ・パケットは、通信ネットワーク・プロキシ・サーバまたは外部ネットワーク・プロキシ・サーバを介して行くわけではない。プロキシ・サーバは、ＲＳＶＰセッションのセットアップ中にだけ使用される。
【０１０８】
ＲＳＶＰセッションが前述したとおりセットアップされ、メッセージが通信ノードからモバイル・ノードに送信された後、データ・メッセージのＩＰパケットによって搬送されたフロー識別情報が、ＲＳＶＰセッションのセットアップで使用されたフロー識別情報に一致することが必要不可欠である。したがって、図２に示す一般形式を有するＩＰパケットは、ＲＳＶＰメッセージのペイロード内に同一の送信元ポート番号、宛先ポート番号、およびプロトコルＩＤを含まなければならず、また送信元アドレスおよび宛先アドレスを含まなければならない。このようにして、ＲＳＶＰセッションによって構成されたフローに関連するものとしてそのデータＩＰパケットが一意的に識別される。
【０１０９】
したがって、外部ネットワーク・プロキシ・サーバを備えることにより、モバイルＩＰにおいてＲＳＶＰサービス品質がサポートされることを確実にする。したがって、図１２に示すプロキシ・サーバは、「ＲＳＶＰプロキシ・サーバ」であると考えることができる。このプロキシ・サーバは、モバイル・ノードの移動を追うようにＲＳＶＰメッセージの宛先を動的に適合し、また他方で、フロー識別情報およびサービス品質情報が、非カプセル化モバイルＩＰ（ＮＥＭＩＰ）に従ってダイレクトされたデータ・フローと一致することを保証する。
【０１１０】
以上の説明から、モバイルＩＰにおいてサービス品質がサポートされるとすれば、プロキシ・サーバ（またはプロキシ・サーバの等価の機能性）が、外部ネットワーク内、つまり他のネットワーク内に通常は常駐するホスト端末を受け入れるネットワーク内で提供されるのが必要不可欠なことが理解されよう。
【０１１１】
外部ネットワーク内にＲＳＶＰプロキシ・サーバ（またはその機能的等価物）を備えることにより、確立されたＲＳＶＰセッション（詳細には、ＲＳＶＰセッションの第２セクション）が、モバイル・ノードの移動を追い、他方、同時に、モバイル・ノードのネットワーク接続ポイントの変化に関わりなく、ＲＳＶＰセッションの同じパスを辿るデータ・フローのフロー情報に一致する正しいフロー情報を記録するのを保証する。
【０１１２】
伝送中、どのホスト端末も、そこに伝送しているホスト端末がモバイル端末であるのかどうか、またはそれがＲＳＶＰプロキシ・サーバを有する外部ネットワーク内にあるのかどうか知ることはない。モバイルＩＰでＲＳＶＰのサポートを確実にするためには、ホスト・モバイル・ノードに対する外部ネットワークとして動作することができる各ネットワークが、本明細書に記載した機能を有するプロキシ・サーバ（またはそれと等価の機能性）を備えていなければならない。外部ネットワーク内のプロキシ・サーバによって実行される機能制御の前記説明は、モバイル環境内でサービス品質をサポートするのに必要不可欠である。
【０１１３】
図１２を参照すると、モバイル・ノードにデータ・メッセージを送信しようとする通信ネットワーク内の通信ノードに対してサービス品質セッションをサポートするのに必要不可欠な要件は、モバイル・ノードがその中にある外部ネットワークが、プロキシ・サーバまたはその機能的等価物を有さなければならないということである。この場合、通信ノードは、通信ノード・プロキシ・サーバの必要性なしに、ＲＳＶＰセッション自体を直接にセットアップすることができる。
【０１１４】
ただし、通信ノード・プロキシ・サーバを備えていることは、それにより、通信ノード内のＲＳＶＰ機能性を有さない端末が、ＲＳＶＰセッションを開始できるという利点を有する。このプロキシ・サーバは、プラットフォーム非依存かつアプリケーション非依存のサービス品質セッションを構成する技法を提供する。したがって、サービス品質セッションを確立する専用手段を提供することにより、現在および将来のサービス品質非対応ホスト端末が、サービス品質セッションをセットアップさせ、またこれにより、その通信ピアまでの伝送パスにわたってそのサービス品質制御を可能にすることができる。多数のサービス品質制御シグナリングおよび制御機構がもたらす複雑でインテンシブな計算処理の要件、ならびにワイヤレス／モバイル端末のためのバッテリ電力に対する負担が回避される。
【０１１５】
前記に一貫して言及してきた代替の適用例では、外部ネットワーク内で実行されるプロキシ・サーバの機能性が、モバイル・ノード自体の中で実行される。そのような適用例では、モバイル・ノードは、既にＲＳＶＰ対応であり、標準ＲＳＶＰセッションをサポートするＲＳＶＰデーモンを有することになる。そうした適用例では、ホーム・ネットワークからの変更されたパス・メッセージの受信に応答して、モバイル・ノードが、図１０（ｃ）に示す標準ＲＳＶＰメッセージ形式を生成することになる。この場合、モバイル・ノードのＲＳＶＰデーモン内に組み込まれたプロキシ・サーバ機能性が、この予約メッセージを変更して、図１０（ｄ）の変更された予約メッセージを生成することになる。次に、この変更された予約メッセージが、モバイル・ノードから直接に伝送される。
【０１１６】
この文書中で本明細書に記載する例は、標準ＲＳＶＰを利用していることに留意されたい。標準ＲＳＶＰに対するどのような変更も想定または提案していない。
【０１１７】
図１２に関連して前述したモバイルＩＰにおいてサービス品質をサポートする解決法は、具体的には、外部ネットワークが外部エージェントを含まない共通で置かれた気付アドレス作業モードに関する。また、この技法は、外部ネットワークが外部エージェントを含む外部エージェント気付アドレス作業モードにも適用される。ただし、サービス品質セッションを開始できるにはまず、下記に説明するとおり、外部エージェント気付アドレス作業モードにおいて、特別な予防策をとらなければならない。
【０１１８】
図６に関連して前述した非カプセル化モバイルＩＰを使用する外部エージェント気付アドレス作業モードでは、モバイル・ノード識別子が、外部ネットワーク内にある各モバイル・ノードに割り振られ、またホーム・エージェントから外部エージェントに送信されるＩＰパケットに付加される。このモバイル・ノード識別子は、外部ネットワーク内におけるＩＰパケットの宛先を一意的に識別する。ただし、モバイル・ノードが外部ネットワーク内にあるとき、このＭＮＩＤは、ホーム・エージェントと外部エージェントの間にある経路指定スイッチには利用不可能である。
【０１１９】
やはり前述したとおり、メッセージのフローは、そのメッセージ内に含まれるフロー識別情報によって識別される。外部エージェント気付アドレス作業モードでは、特定の通信ノードと、すべて同一の外部ネットワーク内にあり、かつ同一の外部エージェントによるサービスを受けるいくつかのモバイル・ノードとの間でサービス品質セッションが構成される場合には、送信元アドレス（すなわち、通信ノードのアドレス）は、すべての情報フローに関して同一であり、また宛先アドレス（外部エージェント気付アドレス、すなわち、実質的には、外部エージェント・アドレス）は、ホーム・エージェントと外部エージェントの間におけるすべての情報フローに関して同一である。また、メッセージ・フローのそれぞれに対するプロトコルＩＤも同一になる可能性が非常に高い。
【０１２０】
この状況では、ホーム・エージェントと外部エージェントの間において異なるメッセージを互いに区別できることは、送信元ポート番号および宛先ポート番号が異なっていることに依存する。ただし、この場合でも、２つの異なるメッセージ・フローが、同一の送信元ポート番号および宛先ポート番号を有することも可能である。そのような場合、ホーム・エージェントと外部エージェントの間にある経路指定スイッチは、同一の送信元アドレスおよび宛先アドレス、同一の送信元ポート番号および宛先ポート番号、ならびに同一のプロトコルＩＤを有する２つの異なるフローを互いに区別できない可能性がある。経路指定スイッチを変更して、それが通常のフロー識別情報に加え、メッセージ・フローからモバイル・ノード識別子を検索できるようにしない限り、経路指定スイッチは、２つ以上の異なるフローを一意的に識別できないことになる。
【０１２１】
もちろん、ホーム・エージェントと外部エージェントの間にある経路指定スイッチまたはその他の経路指定デバイスの設計を変更することは望ましくなく、したがって、下記に説明するとおり、本明細書では、ホーム・エージェントと外部エージェントの間で異なるフローの一意的な識別を確実にする解決法を提示する。この解決法は、メッセージのフロー識別情報内におけるポート番号間の衝突を完全に回避する。
【０１２２】
図１３のネットワーク構成は、この問題のシナリオを例示している。図１３のネットワーク構成は、図１２のネットワーク構成に対応し、外部エージェント７（図６に示す）が追加され、また追加のモバイル・ノード９を有している。モバイル・ノード８および９は、ともに、外部エージェント７によるサービスを受けている。
【０１２３】
図１３では、２つのモバイル・ノード８および９、外部ネットワーク・プロキシ・サーバ１４４、および外部エージェント７が、すべて、経路指定ネットワーク内で経路指定スイッチ１３２ｂに接続するネットワーク・リンク接続１３９によって相互接続されているのが示されている。実際、当分野の技術者には理解されるとおり、それぞれのネットワークのすべてにおいて、その中の様々な要素（端末、それが該当する場合、プロキシ・サーバ、およびそれが該当する場合、ホーム／外部エージェント）の間の相互接続は、共通ネットワーク・リンク上、例えば、イーサネット上で提供される。
【０１２４】
図１３のネットワーク構成では、各プロキシ・サーバ、またはプロキシ・サーバの機能性を含む各端末が、「使用中ポート」メモリおよび「一時ポート置換メモリ」を含む。図１４（ａ）に示すとおり、使用中ポート・メモリ２００は、単一の列２０４を含み、これは、現在使用中であるすべてのポート番号を含む。図１４（ｂ）に示すとおり、この一時ポート置換メモリ２０２は、割当て済み一時ポート番号の値を格納する列２０６、対応する「実」ポート番号を格納する列２０８、モバイル・ノード識別子（ＭＮＩＤ）を格納する列２０９を含む。
【０１２５】
本例では、ホーム・エージェント１２のプロキシ・サーバ機能性および外部エージェント・プロキシ・サーバ１１４が、それぞれ、「使用中ポート」メモリおよび「一時ポート置換」メモリを有する。この例では、通信ネットワーク・プロキシ・サーバ１４２が、「使用中ポート」または「一時ポート置換メモリ」を有していなければならないという要件はないことに留意されたい。これは、通信ネットワークとホーム・ネットワークの間の情報フローを区別する上で、問題が存在しないからである。というのは、フローは、少なくとも、モバイル・ノードのホーム・アドレスである宛先アドレスによって一意的に識別されるからである。
【０１２６】
図１４の例としてのメモリ・エントリでは、「使用中ポート」メモリは、ポート番号Ａ、Ｂ、Ｘが使用中であることを示している。「一時ポート置換」メモリは、一時ポートＸが割り振られており、このポートが、モバイル・ノード９に関連するＢという実際のポート番号に対応することを示している。
【０１２７】
外部エージェント・プロキシ・サーバのピアであるその他のプロキシ・サーバのそれぞれは、この情報をそれ独自の等価な使用中ポート・メモリ内におよび「一時ポート置換」メモリ内に格納する。この目的での、外部エージェント・プロキシ・サーバのピアは、外部ネットワーク内で外部ネットワーク・プロキシ・サーバに対して外部エージェント気付アドレス・モードで接続されているモバイル・ノードと通信する任意のホーム・エージェント・プロキシ・サーバ（または等価の機能性を備えたホーム・エージェント）である。
【０１２８】
一時ポートの割振りは、好ましくは、モバイル・ノードがそこで外部エージェント７およびプロキシ・サーバ１４４に登録する手順中に行われる。モバイル・ノードは、プロキシ・サーバに登録するのと同時に、それがサポートするすべてのアプリケーションのポート番号もプロキシ・サーバに通知する。
【０１２９】
したがって、モバイル・ノード８は、プロキシ・サーバ１４４にモバイル・ノード８内で利用可能なすべてのアプリケーションのすべてのポート番号を通知する。次に、プロキシ・サーバ１４４が、これらのポート番号のそれぞれを「使用中ポート」メモリ２０４に照らして検査する。なんらかの衝突が検出された場合には、プロキシ・サーバ１４４は、一時ポート番号を実ポート番号に割り振り、一時ポート番号および実ポート番号、またそれと合せてモバイル・ノードの識別子をメモリ２０２内に格納する。プロキシ・サーバは、外部エージェント７に登録している他の各モバイル・ノードに関して、同様の動作を行う。
【０１３０】
モバイル・ノードの各登録時に、外部ネットワーク・プロキシ・サーバは、一時ポート番号の割振りをそのピアに通知する。これにより、外部ネットワーク・プロキシ・サーバは、プロキシ・サーバの機能性を含むホーム・エージェント１２に通知を行い、このホーム・エージェントは、それに応じて、その「使用中ポート」メモリおよび「一時ポート割振り」メモリを更新する。
【０１３１】
説明例として、モバイル・ノード８は、１つだけの利用可能なアプリケーションを備え、これがＢというポート番号を有するものと想定する。したがって、モバイル・ノード８が、外部ネットワーク・プロキシ・サーバ１４４に登録するとき、ポート番号Ｂが、「使用中ポート」メモリ２００に入力され、この情報がホーム・エージェント１２に伝送されて、ホーム・エージェントが、それに応じて、それ自体の「使用中ポート」メモリを更新する。モバイル・ノード９は、２つの利用可能なアプリケーションを備え、これが、それぞれ、ポート番号ＡおよびＢを有するものと想定する。したがって、モバイル・ノード９が、外部ネットワーク・プロキシ・サーバ１４４に登録するとき、ポート番号Ｂに関するポート衝突が識別される。この衝突は、「使用中ポート」メモリの内容を使用したモバイル・ノード９内で利用可能なアプリケーションのポート番号の簡単な検査によって識別することができる。したがって、外部ネットワーク・プロキシ・サーバ１４４は、一時ポート番号をモバイル・ノード９のポート番号Ｂに割り振り、この情報が、「一時ポート置換」メモリ２０２内に格納される。したがって、図１４（ｂ）に示すとおり、「一時ポート置換」メモリ２０２は、一時ポート番号Ｘがモバイル・ノード９のポート番号Ｂに割り振られていることを示す。また、プロキシ・サーバ１４４は、「使用中ポート」メモリ２００も更新して、ポートＡおよびＸが使用中であることをさらに示す。次に、外部ネットワーク・プロキシ・サーバは、「使用中ポート」メモリと「一時ポート置換」メモリの両方の更新済み内容をホーム・エージェント１２に通信し、ホーム・エージェントは、それに応じて、それ自体の「使用中ポート」メモリおよび「一時ポート置換」メモリを更新する。
【０１３２】
モバイル・ノードの登録時に一時ポートの割振りが必要かどうかを判定するステップを図１５に示している。ステップ２１０で、外部ネットワーク・プロキシ・サーバは、それに登録を行っているモバイル・ノード内のアプリケーションのポート番号が、既に使用中であるかどうかを判定する。これは、アプリケーションのポート番号をメモリ２００の列２０４内の値と比較することによって判定される。
【０１３３】
本例では、前述したとおり、モバイル・ノード９が登録するとき、ポート番号Ｂが既に使用中である。したがって、ステップ２１２で、外部ネットワーク・プロキシ・サーバが、一時ポート番号を割り振る。この一時ポート番号は、単に、現在使用中ではない一時ポート番号から選択することができ、これは、メモリ２０２の列２０６の検査から判定することができる。この例では、前述したとおり、一時ポート番号Ｘが割り振られる。
【０１３４】
ステップ２１４で、ホーム・エージェントが、外部ネットワーク・プロキシ・サーバからの通知時に、ポート番号Ｘを列２０６内に、また関連ポート番号Ｂを列２０８内に入力することにより、一時ポート置換メモリの列２０６および２０８の内容を更新する。
【０１３５】
ここで、通信ノード１０が、外部ネットワーク内にあるモバイル・ノード９とのサービス品質セッションのセットアップを試みるものと仮定する。この新しいサービス品質セッションにおいて識別されるモバイル・ノード９内のポート番号（すなわち、アプリケーション）は、Ｂである。
【０１３６】
図１１の流れ図によれば、ステップ１５０で、通信ノードが、ネットワーク・リンク１３８上でサービス品質要求を通信ノード・プロキシ・サーバに送信する。ステップ１５２で、通信ノード・プロキシ・サーバ１４２が、パス・メッセージを送信し、またステップ１５４で、ホーム・エージェントがこのパス・メッセージを代行受信する。
【０１３７】
ただし、ステップ１５６でホーム・エージェントが変更されたパス・メッセージを送信する前に、一時ポート番号が宛先モバイル・ノード内の特定のポート番号に割り振られているかどうかを検査する必要がある。ホーム・エージェントは、パス・メッセージを変更してモバイル・ノード識別子を含めるとき、現行のメッセージのモバイル・ノード識別子と列２０９の間、および現行のメッセージの宛先ポートと列２０８の間で、「一時ポート置換」メモリ内に一致がないか検査する。一致が検出された場合には、ホーム・エージェントは、宛先ポート番号を適切な一時ポート番号で置き換える。
【０１３８】
ホーム・ネットワークと外部ネットワークの間で使用するモバイル・ノード識別子（ＭＮＩＤ）が、やはり割り振られ、外部エージェントにモバイル・ノードが登録するプロセスの一環として、前述したのと同じ方式でホーム・エージェントに通知される。
【０１３９】
何らかの必要なポート置換が行われると、次に、ホーム・エージェントは、ステップ１５６に進み、前述したとおり、パス・メッセージおよび予約メッセージが転送されて、サービス品質セッションをセットアップする。
【０１４０】
図１１の流れ図に対する別の変更が、ステップ１５８で行われる。サービス品質指示信号をモバイル・ノードに送信するのに先立って、外部ネットワーク・プロキシ・サーバは、宛先ポート番号およびＭＮＩＤをそのメモリ２０２の列２０６内および２０９内でルックアップする。一致が見つかった場合、宛先ポート番号は、列２０８からの対応する値で置き換えられ、その後、サービス品質指示信号が送信される。
【０１４１】
同様にステップ１６２で、変更された予約メッセージを送信するのに先立って、モバイル・ノードの宛先ポート番号が、列２０６内の一時値で置き換えられる。
【０１４２】
さらに、ステップ１６６で、ホーム・エージェントが、さらに変更した予約メッセージを送信するのに先立って、さらに変更した予約メッセージを通信ネットワークに転送する前に、一時ポート番号を実ポート番号で置き換える。
【０１４３】
ホーム・エージェントと外部ネットワークの間における特定のいずれかのサービス品質セッションに一時ポート番号が割り振られている場合には、すべてのデータ・パケットは、外部エージェントおよびホーム・エージェントを介して転送されつづけることになり、前記外部エージェントおよび前記ホーム・エージェントは、一時ポート番号の正しい代替および置換を確実にするように適合されている。
【０１４４】
図１６は、図１３のネットワーク構成のさらに変更したバージョンを示している。この構成では、モバイル・ノード８および９のそれぞれは、やはり、共通外部エージェント７によってサポートされているが、モバイル・ノード８および９のそれぞれに対して、別個の外部エージェント・プロキシ・サーバが提供されている。したがって、モバイル・ノード８は、外部エージェント７および外部ネットワーク・プロキシ・サーバ１４４に関連し、またモバイル・ノード９は、外部エージェント７および外部ネットワーク・プロキシ・サーバ１４５に関連する。この場合も、すべての要素が、共通ネットワーク・リンク１３９によってリンクされている。
【０１４５】
このようなシナリオでは、異なる外部ネットワーク・プロキシ・サーバに接続されたモバイル・ノードは、互いに独立して動作する。したがって、ノード１０などの通信ノードが、モバイル・ノード８と９の両方と通信する場合には、その通信は、それぞれの外部エージェント・プロキシ・サーバを介し、またそれぞれの外部エージェント・プロキシ・サーバは、他方の動作について知らない。
【０１４６】
したがって、例えば、通信ノード１０とモバイル・ノード８の間の通信に関して、ホーム・エージェント１２内のプロキシ・サーバの機能性の通信ピアは、外部ネットワーク・プロキシ・サーバ１４４だけである。したがって、このリンク内で一時ポートが割り振られた場合、外部ネットワーク・プロキシ・サーバ１４５は、通知を受けない。先に議論したとおり、ホーム・エージェントと外部ネットワークの間にある経路指定スイッチは、メッセージに付加されたＭＮＩＤを識別することができない。したがって、同一外部エージェントによってではあるが、同一外部ネットワーク内の異なる外部エージェント・プロキシ・サーバのサービスを受ける２つの異なるモバイル・ノードの間で、ポート衝突が生じる可能性が存在する。
【０１４７】
この理由で、このようなシナリオでは、図１５の流れ図によって示される方法が、追加ステップ２１６および２１８を備える。外部ネットワーク・プロキシ・サーバ（またはその機能的等価物）により、あるポート番号が既に使用中であると判定された後、プロキシ・サーバは、同一外部ネットワーク内の他のプロキシ・サーバ（またはその機能的等価物）に一時ポート問合せメッセージを送信する。したがって、図１６のシナリオでは、外部ネットワーク・プロキシ・サーバ１４４により、ポート番号が現在使用中ではないと判定された場合、外部ネットワーク・プロキシ・サーバ１４４は、外部ネットワーク・プロキシ・サーバ１４５に一時ポート問合せを送信する。
【０１４８】
ステップ２１８で、外部ネットワーク・プロキシ・サーバ１４４が、外部ネットワーク内の他のプロキシ・サーバから応答を受信する、または、別法では、タイムアウト後、何も応答を受信しない。次に、外部ネットワーク・プロキシ・サーバ１４４は、一時ポート番号が割り振られるべきかどうかを判定する。一時ポート番号が割り振られる必要がある場合、これは、前と同様にステップ２１２で行われる。そうでなければ、方法は、ステップ１５６に戻る。
【０１４９】
図１６のシナリオが該当するとき、図１５の流れ図の変更は、ステップ２１０と併せて実行されるステップ２１６に対するものとなる。したがって、ステップ２１０でポート衝突が識別された場合、ステップ２１６および２１８が、一時ポート番号の割振りの前に、まず実行される。これは、既に使用されている一時ポート番号が割り振られないことを確実にする。
【０１５０】
一時ポート問合せメッセージを送信するステップ２１６は、常に実行されることになる可能性が大きい。というのは、外部ネットワーク・プロキシ・サーバまたはその機能的等価物は、同一ネットワーク内に他の外部ネットワーク・プロキシ・サーバが存在するかどうかを認識しない（またはする必要がない）からである。
【０１５１】
上記では、宛先ポート番号は、異なるサービス品質セッション間におけるポート番号の衝突に応答して一時的に置き換えられると説明したが、固有フロー情報を確実にするために、フロー識別情報の他の要素を一時的に置き換えることも可能なことが理解されよう。
【０１５２】
前記説明では、外部ネットワークが外部エージェントを含むときのサービス品質セッションをサポートする技法は、有利には、モバイル・ノード識別子がホーム・エージェントと外部ネットワークの間のメッセージ・パケットに付加された、外部ネットワークと外部エージェント気付アドレスを有するモバイル・ノードとの間のサービス品質セッションをサポートする前述した好ましい技法を利用するが、本明細書に記載した技法の用途は、より広く適用可能であり、そのようなシナリオには限定されないことが理解されよう。前記の新しい技法は、サービス品質セッションをサポートする技法の性質によって異なる情報フローに関するフロー識別情報間で衝突が生じ得るようなとき、モバイルＩＰにおけるサービス品質をサポートするどのような技法においても利用することができる。
【図面の簡単な説明】
【図１】  ホーム・ネットワーク、通信ネットワーク、および外部ネットワークを含むネットワーク・セットアップを示す図である。
【図２ａ】  ＩＰパケットの標準形式を示す図である。
【図２ｂ】  ＩＰパケットの標準形式を示す図である。
【図２ｃ】  ＩＰパケットの標準形式を示す図である。
【図３】  ホーム・ネットワークのホーム・エージェントのメモリを示す概略図である。
【図４ａ】  ホーム・ネットワーク内のモバイル・ノードに対する伝送のための通信ネットワークによって構成されたＩＰパケットを示す図である。
【図４ｂ】  従来技術による外部ネットワークに前記ＩＰパケットをリダイレクトするための前記ＩＰパケットの変更を示す図である。
【図５ａ】  ホーム・ネットワーク内のモバイル・ノードに対する伝送のための通信ネットワークによって構成されたＩＰパケットを示す図である。
【図５ｂ】  代替技法による外部ネットワークに前記ＩＰパケットをリダイレクトするための前記ＩＰパケットの変更を示す図である。
【図６】  外部ネットワークがそこで外部エージェントを含む図１のネットワーク・セットアップを示す図である。
【図７ａ】  ホーム・ネットワーク内のモバイル・ノードに対する伝送のための通信ノードによって構成されたＩＰパケットを示す図である。
【図７ｂ】  外部ネットワークが外部エージェントを含むときの、本発明による外部ネットワークに前記ＩＰパケットをリダイレクトするための前記ＩＰパケットの変更を示す図である。
【図８】  図６の外部エージェントのメモリを示す概略図である。
【図９】  図６のホーム・エージェントの変更したメモリを示す概略図である。
【図１０ａ】  ＲＳＶＰをサポートするモバイルＩＰにおけるサービス品質セッションの第１セクションのパス・メッセージのＩＰパケットを示す図である。
【図１０ｂ】  ＲＳＶＰをサポートするモバイルＩＰにおけるサービス品質セッションの第２セクションのパス・メッセージのＩＰパケットを示す図である。
【図１０ｃ】  一般ＩＰにおける予約メッセージの一般終端間構造を示す図である。
【図１０ｄ】  ＲＳＶＰをサポートするモバイルＩＰにおけるサービス品質セッションの第２セクションの予約メッセージの一般終端間構造を示す図である。
【図１０ｅ】  ＲＳＶＰをサポートするモバイルＩＰにおけるサービス品質セッションの第１セクションの予約メッセージの一般終端間構造を示す図である。
【図１１】  モバイルＩＰにおけるＲＳＶＰ動作の好ましい実施を行うステップを示す図である。
【図１２】  モバイルＩＰにおけるＲＳＶＰをサポートするように適合された図１のネットワーク構成を示す図である。
【図１３】  共通外部エージェントによってサポートされる２つのモバイル・ノードを示すようにさらに適合された図１２のネットワーク構成を示す図である。
【図１４ａ】  図１３のネットワークの要素内のメモリ・レイアウト形式の一部を示す図である。
【図１４ｂ】  図１３のネットワークの要素内のメモリ・レイアウト形式の一部を示す図である。
【図１５】  図１３のネットワーク構成を動作させるステップを示す図である。
【図１６】  さらに適合された図１３のネットワーク・シナリオを示す図である。
【図１】
0003710711.tif 000002
【図２ａ】
0003710711.tif 000003
【図２ｂ】
0003710711.tif 000004
【図２ｃ】
0003710711.tif 000005
【図３】
0003710711.tif 000006
【図４ａ】
0003710711.tif 000007
【図４ｂ】
0003710711.tif 000008
【図５ａ】
0003710711.tif 000009
【図５ｂ】
0003710711.tif 000010
【図６】
0003710711.tif 000011
【図７ａ】
0003710711.tif 000012
【図７ｂ】
0003710711.tif 000013
【図８】
0003710711.tif 000014
【図９】
0003710711.tif 000015
【図１０ａ】
0003710711.tif 000016
【図１０ｂ】
0003710711.tif 000017
【図１０ｃ】
0003710711.tif 000018
【図１０ｄ】
0003710711.tif 000019
【図１０ｅ】
0003710711.tif 000020
【図１１】
0003710711.tif 000021
【図１２】
0003710711.tif 000022
【図１３】
0003710711.tif 000023
【図１４ａ】
0003710711.tif 000024
【図１４ｂ】
0003710711.tif 000025
【図１５】
0003710711.tif 000026
【図１６】
0003710711.tif 000027