Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

リモート デバイス サービス マネージャー(RDSM)の概要

サービス プロバイダの使用事例では、加入者サービスはブロードバンド ネットワーク ゲートウェイ(BNG)と 1 つ以上のアクセス ノードの両方にまたがっています。運用サポート システム/ビジネス サポート システム(OSS/BSS)の統合を必要とするネットワーク要素の数を最小限に抑えるために、BNG およびダウンストリーム アクセス ノードはバックオフィス システムを単一の論理システムとして表します。サービス プロバイダのバックオフィス システムは、BNG とそのダウンストリーム アクセス ノード上の加入者サービスの外部構成と管理、認証、プロビジョニングを提供します。PCRFやTACACS+アプリケーションを含むバックオフィスシステムでは、BNGとそのノードは単一のアドレス可能なネットワーク要素を表しています。BNG プロキシは、ダウンストリーム デバイスのサービス プロビジョニングとデプロビジョニングを行います。

Junos OS リリース 18.3R1 以降、BNG として使用される MX シリーズ ルーターは、リモート デバイス サービス マネージャー(RDmd デーモンを使用する RDSM)によってリモートデバイス サービスをサポートします。

図 1 は、RDSM を使用した MX シリーズ BNG のトポロジーの例を示しています。BNGは、加入者のアクセス回線ごとにパッシブ光ネットワーク(PON)アクセスを終端する従来の役割に加え、加入者サービスをプロビジョニングするためのダウンストリームのリモートデバイスとして機能するOLTに接続されています。OLTはBNGの論理的拡張であり、BNGとそのダウンストリームアクセスノードは、単一のアドレス可能なネットワーク要素としてバックオフィスシステムに提示されます。BNGは、TCPポート転送を使用して、リモートデバイスとバックオフィスシステム間の通信を仲介します。リモートデバイス管理アクセス用のTCPポート転送の詳細については、 リモートデバイス管理 用のTCPポート転送を参照してください。

図 1:リモート デバイス管理 Topology for Remote Device Managementのトポロジー

バックオフィスの管理およびプロビジョニングシステムでは、加入者ネゴシエーションが開始される前のリモートデバイスの基本設定、新規加入者のレイヤー2データパスの設定、リモートデバイスのステータスの表示、リモートデバイスのトラブルシューティングなどのタスクに、SSH経由のNETCONF XMLプロトコルを使用します。BNG は、管理システムからのリクエストをリモート デバイスに逆多重化します。1 台のリモート デバイスに対して複数の NETCONF セッションを使用できます。

このサンプル トポロジーでは、システムには管理プラットフォーム、PCRF、TACACS+ サーバー、IPFIX コレクターが含まれています。

  • PCRFは、MX BNG上でローカルにプロビジョニングされた加入者サービスをローカルおよびOLT上でリモートでソースします。

  • TACACS+サーバーは、リモートデバイスへのアクセスの認証と検証、システムアカウンティングの実行、オペレーターアクセスの制御に使用されます。リモートデバイスは、外部管理プラットフォームまたはステーションからNETCONFプロトコル設定に応答して、TACACs+ TCPセッションを動的に開始します。BNGは、リモートデバイスからTACACS+サーバーにリクエストを多重化します。

    バックオフィスシステムからのリモートデバイスアクセスの場合、サーバーは以下の条件でTACACS+認証を開始します。

    • BNGは、リモートデバイスのサービス設定を開始します。リモートサービスのプロビジョニングまたはデプロビジョニングにBNGが使用するNETCONF TCPソケットを開くと、TACACS+サーバーはセッションを認証します。認証後、サービスアクションに使用される各リモートプロシージャコール(RPC)の認証または許可なしにセッションが維持されます。

    • 外部管理ステーションは、リモート デバイスの設定や、監視(show コマンド)やトラブルシューティングのために外部管理ステーションにアクセスするために使用されます。

  • IPFIX コレクターは、システムおよび接続レベルの統計やその他の情報を含むレコードを MX BNG から受信します。MX BNG は、OLTs(IPFIX エクスポート装置)と外部 IPFIX コレクター間の IPFIX 媒体として動作します。ダウンストリームデバイスのBNGプロキシ。リモート・デバイスからデータを受信する IPFIX コレクターとして機能し、IPFIX エクスポート機能として単一の TCP または TLS セッションを介してデータ・アップストリームをコレクターに送信します。BNG を IPFIX メディエーターとして使用する方法の詳細については、 BNG に関する IPFIX 仲介を参照してください。

リモートサービス

MX BNGは、ローカルおよびリモートのすべての加入者サービスに対する外部権限への単一管理ポイントを表しています。また、リモート・サービスは、BNG 上のローカル・サービスと同じ方法で外部権限によって参照される、ローカルに構成された動的サービス・プロファイルで表されます。その結果、すべてのサービス・アクションに対して外部権限とBNGの間に一貫したインターフェースが存在します。NETCONF XML 管理プロトコルは、リモート サービスのプロビジョニングとデプロビジョニングに使用されます。

ローカル加入者サービスは、加入者固有のポリシーを満たすために、引数ゼロ以上の動的サービスプロファイルによって定義されます。PCRF などの外部権限は通常、参照モデルを使用してサービスを提供します。PCRF 課金ルールは、動的サービス プロファイルの名前と、加入者のネゴシエーション時にサービス プロビジョニング(アクティブ化)、または加入者のアクティブ後の更新として適用される引数値を指定します。サービスは、解析、解釈、適用するための RDSM XML 辞書によってリモート デバイスに提供され、外部権限からの課金ルールまたはサービスを最小限の処理でリモート デバイスに不透明に渡すことができます。リモート サービス プロファイルには、サービス パラメーターを定義するための 1 つ以上の変数が含まれている場合があります。

ただし、リモートサービスは、参照ではない方法で適用することもできます。この場合には,外部権限はリモート・サービスをローカル・サービスの場合と同様に参照的に指定します。リモート サービス プロファイルには、サービス パラメーターを定義する 1 つ以上の変数が含まれています。その後、RDSM はリモート デバイスに割り当てられたデータ辞書を使用して、そのデバイスでサービスを構成します。デバイスの RDSM 辞書の内容は、サービス プロバイダが参照メソッドと呼び出し方式のどちらを使用するかによって異なります。

リモート動的サービスプロファイルは、多数の設定スタンザを含むローカルサービスプロファイルに比べて非常に軽量です。リモート動的サービスプロファイルには、2つのものしかありません。

  • 動的プロファイル タイプが . remote-device-serviceを指定する必要があります。この設定により、プロファイルがローカル サービス プロファイルとして使用されるのを防ぎます。つまり、動的サービス プロファイルをデュアルパーベース(ローカルとリモートの両方)に設定することはできません。

  • リモート・サービス・プロファイルは、オプションで変数スタンザを含め、引数値をリモート・デバイスに渡すことができます。この変数スタンザは、参照メソッドまたは非参照メソッドのいずれかに使用できます。

追加の設定はコミットチェックに失敗します。リモート サービス プロファイルは非常に固有であるため、各リモート サービスに対して専用のサービス プロファイルが必要です。外部権限の場合、これは、各リモート サービスに個別の PCRF 課金ルールが必要であることを意味します。

RDSM プロビジョニングとデプロビジョニングのプロセス フロー

加入者サービスは、以下のようにプロビジョニングおよびデプロビジョニングされます。

  • 加入者ログイン時にプロビジョニングされます。Gx CCR-I/CCR-A メッセージ交換の開始に応じて、サービスを PCRF から供給できます。

  • 加入者のログアウト時にプロビジョニングが解除されます。

  • PCRF からの Gx RAR メッセージなど、外部機関に応答して、アクティブな加入者セッション用にプロビジョニングまたはデプロビジョニングされます。

図 2 は、アップストリームのBW サービス プロファイルをインスタンス化して、RDSM が 3 つの対象リモート デバイス(OLT1、OLT2、OLT3)でサービスを正常にプロビジョニングした場合のプロセス フローを示しています。

図 2:リモート デバイスでの RDSM サービス プロビジョニング:加入者ネゴシエーション フロー RDSM Service Provisioning on a Remote Device: Successful Subscriber Negotiation Flowの成功
  1. サービス プロビジョニングは、加入者がログインし、認証が RDSM に要求を送信し、ネゴシエーション中に対象のリモート デバイスでリモート サービス プロファイルをインスタンス化するときに開始されます。

  2. RDSM は、サービスのプロビジョニングの対象となるリモート デバイスのリストを確立します。

    • デバイスのレイヤー 2 アクセス ドメインは、加入者の場所と一致する必要があります。アクセス ドメインは、VLAN 範囲または個別の VLAN ID の構成済みリストで構成されています。加入者の外部 VLAN タグは、このリストに含まれている必要があります。

    • デバイスへのNETCONF TCP接続が稼働している必要があります。ダウン状態のデバイスはプロビジョニングの対象にはなりませんが、後でアップ状態に移行した場合、デバイスを再設定できます。

  3. RDSM は、リモート サービス プロファイルのインスタンス化要求に応答する前に、初期検証を実行します。

    • 検証に合格すると、RDSM は ACK 応答を保留中のサービス プロファイルのインスタンス化を認証に送信します。現在、サービス プロビジョニングは保留されています。

    • 検証に失敗した場合、RDSM は認証に対する NACK 応答を返し、サービスのプロビジョニングを放棄します。

    RDSM が実行する検証チェックは、通常、アクティブな加入者セッションに対して失敗しません。失敗の原因には以下が含まれます。

    • アクセス ドメインに一致する加入者の位置を持つリモート デバイスはありません。

    • BNG に格納されている辞書には、要求されたリモート サービス プロファイルのエントリーは含まれていません。その結果、サービス変数を提供してサービスをインストールする RPC はありません。

  4. RDSM は、各リモート デバイスに必要なパラメーターを解決します。少なくとも、これには加入者識別子が含まれます。

  5. その後、RDSM は、対象となる各デバイスに対して専用の NETCONF セッションを使用し、サービスのプロビジョニングに関する辞書で指定された一連の RPC 呼び出しを発行します。

    サービスプロビジョニングは、対象となるデバイスに対して並行して行われます。以下のいずれかが発生した場合、デバイスのプロビジョニングは失敗します。

    • RDSM は、RPC 呼び出しに対して明示的なエラーを受信します。

    • 応答がタイムアウトします。

    どちらの場合も、以下の ERRMSG イベントが記録されます。

    remote device device-name ip-address service service-name provisioning failed for subscriber subscriber-id

  6. 正常にプロビジョニングされたリモート デバイスは、RDSM に ACK 応答を返します。

    1 台以上のリモート デバイスのプロビジョニングに失敗した場合、RDSM は、正常にプロビジョニングされたすべてのリモート デバイスでサービスをロールバックします。RDSM は、これらの各デバイスへの専用 NETCONF セッションを使用して、サービスのプロビジョニング解除に関する辞書で指定された一連の RPC 呼び出しを発行します。

  7. RDSM は、リモート サービスがリモート デバイスでプロビジョニングされたかどうかを報告するために、帯域外通知を認証に送信します。

    • すべてのリモート デバイスのプロビジョニングに成功すると、RDSM はサービス プロビジョニングの完全な応答を認証済みに送信します。

    • 1 つ以上の対象となるリモート デバイスのプロビジョニングに失敗した場合、RDSM はプロビジョニングの失敗を認証済みとして報告します。

図 3 は、RDSM がログイン時に使用したパラメータ値とは異なるアップストリームのBWサービス プロファイルをインスタンス化して、3 つの対象リモート デバイス、OLT1、OLT2、OLT3 の加入者サービスを正常に更新した場合のプロセス フローを示しています。

図 3:リモート デバイスでの RDSM サービス プロビジョニング:加入者更新フロー RDSM Service Provisioning on a Remote Device: Subscriber Update Flow

加入者サービスの更新は、認証が RDSM にリクエストを送信してリモート サービス プロファイルをインスタンス化してサービスを更新するときに開始されます。プロセス フローは加入者ログイン フローの場合と同じですが、RDSM はサービスのプロビジョニングに必要なすべての処理が完了するまでインスタンス化要求に応答しません。つまり、検証チェックに合格すると、RDSM は ACK 応答を認証する保留中のサービス プロファイルのインスタンス化を送信しません。検証に失敗すると、RDSM は認証に対する NACK 応答を返し、サービスのデプロビジョニングを放棄します。

図 4 は、アップストリームのBWサービス プロファイルを立ち上けることで、RDSM がサービスのプロビジョニングを正常に解除して、3 つの対象となるリモート デバイス、OLT1、OLT2、OLT3 を更新するプロセス フローを示しています。

デプロビジョニング プロセス フローは、加入者のログアウトと認証からの更新要求の両方で同じです。

RDSM は、サービスのプロビジョニング解除に必要なすべての処理が完了するまで認証には応答しません(失敗の再試行を含む)。これにより、デプロビジョニングの結果に関係なく、加入者のログアウトを続行できます。

通常、サービスのデプロビジョニングは失敗しません。その場合は、リモートデバイスで何らかの是正措置を講じて、プロビジョニングを解除する必要があります。

図 4:リモート デバイスでの RDSM サービス デプロビジョニング:加入者のログアウトと更新フロー RDSM Service Deprovisioning on a Remote Device: Subscriber Logout and Update Flow
  1. サービスのデプロビジョニングは、以下のいずれかが発生した場合に開始されます。

    • 加入者がログアウトして認証された場合、要求が RDSM に送信され、対象のリモート デバイス上のリモート サービス プロファイルが表示されます。

    • 認証がRDSMに更新要求を送信し、対象のリモートデバイス上のリモートサービスプロファイルを無効にします。

  2. RDSM は、サービスでプロビジョニングされたリモート デバイスのリストを保持します。デバイスへの NETCONF TCP 接続がダウンしている場合、何らかの方法で発生したと見なされるため、デプロビジョニングは試行されません。例えば、デバイスは、デフォルトのベースライン構成と、すべてのアクティブな加入者サービスに対して BNG によって開始された後続のオペレーター・アクションの再設定で再構成されている場合があります。

  3. RDSM は、リモート サービス プロファイルの隔離要求に応答する前に、最初の検証を実行します。

    • 検証に合格しても、RDSM は認証への応答を送信しません。

    • 検証に失敗した場合、RDSM は認証に対する NACK 応答を返し、サービスのデプロビジョニングを放棄します。検証失敗の原因には、以下が含まれます。

      • 設定されたリモート デバイスがアップ状態ではありません。

      • BNG に格納されている辞書には、要求されたリモート サービス プロファイルまたはデプロビジョニング アクションのエントリは含まれません。その結果、サービス変数を提供してサービスを削除する RPC はありません。

    RDSM が実行する検証チェックは、通常、アクティブな加入者セッションに対して失敗しません。

  4. RDSM は、各リモート デバイスに必要なパラメーターを解決します。少なくとも、これには加入者識別子が含まれます。

  5. その後、RDSM は、対象となる各デバイスへの専用 NETCONF セッションを使用して、サービスのプロビジョニング解除に関する辞書で指定された一連の RPC 呼び出しを発行します。サービスのデプロビジョニングは、対象となるデバイスに対して並行して行われます。以下のいずれかが発生した場合、デバイスのデプロビジョニングは失敗します。

    • RDSM は、RPC 呼び出しに対して明示的なエラーを受信します。

    • 応答がタイムアウトします。

    いずれの場合も、RDSM はデプロビジョニング アクションを 5 秒間隔で最大 5 回再試行します。この試みがすべて失敗した場合は、どちらの場合も以下の ERRMSG イベントが記録されます。

    remote device device-name ip-address service service-name de-provisioning failed for subscriber subscriber-id

  6. プロビジョニング解除に成功したリモート デバイスは、RDSM に ACK 応答を返します。

  7. RDSM は、アウトオブバンド通知を認証に送信し、リモート デバイスでリモート サービスのプロビジョニングが解除されたかどうかを報告します。

    • デプロビジョニングが成功すると、RDSM はサービスのデプロビジョニングの完全な応答を認証済みに送信し、加入者のログアウトを完了します。

      加入者のログアウトではなく更新要求が発生した場合、RDSM は認証に対してサービス プロファイルの分離の完全な応答を送信し、サービス セッションのクリーンアップを完了します。

    • 1 つ以上の対象となるリモート デバイスのプロビジョニング解除に失敗した場合、RDSM は認証のデプロビジョニング失敗を報告します。

RDSM サービスアクション実装辞書

BNGにローカルに保存されたXML辞書は、リモートデバイスサービス管理の不可欠なコンポーネントです。外部権限によってプロビジョニングされた各リモート サービスには、BNG に関する RDSM 辞書のエントリーが必要です。この辞書は、PCRF が提供する課金ルールを、サービスに関連付けられたエントリ内の一連のベンダー固有のリモート プロシージャ コール(RPC)に変換します。その後、RPC はサービスのプロビジョニングまたはデプロビジョニングを行います。RPC はベンダー固有であるため、辞書も同様です。これは、各ベンダーのリモートデバイスに個別の辞書が必要であることを意味します。特定のベンダーのデバイスでは、デバイス上の異なるソフトウェア リリースにも異なる辞書が必要になる場合があります。

辞書形式は、参照サービスと非参照サービスの両方をサポートするのに十分柔軟です。

  • 参照サービスとは、引数を含むサービス全体が、RDSM 辞書を介して外部権限から受け取られるように、リモート デバイスに不透明に表示されていることを意味します。動的サービス・プロファイルには、引数変換時に辞書によって使用される可変スタンザを含めることができます。リモートデバイスは、BNGによる解釈や解析を行うことなく、自分で引数を解析、解釈、適用します。

  • 参照ではないサービスとは、外部権限によって提供されるすべての引数を解決し、1 つ以上の RPC によってリモート・デバイスに個別に提供する必要があることを意味します。この場合、動的サービス・プロファイルには、引数の変換時に辞書で使用される変数スタンザが必要になる場合があります。

いずれの場合も、辞書では、リモート デバイスが 1 つの加入者と別の加入者を区別するのに適した加入者を識別するための手段(通常はレイヤー 2 の場所)を指定する必要があります。

XML RDSM 辞書の一般的な形式は次のとおりです。

表 1 は、辞書の個々のコンポーネントを定義しています。

表 1: XML 辞書コンポーネントの定義

junos-rdm パラメータ

サービスを構成する個々のパラメーターを一覧表示するパラメーター ブロックです。

junos-rdm-parameter

個々のパラメータ。

junos-rdm-name

パラメーター・ブロックでは、このエレメントはリモート・デバイスまたは PCRF 引数上の加入者を識別します。加入者の subscription-id と PCRF で指定された引数の引数名を使用します。

junos-rdm-source

パラメーター値のソース:

  • 値がSDBセッションからソースされた場合の加入者セッション。

  • サービスプロファイルの引数から値が取得された場合のサービスプロファイルです。

junos-rdm-index

指定したソースからパラメーターを解決する列挙された型の値などのインデックス。加入者セッションソースでは、パラメーター値の解決に使用されるSDB属性にパラメーターをマッピングする必要があります。

例えば、一部のユースケースでは、PCRFサブスクリプションIDは、このパラメーターを解決するためにインデックス(属性タイプ)によって参照される加入者SDBエントリーに格納されます。

junos-rdm-services

デバイスでサポートされている 1 つ以上のリモート サービスを一覧表示するサービス ブロック。

junos-rdm-service

サービス名、プロビジョニング設定、デプロビジョニング設定で定義された個々のリモート サービス。

junos-rdm-name

サービス ブロックでは、この要素はサービスの名前です。PCRF から発信されたサービスの引数なしの基本サービス名です。

junos-rdm-provision

プロビジョニング設定を含むプロビジョニング ブロック。

junos-rdm-deprovision

デプロビジョニング構成を含むデプロビジョニング ブロック。

junos-rdm-service-configuration

サービスをプロビジョニングまたはデプロビジョニングする 1 つ以上の RPC を含むサービス設定。プロビジョニングのために PCRF サービスで引数が指定されている場合、RPC にはこれらの引数が含まれます。

junos-rdm-open-configuration

0 個以上の RPC を含むブロックを行い、リモート デバイスの設定を開始します。

junos-rdm-edit-configuration

1 つ以上の RPC を含むブロックで、指定されたサービスの junos-rdm-provision または junos-rdm-deprovision ブロックを参照することで、設定を編集し、サービス プロビジョニングまたはデプロビジョニング アクションをデバイスに一括で適用します。リモート デバイスへの一括更新の一部である各サービスの構成が含まれています。

junos-rdm-commit-configuration

0 個以上の RPC を含むブロックで、リモート デバイスに編集をコミットします。

junos-rdm-close-configuration

リモートデバイスの最終設定に対して、0以上のRPCを含むブロック。

junos-rdm-rpc

リモートデバイスを設定する個々のRPC。

リモート デバイスの設定では、編集設定はサービスのプロビジョニングまたはデプロビジョニングに常に必要です。一部の使用例では、設定ブロックのオープン、コミット、およびクローズはオプションである場合があります。

RDSM アクセス モデルで使用する追加機能

このセクションの機能は RDSM には必要ありませんが、特定の使用事例やトポロジーで役立つ場合があります。

ローカルで生成されたユーザー名は、動的 VLAN、DHCPv4、および DHCPv6 加入者を認証するために外部権限とのやり取りで使用されます。通常、 ステートメントの オプションを設定 interface-name することで、加入者VLANタグがユーザー名に username-include 含まれます。

同様に、 ステートメントの オプションを設定 interface-name することで、加入者VLANタグがPCRFインタラクションのサブスクリプション識別子に subscription-id-data-include 含まれています。

慣習的に、インターフェイス名は両方の場合で次の形式を持っています。

RDSM アクセス モデルの一部の使用例では、外部 VLAN タグはシステム全体で一意です。つまり、基になる IFD 名を除外する別の形式を使用できます。

基になる IFD 名を使用せずにユーザー名形式を生成するには、 ステートメントで vlan-tags オプションのinterface-name代わりに オプションをusername-include指定します。詳細については、 AAA認証用のVLANインターフェイスユーザー名情報の設定とDHCPクライアントの一意のユーザー名の作成を参照してください。

基になる IFD 名なしでサブスクリプション ID 形式を生成するには、 ステートメントで vlan-tags オプションの interface-name 代わりに オプションを subscription-id-data-include 指定します。詳細については 、 PCRF パーティションの設定 を参照してください。

顧客ネットワークの中には、複数の導入モデルやユースケースがあり、その結果、各ケースが同じPCRFバックエンドとやり取りするMXシリーズBNGが生じる場合があります。このような場合は、PCRF のユース ケースを区別する必要がある場合があります。

ピア間の Diameter 機能交換メッセージは、Diameter 製品名 AVP を伝送します。PCRFがメッセージを識別できるように、ユースケースにデフォルト以外の値を設定することができます。詳細については、 DiameterアプリケーションDiameter AVP、Diameterアプリケーションで使用される メッセージを参照してください。

成功または失敗に関する認証による外部権限への対応

外部権限に対する認証の応答方法は、以下によって異なります。

  • 例えば、加入者ログイン時のプロビジョニングと既存の加入者セッションの更新などの操作です。

  • 外部権限 Gx (PCRF)

表 2 は、サービスのプロビジョニングまたはデプロビジョニングのアクションが成功した場合の認証応答の違いを示しています。

表 2: サービス アクションが成功した場合に認証された外部権限への応答方法

操作

Gx

ログイン

authd は、加入者セッションをプロビジョニングするために CCR-I/CCA-I メッセージ交換を開始します。

CCA-I内のすべてのサービスがプロビジョニングされると、認証はCCA-I内の課金ルールごとにサービスがアクティブであることを示すCCR-Uメッセージを送信します。ローカル動的サービスのステータスレポートは、リモートサービスのプロビジョニングが完了するまで遅れます。

更新

デプロビジョニングは、同じPCRF RARメッセージに含まれるサービスのプロビジョニング前に適用されます。

PCRF RAAに含まれるすべてのサービスアクションに対してプロビジョニング解除とプロビジョニングが完了すると、認証はRAA応答をルールレポートとともに送信します。この応答は、RARで指定された各課金ルールについて、サービスの非アクティブ/アクティブ状態を示します。

ローカル動的サービスのステータスレポートは、リモートサービス処理が完了するまで遅れます。

ログアウト

認証は、PCRFに加入者の終端を通知するために、CCR-T/CCA-Tメッセージ交換を開始します。

認証は、加入者セッションに設定されたすべてのサービスのプロビジョニング解除を開始します。

コマンド発行後のup状態の reconfigure サービスデバイス

認証は、サービスアクションが成功したことをRDSMからアウトオブバンド通知を受信しても、それ以上のアクションは行われません。

たとえば、対応する課金ルールに対してサービスがアクティブであることを示す CCR-U メッセージは送信されません。

表 3 は、サービスプロビジョニングまたはデプロビジョニングアクションが失敗した場合の認証応答の違いを示しています。

表 3: サービス・アクションに障害が発生した場合の認証による外部権限への応答

操作

Gx

ログイン

authd は、加入者セッションをプロビジョニングするための CCR-I/CCA-I 交換を開始します。

認証がサービスプロファイルのインスタンス化応答またはRDSMからのアウトオブバンドで障害の通知を受信すると、認証は残りのサービスの処理を停止します。

認証は、以下を報告する CCR-U メッセージを送信します。

  • サービスは、正常にプロビジョニングされたCCA-Iの各課金ルールに対してアクティブです

  • プロビジョニングに失敗したCCA-Iの課金ルールについては、サービスは非アクティブです。

  • サービスは、障害のために処理されないすべての課金ルールについて非アクティブです。

認証により、加入者セッションネゴシエーションを完了してアクティブな状態に到達できます。

更新

デプロビジョニングは、同じPCRF RARメッセージに含まれるサービスのプロビジョニング前に適用されます。

プロセスは、失敗するアクションによって異なります。

  • 認証がサービスプロファイルの非立ち入り応答で障害の通知を受信すると、RDSMは成功せずにすべての再試行を実行したことを意味し、認証は次のサービスアクションを引き続き処理します。

    つまり、サービスのデプロビジョニングのみが失敗すると、更新が続行され、完了します。

  • 認証がサービスプロファイルのインスタンス化応答で障害の通知を受信すると、認証は残りのサービスの処理を停止します。

    リクエスト内のプロビジョニングおよびデプロビジョニングされたサービスはすべてロールバックされます。つまり、正常にプロビジョニングされたサービスがプロビジョニング解除されます。プロビジョニングの解除に成功したサービスが再プロビジョニングされました。

    すべてのロールバックアクションが完了すると、認証はRARで指定された各課金ルールに対してサービスの非アクティブ/アクティブ状態を示すルールレポートを含むRAA応答を送信します。

    つまり、再プロビジョニングされた課金ルールは、アクティブおよびデプロビジョニングされた課金ルールは非アクティブとして報告されます。

ログアウト

認証は、PCRFに加入者の終端を通知するために、CCR-T/CCA-Tメッセージ交換を開始します。

認証は、加入者セッションに設定されたすべてのサービスのプロビジョニング解除を開始します。

認証がサービスプロファイルのインスタンス化応答またはRDSMからのアウトオブバンドで障害の通知を受信すると、残りのサービスのプロビジョニング解除を含め、認証はログアウトを続行します。

コマンドが発行された後の最後の reconfigure サービスデバイス(ダウン状態)

認証は、サービスアクションに失敗したというアウトオブバンド通知をRDSMから受信しても、それ以上のアクションは行われません。

たとえば、対応する課金ルールに対してサービスが非アクティブであることを示す CCR-U は送信されません。

影響を受ける加入者セッションは維持されます。

リモート デバイスのオペレータ再設定

状況によっては、少なくとも1つのリモートデバイスでアクティブで設定されているすべての一致する加入者サービスとデバイスを再同期するために、リモートデバイス上でサービスを手動でプロビジョニングする必要がある場合があります。以下のシナリオでは、手動でのプロビジョニングが必要です。

  • 他のリモートデバイスで1つ以上の加入者セッションがネゴシエートされ、そのデバイス上でリモートサービスがプロビジョニングされた後、新しいリモートデバイスがBNGに接続されます。

  • 1 つ以上のプロビジョニング済みリモート サービスを持つリモート デバイスへの NETCONF セッションはダウン状態に移行し、その後復旧してアップ状態に戻ります。これは、BNGに接続されている新しいデバイスと実質的に同じです。

これらのいずれの状況でも、リモート・デバイスに NETCONF セッションが確立されると、ERRMSG イベントが記録され、そのデバイスが立ち上がっています。現在、デバイス上でリモート サービスがプロビジョニングされていません。RDSM は、デバイス上でプロビジョニングする対象となる加入者リモート サービスのリストを確立します。これらのサービスは、アクティブであるか、プロビジョニング中である必要があります。別の ERRMSG イベントが記録され、サービスが再構成を保留していることを示します。

remote device device-name ip-address has number services pending reconfiguration

コマンドを request services remote-device-management reconfigure service-device 使用して、デバイスに関連付けられたアクセス ドメインにマッピングされたすべてのアクティブ(または処理中)加入者サービスをプロビジョニングします。再設定要求により、デバイス上のサービスの一括プロビジョニングがトリガーされます。1 つのサービスのプロビジョニングに失敗した場合、バルク プロビジョニング全体が失敗と見なされ、正常にプロビジョニングされたサービスはロールバックされます。この場合、もう一度コマンドを発行する必要があります。ロールバックは、一括プロビジョニングの試みごとに適用されるため、一括制限を設定することで、一括プロビジョニング失敗の影響を制御できます。

メモ:

リモート デバイスは、NETCONF セッション確立後に発生する加入者ログインに対するオペレーターの介入なしで、加入者サービスで自動的にプロビジョニングされる資格があります。

リモート デバイスが起動している場合はいつでも、再設定要求を発行できます。リモートデバイスの再設定が開始されると、新しい加入者ネゴシエーションや既存の加入者の更新またはログアウトから生じる新しいサービスアクションは、再設定が完了するまでリモートデバイスに遅れます。また、リモート デバイスが起動しているときはいつでも再設定要求が実行される場合があります。つまり、再設定要求によって既存の加入者がプロビジョニングされる前に、リモートデバイスがネットワークに接続され、新しい加入者サービスのプロビジョニングを受け入れることがあります。

以下の手順は、再構成要求に対する RDSM プロセス フローを示しています。

  1. RDSM は、サービスでプロビジョニングされたリモート デバイスのリストを保持します。デバイスへの NETCONF TCP 接続がダウンしている場合、何らかの方法で発生したと見なされるため、デプロビジョニングは試行されません。例えば、デバイスは、デフォルトのベースライン構成と、すべてのアクティブな加入者サービスに対して BNG によって開始された後続のオペレーター・アクションの再設定で再構成されている場合があります。

  2. RDSM は、一括操作として以下を実行します。この場合、一括サイズではプロビジョニングされる加入者サービスの総数が含まれます。

    1. 再構成要求に応答する前にサービスを検証します。例えば、BNGに格納されている辞書に要求されたリモートサービスプロファイルまたはプロビジョニングアクションのエントリが含まれていない場合、サービス変数を提供してサービスを追加するRPCがないため、検証は失敗します。

    2. 各リモート デバイスに必要なパラメーターを解決します。少なくとも、これには加入者識別子が含まれます。

    3. リモート デバイスへの専用 NETCONF セッションを使用して、サービスプロビジョニングの辞書で指定された一連の RPC 呼び出しを発行します。以下のいずれかが発生した場合、デバイスのプロビジョニングは失敗します。

      • RDSM は、RPC 呼び出しに対して明示的なエラーを受信します。

      • 応答がタイムアウトします。

      いずれの場合も、一括操作によって正常にプロビジョニングされたすべてのサービスを RDSM はロールバックし、再構成は放棄され、RDSM は以下の ERRMSG イベントをログに記録します。

      remote device device-name ip-address reconfiguration failed

  3. リモート デバイス上のすべての加入者サービスのプロビジョニングが完了した場合、RDSM は以下の ERRMSG イベントを記録します。

    remote device device-name ip-address reconfiguration succeeded

ERRMSG イベントを処理するための外部通知

表 4 は、認証が外部管理システムと通信できる ERRMSG イベントと、通知に含まれる情報をリストしています。正常なリモート・サービス・アクションは外部権限にのみ報告され、ERRMSG ログは生成されません。

表 4: ERRMSG イベントの外部通知に含まれる情報

ERRMSG イベント

デバイス名

IP アドレス

現在の状態

再設定が保留されているサービス数

サービス名

加入者識別子

デバイスのリモート ステータスがアップからダウンまたはダウンからアップに変更

リモート デバイスに再構成中のサービスがある

リモート デバイスの再設定完了(成功または失敗)

加入者リモートサービスプロビジョニングの失敗

加入者のリモートサービスデプロビジョニングの失敗

リモートデバイスサービス管理のメリット

  • 加入者サービスがMXシリーズBNGとそのアクセスノードの両方にまたがるトポロジーを可能にし、単一の論理システムを形成します。

  • 外部管理およびプロビジョニング システムを使用するトポロジーで、BNG およびリモート デバイスの設定と管理を簡素化します。リモートデバイスは通常、外部システムに未知のプライベートアドレスを持っているので、外部システムはMXシリーズBNGにのみ対応します。

  • リモート サービスの新しいサービス プロファイル タイプを追加して、リモート サービスとローカル サービスを簡単に区別できます。