RFC 4323
Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)
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).Abstract
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.
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 2.2.2.1. 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 ........................................871. 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].
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.
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
(CATV).
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
CMTS.
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
docsIetfQosPktClassInetDestAddr
docsIetfQosPktClassInetDestMask
docsIetfQosPktClassSourcePortStart
docsIetfQosPktClassSourcePortEnd
docsIetfQosPktClassDestPortStart
docsIetfQosPktClassDestPortEnd
docsIetfQosPktClassDestMacAddr
docsIetfQosPktClassDestMacMask
docsIetfQosPktClassSourceMacAddr
docsIetfQosPktClassEnetProtocolType
docsIetfQosPktClassEnetProtocol
docsIetfQosPktClassUserPriLow
docsIetfQosPktClassUserPriHigh
docsIetfQosPktClassVlanId
docsIetfQosPktClassStateActive
docsIetfQosPktClassPkts
docsIetfQosPktClassBitMap
docsIetfQosParamSetTable
docsIetfQosParamSetEntry
docsIetfQosParamSetServiceClassName
docsIetfQosParamSetPriority
docsIetfQosParamSetMaxTrafficRate
docsIetfQosParamSetMaxTrafficBurst
docsIetfQosParamSetMinReservedRate
docsIetfQosParamSetMinReservedPkt
docsIetfQosParamSetActiveTimeout
docsIetfQosParamSetAdmittedTimeout
docsIetfQosParamSetMaxConcatBurst
docsIetfQosParamSetSchedulingType
docsIetfQosParamSetNomPollInterval
docsIetfQosParamSetTolPollJitter
docsIetfQosParamSetUnsolicitGrantSize
docsIetfQosParamSetNomGrantInterval
docsIetfQosParamSetTolGrantJitter
docsIetfQosParamSetGrantsPerInterval
docsIetfQosParamSetTosAndMask
docsIetfQosParamSetTosOrMask
docsIetfQosParamSetMaxLatency
docsIetfQosParamSetType
docsIetfQosParamSetRequestPolicyOct
docsIetfQosParamSetBitMap
docsIetfQosServiceFlowTable
docsIetfQosServiceFlowEntry
docsIetfQosServiceFlowId
docsIetfQosServiceFlowSID
docsIetfQosServiceFlowDirection
docsIetfQosServiceFlowPrimary
docsIetfQosServiceFlowStatsTable
docsIetfQosServiceFlowStatsEntry
docsIetfQosServiceFlowPkts
docsIetfQosServiceFlowOctets
docsIetfQosServiceFlowTimeCreated
docsIetfQosServiceFlowTimeActive
docsIetfQosServiceFlowPHSUnknowns
docsIetfQosServiceFlowPolicedDropPkts
docsIetfQosServiceFlowPolicedDelayPkts
docsIetfQosUpstreamStatsTable
docsIetfQosUpstreamStatsEntry
docsIetfQosSID
docsIetfQosUpstreamFragments
docsIetfQosUpstreamFragDiscards
docsIetfQosUpstreamConcatBursts
docsIetfQosDynamicServiceStatsTable
docsIetfQosDynamicServiceStatsEntry
docsIetfQosIfDirection
docsIetfQosDSAReqs
docsIetfQosDSARsps
docsIetfQosDSAAcks
docsIetfQosDSCReqs
docsIetfQosDSCRsps
docsIetfQosDSCAcks
docsIetfQosDSDReqs
docsIetfQosDSDRsps
docsIetfQosDynamicAdds
docsIetfQosDynamicAddFails
docsIetfQosDynamicChanges
docsIetfQosDynamicChangeFails
docsIetfQosDynamicDeletes
docsIetfQosDynamicDeleteFails
docsIetfQosDCCReqs
docsIetfQosDCCRsps
docsIetfQosDCCAcks
docsIetfQosDCCs
docsIetfQosDCCFails
docsIetfQosServiceFlowLogTable
docsIetfQosServiceFlowLogEntry
docsIetfQosServiceFlowLogIndex
docsIetfQosServiceFlowLogIfIndex
docsIetfQosServiceFlowLogSFID
docsIetfQosServiceFlowLogCmMac
docsIetfQosServiceFlowLogPkts
docsIetfQosServiceFlowLogOctets
docsIetfQosServiceFlowLogTimeDeleted
docsIetfQosServiceFlowLogTimeCreated
docsIetfQosServiceFlowLogTimeActive
docsIetfQosServiceFlowLogDirection
docsIetfQosServiceFlowLogPrimary
docsIetfQosServiceFlowLogServiceClassName
docsIetfQosServiceFlowLogPolicedDropPkts
docsIetfQosServiceFlowLogPolicedDelayPkts
docsIetfQosServiceFlowLogControl
docsIetfQosServiceClassTable
docsIetfQosServiceClassEntry
docsIetfQosServiceClassName
docsIetfQosServiceClassStatus
docsIetfQosServiceClassMaxTrafficRate
docsIetfQosServiceClassMaxTrafficBurst
docsIetfQosServiceClassMinReservedRate
docsIetfQosServiceClassMinReservedPkt
docsIetfQosServiceClassMaxConcatBurst
docsIetfQosServiceClassNomPollInterval
docsIetfQosServiceClassTolPollJitter
docsIetfQosServiceClassUnsolicitGrantSize
docsIetfQosServiceClassNomGrantInterval
docsIetfQosServiceClassTolGrantJitter
docsIetfQosServiceClassGrantsPerInterval
docsIetfQosServiceClassMaxLatency
docsIetfQosServiceClassActiveTimeout
docsIetfQosServiceClassAdmittedTimeout
docsIetfQosServiceClassSchedulingType
docsIetfQosServiceClassRequestPolicy
docsIetfQosServiceClassTosAndMask
docsIetfQosServiceClassTosOrMask
docsIetfQosServiceClassDirection
docsIetfQosServiceClassStorageType
docsIetfQosServiceClassDSCPOverwrite
docsIetfQosServiceClassPolicyTable
docsIetfQosServiceClassPolicyEntry
docsIetfQosServiceClassPolicyIndex
docsIetfQosServiceClassPolicyName
docsIetfQosServiceClassPolicyRulePriority
docsIetfQosServiceClassPolicyStatus
docsIetfQosServiceClassPolicyStorageType
docsIetfQosPHSTable
docsIetfQosPHSEntry
docsIetfQosPHSField
docsIetfQosPHSMask
docsIetfQosPHSSize
docsIetfQosPHSVerify
docsIetfQosPHSIndex
docsIetfQosCmtsMacToSrvFlowTable
docsIetfQosCmtsMacToSrvFlowEntry
docsIetfQosCmtsCmMac
docsIetfQosCmtsServiceFlowId
docsIetfQosCmtsIfIndex
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.
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
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.2.2.2.1. 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
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
operation.
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
CM.
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
docsIetfQosServiceFlowTable.
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.
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.
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.
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.
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
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.
| | Outbound Pkt V 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.
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
docsIetfQosPktClassPriority.
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
forwarded.
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
classification.
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
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)
