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 ipcdn@terayon.com
` 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]
`
`RPX EXHIBIT 1014
`RPX v. CHANBOND
`
`

`
`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
` OBJECTS {
` ifIndex,
` eventReason,
` other useful objects
` }
` STATUS current
` DESCRIPTION
` "trap description"
` ::= Object Id
`
` Note that ifIndex is only included if the event or trap is interface
` related.
`
` An example (fake) vendor defined trap might be:
`
` xyzVendorModemDropout NOTIFICATION-TYPE
` OBJECTS {
` eventReason,
` xyzModemHighWatermarkCount
` }
` STATUS current
` DESCRIPTION
` "Sent by a CMTS when a configurable number of modems
` (xyzModemHysteresis) de-register or become unreachable during
` the sampling period (5 minutes). Used to warn a management
` station about a catastrophic cable plant outage."
` ::= { xyzTraps 23 }
`
` In this example eventReason is a DisplayString providing a human
` readable error message, and xyzModemHighWatermarkCount is a Gauge32
` which indicates the maximum number of modems during the epoch.
`
`St. Johns Standards [Page 7]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
` The last digit of the trap OID for enterprise-specific traps must
` match docsDevEvId. For SNMPv1-capable Network Management systems,
` this is necessary to correlate the event type to the trap type. Many
` Network Management systems are only capable of trap filtering on an
` enterprise and single-last-digit basis.
`
`3.2.3. Trap Throttling
`
` The CM and CMTS MUST provide support for trap message throttling as
` described below. The network operator can employ message rate
` throttling or trap limiting by manipulating the appropriate MIB
` variables.
`
`3.2.3.1. Trap rate throttling
`
` Network operators may employ either of two rate control methods. In
` the first method, the device ceases to send traps when the rate
` exceeds the specified maximum message rate. It resumes sending traps
` only if reactivated by a network management station request.
`
` In the second method, the device resumes sending traps 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 traps to be transmitted within the measurement interval. The
` operator can query the operational throttling state (to determine
` whether traps 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 trap rate
`
` Network operators may wish to limit the number of traps sent by a
` device over a specified time period. The device ceases to send traps
` when the number of traps exceeds the specified threshold. It resumes
` sending traps only when the measurement interval has passed.
`
` The network operator defines the maximum number of traps 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 traps.
`
` See "Techniques for Managing Asynchronously Generated Alerts" [17]
` for further information.
`
`St. Johns Standards [Page 8]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
`3.3. Protocol Filters
`
` The Cable Device MIB provides objects for both 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, IPX, 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 TCP, UDP, and 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. Since the cable modem does not generally do any IP
` processing (other than that specified by the filters) the processing
` of the IP in filters and IP out filters can usually be combined into
` a single step.
`
` ***************
` * LLC Filters *
` ***************
` | | |
` v | v
` ************ | ***************
` * IP Spoof * | * SNMP Access *
` ************ | ***************
` | | |
` v v v
` ****************
` * IP Filter In *
` ****************
` |
` v
` *****************
` * IP Filter Out *
` *****************
` |
` v
` ***********
` * LLC Out *
` ***********
`
`St. Johns Standards [Page 9]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
`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
` (ethernet or other) interfaces. 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 filter. Some examples of possible configurations would be to
` only permit IP (and ARP) traffic, or to drop NETBUEI 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
`
` 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 this table or
` it is discarded without further processing.
`
` 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 policy for automatically creating
` filters in that table is controlled by docsDevCpeEnroll and
` docsDevCpeMax as well as the network management agent.
`
`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 [12].
`
`St. Johns Standards [Page 10]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
`3.3.3. IP Filtering - docsDevIpFilterTable
`
` 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, TOS and TOS mask. 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, the 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. 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 example, a value pointing
` to an entry in the docsDevFilterTosTable may result in the re-writing
` of the TOS bits in the IP packet which was matched. Another
` possibility may be to assign an output packet to a specific output
` upstream queue. An even more complex action might be to re-write the
` TOS value, assign the packet to an upstream service ID, and drop it
` into a particular IPSEC tunnel.
`
`St. Johns Standards [Page 11]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
` Example:
`
` docsDevFilterIpTable
`
` # Index, SrcIP/Mask, DstIP/Mask,ULP, SrcPts,DstPts,Tos/Mask,
` # Int/Dir, Pgroup, [continue]
` # drop any netbios traffic
` 10, 0/0, 0/0, TCP, any, 137-139, 0/0, any/any, drop
`
` # traffic to the proxy gets better service - other matches possible
` 20, 0/0, proxy/32, TCP, any,any, 0/0, cpe/in, 10, continue
`
` # Traffic from CPE 1 gets ’Gold’ service, other matches possible
` 30, cpe1/32, 0/0, any, any,any, 0/0, cpe/in, 20, continue
`
` # Traffic from CPE2 to work goes, other traffic dropped
` 40, cpe2/32, workIPs/24, any, 0/0, cpe/in, accept
` 45, cpe2/32, 0/0, any, any,ayn, 0/0, cpe/in, drop
`
` # Traffic with TOS=4 gets queued on the "silver" queue.
` 50, 0/0, 0/0, any, any,any, 4/255, cpe/in, 30
`
` # Inbound "server" traffic to low numbered ports gets dropped.
` 60, 0/0, 0/0, TCP, any,1-1023, 0/0, cpe/out, drop
` 65, 0/0, 0/0, UDP, any,1-1023, 0/0, cpe/out, drop
`
` docsDevFilterIpPolicyTable
`
` #
` # index, policy group, policy
` 10, 10, queueEntry.20 -- special queue for traffic to proxy
`
` 15, 20, queueEntry.15 -- Gold Service queue
` 20, 20, docsDevFilterTosStatus.10 -- Mark this packet with TOS 5
`
` 25, 30, queueEntry.10 -- Silver service queue
`
` This table describes some special processing for packets originating
` from either the first or second CPE device which results in their
` queuing on to special upstream traffic queues and for the "gold"
` service results in having the packets marked with a TOS of 5. The
` 10, 20, 60 and 65 entries are generic entries that would generally be
` applied to all traffic to this CM. The 30, 40 and 45 entries are
` specific to a particular CPE’s service assignments. The ordering
` here is a bit contrived, but is close to what may actually be
` required by the operator to control various classes of customers.
`
`St. Johns Standards [Page 12]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
`3.3.4. Outbound LLC Filters
`
` Lastly, any outbound LLC filters are applied to the packet just prior
` to it being emitted on the appropriate interface. This MIB does not
` specify any outbound LLC filters, but it is anticipated that the QOS
` additions to the DOCSIS standard may include some outbound LLC
` filtering requirements. If so, those filters would be applied as
` described here.
`
`4. Definitions
`
`DOCS-CABLE-DEVICE-MIB DEFINITIONS ::= BEGIN
`
`IMPORTS
` MODULE-IDENTITY,
` OBJECT-TYPE,
`-- do not import BITS,
` IpAddress,
` Unsigned32,
` Counter32,
` Integer32,
` zeroDotZero,
` mib-2
` FROM SNMPv2-SMI
` RowStatus,
` RowPointer,
` DateAndTime,
` TruthValue
` FROM SNMPv2-TC
` OBJECT-GROUP,
` MODULE-COMPLIANCE
` FROM SNMPv2-CONF
` SnmpAdminString
` FROM SNMP-FRAMEWORK-MIB
` InterfaceIndexOrZero
` FROM IF-MIB; -- RFC2233
`
`docsDev MODULE-IDENTITY
` LAST-UPDATED "9908190000Z" -- August 19, 1999
` ORGANIZATION "IETF IPCDN Working Group"
` CONTACT-INFO
` " Michael StJohns
` Postal: @Home Network
` 425 Broadway
` Redwood City, CA 94063
` U.S.A.
` Phone: +1 650 569 5368
` E-mail: stjohns@corp.home.net"
`
`St. Johns Standards [Page 13]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
` DESCRIPTION
` "This is the MIB Module for MCNS-compliant cable modems and
` cable-modem termination systems."
` REVISION "9908190000Z"
` DESCRIPTION
` "Initial Version, published as RFC 2669.
` Modified by Mike StJohns to add/revise filtering, TOS
` support, software version information objects."
` ::= { mib-2 69 }
`
`docsDevMIBObjects OBJECT IDENTIFIER ::= { docsDev 1 }
`docsDevBase OBJECT IDENTIFIER ::= { docsDevMIBObjects 1 }
`
`--
`-- For the following object, there is no concept in the
`-- RFI specification corresponding to a backup CMTS. The
`-- enumeration is provided here in case someone is able
`-- to define such a role or device.
`--
`
`docsDevRole OBJECT-TYPE
` SYNTAX INTEGER {
` cm(1),
` cmtsActive(2),
` cmtsBackup(3)
` }
` MAX-ACCESS read-only
` STATUS current
` DESCRIPTION
` "Defines the current role of this device. cm (1) is
` a Cable Modem, cmtsActive(2) is a Cable Modem Termination
` System which is controlling the system of cable modems,
` and cmtsBackup(3) is a CMTS which is currently connected,
` but not controlling the system (not currently used).
`
` In general, if this device is a ’cm’, its role will not
` change during operation or between reboots. If the
` device is a ’cmts’ it may change between cmtsActive and
` cmtsBackup and back again during normal operation. NB:
` At this time, the DOCSIS standards do not support the
` concept of a backup CMTS, cmtsBackup is included for
` completeness."
` ::= { docsDevBase 1 }
`
`docsDevDateTime OBJECT-TYPE
` SYNTAX DateAndTime
` MAX-ACCESS read-write
` STATUS current
`
`St. Johns Standards [Page 14]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
` DESCRIPTION
` "The date and time, with optional timezone
` information."
` ::= { docsDevBase 2 }
`
`docsDevResetNow OBJECT-TYPE
` SYNTAX TruthValue
` MAX-ACCESS read-write
` STATUS current
` DESCRIPTION
` "Setting this object to true(1) causes the device to reset.
` Reading this object always returns false(2)."
` ::= { docsDevBase 3 }
`
`docsDevSerialNumber OBJECT-TYPE
` SYNTAX SnmpAdminString
` MAX-ACCESS read-only
` STATUS current
` DESCRIPTION
` "The manufacturer’s serial number for this device."
` ::= { docsDevBase 4 }
`
`docsDevSTPControl OBJECT-TYPE
` SYNTAX INTEGER {
` stEnabled(1),
` noStFilterBpdu(2),
` noStPassBpdu(3)
` }
` MAX-ACCESS read-write
` STATUS current
` DESCRIPTION
` "This object controls operation of the spanning tree
` protocol (as distinguished from transparent bridging).
` If set to stEnabled(1) then the spanning tree protocol
` is enabled, subject to bridging constraints. If
` noStFilterBpdu(2), then spanning tree is not active,
` and Bridge PDUs received are discarded.
` If noStPassBpdu(3) then spanning tree is not active
` and Bridge PDUs are transparently forwarded. Note that
` a device need not implement all of these options,
` but that noStFilterBpdu(2) is required."
` ::= { docsDevBase 5 }
`
`--
`-- The following table provides one level of security for access
`-- to the device by network management stations.
`-- Note that access is also constrained by the
`-- community strings and any vendor-specific security.
`
`St. Johns Standards [Page 15]
`
`

`
`RFC 2669 DOCSIS Cable Device MIB August 1999
`
`--
`
`docsDevNmAccessTable OBJECT-TYPE
` SYNTAX SEQUENCE OF DocsDevNmAccessEntry
` MAX-ACCESS not-accessible
` STATUS current
` DESCRIPTION
` "This table controls access to SNMP objects by network
` management stations. If the table is empty, access
` to SNMP objects is unrestricted. This table exists only
` on SNMPv1 or v2c agents and does not exist on SNMPv3
` agents. See the conformance section for details.
` Specifically, for v3 agents, the appropriate MIBs and
`