Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4323

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

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

Part 1 of 4, p. 1 to 20
None       Next RFC Part


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

   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

   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       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       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",
   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

   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:


Top      ToC       Page 6 

Top      ToC       Page 7 

Top      ToC       Page 8 

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

   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       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       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       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       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       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

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

   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       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       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

   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       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       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       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       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 RFC Part