rfc2669.txt

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

           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,