JP2010521847A - 移動体ネットワークにおけるインタフェース選択 - Google Patents

Abstract

移動体ルータにアタッチされた移動体ネットワークノードのためのトラヒックルートを確立する方法であって、前記移動体ルータは、自身が利用可能な複数のアップストリームインタフェースを有する。方法は、移動体ルータから、移動体ネットワークノードへ、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングされる、インタフェースの識別子と該インタフェースの特性とを送信する工程を含む。ＩＰｖ６の場合、識別子は、移動体ルータがブロードキャストするルータ通知メッセージ内に含まれてもよい。移動体ネットワークノードでは、識別されたインタフェースの特性に基づいてインタフェースが選択される。少なくとも所定の送出パケットのトラヒッククラス又はサービス・タイプのフィールドは、選択されたインタフェースの識別子を含む。移動体ルータでは、トラヒッククラス又はサービス・タイプのフィールドに含まれる識別子に対応するインタフェースを介して、典型的には、パケットヘッダ内のトラヒック・クラス値の検出に応じて生成されたルールを利用して、パケットがルーティングされる。
【選択図】図１

Description

本発明は、移動体ネットワークにおけるインタフェースの選択に関する。特には、移動体ルータのダウンストリームに配置された移動体ネットワークノードによる、移動体ルータのアップストリームのインタフェースの選択に関する。

電車、バス、飛行機およびパーソナル・エリア・ネットワーク（ＰＡＮｓ）は、移動体ネットワーク技術が適用可能ないくつかの利用例である。移動体無線ネットワークは、複数の移動体ネットワークノード（ＭＮＮs）と複数の移動体ルータ（ＭＲｓ）からなるクラスタである。移動体ルータは、ＭＮＮとインターネット（あるいは、他のＩＰネットワーク）との間でＩＰトラヒックをルーティングする。移動体ルータは、ＭＮＮのためのアクセスポイントとして機能する。移動体ルータは、別の移動体ネットワークに接続されていても良いし、あるいは、アクセスポイント（ＡＰ）を介して直接にインターネットに接続されていても良い。前者の場合、ネスト状の移動体ネットワークのセットが形成される。ＩＥＴＦ ＲＦＣ ３９６３は、この構造に従ったネットワーク・モビリティ（ＮＥＭＯ）プロトコルを提案する。

ＩＥＴＦ ＲＦＣ２４６１によれば、移動体ルータは、その存在を告知して、自身が移動体ルーティングサービスを提供することを複数のＭＮＮに通知するために、ルーティング通知（ＲＡ）メッセージをブロードキャストする。ＲＡｓは、たとえばユーザによる適切なネットワーク選択を補助するために、オペレータ識別子を含んでいても良い。ＭＮＮが適切な移動体ルータを発見すると、ＭＮＮは移動体ルータに対してアタッチメント交換をトリガーする。

移動体ルータが、インターネットに対するアタッチメント点を変更すると、あるいは、別の移動体ルータにハンドオフされると、ダウンストリームのＭＮＮｓのすべての位置（すなわち、ＩＰアドレス）が変わることは理解されよう。移動体ルータのハンドオフの間およびその後にサービスの連続性を維持するためには、ＭＮＮとの通信セッションに含まれるピア（あるいは対応する）ノードから送信されるデータが、ノードの新しい位置におけるＭＮＮに確実に送信されるようにするために、いくつかのメカニズムが必要とされる。ＮＥＭＯが採用するアプローチは、移動体ルータと、固定ネットワーク内のいくつかのホームルータ（あるいは、"ホーム・エージェント"）との間のトンネルの生成を含む。ピアノードからＭＮＮへのすべてのトラヒック（と、可能ならば逆方向に送信されるトラヒック）は、当該トンネルを解してルーティングされる。移動体ルータがその位置を変更すると、ホームルータへ更新を送信する。ＭＮＮが、アップストリーム移動体ルータへの位置更新シグナリングに関する責任を委譲することも可能かもしれない。しかしながら、キーポイントは、ＭＮＮにより利用されるネットワーク・プレフィックスは、移動体ルータが移動しても変更されないということである。

移動体ルータは、ＭＩＰｖ６仕様に記述されるように、インタフェースのインターネットに対するアタッチメント点の変更を可能とするために、移動体ルータのアップストリームあるいは、"出力（egress）"インタフェースのホーム登録を行う。移動体ルータが複数出力インタフェースを利用する場合、移動体ルータは２つ以上のホーム登録を同時に行うことができる。このことは、ＭＣｏＡ（multiple care-of-addresses）ＩＥＴＦ monami６ワーキンググループ仕様に記述されている。

複数出力インタフェースを有するのとともに、ＭＲは複数ダウンストリームあるいは、入力（ingress）インタフェースを提供してもよい。ＭＲは異なるネットワークプレフィックスを、さまざまな入力インタフェースのそれぞれに割り当てなければならない。これらの複数のネットワークプレフィックスは、通常のMIPｖ６ホーム登録に加えて、ＨＡに登録されていなければならない。ＭＮＮあるいは移動体ルータの入力インタフェースにアタッチされているホストは、選択されたインタフェースにあったプレフィックスを利用してIPｖ６アドレスを構成する。移動体ルータは、すべてのトラヒックを入力インタフェースにアタッチされたＭＮＮから移動体ルータのホームエージェント（ＨＡ）へトンネルする。そして、ＨＡはこのトラヒックをインターネットへ送信する。移動体ルータの入力インタフェースに委譲されたネットワークプレフィックスにアドレスされたすべてのトラヒックは、ＨＡに到達し、ＨＡはトラヒックをインターセプトして、移動体ルータへ転送する。移動体ルータは、それらを順に正しい入力インタフェースへルーティングする。

移動体ルータが２以上のホーム登録を有する（すなわち、複数の出力インタフェースを有する）場合、ＨＡとそれ自体との間にも２以上のルートを有する。ＨＡと移動体ルータとの間の異なるこれらのパスのトラヒック特性は、まったく異なるものとすることができる。しかしながら、移動体ルータの入力インタフェースにアタッチされたＭＮＮは、移動体ルータの出力インタフェースについて、および、これらを介して移動体ルータがどんなサービスを提供できるのかについて何も知らない。さらに、移動体ルータの入力インタフェースにアタッチされたＭＮＮが、送出パケットのルーティングに利用される出力インタフェースの選択に影響を与えるとしても、パケットのＨＡから移動体ルータへのダウンリンクパスにＭＮＮがどの程度の影響を与えるのかを把握するのは簡単ではない。

本発明は、複数の出力インタフェースを有する移動体ルータが、ダウンストリーム移動体ネットワークノードに、移動体ルータのアップストリームインタフェースとその特徴を通知するための方法を提供する。IPｖ６の場合、識別子および特性記述子を含む新ルータ通知（ＲＡ）オプションを利用して通知を行うことができる。移動体ネットワークノードがそのようなＲＡオプションを受信すると、次にホップするルータ、即ち移動体ルータの性能を把握し、それに従ってIPｖ６ヘッダ内にトラヒック・クラス（Traffic Class：ＴＣ）フィールドを設定してもよい。識別子は、整数８ビットの形式を有していてもよく、ＩＰｖ６ヘッダ内のTCフィールドに直接にマッピングできる。これにより、移動体ルータは、送出するパケットを所望のインタフェースを介してルーティングすることができる。ＩＰｖ４の場合、サービス・タイプ（ＴｏＳ）フィールドを、ＴＣフィールドの代わりに採用してもよい。

トラヒック・クラスおよびサービス・タイプの用語は、既存のIPv４やIPｖ６標準との関連で、特定の意味を有する。しかしながら、将来的な標準では異なる用語が採用されるかもしれないことは理解されるであろうし、そのような用語も本発明の範囲に含まれることが意図されている。特に、異なるクラスあるいは特性のパケット同士を識別し、区別することを目的としてインタフェース識別子がフィールドにマッピングされるすべてのケースに本発明が適用されることが意図されている。

本発明の第１の側面によれば、移動体ルータにアタッチされた移動体ネットワーク・ノードのためのトラヒック・ルートを確立する方法が提供され、移動体ルータは、自身が利用可能な複数のアップストリーム・インタフェースを有する。当該方法は、移動体ルータから移動体ネットワーク・ノードへ、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングする、インタフェースの識別子と該インタフェースの特性の識別子とを送信する工程を備える。ＩＰｖ６の場合、識別子が、移動体ルータがブロードキャストするルータ通知メッセージ内に包含されてもよい。移動体ネットワーク・ノードでは、識別されたインタフェースの特性に基づいてインタフェースが選択される。少なくとも所定の送出パケットのトラヒック・クラス又はサービス・タイプのフィールドは、選択されたインタフェースの識別子を含む。移動体ルータでは、トラヒック・クラス又はサービス・タイプのフィールドに含まれる識別子に対応するインタフェースを介し、典型的にはパケットヘッダのトラヒック・クラス値の検出に応じて生成されるルールを利用して、パケットがルーティングされる。

本発明は、移動体ネットワークノードが、移動体ルータで利用されるべき送出インタフェースを選択することを可能とする。この種のメカニズム無しでは、データは当該トラヒックに（ビットレートやコスト等の面で）相応しくないインタフェース上に送出されるかも知れない。

本発明の第２の側面によれば、複数のアップストリーム・インタフェースを提供する手段を有する移動体ルータが提供される。これらは、例えば、ＷＬＡＮインタフェースや３Ｇインタフェースとすることができる。第１の送信器は、移動体ネットワークノードに、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングする、インタフェースの識別子とインタフェースの特性の識別子とを送信するために提供される。受信器は、ダウンストリーム移動体ネットワークノードからパケットを受信する。当該ルータは、少なくとも所定の受信パケット内のトラヒック・クラス又はサービス・タイプのフィールドを、アップストリーム・インタフェースにマッピングする手段と、トラヒック・クラス又はサービス・タイプのフィールドに含まれる識別子に対応するインタフェースを介して、パケットがルーティングされるようにする第２の送信器とを備える。

本発明の第３の側面によれば、移動体ルータから、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングする、該移動体ルータが利用可能なアップストリームインタフェースの識別子と、該インタフェースの特性の識別子とを受信する受信器と、識別されたインタフェースの特性に基づいて、インタフェースを選択する手段と、選択されたインタフェースの識別子を、少なくとも所定の送出パケットのトラヒック・クラス、又は、サービス・タイプのフィールドに包含させる手段とを備える移動体ネットワークノードが提供される。

移動体ルータにアタッチされた移動体ネットワークノードを含む移動無線ネットワークを示す図である。 インタフェース識別子と関連する特性を収容するためのルータ通知メッセージの新しいオプションフィールドの構造を示す図である。 ルート選択メカニズムの全体的な動作を示すフローチャートである。

図１は、移動体ルータ（ＭＲ）２と、ＭＲにアタッチされている１以上の移動体ネットワークノード（ＭＮＮ）とを含む移動体ネットワーク１を示す。図では、単一のＭＮＮ３のみを示している。ＭＲ２には、（それぞれ参照番号４及び５で識別される）無線アクセス・ネットワークＡＮ１及びＡＮ２とそれぞれ関連づけられる２つのアップストリーム又は出力インタフェースが利用可能になることが仮定される。ＡＮ１及びＡＮ２は、ＭＲがインターネット７（或いは、他のＩＰネットワーク）に接続することを許容する。典型的なシナリオでは、ＡＮ１及びＡＮ２はそれぞれＷｉＦｉネットワーク、Ｗｉ−Ｍａｘ、携帯電話網などになり得る。ケースによっては、アクセス・ネットワークが同一アクセス・ネットワーク内で異なるアクセス技術に対応していてもよいし、或いは、異なるリンク品質に対応するが、実際には同一アクセス・ネットワーク内では同一のアクセス技術を利用していてもよい。

ＭＲ２は、出力インタフェースのそれぞれについて、ＭＩＰｖ６の拡張ＭＣｏＡを利用してＣｏＡ（care-of-address）をホームエージェント（ＨＡ）に登録することが要求される。ＨＡはＭＲのホームネットワーク内、典型的には、携帯電話網のオペレータのコアネットワーク内に位置し、そこではＭＲのオペレータが加入者となる。良く知られているように、ＨＡはＭＲと対応するノードとの間で行き来するデータのアンカー点として機能する。各出力インタフェースについてCoAを登録するのと同様に、ＭＲはそのアクセス・ネットワークの機能を把握し、この情報を周期的にブロードキャストするルーティング通知（Routing Advertisement : RA）メッセージに追加する。ＲＡメッセージを受信するＭＮＮは、どの出力インタフェースが送出するトラヒックに好ましいかどうかをＭＲに知らせるために、この情報を利用することができる。ＭＲは、インタフェースと関連するＨＡ内にルールを設定したり、それを変更したりすることができる。ＨＡ内でのルールの利用は、以下で更に説明する。（この構造は、ＭＮＮ自体がモビリティプロトコルを採用し、更なるＨＡをトラヒックパスに追加することを排除するものではない。）

ＩＰｖ６は、ＲＡメッセージが"オプション"フィールドを含んでいてもよいことを規定する（ＲＦＣ２４６１ チャプタ４．２）。この場合、ＭＲは、インタフェースの識別子を含み、当該インタフェースの特徴を記述する１つのＲＡオプションを、各出力インタフェースについて追加する。新しいＲＡオプションの構造は、図２に示す通りである。タイプ及び長さのフィールドは、関連ＲＦＣに記述される通りである。ＩＤフィールドは、アクセス・ネットワーク特性フィールド内で特性が規定されているアクセス・ネットワークを利用する場合にＭＮＮが使用しなければならない識別子を規定する。アクセス・ネットワーク特性フィールドの長さは、長さフィールドから決定することができる。アクセス・ネットワーク特性フィールドは、ＭＮＮが、どの出力インタフェースを送出トラヒック用に使用するかを決定するために利用する情報を搬送する。このフィールドのフォーマットは、必要に応じて設定することができる。

ＩＰｖ６に適用された場合、ＩＤフィールドは、ＩＥＴＦ ＲＦＣ２４６０で規定されるＩＰｖ６ヘッダーのトラヒッククラスフィールドに直接にマッピングされる。これにより、ＭＮＮは、ＩＰｖ６ヘッダを修正するだけで、ＭＲ上の特定の出力インタフェースを利用してルーティングされるべき送出パケットにタグ付けすることができる。この結果、ＭＮＮとＭＲとの間では他のシグナリングが必要とされることはない。もしトラヒッククラスフィールドが既に、いくつかのアッパーレイヤプロトコルにより使用されていた場合は、ＭＮＮはパケットを、例えばリンクローカルアドレスを利用してＭＲへトンネルする。この場合、ＩＤフィールドは、アウターＩＰｖ６ヘッダのトラヒッククラスフィールドに含まれる。

ＭＲは、ソース及び目的地のアドレスをアップストリームインタフェースにマッピングするルールが確立されているかどうかを判定するために、入来パケットを検査する。もし、ルールが確立されておらず、かつ、パケットがトラヒック・クラス・フィールドの値を含む場合、トラヒック・クラス値に対応するインタフェースにソース及び目的地のアドレスをマッピングする新しいルールを、ＭＲは生成する。同一ストリームに属する後続の送出パケットについては、ＭＲはトラヒック・クラス・フィールドを確認する必要がなく、単にソース及び目的地のＩＰアドレスを事前に確立されたルールに適合させて、それに従ってインタフェースを選択すればよい。

ＭＲにおいて確立されたルールを、固定長のタイマーに従って維持することができる。このタイマーは、所定のストリームについてパケットが受信される度にリセットされる。もし、タイマーが切れた場合、関連ルールは削除される。もし、ＭＮＮが同一ストリームについてさらにパケットを続けて送信した場合、ＭＲはトラヒック・クラス値に基づいてルールを再生成しなければならない。全てのパケットにトラヒック・クラス値が含めることで、ＭＮＮが所定のストリームについてアップストリームインタフェースを変更したい場合に、ＭＲがそれを検出することができる。これにより、移動性が向上し、ＭＮＮが新しいＭＲに移動することが可能となる。その一方で、新しいＭＲは適切なルールを確立することができる。

ＭＲの入力インタフェースにアタッチされたＭＮＮに対する入来トラヒックは、ＭＲのホームリンク（ＭＮＮが使用するネットワークプレフィックス）に到達し、ＭＲのＨＡによりインターセプトされるであろう。もしＭＲが２つ以上のＣｏＡを登録していた場合、ＨＡは、このトラヒックをＭＲに転送する場合に２以上の選択の可能性のあるルートを有する。しかしながら、このトラヒックを、ＭＮＮから見える"サービス"が両方向で同一となるように、送出トラヒックが使用したのと同一のルートを介して転送することが一般的には望ましい。どのルートを使用するかを決定するために、ＨＡは、特定のトラヒックフローについてＨＡからＭＲへのトラヒックパスを定義するルール（ルーティングテーブルエントリ、ルール、フロー・ビンディング等）を調査する。

ＨＡとＭＲとの間のパスの１つは、デフォルトパスに特定される。もし、ＭＮＮからの送出トラヒックがデフォルトパスを使用する場合、ＭＲは特定ルールを、このトラヒックについてＨＡで追加する必要はなく、むしろデフォルトルールが適用される。（この場合、"ルール"は、所定の基準を満たすパケット、或いは、そうでないものが、どのようにルーティングされるべきかを定義する。）しかしながら、もしＭＮＮが、デフォルトパス以外のパスをそのトラヒックのために利用すべきであると要求した場合、ＭＲは、（ＭＮＮ宛の）入来トラヒックをこのパス経由でルーティングするためにＨＡに新しいルールを追加しなければならない。よって、ＭＲが送出パケット用のルールを生成するのと同時に、ＭＲは入来パケットをルーティングするための対応ルールをＨＡにインストールする。

新しいルールは、ＨＡとＭＲとの間で交渉されなければならない。ＭＲは新しいルールをＨＡに送信し、ＨＡはこのルールを自身のルールデータベースに追加する。ＨＡはルール受信の確認応答を行い、その受領或いは拒否を示す。新しいルールが追加される前に、ＨＡは、委譲されたプレフィックスに到達する全てのトラヒックは、デフォルトパスを介してＭＲに送信されるべきことを指示するルーティングエントリを保持したであろう。ＭＲが、ＭＮＮのための新しいルールを投入すると、ＭＲルータは、ＨＡへのフローを一意に識別するためにＩＰヘッダ（ソース及び目的地のアドレス等）とアッパーレイヤヘッダ（ＴＣＰ／ＵＤＰポート等）の両方から結合された情報の集合を特定する。入来パケット内の情報がこの情報と一致すると、ＨＡはこのトラヒックをＭＲに特定されたルートを介して転送しなければならない。ここで、選択インタフェースを定義する識別子は、ＭＲがＨＡと通信する必要はない点に注意すべきである。この識別子は、単にＭＮＮとＭＲとの間で使用される。

図３は、上述の実施形態を実現するためのＭＲ及びＭＮＮで採用されるプロセスの流れを説明する図である。

ＭＮＮが非デフォルトルートの利用を要求していることをトラヒック・クラス・フィールドから決定するのにもかかわらず、ＭＲは、ＭＮＮのために新しいルールを設定しないことを当然に選択することができる。その場合、ＭＮＮの入来トラヒックと送出トラヒックは、異なるパスを介してルーティングされるであろう。さらに、もし、ＭＲとＨＡとの間でルールを設定するメカニズムが存在しない場合、入来トラヒックは常にデフォルトパスを介してルーティングされることになろう。

当業者であれば、発明の範囲から逸脱することなく、上述の実施形態に対して様々な修正を行ってもよいことを理解するであろう。特に、本発明は、ＴｏＳ値にマッピングされるインタフェース識別子を有し、選択識別子が送出パケットのＴｏＳフィールド内に包含されるＩＰｖ４に適用されてもよい。上述の実施形態の詳細は、ＨＩＰ、ＭＩＰｖ６、ＭＩＰｖ４、ＤＳＭＩＰｖ６、ＤＳＭＩＰｖ４といったモビリティ・プロトコルでの利用に応じて修正されてもよい。

Claims (18)

1. 移動体ルータにアタッチされた移動体ネットワーク・ノードのためのトラヒック・ルートを確立する方法であって、前記移動体ルータは、自身が利用可能な複数のアップストリーム・インタフェースを有し、前記方法は、
   前記移動体ルータから前記移動体ネットワーク・ノードへ、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングする、前記インタフェースの識別子と該インタフェースの特性の識別子とを送信する工程と、
   識別された前記インタフェースの特性に基づいて、前記移動体ネットワーク・ノードにおいてインタフェースを選択する工程と、
   選択されたインタフェースの前記識別子を、少なくとも所定の送出パケットのトラヒック・クラス又はサービス・タイプのフィールドに含める工程と、
   前記移動体ルータにおいて、前記トラヒック・クラス又はサービス・タイプのフィールドに含まれる前記識別子に対応するインタフェースを介して、パケットがルーティングされるようにする工程と
   を備えることを特徴とする方法。
2. 前記移動体ルータは、前記移動体ルータがそのプレゼンスを通知するためにブロードキャストするビーコン内で前記識別子を送信することを特徴とする請求項１に記載の方法。
3. 前記ビーコンは、ＩＰｖ６ルータ通知メッセージであることを特徴とする請求項２に記載の方法。
4. 各識別子及び関連する特性は、前記ルータ通知メッセージのオプション・フィールド内に含まれることを特徴とする請求項３に記載の方法。
5. 各ルータ通知メッセージは、各インタフェースについてオプション・フィールドを含むことを特徴とする請求項４に記載の方法。
6. 前記パケットヘッダに含まれる前記識別子に対応するインタフェースを介して、パケットがルーティングされるようにする工程は、
   前記移動体ルータにおいて、ダウンストリーム移動体ネットワークノードからパケットを受信する工程と、
   前記パケットヘッダの前記トラヒック・クラス、又は、サービス・タイプのフィールドを識別する工程と、
   前記移動体ルータにおいて、前記トラヒック・クラス、又は、サービス・タイプに対応するインタフェースを介して送出パケットをルーティングするためのルールを確立する工程と、
   前記移動体ネットワークノードから受信したパケットを、前記ルールに従ってルーティングする工程と
   を含むことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記ルールは、パケットのソース及び目的地のアドレスを、前記選択されたインタフェースにマッピングすることを特徴とする請求項６に記載の方法。
8. 前記移動体ルータから前記移動体ルータのホーム・エージェントへ、入来パケットをルーティングするためのルールを送信する工程と、
   前記ルールを前記ホーム・エージェントにおいて適用する工程と
   を備えることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記ルールは、パケットのソース及び目的地のアドレスを前記選択されたインタフェースにマッピングすることを特徴とする請求項８に記載の方法。
10. 前記移動体ネットワーク・ノードは、前記選択されたインタフェースの識別子を、所定のセッションに属する全パケットの前記トラヒック・クラス、又は、サービス・タイプのフィールドに含むことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 移動体ルータであって、
    複数のアップストリーム・インタフェースを提供する手段と、
    移動体ネットワークノードに、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングする、前記インタフェースの識別子と前記インタフェースの特性の識別子とを送信する第１の送信器と、
    ダウンストリーム移動体ネットワークノードからパケットを受信する受信器と、
    少なくとも所定の受信パケット内のトラヒック・クラス又はサービス・タイプのフィールドを、アップストリーム・インタフェースにマッピングする手段と、
    前記トラヒック・クラス又はサービス・タイプのフィールドに含まれる前記識別子に対応するインタフェースを介して、パケットがルーティングされるようにする第２の送信器と
    を備えることを特徴とする移動体ルータ。
12. 前記第１の送信器は、前記識別子をＩＰｖ６ルータ通知メッセージ内で送信することを特徴とする請求項１１に記載の移動体ルータ。
13. 前記第１の送信器は、ルータ通知メッセージの各オプションフィールド内に前記識別子を包含させるように構成されていることを特徴とする請求項１２に記載の移動体ルータ。
14. パケット・セッションのために、ＩＰソース及び目的地のアドレスを選択されたインタフェースへマッピングするルーティング・ルールを確立し、当該ルールに従って送出パケットをルーティングするように構成されたことを特徴とする請求項１０乃至１３のいずれか１項に記載の移動体ルータ。
15. 前記セッションの第１のパケットが前記移動体ルータによって受信されると前記ルールを確立し、前記セッションの後続パケットに当該ルールを適用するように構成されたことを特徴とする請求項１４に記載の移動体ルータ。
16. 対応する送出パケットセッションに利用されたインタフェースと同一のインタフェースを介して入来パケットセッションが前記移動体ルータにルーティングされるようにするために、ホーム・エージェントにルールを通知する手段を備えることを特徴とする請求項１０乃至１５のいずれか１項に記載の移動体ルータ。
17. 移動体ネットワーク・ノードであって、
    移動体ルータから、ＩＰｖ６トラヒック・クラス又はＩＰｖ４サービス・タイプにマッピングする、該移動体ルータが利用可能なアップストリームインタフェースの識別子と、該インタフェースの特性の識別子とを受信する受信器と、
    識別された前記インタフェースの特性に基づいて、インタフェースを選択する手段と、
    前記選択されたインタフェースの識別子を、少なくとも所定の送出パケットの前記トラヒック・クラス、又は、サービス・タイプのフィールドに包含させる手段と
    を備えることを特徴とする移動体ネットワークノード。
18. 前記包含させる手段が、前記選択されたインタフェースの識別子を、所定のセッションに属する全パケットの前記トラヒック・クラス、又は、サービス・タイプのフィールドに包含させることを特徴とする請求項１７に記載の移動体ネットワークノード。

Images