(57)【特許請求の範囲】
【請求項１】
通信ノードとモバイルノードとの間でサービス品質（ＱｏＳ）セッションを設定する方法であって、前記モバイルノードは、ホームネットワークにおけるホームアドレスを有し、そして外部ネットワークにおける気付アドレスに一時的に接続されており、前記方法は、
前記外部ネットワークにおいて、前記モバイルノードのホームアドレスに代わる前記モバイルノードの前記気付アドレスのソースアドレスと、前記通信ノードの宛先アドレスとを有する修正済み応答メッセージを生成する段階と、
前記修正済み応答メッセージを送出する段階とを含むことを特徴とする通信方法。
【請求項２】
請求項１に記載の通信方法であって、さらに、
前記ホームネットワークにおいて、前記通信ノードのソースアドレスと、前記モバイルノードのホームアドレスの宛先アドレスとを有する要求メッセージを受信する段階と、
前記要求メッセージの前記宛先アドレスを前記モバイルノードの前記気付アドレスで置換して修正済み要求メッセージを生成する段階と、
前記修正済み要求メッセージを前記外部ネットワークへ送出する段階とを含み、これにより、前記修正済み要求メッセージに応答して、前記修正済み応答メッセージが生成されることを特徴とする通信方法。
【請求項３】
請求項１または２に記載の通信方法であって、さらに、
前記ホームネットワークにおいて、前記修正済み応答メッセージを受信する段階と、
前記ソースアドレスを前記モバイルノードの前記ホームアドレスで置換することによって再修正済み応答メッセージを生成する段階と、
前記再修正済み応答メッセージを送出する段階とを含むことを特徴とする通信方法。
【請求項４】
請求項１乃至３のいずれかに記載の通信方法であって、前記修正済み応答メッセージを生成する段階が前記モバイルノードにおいて実行されることを特徴とする通信方法。
【請求項５】
請求項４に記載の通信方法において、前記修正済み応答メッセージを生成する段階は、
前記モバイルノードの前記ホームアドレスのソースアドレスと前記通信ノードの宛先アドレスとを有する応答メッセージを生成する段階と、
前記ソースアドレスを前記モバイルノードの前記気付アドレスで置換する段階を含み、これにより前記修正済み応答メッセージを生成することを特徴とする通信方法。
【請求項６】
請求項１乃至３のいずれかに記載の通信方法であって、前記修正済み応答メッセージを生成する段階が、前記モバイルノードに係る前記外部ネットワーク内のプロキシ手段によって実行されることを特徴とする通信方法。
【請求項７】
請求項６に記載の通信方法であって、前記請求項２に記載の通信方法はさらに、
前記プロキシ手段における前記修正済み応答メッセージの受信に応答して、前記モバイルノードにサービス品質表示信号を送出する段階を含み、これにより、前記モバイルノードからのサービス品質アクノレッジメントの受信に応答して前記修正済み応答メッセージが生成されることを特徴とする通信方法。
【請求項８】
請求項３乃至７のいずれかに記載の通信方法であって、前記通信ノードは、前記要求メッセージを生成し、そして前記再修正済み応答メッセージを受信することを特徴とする通信方法。
【請求項９】
請求項３乃至７のいずれかに記載の通信方法であって、前記通信ノードが通信ノードプロキシ手段に関連づけられており、これにより、前記通信ノードプロキシ手段は前記通信ノードからのサービス品質要求に応答して前記要求メッセージを生成し、そして前記通信ノードプロキシ手段は前記再修正済み応答メッセージの受信に応答してサービス品質確認を生成することを特徴とする通信方法。
【請求項１０】
サービス品質セッションをサポートすることが可能な、通信ノードとモバイルノードとを有するモバイルＩＰ環境であって、前記モバイルノードは、ホームネットワークにおけるホームアドレスを有し、そして外部ネットワークにおける気付アドレスに一時的に接続されており、前記外部ネットワークは、前記モバイルノードの前記ホームアドレスに代わる前記モバイルノードの前記気付アドレスのソースアドレスと、前記通信ノードの宛先アドレスとを有する修正済み応答メッセージを生成する、前記モバイルノードに係る手段を有することを特徴とするモバイルＩＰ環境。
【請求項１１】
請求項１０に記載のモバイルＩＰ環境であって、前記手段が前記モバイルノード内に実現されていることを特徴とするモバイルＩＰ環境。
【請求項１２】
請求項１０に記載のモバイルＩＰ環境であって、前記手段が前記モバイルノードとは別個に実現されていることを特徴とするモバイルＩＰ環境。
【請求項１３】
請求項１から１２のいずれかに記載の通信方法あるいはモバイルＩＰ環境であって、前記サービス品質セッションはＲＳＶＰセッションであり、前記要求メッセージは経路メッセージであり、そして、前記応答メッセージが予約メッセージであることを特徴とする通信方法あるいはモバイルＩＰ環境。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は移動体インターネットプロトコル（モバイルＩＰ）に従ってネットワーク内のホストから移動体ノード宛に送出されるメッセージに関し、特に、あらゆる移動体ホストノードがそのネットワークへの接続点を偏光する場合においても所望されるサービス品質を維持する方法及びそのシステムに関する。
【０００２】
【従来の技術】
現在のインターネットプロトコル（ＩＰ）技術及びモバイルＩＰ技術により、特定のネットワーク（ノードにとっての‘ホーム’ネットワーク）に通常は接続されているホスト端末すなわちホストノードが一時的に相異なったネットワーク（‘外部’ネットワーク）に接続して、ホームネットワークにおけるアドレスによってそのホスト端末宛に送出されたＩＰパケットすなわちメッセージを依然として受信することが可能になっている。ネットワークへの接続点を変更することが可能なこの種のホスト端末は、移動体（モバイル）ノードとして知られている。外部ネットワークにおいても依然としてＩＰパケットを受信するためには、モバイルノードはそのホームネットワーク内に所謂‘ホームエージェント’を登録しなければならない。ホームエージェントを登録する際には、モバイルノードはそのホームエージェントに、そのモバイルノードの外部ネットワークにおけるアドレスである‘気付アドレス’を与えなければならない。その後、ホームエージェントはホームネットワーク内のトラフィックをモニタし、そのホームネットワーク内でのモバイルノードのホームアドレスに対応する宛先アドレスを有するＩＰパケットを識別すると、そのＩＰパケットをインターセプトする。次いで、ホームエージェントはそのＩＰパケットを‘再パケット化’し、外部ネットワーク内の‘気付アドレス’に存在するモバイルノード宛に送出する。‘気付アドレス’は、モバイルノードの気付アドレスあるいは外部エージェントの気付アドレスである。
【０００３】
ホームネットワーク内のアドレス宛のＩＰパケットを外部ネットワークにおける‘気付アドレス’宛に転送する技法は、モバイルＩＰ技術においては‘トンネリング（透過）’として知られている。ＩＰパケットを‘気付アドレス’宛にトンネリングさせるためには、元のＩＰパケットに含まれる所定の情報を再パケット化されたＩＰパケットにおいても保持することが重要である。例えば、ＩＰパケットの元のペイロード（すなわち情報部分）を保持すると共に、‘気付アドレス’におけるモバイルノードが、その‘再パケット化’されたＩＰパケット内で、元のＩＰパケットが送出された送出元のアドレス及びホームネットワーク内のモバイルノードのホームアドレスを識別することが可能でなければならない。
【０００４】
モバイルＩＰにおいてモバイルノードの‘気付アドレス’宛のＩＰパケットの‘トンネリング’に関して知られている一つの技法は、元のＩＰパケットを新たなＩＰパケットのＩＰパケットペイロードにカプセル化する。すなわち、元のＩＰパケットは、その内容に変更を加えられることなく新たなパケットのペイロード（すなわち情報部分）として組み込まれる。新たなＩＰパケットにはその宛先として‘気付アドレス’が付加され、新たなＩＰパケットの発信元（ソース）アドレスは、ホームエージェントとして識別される。ひとたび受信すると、‘気付アドレス’におけるモバイルノードは新たなＩＰパケットの‘ラッピング（包装）’を解き、元のパケットを回復する。
【０００５】
この技法の一つの欠点は、再パケット化されたＩＰパケットが、既存のＩＰサービス品質標準に適合したサービス品質提供サポートを促進しないことである。
【０００６】
各々のＩＰパケットには、それぞれのＩＰパケットに含まれているフロー識別情報が関連づけられており、この情報は当該ＩＰパケット伝送に係るサービス品質を識別する。このフロー識別情報は、固定されたロケーションに係るＩＰパケットにおいて存在する。なぜなら、サービス品質（ＱｏＳ）保証可能ルーティング／スイッチング素子はそのフロー識別情報を見出すことが可能であってそれに依存して動作しうるからである。しかしながら、カプセル化トンネリング技法を用いてしまうと、発信元によるＩＰパケットに含まれているフロー識別情報は、ホームエージェントと‘気付アドレス’との間では利用可能ではないからである。
【０００７】
よって、従来技術に係るモバイルＩＰにおけるカプセル化技法（それらのうちの一技法は、ＩＰ−ｉｎ−ＩＰカプセル化として知られている）は、実際の発信元アドレス（すなわち、通信ノードのアドレス）及び実際の宛先アドレス（すなわち、モバイルノードのホームアドレス）、さらにはＩＰパケット内のプロトコルＩＤを、ホームエージェントからモバイルノードまでの間、遮蔽する。加えて、カプセル化モバイルＩＰは、ペイロードインフラストラクチャを変更し（元のＩＰヘッダがペイロードの一部となる）、ルータが修正あるいは変更を検出することが可能であるようにそれに従って変更されない場合には、フロー弁別を行なうことが不能となる。ルータの変更あるいはごくわずかな修正でさえも、しばしば既存の全ルータに係る大量の再設計及び置換を必要とする。このことは、ネットワークの制御及び管理をはるかに複雑化する。セキュリティ制御及びインターオペラビリティ（共用性）の観点からも問題が生じうる。
【０００８】
インターネットにおいて用いられることが提案されているサービス品質（ＱｏＳ）実現は各種標準で規定されており、ＩＰにおいてサービス品質シグナリングに係る公知の一標準はＲＳＶＰと呼称されるものである。ＲＳＶＰ（資源予約プロトコル）は、ＩＥＴＦによって規定された統合サービスモデル（ＩｎｔＳｅｒｖ）サービス品質フレームワークにおいて用いられる。統合サービスモデルは、ある種のトラフィックに対して特別の処理を実現し、アプリケーションがそのトラフィックに関して複数個の伝達サービスレベル間で選択するメカニズムを提供し、ＯＳＩ  ＲＭ（ＡＴＭのシグナリングレイヤ２）におけるレイヤ３でサービス品質パラメータのシグナリングを実現する。
【０００９】
ＩｎｔＳｅｒｖは、二つのクラスのサービスを規定する。制御負荷クラスは、ネットワークが無負荷の場合と同じようにトラフィックデリバリを実現する（“ベター・ザン・ベスト・デリバリ”）。ＱｏＳ保証サービスクラスは、帯域保証及び遅延制限を実現した上でアプリケーションに係るトラフィックを伝達する。
【００１０】
ＩｎｔＳｅｒｖは、アプリケーションとノードとの間及びノードとノードとの間でＱｏＳ要求を通信するために、ＱｏＳ利用可能ノード及びシグナリングプロトコルを要求する。
【００１１】
ＲＳＶＰは、ＩｎｔＳｅｒｖによって用いられるＱｏＳシグナリングプロトコルである。ＲＳＶＰは、レシーバＱｏＳ要求をそのトラフィックの通過経路に沿った全てのルータノードに供給し、ソフト状態（経路／予約状態）を管理し、リソースが各々のルータにおいて予約されている状態を実現する。
【００１２】
ＲＳＶＰ／ＩｎｔＳｅｒｖサービス品質が機能するためには、フロー識別情報がＩＰパケット中の固定された位置に配置されていなければならない。ＲＳＶＰセッションは、データ伝送の前に所謂経路／予約メッセージを交換するホスト端末によって設定される。
【００１３】
それゆえ、ピアホスト端末間で通過経路を横断したサービス品質制御を可能にするためには、各ホスト端末は、必要なメッセージを設定しかつＲＳＶＰセッションに対応するサービス品質要求を認識する機能を有していなければならない。
【００１４】
【発明が解決しようとする課題】
既存のＲＳＶＰは、モバイルＩＰに基づく移動性制御シナリオにおいて経路及び予約メッセージをどのように特別に処理するかを規定していない。さらに、標準的なモバイルＩＰの‘トンネリング’（例えば、ＩＰ−イン−ＩＰカプセル化など）を行なうと、正しいフロー識別及びサービス差別化クラスがディセーブルされてしまう。
【００１５】
従って、本発明の目的は、メッセージ発信源によって決定されたサービス品質要求が当該メッセージに係るモバイルノードの‘気付アドレス’宛のルーティング経路全体に亘ってサポートされることを可能にする技法を提供することである。
【００１６】
【課題を解決するための手段】
本発明に従って、通信ノードとモバイルノードとの間のサービス品質セッションを設定する方法が本明細書において記述される。モバイルノードは、ホームネットワークにおいてはホームアドレスを有しており、外部ネットワークにおいて一時的に気付アドレスに接続されている。本発明に係る方法は、モバイルノードの気付アドレスをソースアドレス（発信元）、通信ノードのアドレスをデスティネーション（宛先）アドレスとして有する修正応答メッセージを外部ネットワークにおいて生成する段階；および、当該修正応答メッセージを送出する段階を有している。
【００１７】
本発明は、一般に、サービス品質セッションを設定する二つの端末間で要求及び応答メッセージを用いるあらゆるサービス品質セッションに対して適用可能である。
【００１８】
本発明に係る方法は、さらに、ホームネットワークにおいて、通信ノードのアドレスをソースアドレス、モバイルノードのホームアドレスをデスティネーションアドレスとしてそれぞれ含む要求メッセージを受信する段階；要求メッセージのデスティネーションアドレスをモバイルノードの気付アドレスで置換することによって修正要求メッセージを生成する段階；及び、修正要求メッセージを外部ネットワーク宛に送出する段階；このことによって、修正要求メッセージに応答して応答メッセージが生成される；を有している。
【００１９】
本発明に係る方法は、さらに、ホームネットワークにおいて修正応答メッセージを受信する段階；再修正済み応答メッセージを、ソースアドレスをモバイルノードのホームアドレスで置換することによって生成する段階；及び、再修正済み応答メッセージを送出する段階；を有している。
【００２０】
修正応答メッセージ生成段階はモバイルノードにおいて実行される。修正応答メッセージ生成段階は、モバイルノードのホームアドレスをソースノード、通信ノードのアドレスをデスティネーションアドレスとしてそれぞれ有する応答メッセージを生成する段階；及び、ソースアドレスをモバイルノードの気付アドレスで置換する段階；を有しており、このようにして修正応答メッセージが生成される。
【００２１】
修正応答メッセージ生成段階は、モバイルノードに係る外部ネットワーク中のプロキシ手段によって実行されることも可能である。
【００２２】
本発明に係る方法は、さらに、プロキシ手段における修正応答メッセージの受信に応答して、モバイルノード宛にサービス品質表示信号を送出する段階；このことによって、モバイルノードからのサービス品質アクノレッジメントの受信に応答して修正応答メッセージが生成される；を有している。
【００２３】
通信ノードは、要求メッセージを生成し、再修正済み応答メッセージを受信する。
【００２４】
通信ノードは通信プロキシ手段に関連づけられていることが可能であり、そのような場合には、通信プロキシ手段は、通信ノードからのサービス品質要求に応答して要求メッセージを生成し、再修正済み応答メッセージの受信に応答してサービス品質確認を生成する。
【００２５】
本発明は、サービス品質セッションをサポートすることが可能な、通信ノードとモバイルノードを含むモバイルＩＰ環境を実現する。このモバイルＩＰ環境においては、モバイルノードは、ホームネットワークにおいてはホームアドレスを有し、外部ネットワークにおいて一時的に気付アドレスに接続されており、外部ネットワークは、モバイルノードの気付アドレスをソースアドレス、通信ノードのアドレスをデスティネーションアドレスとしてそれぞれ有する修正応答メッセージを生成する、モバイルノードに係る手段を有している。
【００２６】
上記手段は、モバイルノード内に実現されるか、あるいはモバイルノードとは独立して実現される。
【００２７】
【発明の実施の形態】
図１は、一般的なネットワーク設定例が示されている。この例においてメッセージの宛先となるモバイルノードＭＮ８は、通常はホームネットワーク２内に位置している。モバイルノードＭＮ８は、通常、ホームネットワーク２内の特定のアドレスに存在する。このアドレスは、必ずしも静的ＩＰアドレスである必要は無い：モバイルノードはネットワーク内のあらゆる物理的な場所に位置していることが可能であるが、（物理的な接続点ではなく）特定のＩＰアドレスが当該モバイルノード自体に関連づけられている。ホームネットワークは、物理的な大きさは、スモールオフィス環境であったり、数カ国にまたがるものであったりする。
【００２８】
モバイルノードＭＮ８は、無線ＬＡＮ、赤外線リンク、無線電話リンクあるいは直接イーサネットもしくはトークンリングネットワークフックアップを介してホームネットワーク２に接続されている。‘モバイルノード’という術語は、ノードがネットワークに対して無線リンクを介して接続されているということを意味しておらず、モバイルノードがホームネットワーク２の外部に移動して図１において外部ネットワーク６として示されているような外部ネットワークに入ることが可能である、ということを意味している。このことは、後により詳細に議論される。
【００２９】
図１に示された配置には、通信ノードＣＮ１０を含む通信ノードネットワーク４が示されている。本発明の例示目的で、通信ノードネットワークの通信ノードＣＮ１０がホームネットワーク２のモバイルノード８宛にメッセージを送出することが仮定されている。通信ノードは、ホームネットワーク２とは独立でかつ別個の外部ネットワーク内に存在することも可能である。しかしながら、外部ネットワークという術語は、相異なったネットワーク（すなわち、そのホームネットワーク）内に通常存在しているモバイルノードのホストとして機能するネットワークを指し示す目的で留保されている。この具体的な例においては、ホームネットワーク２のモバイルノード８が、外部ネットワーク６へ移動したところである。よって、モバイルノードＭＮ８は、ホームネットワーク２においてはそれが通常そこに存在していることを示す目的で破線で表されており、外部ネットワークＦＮ６においてはそれが現時点で一時的に外部ネットワーク６内に存在していることを示す目的で実線で表されている。
【００３０】
通信ノード及び通信ノードネットワークという術語は、モバイルノード８の通信相手を記述するために使用されるよう留保されている。通信ノードは、モバイルノードが現時点で通信しているノードである（別なモバイルノードである可能性もある）：そして、ＩＰパケットを受信するかあるいはＩＰパケットを送信する。通信ノードネットワークは、通信ノードが接続されているネットワークを指し示す目的で用いられる。モバイルノードはそのホームネットワーク内で通信ノードと通信することも可能であり、それゆえ通信ノードネットワークがホームネットワークそれ自体である可能性があることに留意されたい。
【００３１】
図１より明らかであって、後にさらに議論されるように、ホームネットワーク２は、さらに、ホームエージェント１２を含んでいる。
【００３２】
通信ノードＣＮ１０とモバイルノードＭＮ８との間の‘通常の’通信の簡単な例が以下に与えられる。図２は、通信ノードＣＮ１０によってモバイルノードＭＮ８宛に送出されたＩＰパケット１４の一般的な構造を示している。
【００３３】
図２において参照番号１４で示されている、ネットワーク間で送出されるＩＰパケットは、一般に、ＩＰヘッダ３０とＩＰペイロード３２を有している。ＩＰペイロード３２は、モバイルノード８宛に伝達されるＩＰパケットの情報部分である。ＩＰパケットの、ここでの議論に係る部分は、図３及び図４に示されている。図３に示されているＩＰヘッダ３０は、ソースアドレス部分１６、デスティネーションアドレス部分１８、及びプロトコルＩＤ部分２０を有している。ＩＰヘッダ３０は、ここでの説明に関連しないために図３に示されていない、種々のフィールドを含んでいる。
【００３４】
図４に示されているように、ＩＰペイロード３２は、ソースポート番号３４及びデスティネーションポート番号３６を有している。ＩＰペイロード３２も、ここでの説明に関連しないために図４に示されていない、種々のフィールドを含んでいる。
【００３５】
ソースアドレス１６は、ＩＰパケットが送出されたホスト端末（通信ノード）のＩＰアドレスであり、デスティネーションアドレス１８は、ＩＰパケットの送出先のホスト端末（モバイルノード）のホームＩＰアドレスである。ソースポート番号３４は、通信ノード１０においてＩＰパケット１４に関連してアプリケーションによって用いられたポート番号である。デスティネーションポート番号３６は、ＩＰパケットの送出先であるモバイルノード８におけるアプリケーションによって用いられるポート番号である。プロトコルＩＤ２０は、なかでも、ソースアプリケーションからデスティネーションアプリケーションへのＩＰパケットシグナリングにおいてサポートされるサービス品質を表示する役割を担っている。当業者には明らかなように、デスティネーション及びソースアドレスは、ＩＰパケットをその宛先にルーティングする目的で、通信ノードとホームネットワーク内のモバイルノードとの間のルーティング交換機によって用いられる。
【００３６】
ルータあるいはルータ交換機がサービス品質（ＱｏＳ）をサポートする場合には、ＲＳＶＰ及びＩｎｔＳｅｒｖなどのある種のＱｏＳ制御方式においては、プロトコルＩＤ２０は、ソース及びデスティネーションアドレス１６及び１８、加えてエンドアプリケーションの通信ポート番号（すなわち、ソースポート番号３４及びデスティネーションポート番号３６）と共に、フローを区別して必要とされるＱｏＳ制御を課する目的で用いられる。
【００３７】
中間ルータにおいてデータトラフィックフローに課せられるＱｏＳ制御はシステム依存である。例えば、それは、所謂ＷＦＱ（重み付き公平キューイング）あるいはＣＢＱ（クラスベースキューイング）である。それらは標準のものではなく、ベンダ依存であるが、しばしば実際のユーザプロトコルＩＤには依存していない。
【００３８】
ＩＥＴＦのＩｎｔＳｅｒｖ／ＲＳＶＰ標準は、ＱｏＳ規格及びシグナリング機構を提供するように規定されているが、ＱｏＳ制御機構ではない。ＩｎｔＳｅｒｖ／ＲＳＶＰは、ＷＦＱ、ＣＢＱなどの実際のＱｏＳ制御機構とは独立である。
【００３９】
ＱｏＳ制御が実行されるステータスは、例えばＲＳＶＰなどの特定のサービス品質シグナリングプロトコル手段によって、データ転送以前にルーティング交換機内で設定される。
【００４０】
モバイルノードＭＮ８が外部ネットワーク内の位置へ移動した場合の通信ノードからモバイルノードへのＩＰパケットルーティングに係る既知の方法が以下に記述される。モバイルノードＭＮ８は、外部ネットワークへ移動する際には、ホームネットワークのホームエージェントＨＡ１２に、外部ネットワーク内に存在する場合においてもメッセージを依然として受信することが可能であるようにする目的で登録しなければならない。このことは、モバイルノードが、外部ネットワークにおいてその位置を占めた後に、ホームエージェントＨＡ１２に対して登録メッセージを送出することによって実現されうる。モバイルノードは、外部ネットワークに接続されて気付アドレスが割り当てられた時点で、外部ネットワークにおいてその位置を占めたと見なされる。
【００４１】
図５に示されているように、ホームエージェントＨＡ１２は、参照番号２４で示されているメモリすなわち検索（ルックアップ）テーブルを有している。メモリの一方の列には、ホームエージェントＨＡ１２は、通常ホームネットワーク内に存在していて一時的に外部ネットワーク内に位置していることを登録したモバイルノードのアドレスをストアしている。メモリ２４の他方の列２８には、ホームエージェントは、外部ネットワークへ移動したモバイルノードの‘気付アドレス’及びＳＰＩ（セキュリティパラメータインデックス）などの他の関連する状態をストアする。
【００４２】
ホームエージェントがモバイルノードの現時点での気付アドレス及びそのホームアドレス（すなわち、ホームネットワーク内でのモバイルノードのアドレス）を記録する技法は、通常、そのインプリメンテーションに依存する。本発明は、ホームエージェントにおいてモバイルノードの位置既知性を実現するための相異なったアプローチを排除するものではない。
【００４３】
現在知られている一技法に従った、通信ノードから外部ネットワーク内のモバイルノードへのＩＰパケットルーティングの際のホームエージェントの動作が以下に記述される。
【００４４】
通信ノードＣＮ１０は、図２に示されたものと同一のフォーマットを有するＩＰパケットを生成する。このようにして生成された通信ノードからのＩＰパケットが図６においてＩＰパケット５０として示されており、通信ノードのアドレスを識別するソースアドレス６０、ホームネットワークにおけるモバイルノードのホームアドレスを識別するデスティネーションアドレス６２、及びプロトコルＩＤ６６を有している。このプロトコルＩＤは、プロトコル‘Ａ’と呼称される。ソースポート番号及びデスティネーションポート番号は、図６から図９においては、その説明に関係していないために図示されていない。
【００４５】
図１に示された例においては、外部ネットワーク６へ移動した後、モバイルノード８には独自の‘気付アドレス’が割り当てられ、当該モバイルノードはホームネットワークにおけるホームエージェントに直接登録する。これは、ＣＯ−ＣＯＡ（共存気付アドレス）ワーキングモードとして知られている。別のワーキングモードは、ＦＡ−ＣＯＡ（外部エージェント気付アドレス）ワーキングモードとして知られているものである。モバイルノードがホームエージェントに登録する方式はモバイルＩＰにおいては公知であり、本発明に直接関連していないためここでは議論されない。
【００４６】
通信ノード１０によって生成されたＩＰパケットは、モバイルノードがホームネットワーク２内に位置しているか外部ネットワーク６内に位置しているかにかかわらず同一である。なぜなら、通信ノードは、モバイルノードの移動に係る知識を有することを要求されていないからである。しかしながら、ルート最適化を行なうモバイルＩＰは、通信ノードがモバイルノードの現時点での位置を知っている、ということを要求する。
【００４７】
モバイルノードが現在の気付アドレスを用いてホームエージェントに登録した後、ホームエージェントはモバイルノードが外部ネットワーク内に位置していると認識し、当該モバイルノードのホームアドレス宛のＩＰパケット５０をインターセプトしてこれらのＩＰパケットをモバイルノードの現時点での気付アドレス宛にトンネリングする。
【００４８】
ホームエージェントは、当該ホームネットワークに入ってくる全てのＩＰパケットをモニタし、当該ホームネットワーク内のデスティネーションアドレス（ＩＰヘッダ５２の部分６２）がホームエージェントのメモリ２４の列２６にストアされているモバイルノードのホームアドレスに一致するか否かをチェックする。
【００４９】
一致が検出されると、ホームエージェントは新たなＩＰパケット（図７に示されている）を生成する。デスティネーションアドレス、ソースアドレス、プロトコルＩＤ、及び他のＩＰヘッダフィールド及びペイロードを含む、通信ノードからの元のＩＰパケットが、この新たなＩＰパケットのペイロードの部分を構成するために用いられる。すなわち、元のＩＰパケットはホームエージェントによって処理されるのでは全く無く、そのまま変更せずに新たなＩＰパケット３０のペイロード３２に組み込まれる。
【００５０】
その後、ホームエージェントは、デスティネーションアドレス３６、ソースアドレス３８及びプロトコルＩＤ４０を新たなＩＰパケット３０に付加する。
【００５１】
デスティネーションアドレス３６は、ＩＰパケットの送出先である、外部ネットワーク内のアドレス、すなわちモバイルノードＭＮ８の‘気付アドレス’である。ソースアドレス３８は、新たなＩＰパケット３０の発信元、すなわちホームエージェントのアドレスである。
【００５２】
ホームエージェントプロトコルＩＤは、ホームエージェントそれ自体によって決定されるプロトコルＩＤである。ホームエージェントは、通信ノードによって元のＩＰパケットに含められたプロトコルＩＤ２０にかかわらず、常に同一のプロトコルＩＤを新たなＩＰパケット３０に付け加える。なぜなら、ホームエージェントは元のＩＰパケット１４のプロトコルＩＤ２０を見ないからである。プロトコルＩＤ４０は、プロトコル‘Ｘ’として示される。従来技術に係るモバイルＩＰのＩＰ−イン−ＩＰカプセル化においては、プロトコルＩＤはホームエージェントによって常に“１”に変更される。よって、‘実際の’ソース及びデスティネーションアドレス（図６の６０及び６２）は、新たなＩＰパケットのペイロード部分に移動され、元のＩＰペイロード中のソース及びデスティネーションポート番号などの他の必要なフロー識別情報も新たなＩＰパケットのペイロード部分に包み込まれている。
【００５３】
よって、通信ノードからモバイルノードへのフローに係る元々の識別が失われ、ＩＰパケットがホームエージェントから外部ネットワークへルーティングされる際のサービス品質保持ができなくなる。
【００５４】
その後、ＩＰパケット３０は、ホームエージェントによって送出され、外部ネットワーク内のモバイルノードの‘気付アドレス’に到達するようにルーティングされる。ＩＰパケット３０が‘気付アドレス’に到達すると、モバイルノードは新たなＩＰパケット３０の外部レイヤを剥ぎ取って元のＩＰパケット５０を回復する。
【００５５】
よって、この既知の配置においては、元のＩＰパケットのプロトコルＩＤに含まれている必要とされるフロー識別情報がホームエージェントによって遮蔽されてしまい、ホームエージェントとモバイルノードの‘気付アドレス’との間のサービス品質を実現するルーティング交換機（あるいはＩＰルータ）によって認識され得ないようになる。
【００５６】
本発明に係る望ましい実装に従った、通信ノードからモバイルノードの‘気付アドレス’へのＩＰパケットのルーティングが以下に記述される。この望ましい実装に従った方式においては、通信ノードによって生成された元のＩＰパケットに含まれる元のソースアドレス、元のソース及びデスティネーションポート番号、及びソースプロトコルＩＤなどのフロー識別／分別情報が変更されずに保持され、結果として通信ノードとモバイルノードの‘気付アドレス’との間の全てのルーティング交換機にとってそれらを利用することが可能となる。
【００５７】
通信ノードは、図８に示されているような、従前のものと同一のＩＰパケット５０を生成する。ホームネットワークに到達すると、ホームエージェント１２は、そのＩＰパケットが配送されるべきモバイルノードが外部ネットワークへ移動したと登録されているか否かを、前述された方法の場合と同じくメモリ２４の内容をチェックすることによって決定する。メモリ列２６においてデスティネーションアドレスを検出すると、ホームエージェントはそのＩＰパケットをインターセプトする。
【００５８】
この実装においては、ホームエージェントＨＡは、ホームネットワーク２におけるモバイルノード８のデスティネーションアドレス６２を除去し、それを外部ネットワーク６におけるモバイルノードＭん８のデスティネーションアドレス（すなわち、‘気付アドレス’）で置換することによってＩＰパケット１４を修正する。従って、新たなＩＰパケット４２は、元のＩＰパケット５０のペイロード６３、元のＩＰパケット５０のソースアドレス６０、及び元のＩＰパケット５０のプロトコルＩＤ６６を有している。元のＩＰパケットのデスティネーションアドレス６２は新たなデスティネーションアドレス４１（モバイルノードの‘気付アドレス’）によって置換されている。
【００５９】
もちろん、当業者は、デスティネーションアドレスの変更の観点から、元のＩＰパケット５０に対して与えられたエラーチェックを修正する必要がある、ということを容易に認識するであろう。このようにして、生成された新たなＩＰパケットは、外部ネットワークにおける‘気付アドレス’宛に送出される。その後、ＩＰパケットは、通信ノードのソースアドレス、元のプロトコルＩＤ及び他の元のフロー識別情報を含むフロー情報を有する状態でモバイルノード宛にルーティングされる：  ペイロード部分が変更されていないため、ソース及びデスティネーションポート番号がＩＰパケット中で以前と同一の位置で利用可能であることに留意されたい。
【００６０】
よって、フロー識別情報は、同一のＱｏＳ要求を実現している同一の通信ノードからホームエージェントと‘気付アドレス’との間のルータによって、通信ノードとホームエージェントとの間の場合と同様、モバイルノードの移動にかかわらず認識可能である。従って、この配置（ＣＯ−ＣＯＡワーキングモード）においては、本発明に従ってホームエージェントによって生成された新たなＩＰパケット４２は、通信ノードによって生成された元のＩＰパケットと同一の長さを有している。
【００６１】
この望ましいトンネリング実装においては、フロー情報は隠されず、それゆえサービス品質は見かけ上サポートされる。しかしながら、ＲＳＶＰサービス品質においては、このことは当てはまらない。なぜなら、ＲＳＶＰが正確に機能するためには、（所謂経路（Ｐａｔｈ）メッセージによって示されたものと同一のホップに従ってホップ毎にルーティングされる）所謂予約（Ｒｅｓｖ）メッセージに引き続く送出経路は、経路メッセージと同一かつ逆方向の経路でなければならないからである。すなわち、経路メッセージのソースアドレスは予約（Ｒｅｓｖ）メッセージのデスティネーションアドレスと一致しなければならず、経路メッセージのデスティネーションアドレスは予約メッセージのソースアドレスと一致しなければならない。図１に示されたネットワーク構造におけるＲＳＶＰセッションの設定に係る以下の例は、前述された非カプセル化モバイルＩＰが、サービス品質をサポートするために充分では無い理由を表している。
【００６２】
図１に示されているようにモバイルノードが外部ネットワークに移動した場合においてもＲＳＶＰセッションをサポートするためには、二つのＲＳＶＰセッションが設定されなければならない：  通信ノード１０とホームエージェント１２との間の第一ＲＳＶＰセッション（“セッション１”）、及び、ホームエージェントとモバイルノード８との間の第二ＲＳＶＰセッション（“セッション２”）である。
【００６３】
この例ではメッセージをモバイルノード８宛に送出すると仮定されている通信ノード１０は、図１０に示されたような一般的なフォーマットを有するＩＰパケット７０を含む標準ＲＳＶＰ経路メッセージを回線１２８上に送出する。
【００６４】
ＲＳＶＰセッションにおいて用いられるメッセージを構成するＲＳＶＰパケットは、図２から図４に示されたフォーマットを有していない。図２から図４に示されたＩＰパケットは、データメッセージよりなるＩＰパケットである。図１０に示された経路メッセージよりなるＩＰパケットは、通信ノードのアドレスに対応するソースアドレス７８、及びホームネットワークにおけるモバイルノード８のアドレス（モバイルノードのホームアドレス）に対応するデスティネーションアドレスを有している。
【００６５】
経路メッセージ（及び他のＲＳＶＰメッセージ）よりなるＩＰパケットは、付加的に、ＩＰパケットのペイロードに別のフロー識別情報を含んでいる。当業者には、これらの別のフロー識別情報は明らかである。
【００６６】
通信ノード１０からの経路メッセージよりなるＩＰパケットは、図１において１３２ａで示されている、回線１２８及び１２４上の複数個のルーティング交換機を介してホームネットワーク２宛にルーティングされる。
【００６７】
ルーティング交換機１３２ａは、サービス品質をサポートしている場合には、経路メッセージよりなるＩＰパケットのＩＰペイロード中のフロー識別情報を抽出し、このフロー識別情報をストアする。このフロー識別情報には、ソースアドレス、デスティネーションアドレス、ソースポート番号、デスティネーションポート番号、及びプロトコルＩＤが含まれる。これらは、サービス品質セッションが設定された後にソースからデスティネーション宛に送出される全てのＩＰデータパケットに含まれることになるものである。ルーティング交換機１３２ａは、経路メッセージよりなるＩＰパケットを別のルーティング交換機宛にルーティングし、付加的に、ＩＰパケットから抽出されたフロー識別情報と共に、当該メッセージを送出した先（次のホップ）のルーティング交換機のアドレス及び受信したメッセージの送信元（直前のホップ）のルーティング交換機のアドレスをストアする。図１においては、ＩＰパケットが単一のルーティング交換機１３２ａのみを介してホームネットワークに到達するように示されているが、実際には、ＩＰパケットは複数個のルーティング交換機を介してホームネットワークに到達するので、各ルーティング交換機は、経路メッセージよりなるＩＰパケットから抽出したフロー識別情報を、当該ＩＰパケットの送出先のルーティング交換機及び当該受信したパケットの送出元のルーティング交換機の識別と共にストアする。
【００６８】
このように、経路メッセージよりなるＩＰパケットは、通信ノードからホームネットワークまで、ルーティングネットワークを介して伝播する。各ルーティング交換機は、そのＩＰパケットが送出された元のホップのアドレス及びそのＩＰパケットを送出した次のホップのアドレス、さらにはそのＩＰパケットに係るフロー識別情報を保持している。ルーティング交換機は、経路メッセージ中の他のトラフィック関連情報も処理するが、それらは本発明の議論とは関連していない。
【００６９】
サービス品質セッションが設定された後、ルーティング交換機のメモリにストアされたものと同一のフロー識別情報を有する別のＩＰパケットがそのルーティング交換機に到達すると、ルーティング交換機は、それを、全く同一の次のホップへ転送する。次のホップのアドレスはメモリ中にストアされている。
【００７０】
このように、それ以降のホップにおいては、各々のルーティング交換機は、（それがＲＳＶＰサービス品質をサポートする限りは）経路メッセージよりなるＩＰパケットの固定された位置からフロー識別情報を読み出し、それらを、次のホップ及び直前のホップのアドレスと共にメモリにストアする。よって、ＩＰパケット中のフロー識別情報はメッセージフローをその他のものと混同することなく識別するために有用であり、そのメッセージフローに関連する全てのパケットがソースからデスティネーション宛に全く同一の経路を通じてルーティングされる。
【００７１】
その後、ホームエージェントは、モバイルノード宛に企図された経路メッセージよりなるＩＰパケットをインターセプトする。ホームエージェントは、モバイルノード８宛の経路メッセージよりなるＩＰパケットをインターセプトすると、それらを外部ネットワーク宛にリダイレクトする。この例では、非カプセル化モバイルＩＰが用いられ、新たなＩＰパケットが、新たなあるいは修正された経路メッセージとして外部ネットワーク宛に送出されるように生成される。ホームエージェントによって送出される、修正された経路メッセージよりなるＩＰパケット７４が図１１に示されている。ホームエージェントは、経路メッセージよりなるＩＰパケットのデスティネーションアドレスを、修正された経路メッセージよりなるＩＰパケット７４のデスティネーションアドレス１０６が外部ネットワークにおけるモバイルノードの気付アドレスとなるように置換する。前述されているように、非カプセル化モバイルＩＰにおいては、ＩＰパケット７０の他の全ての要素は不変に保たれる。
【００７２】
この修正された経路メッセージは、回線１２６及び１３０上で単一のルーティング交換機１３２ｂによって表現されているルーティング交換機を介してモバイルノードの気付アドレス宛にルーティングされる。
【００７３】
経路メッセージの第一セクションに関して既に記述されているように、経路メッセージの第二セクションにおいては、修正された経路メッセージよりなるＩＰパケットは、それらに含まれているフロー識別情報に基づいて同様に送出される。次のホップ及び直前のホップが、ルーティング交換機によって同様にストアされる。
【００７４】
モバイルノードは、修正された経路メッセージを受信して、図１２に示されたような一般的なフォーマットのＩＰパケット７６を有する、送出目的の予約メッセージを生成することによって、第二セクションに係る予約（Ｒｅｓｖ）メッセージを開始する。
【００７５】
予約メッセージ（Ｒｅｓｖ）よりなるＩＰパケットが経路メッセージよりなるＩＰパケットと同一のネットワーク経路に沿ってホップ毎に逆方向に送出されていくことは当業者には明らかである。よって、予約メッセージよりなるＩＰパケットのソース及びデスティネーションアドレスは、実際に、最終及びその直前のホップである。ソース及びデスティネーションアドレスの値は、予約メッセージが経路に沿って伝達されるに連れて動的に決定される。図１２に示された予約メッセージよりなるＩＰパケットの構造は、実際には、予約メッセージのトランスポートレイヤを表現している。図１２に示された構造は、発信側ソースアドレス及び最終デスティネーションアドレスという予約メッセージの概念を表しているものである。予約メッセージのこの分析は若干人為的なものであるが、ＲＳＶＰの原理を最も良く表現する。
【００７６】
モバイルノード８は、ソースアドレス１１４を当該モバイルノードのホームアドレスと認識する。標準モバイルＩＰは、モバイルノードそれ自体におけるアプリケーションがモバイルノードのネットワークへの接続点の変更を認識している、ということを要求しない。それゆえ、モバイルノードの位置にかかわらず（ホームネットワークに存在するか外部ネットワークに存在するかにかかわらず）モバイルノードは、当該モバイルノードのホームアドレスをソースアドレスとして識別するＩＰパケットを常に生成する。モバイルノードは、予約メッセージのデスティネーションアドレスに通信ノードのアドレスを含める。これは、標準モバイルＩＰに従って、モバイルノードはメッセージが通信ノードから発せられたものであることを認識しており、ホームエージェントを介したリダイレクションを認識していないからである。標準モバイルＩＰでモバイルノードから通信ノード宛に送出されたＩＰパケットは、モバイルノードがあたかもホームネットワーク内の‘ホームアドレス’にいるかのように、通常のＩＰパケットとしてルーティングされる。
【００７７】
図１１及び図１２に示された経路及び予約メッセージよりなるＩＰパケットを比較すると、ＲＳＶＰセッションが成功するための条件は存在しない。予約メッセージ７６のソースアドレスは、経路メッセージ７４のデスティネーションアドレスとは異なっている。
【００７８】
このため、経路メッセージよりなるＩＰパケットによって設定されたものと同一のネットワーク経路に従ってホップ毎にルーティングされる予約（Ｒｅｓｖ）メッセージが失敗してしまう。第一セクション（ホームエージェントと通信ノードとの間）では、予約メッセージが全く開始されない。なぜなら、第二セクションで失敗してしまうからである。
【００７９】
図１５は、図１に示されたネットワーク配置を、非カプセル化モバイルＩＰがＲＳＶＰをサポートすることを可能にするように適応させたものが示されている。この配置では、プロキシサーバが通信ノードネットワーク及び外部ネットワークに導入されている。しかしながら、以下の記述から、プロキシサーバの機能が実際にはプロキシサーバに接続されているホスト端末に組み込まれうることに留意されたい。以下、図１５に示された配置の説明に引き続いてより詳細な説明が与えられる。
【００８０】
図１５においては、図１のネットワークが、通信ノードネットワーク４がさらに通信ノードネットワークプロキシサーバ１４２を、外部ネットワーク６が外部ネットワークプロキシサーバ１４４を、それぞれ含むように適応させられている。通信ノード１０は、ネットワーク回線１３８を介して通信ノードネットワークプロキシサーバ１４２に接続されている。通信ノードネットワークプロキシサーバは、ネットワーク回線１２８を介してルーティング交換機に接続されている。外部ネットワークプロキシサーバ１４４は、外部ネットワーク６内のモバイルノード８にネットワーク回線１４６を介して接続されている。外部ネットワークプロキシサーバは、ネットワーク回線１３６を介してルーティング交換機１３２ｂに接続されている。
【００８１】
以下に、図１５に示された適応済みネットワークにおいて、通信ノード１０からの外部ネットワーク内のモバイルノード８へのメッセージがＲＳＶＰをサポートしている非カプセル化モバイルＩＰを用いて送出される際の動作例が記述される。
【００８２】
ネットワーク内でサービス品質実現を要求する各ホスト端末は、ネットワーク内のプロキシサーバの存在を認識している必要がある。すなわち、ホスト端末がプロキシサーバを発見することが可能なプロセスが存在しなければならない。このことを実現するためには、実質的に二つの方法が存在する。第一の方法においては、ネットワーク内のホスト端末がサーバ請求メッセージ（ＳＳＭ）をブロードキャストする。ネットワーク内のプロキシサーバは、ホスト端末宛にサーバ応答メッセージ（ＳＲＭ）を返送することによって応答する。第二の方法においては、ネットワーク内のプロキシサーバがローカルネットワーク宛にクライアント要求メッセージ（ＣＲＱＭ）をブロードキャストする。それに応答して、（プロキシサーバのクライアントと見なされる）ホスト端末は、クライアント登録メッセージ（ＣＲＧＭ）を返送する。この方法では、ネットワーク内のプロキシサーバの存在は、現在の標準モバイルＩＰにおいてエージェント（ホームエージェント、外部エージェントなど）の存在が登録されるのと全く同じ方式でネットワーク内のホスト端末によって登録される。ノードによるプロキシサーバ登録の実装技法は、当業者には明らかである。
【００８３】
既に議論されているように、通信ノードがモバイルノード宛にメッセージを送出する際に通信ノードとモバイルノードとの間でのサービス品質セッション設定を成功させるためには、ＲＳＶＰセッションを二つのセクションにおいて設定することが必要である。概説すれば、サービス品質セッションの第一セクションは通信ノードネットワークとモバイルノードのホームネットワークとの間で設定されなければならず、サービス品質セッションの第二セクションはホームネットワークと外部ネットワークとの間で設定されなければならない。
【００８４】
図１５に示されたネットワーク配置において第一サービス品質セッション、特にモバイルＩＰでのＲＳＶＰセッション、を設定する技法が図１６の流れ図に示されている。本発明に従って、段階１５０においては、サービス品質セッションを開始する通信ノード１４ａが、ネットワーク回線１３８上に通信ノードネットワークプロキシサーバ１４２宛のサービス品質要求を送出する。
【００８５】
サービス品質要求は、暗示的であるか明示的であるかのいずれかである。通信ノードからの明示的サービス品質要求は、サービス品質要求を正確に規定する。よって、明示的サービス品質要求は、通信ノードが特定のサービス品質を明示的に記述することをサポートする機能を有する場合にのみ発行される。通信ノードからの暗示的サービス品質要求は、その後になされる伝送の性質のみを規定する。例えば、暗示的サービス品質要求は、送出されるデータがビデオデータであるということを示す。その後、プロキシサーバが、示されたデータタイプに依存して、適切なサービス品質を決定する。
【００８６】
段階１５２において、通信ノードネットワークプロキシサーバ１４２は、標準ＲＳＶＰ経路メッセージを送出する。この経路メッセージは、回線１２８及び１２４上のルーティング交換機１３２ａを介してホームネットワークプロキシサーバ宛に伝達される。
【００８７】
通信ノードネットワークプロキシサーバによって送出された経路メッセージよりなるＩＰパケットは、図１０のＩＰパケット７０に同一に対応するものであって、ルータ交換機１３２を含むルーティングネットワークによってホームエージェント１２宛に送出される。ルーティングは、前述されたものと全く同様に実行される。
【００８８】
段階１５４では、ホームエージェントが経路メッセージよりなるＩＰパケットをインターセプトし、前述されているように当該ＩＰパケットを適応させて修正経路メッセージ用のＩＰパケットを生成する。
【００８９】
修正経路メッセージよりなるＩＰパケットは、図１１に示されたＩＰパケット７４と同一に対応するものである。段階１５６においては、経路メッセージ７４の第二セクションを有するＩＰパケットがホームエージェントによって送出され、ルーティング交換機１３２ｂによって表わされているルーティングネットワークを介して外部ネットワーク１４４宛にルーティングされる。
【００９０】
段階１５８においては、外部ネットワークプロキシサーバ１４４は経路メッセージの第二セクションを受信し、回線１４６上でモバイルノード８宛にサービス品質表示信号を送出して、通信ノード１０によって要求されたサービス品質を表示する。サービス品質レベルがモバイル端末にとって受容しうるものである場合には、モバイル端末は、サービス品質応答を、ネットワーク回線１４６上での外部ネットワークプロキシサーバ１４４へのアクノレッジメントの形で送出する（段階１６０）。
【００９１】
段階１６２においては、外部ネットワークプロキシサーバは修正予約メッセージ（すなわち、標準モバイルＩＰに従って送出された予約メッセージに対して修正されたもの）を送出し、サービス品質セッションを確認する。予約メッセージは、回線１３６及び１２６を介して、経路メッセージと同一の経路を（逆方向に）たどる。
【００９２】
外部ネットワークプロキシサーバによって返送される、第二ＲＳＶＰセッションに係る修正予約メッセージ７７のフォーマットが図１３に示されている。この図から明らかなように、外部ネットワークプロキシサーバ１４４を用いているために、ソースアドレス１５５がモバイルノードの気付アドレスであり、デスティネーションアドレスが通信ノードのアドレスである。よって、第二ＲＳＶＰセッションにおける経路及び予約メッセージのソース及びデスティネーションアドレス間では正確な相関が存在し、そのためＲＳＶＰセッションがサポートされる。
【００９３】
図１３に示されたメッセージは、外部ネットワークとホームネットワークとの間のエンド−ツー−エンドメッセージを表現している。図１３に示されたフォーマットは、前述されたような次及び直前のホップに対応するソース及びデスティネーションアドレスを有するような予約メッセージよりなるＩＰパケットを表わしているのではない。
【００９４】
段階１６４においては、ホームエージェントは修正予約メッセージを受信する。ホームエージェントは当該予約メッセージを図１４に示されたような形態に修正し、これはさらに再修正済み予約メッセージを構成する。この修正を実行するために、ホームエージェントにはそれ自体にプロキシサーバの機能が備わっている。あるいは、通信ノードネットワークプロキシサーバ及び外部ネットワークプロキシサーバと同等のホームネットワークプロキシサーバがホームネットワークに備えられており、ホームエージェントに関連づけられている。
【００９５】
ＲＳＶＰセッションは、ホームエージェントがネットワーク回線１２４及び１２８及びルーティング交換機１３２ａを介して通信ノードネットワークに再修正済み予約メッセージを返送することによって完了する。図１４に示されているように、予約メッセージはソースアドレス８８としてモバイルノードのホームアドレスを、そしてデスティネーションアドレスとして通信ノードのアドレスをそれぞれ有している。よって、通信ノードネットワークとホームネットワークとの間のＲＳＶＰセッション部分は標準静的ＲＳＶＰセッションと等価である。ＲＳＶＰをサポートする目的でルーティングネットワークにおけるルーティング交換機によって必要とされるフロー情報は全て利用可能である。再修正済み予約メッセージにおけるソース及びデスティネーションアドレスは、経路メッセージと比較して‘入れ替えられている’。
【００９６】
段階１６６においては、ホームエージェントが第一セクションに対して予約メッセージを送出する。再修正済み予約メッセージが通信ノードネットワーク４に対して送出され、通信ノードネットワークプロキシサーバ１４２によって受信される。
【００９７】
その後、通信ノードネットワークプロキシサーバは、段階１６８において、通信ノード１０へのアクノレッジメントの形態でネットワーク回線１３８上にサービス品質確認メッセージを送出し、サービス品質セッションが設定されたことを示す。
【００９８】
その後、通信ノード１０は、モバイル端末に対してデータメッセージパケットの送出を開始する。しかしながら、データメッセージパケットは、通信ノードネットワークプロキシサーバや外部ネットワークプロキシサーバを経由しない。プロキシサーバは、ＲＳＶＰセッション設定の間のみ利用される。
【００９９】
前述されているようにＲＳＶＰセッションが設定されてメッセージが通信ノードからモバイルノード宛に送出されると、データメッセージよりなるＩＰパケットによって担われるフロー識別情報がＲＳＶＰセッションの設定において用いられたものと一致することが本質的である。よって、図２から図４に示されているような一般的なフォーマットを有するデータパケットは、ＲＳＶＰメッセージのペイロードにおいて含まれていたものと同じソースポート番号、デスティネーションポート番号、及びプロトコルＩＤさらにはソース及びデスティネーションアドレスを有していなければならない。このようにして、データＩＰパケットは、ＲＳＶＰセッションにおいて設定されたフローに関連しているものとして正しく識別される。よって、外部ネットワークプロキシサーバを実現することは、ＲＳＶＰサービス品質がモバイルＩＰにおいてもサポートされることを保証する。よって、図１５に示されているプロキシサーバは、“ＲＳＶＰプロキシサーバ”と見なされうる。プロキシサーバは、ＲＳＶＰメッセージのデスティネーションをモバイルノードの移動に従うように動的に修正し、同時にフロー識別情報及びサービス品質情報が、非カプセル化モバイルＩＰ（ＮＥＭＩＰ）に従ってルーティングされるデータフローに一致することを保証する。
【０１００】
以上の記述から、プロキシサーバ（あるいはプロキシサーバと同等の機能）が外部ネットワークにおいて実現されることが本質的であることが理解される。この場合のネットワークとは、モバイルＩＰにおいてサービス品質がサポートされる場合には、ホスト端末が外部ネットワークに通常存在していることを許容するネットワークである。
【０１０１】
外部ネットワークにＲＳＶＰプロキシサーバ（あるいは機能的に同等のもの）を実現することは、設定されたＲＳＶＰセッション（特に、ＲＳＶＰセッションの第二セクション）がモバイルノードの移動に従う、同時に、ＲＳＶＰセッションと同一の経路をたどるデータフローと一致する正しいフロー情報を、モバイルノードのネットワークへの接続点の変更にかかわらずに記録する、ということを保証する。
【０１０２】
いずれのホスト端末も、送信時点においては、その送信先のホスト端末がモバイルノードであるか否か、さらには、それがＲＳＶＰプロキシサーバを有する外部ネットワーク内に存在しているか、を認識することはない。モバイルＩＰにおいてＲＳＶＰのサポートを保証するために、モバイルノードに対する外部ネットワークとして機能することが可能な各々のネットワークは、本明細書に記述されているような機能を有するプロキシサーバ（あるいはその機能的に同等なもの）を備えることが必要である。外部ネットワークにおいてプロキシサーバによって実行される機能制御に係る以上の記述は、モバイル環境においてサービス品質をサポートするために本質的なものである。
【０１０３】
モバイルノード宛のデータメッセージ送出を希望する、通信ノードネットワーク内の通信ノードにとってサービス品質をサポートするために本質的な必要条件は、モバイルノードが位置している外部ネットワークがプロキシサーバあるいは機能的に同等なものを有していなければならない、ということである。その際には、通信ノードは通信ノードネットワークプロキシサーバを必要とすることなく、それ自体で直接ＲＳＶＰセッションを設定することが可能である。
【０１０４】
しかしながら、通信ノードネットワークプロキシサーバを実現することは、それが、通信ノードネットワーク内に存在する、ＲＳＶＰ機能を有さない端末がＲＳＶＰセッションを開始することを可能にする、という利点を有している。プロキシサーバは、プラットフォームとアプリケーションの双方から独立したサービス品質セッションを設定する技法を実現する。サービス品質セッションを設定する専用の手段を与えることによって、現時点及び将来におけるサービス品質不能ホスト端末がサービス品質セッション設定機能を有することが可能になり、伝送経路を介してその通信相手先へのサービス品質制御が可能になる。多くのサービス品質制御シグナリング及び制御機構で必要とされる複雑かつ大量の計算や無線／モバイル端末に係るバッテリパワーへの圧力が回避される。
【０１０５】
別のアプリケーションにおいては、外部ネットワークにおいて実行されたプロキシサーバの機能が、モバイルノードそれ自体によって実行される。このようなアプリケーションでは、モバイルノードは既にＲＳＶＰ可能であり、標準ＲＳＶＰセッションをサポートするＲＳＶＰデーモンを有している。この種のアプリケーションにおいては、ホームネットワークからの修正経路メッセージの受信に応答して、モバイルノードは図１２に示されているようなフォーマットを有する標準ＲＳＶＰメッセージを生成する。モバイルノードのＲＳＶＰデーモンに組み込まれたプロキシサーバ機能が、この予約メッセージを修正して図１３に示されているような修正済み予約メッセージを生成する。その後、この修正済み予約メッセージは、モバイルノードから直接送出される。
【０１０６】
以上、本明細書において記述された実施例においては、標準ＲＳＶＰが用いられている。標準ＲＳＶＰ／ＩｎｔＳｅｒｖへの変更は何ら企図あるいは提案されていない。
【０１０７】
本発明は、経路及び予約メッセージを用いるＲＳＶＰサービス品質セッションの特定の実例に関連して記述されているが、本発明は、サービス品質セッションを設定するために二つの端末間で要求及び応答メッセ次を用いるあらゆるサービス品質セッションに対して、本明細書において識別された問題点を克服するという要求が存在するような場合に、より一般的に適用可能である。
【０１０８】
以上の説明は、本発明の一実施例に関するもので，この技術分野の当業者であれば、本発明の種々の変形例が考え得るが、それらはいずれも本発明の技術的範囲に包含される。
【０１０９】
【発明の効果】
以上述べたごとく、本発明によれば、メッセージ発信源によって決定されたサービス品質要求が当該メッセージに係るモバイルノードの‘気付アドレス’宛のルーティング経路全体に亘ってサポートされることを可能にする技法が提供される。
【図面の簡単な説明】
【図１】ホームネットワーク、通信ノードネットワーク、及び外部ネットワークを有するネットワーク設定例の概略を示す模式図。
【図２】ＩＰパケットの標準的なフォーマットを示す模式図。
【図３】ＩＰパケットの標準的なフォーマットを示す模式図。
【図４】ＩＰパケットの標準的なフォーマットを示す模式図。
【図５】ホームネットワークにおけるホームエージェントのメモリを示す模式図。
【図６】通信ノードによって、ホームネットワーク内のモバイルノード宛の伝送を目的として生成されたＩＰパケットを示す模式図。
【図７】従来技術に従って、図６に示されたＩＰパケットを外部ネットワーク宛にリダイレクトするためになされた修正を示す模式図。
【図８】通信ノードによって、ホームネットワーク内のモバイルノード宛の伝送を目的として生成されたＩＰパケットを示す模式図。
【図９】別の技法に従って、図６に示されたＩＰパケットを外部ネットワーク宛にリダイレクトするためになされた修正を示す模式図。
【図１０】標準的なモバイルＩＰにおけるサービス品質セッションの第一セッションにおける経路メッセージのＩＰパケットを示す模式図。
【図１１】標準的なモバイルＩＰにおけるサービス品質セッションの第二セッションにおける経路メッセージのＩＰパケットを示す模式図。
【図１２】一般的なＩＰにおける予約メッセージの一般的なエンド・ツー・エンドストラクチャを示す模式図。
【図１３】ＲＳＶＰをサポートするモバイルＩＰにおけるサービス品質セッションの第二セクションにおける予約メッセージの一般的なエンド・ツー・エンドストラクチャを示す模式図。
【図１４】ＲＳＶＰをサポートするモバイルＩＰにおけるサービス品質セッションの第一セクションにおける予約メッセージの一般的なエンド・ツー・エンドストラクチャを示す模式図。
【図１５】モバイルＩＰにおいてＲＳＶＰをサポートするように適合させられた、図１に示されたネットワーク配置を示す模式図。
【図１６】モバイルＩＰにおいてＲＳＶＰ動作の望ましい実装例を実行する段階を示す流れ図。
【符号の説明】
２  ホームネットワーク
４  通信ノードネットワーク
６  外部ネットワーク
８  モバイルノード
１０  通信ノード
１２  ホームエージェント
１４  ＩＰパケット
１６  ソースアドレス
１８  デスティネーションアドレス
２０  プロトコルＩＤ
２４  ルックアップテーブル
２６  ホームネットワークでのモバイルノードアドレス
２８  外部ネットワークでのモバイルノードアドレス
３０  ＩＰヘッダ
３２  ＩＰペイロード
３４  ソースポート番号
３６  デスティネーションポート番号
３８  ソースアドレス
４０  プロトコルＩＤ
４１  デスティネーションアドレス
５０  ＩＰパケット
６０  ソースアドレス
６２  デスティネーションアドレス
６３  ペイロード
６６  プロトコルＩＤ
７０、７４、７６  ＩＰパケット
７８  ソースアドレス
８０  デスティネーションアドレス
１０４  ソースアドレス
１０６  デスティネーションアドレス
１１４、１１５、１１９  ソースアドレス
１１６、１１７、１２１  デスティネーションアドレス
１２４、１２６、１２８、１３０  ネットワーク回線
１３２ａ、１３２ｂ、１３２ｃ  ルーティング交換機
１３６、１３８、１４６  ネットワーク回線
１４２  通信ノードネットワークプロキシサーバ
１４４  外部ネットワークプロキシサーバ
【図１】
0003545987.tif 000002
【図２】
0003545987.tif 000003
【図３】
0003545987.tif 000004
【図４】
0003545987.tif 000005
【図５】
0003545987.tif 000006
【図６】
0003545987.tif 000007
【図７】
0003545987.tif 000008
【図８】
0003545987.tif 000009
【図９】
0003545987.tif 000010
【図１０】
0003545987.tif 000011
【図１１】
0003545987.tif 000012
【図１２】
0003545987.tif 000013
【図１３】
0003545987.tif 000014
【図１４】
0003545987.tif 000015
【図１５】
0003545987.tif 000016
【図１６】
0003545987.tif 000017