Cisco SCMS SCE Subscriber API プログラミング ガイド Release 3.1
概念および用語
概念および用語
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 946KB) | フィードバック

目次

概念および用語

サブスクライバの特性

サブスクライバ ID

アノニマス サブスクライバ ID

ネットワーク ID

ポリシー プロファイル

クォータ

サブスクライバ統合モデル

プッシュ モデル

プル モデル

ノンブロッキング モデル

通知リスナ

サポート対象トポロジ

マルチスレッドのサポート

自動再接続のサポート

信頼性のサポート

ハイ アベイラビリティのサポート

同期

ヒント

サブスクライバの特性

Service Control Application for Broadband(SCA BB)ソリューションの基本的なエンティティの 1 つがサブスクライバです。サブスクライバは、SCAS BB ソリューションでサービス コンフィギュレーションを個別にモニタ、アカウンティング、および実施できるエンティティです。ここでは、SCA BB のサブスクライバの特性について簡単に説明します。サブスクライバ特性の形式および使用方法に関する詳細は、「API データ型」を参照してください。

「サブスクライバ ID」

「アノニマス サブスクライバ ID」

「ネットワーク ID」

「ポリシー プロファイル」

「クォータ」

サブスクライバ ID

サブスクライバ ID はサブスクライバ固有の ID です。ユーザ名、IMSI、サブスクライバを一意に識別するその他のコードなどが該当します。

アノニマス サブスクライバ ID

プルモデル統合環境で作業する場合は、ポリシー サーバから実際にサブスクライバ ID が受信されるまで、不明なサブスクライバの IP アドレスにはそれぞれ一時的なサブスクライバ ID(アノニマス サブスクライバ ID)が割り当てられます。

プル モデル統合についての詳細は、「サブスクライバ統合モデル」を参照してください。

ネットワーク ID

SCE はネットワーク ID(IP アドレス、IP 範囲、VLAN [仮想 LAN] など)をサブスクライバ エンティティにマッピングして、特定のトラフィック フローとサブスクライバを関連付けます。

ポリシー プロファイル

ポリシー プロファイルには、サブスクライバで実行されるポリシーを定義するために SCA BB ソリューションで使用されるパラメータ セットが含まれています。

クォータ

クォータには、サービス クォータ、またはサブスクライバを使用するために利用可能なクォータのクォータバケット値が含まれています。

サブスクライバ統合モデル

次の用語は、SCE プラットフォームでサポートされている 2 つの動的なサブスクライバ統合モデルを示します。

「プッシュ モデル」

「プル モデル」

プッシュ モデル

プッシュ モデル統合環境では、外部サーバから SCE プラットフォームにサブスクライバが導入(プッシュ)されます。この処理が実行されるのは、新しいサブスクライバがネットワークにログインした場合、または外部サーバがすべてのサブスクライバを認識していて、サブスクライバの接続時にサブスクライバを SCE ボックスに導入する場合です。

図2-1 プッシュ モデルの概略図

 

プル モデル

プル モデル統合環境では、SCE プラットフォームは不明なサブスクライバ(アノニマス サブスクライバ)のトラフィックを検出すると、外部エンティティに対してサブスクライバ データを要求します。外部エンティティは要求されたサブスクライバ情報を取得して、SCE プラットフォームに戻します。

図2-2 プル モデルの概略図

 

ノンブロッキング モデル

SCE Subscriber API はノンブロッキング モデルを使用して実装されます。ノンブロッキング メソッドは、サブスクライバ プロビジョニング操作が完了する前であっても、即座に戻されます。ノンブロッキング モデル メソッドは、入出力が含まれていて時間のかかる操作の場合に有利です。別のスレッドで操作を実行すれば、呼び出し側はほかのタスクを続行できるので、システム全体のパフォーマンスが向上します。

操作結果は、Observer オブジェクト(リスナ)に戻るか、またはまったく戻りません。

API は操作結果ハンドラを使用して、操作結果を取得できます( 結果処理を参照)。

次の図に、サブスクライバ プロビジョニング操作中のノンブロッキング モデル メソッドを示します。

図2-3 ノンブロッキング モデル

 

操作結果は、操作結果エラーのロギングや、操作で使用したパラメータの検査に使用できます。

通知リスナ

API には、SCE プラットフォームに特定のイベントが発生した場合に、通知を受信する機能があります。API は関連エンティティ(リスナ)のコールバック メソッドをアクティブにして、SCE から受信した通知を目的のリスナにディスパッチします。通知グループごとに定義できるリスナが 1 つ のみの場合、通知は複数の論理グループに分割されます。

図2-4 通知リスナ

 

特定の通知を受信するには、必要なコールバック関数を実装する API にリスナを登録する必要があります。リスナが登録されると、API は要求された通知をリスナにディスパッチできます。各リスナが次の 3 つのタイプの通知に登録されている場合、SCMS SCE Subscriber API はこれらのタイプの通知を送信します。

ログインプル通知

ログアウト通知

クォータ通知

リスナの通知についての詳細は、「API イベント」を参照してください。

サポート対象トポロジ

SCMS SCE Subscriber API では、次のトポロジを使用することを推奨します。

サブスクライバ プロビジョニング プロセスの要素をすべて実行するポリシー サーバ(または2 ノード クラスタ)× 1

図2-5 サポート対象のトポロジ--ポリシー サーバ× 1

 

ポリシー サーバ× 3(または 2 ノード クラスタ× 3) ― サーバごとにサブスクライバ プロビジョニング プロセスの異なる要素を実行します。

図2-6 サポート対象のトポロジ--ポリシー サーバ× 3

 

ポリシー サーバ× 2(または 2 ノード クラスタ× 2) ― 1 つのサーバでサブスクライバ プロビジョニング プロセスの要素を 2 つ実行し、もう 1 つのサーバでプロセスの要素を 1 つのみ実行します(任意の組み合わせが可能)。次に例を示します。

図2-7 サポート対象のトポロジ--ポリシー サーバ× 2

 

ネットワーク ID とサブスクライバ ID をマッピングする DHCP Lease Query LEG と、1 台以上のポリシー サーバ(ポリシー サーバを 3 台配置した上図を参照)。次の図に、DHCP Lease Query LEG を示します。

図2-8 サポート対象のトポロジ-- DHCP Lease Query LEG

 

ネットワーク ID とサブスクライバ ID をマッピングする SCMS SM と、1 台以上のポリシー サーバ。ポリシー サーバ数は、SM をネットワーク ID だけでなくポリシー プロファイル プロビジョニングにも使用するかどうかによって異なります。

図2-9 サポート対象のトポロジ-- SM

 


) API によってトポロジの使用が制限されることはありません。ただし、SCE プラットフォームでは、サブスクライバ プロビジョニングを実行するエントリ(ポリシー サーバ)の一部が関連付けられないことがあります。したがって、同じプロビジョニング目的にポリシー サーバを複数使用する場合は、特に注意する必要があります。そうししないと、SCE プラットフォームは、同じサブスクライバ プロビジョニング プロセスを実行する 2 台のポリシー サーバから、同じサブスクライバに対して異なる情報を受信することがあります。この場合、少なくとも 1 台のポリシー サーバとの同期が失われることがあります。たとえば、同じサブスクライバに 2 台のポリシー サーバを使用して、サブスクライバ ID/ネットワーク ID の関連付けを行っている場合、SCE は、このサブスクライバに最後の更新を実行したポリシー サーバと常に同期します。


マルチスレッドのサポート

API では、メソッドを同時に呼び出すスレッドの数に制限がありません(ただし、使用可能メモリによってスレッド数は制限されます)。


) マルチスレッド シナリオでは、呼び出しの順番が保証されます。API は、呼び出された順番と同じ順序で操作を実行します。


自動再接続のサポート

接続障害が発生した場合、API は SCE との自動再接続をサポートします。このオプションがアクティブな場合、API は SCE との接続が切断された時期を判別できます。接続が切断されると、API は再接続タスクをアクティブにして、再接続に成功するまで、設定可能なインターバル内で SCE との再接続を試みます。

信頼性のサポート

SCMS SCE Subscriber API は 信頼できる API として実装されます。この API を使用すると、SCE に対する要求や SCE からの通知が失われなくなります。また、SCE に送信されたすべての API 要求が内部ストレージに保存されます。要求が処理された SCE から確認応答を受信した場合のみ、要求は コミットした とみなされ、API は内部ストレージから要求を削除できます。API と SCE 間の接続に障害が発生すると、API は SCE との接続が再確立されるまで、内部ストレージにすべての要求を蓄積します。再接続されると、API は コミットされていない すべての要求を SCE に再送信して、要求が失われないようにします。


) 要求を再送信する順序は保証されています。API は、呼び出された順番と同じ順序で要求を再送信します。


ハイ アベイラビリティのサポート

API はハイ アベイラビリティをサポートしています。ポリシー サーバのハイ アベイラビリティ方式には、2 ノード クラスタ タイプが使用されます。この場合、同時にアクティブにできるサーバは 1 台のみです。別のサーバ(スタンバイ)は、SCE に接続されません。詳細は、「ハイ アベイラビリティの実装」を参照してください。

同期

SCE が内部パラメータを処理しているサブスクライバに関して、SCE およびポリシー サーバを常に同期させる必要があります。そうしないと、SCE は一方のサブスクライバのトラフィックを別のサブスクライバのトラフィックと混同したり、SCE に到達しなかったポリシーが変更されて、サブスクライバの SLA(サービス レベル契約)が実行されなくなることがあります。詳細は、「SCE-API の同期」を参照してください。

ヒント

API とアプリケーションを統合するコードを実装する場合は、次のヒントを考慮する必要があります。

SCE に接続したら、API を複数回使用して、API と SCE との接続を維持します。接続は適切なタイミングで確立され、これによって、SCE 側と API クライアント側でリソースが割り当てられます。

API 接続はスレッド間で共有されます。ポリシー サーバごとに接続を 1 つ確立することを推奨します。複数の接続を確立する場合は、SCE 側およびクライアント側でより多くのリソースが必要となります。

API への呼び出しを同期しないでください。API への呼び出しはクライアントによって自動的に同期されます。

ポリシー サーバ アプリケーションにログオン処理がバースト的に発生した場合は、これらのバーストを保持できるように、内部バッファ サイズを拡張します(ノンブロッキング方式)。

統合中に問題が発生した場合は、「SCE ロギング」および「API クライアント ロギング」に記載されているロギング機能を使用して、SCE クライアント ログ内の API 操作を表示し、トラブルシューティングを実行してください。

ポリシー サーバ アプリケーションで処理の戻り値を記録または出力する場合は、デバッグ モードを使用します。

SCE との接続の復元力を向上させるには、自動再接続機能を使用します。