OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

1. 背景・目的
DOCS-CABLE-DEVICE-MIBは、CMTS/CM内に発生した各種DOCSISイベントの取り扱い
を定義・設定する目的で策定された技術規格であり、DOCSIS1.0での標準化以来、継続して全バージョンのDOCSIS OSSIに定義されている。
DOCSISネットワークの状態監視では、ヘッドエンド側に配置されたNMSから各CMTS/CMを
定期ポーリングする手法が、通信負荷の適切な分散制御や死活監視の観点上合理的であり比較的普及・一般化しているが、例えばロードバランシング構成時の上りチャンネル切り替
わり等、CM内部で不定期に発生するリブートを伴わない何らかの状態変化イベントの種類
別発生履歴を長期に亘って集計したい場合、現在状態値の定期ポーリング方式では実行間隔によっては発生イベントを取り逃がす可能性を排除できない。現在状態値ではなくイベ
ントログを収集する方法も考えられるが、CMイベントログテーブルの最小サイズは僅か 10 であり、皮肉な事に不安定なCMほど収集間隔で 10 を超えるイベントが生じる確率が高く、結果として状態値収集と同様、履歴の不完全性を排除できない。
DOCS-CABLE-DEVICE-MIBにより、従来の「上から下」の定期ポーリング方式に「下から上」のイベント通知方式を併用すれば、「上から下」の特長である効率的なCM死活監視に加え、状態履歴の不完全性をある程度改善できる。
各種DOCSISイベントの通知プロトコルには、SNMP v1/v2c/v3 Trap/Inform又はSyslogを選択的に使用できる。プロトコル選択や対象イベント定義等の動作設定は、DOCSIS規格では
上位NMS（SNMPマネージャー）によるSNMP Setコマンドを介して行う前提で設計されているが、等価な内容をCMコンフィグファイルに静的に定義する事も可能であり、実商用環境では後者の方がよりポピュラーである。
本Tipsでは、CMのイベントログ管理仕様、DOCS-CABLE-DEVICE-MIBの概要、MIBオブ
ジェクトの構造、対象イベント、CMコンフィグファイルへの定義方法、及び、NMSへの応用方式案について説明する。

2. 対象読者
CATV事業者、システムインテグレーター、ネットワーク管理者

3. 参考文献・関連文書
CM-SP-CM-OSSIv3.1-I20-210716.pdf ( 以降、「CM-OSSI」)
CM-SP-MULPIv3.1-I22-211110.pdf ( 以降、「MULPI」)
RFC4639 Cable Device Management Information Base for Data-Over-Cable Service
Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem
Termination Systems, December 2006.( 以降、「RFC4639」)

4. その他
本Tips中の図表番号につき、参考文献・関連文書からの抜粋には原文の番号をそのまま流用、一方で独自に作成した図表には ”Tips-*” の形式で番号を付与した。

5. 最終更新日
2021 年 11 月 27 日

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
1 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6. 詳細
6.1 CM のイベントログ管理仕様
CM内で発生した各種のイベントは、以下の何れかの方法により管理される。
(1) イベントログテーブルへの内部書き込み
CMは自身の揮発・不揮発メモリに「イベントログテーブル」(docsDevEventTable）を持ち、イベント発生の度にレコードを都度追加する。
DOCSIS規格上のイベントログテーブルの最小サイズは 10 行、実際のサイズはベンダー依存でまちまちであり、FIFO方式で古いものから順に削除される。
(2) Syslogサーバーへのメッセージ送信
CMはCMコンフィグファイルに設定記述されたSyslogサーバーにメッセージを送信する。
メッセージ形式と各項目の説明、メッセージ例を以下に示す。
【メッセージ形式】<レベル>CABLEMODEM[vendor]: <イベントID> テキスト ベンダー独自テキスト【項目説明】
レベル
ファシリティ128(CM本体の意味)にイベントプライオリティ0~7を加算した128~135の範
囲の整数値。.
イベントID
イベントの種類を一意に表す32ビット正整数値で、8桁固定長の十進表現。
DOCSISエラーコードと一意に対応（例: D04.2が 68000402）。
テキスト
CM-OSSI Annex Cに定義されている225文字以下の文字列。
ベンダー独自テキスト
オプションフィールド。

【メッセージ例】<132>CABLEMODEM[DOCSIS]: <68000402> ToD Response received - Invalid data format(3) 上位 NMS へのSNMP 通知
CMは予め指定されたSNMPマネージャーにSNMP Trap/Informを送信する。
SNMP通知の内容は、Syslogメッセージと概ね等価である。
（例：Syslogの「レベル」がRFC4639
SNMPの”docsDevEvLevel”に、「イベントID」が”docsDevEvId”に相当）【メッセージ例】
SNMP CVC Validation Failure SNMP Manager:
10.50.1.11;CM-MAC=00:22:ce:03:f4:da;CMTSMAC=00:15:20:00:25:ab;CM-QOS=1.1;C
M-VER=3.0;
動作仕様はCMのSNMP動作モードで異なり、v1/v2c NmAccess モードのCMはv1/v2c
Trap、v1/v2c/v3 CoexistenceモードのCMはv3 Trap/Informを送信する。
NmAccessモードのCMコンフィグファイルにはdocsDevNmAccessTableのみ設定が記述され、Coexistenceモードの各関連TLVの設定は記述されない。
逆にCoexistenceモードのCMにはdocsDevNmAccessTableの設定は記述されず、代わりにsnmpCommunityTableを始めとするRFC標準の各MIBテーブルの設定が記述される。
3.0以前の各DOCSISバージョン互換性上の観点から、本TipsではNmAccessモード即ちSNMP v1/v2cのみを検討対象とし、SNMP v3は対象外としている。

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
2 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.2 DOCS-CABLE-DEVICE-MIB(RFC 4639) の概要
DOCS-CABLE-DEVICE-MIBの原型は、1999年8月に旧@Home（現Comcast Cable）により編纂・公開されたRFC2669である。
RFC2669はDOCSIS1.0
CMTS/CMのSNMPによる管理・制御を目的に設計され、その後2006年12月にComcast CableによりRFC4639に置換された。
RFC4639はmib-2グループ配下のdocsDev(69)グループのMIBツリー構造を定義しており、MIB定義の本体はdocsDevMIBObjectsグループ配下の6つのサブグループ（
docsDevBase, docsDevSoftware, docsDevServer, docsDevEvent, docsDevFilter,
docsDevCpe）とdocsDevNmAccessテーブルにより表現される。
RFC4639のMIBツリー構造をTips-6.2に示す。

Tips-6.2 RFC4639 MIBツリー構造
RFC4639の主用途はCMソフトウェア（ファームウェア）の遠隔更新だが、副次的にCMの状態
変化を上位NMSに通知する用途にも利用されている。
各グループ・テーブルの主な用途を以下に示す。
docsDevBaseグループ：
docsDevSoftwareグループ：
docsDevServerグループ：
docsDevEventグループ：
docsDevFilterグループ：
docsDevCpeグループ：
docsNmAccessテーブル：

CMリセット、最大CPE数制限
CMソフトウェア遠隔更新
DHCP, TFTP, Time等のアドレス情報管理（RO）
各種DOCSISイベントの管理と履歴保持
LLC,ToS等によるフィルター動作の定義
CPEのIPアドレスによるフィルター動作の定義
SNMP v1/v2c向け設定（NmAccessモード用）

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
3 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.3 MIBオブジェクトの構造
6.3.1 docsDevNmAccessテーブル
docsDevNmAccessテーブルのMIBオブジェクト構造をTips-6.3.1に示す。

Tips-6.3.1 docsDevNmAccessテーブルのMIBオブジェクト構造
テーブル内の各行は上位の各SNMPマネージャーを表す。
使用方法は、最初に関連付けたいSNMPマネージャー数だけ本テーブルに行を追加後、docsDevNmAccessIpとdocsDevNmAccessIpMask, docsDevNmAccessCommunityに各
SNMPマネージャーのIPアドレスとサブネットマスク、コミュニティ名を登録する。次に、各
SNMPマネージャーへのアクセス許可種別をdocsDevNmAccessControlで選択する。監視目的には4: roWithTrapsか6: trapsOnlyが一般的に使われる。
SNMP v1/v2cトラップPDUの選択にはdocsDevNmAccessTrapVersionが使われ、1を設定
時にv1トラップ、2を設定時にv2cトラップが送信される。

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
4 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.3.2 docsDevEventグループ
docsDevEventグループのMIBオブジェクト構造をTips-6.3.2に示す。

Tips-6.3.2 docsDevEventグループのMIBオブジェクト構造
docsDevEvControlテーブル内の各行は、各イベントのプライオリティと管理方法の対応関係を定義する。docsDevEventテーブルは、発生したイベントを行単位で格納する履歴テーブルである。
Syslogの宛先アドレスは、CMコンフィグファイルのSyslog定義と同じ内容をdocsDevEvSyslogAddressに定義する。
文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
5 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.4 対象イベント
6.4.1 プライオリティ
RFC4639では以下8つのプライオリティを定義している。
(1) 緊急（Emergency, priority=1）
ログ管理機構のリブートを伴う機種固有のH/W, S/W障害。メモリー障害等。
(2) アラート（Alert, priority=2）
ログ管理機構のリブートを伴う緊急以外の障害。
(3) 深刻（Critical, priority=3）
ログ管理機構のリブートを伴わない深刻な障害。DHCP失敗等。
(4) エラー（Error, priority=4）※デフォルトでのSyslog,SNMPの通知対象
通信の瞬断等を生じるがCMの再登録（再起動）にまでは至らない障害。
(5) 警告（Waring, priority=5）
通信の瞬断等を生じるCMTS/CMの双方が把握できる障害。
デフォルトではSyslog,SNMPの通知対象外。
(6) 通知（Notice, priority=6）※デフォルトでのSyslog,SNMPの通知対象
重要だが障害ではない事象。S/Wアップグレード成功等。
(7) 参考情報（Informational, priority=7）
あまり重要でなく障害でもないが運用に有用な情報。
(8) デバッグ（Debug, priority=8）
ベンダー固有の深刻でない事象向け。
6.4.2 種類
CMが生成する全てのDOCSISイベントは、CM-OSSI の Annex C に定義されている。
NMSによるSyslogメッセージ又はSNMP通知の受信上の観点から、状態監視に有用と「思われる」（即ち、実機検証が必要な）各DOCSISイベントをTips-6.4.2に示す。
動作

プライオリティ

メッセージ

エラーコードイベントID

備考

DBC & DCC関連
DCC要求

Informational

DCC depart old<TAGS>

C202.067020200

CM機種依存DCC要求

Informational

DCC depart new<TAGS>

C203.067020300

同上

Error

RCS Primary DS Failure<TAGS>

T06.0

84000600

NoticeCM-STATUS message sent. Event
Type Code: <P1>; Chan ID: <P2>;
DSID: <P3>; MAC Addr: <P4>;
OFDM/OFDMA Profile ID:<P5>.<TAGS>

J101.074010100

下りCH取得動作
下りCH取得CM状態
CM状態

プロファイル変化
DS変化

NoticeDS profile assignment change. DS
Chan ID: <P1>; Previous Profile:<P2>; New Profile: <P3>.<TAGS>

C616.067061600

OFDMプロファ
イル

US変化

NoticeUS profile assignment change. US
Chan ID: <P1>; Previous Profile:<P2>; New Profile: <P3>.<TAGS>

C616.167061601

同上

Tips-6.4.2 NMSに有用なDOCSISイベント一覧

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
6 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.4.3 特定イベントIDの個別指定
CM-OSSI Annex F 2.3.6には、プライオリティ単位のような大雑把な集合単位でなく、”
CmEventCtrl”オブジェクトにより特定イベントIDを個別にSyslog又はSNMP通知するように設定できそうな記述が存在する。該当箇所の原文は以下の通りである。
“Additionally, if The CmEventCtrl object contains configured instances with non-zero
Event IDs, events matching the Event Ids configured in the object are sent according to
the settings of the docsDevEvReporting object; i.e., Traps, Syslog, etc.”
原文中の”CmEventCtrl”は、DOCS-IF3-MIBのdocsIf3CmEventCtrlテーブルに相当する。
DOCS-IF3-MIBのdocsIf3CmEventCtrlテーブルの項目定義をTips-6.4.3に示す。
ObjectCM

AccessdocsIf3CmEventCtrlTable

M

N-Acc

docsIf3CmEventCtrlEntry

M

N-Acc

docsIf3CmEventCtrlEventId

M

N-Acc

docsIf3CmEventCtrlStatus

M

RC

Tips-6.4.3 docsIf3CmEventCtrlテーブルの項目定義（CM-OSSI Annex A）
同テーブルのインデックスは”EventId”であり、”Status”はシンタックスが”RowStatus”、MIBの
Descriptionには"The status of this instance."とのみ記述されている。
”Status”のAccessがROではなくRC即ちRead Create属性になっており、管理者が自由に行を追加できそうなあたりが本テーブルの使い方を暗示しているようにも思われるが、具体的な使用方法の記述がないため使い方が不明である。
上述の原文中にはまた、”docsDevEvReporting object”の設定に従い、該当イベントIDがTrapやSyslogにより送信される旨の記述が存在する。
しかしながら”docsDevEvReporting”は、DOCS-IF3-MIBではなくRFC4639のdocsDevEvControlテーブルの項目であり（Tips-6.3.2を参照）、Priority毎に生成されたインスタンス各行にイベントの通知方法を割付ける目的に使われる性質の項目であるため、イベントID毎のイベント通知方法の割付目的には使えない。
このように、CM-OSSIとRFC4639の情報のみでは特定イベントIDの個別指定方法は不明であり、指定可否の判断には、実機によるdocsIf3CmEventCtrlテーブルの調査が望まれる。
具体的には、先ず対象機種の実機CMに対し、上述の2テーブルを対象にSNMP Getを実行し、デフォルトでの格納内容を把握する。
次に、同CMに対し、SNMP Setでイベント通知動作の設定を試みる。具体的には、プライオリ
ティ別及びイベントコード別にイベント選別基準を設定できるか検証する。
次に、実機CMがCMイベント受信サーバーに対し、対象イベントを設定通りに送信できるかを確認する。
以上の確認結果に基づき、現実的なイベントIDの指定方式を最終的に決定すべきである。

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
7 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.5 CMコンフィグファイルへの定義方法(1) DOCSIS技術規格文書内の関連情報（MULPI Annex C.1.2.5の抜粋抄訳）
イベントログの管理方法は、CMの docsDevEvControlTable への SNMP Set コマンド実行、またはCMコンフィグファイルの TLV-11としての記述で選択的に指定できる。
TLV-11の記述形式は、以下の通りである。
Type
11

LengthN

Valuevariable binding

Valueは、RFC1157に定義されるSNMP VarBindである。
VarBindはASN.1でエンコードされ、SNMP Setリクエストの相当部分と同様に取り扱われる。
CMは本オブジェクトの記述内容を、上位NMSから発行されたSNMP Setリクエストと同様に取り扱う。
TLV-11による記述内容は、Setの実行権限を持つ主体からのリクエスト相当として認証・実行される。
TLV-11として記述したSNMP Setリクエスト相当に対するSNMP Setレスポンスは、CM側からは特に生成・出力されない。
CMコンフィグファイルには複数のTLV-11を記述できるが、これらは全てCMにとり同時実行相
当として扱われ、ファイル中の記述順序は意味を成さない。
VarBindの最大文字数は、255バイトである。
(2) 具体的な使い方
実機CMに対して先ずSNMP
Setでイベント通知動作を設定する。具体的には、プライオリ
ティ別又はイベントコード別にイベント選別基準を設定する。
次に、実機CMがレシーバーに対し、対象イベントを仕様通りに送信する事を実験室レベルで確認する。
SNMP
Setによる操作内容を一旦確定後、MIBブラウザやnet-snmpのデバッグ機能等でVarBindの中身をASCII文字列として抽出し、これを上述のTLV-11としてCMコンフィグファイ
ルに記述する。
CMコンフィグファイルの更新後、対象CMを再起動し、対象CMがSNMP Setによる設定と同様のイベント通知動作を実行する事を実験室レベルで確認する。
実験室レベルでの動作確認後、対象の商用環境にCMイベント受信サーバーを適宜構成
し、TFTPサーバー内の各CMコンフィグファイルにTLV-11を追記更新、商用環境の各CMの動作設定を個別・段階的に変更する流れとなる。

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
8 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.6 NMSへの応用方式案
6.6.1 Syslogの短所・長所CMが実装するRFC4639のSyslogは、約20年前に策定されたオリジナルのRFC3164、即ちBSD Syslogであり、ポート番号にはUDP514が使用される。
BSD SyslogはUDPベースのメッセージング即ちackを返さない通信プロトコルであり、ネット
ワーク障害による一時的な通信断に起因する欠損や、経路又は受信側のシステムリソース
不足に起因する取りこぼし等の可能性を原理上排除できない。
昨今のLinuxディストリビューションでは、BSD
Syslogの潜在的な問題点を解消すべく、
rsyslogやsyslog-ng等、TCPベースのSyslog通信が可能な改良版Syslogが普及しているが、CMにTCPベースの通知処理を組み込むとCM側の負荷増大が懸念される事、状態監視用途であれば多少の欠損は運用上の許容範囲内と見なされる場合が多い事から、
CM-OSSIでは依然としてBSD Syslogのままである。
逆に言うと若干の欠損可能性を許容できるならば、BSD SyslogにはCM側の負荷が軽いという利点があり、CM-OSSIがBSD Syslogを採用している所以でもある。
6.6.2

SNMPの短所・長所
SNMP Trapの短所・長所は、6.6.1に示したBSD Syslogの短所・長所にほぼ等しい。
Trapではなく、Coexistenceモードから使用可能となった同期型通信方式のInformを使え
ば、Ackに基づく再送やタイムアウト制御が可能となるため、Trap（とSyslog）の欠点である欠損リスクを低減できる可能性がある一方で、CM側の負荷が重くなる恐れがある。
利用目的を状態監視に限るのであれば、多少の履歴欠損があってもある程度の傾向分析
は可能な筈と割り切り、同期型のInformよりも非同期型のTrapでCMの負荷軽減を図る方
が、システム全体の安定性向上の観点からはより現実的である。
なお日本市場では、KDDI社がケーブル光プラスサービスのEMTA位置移動検知目的にSNMP Trapを使用しており、同じSNMPという事で、何らかの設定が万が一被ると運用上の不都合を生じる恐れがある。従って日本市場に限っては、履歴の傾向分析による監視業務への応用が主目的であれば、原則的にはSNMPよりもSyslogを使う方が、潜在的な運用リス
ク低減上の観点からは、より合理的と思われる。

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
9 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

6.6.3

CMイベント受信部の構造方式案
CMイベント受信部の構造方式案をTips-6.6.3に示す。

Tips-6.6.3 CMイベント受信部の構造方式案
本方式案ではロードバランサーを介した複数レシーバーの並列構成により、高負荷なCMイ
ベント受信＆ログ書込処理を分散し、取りこぼしの低減を図っている。
CM台数の増加に応じ、ロードバランサーにはスケールアップ、レシーバーにはスケールアウ
トを段階的に行う。性能向上の観点から、レシーバーにはローカルキャッシュDBへの書込処理に非同期方式を設定できるアプリが望ましい。
6.6.4

履歴データ分析部の構造方式案
履歴データ分析部の構造方式案をTips-6.6.4に示す。

Tips-6.6.4 履歴データ分析部の構造方式案
本方式案ではインターネットを介した複数ローカルキャッシュDB内データからステージング
DBへの大量履歴データの非同期集約＆長期蓄積を前提に、所謂ビッグデータ解析目的のシステム構成を想定している。
履歴データ分析部を例えばクラウド等に配置、複数CATV局の履歴データを集約管理、分析アプリへのログイン権限をサブスクリプション形式で提供、各事業者が自局の個人情報の漏洩なしに集計・分析手法等のノウハウを相互利用できる仕組みを構築できれば、事業者横断的なナレッジベースサービスを提供できる。

文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
10 / 11

OPEN STM Tips

DOCS-CABLE-DEVICE-MIB の使い方

NMS/STMとの統合方式案
NMS/STMとの統合方式案をTips-6.6.5に示す。

6.6.5

Tips-6.6.5 NMS/STMとの統合方式案
Tips-6.6.5は、「上から下」の定期ポーリング方式のNMS/STMに当社製品のTIMS Net/AEを仮定、これに「下から上」のイベント通知方式である本TipsのCMイベント受信部と履歴データ
分析部を統合した場合のシステム構成方式案である。
CMイベント受信部のローカルキャッシュDBに保存された過去ログは、CMイベント受信部のAPI経由でTIMS Net UIに表示される。
CMイベント受信部のローカルキャッシュ保持期間を超える長期間の履歴データは、蓄積
データ分析部のステージングDBに転送され、分析アプリのUIで可視化される。
CM絞り込み検索後に特定CMの履歴を分析したい場合、TIMS Net UIの何らかの画面操作により分析アプリのUIに遷移する。
ノード・MDU等を切り口に複数CMイベント履歴の共通傾向を集計・分析したい場合、設備管理DBからの取込情報に基づき、分析アプリUIで集計・分析を行う。
6.6.6 留意事項
(1) CMコンフィグファイル解釈のCM機種差
CMコンフィグファイルの解釈は、CMの機種・S/Wバージョンにより異なる可能性がある。この
ため実際の運用に際しては、事前に実験室レベルで、機種・S/Wバージョン別に動作検証を行う事が望ましい。
因みにTLV-11の記述内容に誤りがある場合、当該内容はCMにより無視される。このため、本Tipsで示したTLV-11の追加が既存サービスの停止やデグレ等、現場の運用に混乱来す事
態は、原則的にはあり得ない。
(2) docsDevEvControl, docsIf3CmEventCtrl両テーブルの実装挙動のCM機種差
6.4.3で述べた通り、MULPI、CM-OSSI及び、関連MIBファイルのDescription中の両テーブ
ルに関する記述の不完全・不明瞭により、両テーブルの挙動には潜在的な機種差が内在する可能性がある。このためCMコンフィグファイルの解釈同様、実運用に先立ち、実験室レベ
ルで機種・S/Wバージョン別に実機検証を行う事が望ましい。
(3) イベントID解釈のCM機種差
6.4.2に示した各イベントIDの解釈、即ち、実挙動とイベント通知の判断基準がCM機種毎に異なる可能性がある。このためCMコンフィグファイルの解釈同様、実運用に先立ち、実験室レベルで機種・S/Wバージョン別に実機検証を行う事が望ましい。
以上
文書番号: OSSBN-TIPS-21-11-001/01
All Rights Reserved, Copyright © OSS BroadNet 2021
11 / 11