Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4323

Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)

Pages: 89
Proposed Standard
Updated by:  9141
Part 1 of 4 – Pages 1 to 20
None   None   Next

Top   ToC   RFC4323 - Page 1
Network Working Group                                         M. Patrick
Request for Comments: 4323                                     W. Murwin
Category: Standards Track                                   Motorola BCS
                                                            January 2006

             Data Over Cable System Interface Specification
                           Quality of Service
              Management Information Base (DOCSIS-QoS MIB)

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 (2006).


This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0.
Top   ToC   RFC4323 - Page 2

Table of Contents

1. Introduction ....................................................2 1.1. The Internet-Standard Management Framework .................2 1.2. Glossary ...................................................3 2. Overview ........................................................5 2.1. Textual Conventions ........................................5 2.2. MIB Organization ...........................................5 2.2.1. docsIetfQosPktClassTable ............................9 2.2.2. docsIetfQosParamSetTable ...........................10 Interoperation with DOCSIS 1.0 ............11 2.2.3. docsIetfQosServiceFlowTable ........................12 2.2.4. docsIetfQosServiceFlowStatsTable ...................13 2.2.5. docsIetfQosUpstreamStatsTable ......................14 2.2.6. docsIetfQosDynamicServiceStatsTable ................14 2.2.7. docsIetfQosServiceFlowLogTable .....................14 2.2.8. docsIetfQosServiceClassTable .......................15 2.2.9. docsIetfQosServiceClassPolicyTable .................15 2.2.10. docsIetfQosPHSTable ...............................16 2.2.11. docsIetfQosCmtsMacToSrvFlowTable ..................16 3. Externally Administered Classification .........................16 4. DOCSIS and IPv4 Type-of-Service (ToS) Field ....................19 5. Definitions ....................................................20 6. Security Considerations ........................................84 7. IANA Considerations ............................................86 8. Acknowledgements ...............................................86 9. Normative References ...........................................86 10. Informative References ........................................87

1. Introduction

This memo is a product of the IP over Cable Data Network (IPCDN) working group within the Internet Engineering Task Force (IETF).

1.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 [15]. 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 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3].
Top   ToC   RFC4323 - Page 3

1.2. Glossary

Active QPS Active QoS Parameter Set (QPS). The set of QoS parameters that describe the current level of service provided to a Service Flow (SF). Active SF Active Service Flow. An SF with a non-empty Active QPS. Admitted QPS Admitted QoS Parameter Set. The set of QoS parameters that describe a level of service that the Service Flow is not currently using, but that it is guaranteed to receive upon the SF's request to make the set Active. Admitted SF A Service Flow with a non-empty Admitted QPS. CATV Cable Television. CM Cable Modem. A modem connecting a subscriber's LAN to the Cable Television (CATV) Radio Frequency (RF) network. DOCSIS CMs operate as a MAC layer bridge between the home LAN and the Cable Television (CATV) Radio Frequency (RF) network. CMTS Cable Modem Termination System. The "head-end" device providing connectivity between the RF network and the Internet. Downstream The direction from the head-end towards the subscriber. DSA Dynamic Service Addition. A DOCSIS MAC management message requesting the dynamic creation of a new Service Flow. New SFs are created with a three- message exchange of a DSA-REQ, DSA-RSP, and DSA-ACK. DSC Dynamic Service Change. A DOCSIS MAC management message requesting a change to the attributes of a Service Flow. SFs are changed with a three-message exchange of a DSC-REQ, DSC-RSP, and DSC-ACK. DSD Dynamic Service Delete. A DOCSIS MAC management message requesting the deletion of a Service Flow. SFs are deleted with a two-message exchange of a DSD-REQ and DSD-ACK.
Top   ToC   RFC4323 - Page 4
   Head-end        The origination point in most cable systems of the
                   subscriber video signals.  It is generally also the
                   location of the CMTS.

   PHS             Payload Header Suppression.  A feature of DOCSIS 1.1
                   and 2.0 in which header bytes that are common in a
                   sequence of packets of a Service Flow are replaced by
                   a one-byte PHSI Index (PHSI) when transmitting the
                   packet on the RF network.

   primary SF      Primary Service Flow.  All CMs have a Primary
                   Upstream Service Flow and a Primary Downstream
                   Service Flow.  They provide a default path for
                   forwarded packets that are not classified to any
                   other Service Flow.

   Provisioned QPS A QoS Parameter Set describing an envelope of service
                   within which a Service Flow is authorized to request
                   admission.  All existing Service Flows must have a
                   non-empty Provisioned QPS; thus, all SFs are
                   considered to be "Provisioned".

   RF              Radio Frequency.  In particular, this abbreviation
                   refers to the radio frequencies for Cable Television

   SCN             Service Class Name.  A named set of QoS parameters.
                   A Service Flow may or may not be associated with a
                   single named Service Class.  A Service Class has as
                   an attribute a QoS Parameter Set that is used as the
                   default set of values for all Service Flows belonging
                   to the Service Class.

   SID             Service ID.  A 16-bit unsigned integer assigned by
                   the CMTS for an Upstream Service Flow with a non-
                   empty Active QoS Parameter Set.

   SF              Service Flow.  A unidirectional stream of packets
                   between the CM and CMTS.  SFs are characterized as
                   upstream or downstream.  The SF is the fundamental
                   unit of service provided on a DOCSIS CATV network.

   SFID            Service Flow ID.  A 32-bit unsigned integer assigned
                   by the CMTS to each Service Flow.

   Upstream        The direction from a subscriber CM to the head-end
Top   ToC   RFC4323 - Page 5

2. Overview

This MIB module provides a set of objects required for the management of DOCSIS 1.1 and 2.0 compliant Cable Modems (CM) and Cable Modem Termination Systems (CMTS). The specification is derived from the DOCSIS 2.0 Radio Frequency Interface specification [4]. Please note that the referenced DOCSIS specifications only requires Cable Modems to process IPv4 customer traffic. Design choices in this MIB module reflect those requirements. Future versions of the DOCSIS standard are expected to require support for 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 RFC 2119 [5].

2.1. Textual Conventions

The textual convention "DocsIetfQosRfMacIfDirection" is defined to indicate the direction of a packet classifier relative to an interface. It takes the values of either downstream(1) or upstream(2). The textual convention "DocsIetfQosBitRate" corresponds to the bits per second as defined for QoS Parameter Sets in DOCSIS 1.1 and 2.0. This definition includes all bits of the Ethernet MAC frame as transmitted on the RF network, starting with the Destination Address and ending with the Ethernet Frame Check Sequence (FCS). It does NOT includes bits in the DOCSIS MAC header.

2.2. MIB Organization

The structure of the IPCDN QoS MIB module (DOCS-IETF-QOS-MIB) is summarized below: docsIetfQosMIB docsIetfQosMIBObjects docsIetfQosPktClassTable docsIetfQosPktClassEntry docsIetfQosPktClassId docsIetfQosPktClassDirection docsIetfQosPktClassPriority docsIetfQosPktClassIpTosLow docsIetfQosPktClassIpTosHigh docsIetfQosPktClassIpTosMask docsIetfQosPktClassIpProtocol docsIetfQosPktClassInetAddressType docsIetfQosPktClassInetSourceAddr docsIetfQosPktClassInetSourceMask
Top   ToC   RFC4323 - Page 6
Top   ToC   RFC4323 - Page 7
Top   ToC   RFC4323 - Page 8
Top   ToC   RFC4323 - Page 9

   This MIB module is organized as 11 tables.  Most tables are
   implemented in both the CM and CMTS; the
   docsIetfQosUpstreamStatsTable and docsIetfQosServiceFlowLogTable are
   implemented on the CMTS only.

2.2.1. docsIetfQosPktClassTable

The docsIetfQosPktClassTable reports the Service Flow Classifiers implemented by the managed device. The table is indexed by the tuple { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId }. The ifIndex corresponds to a CATV MAC interface. Each CATV MAC interface has a set of Service Flows identified with a docsIetfQosServiceFlowId value that is unique for that interface. Each Service Flow may have a number of packet classifiers that map packets to the flow. The ClassifierId for the classifier is unique only within a particular Service Flow. The semantics of packet classification are provided in [4]. Briefly, the DOCSIS MAC interface calls for matching packets based on values within the 802.2 (LLC), 802.3, IP, and/or UDP/TCP headers. Packets that map more than one classifier are prioritized according to their docsIetfQosPktClassPriority values. The docsIetfQosServiceFlowId (an index object) indicates to which Service Flow the packet is classified. The docsIetfQosPktClassTable is distinct from the docsDevIpFilterTable of [6] in that docsIetfQosPktClassTable is intended only to reflect the state of the Service Flow Classifiers. Service Flow Classifiers may be created only via a CM configuration file or from the Dynamic Service Addition (DSA) messages. For this reason, docsIetfQosPktClassTable is read-only. The docsDevIpFilterTable is intended for external policy-based administration of packet classifiers. See the section "Externally Administered Classification", below.
Top   ToC   RFC4323 - Page 10

2.2.2. docsIetfQosParamSetTable

The docsIetfQosParamSetTable reports the values of QoS Parameter Set as defined in Section C.2.2 of [4]. In general, a Service Flow is associated with three different QoS Parameter Sets (QPSs): an "active" QPS, an "admitted" QPS, and a "provisioned" or "authorized" QPS. The relationship of these three sets is represented below: +---------------------+ | Provisioned | | | | +---------------+ | | | Admitted | | | | | | | | +---------+ | | | | | Active | | | | | | | | | | | +---------+ | | | | | | | +---------------+ | | | +---------------------+ Figure 1: QoS Parameter Sets The Provisioned QPS describes the maximum service envelope for which the SF is authorized. The Admitted QPS is the set of services for which a Service Flow has requested admission to the DOCSIS RF network, but which is not yet active. The Admitted QPS is used during the two-phase process of IP Telephony/PacketCable Service Flow admission to admit the bandwidth for a bidirectional voice call when the far end is ringing. Because ringing may occur for up to four minutes, this permits the bandwidth to be reserved but not actually consumed during this interval. The Active QPS is the set of services actually being used by the Service Flow. The DOCSIS v1.1 specification [4] defines what it means for a QPS envelope to be "within" another. In general, an inner QPS is considered "within" an outer QPS when all QoS parameters represent demands of equal or fewer resources of the network. In addition to its use as an attribute of a Service Flow, a QPS is also an attribute of a Service Class. A DOCSIS CM configuration file or DSA message may request the creation of a new SF and give only the Service Class Name. The CMTS "expands the macro" of a Service Class Name creation by populating the Provisioned, Admitted, and/or Active QPSs of the Service Flow with the QPS of the Service Class Name. All
Top   ToC   RFC4323 - Page 11
   the QPSs of a Service Flow must be expansions of the same Service
   Class, and in this case the SF is said to "belong" to the Service
   Class.  Changing the contents of a Service Class' QPS does not affect
   the QPS of any Service Flow earlier expanded from that Service Class
   name.  Only the CMTS implements docsIetfQosServiceClassTable.

   See [4], section 8, for a full description and the theory of
   operation of DOCSIS 1.1 QoS operation.

   The docsIetfQosParamSetTable sets are indexed by { ifIndex,
   docsIetfQosServiceFlowId, docsIetfQosParamSetType}.  ifIndex
   indicates a particular "DOCSIS MAC Domain".  docsIetfQosServiceFlowId
   uniquely identifies a Service Flow on that MAC domain.  The
   docsIetfQosParamSetType indicates whether the row describes an
   active, admitted, or provisioned QoS Parameter Set.

   The docsIetfQosParamSetTable is read-only because it indicates the
   QoS Parameter Set contents as defined by DOCSIS signaling.  The
   docsIetfQosServiceClassTable is read-create to permit managers to
   define a template of QoS Parameters that can be referenced by DOCSIS
   modems when creating their QoS Parameter Sets. Interoperation with DOCSIS 1.0
The DOCS-IF-MIB [7] specifies a docsIfQosProfileTable to describe the set of Class Of Service (COS) parameters associated with a COS "profile". The docsIfCmServiceTable, which contains one entry per SID, references this table with a docsIfCmServiceQosProfile number. The DOCSIS 1.1 and 2.0 CM registration process allows a modem to register as operating with DOCSIS 1.0, DOCSIS 1.1, or DOCSIS 2.0 functionality. For ease of expression, we call a modem registering with DOCSIS 1.0 functionality a "DOCSIS 1.0 modem", regardless of the modem's capabilities. A CMTS or CM supporting DOCSIS 1.0, as well as DOCSIS 1.1, and/or DOCSIS 2.0 implements both the tables of [7] and the tables of this MIB module. The interoperation goal is that before modem registration, the DOCSIS 1.0 MIB [7] applies. After registration, either the DOCSIS 1.0 or DOCSIS 1.1/2.0 MIB applies, depending on the mode with which the modem registered. The specific interoperation rules are: 1. When a CM initially ranges, the CM implements a row in the DOCS-IF-MIB docsIfCmServiceTable, and the CMTS implements a row in the DOCS-IF-MIB docsIfCmtsServiceTable corresponding to the default upstream Service ID (SID) used for pre-registration
Top   ToC   RFC4323 - Page 12
         upstream traffic.  For historical compatibility, a row may be
         created for the docsIfQosProfileTable with default values,
         which may be referenced by the docsIfCmServiceTable entries.

     2.  Both a CMTS and CM implementing this MIB MUST NOT implement
         docsIetfQosParamSetTable or docsIetfQosServiceFlowTable rows
         until after the CM registers with DOCSIS 1.1 or 2.0 modem

     3.  When a modem registers with the CMTS as a "DOCSIS 1.1" or
         "DOCSIS 2.0" modem, any exclusively-referenced row in DOCS-IF-
         MIB docsIfQosProfileTable representing the modem's upstream QoS
         profile for pre-registration traffic MUST be removed.
         Multiply-referenced rows may remain.  The
         docsIfCmServiceQosProfile object in the CM's row of

         docsIfCmServiceTable MUST be set to zero.  The
         docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem
         continues to exist, and the various statistic objects in that
         row are incremented.  The CMTS should retain a
         docsIfCmtsServiceTable entry for the DOCSIS 1.1 or DOCSIS 2.0

     4.  When a DOCSIS 1.1 or DOCSIS 2.0 modem registers, both the CMTS
         and CM represent all Service Flows described in the modem
         configuration file in docsIetfQosParamSetTable and

     5.  DOCSIS 1.0 modems do not have entries in the DOCS-IETF-QOS-MIB.

2.2.3. docsIetfQosServiceFlowTable

The docsIetfQosServiceFlowTable provides read-only information about all the Service Flows known by the device. It is indexed by the combination of { ifIndex, dosQosServiceFlowId }, where ifIndex corresponds to a CATV MAC interface and docsIetfQosServiceFlowId is the 32-bit integer assigned by the CMTS controlling the MAC domain. A CM typically has only a single CATV MAC interface, whereas a CMTS may have several. See [7] for a description of the ifIndex numbering for DOCSIS devices. The table indicates whether a given SF is in the upstream or downstream direction, and whether it is the "primary" SF in that direction. The primary SF carries traffic that is not otherwise classified to any other SF in that direction.
Top   ToC   RFC4323 - Page 13

2.2.4. docsIetfQosServiceFlowStatsTable

The docsIetfQosServiceFlowStatsTable provides statistics for all currently existing SFs known by the managed device. It provides basic packet and octet counters, as well as certain other SF-specific stats such as the time at which the flow was created and how many seconds it has been active. The table also provides objects that can be used to fine-tune admission control decisions; namely, the number of packets dropped or delayed due to QoS policing decisions enforced by the managed device. The model of the Service Flows stats table is that there exists a Service Flow Classification function followed by a Service Flow maximum rate Policing function for packets transmitted onto the DOCSIS RF network, as depicted below. +----------+ +------------+ clsfy 1 -----+ | Per-SF | forwarded Pkts | |-----------> | | Maximum |-> for DOCSIS ----->| Classify | clsfy 2 SF1 |--> | Rate | RF Network | Function |-----------> | | Policing | transmission | | -----+ | Function | | | | |----+ | | | | | | | +----------+ Dropped +------------+ | ^ +----+ Delayed Packets intended for transmission onto the DOCSIS RF network (upstream or downstream) are first classified to a Service Flow by matching one of several possible classifiers associated with that Service Flow. The docsIetfQosPktClassPkts count includes the number of packets that match the classifier, regardless of the eventual disposition of the packet. DOCSIS requires that each Service Flow be policed to maintain a maximum rate of transmission. This is performed by either dropping or delaying a packet on that Service Flow. The docsIetfQosServiceFlowPolicedDropPkts object counts the number of Service Flow packets dropped by the policing function. The docsIetfQosServiceFlowPolicedDelayPkts counts the number of packets delayed but still forwarded. The docsIetfQosServiceFlowPkts object counts the total number of packets forwarded beyond the policing function intended for eventual transmission onto the DOCSIS RF network. Although packets may later be dropped by other functions (e.g., a transmit queue overflow on a DOCSIS hardware transmitter), the docsIetfQos MIB per service-flow counters are not affected.
Top   ToC   RFC4323 - Page 14

2.2.5. docsIetfQosUpstreamStatsTable

This table provides statistics that are measured only at the CMTS in the upstream direction. These include counts of fragmentation headers received, fragments discarded, and concatenation headers received.

2.2.6. docsIetfQosDynamicServiceStatsTable

This table provides read-only stats on the operation of the Dynamic Service state machines as specified in section 9.4 of [4]. It provides a set of 14 counters in each direction for a DOCSIS MAC layer interface. That is, each DOCSIS MAC layer interface has one row for downstream stats and a second row for upstream stats. Eight of the counters are DSx packet type counts, one counter for each of the eight DSx packet types. For example, the docsIetfQosDSAReqs object in the upstream row at the CMTS counts the number of DSA-REQ messages received by the CMTS from that interface. The docsIetfQosDSAReqs object in the downstream row at the CMTS counts the number of DSA-REQ messages transmitted by the CMTS on that interface. The remaining six counters per (interface, direction) combination count the number of successful and unsuccessful transactions that were initiated on the interface and direction. For example, the upstream docsIetfQosDynamicAdds on a CMTS is the number of successfully completed CM-initiated dynamic additions, because at the CMTS a CM-initiated DSA starts in the upstream direction. The downstream docsIetfQosDynamicAdds at a CMTS is the number of successful CMTS-initiated DSA transactions. Dynamic service transactions can fail for a number of reasons, as listed in the state machines of section 9.4. Rather than include still more counters for each different failure reason, they are grouped into a single count, e.g., docsIetfQosDynamicAddFails. Again, this object exists in both directions, so that locally originated and remotely originated transaction failures are counted separately. Further troubleshooting of transaction failures will require vendor-specific queries and operation.

2.2.7. docsIetfQosServiceFlowLogTable

This table contains a log of the Service Flows that no longer exist in the docsIetfQosServiceFlowTable. It is intended to be periodically polled by traffic monitoring and billing agents. It is implemented only at the CMTS.
Top   ToC   RFC4323 - Page 15
   It contains a chronological log of SF session statistics, including a
   total count of packets and octets transferred on the SF.  It includes
   time stamps of the SF creation and deletion time, and of its number
   of active seconds.  The active second count is the count of seconds
   that the SF had a non-empty Active QoS Parameter Set, i.e., it was
   eligible to pass data.  For unicast SFs, it includes the CM MAC
   address associated with the flow for billing reference purposes.

   The maximum number of log records kept by a CMTS and the duration
   that a log record is maintained in the table are vendor-specific.  An
   explicit control object is provided so that the monitoring
   application can explicitly delete records it has read.

2.2.8. docsIetfQosServiceClassTable

This table defines the Service Class Name and references a QoS Parameter Set for each Service Class defined in a CMTS. It is indexed by the Service Class Name string itself. The table is read- create on a CMTS, and is not implemented in a CM. Each entry of the docsIetfQosServiceClassTable should define a template for flows in a given direction (upstream or downstream). Some parameters of the docsIetfQosServiceClassTable are specific to a particular direction, and so their values are not applicable when used as a template for flows in the other direction.

2.2.9. docsIetfQosServiceClassPolicyTable

The docsIetfQosServiceClassPolicyTable can be referenced by the docsDevFilterPolicyTable of [6] in order to have a "policy" that classifies packets to a named Service Class. This is one mechanism by which "external" entities (such as an SNMP manager) may control the classification of a packet for QoS purposes. Entries are indexed by a small-integer docsIetfQosServiceClassPolicyIndex. They provide a Service Class Name and a Rule Priority. A policy referencing a row of this table intends the packet to be forwarded on a Service Flow "belonging" to the named Service Class. See section 3, "Externally Administered Classification", below. This table is implemented on both the CM and CMTS, and is read-create on both.
Top   ToC   RFC4323 - Page 16

2.2.10. docsIetfQosPHSTable

The Payload Header Suppression (PHS) feature of DOCSIS 1.1 and 2.0 permits packets to replace the unchanging bytes of the Ethernet, IP, and UDP headers with a one-byte index when transmitting on the cable network. This is especially useful for IP Telephony packets, where such suppression can result in almost twice the number of calls supported within the same upstream channel. Each entry of the table corresponds to a PHS Rule as described in section 8.4 of [4]. The rules are identified by their corresponding Service Flow ID and docsIetfQosPktClassId. A PHS rule is associated with exactly one classifier. The table is therefore indexed by the tuple { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId}. This table is read-only, and MUST be implemented on both the CM and CMTS when PHS is supported.

2.2.11 docsIetfQosCmtsMacToSrvFlowTable

The docsIetfQosCmtsMacToSrvFlowTable describes the mapping of CM MAC addresses to the Service Flow IDs that are uniquely identified with that CM. External applications may collect statistics on all packets flowing through a CM by determining the SFID of all of its flows, and then collecting the statistics of packets and bytes for each flow. Downstream multicast Service Flows are not indicated in the docsIetfQosCmtsMacToSrvFlowTable because they are not associated with only one CM.

3. Externally Administered Classification

DOCSIS 1.1 and 2.0 provide rich semantics for the classification of packets to Service Flows with the Service Flow Classifier table. Service Flow Classifiers may be created statically in the DOCSIS CM configuration file, or may be created dynamically with Dynamic Service Addition (DSA) and Dynamic Service Change (DSC) DOCSIS MAC messages. Several major issues arose with the concept of externally administered classification; e.g., should an external SNMP manager be permitted to create classification rows? One problem was the coordination of classifier IDs because such an approach would require either separate classifier ID number spaces or objects to coordinate both internal and external classifier ID assignments. A more serious problem, however, was that external creation of SF Classifiers would require "knowledge" of the individual Service Flow ID for Service Flows by external applications. It was strongly felt by the
Top   ToC   RFC4323 - Page 17
   committee that SFIDs should remain internal DOCSIS objects, and not
   be transmitted as part of protocol flows, e.g., for IP packet
   telephony signaling.  DOCSIS 1.1 introduced the concept of named
   Service Classes for ease of administration within a domain of CMs and
   CMTSs.  What was desired was to permit external classification of
   packets to a Service Class, not to a particular Service Flow.

   The DOCSIS committee therefore decided to use the already-defined IP
   Packet Filter Table [6] for the external classification of packets
   for QoS purposes.  The docsDevIpPacketFilterTable defines similar
   packet matching criteria as does docsIetfQosPktClassTable, but it
   matches a packet to an arbitrary "policy set" instead of a particular
   Service Flow.  One of the policies in the policy set then selects the
   Service Class of the SF on which to forward the packet.  The
   docsIetfQosServiceClassPolicyTable of this MIB module defines the
   Service Class Name to which a packet is classified.

   The interaction of external and internal packet classification is
   depicted below.
Top   ToC   RFC4323 - Page 18
              |  Outbound Pkt
          docsDevIpFilterTable------> docsDevFilterPolicyTable
              |                                   |
              |                                   V
              |                      docsIetfQosServiceClassPolicyTable
              |                                   |
          Pkt |                  ServiceClassName,|
              |     ServiceClassPolicyRulePriority|
              V                                   V
     |        |   DOCSIS MAC LAYER ENTITY         |           |
     |        |                                   | Select    |
     |        V                                   | any       |
     |    docsIetfQosPktClassTable <--------------| SFID Y    |
     |        |                                   | in SCN    |
     |        | docsIetfQosPktClassPriority,      |           |
     |        | SFID X                            |           |
     |        V                                   V           |
     |   +--------------------------------------------+       |
     |   | Select the SFID associated with the        |       |
     |   | higher of docsIetfQosPktClassPriority or   |       |
     |   | docsIetfQosServiceClassPolicyRulePriority  |       |
     |   +--------------------------------------------+       |
     |                             |                          |
     |                             V                          |
     |           |    |          |    |                       |
     |           |    |    ...   |    |  Service Flows        |
     |           +----+          +----+                       |
     |           SFID X          SFID Y                       |

          Figure 2: DOCSIS Packet Classification

   The processing of an outgoing packet proceeds as follows:

     1.  The packet is first checked for matches with rows of the
         docsDevIpFilterTable.  If it matches, the matching row provides
         a docsDevFilterPolicyId integer.

     2.  The docsDevFilterPolicyId indexes into one (or more) rows of
         docsDevFilterPolicyTable.  Each row provides an arbitrary
         RowPointer (docsDevFilterPolicyPtr), corresponding to a policy
         to be applied to the packet.
Top   ToC   RFC4323 - Page 19
     3.  This MIB module defines a docsIetfQosServiceClassPolicyTable
         whose entries may be pointed to by docsDevFilterPolicyPtr in
         order to classify packets administratively to a named DOCSIS
         Service Class.  The docsIetfQosServiceClassPolicyEntry provides
         a Service Class Name (SCN) as docsIetfQosServiceClassPolicyName
         and a classification rule priority as
         docsIetfQosServiceClassPolicyRulePriority.  These are submitted
         to the device's DOCSIS MAC Layer entity as a special form of
         the MAC_DATA.request primitive, as described in Section E.2.1
         of [4].

     4.  The MAC Layer selects an SFID ("Y") of an active Service Flow
         belonging to the named class, choosing an SF arbitrarily if
         there is more than one.

     5.  The packet is then classified according to the
         docsIetfQosPktClassTable, which may classify the packet to a
         different SFID "X".  Associated with the classifier is a

     6.  In the event of a conflict between the SCN-determined SFID and
         the classified SFID, the greater of docsIetfQosPktClassPriority
         and docsIetfQosServiceClassPolicyRulePriority determines which
         SFID is selected to forward the packet.

   A packet that does not match a docsIetfQosServiceClassPolicyEntry is
   directly submitted to the DOCSIS MAC layer, where the
   docsIetfQosPktClassTable selects the SID on which it is to be

   By convention (in [4]), the "internal" docsIetfQosPktClassPriority
   values should be in the range 64-191, while the "external" priorities
   may be either in the range 192-255 to override the internal
   classification or in the range 0-63 to be overridden by internal

   This classification mechanism applies both upstream from the CM and
   downstream from the CMTS.

4. DOCSIS and IPv4 Type-of-Service (ToS) Field

The DOCSIS-IETF-QOS-MIB MIB module relies on the DOCSIS MAC layer protocols and uses objects that reflect the IPv4 Type-of-Service (ToS) octet as defined in [14]. The applicability of these objects is limited to the DOCSIS access network. The past and current versions of the DOCSIS specifications for which this MIB module is defined do not reflect Differentiated Services [9] on the DOCSIS access network. However, with proper selection of values for these
Top   ToC   RFC4323 - Page 20
   objects, the network operator can enforce Differentiated Services
   Per-hop Behaviors (PHBs) on the DOCSIS Access Network, and can
   configure the modification of the DSCP for certain packet flows as
   they enter the metro network from the access network.  Essentially
   this makes the DOCSIS access network TOS marking compatible with the
   wider use of DSCP outside DOCSIS networks.  Note that because the
   entire IPv4 TOS octet may be available for modification via the
   latter mechanism (due to the current MAC level DOCSIS protocols and
   CLI interface configuration), it is possible that the DOCSIS network
   could be configured to modify the Explicit Congestion Notification
   (ECN) bits [10] of certain packets.  This modification of the ECN
   bits is prevented by the MIB module's design.  The MIB module
   prohibits the modification of the TOS octet (read-only objects:
   docsIetfQosPktClassIpTosLow, docsIetfQosPktClassIpTosHigh
   docsIetfQosPktClassIpTosMask, docsIetfQosParamSetTosAndMask,
   docsIetfQosParamSetTosOrMask) and allows the DSCP field to be
   modified (read-create object: docsIetfQosServiceClassDSCPOverwrite).

(page 20 continued on part 2)

Next Section