rfc2669.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                  M. St. Johns, Ed.
Request for Comments: 2669                                 @Home Network
Category: Proposed Standard                                  August 1999


                        DOCSIS Cable Device MIB
                Cable Device Management Information Base
                 for 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 Internet Society (1999).  All Rights Reserved.

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 SNMP-
   based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem
   Termination Systems.

   This memo specifies a MIB module in a manner that is compliant to the
   SNMP SMIv2 [5][6][7].  The set of objects is consistent with the SNMP
   framework and existing SNMP standards.

   This memo is a product of the IPCDN working group within the Internet
   Engineering Task Force.  Comments are solicited and should be
   addressed to the working group's mailing list at [e-mail]
   and/or the author.

Table of Contents

   1 The SNMP Management Framework ................................... 2
   2 Glossary ........................................................ 3
   2.1 CATV .......................................................... 3
   2.2 CM ............................................................ 3
   2.3 CMTS .......................................................... 4
   2.4 DOCSIS ........................................................ 4



St. Johns                      Standards                        [Page 1]

RFC 2669                DOCSIS Cable Device MIB              August 1999


   2.5 Downstream .................................................... 4
   2.6 Head-end ...................................................... 4
   2.7 MAC Packet .................................................... 4
   2.8 MCNS .......................................................... 4
   2.9 RF ............................................................ 4
   2.10 Upstream ..................................................... 4
   3 Overview ........................................................ 4
   3.1 Structure of the MIB .......................................... 5
   3.2 Management requirements ....................................... 6
   3.2.1 Handling of Software upgrades ............................... 6
   3.2.2 Events and Traps ............................................ 6
   3.2.3 Trap Throttling ............................................. 8
   3.2.3.1 Trap rate throttling ...................................... 8
   3.2.3.2 Limiting the trap rate .................................... 8
   3.3 Protocol Filters .............................................. 9
   3.3.1 Inbound LLC Filters - docsDevFilterLLCTable ................ 10
   3.3.2 Special Filters ............................................ 10
   3.3.2.1 IP Spoofing Filters - docsDevCpeTable .................... 10
   3.3.2.2 SNMP Access Filters - docsDevNmAccessTable ............... 10
   3.3.3 IP Filtering - docsDevIpFilterTable ........................ 11
   3.3.4 Outbound LLC Filters ....................................... 13
   4 Definitions .................................................... 13
   5 Acknowledgments ................................................ 51
   6 References ..................................................... 51
   7 Security Considerations ........................................ 52
   8 Intellectual Property .......................................... 54
   9 Author's Address ............................................... 54
   10 Full Copyright Statement ...................................... 55

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o   An overall architecture, described in RFC 2571 [1].

   o   Mechanisms for describing and naming objects and events for the
       purpose of management. The first version of this Structure of
       Management Information (SMI) is called SMIv1 and described in STD
       16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].  The
       second version, called SMIv2, is described in STD 58, RFC 2578
       [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].

   o   Message protocols for transferring management information. The
       first version of the SNMP message protocol is called SNMPv1 and
       described in STD 15, RFC 1157 [8]. A second version of the SNMP
       message protocol, which is not an Internet standards track
       protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC



St. Johns                      Standards                        [Page 2]

RFC 2669                DOCSIS Cable Device MIB              August 1999


       1906 [10].  The third version of the message protocol is called
       SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
       [12].

   o   Protocol operations for accessing management information. The
       first set of protocol operations and associated PDU formats is
       described in STD 15, RFC 1157 [8]. A second set of protocol
       operations and associated PDU formats is described in RFC 1905
       [13].

   o   A set of fundamental applications described in RFC 2573 [14] and
       the view-based access control mechanism described in RFC 2575
       [15].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

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 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   Cable Modem.

   A CM acts as a "slave" station in a DOCSIS compliant cable data
   system.







St. Johns                      Standards                        [Page 3]

RFC 2669                DOCSIS Cable Device MIB              August 1999


2.3.  CMTS   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

   "Data Over Cable Interface Specification".  A term referring to the
   ITU-T J.112 Annex B standard for cable modem systems [20].

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.  MAC Packet

   A DOCSIS PDU.

2.8.  MCNS

   "Multimedia Cable Network System".  Generally replaced in usage by
   DOCSIS.

2.9.  RF

   Radio Frequency.

2.10.  Upstream

   The direction from the subscriber towards the head-end.

3.  Overview

   This MIB 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 [16].   Please note that the DOCSIS
   1.0 standard only requires Cable Modems to implement SNMPv1 and to





St. Johns                      Standards                        [Page 4]

RFC 2669                DOCSIS Cable Device MIB              August 1999


   process IPv4 customer traffic. Design choices in this MIB reflect
   those requirements.  Future versions of the DOCSIS standard are
   expected to require support for SNMPv3 and IPv6 as well.

   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 [19].

3.1.  Structure of the MIB

   This MIB is structured into seven groups:

      o    The docsDevBase group extends the MIB-II 'system' group with
           objects needed for cable device system management.

      o    The docsDevNmAccessGroup provides a minimum level of SNMP
           access security (see Section 3 of [18]).

      o    The docsDevSoftware group provides information for network-
           downloadable software upgrades.  See "Handling of Software
           Upgrades" below..

      o    The docsDevServer group provides information about the
           progress of the interaction between the CM or CMTS and
           various provisioning servers.

      o    The docsDevEvent group provides control and logging for event
           reporting.

      o    The docsDevFilter group configures filters at link layer and
           IP layer for bridged data traffic.  This group consists of a
           link-layer filter table, docsDevFilterLLCTable, which is used
           to manage the processing and forwarding of non-IP traffic; an
           IP packet classifier table, docsDevFilterIpTable, which is
           used to map classes of packets to specific policy actions; a
           policy table, docsDevFilterPolicyTable, which maps zero or
           more policy actions onto a specific packet classification,
           and one or more policy action tables.

           At this time, this MIB specifies only one policy action
           table, docsDevFilterTosTable, which allows the manipulation
           of the type of services bits in an IP packet based on
           matching some criteria.  The working group may add additional
           policy types and action tables in the future, for example to
           allow QOS to modem service identifier assignment based on
           destination.





St. Johns                      Standards                        [Page 5]

RFC 2669                DOCSIS Cable Device MIB              August 1999


      o    The docsDevCpe group provides control over which IP addresses
           may be used by customer premises equipment (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.2.  Management requirements

3.2.1.  Handling of Software upgrades

   The Cable Modem software upgrade process is documented in [16].  From
   a network management station, the operator:

      o    sets docsDevSwServer to the address of the TFTP server for
           software upgrades

      o    sets docsDevSwFilename to the file pathname of the software
           upgrade image

      o    sets docsDevSwAdminStatus to upgrade-from-mgt

   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.

      o    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).

3.2.2.  Events and Traps

   This MIB provides control facilities for reporting events through
   syslog, traps, and non-volatile logging.  If events are reported
   through traps, the specified conventions must be followed.  Other
   means of event reporting are outside the scope of this document.





St. Johns                      Standards                        [Page 6]

RFC 2669                DOCSIS Cable Device MIB              August 1999


   The definition and coding of events is vendor-specific.  In deference
   to the network operator who must troubleshoot multi-vendor networks,
   the circumstances and meaning of each event should be reported as
   human-readable text.  Vendors SHOULD provide time-of-day clocks in
   CMs to provide useful timestamping of events.

   For each vendor-specific event that is reportable via TRAP, the
   vendor must create an enterprise-specific trap definition.  Trap
   definitions MUST include the event reason encoded as DisplayString
   and should be defined as:

   trapName NOTIFICATION-TYPE