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