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

リモートサービス

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

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

ただし、リモート サービスは非参照方式で適用することもできます。この場合、外部権限は、ローカル・サービスの場合と同様に、リモート・サービスを参照的に指定します。リモートサービスプロファイルには、サービスパラメータを定義するための変数が1つ以上含まれています。次に、RDSM は、リモートデバイスに割り当てられたデータディクショナリを使用して、そのデバイスでサービスを設定します。デバイスの RDSM ディクショナリの内容は、サービス プロバイダーが参照方式と非参照方式のどちらを使用するかによって異なります。

リモート動的サービス プロファイルは、多数の設定スタンザを含むことができるローカル サービス プロファイルと比べると非常に軽量です。リモート動的サービス プロファイルには、次の 2 つの機能のみが含まれます。

• 動的プロファイル・タイプが remote-device-service であることを指定する必要があります。この設定により、プロファイルがローカル サービス プロファイルとして使用できなくなります。つまり、ダイナミック サービス プロファイルを二重目的(ローカルとリモートの両方)に設定することはできません。

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

追加の構成はコミット チェックに失敗します。リモートサービスプロファイルは非常に具体的であるため、リモートサービスごとに専用のサービスプロファイルが必要です。外部機関の場合、これは、各リモートサービスに個別のPCRF課金ルールが必要であることを意味します。

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

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

• サブスクライバーのログイン時にプロビジョニングされます。サービスは、Gx CCR-I/CCR-A メッセージ交換の開始に応じて PCRF から供給することができます。

• サブスクライバーのログアウト中にプロビジョニング解除されます。

• PCRF からの Gx RAR メッセージなどの外部権限に応じて、アクティブなサブスクライバ セッション用にプロビジョニングまたはプロビジョニング解除されます。

図 2 は、RDSM が upstreamBW サービスプロファイルをインスタンス化することによって、3 つの適格なリモートデバイス(OLT1、OLT2、および OLT3)でサービスを正常にプロビジョニングしたときのプロセスフローを示しています。

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

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

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

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

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

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

   • 検証に失敗した場合、RDSM は authd に 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 は、リモートサービスがリモートデバイスでプロビジョニングされたかどうかを報告するために、authd に帯域外通知を送信します。

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

   • 1 つ以上の適格なリモートデバイスのプロビジョニングに失敗した場合、RDSM はプロビジョニングの失敗を authd に報告します。

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

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

図 4 は、RDSM がサービスのプロビジョニングを正常に解除して、3 つの適格なリモート デバイスである OLT1、OLT2、および OLT3 を upstreamBW サービス プロファイルのインスタンス解除によって更新する場合のプロセス フローを示しています。

プロビジョニング解除のプロセス フローは、サブスクライバーのログアウトと authd からの更新要求の両方で同じです。

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

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

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

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

   • authd は RDSM に更新リクエストを送信して、適格なリモートデバイスでリモートサービスプロファイルをインスタンス解除します。

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

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

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

   • 検証に失敗した場合、RDSM は authd に 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 は authd に帯域外通知を送信して、リモートサービスがリモートデバイスでプロビジョニング解除されたかどうかを報告します。

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

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

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

サービスアクションを実装するための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 引数を識別します。サブスクライバーのサブスクリプション ID と、PCRF で指定された引数の引数の名前を使用します。
junos-rdm-source	パラメータ値のソース: 値が SDB セッションから取得される場合の subscriber セッション。 値がサービス プロファイル引数から取得される場合の service-profile
junos-rdm-index	指定したソースからパラメーターを解決するインデックス (列挙型の値など)。サブスクライバー セッション ソースでは、パラメーター値の解決に使用される SDB 属性にパラメーターをマップするために、これが必要です。 たとえば、一部のユースケースでは、PCRF サブスクリプション ID は、このパラメーターを解決するためにインデックス (属性タイプ) によって参照されるサブスクライバー SDB エントリに格納されます。
junos-rdm-services	デバイスでサポートされている 1 つ以上のリモート サービスを一覧表示する Service ブロック。
junos-rdm-service	サービス名、プロビジョニング構成、プロビジョニング解除構成で定義された個々のリモートサービス。
junos-rdm-name	サービス ブロックでは、この要素はサービスの名前です。これは、PCRF から供給されるサービスの基本サービス名 (引数なし) です。
junos-rdm-provision	プロビジョニング構成を含むプロビジョニング ブロック。
junos-rdm-deprovisioning(Junos-RDM-Deprovisioning)	設定のプロビジョニング解除を含むプロビジョニング解除ブロック。
junos-rdm-service-configuration	サービスをプロビジョニングまたはプロビジョニング解除するための 1 つ以上の RPC を含むサービス構成。プロビジョニングのために PCRF サービスで引数が指定されている場合、RPC にはそれらの引数が含まれます。
junos-rdm-open-configuration	リモート デバイスの構成を開始するための 0 個以上の RPC を含むブロック。
junos-rdm-edit-configuration	指定されたサービスのjunos-rdm-provisioningまたはjunos-rdm-deprovisioningブロックを参照して、設定を編集し、サービスプロビジョニングまたはプロビジョニング解除アクションをデバイスに一括で適用するための1つ以上のRPCを含むブロック。リモート デバイスへの一括更新の一部である各サービスの構成が含まれています。
junos-rdm-commit-configuration	リモート デバイスに編集をコミットするための 0 個以上の RPC を含むブロック。
junos-rdm-close-configuration	リモート デバイスの構成を終了するための 0 個以上の RPC を含むブロック。
junos-rdm-rpc	リモート デバイスを構成する個々の RPC。

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

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

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

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

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

慣例により、インターフェイス名はどちらの場合も次の形式になります。

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

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

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

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

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

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

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

• たとえば、サブスクライバ ログイン時のプロビジョニングと既存のサブスクライバ セッションの更新など、実行される操作。

• 外部機関 Gx (PCRF)。

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

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

操作	ティッカー
ログイン	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 は、サービスのプロビジョニングまたはプロビジョニング解除アクションが失敗した場合の authd 応答の変化を示しています。

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

操作	ティッカー
ログイン	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のみをアドレス指定します。

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