Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems

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 . Please note that the DOCSIS 1.0 standard only required Cable Modems to 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 and DOCSIS 2.0 require support for SNMPv3, as well as SNMPv1 and SNMPv2c, and the changes in this MIB module over the previous proposed standard version reflect those additional requirements. Future versions of DOCSIS are expected to require support for 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 .

This MIB module is structured into seven components. A component contains one or more MIB groups related by deprecation or logical extension. The docsDevBaseGroup extends the MIB-II 'system' group of 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). The docsDevNmAccessGroup and the docsDevNmAccessExtGroup provide a minimum level of SNMP access security (see Section 2.7 of , section 2 of , and section 5 of ). With the completion of the SNMP coexistence document, RFC 3584 , these groups have been deprecated in this version of the MIB. The docsDevSoftwareGroup, updated by the docsDevSoftwareGroupV2, provides information for network-downloadable software upgrades. See "Handling of Software Upgrades" below. The docsDevServerGroup, updated by the docsDevServerGroupV2, provides information about the progress of the interaction between the CM or CMTS and various provisioning servers. The docsDevEventGroup, updated by the docsDevEventGroupV2, provides control and logging for event reporting. With the addition of the SNMP Notification MIB, RFC 3413 , and Notification Log MIB, RFC 3014 , which cover event reporting, the objects in this MIB module have been modified to allow for the usage of these RFCs. The docsDevFilterGroup configures filters at 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 -- specifically the groups representing the Data Path, Classifier, and Actions tables from that MIB. 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).

This MIB module IMPORTs definitions normatively from the following MIB modules, beyond , and : INET-ADDRESS-MIB , SNMP-FRAMEWORK-MIB , IF-MIB , RMON2-MIB , and DIFFSERV-MIB . This MIB module also includes REFERENCE clauses that normatively refer to , , , , , and .

Most of the tables in this MIB module (e.g. docsDevNmAccessTable, docsDevFilterLLCTable) are specified not to persist objects across reboots. 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 debugging purposes.

Please note that the compliance statements in this version of the MIB module require support only for IPv4 addresses. That is because the current version 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.

The Cable Modem software upgrade process is documented in . From a network management station, the operator: sets docsDevSwServer to the address of the Trivial File Transfer Protocol (TFTP) server for software upgrades sets docsDevSwFilename to the file pathname of the software upgrade image sets docsDevSwAdminStatus to upgrade-from-mgt While DOCSIS only specifies the implementation of the TFTP protocol for file transfers, other functional entities embedded within the cable device (particularly a PacketCable Multimedia Terminal Adapter ) specify the optional implementation of the Hyper Text Transfer Protocol (HTTP) 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: The download is incomplete. The file contents are incomplete or damaged. The software is not intended for that hardware device (may include the case of a feature set that has not been purchased for this device). A cable device that implements the code verification mechanisms of verifies the source and integrity of the downloaded image by validating one or more Code Verification Signatures that are bundled within the software upgrade.

This MIB module provides control facilities for reporting events through syslog , notifications (traps and informs), and non-volatile logging. Additional controls allow for the agent to use the SNMP Notification MIB and Notification Log MIB 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 .

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.

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 request. 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.

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 threshold which is the maximum number of notifications. See "Techniques for Managing Asynchronously Generated Alerts" for additional technical motivations.

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 based on 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, then any final LLC outbound filters.

***************** * LLC Filter In * ***************** | v ******************* * Special Filters * * | * * V * * ************ * * * IP Spoof * * * ************ * * | * * v * * *************** * * * SNMP Access * * * *************** * * | * ******************* | v **************** * IP Filter In * **************** | v ***************** * IP Filter Out * ***************** | v ****************** * LLC Filter Out * ******************

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 to either drop frames which match at least one filter, or to process a frame which matches at least one filter. Some examples of possible configurations would be to only permit IP (and ARP) traffic, or to drop NetBIOS traffic.

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.

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 mis-using 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 automatically populate the table. 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 the network management agent. Similar IP spoofing filter controls are defined for CMTS implementation in the Subscriber Management MIB .

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 . With the completion of the SNMP coexistence document, RFC 3584 , 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 MIB.

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 which 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 the packet. 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 24.0.16.30, and these sets of actions may not be mutually exclusive. Once a packet is matched, one of three actions happen based on 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 based on the match. The docsDevFilterPolicyTable is scanned in row order and all rows where docsDevFilterPolicyId equals docsDevFilterIpPolicyId have the action specified by docsDevFilterPolicyValue 'executed'. 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 . See the body of the MIB for the description of how agents should handle the interaction between RFC 3289 MIBs and this MIB module.

Lastly, any outbound LLC filters are applied to the packet just prior to it being emitted on the appropriate interface. This MIB module does not specify any outbound LLC filters, but it is anticipated that the Quality of Service (QoS) additions to the DOCSIS standard may include some outbound LLC filtering requirements. If so, those filters would be applied as described there.