この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco Mobile Wireless Home Agent が IP レジストレーションを終了し、この機能を実行するよう Home Agent(HA)を設定する方法について説明します。
基本的なモバイル IP リソースの失効は、モビリティ エージェント(モバイル IP サービスをモバイル ノードに提供する)が他のモビリティ エージェントに、管理上の理由または MIP ハンドオフによってレジストレーションの終了を通知できる方式を定義する IS-835-C イニシアチブです。
この機能は、Cisco MobileIP Bind Update 機能と類似しています。モバイルが接続ポイント(FA)を変更する、または管理上、セッションを終了する必要がある場合、HA は Registration Revocation メッセージを古い FA に送信します。古い FA はセッションを切断し、Registration Revocation ACK メッセージを HA に送信します。さらに、PDSN/FA が管理上、セッションを終了する必要がある場合、FA は Registration Revocation メッセージを HA に送信します。HA はモバイルのバインディングを削除し、Registration Revocation ACK を FA に送信します。
モバイル IPv4 のレジストレーション失効をサポートするよう設定された HA には、有効なレジストレーション失効拡張を含んだ PDSN から関連付けられた MIP RRQ に対するすべての MIP RRP の失効サポート拡張が含まれます。HA が失効サポート拡張を受信し、以後の失効サポート拡張に応答したレジストレーションは、HA によって取り消し可能とみなされます。
次のコール フローでは、モバイル IP リソース失効(レジストレーション フェーズ)を示します。
ステップ 1 MS はコールを発信し、PPP セッションがアップします。
ステップ 2 MIPv4 レジストレーション失効サポートをアドバタイズするよう PDSN/FA は設定されました。PDSN/FA は MIPv4 レジストレーション失効サポート ビット「X」セットのあるアドバタイズメントを送信します。
ステップ 3 PDSN/FA は MN から MIP RRQ を受信します。これには、FA-CHAP 時の access-request で 2 に設定された STC アトリビュートが含まれます。RRQ を HA を転送すると、失効サポート拡張が MHAE のあとに追加されます。失効サポート拡張の I-bit は 1 に設定され、必要な場合はいつでも MS がバインディングの失効に関する明示的な通知を受け取ったことを示します。
ステップ 4 失効拡張を含んだ MIP RRQ を受信すると、HA は失効サポート拡張を含み、I-bit を MIP RRQ で受信した値に設定する MIP RRP を戻します。HA-CHAP(MN-AAA 認証)の場合、STC アトリビュート(値 2)は、AAA に送信された access-request に含まれます。
ステップ 5 PDSN は失効サポート拡張を含んだ MIP RRP を受信します。データ フローは取り消し可能とみなされます。
次のコール フローでは、モバイル IP リソース失効(HA が開始)を示します。
ステップ 1 モバイルは、PDSN/FA(1)のあるモバイル IP データ セッションを開始します。
ステップ 2 PDSN/FA(1)は、レジストレーション失効サポート拡張をモバイル レジストレーション要求に追加し、これを HA に転送します。
ステップ 3 応答として、HA はレジストレーション失効サポート拡張をレジストレーション応答に追加し、これを PDSN/FA(1)に送信します。
ステップ 4 PDSN/PDSN ハンドオフが発生し、モバイルは PDSN/FA(2)のあるモバイル IP データ セッションを再開します。
ステップ 5 PDSN/FA(2)はレジストレーション要求を HA に送信します。
ステップ 6 HA はレジストレーション応答を PDSN/FA(2)に送信します。
ステップ 7 HA は Mobile IP Resource Revocation メッセージを PDSN/FA(1)に送信します。
ステップ 8 PDSN/FA(1)はモバイル IP リソース失効 ACK を HA に送信し、モバイルのモバイル IP データ セッションを終了します。
次のコール フローでは、モバイル IP リソース失効(FA が失効を開始)を示します。
ステップ 1 モバイルは、PDSN/FA のあるモバイル IP データ セッションを開始します。
ステップ 2 PDSN/FA は、レジストレーション失効サポート拡張をモバイル レジストレーション要求に追加し、これを HA に転送します。
ステップ 3 応答として、HA はレジストレーション失効サポート拡張をレジストレーション応答に追加し、これを PDSN/FA に送信します。
ステップ 4 PDSN/FA では一部のイベントが発生し、PDSN/FA はセッションを終了するよう決定します。
ステップ 5 PDSN/FA は Mobile IP Resource Revocation メッセージを HA に送信します。
ステップ 6 HA はモバイル IP リソース失効 ACK を PDSN/FA に送信します。HA はバインディングをクリアし、PDSN/FA はセッションをクリアします。
レジストレーション失効フェーズ中、モバイル ノード(MN)に複数のモバイル IP フローがある場合に、I(Inform)ビットは、MN に対して失効したデータ サービスを通知します。レジストレーション フェーズ中、RRQ/RRP の失効サポート拡張のモビリティ エージェントによってこのビットが 1 に設定されている場合、エージェントが Revocation メッセージの「I」ビットの使用をサポートすることを示します。
現在の実装では、MobileIP RRQ が失効サポート拡張に設定された I ビットで受信された場合、HA も I-bit を 1 に設定します。I-bit は失効フェーズ中も使用できます。HA が失効を開始した(I ビットはネゴシエートされた)ときに、バインディングが管理上、解除された場合、HA は I ビットを Revocation メッセージで 1 に設定します。PDSN 間ハンドオフが HA によって検出された場合、I ビットを 0 に設定します。失効が PDSN によって開始され、Revocation メッセージで I-bit が 1 に設定されている場合、HA も Revocation ACK メッセージで I-bit を 1 に設定します。
HA で MIPv4 レジストレーション失効機能をイネーブルにするには、グローバル コンフィギュレーション モードで次の手順を実行します。
|
|
|
---|---|---|
Router(config)# ip mobile home-agent revocation timeout 5 retransmit 6 |
次に、 ip mobile home-agent revocation コマンドの例を示します。
次のリストでは、現在のリリースのモバイル IPv4 リソース失効機能の制約事項を特定します。
• HA-CHAP(MN-AAA 認証)時に access-accept で受信した STC アトリビュートは無視され、HA の機能設定が優先されます。
• Revocation メッセージ、Revocation ACK メッセージ、失効サポート拡張(FHAE または IPSec によって保護されない)は廃棄されませんが、処理されます。HA に FA-HA セキュリティ アソシエーションを設定する、または FA と HA の間に IPSec トンネルが存在することを推奨します。
• リリース失効とバインド アップデートを同時にイネーブルにすることはできません。いずれか 1 つを選択しなければなりません。
• 複数のフローが同じ NAI に確立されている場合、異なる IP アドレスが各フローに割り当てられます。したがって、この機能は同じ IP アドレスに対する複数のフローを維持するので、同時バインディングは必要ありません。
RADIUS 切断(または Packet of Disconnect[POD; パケット オブ ディスコネクト])は、RADIUS サーバが Radius Disconnect メッセージを HA に送信してリソースを解放できるメカニズムです。リソースは管理上の目的で解放され、主に HA のモバイル IP バインディングです。
Cisco HA での RADIUS 切断のサポートは RFC 3576 に準拠します。HA はリソース管理機能を Access Request メッセージでホーム AAA サーバに送信します。このメッセージは、3GPP2 ベンダー固有の Session Termination Capability(STC)VSA を含めることで、認証/許可手順用に送信されます。STC VSA で送信された値は設定から取得されます。radius-server attribute 32 include-in-access-req format コマンドの設定時、HA には、Access Request の Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)を含んだ NAS-Identifier アトリビュートがあります。
Disconnect Request が HA で受信されると、次のイベントが発生します。
ステップ 1 ユーザ名に対応するユーザ セッションを検出します(NAI)。
ステップ 2 Framed-IP-Address アトリビュートが Disconnect Request で受信された場合、アドレスに対応するバインディングを終了します。
ステップ 3 Framed-IP-Address が Disconnect Request で受信されない場合、ユーザのすべてのバインディングを終了します(NAI)。
クライアントと関連したキーに RADIUS 切断を設定するため、次の手順を実行します。
次のリストには、RADIUS 切断機能の制約事項が含まれます。
現在の HA 冗長性の実装では、アクティブ スタンバイ モードのアクティブ HA(またはピアツーピア モードのピア)で削除されるバインディングは、Revocation メッセージまたは RADIUS Disconnect メッセージの受信により、スタンバイ HA またはピア HA に同期化されます。また、Revocation および Radius Disconnect の追加の拡張およびアトリビュートはスタンバイにリレーされます。Registration Revocation および Radius Disconnect(clear ip mobile binding コマンドを使用)は、HA 冗長性でサポートされます。次のリストでは、このサポートの利点を示します。
• トリガー(たとえば、Revocation メッセージまたは RADIUS Disconnect メッセージの受信)によって削除されるアクティブ HA 上のバインディングは、スタンバイ HA に同期化されます。
• 設定解除するコマンド(たとえば、ip mobile host など)によって削除されるバインディングは同期化されません。
• スタンバイ HA 上で削除されるバインディングは、アクティブ スタンバイ モードの場合にはアクティブに同期化されません。
• Revocation および Radius Disconnect の追加の拡張(失効サポート拡張)やアトリビュート(STC アトリビュート)はスタンバイ HA にリレーされます。
• トリガー(たとえば、Revocation メッセージまたは RADIUS Disconnect メッセージの受信)によっていずれかのピアで削除されるバインディングは、他のピアに同期化されます。
• 設定解除するコマンド(たとえば、ip mobile host など)によって削除されるバインディングは同期化されません。
• Revocation および Radius Disconnect の追加の拡張(失効サポート拡張)やアトリビュート(STC アトリビュート)はピア HA にリレーされます。
次のコール フローでは、モバイル IP フローを起動し、情報をスタンバイ HA に同期化するのに使用される、さまざまなネットワーク エンティティの間のシーケンスおよびメッセージ交換を示します。
1. MS はコールを発信し、PPP セッションがアップします。
2. PDSN は MN から MIP RRQ を受信し、FA-CHAP によって MN を認証します。適切な値(2 または 3)を持った STC VSA は、AAA に送信された Access-request メッセージに含まれます。認証が成功すると、PDSN は RRQ を HA に転送し、失効サポート拡張を MHAE のあとに含めます。
3. 失効拡張を含んだ MIP RRQ を受信すると、HA では PDSN に送信された MIP RRP に失効サポート拡張が含まれます。MS を認証する HA-CHAP 時、適切な値(2 または 3)を持った STC VSA は、AAA に送信された Access-request メッセージに含まれます。HA でのバインディングは現在、取り消し可能であるとみなされます。
4. PDSN は失効拡張を含んだ MIP RRP を受信します。MIP RRP に失効拡張が含まれているので、PDSN でのバインディングは取り消し可能です。
5. HA は冗長モードで設定されているので、Bind Update メッセージは追加情報(失効サポート拡張および STC NVSE)とともにスタンバイに送信されます。
6. スタンバイ HA は Bind Update メッセージで受信した情報を使用してバインディングを再生成し、スタンバイでバインディングを正常に作成したときのコード「accept」とともに Bind Update ACK メッセージを戻します。
このサポートの一部として 2 つの新しいメッセージ、「Bind Delete Request」と「Bind Delete ACK」が追加されました。これらのメッセージは、バインディングが削除されたときに冗長 HA の間で交換されます。次のコール フローでは、Revocation メッセージの受信によりバインディングがアクティブ HA で削除され、バインディングの削除がスタンバイ HA に同期化されるときを示します。
1. MS はコールを発信し、PPP セッションがアップします。モバイル IP フローは、レジストレーション失効機能がイネーブルとなりネゴシエートされたアクティブ HA でセットアップされます。同様にスタンバイ HA に同期化されます。
2. ユーザは administrative clear コマンドを発行し、PDSN は Revocation メッセージをアクティブ HA に送信し、ビジター エントリを削除し、関連付けられたリソースをクリアします。
3. MIP Revocation メッセージを受信すると、アクティブ HA は削除するバインディングを特定します。バインディングを特定すると、Bind Delete Request メッセージがスタンバイ HA に送信されます。
4. Bind Delete Request が送信されると、アクティブ HA は、着信した Revocation メッセージのバインディングに関連付けられたリソースを消去し、MIP Revocation ACK メッセージを PDSN に送信します。
5. Bind Delete Request メッセージを受信すると、スタンバイ HA は削除するバインディングを特定し、コード「accept」とともに Bind Delete ACK メッセージを戻します。
6. Bind Delete ACK メッセージが設定された時間内にアクティブ HA で受信されないと、Bind Delete Request メッセージは再送信されます。このプロセスは、最大再送信カウントの間繰り返されます。
バインディングの同期化中、拡張(失効サポート拡張)と、Revocation および RADIUS Disconnect のアトリビュート(STC アトリビュート)がアクティブ HA からスタンバイ HA へ同期化されます。アクティブ HA がダウンし、スタンバイがアクティブになるシナリオでは、現在のアクティブ HA は RADIUS Disconnect メッセージの受信時にバインディングを削除できます。失効の場合、現在のアクティブ HA のバインディングは取り消し可能です。HA は現在、Revocation メッセージを送受信できます。
3GPP2 環境では、サブスクライバが自分のサービス プロバイダーのネットワークと他のパートナーのサービス プロバイダーのネットワークの間でローミングすると、PDSN ゲートウェイは Resource Revocation メッセージを HA に送信してサブスクライバを削除します。これによりタイミング問題が発生します。したがって、Selective FA Revocation はこれらの「remove subscriber」要求を選択して無視します。失効は FA に基づいて実行されます。所定の HA は、「remove subscriber」メッセージを無視する FA のリストをスタティックに設定します。
次に、Selective FA Revocation の詳細なコール フローを示します。
1. デュアル 1x/DO ハンドセットは RF に登録し、DO でデータ コールを確立します。音声コールとは異なり、RF ネットワークは EVDO ネットワークを認識していないので(標準により)、このデータ コールを VLR に登録しません。
2. ハンドセットは休止します(Samsung で 35 秒、RIM で 30 秒、Sierra で 40 秒)。
3. ハンドセットは DO カバレッジ エリアから 1x カバレッジ エリアに移行します。この移行の一部として、ハンドセットは、MTX 経由でアクティブ データ セッションがあることを 1x RF に通知しますが、休止している(DRS ビットは 0 に設定されている)ので送信するデータはありません。新しいセッションが MTX PCF 経由で PDSN に確立されます。
4. ステップ 3 のイベントに基づいて、1x PCF は、ハンドセットで述べたこのアクティブ データ セッションの VLR をクエリーします。ステップ 1 により、このようなセッションは検出できません。
5. ステップ 3 のイベントの一部として、PCF は現在、0 に設定された Mobility Event Indicator(MEI)で PDSN メッセージを(OpenRP インターフェイス経由で)送信します。PDSN に対して、このイベントは、コール セットアップの一部としてまったく新しいセッション用であり、次のチェックを実行します。
–MEI=0、および IMSI が既存のセッションに現在割り当てられていない新しい IMSI である場合、処理を進め、新しいセッションを確立します。
–MEI=0、および IMSI が現在、セッションに割り当てられている場合、このセッションを古いものとみなし、セッションを切断します。
6. MEI=0、および IMSI が現在セッションに割り当てられているので(これは Hybrid PDSN であり、DO と 1X セッション両方を同時に処理するので)、PDSN は PPP TermReq をハンドセットし送信し、Resource Revocation を HA に送信します。
7. モバイル ノードは休止しており、TermReq を検出しません。MTX RF はしばらくメッセージをバッファリングします。
8. モバイル ノードはアクティブになりますが送信するデータはありません。これは、まだ有効なモバイル IP セッションがあるかのように機能し、TermReq(バッファリングされた)メッセージおよび ACK メッセージを受信してからただちに RF セットアップ/RRQ を受信します。RRQ には、ハンドセットに割り当てられた IP アドレスや HA の IP アドレスなど、事前に割り当てられた値が含まれます。
9. PDSN はこれを新しいセッション(MEI=0、および IMSI は現在、セッションに割り当てられていません)とみなし、RRQ を HA に送信します。
10. 現在、HA は既存のバインディングがなく(ステップ 6 で失効)、RRQ にパラメータがある RRQ を検出し、これをスタティックに割り当てられた MN とみなします。
11. HA は Code-139(管理上の禁止)を MN に戻します。
Selectable FA Revocation ならば、Hybrid PDSN/FA は上記の条件を通り、Revocation を HA に送信します。ただし、HA が Revocation を無視すると、RR 応答を PDSN に送信します。
この結果、MN と HA にはまだバインディング ステートがありますが、PDSN/FA には PPP セッション/ビジター テーブル エントリはありません。実際にモバイルはアクティブになり、Data Ready to Send があります。これには 1x RF チャネル DRS=1 が含まれます。このシナリオでは、VLR はクエリーされず、PDSN への OpenRP メッセージでは MEI が 1 に設定されています。MEI 値に関係なく、PDSN は PPP を開始し、事前に割り当てられたホーム アドレスのある RRQ を送信します。この場合、HA は Re-registration を受信します。
Selective FA Revocation を設定するには、次の手順を実行します。
|
|
---|---|
Router(config)# ip mobile home-agent revocation ignore fa acl |
HA をイネーブルにして、Revocation ACK を PDSN/FA に送信しますが、バインディングは削除しません。fa-acl は ACK 番号 1-99 または名前です。 |
次に、ip mobile home-agent revocation ignore コマンドの例を示します。
standard access-list 番号または standard access-list 名を指定することで、FA からの失効を無視できます。
COA 5.1.1.4 からの要求を無視するよう access-list 名を設定
COA 5.1.1.5 からの要求を無視するよう access-list 番号を設定
FA 5.1.1.4 からの要求を選択して、無視するよう access-list 名を設定。これは、上記で作成した ACK と ip mobile home-agent revocation ignore コマンドを関連付けます。
FA 5.1.1.5 からの要求を選択して、無視するよう access-list 番号を設定
(注) ip mobile home-agent revocation ignore は現在、1300 ~ 1999 (標準 IP access-list 番号[拡張範囲])の使用はサポートしていません。