RFC 4639
Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems
Network Working Group R. Woundy Request for Comments: 4639 Comcast Cable Obsoletes: 2669 K. Marez Category: Standards Track Motorola December 2006 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2006).Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems. This memo obsoletes RFC 2669.
Table of Contents
1. The Internet-Standard Management Framework ......................3 2. Glossary ........................................................3 2.1. CATV .......................................................3 2.2. CM or Cable Modem ..........................................3 2.3. CMTS or Cable Modem Termination System .....................3 2.4. DOCSIS or Data-Over-Cable Service Interface Specification ..3 2.5. Downstream .................................................4 2.6. Head-End ...................................................4 2.7. Media Access Control (MAC) Packet ..........................4 2.8. RF .........................................................4 2.9. Simple Network Management Protocol (SNMP) ..................4 2.10. Upstream ..................................................4 3. Introduction ....................................................4 3.1. Structure of the MIB .......................................5 3.1.1. IMPORTed MIB Modules and REFERENCE Clauses ..........6 3.1.2. Persistence Model for Cable Modems ..................6 3.1.3. IPv4 Compliance .....................................6 3.2. Management Requirements ....................................7 3.2.1. Handling of Software Upgrades .......................7 3.2.2. Events and Notifications ............................8 3.2.3. Notification Throttling .............................8 3.2.3.1. Notification Rate Throttling ...............8 3.2.3.2. Limiting the Notification Rate .............9 3.3. Protocol Filters ...........................................9 3.3.1. Inbound LLC Filters: docsDevFilterLLCTable .........10 3.3.2. Special Filters ....................................11 3.3.2.1. IP Spoofing Filters: docsDevCpeTable, docsDevCpeInetTable ......11 3.3.2.2. SNMP Access Filters: docsDevNmAccessTable ......................11 3.3.3. IP Filtering: docsDevFilterIpTable .................12 3.3.4. Outbound LLC Filters ...............................13 4. Definitions ....................................................13 5. Acknowledgements ...............................................78 5.1. Revision Descriptions .....................................78 6. Security Considerations ........................................79 7. IANA Considerations ............................................82 8. References .....................................................83 8.1. Normative References ......................................83 8.2. Informative References ....................................85
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 [RFC2580].2. Glossary
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.2.1. CATV
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 system.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 CMs.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] [RFI2.0]
2.5. Downstream
The direction from the head-end towards the subscriber.2.6. Head-End
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.8. RF
Radio Frequency.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).2.10. Upstream
The direction from the subscriber towards the head-end.3. Introduction
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 extension. 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 the MIB. 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
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.
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 this device). 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.3.2.3.1. 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 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.
3.2.3.2. 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 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 *
******************
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.3.3.2.1. 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 management agent. Similar IP spoofing filter controls are defined for CMTS implementation in the Subscriber Management MIB [RFC4036].3.3.2.2. 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 MIB.
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 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 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 docsDevFilterPolicyValue 'executed'. For an example of the use of these IP Filtering MIB tables, see [RFC2669]. 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 filtering requirements.
(page 13 continued on part 2)
