tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4639

Proposed STD
Pages: 88
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPCDN

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

Part 1 of 5, p. 1 to 13
None       Next RFC Part

Obsoletes:    2669


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
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]

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
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.

Top      ToC       Page 9 
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.

Top      ToC       Page 10 
                   *****************
                   * 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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
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.

Top      ToC       Page 13 
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)

Next RFC Part