Status: pending implementation. Last revised: Nov 15 2010
Torrus has already got templates and the discovery engine for DOCSIS CMTS monitoring. This draft explains also the approach to monitoring network parameters on each individual modem in the cable network.
The Docsis provisioning system contains a complete list of valid CM MAC addresses. Also the DHCP server contains IP addresses assigned to those modems which are online or those which were online before the leases timed out.
As the list of valid CM MAC addresses is relatively stable and independent from modem online status, it should be taken as the primary reference for all monitored modems in Torrus.
Torrus needs also CM IP addresses in order to access their statistics.
We assume that the CM IP lease time is long enough, and is more than two times longer than the Torrus import and re-discovery interval.
In order to import the CM data into Torrus, a new tool should be developed. It should accept various forms of tabular input (plain text, JSON, YAML, direct SQL access, etc.). The tabular data input defines a number of attributes for each modem, as follows:
[Mandatory] A unique modem MAC address (/^[0-9a-f]{12}$/)
[Optional] CM management IPv6 address
[Optional] CM management IPv6 address
[Optional] Unique Service ID. If undefined, CmMacAddress is taken as the
Service ID value. This identifier is used as a base for nodeid values.
Allowed symbols: letters, digits and underscores.
The import tool processes only those modems having IPv4 or IPv6 management addresses. Its output is a DevDiscover input XML (DDX) suitable for parallel discovery execution. The resulting DDX file contains both CMTS and CM data. The same CMTS is not supposed to be used in any other DDX file.
In addition to the list of modems, the import tool should receive the following parameters:
all SNMP parameters that are understood by Devdiscover, such as snmp-community, snmp-version, etc.
all DevDiscover parameters applicable to CMTS, including ifIndex mapping hints, selectors, etc.
The current RFC2670_DOCS_IF discovery module is only applicable to CMTS. It should be extended to be usable with cable modems, and also for per-CM statistics on CMTS.
Per-modem statistics on CMTS are organized differently, depending if DOCSIS 2.0 and 3.0 is supported by CMTS. The new DOCS-IF3-MIB should be used for DOCSIS 3.0 CMTS devices, even if the cable modems are only supporting DOCSIS 2.0.
The following CM statistics are collected from CMTS:
The following statistics are collected from cable modems:
The discovery module should find out if 64-bit FEC counters are supported on each device and preferably use them instead of 32-bit counters.
The discovery module should generate per-modem nodeid references based on
CmSvcId attribute in the import data.
The discovery module should recognize the cable modems and set fixed ifIndex mapping for them, so that the collector does not spend extra time on interface indexing.
As there are thousands of modems per CMTS, the SNMP collection job should be
distributed among multiple collector instances. Also the
collector-instance-hashstring parameter should include the CMTS system ID
and CM MAC address, so that per-CM statistics collection from CMTS is spread
across the collector instances.
It makes sense to move all DOCSIS-related tools, discovery modules, and XML templates into a separate Torrus plugin.
The current Torrus WebUI is not very convenient for watching and surfing
large flat sets of data, such as CM MAC addresses. It is intended that Torrus
UI would hand over the graphs to some external DOCSIS management portal.
The graphs would be referenced by unique nodeid strings, as described in
Torrus/OSS integration: NodeID usage guidelines document. These strings
will contain CM MAc addresses or unique Service ID assigned at the data import.
In order to avoid subtrees with thousands of child elements, the per-CM subtrees should be organized in multi-level hierarchies. The import tool should accept the number of hierarchy levels and the number of nybbles per level as parameters. Then each level (except the bottom) would have 16 or 256 or 4096 child subtrees.
For example, if we use one nybble per level and 3 levels in the hierarchy, the statistics for the modem 00:24:d1:20:48:ac would lie in a subtree /DOCS_CM/ac/48/20/0024d12048ac/.
Humans are not supposed to look into this hierarchy, and its mere purpose is to speed up the tree walk by the compiler and collector.
Copyright (c) 2010 Stanislav Sinyagin <ssinyagin@k-open.com>