C-DOCSIS Service Class
Service Classes
The QoS attributes of a Service Flow may be specified in two ways: either by explicitly defining all attributes, or
implicitly by specifying a Service Class Name. A Service Class Name is a string which the CMTS associates with a
QoS Parameter Set.
The Service Class serves the following purposes:
1. It allows operators, who so wish, to move the burden of configuring service flows from the provisioning server
to the CMTS. Operators provision the modems with the Service Class Name; the implementation of the name is
configured at the CMTS. This allows operators to modify the implementation of a given service to local
circumstances without changing modem provisioning. For example, some scheduling parameters may need to
be tweaked differently for two different CMTSs to provide the same service. As another example, service
profiles could be changed by time of day.
2. It allows CMTS vendors to provide class-based-queuing if they choose, where service flows compete within
their class and classes compete with each other for bandwidth.
3. It allows higher-layer protocols to create a Service Flow by its Service Class Name. For example, telephony
signaling may direct the CM to instantiate any available Provisioned Service Flow of class "G711".
4. It allows packet classification policies to be defined which refer to a desired service class, without having to
refer to a particular service flow instance of that class.
NOTE: The Service Class is optional: the flow scheduling specification may always be provided in full; a
service flow may belong to no service class whatsoever. CMTS implementations MAY treat such
"unclassed" flows differently from "classed" flows with equivalent parameters
Any Service Flow MAY have each of its QoS Parameter Sets specified in any of three ways:
1. By explicitly including all traffic parameters;
2. By indirectly referring to a set of traffic parameters by specifying a Service Class Name;
3. By specifying a Service Class Name along with modifying parameters.
The Service Class Name is "expanded" to its defined set of parameters at the time the CMTS successfully admits the
Service Flow. The Service Class expansion can be contained in the following CMTS-originated messages:
Registration Response, DSA-REQ, DSC-REQ, DSA-RSP and DSC-RSP. In all of these cases, the CMTS MUST
include a Service Flow Encoding that includes the Service Class Name and the QoS Parameter Set of the Service
Class. If a CM-initiated request contained any supplemental or overriding Service Flow parameters, a successful
response from the CMTS MUST also include these parameters.
When a Service Class name is given in an admission or activation request, the returned QoS Parameter Set may
change from activation to activation. This can happen because of administrative changes to the Service Class’ QoS
Parameter Set at the CMTS.
The CMTS MAY change the QoS parameters of all downstream service flows (including both Individual and Group
Service Flows) derived from a Service Class when the QoS parameters of the Service Class are changed.
The CMTS MAY change the QoS parameters of all upstream service flows derived from a Service Class when those
QoS parameters of the Service Class are changed.
QoS parameters for downstream service flows, or CMTS-enforced QoS parameters for upstream service flows,
can be changed locally at the CMTS, without sending a Dynamic Service Change message to the affected CM.
In order to change the CM-enforced QoS parameters of an upstream service flow, it is necessary for the CMTS
to send a Dynamic Service Change message to the affected CM.
The CM-enforced QoS parameters of an upstream service flow include:
• Upstream Maximum Sustained Traffic Rate
• Maximum Traffic Burst
• Maximum Concatenated Burst
• Service Flow Scheduling Type
All other QoS parameters are CMTS-enforced.
When a CM uses the Service Class Name to specify the Admitted QoS Parameter Set, the expanded set of TLV
encodings of the Service Flow will be returned to the CM in the response message (REG-RSP, REG-RSP-MP,
DSA-RSP, or DSC-RSP).
Use of the Service Class Name later in the activation request may fail if the definition of
the Service Class Name has changed and the new required resources are not available.
Thus, the CM SHOULD explicitly request the expanded set of TLVs from the response message in its later activation request.