Remote Device Services Manager(RDSM)の概要

リモートサービス

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)でサービスプロビジョニングに成功した場合のプロセスフローを示しています。

1. サービスプロビジョニングは、加入者がログインし、ネゴシエーション中にAuthdがRDSMにリクエストを送信して、対象となるリモートデバイス上でリモートサービスプロファイルをインスタンス化すると開始されます。

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

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

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

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

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

   • 検証に失敗した場合、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. 正常にプロビジョニングされたリモートデバイスは、ACK応答をRDSMに返します。

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

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

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

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

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

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

図4 は、アップストリームBWサービスプロファイルのインスタンス化を解除することにより、RDSMがサービスのプロビジョニング解除に成功し、対象となる3つのリモートデバイス(OLT1、OLT2、OLT3)を更新する場合のプロセスフローを示しています。

プロビジョニング解除プロセスのフローは、加入者のログアウトと authd からの更新リクエストの両方で同じです。

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

サービスのプロビジョニング解除は通常失敗しません。その場合、プロビジョニング解除を成功させるために、リモートデバイスに対して何らかの修正アクションを実行する必要がある場合があります。

1. サービスプロビジョニング解除は、以下のいずれかが発生した場合に開始されます。

   • 加入者がログアウトすると、authdがRDSMにリクエストを送信して、対象となるリモートデバイス上のリモートサービスプロファイルのインスタンス化を解除します。

   • authdは、RDSMに更新リクエストを送信して、対象となるリモートデバイス上のリモートサービスプロファイルのインスタンス化を解除します。

2. RDSMは、サービスでプロビジョニングされたリモートデバイスのリストを維持します。デバイスへのNETCONF TCP接続がダウンしている場合、他の手段によって行われたと見なされるため、プロビジョニング解除は試行されません。例えば、デバイスがデフォルトのベースライン設定で再設定されており、その後の運用担当者のアクションにより、すべてのアクティブな加入者サービスに対してBNGによって再設定が開始されている可能性があります。

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

   • 検証に合格すると、RDSMはauthdに応答を送信しません。

   • 検証に失敗した場合、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. プロビジョニング解除に成功したリモートデバイスは、ACK応答をRDSMに返します。

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

   • プロビジョニング解除が成功すると、RDSMはサービスプロビジョニング解除の完全な応答をauthdに送信し、これにより加入者のログアウトが完了します。

     加入者ログアウトではなく更新リクエストの場合、RDSMはサービスプロファイルのインスタンス化解除完全な応答をauthdに送信し、サービスセッションのクリーンアップを完了します。

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

サービスアクションを実装するためのRDSMディクショナリ

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

辞書形式は、参照サービスと非参照サービスの両方をサポートするのに十分な柔軟性を備えています。

• 参照サービスとは、引数を含むサービス全体が、RDSM辞書を介して外部機関から受信したように、リモートデバイスに不透明に提示されることを意味します。動的サービスプロファイルには、引数の変換中にディクショナリによって使用される変数スタンザを含めることができます。リモートデバイスは、BNGによる解釈や解析なしに、引数を独自に解析、解釈、適用します。

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

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

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

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

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

junos-rdm-parameters	サービスを設定する個々のパラメーターを一覧表示するパラメーター ブロック。
junos-rdm-parameter	個々のパラメーター。
junos-rdm-name	パラメーター ブロックでは、この要素はリモート デバイスまたは PCRF 引数上の加入者を識別します。加入者にはsubscription-idを使用し、PCRFで指定された任意の引数には引数の名前を使用します。
junos-rdm-source	パラメーター値のソース: 値が SDB セッションから取得された場合、加入者セッション。 service-profile 値がサービスプロファイル引数から取得される場合。
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	指定されたサービスのjunos-rdm-provisionまたはjunos-rdm-deprovisionブロックを参照することにより、設定を編集し、サービスプロビジョニングまたはプロビジョニング解除アクションをデバイスに一括で適用するための1つ以上のRPCを含むブロック。リモートデバイスへの一括更新の一部である各サービスの設定が含まれています。
junos-rdm-commit-configuration	リモートデバイスに編集をコミットするための0個以上のRPCを含むブロック。
junos-rdm-close-configuration	リモートデバイスの設定を終了するための RPC が 0 個以上含まれるブロック。
junos-rdm-rpc	リモートデバイスを設定するための個々のRPC。

リモートデバイス設定の場合、サービスのプロビジョニングまたはプロビジョニング解除には常に設定の編集が必要です。ユースケースによっては、open、commit、closeの設定ブロックがオプションになる場合があります。

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

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

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

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

慣例により、インターフェイス名は両方の場合で次の形式になります。

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

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

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

お客様のネットワークによっては、複数の導入モデルまたはユースケースがあり、その結果、同じPCRFバックエンドとやり取りするケースごとにMXシリーズBNGが発生する場合があります。この状況では、PCRFのユースケースを区別する必要があるかもしれません。

ピア間のDiameter Capability Exchangeメッセージは、Diameter Product-Name AVPを伝送します。PCRFがメッセージを区別できるように、ユースケースにデフォルト以外の値を設定できます。詳細については、「 Diameter アプリケーションで使用されるメッセージ」 および「 Diameter AVP と Diameter アプリケーション 」を参照してください。

成功または失敗時の認証による外部機関への応答

authdが外部機関にどのように応答するかは、以下によって異なります。

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

• 外部権限、Gx(PCRF)。

表2は 、サービスのプロビジョニングまたはプロビジョニング解除アクションが成功したときに、authd応答がどのように変化するかを示しています。

表2:サービスアクションが成功したときのauthdの外部権限への応答方法

操作	Gx
ログイン	authd は、加入者セッションをプロビジョニングするために CCR-I/CCA-I メッセージ交換を開始します。 CCA-Iのすべてのサービスがプロビジョニングされると、authdはCCA-Iの各課金ルールに対してサービスがアクティブであることを示すCCR-Uメッセージを送信します。ローカル動的サービスのステータスレポートは、リモートサービスのプロビジョニングが完了するまで遅延されます。
更新	同じPCRF RARメッセージに含まれるサービスのプロビジョニングの前に、プロビジョニング解除が適用されます。 PCRF RAAに含まれるすべてのサービスアクションのプロビジョニング解除とプロビジョニングが完了すると、authdはRARで指定された各課金ルールのサービスの非アクティブ/アクティブ状態を示すルールレポートとともにRAA応答を送信します。 ローカル動的サービスの状態報告は、リモートサービス処理が完了するまで遅延されます。
ログアウト	authdは、CCR-T/CCA-Tメッセージ交換を開始し、PCRFに加入者終了を通知します。 authd は、加入者セッションに設定されたすべてのサービスのプロビジョニング解除を開始します。
reconfigureコマンド発行後のアップ状態のサービスデバイス	authdは、RDSMからサービスアクションが成功したという帯域外通知を受信しても、それ以上のアクションは実行しません。 例えば、対応する課金ルールに対してサービスがアクティブであることを示すCCR-Uメッセージは送信されません。

表3は 、サービスのプロビジョニングまたはプロビジョニング解除のアクションが失敗したときの認証された応答の変化を示しています。

表3:サービスアクションが失敗した場合の外部権限へのauthdの応答方法

操作	Gx
ログイン	authd は、CCR-I/CCA-I 交換を開始して、加入者セッションをプロビジョニングします。 authdがRDSMからサービスプロファイルのインスタンス化応答または帯域外で障害の通知を受信すると、authdは残りのサービスの処理を停止します。 authd は、以下を報告する CCR-U メッセージを送信します。 サービスは、正常にプロビジョニングされたCCA-I内の各課金ルールに対してアクティブです プロビジョニングに失敗したCCA-Iの課金ルールのサービスは非アクティブです。 障害のために処理されなかったすべての課金ルールに対して、サービスは非アクティブになります。 Authd により、加入者セッションのネゴシエーションが完了してアクティブな状態に到達できます。
更新	同じPCRF RARメッセージに含まれるサービスのプロビジョニングの前に、プロビジョニング解除が適用されます。 このプロセスは、失敗するアクションによって異なります。 authdがサービスプロファイルのインスタンス化解除応答で失敗の通知を受信した場合、つまりRDSMがすべての再試行を成功せずに実行した場合、authdは次のサービスアクションの処理を続行します。 つまり、サービスのプロビジョニング解除のみが失敗した場合、更新は続行され、完了します。 authdがサービスプロファイルのインスタンス化応答で失敗の通知を受信すると、authdは残りのサービスの処理を停止します。 リクエスト内のプロビジョニング済みおよびプロビジョニング解除済みサービスはすべてロールバックされます。つまり、正常にプロビジョニングされたサービスはプロビジョニング解除されます。正常にプロビジョニング解除されたサービスが再プロビジョニングされました。 すべてのロールバックアクションが完了すると、authdはRARで指定された各課金ルールのサービスの非アクティブ/アクティブ状態を示すルールレポートを含むRAA応答を送信します。 つまり、再プロビジョニングされた課金ルールはアクティブとして報告され、プロビジョニング解除された課金ルールは非アクティブとして報告されます。
ログアウト	authdは、CCR-T/CCA-Tメッセージ交換を開始し、PCRFに加入者終了を通知します。 authd は、加入者セッションに設定されたすべてのサービスのプロビジョニング解除を開始します。 authdがサービスプロファイルのインスタンス化応答またはRDSMからの帯域外で障害の通知を受信すると、authdはログアウトを続行し、残りのサービスのプロビジョニングを解除します。
reconfigureコマンドを発行した後にダウン状態になった最後のサービスデバイス	authdは、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 に、authdが外部管理システムと通信できるERRMSGイベントと、通知に含まれる情報を示します。リモート・サービス・アクションが成功すると、外部機関にのみ報告され、ERRMSG ログは生成されません。

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

ERRMSGイベント	デバイス名	IPアドレス	現在の状態	再設定保留中のサービス数	サービス名	加入者識別子
リモートデバイスのステータスがアップからダウンまたはダウンからアップに変化します	✓	✓	✓	–	–	–
リモートデバイスには再設定を保留中のサービスがあります	✓	✓	–	✓	–	–
リモートデバイス再設定の完了(成功または失敗)	✓	✓	✓	–	–	–
加入者のリモートサービスプロビジョニングに失敗	✓	✓	–	–	✓	✓
加入者のリモートサービスのプロビジョニング解除に失敗	✓	✓	–	–	✓	✓

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

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

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

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