Cisco Broadband Access Center アドミニストレータ ガイド Release 4.0

デバイス構成の生成

デバイスはブート時に、BAC に構成を要求します。この構成がデバイスのサービス レベルを決定します。この処理中、DHCP サーバは RDU にデバイスの構成を作成するように要求します。RDU は構成を生成して、そのデバイスが属するプロビジョニング グループにサービスを提供するすべての DPE に転送します。これで、DPE は RDU にアクセスしなくてもデバイスに構成を提供できるようになります。

デバイス構成には、ユーザが必要とする次のプロビジョニング情報を含めることができます。

• DHCP IP アドレス選択

• 帯域幅

• データ レート

• フロー制御

• 通信速度

• サービス レベル

構成には、任意のデバイスの DHCP 構成と TFTP ファイルを含めることができます。プロビジョニングされていないデバイスをインストールしてブートすると、デフォルトのテクノロジー固有の構成が割り当てられます。BAC がサポートするテクノロジーごとにデフォルト構成を変更できます。

RDU は、次の場合にデバイスの構成を再生成します。

• デバイスのサービス クラス変更など、特定のプロビジョニング API コールが実行された場合。

• 構成の検証が失敗した場合。デバイスから送信された DHCP 要求の特定のパラメータが最初の要求パラメータと異なる場合などに発生します。

• DPE がキャッシュへの再読み込みを行った場合。

RDU がデバイスの構成を再生成するたびに、更新された構成が該当する DPE に転送されます。

サービス レベル選択

サービス レベル選択の拡張ポイントは、RDU がデバイスの構成を生成するときに使用する DHCP 基準とサービス クラスを決定します。RDU は、この情報をデバイスごとにデータベースに保存します。

RDU がデバイス構成の生成に使用する DHCP 基準とサービス クラスは、デバイスに付与されているアクセス権のタイプに基づきます。デバイスのアクセス権には次の 3 つのタイプがあります。

• デフォルト：デフォルト アクセス権を付与されているデバイスの場合、BAC はデバイス タイプに割り当てられているデフォルトのサービス クラスと DHCP 基準を使用します。

• 無差別：無差別アクセス権を付与されているデバイスの場合、BAC はそのデバイスが背後にあるリレー エージェントからサービス クラスと DHCP 基準を取得します。

• 登録済み：登録済みアクセス権を付与されているデバイスの場合、BAC は RDU データベース内にある、デバイスの登録済みサービス クラスと DHCP 基準を使用します。

デバイス タイプごとに必ず 1 つのデフォルト拡張が存在している必要があります。

Configuration > Defaults のデフォルト ページを使用して特定のテクノロジーのサービス レベル選択の拡張ポイントを入力できます。詳細については、「デフォルトの設定」を参照してください。デフォルトでは、これらのプロパティにゼロまたは組み込み拡張の 1 つが入力されます。

デバイスは、DHCP 基準とサービス クラスのセットを 1 つ受け付けるように登録されていても、実際には 2 つ目のセットを選択する場合があります。構成生成の拡張は、選択された DHCP 基準とサービス クラスを検索して使用します。

サービス レベル選択拡張は、デバイスに対して指定された特定のルールに基づいて 2 つ目のサービス クラスと DHCP 基準を選択します。たとえば、特定のプロビジョニング グループ内のデバイスについて、特定のサービス クラスと DHCP 基準を割り当てるには、そのデバイスをブートするように指定する場合があります。

拡張は、DHCP 基準とサービス クラスの特定のセットがデバイスのプロビジョニングに選択される理由となる情報を返します。これらの理由は、View Device Details ページの管理者のユーザ インターフェイスで確認できます。

表2-1 に、これらの理由とその場合に付与されるアクセス権のタイプを示します。

表2-1 サービス レベル選択拡張がデバイスのアクセス権を決定した理由

理由コード	説明	付与されるデバイス アクセス権のタイプ
		デフォルト	無差別	登録済み
NOT_BEHIND_REQUIRED_ DEVICE	必要なリレー エージェントの背後にデバイスがありません。	P
NOT_IN_REQUIRED_PROV_GROUP	必要なプロビジョニング グループにデバイスが含まれていません。	P
NOT_REGISTERED	デバイスが登録されていません。	P
PROMISCUOUS_ACCESS_ ENABLED	リレー エージェントに対して無差別モードのアクセス権がイネーブルになっています。		P
REGISTERED	デバイスが登録されています。			P
RELAY_NOT_IN_REQUIRED_PROV_GROUP	必要なプロビジョニング グループにリレー エージェントが含まれていません。	P
RELAY_NOT_REGISTERED	リレー エージェントが登録されていません。	P
（注） これらの理由のほとんどは、登録済みまたは無差別のアクセス権を付与するための要件違反を示しており、結果としてデフォルト アクセス権が付与されています。

DPE のライセンシング

ライセンシングにより、ご使用になれる DPE（ノード）の数が管理されます。お持ちのライセンスより多くの DPE をインストールしようとすると、新しい DPE は RDU に登録されず、拒否されます。ライセンスされている既存の DPE は、オンラインのままになります。

（注） ライセンシングの目的上、登録済みの DPE は 1 つのノードと見なされます。

ライセンスの追加または評価ライセンスの延長を行った場合、または評価ライセンスが満了した場合、その変更はただちに有効になります。

RDU データベースから登録済みの DPE を削除すると、ライセンスは解放されます。DPE は RDU に自動的に登録されるため、ライセンスを開放する場合は DPE をオフラインにする必要があります。次に、管理者のユーザ インターフェイスまたは API を介して、DPE を RDU データベースから削除します。

削除した DPE は、属するすべてのプロビジョニング グループから削除されます。すべての Network Registrar 拡張に、その DPE が使用できなくなったことが通知されます。そのため、以前に削除された DPE が再度登録されると、再度ライセンスされたと見なされ、RDU から再度削除されるかライセンスが満了するまで、その状態が続きます。

RDU を使用してライセンスされていない DPE は、管理者のユーザ インターフェイスに表示されません。ライセンスの状態を判断するには、DPE と RDU のログファイルを調べる必要があります（ dpe.log と rdu.log ）。

（注） 特定のライセンスを介してイネーブルにした機能は、対応するライセンスがシステムから削除されても、引き続き動作します。

ライセンシングの詳細については、「ライセンスの管理」を参照してください。

TACACS+ および DPE 認証

TACACS+ は TCP ベースのプロトコルで、多くのネットワーク デバイスを対象とする中央集中型のアクセスと DPE CLI のユーザ認証をサポートします。

TACACS+ を使用して、DPE は複数のユーザをサポートできます。各ユーザ名とログイン パスワードおよびイネーブル パスワードは、TACACS+ サーバで設定されます。TACACS+ は、TACACS+ クライアント/サーバ プロトコルを実装するために使用されます（ASCII ログインのみ）。

TACACS+ 特権レベル

TACACS+ サーバは、TACACS+ プロトコルを使用して DPE にログインするユーザを認証します。TACACS+ クライアントは、そのユーザに設定される特定のサービス レベルを指定します。

表2-2 は、DPE ユーザのアクセスを許可するために使用される 2 つのサービス レベルを示します。

TACACS+ クライアント設定

TACACS+ は、CLI を使用して設定される複数のプロパティを使用します。TACACS+ に関するコマンドの詳細については、『 Cisco Broadband Access Center DPE CLI Reference 4.0 』を参照してください。

TACACS+ をイネーブルにする場合、管理者はすべての TACACS+ サーバの IP アドレスまたは Fully Qualified Domain Name（FQDN; 完全修飾ドメイン名）を、デフォルト値以外に指定する必要があります。

次の設定についても、該当する場合はデフォルト値を使用して指定できます。

• 各 TACACS+ サーバの共有秘密鍵。この鍵を使用して、DPE と TACACS+ サーバの間のデータを暗号化できます。特定の TACACS+ サーバの共有秘密情報を省略することを選択した場合、TACACS+ メッセージ暗号化は使用されません。

• TACACS+ サーバのタイムアウト値。この値を使用して、TACACS+ サーバがプロトコル要求に応答するのを TACACS+ クライアントが待機する最長時間を指定できます。

• TACACS+ サーバのリトライ回数。この値を使用して、TACACS+ クライアントが TACACS+ サーバとの有効なプロトコル交換を試行する回数を指定できます。

DPE と RDU 間の同期

DPE と RDU 間の同期とは、RDU との整合を取るために、DPE キャッシュを自動的に更新するプロセスです。DPE キャッシュは、デバイスの構成を含む構成キャッシュと、デバイスに必要なファイルを含むファイル キャッシュから構成されます。

通常、RDU は、構成の更新が含まれるイベントを生成し、関係するすべての DPE に送信して DPE を最新の状態に保ちます。同期が必要になるのは、接続の切断によって DPE 側でいくつかのイベントが欠落した場合です。切断の原因としては、ネットワークの問題、管理目的での DPE サーバのダウン、または障害などが考えられます。

また、同期は、RDU データベースをバックアップから復元するという特殊なケースでも使用されます。このケースでは、RDU との整合を取るために、DPE キャッシュのデータベースを古い状態に戻す必要があります。

RDU と DPE 間の同期プロセスは自動的に実行されるため、管理操作は必要ありません。同期プロセスの実行中でも、DPE は CPE に対してプロビジョニング操作や管理操作をすべて実行できます。

同期プロセス

DPE は RDU との接続を確立するたびに同期プロセスをトリガーします。

DPE は最初に起動したときに、RDU への接続を確立し、RDU に登録して構成変更の更新を受信します。次に、DPE と RDU が、ハートビート メッセージの交換を使用して、接続を監視します。DPE は、RDU への接続が切断されたと判断すると、接続の再確立を自動的に試みます。この試行は、成功するまでバックオフのリトライ間隔で続行されます。

RDU も、接続の切断を検出すると、DPE へのイベントの送信を停止します。接続の切断によって RDU からの更新イベントが DPE 側で欠落する場合があるため、DPE は、RDU との接続を確立するたびに同期を実行します。

一般的な DPE の状態

同期プロセス中、DPE は次の状態になります。

1. Registering：RDU との接続を確立して登録するプロセスの間、DPE は Registering 状態になっています。

2. Synchronizing：DPE は、必要な構成のグループを RDU に要求します。このプロセスの間、DPE は、ストレージ内の構成のうち、整合の取れていない（バージョン番号が間違っている）もの、欠落しているもの、および削除するものを判別し、必要であればキャッシュ内の構成を更新します。また、DPE は TFTP サーバに配信可能なキャッシュ内のファイルを同期します。DPE では、RDU が構成要求によって過負荷にならないようにするため、一度に 1 つのバッチだけを中央サーバに送信します。

3. Ready：DPE は最新の状態であり、RDU と完全に同期が取れています。通常 DPE はこの状態にあります。

表2-3 に、DPE に発生し得るその他の状態を示します。

（注） DPE の状態に関係なく、デバイス構成要求、TFTP 要求、および ToD 要求に引き続きサービスが提供されます。

DPE 状態は次の方法で表示できます。

• 管理者のユーザ インターフェイスから表示します。「Device Provisioning Engine の表示」を参照してください。

• show dpe コマンドを使用して DPE CLI から表示します。『 Cisco Broadband Access Center DPE CLI Reference 4.0 』を参照してください。

TFTP サーバ

統合された TFTP サーバは、デバイスおよびデバイス以外のエンティティから、DOCSIS 構成ファイルを含む、ファイル要求を受信します。その後、このサーバはファイルを要求元のエンティティに送信します。

TFTP サーバは、ローカル ファイルシステム アクセスに使用されるホーム ディレクトリにあります。ローカル ファイルは、 BPR_DATA/dpe/tftp ディレクトリに格納されています。このリリースでは、すべての配信可能な TFTP ファイルは、事前に DPE にキャッシュされます。つまり、DPE は常にシステム内のすべてのファイルが使用された最新の状態になっています。

（注） DPE での TFTP サービスには、要件に合せてサービスを設定できる機能があります。

デフォルトでは、TFTP サーバは TFTP 読み取りに対してキャッシュしか検索しません。ただし、DPE コマンドラインから service tftp 1..1 allow-read-access コマンドを実行すると、TFTP サーバはキャッシュの前にローカル ファイル システムを検索します。ファイルがローカル ファイル システムにある場合は、そこからファイルを読み取ります。ファイルがない場合、TFTP サーバはキャッシュを検索します。ファイルがキャッシュにある場合、サーバはそのファイルを使用し、キャッシュにない場合はエラーを返します。

ローカル ファイル システムからの読み取りアクセスをイネーブルにできる場合、ディレクトリ構造読み取り要求は、ローカル ファイル システムからだけ許可されます。

（注） すべての TFTP ファイルに一意の名前を指定します。ファイルを大文字と小文字を使用して区別しないようにしてください。DPE は、ローカル ディレクトリまたはキャッシュでファイルを検索するとき、すべてのファイル名を小文字に変換するため、ファイル名の文字は重要です。

IPv4 または IPv6 を使用する TFTP 転送を指定するには、DPE コマンドラインから service tftp 1..1 ipv4 | ipv6 enabled true コマンドを使用します。また、転送のブロックサイズを指定するには、 service tftp 1..1 ipv4 | ipv6 blocksize コマンドを使用します。blocksize オプションには、データ オクテットの数を指定します。これにより、クライアントとサーバが、ネットワーク メディアにより適したブロック サイズをネゴシエートできます。blocksize をイネーブルにすると、TFTP サービスは、要求されたブロック サイズが指定された上限と下限の間に収まっていれば、転送に使用します。詳細については、『 Cisco Broadband Access Center DPE CLI Reference 4.0 』を参照してください。

TFTP サービスは、TFTPv4 と TFTPv6 について、処理された TFTP パケット数の統計情報を保持しています。これらの統計情報は、Device Details ページの管理者のユーザ インターフェイスで表示できます。詳細については、「デバイスの詳細の表示」を参照してください。

ToD サーバ

BAC の統合された Time of Day（ToD）サーバは、RFC 868 の高性能 UDP を実装します。

（注） DPE での ToD サービスには、要件に合せてサービスを設定できる機能があります。

ToD サービスをイネーブルにして IPv4 または IPv6 をサポートするには、DPE コマンドラインから service tod 1..1 enabled true コマンドを使用します。デフォルトでは、ToD サービスは DPE でディセーブルになっています。

このプロトコルを DPE に設定するときには、プロビジョニング用に設定したインターフェイスにだけ ToD サービスはバインドされることに注意してください。ToD サービスの設定の詳細については、『 Cisco Broadband Access Center DPE CLI Reference 4.0 』を参照してください。

ToD サービスは、ToDv4 と ToDv6 について、処理された ToD パケット数の統計情報を保持しています。これらの統計情報は、Device Details ページの管理者のユーザ インターフェイスで表示できます。詳細については、「デバイスの詳細の表示」を参照してください。

DOCSIS 共有秘密情報

BAC では、Cable Modem Termination System（CMTS; ケーブル モデム ターミネーション システム）ごとに異なる DOCSIS Shared Secret（DSS; DOCSIS 共有秘密情報）を定義できます。このように定義すると、共有秘密情報が侵害されても影響を受ける CMTS の数が限られ、配備におけるすべての CMTS が対象となりません。

DSS は DPE ごとに設定できますが、プロビジョニング グループ単位で設定する必要があります。また、そのプロビジョニング グループで CMTS に設定されている内容と一致させる必要があります。

共有秘密情報はクリア テキスト文字列または IOS 暗号化文字列で入力できます。クリア テキストで入力する場合、DSS は IOS バージョン 12.2BC に適合するように暗号化されます。

また、管理者のユーザ インターフェイスまたは API を使用して、RDU から DSS を設定することもできます。この場合、DSS はクリア テキストで入力され、RDU に格納されて、すべての DPE に渡されます。そのため、このように入力された DSS は、DPE に保存される前に暗号化されます。

CLI から dpe docsis shared-secret コマンドを使用して直接 DSS を DPE で設定する場合、この設定は RDU から設定される内容よりも優先されます。

DOCSIS 共有秘密情報のリセット

DSS のセキュリティが侵害された場合、または単に管理目的で共有秘密情報を変更する場合は DSS をリセットできます。

DSS をリセットするには、CMTS CLI から show running-config コマンドを実行し、表示された設定から DOCSIS 共有秘密情報を DPE 設定にコピー アンド ペーストします。この方法で、Cisco CMTS に入力した設定を DPE CLI にコピーできます。

（注） 上記で説明されたように共有秘密情報を変更するには、CMTS は 12.2BC より新しいソフトウェア バージョンで実行されている必要があります。

DSS を変更するには、次の手順に従います。

ステップ 1 リセットする DOCSIS 共有秘密情報を持つプロビジョニング グループを確認します。

ステップ 2 そのプロビジョニング グループに関連付けられた DPE と CMTS のリストを調べます。

ステップ 3 CMTS 上でプライマリ DSS を変更します。

ステップ 4 CMTS 上で侵害された DSS をセカンダリ DSS に変更します。すべての DOCSIS 設定ファイルが新しい DSS を使用するように正しく変更されるまで、ケーブル モデムで登録を実行できるようにする必要があります。

ステップ 5 影響を受けた DPE を判別し、それぞれ DSS を変更します。

ステップ 6 DOCSIS 設定ファイルが新しい DSS を使用していることを確認してから、侵害されたセカンダリ共有秘密情報を CMTS 設定から削除します。

DHCP

DHCP サーバは、IP ネットワーク上で IP アドレスを設定するプロセスを自動化します。このプロトコルは、デバイスをネットワークに接続するときにシステム管理者が行う多くの機能を実行します。DHCP はネットワーク ポリシーの決定を自動的に管理するため、手動の設定が不要になります。これにより、ネットワーク デバイスの設定の柔軟性とモビリティが高まり、管理が容易になります。

このリリースの BAC は、IPv6 用の DHCP（DHCPv6 とも呼ばれる）をサポートします。DHCPv6 を使用すると、DHCP サーバは、拡張を介して設定パラメータを IPv6 ホストに配信できるようになります。IPv6 ホストは、デフォルトでステートレス自動設定を使用します。これは、IPv6 ホストがローカル IPv6 ルータを使用して独自のアドレスを設定できるようにするものです。DHCPv6 とは、このステートフル自動設定オプションのことで、サーバがホストに設定情報を設定する技術の 1 つです。

DHCPv6 には次の利点があります。

• IPv6 アドレスによるアドレッシング機能の拡張

• ステートフル自動設定プロトコルを使用した容易なネットワーク管理

• オプションと拡張のサポート向上

• リレー エージェント機能

• 1 つのインターフェイスへの複数アドレスの割り当て

DHCPv4 と DHCPv6 の比較

DHCPv6 は、DHCPv4 と同様にクライアント/サーバ モデルを使用します。DHCP サーバと DHCP クライアントは、IP アドレスの要求、オファー、およびリースを行うために一連のメッセージを交わします。DHCPv4 とは異なり、DHCPv6 は、一括して会話を行う場合、ブロードキャスト メッセージではなく、ユニキャスト メッセージとマルチキャスト メッセージの組み合せを使用します。

この他にも DHCPv4 と DHCPv6 には次のような違いがあります。

• DHCPv4 とは異なり、DHCPv6 の IPv6 アドレス割り当てはメッセージ オプションを使用して処理されます。

• DHCP 検出や DHCP オファーなど、DHCPv4 でサポートされていたメッセージ タイプが DHCPv6 では削除されています。代わりに、DHCPv6 サーバはクライアントの送信要求メッセージとその後に続くサーバのアドバタイズ メッセージによって検索されます。

• DHCPv4 クライアントとは異なり、DHCPv6 クライアントは複数の IPv6 アドレスを要求できます。

DHCPv4 フェールオーバーによって、DHCP サーバのペアは、片方が機能を停止したらもう一方が引き継ぐという方法で機能します。このサーバのペアは、メイン サーバおよびバックアップ サーバと呼ばれます。通常の状況では、メイン サーバがすべての DHCP 機能を実行します。メイン サーバが使用不能になると、バックアップ サーバが引き継ぎます。このように、DHCP フェールオーバーでは、メイン サーバに障害が発生しても DHCP サービスへのアクセスが失われないようにします。

DNS

DNS サーバは、IP アドレス、ホスト名など、ネットワーク全体のホストに関する情報を格納します。DNS は主に IP アドレスとドメイン名を変換するためにこの情報を利用します。www.cisco.com などの名前を IP アドレスに変換することで、インターネットベースのアプリケーションへのアクセスが簡素化されます。

リース クエリー

リース クエリー機能を使用すると、プロビジョニング グループ内の Network Registrar DHCP サーバに、現在の IP アドレス情報を直接要求できます。デバイスの IP アドレスを見つけるために、RDU は DHCP リース クエリー メッセージを、デバイスのプロビジョニング グループ内の DHCP サーバだけに送信し、ネットワーク上のすべての DHCP サーバにクエリーが送信されないようにします。すべての応答の中で、デバイスと最後に通信したサーバからの応答が信頼できる応答と見なされます。

以前のバージョンの BAC では、リース クエリー機能は、リース クエリー要求を送信するための送信元インターフェイスと送信元ポートの選択をオペレーティング システムに依存していました。このリリースでは、特定のインターフェイスと送信元ポートを使用するように RDU を設定できます。

このリリースの BAC でのリース クエリー サポートの詳細については、「リース クエリー」を参照してください。

プロビジョニング グループ

プロビジョニング グループは、通常 1 つ以上の DPE と DHCP サーバのフェールオーバー ペアで構成されるサーバを、論理的に（通常は地理的に）グループ化したものになるように設計されています。特定のプロビジョニング グループ内の各 DPE では、RDU からの同一の構成セットがキャッシュされます。その結果、冗長性とロード バランシングが可能になります。デバイスの数が増えたら、追加のプロビジョニング グループを配備に加えることができます。

（注） プロビジョニング グループのサーバは、各地域に設置する必要はありません。中央のネットワーク オペレーション センターに簡単に配備できます。

プロビジョニング グループでは、BAC 配備のスケーラビリティを拡張する手段として、各プロビジョニング グループをデバイスのサブセットだけに関連付けます。このようなデバイスのパーティション化では、デバイスを地域的にグループ化することや、サービス プロバイダーによって定義されたポリシー別にグループ化することができます。

サービス プロバイダーで配備を拡大するには、次の作業を行います。

• 既存の DPE サーバのハードウェアをアップグレードする。

• プロビジョニング グループに DPE サーバを追加する。

• プロビジョニング グループを追加する。

冗長性とロード シェアリングをサポートするために、各プロビジョニング サポートは任意の数の DPE に対応できます。DHCP サーバから要求が届くと、その要求はプロビジョニング グループ内の DPE 間に分配され、デバイスと特定の DPE の間にアフィニティが確立されます。プロビジョニング グループ内の DPE 状態が安定している限り、このアフィニティは保たれます。

静的プロビジョニングと動的プロビジョニングの比較

BAC は、デバイス構成を使用してネットワークにデバイスをプロビジョニングします。デバイス構成とは、テクノロジー タイプに基づいた特定のデバイスのプロビジョニング データです。BAC を使用したデバイスのプロビジョニング方法には、静的プロビジョニングと動的プロビジョニングの 2 つがあります。

静的プロビジョニング時には、BAC システムに静的設定ファイルを入力します。この設定ファイルは、構成を生成するために TFTP を介して特定のデバイスに配信されます。BAC は、静的設定ファイルをその他のバイナリ ファイルと同様に扱います。

動的プロビジョニング時にはテンプレートを使用します。テンプレートは、DOCSIS、PacketCable、または CableHome オプションと、特定のサービス クラスで使用されると動的にファイルを生成する値が含まれるテキスト ファイルです。動的設定ファイルを使用すると、プロビジョニング プロセス中の柔軟性とセキュリティが強化されます。

表2-4 に、それぞれのファイルを使用した静的プロビジョニングと動的プロビジョニングの影響を示します。

プロビジョニング グループの機能

配備にデバイスのサブセットをプロビジョニングするには、プロビジョニング グループによるそれらのデバイスのプロビジョニングが可能であり、かつイネーブルになっている必要があります。たとえば、DPE がこの機能をサポートするように設定されていない場合、プロビジョニング グループは PacketCable MTA を Secure モードでプロビジョニングできません。

以前のリリースの BAC では、プロビジョニング グループ内の各 DPE がサポートできる機能を起動時に RDU に登録していました。この情報が、プロビジョニング グループに含まれる他の DPE の情報と結合されて、グループがサポートできるデバイス タイプを決定していました。サーバは、その下位機能を登録し、またそれらの機能をイネーブルまたはディセーブルに登録しました。サーバの登録後、プロビジョニング グループは自動的にイネーブルになり、サポート可能なデバイス タイプをサポートしていました。一方、このリリースの BAC では、次のように手動でデバイス サポートをイネーブルにする必要があります。

• Provisioning Group Details ページの管理者のユーザ インターフェイスを使用します。「プロビジョニング グループの表示」を参照してください。

• API で ProvGroupCapabilitiesKeys 定数を使用します。詳細については、API Javadoc を参照してください。