1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
The terms in this document are derived either from normal cable
system usage, or from the documents associated with the Data-Over-
Cable Service Interface Specification (DOCSIS) process.
Originally "Community Antenna Television", now used to refer to any
cable or hybrid fiber and cable system used to deliver video signals
to a community.
2.2. CM or Cable Modem
A CM acts as a "slave" station in a DOCSIS-compliant cable data
2.3. CMTS or Cable Modem Termination System
A generic term covering a cable bridge or cable router in a head-end.
A CMTS acts as the master station in a DOCSIS-compliant cable data
system. It is the only station that transmits downstream, and it
controls the scheduling of upstream transmissions by its associated
2.4. DOCSIS or Data-Over-Cable Service Interface Specification
A term referring to the ITU-T Recommendation J.112 [ITU-T_J.112],
Annex B, standard for cable modem systems. [RFI1.0] [RFI1.1]
The direction from the head-end towards the subscriber.
The origination point in most cable systems of the subscriber video
signals. Generally, also the location of the CMTS equipment.
2.7. Media Access Control (MAC) Packet
A DOCSIS Packet Data Unit.
2.9. Simple Network Management Protocol (SNMP)
Protocol used for network access to Management Information Base (MIB)
objects. The three most commonly used versions are Version 1
(SNMPv1), Version 2 (SNMPv2c), and Version 3 (SNMPv3).
The direction from the subscriber towards the head-end.
This MIB module provides a set of objects required for the management
of DOCSIS-compliant Cable Modems (CM) and Cable Modem Termination
Systems (CMTS). The specification is derived from the DOCSIS Radio
Frequency Interface specification [RFI1.0]. Please note that the
DOCSIS 1.0 standard only required that Cable Modems implement SNMPv1
and to process Internet Protocol Version 4 (IPv4) customer traffic.
Design choices in the original version of this MIB module reflected
those requirements. DOCSIS 1.1 [RFI1.1] and DOCSIS 2.0 [RFI2.0]
require support for SNMPv3, as well as for SNMPv1 and SNMPv2c, and
the changes in this MIB module over the previous proposed standard
version reflect those additional requirements.
Future versions of DOCSIS, starting with DOCSIS 3.0 [MULPI3.0], are
expected to require support for the Internet Protocol Version 6
(IPv6) as both a Customer Premise Equipment (CPE) protocol and one
supported by the network elements of the DOCSIS CMTS/CM system.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3.1. Structure of the MIB
This MIB module is structured into seven components. A component
contains one or more MIB groups related by deprecation or logical
o The docsDevBaseGroup extends the MIB-II 'system' group of RFC3418
[RFC3418] with objects needed for cable device system management.
Related to this group is the docsDevBaseIgmpGroup (enabling
Internet Group Management Protocol (IGMP) status and control) and
the docsDevBaseMaxCpeGroup (managing the maximum number of CPEs
permitted access through the cable modem).
o The docsDevNmAccessGroup and the docsDevNmAccessExtGroup provide a
minimum level of SNMP access security (see Section 2.7 of
[OSSI1.0], Section 2 of [OSSI1.1], and Section 5 of [OSSI2.0]).
With the completion of the SNMP coexistence document, RFC 3584
[RFC3584], these groups have been deprecated in this version of
o The docsDevSoftwareGroup, updated by the docsDevSoftwareGroupV2,
provides information for network-downloadable software upgrades.
See "Handling of Software Upgrades", below.
o The docsDevServerGroup, updated by the docsDevServerGroupV2,
provides information about the progress of the interaction between
the CM or CMTS and various provisioning servers.
o The docsDevEventGroup, updated by the docsDevEventGroupV2,
provides control and logging for event reporting. With the
addition of the SNMP Notification MIB, RFC 3413 [RFC3413], and
Notification Log MIB, RFC 3014 [RFC3014], which cover event
reporting, the objects in this MIB module have been modified to
allow for the usage of these RFCs.
o The docsDevFilterGroup configures filters at the link layer and IP
layer for bridged data traffic. This group has been deprecated in
this version of the MIB in favor of the docsDevFilterLLCGroup, and
by groups from the Differentiated Services MIB [RFC3289] --
specifically, the groups representing the Data Path, Classifier,
and Actions tables from that MIB.
o The docsDevCpeGroup, updated by the docsDevInetCpeGroup, provides
control over which IP addresses may be used by CPEs (e.g., PCs)
serviced by a given cable modem. This provides anti-spoofing
control at the point of origin for a large cable modem system.
This group is separate from docsDevFilter, primarily as this group
is only implemented on the Cable Modem (CM) and MUST NOT be
implemented on the Cable Modem Termination System (CMTS).
3.1.1. IMPORTed MIB Modules and REFERENCE Clauses
This MIB module IMPORTs definitions normatively from the following
MIB modules, beyond [RFC2578], [RFC2579], and [RFC2580]: INET-
ADDRESS-MIB [RFC4001], SNMP-FRAMEWORK-MIB [RFC3411], IF-MIB
[RFC2863], RMON2-MIB [RFC4502], and DIFFSERV-MIB [RFC3289].
This MIB module also includes DESCRIPTION and REFERENCE clauses that
normatively refer to [RFC868], [RFC3617], [RFI1.0], [RFI1.1],
[RFI2.0], [OSSI1.1], and [OSSI2.0].
3.1.2. Persistence Model for Cable Modems
Most of the tables in this MIB module (e.g., docsDevNmAccessTable,
docsDevFilterLLCTable) are specified not to let objects persist
The expectation (and current operational practice) is that upon
reboot, these tables are cleared and repopulated from the DOCSIS
configuration file supplied by the cable operator. This approach
enables a cable modem to adapt to the current cable operator's
environment, which in turn enables cable modem portability across
different cable operators.
A notable exception to the persistence model is docsDevEventTable,
since it is useful to maintain a record of events across reboots for
3.1.3. IPv4 Compliance
Please note that the compliance statements in this version of the MIB
module require support only for IPv4 addresses. That is because the
current versions of the DOCSIS protocols (1.0, 1.1, and 2.0) are not
IPv6 capable. Although support for IPv6 will require changes to the
DOCSIS protocols, it is expected that the only changes needed to the
MIB module itself will be the addition of new compliance statements
that mandate support for IPv6 addresses.
3.2. Management Requirements
3.2.1. Handling of Software Upgrades
The Cable Modem software upgrade process is documented in [RFI1.0].
From a network management station, the operator
o sets docsDevSwServer to the address of the Trivial File Transfer
Protocol (TFTP) server for software upgrades;
o sets docsDevSwFilename to the file pathname of the software
upgrade image; and
o sets docsDevSwAdminStatus to upgrade-from-mgt.
Although DOCSIS only specifies the implementation of the TFTP
protocol [RFC1350] for file transfers, other functional entities
embedded within the cable device (particularly a PacketCable
Multimedia Terminal Adapter [MTA-PROV]) specify the optional
implementation of the Hyper Text Transfer Protocol (HTTP) [RFC1945]
and [RFC2616] for file transfers. The value of the
docsDevSwServerTransportProtocol object determines which protocol is
used for SNMP-initiated software upgrade.
One reason for the SNMP-initiated upgrade is to allow loading of a
temporary software image (e.g., special diagnostic software) that
differs from the software normally used on that device without
changing the provisioning database.
Note that software upgrades should not be accepted blindly by the
cable device. The cable device may refuse an upgrade if
o the download is incomplete;
o the file contents are incomplete or damaged; or
o the software is not intended for that hardware device (this may
include the case of a feature set that has not been purchased for
A cable device that implements the code verification mechanisms of
[BPIPLUS] verifies the source and integrity of the downloaded image
by validating one or more Code Verification Signatures that are
bundled within the software upgrade.
3.2.2. Events and Notifications
This MIB module provides control facilities for reporting events
through syslog [RFC3164], notifications (traps and informs), and
non-volatile logging. Additional controls allow the agent to use the
SNMP Notification MIB [RFC3413] and Notification Log MIB [RFC3014]
for event notification.
The conventions for event reporting are outside the scope of this
document. The definition and coding of common DOCSIS notifications
can be found in [RFC4547].
3.2.3. Notification Throttling
The CM and CMTS MUST provide support for notification message
throttling as described below. The network operator can employ
notification rate throttling or notification limiting by manipulating
the appropriate MIB variables.
220.127.116.11. Notification Rate Throttling
Network operators may employ either of two rate control methods. In
the first method, the device ceases to send notifications when the
rate exceeds the specified maximum message rate. It resumes sending
notifications only if reactivated by a network management station
In the second method, the device resumes sending notifications when
the rate falls below the specified maximum message rate.
The network operator configures the specified maximum message rate by
setting the measurement interval (in seconds), and the maximum number
of notifications to be transmitted within the measurement interval.
The operator can query the operational throttling state (to determine
whether notifications are enabled or blocked by throttling) of the
device, as well as query and set the administrative throttling state
(to manage the rate control method) of the device.
18.104.22.168. Limiting the Notification Rate
Network operators may wish to limit the number of notifications sent
by a device over a specified time period. The device ceases to send
notifications when the number of notifications exceeds the specified
threshold. It resumes sending notifications only when the
measurement interval has passed.
The network operator defines the maximum number of notifications he
is willing to handle and sets the measurement interval to a large
number (in hundredths of a second). For this case, the
administrative throttling state is set to stop at a threshold that is
the maximum number of notifications.
See "Techniques for Managing Asynchronously Generated Alerts"
[RFC1224] for additional technical motivations.
3.3. Protocol Filters
The Cable Device MIB provides objects for both Link Layer Control
(LLC) and IP protocol filters. The LLC protocol filter entries can
be used to limit CM forwarding to a restricted set of network-layer
protocols (such as IP, Internetwork Packet Exchange (IPX), Network
Basic Input/Output System (NetBIOS), and Appletalk).
The IP protocol filter entries can be used to restrict upstream or
downstream traffic according to source and destination IP addresses,
transport-layer protocols (such as Transport Control Protocol (TCP),
User Datagram Protocol (UDP), and Internet Control Message Protocol
(ICMP)), and source and destination TCP/UDP port numbers.
In general, a cable modem applies filters (or, more properly,
classifiers) in an order appropriate to the layering model.
Specifically, the inbound MAC (or LLC) layer filters are applied
first, then the "special" filters, then the IP layer inbound filters,
then the IP layer outbound filters, and then any final LLC outbound
* LLC Filter In *
* Special Filters *
* | *
* V *
* ************ *
* * IP Spoof * *
* ************ *
* | *
* v *
* *************** *
* * SNMP Access * *
* *************** *
* | *
* IP Filter In *
* IP Filter Out *
* LLC Filter Out *
3.3.1. Inbound LLC Filters: docsDevFilterLLCTable
The inbound LLC (or MAC or level-2) filters are contained in the
docsDevFilterLLCTable and are applied to level-2 frames entering the
cable modem from either the RF MAC interface or from one of the CPE
interfaces (physical or logical). These filters are used to prohibit
the processing and forwarding of certain types of level-2 traffic
that may be disruptive to the network. The filters, as currently
specified, can be set to cause the modem either to drop frames that
match at least one filter, or to process a frame that matches at
least one filter. Some examples of possible configurations would be
to permit only IP (and ARP) traffic, or to drop NetBIOS traffic.
3.3.2. Special Filters
Special filters are applied after the packet is accepted from the MAC
layer by the IP module, but before any other processing is done.
They are filters that apply only to a very specific class of traffic.
22.214.171.124. IP Spoofing Filters: docsDevCpeTable, docsDevCpeInetTable
IP spoofing filters are applied to packets entering the modem from
one of the CPE interfaces and are intended to prevent a subscriber
from stealing or misusing IP addresses that were not assigned to the
subscriber. If the filters are active (enabled), the source address
of the IP packet must match at least one IP address in one of these
two tables (docsDevCpeTable or docsDevCpeInetTable), or it is
discarded without further processing.
To prevent potential implementation ambiguity, the device consults
the docsDevCpeTable for the IP packet source address before
consulting the docsDevCpeInetTable.
The table can be automatically populated where the first N different
IP addresses seen from the CPE side of the cable modem are used to
populate the table automatically. The spoofing filters are specified
in the docsDevCpeTable and the docsDevCpeInetTable, and the policy
for automatically creating filters in those tables is controlled by
docsDevCpeEnroll and docsDevMaxCpe, as well as by the network
Similar IP spoofing filter controls are defined for CMTS
implementation in the Subscriber Management MIB [RFC4036].
126.96.36.199. SNMP Access Filters: docsDevNmAccessTable
The SNMP access filters are applied to SNMP packets entering from any
interface and destined for the cable modem. If the packets enter
from a CPE interface, the SNMP filters are applied after the IP
spoofing filters. The filters only apply to SNMPv1 or SNMPv2c
traffic and are not consulted for SNMPv3 traffic (and need not be
implemented by a v3-only agent). SNMPv3 access control is specified
in the User Security Model MIB, in [RFC3414].
With the completion of the SNMP coexistence document, RFC 3584
[RFC3584], docsDevNmAccess table has been deprecated in this version
of the MIB. See the body of the MIB for the description of how
agents should handle the interaction between RFC 3584 MIBs and this
3.3.3. IP Filtering: docsDevFilterIpTable
The IP Filtering table acts as a classifier table. Each row in the
table describes a template against which IP packets are compared.
The template includes source and destination addresses (and their
associated masks), upper level protocol (e.g., TCP, UDP), source and
destination port ranges, and Terms of Service (ToS) values. A row
also contains interface and traffic direction match values that have
to be considered in combination. All columns of a particular row
must match the appropriate fields in the packet and must match the
interface and direction items for the packet to result in a match to
When classifying a packet, each table is scanned, beginning with the
lowest number filter. If the agent finds a match, it applies the
group of policies specified. If the matched filter has the continue
bit set, the agent continues the scan possibly matching additional
filters and applying additional policies. For example, this allows
the agent to take one set of actions for the 24.0.16/255.255.255.0
group and one set of actions for telnet packets to/from 188.8.131.52,
and these sets of actions may not be mutually exclusive.
Once a packet is matched, one of three actions happen according to
the setting of docsDevFilterIpControl in the row. The packet may be
dropped, in which case no further processing is required. The packet
may be accepted, and processing of the packet continues. Lastly, the
packet may have a set of policy actions applied to it. If
docsDevFilterIpContinue is set to true, scanning of the table
continues and additional matches may result.
When a packet matches and docsDevFilterIpControl in the filter
matched is set to 'policy', the value of docsDevFilterIpPolicyId is
used as a selector into the docsDevFilterPolicyTable. The first
level of indirection may result in zero or more actions being taken
according to the match. The docsDevFilterPolicyTable is scanned in
row order, and all rows where docsDevFilterPolicyId equals
docsDevFilterIpPolicyId have the action specified by the
For an example of the use of these IP Filtering MIB tables, see
The IP Filtering table and related tables have been deprecated in
this version of the MIB in favor of the Data Path, Classifier, and
Action tables from the Differentiated Services MIB [RFC3289]. See
the body of the MIB for the description of how agents should handle
the interaction between RFC 3289 MIBs and this MIB module.
3.3.4. Outbound LLC Filters
Lastly, any outbound LLC filters are applied to the packet just prior
to its being emitted on the appropriate interface. This MIB module
does not specify any outbound LLC filters, but section 3 of the
DOCSIS Quality of Service (QoS) MIB, [RFC4323], includes outbound LLC