- このマニュアルについて
- Broadband Access Center の概要
- Broadband Access Center のアーキ テクチャ
- 設定のワークフロー
- CPE プロビジョニングの概要
- 設定テンプレートの管理
- DOCSIS 設定
- PacketCable 音声設定
- CableHome の設定
- Broadband Access Center の管理
- Broadband Access Center の監視
- 管理者のユーザ インターフェイスに ついて
- 管理者のユーザ インターフェイスの使 用方法
- Broadband Access Center の設定
- サポートするツールと高度な概念
- データベースの管理
- Broadband Access Center のトラブル シューティング
- アラートとエラー メッセージ
- オプションのサポート
- PacketCable DHCP オプションと BAC プロパティのマッピング
- プロビジョニング API の使用例
- Broadband Access Center のプロビ ジョニングに関する FAQ
- 用語集
- 索引
Cisco Broadband Access Center アドミニストレータ ガイド Release 4.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月30日
章のタイトル： CPE プロビジョニングの概要
CPE プロビジョニングの概要
この章では、Broadband Access Center（BAC）で Customer Premises Equipment（CPE; 顧客宅内装置）がサポートするテクノロジーを使用して CPE を管理する方法について説明します。この章は、次の項で構成されています。
•
「概要」
概要
BAC を使用して、住宅用デバイス（DOCSIS ケーブル モデムおよびセットトップ ボックス、PacketCable eMTA、CableHome デバイス、コンピュータ）のプロビジョニングと管理を行うことができます。
BAC は次のデバイス タイプのプロビジョニングを行います。
• DOCSIS 1.0、1.1、2.0 準拠のケーブル モデムと STB
• PacketCable バージョン 1.x 準拠の embedded Multimedia Terminal Adapter（eMTA; 組み込み型マルチメディア ターミナル アダプタ）
このリリースの BAC は、次のプロビジョニングと管理をサポートします。
–Set-top box（STB; セットトップ ボックス）
• ビデオ STB（特に進化途上の OpenCable アプリケーション プラットフォームに基づく RNG-200 STB）。
• embedded Service/Application Functional Entities（eSAFE）デバイスのバリアント。混在 IP モードの PacketCable Multimedia Terminal Adapters（MTA; マルチメディア ターミナル アダプタ）などがあります。混在 IP モード MTA は、IPv6 組み込みケーブル モデムと IPv4 eMTA で構成される eSAFE デバイスです。このクラスのデバイスでは、ケーブル モデムにパケット テレフォニー、ホーム ネットワーキング、動画などの付加的機能が組み込まれています。
デバイス オブジェクト モデル
BAC のデバイス オブジェクト モデルは、DPE のデバイス管理用に生成される構成を制御する上で重要です。このデバイス構成生成プロセスは RDU で発生し、名前付き属性および関連付けを通じて制御されます。
デバイス オブジェクト モデルには、次の主要オブジェクトがあります。
• IP デバイス：プロビジョニングを必要とするネットワーク エンティティを表します。
• プロビジョニング グループ：特定の複数の DPE からサービスを受けるデバイスの論理グループを表します。
• サービス クラス：デバイスに割り当てる構成プロファイルを表します。
• DHCP 基準：デバイスが、Cisco Network Registrar DHCP サーバ内で IP アドレスの選択を決定するための基準を表します。
• ファイル：プロビジョニングで使用される、テンプレートを含むファイルのコンテナとして機能します。
• ノード：デバイスをグループ化するための顧客固有のメカニズム。
BAC デバイス データ モデルの各種オブジェクトには、次の共通要素があります。
• 属性：たとえば、Device ID や Fully Qualified Domain Name（FQDN; 完全修飾ドメイン名）。
• 関連付け：たとえば、デバイスとサービス クラスの関連付け。
• プロパティ：たとえば、デバイスを特定のプロビジョニング グループに追加することを指定するプロパティ。
図4-1 に、デバイス データ モデルの各種オブジェクト間のインタラクションを示します。
表4-1 は、データ モデルの各オブジェクトに固有の属性および関連付けを示しています。
|
|
|
|---|---|
| • |
|
| 属性には、Type、Name、および Properties があります（詳細については、「サービス クラス」を参照してください）。 |
|
サービス クラスは RDU 抽象の 1 つで、静的ファイルまたはテンプレート ファイルとしてデバイスに渡されるファイル構成を表します。サービス クラスを使用すると、デバイスをグループ化して構成セットにすることができます。構成セットは、各種のサービス レベルまたはパッケージで CPE に提供されます。
• 登録されているもの：デバイスの登録時にユーザによって指定されます。このサービス クラスは、明示的に、Application Programming Interface（API; アプリケーション プログラミング インターフェイス）を介してデバイス レコードに追加されます。
• 選択されているもの：RDU 拡張によって選択され、返されます。
• 関連付けられているもの：登録、選択、またはその両方の操作によってデバイスに関連付けられます。このサービス クラスは、RDU 拡張によって選択されます。
デバイス用の選択されているサービス クラスが変更された場合は、デバイス構成が再生成されます。デバイス用の登録されているサービス クラスが変更された場合、それが選択されているサービス クラスでなくても、デバイス構成が再生成されます。その理由は、サービス クラスが適用するポリシーによって、選択されているサービス クラスが変更される可能性があるためです。
検出されたデータ
プロビジョニング プロセスの間、BAC は一連のプロパティを使用してデバイス タイプを検出し（デバイスがケーブル モデムやコンピュータかどうかなど）、そのデバイス タイプと技術用の構成を生成します。この一連のプロパティを使用して BAC が検出した情報は、検出されたデータと呼ばれます。BAC は、デバイスごとに検出されたデータを RDU データベースに格納します。
デバイスがプロビジョニング サーバに接続すると、ファームウェアのバージョン、MAC アドレス、操作モードなど、そのデバイス自体に関する詳細情報を提供します。プロビジョニング サーバに接続するケーブル モデムの場合、これらの詳細は次のメッセージに含まれています。
Network Registrar にインストールされている BAC 拡張も、デバイスの構成を要求するときに、検出されたデータを取得して RDU に送信します。これらのデバイスの場合、検出されたデータは Network Registrar の設定によって異なります。属性またはオプションが Network Registrar で使用できるように設定されている場合、拡張は、その属性またはオプションの値を DHCP パケットから取得し、検出されたデータの中に含めて BAC プロビジョニングで使用できるようにします。
表4-2 は、BAC が IPv4 デバイスから検出するデータの一覧を示します。
|
|
|
|---|---|
表4-3 は、BAC が IPv6 デバイスから検出するデータの一覧を示します。
Device Details ページの管理者のユーザ インターフェイスを使用して検出されたデータを表示できます。デバイスの詳細の表示方法については、「デバイスの詳細の表示」を参照してください。
BAC 拡張が DHCPv4 および DHCPv6 のデータの検出に使用するプロパティの一覧については、「属性とオプション」を参照してください。
DHCPv4 標準は、クライアント識別子または MAC アドレスを DHCP クライアントのプライマリ デバイス識別子として使用しますDHCPv6 では、新しいプライマリ デバイス識別子である DHCP Unique Identifier（DUID）が導入されています。
DHCPv4 は、アドレスの割り当て時に、ハードウェア アドレスとオプションのクライアント識別子を使用してクライアントを識別します。DHCPv6 も基本的に同じスキームに従いますが、クライアント識別子が必須になり、ハードウェア アドレスとクライアント ID を連結して 1 つの一意のクライアント識別子にします。
DHCPv6 のクライアント識別子は次の項目で構成されます。
• DUID：クライアント システムを示します（DHCPv4 のようにインターフェイスだけではない）。
• Identity Association Identifier（IAID）：システム上のインターフェイスを示します。RFC 3315 で説明されているように、Identity Association は、サーバとクライアントが、関連する一連の IPv6 アドレスを識別、グループ化、および管理するために使用する手段です。
DHCP クライアントとサーバはそれぞれ DUID を持っています。DHCP サーバは、DUID を使用してクライアントを IA と関連付けて識別し、設定情報を選択します。DHCP クライアントは、サーバの識別が必要なメッセージの場合、DUID を使用してメッセージ内のサーバを識別します。
構成の生成と処理
BAC 配備内でデバイスを有効にすると、そのデバイスは BAC サーバとの交信を開始します。交信が確立すると、デバイスの事前設定されたポリシーが、デバイスに関連付けられている設定テンプレートに基づいて DPE によるデバイスのプロビジョニングおよび管理を決定します。このデバイスの信頼できるプロビジョニング情報は、デバイス構成として、RDU から DPE に転送されます。DPE はデバイス構成をキャッシュし、デバイスからのサービス要求に対して使用します。
デバイス構成には、ユーザが必要とする次のプロビジョニング情報を含めることができます。
構成には、識別子（MAC アドレスまたはファイル名）と、構成が再生成されるたびに大きくなるリビジョン番号が含まれます。
• デバイスのサービス クラス変更など、特定のプロビジョニング API コールが実行された場合。
• 構成の検証が失敗した場合。デバイスから送信された DHCP 要求の特定のパラメータが最初の要求パラメータと異なる場合などに発生します。
RDU がデバイスの構成を再生成するたびに、更新された構成が該当する DPE に転送され、キャッシュされます。
静的ファイルとテンプレート ファイルの比較
BAC でのデバイスのプロビジョニングは、静的ファイルとテンプレート ファイルという 2 つのタイプの設定ファイルを使用して行うことができます。
静的設定ファイルを使用する場合、ファイルを BAC システムに入力します。設定ファイルが入力されたら、その構成を生成するために TFTP を介して特定のデバイスに配信されます。BAC は、静的設定ファイルをその他のバイナリ ファイルと同様に扱います。静的ファイルは、拡張子 .cm で識別します。
テンプレート ファイルは、DOCSIS、PacketCable、または CableHome オプションと、特定のサービス クラスで使用された場合に動的ファイル生成を実行する値が含まれるテキスト ファイルです。BAC には設定ファイル ユーティリティが同梱されており、DOCSIS、PacketCable、および CableHome の設定ファイルとテンプレート ファイルのテスト、検証、表示に使用できます。設定ファイルユーティリティの使用方法の詳細については、「設定ファイル ユーティリティの使用方法」を参照してください。テンプレート ファイルは、拡張子 .tmpl で識別します。
静的プロビジョニングと動的プロビジョニングの概要については、 表2-4 を参照してください。
プロパティ階層
BAC のプロパティを使用すると、BAC で API を介してデータにアクセスしたり、データを格納したりできます。事前プロビジョニングされたデータ、検出されたデータ、およびステータス データは、API を介して、対応するオブジェクトのプロパティから取得できます。また、プロパティを使用すると、BAC を適切な粒度で（システム レベルからデバイス グループおよび個々のデバイスのレベルまで）設定できます。
デバイス関連のプロパティは、BAC プロパティ階層内の任意の許容ポイントで定義できます。プロパティを任意のレベルで割り当てられるかどうかの詳細については、API Javadoc を参照してください。
BAC プロパティ階層には、個々のデバイスまたはデバイスのグループに対してプロパティを定義できるという柔軟性があります。プロパティは、デバイスおよび関連付けられたオブジェクト上で見つかるまで次の順序で検索されます。
1. デバイス登録済みプロパティ：API または管理者のユーザ インターフェイスを介して設定されたプロパティを指定します。
2. デバイス選択プロパティ：サービス レベル選択プロセスによってデバイス レコードに保存されたプロパティを指定します。
3. デバイス検出プロパティ：デバイス検出プロセスによってデバイス レコードに保存されたプロパティを指定します。
4. プロビジョニング グループ：デバイスのプロビジョニング グループのプロパティを指定します。
5. サービス クラス：デバイスのサービス クラス上に設定されているプロパティを指定します。サービス レベル選択プロセスがデバイスの選択済みサービス クラスを判別したら、そのオブジェクトのプロパティが使用されます。判別しなかった場合、プロパティは、API または管理者のユーザ インターフェイスを介して、デバイスに対して設定されている登録済みサービス クラスから検索されます。
6. DHCP 基準：デバイスの DHCP 基準上に設定されているプロパティを指定します。サービス レベル選択プロセスがデバイスの選択済み DHCP 基準を判別したら、そのオブジェクトのプロパティが使用されます。判別しなかった場合、プロパティは、API または管理者のユーザ インターフェイスを介して、デバイスに対して設定されている登録済み DHCP 基準から検索されます。
7. テクノロジー デフォルト：デバイスのテクノロジー デフォルトに設定されているプロパティを指定します。たとえば、DOCSIS モデム、PacketCable MTA、またはコンピュータのテクノロジー デフォルトなどです。
テンプレートとプロパティ階層
動的に構成を生成すると、デバイス設定ファイルのテキスト記述（テンプレートとも呼ばれる）をバイナリのデバイス構成に変換する処理も行われます。このバイナリ設定ファイルは、基本的には type-length-value（TLV）タプルのリストであり、各タプルにはデバイス構成の設定値が含まれます。処理後のバイナリ構成は、TFTP を介してデバイスに転送されます。
動的な構成生成では、マクロ機能の使用によって大幅な柔軟性が実現されます。マクロにより、BAC プロパティ階層の値をテンプレートに代入できます。この代入は、通常は上書きされる次のような値に使用されます。
このように、BAC は 1 つのテンプレートを使用して、数台から数百や数千、数百万台まで、何台でもデバイスの構成を生成します。
カスタム プロパティ
BAC を使用すると、RDU 内に新しいプロパティを定義できます。定義されたプロパティは、API を介して任意のオブジェクト上に格納することができます。これらのプロパティによって、テンプレートに値を代入できます。
カスタム プロパティは、RDU で定義された変数名であるため、スペースを含めることはできません。
カスタム プロパティの作成方法の詳細については、「カスタム プロパティの設定」を参照してください。
BAC におけるデバイス配備
BAC 配備はプロビジョニング グループに分割され、各プロビジョニング グループはデバイスのサブセットだけに関連付けられます。耐障害性を確保するため、プロビジョニング グループによって提供されるサービスはすべて実装されます（「プロビジョニング グループ」を参照）。
BAC では、次の 2 つのデバイス配備オプションを使用できます。
• Preprovisioned：RDU に、さまざまなデバイス タイプの構成とルールが読み込まれます。デバイス レコードが RDU に追加されると、そのデバイス タイプ固有の構成がマッピングされます。
• Self-provisioned：デバイスがプロビジョニング グループと最初に交信した後で、デバイス レコードが RDU に追加されます。ただし、事前プロビジョニングされたルールによってデバイスの構成が決まります。
CPE 登録モード
登録モードによって、サービス プロバイダーは加入者とのインタラクション数を制御できます。どの登録済みのデバイスについても、サービス プロバイダーはそのデバイスに対する変更があれば処理できるように準備する必要があります。背後に未登録のコンピュータがあるケーブル モデムを 100 台登録する作業と、それぞれの背後に登録済みコンピュータが大量に存在する可能性のあるケーブル モデムを 100 台登録する作業では、大きな違いがあります。この理由で、サービス プロバイダーは標準モード、無差別モード、ローミング モード、および混在モードから登録モードを慎重に選択する必要があります。
標準モード
標準モード（固定モードとも呼ばれる）での動作時、コンピュータは登録され、そのコンピュータが正しいケーブル モデムの背後にあれば、登録済みのアクセス権を受け取ります。このコンピュータが別のケーブル モデムの背後に移動すると、プロビジョニングされていないアクセス権が与えられます。
無差別モード
無差別モードでの動作時、DOCSIS モデムだけが登録され、別のデバイスの背後で動作しているデバイスに関するリース情報は DHCP サーバに保持されます。登録済みのデバイスの背後にある指定されたタイプのデバイスは、すべてネットワーク アクセス権を受け取ります。
ローミング モード
ローミング モードでの動作時、登録済みのデバイスは、他のどの登録済みデバイスの背後でも割り当てられたサービスを受け取ります。たとえば、このモードでは、ラップトップを使用しながら場所を移動し、複数のケーブル モデムからサービスを得ることができます。
混在モード
CPE プロビジョニング フロー
初期設定ワークフロー
この項では、デバイスが最初にインストールされ、ブートされるときの設定フローについて説明します。このワークフローは、配備および登録モードによって異なります。次のワークフローがあります。
事前プロビジョニングされたデバイスのワークフロー
この項では、事前プロビジョニングされたデバイスのワークフローについて説明します。図4-2 は、一般的な初期設定フローを示しています。
図4-2 初期デバイス設定のワークフロー：事前プロビジョニング モード
1. BAC API から RDU に、さまざまなデバイス タイプ用に特別に定義された構成およびルールが読み込まれます。デバイスが事前設定され、サービス クラスに関連付けられ、RDU データベースに事前登録されます。
（注） CPE を事前設定すると、API を介して BAC にデバイス情報（MAC アドレス、サービス クラスなどの）が読み込まれます。
事前プロビジョニング モードでは、この処理が行われた後にネットワーク上でデバイスがブートします。セルフプロビジョニング モードでは、ネットワーク上でデバイスがブートしてからこの処理が行われます。
2. ブート時に、デバイスは自分のプロビジョニング グループを検出し、プロビジョニング グループの DPE に対して自動プロビジョニング フローを開始します。Cable Modem Termination System（CMTS; ケーブル モデム ターミネーション システム）がブロードキャスト トラフィックを DHCP サーバにリレーします。DHCP サーバまたは Network Registrar DHCP サーバ上の BAC 拡張が DPE に構成を要求します。
（注） デバイスがローミング モードを使用して新しいプロビジョニング グループに移動した場合は、前に属していたプロビジョニング グループから古い構成が削除される点を除き、同じフローがデバイスに対して実行されます。
3. DPE は、デバイス要求を受信すると、キャッシュにデバイスの構成があるかどうか検索します。デバイスはこれまでこのプロビジョニング グループと交信したことがないため、構成は見つかりません。次に、プロビジョニング グループ内の Network Registrar 拡張が、RDU にデバイスの構成を生成するように要求します。
RDU で要求処理にかかる時間によっては、プロビジョニング グループがデバイス要求に応答しないことを決定する場合もあります。
4. RDU が、デバイスに適した構成を生成します。生成されるデバイス構成では、DHCP 検出など、さまざまな CPE プロトコル イベントに対する DPE 応答が指定されます。
5. デバイス構成が DPE に転送され、そこでキャッシュされます。この段階で、DPE は、このデバイスに対する以後の CPE プロトコルのインタラクションを、RDU から独立して処理するようにプログラムされています。デバイスがネットワークに追加され、そのデバイスの構成が生成された場合、デバイスがブートすると、DPE は、事前登録されたデバイスとのインタラクションを開始できます。
6. デバイスとのインタラクションにおいて、追加情報を検出して RDU に転送することができます。この場合、RDU では、新しい構成を生成してすべての DPE に転送することがあります。
セルフプロビジョニングされたデバイスのワークフロー
この項では、セルフプロビジョニングされたデバイスのワークフローについて説明します。図4-3 は、一般的な初期設定フローを示しています。
図4-3 初期デバイス設定のワークフロー：セルフプロビジョニング モード
1. BAC API から RDU に、さまざまなデバイス タイプ用に特別に定義された構成およびルールが読み込まれます。
（注） CPE を事前設定すると、API を介して BAC にデバイス情報（MAC アドレス、サービス クラスなどの）が読み込まれます。セルフプロビジョニング モードでは、ネットワーク上でデバイスがブートしてからこの処理が行われます。
2. ブート時に、デバイスは自分のプロビジョニング グループを検出し、プロビジョニング グループの DPE に対して自動プロビジョニング フローを開始します。Cable Modem Termination System（CMTS; ケーブル モデム ターミネーション システム）がブロードキャスト トラフィックを DHCP サーバにリレーします。DHCP サーバまたは Network Registrar DHCP サーバ上の BAC 拡張が DPE に構成を要求します。
（注） デバイスがローミング モードを使用して新しいプロビジョニング グループに移動した場合は、前に属していたプロビジョニング グループから古い構成が削除される点を除き、同じフローがデバイスに対して実行されます。
3. DPE は、デバイス要求を受信すると、キャッシュにデバイスの構成があるかどうか検索します。デバイスはこれまでこのプロビジョニング グループと交信したことがないため、構成は見つかりません。次に、プロビジョニング グループ内の Network Registrar 拡張が、RDU にデバイスの構成を生成するように要求します。
RDU で要求処理にかかる時間によっては、プロビジョニング グループがデバイス要求に応答しないことを決定する場合もあります。
4. RDU が、デバイスに適した構成を生成します。生成される構成では、DHCP 検出など、さまざまな CPE プロトコル イベントに対する DPE 応答が指定されます。
5. デバイス構成が DPE に転送され、そこでキャッシュされます。この段階で、DPE は、このデバイスに対する以後の CPE プロトコルのインタラクションを、RDU から独立して処理するようにプログラムされています。デバイスがネットワークに追加され、そのデバイスの構成が生成された場合、デバイスがブートすると、DPE は、事前登録されたデバイスとのインタラクションを開始できます。
6. デバイスとのインタラクションにおいて、追加情報を検出して RDU に転送することができます。この場合、RDU では、新しい構成を生成してすべての DPE に転送することがあります。
構成の更新ワークフロー
この項では、デバイス構成が更新されたときのワークフローについて説明します。
図4-4 に、以前に設定されたデバイスの構成を変更した場合の一般的な設定ワークフローを示します。
1. BAC API から、RDU のデバイス構成が更新されます。
2. RDU はデバイスの構成を生成して、デバイスが属するプロビジョニング グループの各 DPE に配信します。
デバイスの無差別アクセス権
この項では、無差別アクセス権が与えられているデバイスの構成の制御に使用されるオブジェクトとプロパティについて説明します。
デバイスは、BAC に事前登録されていなくても、ブートと設定が許可されていれば、無差別アクセス権が与えられます。無差別アクセス権は通常、登録済みの DOCSIS モデムの背後にあるコンピュータなどのデバイスに使用されます。登録済みの DOCSIS モデムの背後にある不明なデバイスに対して無差別アクセス権がイネーブルになっていない場合、そのデバイスはデフォルトのサービス レベルを受け取ります。
デバイスに無差別アクセス権を付与するには、次の操作を実行する必要があります。
• 所定のタイプの不明なデバイスに対して、無差別ポリシーをイネーブルまたはディセーブルにします。無差別アクセス権がイネーブルになっているデバイスは、デフォルト構成を受け取るのではなく、ポリシーに従って設定されます。
• デバイスが無差別アクセス権の付与対象である場合、所定のタイプの不明なデバイスを対象としたサービス クラスを指定します。
• デバイスが無差別アクセス権の付与対象である場合、所定のタイプの不明なデバイスを対象とした DHCP 基準を指定します。
無差別アクセス権の設定
表4-4 に、デバイスの無差別ポリシーを設定する方法を示します。
（注） 特定のモデムなどのデバイスに、無差別ポリシーを直接設定することはできません。
無差別アクセス権とプロパティ階層
BAC では、複数のオブジェクトに対して無差別ポリシーを設定できます。したがって、優先される設定値を理解することが重要です。ポリシーがプロパティを使用して設定されるのに対し、プロパティの優先度は BAC プロパティ階層によって決まります。プロパティ階層内で特定のプロパティを持つ最初のオブジェクトによって、BAC が使用する値が決まります。
BAC は、デバイスのリレー エージェントのプロパティ階層内で無差別ポリシーのプロパティを検索します。たとえばコンピュータの場合、BAC は、コンピュータのリレーとして機能するケーブル モデムのプロパティ階層内で無差別ポリシーの設定値を検索します。プロパティ階層の詳細については、「プロパティ階層」を参照してください。無差別ポリシーの詳細については、「無差別ポリシー設定のプロパティ」を参照してください。
（注） テクノロジー デフォルトを使用して無差別アクセス権を設定すると、対象となるデバイス タイプではなく、リレー エージェントに関連付けられたオブジェクトにプロパティを設定する必要があります。たとえば、DOCSIS モデムの背後にあるコンピュータに対して無差別アクセス権をイネーブルにするには、コンピュータのテクノロジー デフォルトではなく、その DOCSIS モデムのテクノロジー デフォルトへの無差別アクセス権をイネーブルにします。
無差別ポリシーのプロパティではデバイス タイプごとに、サービス クラスと DHCP 基準を指定し、また無差別アクセス権をイネーブルまたはディセーブルに指定します。デバイスで無差別モードがイネーブルになっているにもかかわらず、デバイスのリレー エージェント階層の検索で、サービス クラスまたは DHCP 基準のプロパティに一致するものが検出されない場合、非無差別アクセス権のデフォルトのサービス クラスまたは DHCP 基準が使用されます。たとえば、BAC がコンピュータに無差別アクセス権を付与するように設定されているが、無差別のサービス クラスまたは DHCP 基準（あるいはその両方）を見つけられない場合、コンピュータに対してデフォルトのサービス クラス、DHCP 基準、またはその両方が使用されます。
サービス クラスと DHCP 基準のデフォルトは、次のプロパティを使用して、対象デバイス（リレー エージェントではなく）のテクノロジー デフォルトに設定されます。
• サービス クラス： /default/classOfService
API 定数は TechnologyDefaultsKeys.DEFAULT_CLASS_OF_SERVICE です。
無差別モードのデバイス用構成の生成
• デバイスが最初にオンラインになり、無差別アクセス権が与えられた。
• 最新ではなくなった DPE がキャッシュを読み込み中で、特定のプロビジョニング グループの構成を要求した。
• API コール regenConfigs でデバイス構成の再生成が明示的に要求された。
• 無差別アクセス権を持つデバイスのリレー エージェント デバイスの構成が再生成中である。
• 無差別ポリシー（またはその他の設定）が変更されたために、BAC Configuration Regeneration Service（CRS; 構成再生成サービス）が影響を受けるデバイスの構成を再生成する必要が生じた。
無差別モードのデバイスの構成が再生成されるたびに、新しく設定された無差別ポリシーが使用されます（たとえば、無差別モードのコンピュータに現在指定されているサービス クラス）。ただし、デバイスが無差別モードのデバイスとしてオンラインになった後に API を介してそのデバイスのサービス クラスまたは DHCP 基準が変更された場合、それ以降、そのデバイスは無差別とは見なされず、無差別ポリシーに変更を加えても影響を受けません。デバイスはそれ以降、登録済みと見なされます。
無差別ポリシー設定のプロパティ
デバイスに無差別アクセス権を設定するには、BAC がサポートする特定のデバイス タイプに関連付けられたプロパティを設定する必要があります。デバイス タイプに対して無差別アクセス権をイネーブルまたはディセーブルにできます。
• Enabled： 表4-4 に示す API コールに関連付けられたスコープ内で、デバイスの無差別アクセス権をイネーブルにします。
• Disabled：無差別アクセス権をディセーブルにします。プロパティが存在しない場合、Disabled 設定がデフォルトになります。
無差別アクセス権を設定するプロパティのリストについては、 表4-5 を参照してください。
無差別ポリシーのプロパティは、読み取り/書き込みプロパティと読み取り専用のプロパティに分かれます。この項では、読み取り/書き込みプロパティと読み取り専用プロパティについて説明します。これらのプロパティには、デバイスの無差別アクセス権をイネーブルにするために設定が必要なものと、デバイスのサービス クラスと DHCP 基準を選択するために設定するものがあります。
読み取り/書き込みプロパティ
（注） この項で説明するすべてのプロパティに適用可能な API コールについては、表4-4 を参照してください。
表4-5 に、無差別アクセス権をイネーブルにするために使用できるプロパティを示します。
表4-6 に、無差別アクセス権を付与されたデバイスのサービス クラスを選択するために設定が必要な読み取り/書き込みプロパティを示します。
表4-7 に、無差別アクセス権を付与されたデバイスの DHCP 基準を選択するために設定が必要な読み取り/書き込みプロパティを示します。
読み取り専用プロパティ
表4-8 に、デバイスのサービス クラスと DHCP 基準を選択するために設定が必要な読み取り専用の無差別プロパティを示します。これらの読み取り専用プロパティは、前の項で指定した読み取り/書き込みプロパティと合せて、現在のシステム構成を判別するのに役立ちます。
無差別モードのデバイスのカスタム ポリシー
前の項で指定したプロパティを使用して、デバイスの無差別ポリシーを設定できます。ただし、追加のロジックが必要な場合は、拡張とカスタム プロパティを使用してカスタム ロジックを実装できます。カスタム プロパティを使用すると、新しいプロパティを定義できます。定義されたプロパティは、API を介して任意のオブジェクト上に格納することができます。
無差別モードのデバイスのポリシーを強化するために、次の拡張を使用できます。
• デバイス検出：デバイスのテクノロジー タイプを判別します（通常は DHCP 要求データに基づく）。この拡張が検出した情報は、Device Detection Context に追加され、他の拡張から使用できるようになります。
• サービス レベル選択：デバイスに対して適切なサービス クラス オブジェクトおよび DHCP 基準オブジェクトを選択します。無差別ポリシーのプロパティによって、無差別アクセス権を持つデバイスのサービス クラスおよび DHCP 基準が決まります。
• 構成生成：デバイスと、必要に応じてその背後にあるデバイスの構成を生成します。サービス レベル選択拡張が選択したポリシーに基づいて、リレー エージェントの背後にある無差別モードのデバイスの構成が再生成されます。リレー エージェントの背後にあるデバイスの構成を再生成するデフォルトの動作を強化する場合だけ、拡張の変更が必要になることがあります。
フィードバック