This document answers frequently asked questions about the Data Over Cable Service Interface Specification (DOCSIS) 1.0.
A. Data-over-Cable Service Interface Specifications (DOCSIS) 1.0+ implementation is DOCSIS 1.0 with Quality of Service (QoS) extensions for supporting realtime voice, fax, and video on a LAN. DOCSIS 1.0+ is not a new or intermediate specification by cable labs. The whole DOCSIS1.0+ architecture is a time-to-market solution provided by Cisco and certain cable modem vendors until DOCSIS 1.1 specifications and development are widely available.
A. Yes. DOCSIS 1.0+ is fully backward-compatible with DOCSIS 1.0. It is important to remember that all the special QoS services of the DOCSIS 1.0+ Cable Modem Termination System (CMTS) are only activated when a DOCSIS 1.0+ cable modem (CM) solicits these services via new dynamic Media Access Control (MAC) messages. If your CM is pure DOCSIS 1.0, it will not be able to activate those services and will get regular DOCSIS 1.0 treatment from the DOCSIS 1.0+ CMTS.
A. DOCSIS 1.0+ provides additional QoS features for realtime voice, fax, and data packets from the Integrated Telephony Cable Modems (ITCMs). In DOCSIS 1.0+, the private extensions added to DOCSIS 1.0 are:
Two new CM-initiated dynamic MAC messages: Dynamic Service Addition (DSA) and Dynamic Service Deletion (DSD). These messages allow dynamic Service IDs (SIDs) to be created or deleted at runtime on a per-call basis.
Unsolicited Grant Service (constant bit rate [CBR]-scheduling) on the upstream. This provides high quality QoS channel for the upstream CBR voice and fax packets from the ITCM.
For any given ITCM, ability to provide separate downstream rates based on the IP-precedence value in the packet. This helps separate voice, signaling, and data traffic going to the same ITCM for rate-shaping purposes.
A. Let's take an example where subscriber Mr. X has joined your service and wants the following service package:
One data service with peak upstream (US) rate 128 kBps, peak digital signal (DS) rate 2 Mbps
Two virtual phone lines
Here are the steps to follow:
The provisioning system prepares a configuration file for the ITCM subscriber using any off-the-shelf DOCSIS 1.0 style configuration file editor. The configuration file contains:
A regular DOCSIS 1.0 style Class of Service setting for the data service with US rate 128 kBps, peak DS rate 2 Mbps.
A vendor-specific encoding called "number of phone lines", set to 2.
A vendor-specific encoding called "per IP precedence rate limit tuple", which sets downstream rate limits for IP packets of special precedence.
The ITCM downloads this configuration file at the time of registration, and sends the provisioning information to the DOCSIS 1.0+ CMTS.
When CMTS receives the registration request (REG-REQ), it creates a local database entry for the ITCM. A static SID is immediately assigned to the ITCM for the data service. For the phone line service, the CMTS only creates two deferred service flows (for subsequent activation) in the ITCM's database entry. No SIDs are assigned for the phone line service during registration.
Whenever an ITCM wants to get a voice or fax channel with realtime CBR service, it sends a DSA-REQ MAC message to the CMTS, specifying its special CBR scheduling requirements such as grant-size and grant-interval (grant-size and grant-interval depend on the coder-decoder (CODEC) type G.711/G.729 being used on the ITCM). For more information on CODEC types, see Cisco uBR7200 - QoS/MAC Enhancements for Voice and Fax Calls: DOCSIS 1.0+.
When CMTS receives the DSA-REQ, it first checks in that ITCM's database entry to see if any deferred service flow is available. If a deferred service flow is available, the CMTS assigns a new dynamic SID for that ITCM and triggers unsolicited grants (CBR slots) on that newly assigned dynamic SID. The CMTS informs the ITCM of the newly assigned dynamic SID using the DSA-RSP.
Given that the CMTS can accommodate the new CBR connection, that ITCM keeps getting unsolicited grants of the correct size packet (enough to fit the periodic voice and fax) at correct periodic intervals. The ITCM does not have to contend with any other CM on the upstream for sending these realtime packets. It has a dedicated time-division multiplexing (TDM) sub-channel on the upstream in the form of the unsolicited grants. The jitter is well bounded or limited (you will not get big delay differences between the packets), and good voice quality is thus maintained on the upstream path from ITCM to uBR7200.
The ITCM colors the precedence bits in the IP header of these voice packets with the predefined value of 0x05 for propagating the preferential local access QoS into the IP backbone.
When the voice packets arrive at the CMTS in the CBR slots, they either are switched into the WAN (IP cloud), or forwarded to some other ITCM on the downstream channel.
If they are switched into the WAN cloud, you need to configure the backbone routers, such as the Gigabit Switch Router (GSR), to recognize and give preferential treatment for these voice transport packets (precedence value 0x05) as compared to signaling or regular best effort data packets with precedence 0x3 and 0x0, respectively.
If the upstream packets are switched to the downstream channel of the same uBR7200, the voice packets 0x05 are handled separately for rate limiting as compared to signaling data packets based on their precedence values.
Even if at the time of the call, the destination ITCM was doing a large downstream file transfer, the voice packets forwarded to it on the same downstream will be unaffected by File Transfer Protocol (FTP) on the same ITCM due to the use of IP-precedence values in doing downstream bandwidth accounting.
When the call is finished, the ITCM sends a DSD-REQ to the CMTS to release the dynamic SID. The CMTS stops the CBR grants, destroys the dynamic SID indicated in DSD-REQ, frees up one deferred flow for the ITCM, and sends a DSD-RSP to the ITCM confirming that it has done so.
Q. How do we ensure that an ITCM subscriber provisioned for two virtual phone lines only gets up to two high quality dynamic CBR QoS SIDs at runtime?
A. Each time the ITCM sends a DSA-REQ requesting a new dynamic SID, the CMTS first checks to see whether that ITCM has any unused deferred service flows available before creating a new dynamic SID. If the ITCM already uses two dynamic SIDs, both of its deferred service flows show as in-use at CMTS. As long as a dynamic SID is using the service flow, the service flow is unavailable for the creation of any new dynamic SIDs from this ITCM.
A. No. The virtual phone line concept is very similar to a real phone line. You can transparently use each of its N virtual phone lines to send either a fax or voice call. The DOCSIS 1.0+ CMTS does not enforce what type of application traffic is sent by the ITCM in the unsolicited grants (CBR slots) of its dynamic SID.
A. No. However, DOCSIS 1.0+ CMTS can still provide good realtime CBR service since the absence of fragmentation causes a few msecs of extra jitter for the CBR slots (which is within typical VoIP design budgets for local access links). In addition, DOCSIS 1.0+ does not have packet classification and payload header suppression, both of which are slated for the DOCSIS 1.1 release.
A. For the purpose of this section, we assume that an operator expects three basic packet types on the end-to-end IP network:
IP packets with precedence equal to 0x05 for voice or fax transport
IP packets with precedence equal to 0x03 for voice or fax signaling
IP packets with precedence other than 0x03 or 0x05 for regular data
For end-to-end QoS to work, it is important that all the nodes in the end-to-end network understand and honor the above IP-precedence mapping. All the network nodes starting from ITCM to uBR7200 to backbone router(s) to Trunking Gateway (TGW) will need to have consistent interpretation of the above precedence.
For an ITCM DOCSIS Trivial File Transfer Protocol (TFTP) configuration file, we assume that the ITCM is provisioned with a single Best Effort Data Class and two VoIP phone lines. One immediate variation is to provision two Data Classes, a Best Effort Data Class for Data packets and MAC messages, and one CIR Data Class for voice signaling packets.
For static provisioning of the DOCSIS 1.0 class of service(s) for regular data service, the ITCM can be assigned one or more static DOCSIS 1.0 class of services. The operator is free to choose any combination of the five parameters below to design a custom data service for the ITCM.
A sample DOCSIS 1.0 class of service encoding is provided below to illustrate how a typical ITCM Data Service Class might appear in the configuration file:
Type Length Value (subtype) Length Value Comments 4 28 Class of service configuration 1 1 1 Class ID 1 2 4 2000000 Max downstream rate equals 2 Mbps 3 4 128000 Max upstream rate equals 128 kBps 4 1 5 Upstream priority equals 5 5 4 0 No minimum upstream rate 6 2 1800 Max transmit burst equals 1800 bytes
Pre-provisioning the Number of Phone Lines and Provisioning the IP-precedence Rate Limits for Downstream
These two new objects are not part of the regular DOCSIS 1.0 class of service, and thus are encoded using "Vendor Specific Information" as shown below:
Type Length Value (subtype) Length Value Comments 43 28 Vendor spec info 8 3 0x00 0x00 0x00 Cisco vendor ID
Cisco Vendor Specific Subtype Length Value 43:8:X
Type Length Value (subtype) Length Value Comments 10 1 2 Two phone lines allowed for the ITCM 11 18 1 1 0x05 0x00 0x00 Voice-transport precedence (5) 2 4 128000 Downstream rate limit 128 kBps for 0x05 1 1 0x03 Voice-signaling precedence (3) 2 4 64000 Downstream rate limit 64 kBps for 0x03
Note: All downstream traffic (excepting IP-precedence 0x05 and 0x03) will be rate-shaped together at the default downstream rate limit of 2 Mbps provisioned in the ITCMs DOCSIS 1.0 Data class of service.
A. No. Any regular DOCSIS 1.0 configuration file editor with support for vendor-specific fields will do the job.
Q. Are there any other network-wide configuration issues that need to be taken into account in the DOCSIS 1.0+ environment?
A. Yes. The IP precedence settings used for separating voice and signaling from data must be known and understood. In case of a call where one endpoint is outside the cable network, it is the responsibility of the "outside" network to ensure that all voice packets are colored appropriately before forwarding them to the uBR7200. In case of a call where both endpoints are on the cable network, it is the responsibility of the endpoint (ITCM) originating the traffic to color the voice packets before launching them into the network.
Q. Is there an optimal configuration on the uBR7200 for maximizing the number of VoIP calls for each upstream port?
A. Yes. This section illustrates sample physical layer parameters that could be used on the CMTS for upstream channels expected to have high VoIP call density. These parameters try to minimize the physical layer overhead encountered for each fixed-size (89 bytes) voice packet. The resulting fine-tuning gives a direct improvement in the number of CBR voice connections that can be admitted on a single upstream channel. The following settings need to be configured for the upstream channel to maximize the number of CBR connections:Minislot size: 8 Symbol rate: 1280 ksymbols/sec Modulation type: QPSK Preamble length: 72 bits FEC error correction (T bytes): 2 bytes FEC codeword length: 52 bytes Guard time: 8 symbols Last codeword: shortened last codeword
To configure the above modulation profile at the CMTS, use the existing CLI as follows:
Create a new qpsk modulation profile template (m) with all default parameters except the "short grant" profile which has special parameters as given below:cmts(config)#cable modulation-profile m qpsk cmts(config)#cable modulation-profile m short 2 52 16 8 qpsk scrambler 152 diff 72 shortened uw8
Configure upstream port (n) on a given interface to use minislot size of 8 ticks and above modulation profile template (m):cmts(config-if)#cable upstream n minislot-size 8 cmts(config-if)#cable upstream n modulation-profile m
A. Cisco IOS® Software release 12.1(01)T supports DOCSIS 1.0+ on the Cisco uBR7200 and uBR924. Cisco IOS Software release 12.07XR will provide the IOS images for the Cisco uBR7200 and uBR924.
A. Currently, DOCSIS 1.1 CMTS is slated for Cisco IOS Software release 12.(1)5EC. Until that time, DOCSIS 1.0+ is the time-to-market solution for realtime voice and fax over hybrid fiber-coaxial (HFC). The migration from DOCSIS 1.0+ to DOCSIS 1.1 is expected to be a software upgrade.
DOCSIS 1.1 provisioning requires a new configuration file editor, and supports all the features of DOCSIS 1.0+ in addition to several advanced QoS features. The Cisco uBR7200 fully supports DOCSIS 1.1 specifications.
A. CableLabs , a non profit organization of cable television system operators that represent North and South America, is in charge of the creation of the DOCSIS specification.
You can find the specifications here:
A. A DOCSIS configuration file is a binary file that has the parameters for cable modems to come online in accordance to what the ISP provisions, such as maximum downstream and upstream rates, maximum upstream burst rate, Class of Service (CoS) or baseline privacy, MIBs, and many other parameters. You can build this file with the Cisco DOCSIS CPE Configurator ( registered customers only) or with several other tools on the Internet. To learn how to build a DOCSIS configuration file, refer to Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator ( registered customers only) .
A Cisco IOS configuration file is an ASCII text file that can contain specific configurations, such as access lists, passwords, Network Address Translation (NAT) configurations, and others. These configurations can be downloaded within the DOCSIS configuration file.
This is an example of a Cisco IOS configuration file named ios.cfg:hostname SUCCEED service line service time deb date local msec service time log date local msec no service password no enable secret enable password ww line con 0 login pass ww line vty 0 4 password ww login snmp community public RO snmp community private RW end
Note: For Cisco cable modems that do not have a console port (similar to the Cisco CVA120 Series), it is a very common practice to send the Cisco IOS configuration embedded in the DOCSIS configuration file.
A. These are the minimum DOCSIS protocol requirements:
Time of Day (ToD) Server
Dynamic Host Configuration Protocol (DHCP)
Trivial File Transfer Protocol (TFTP)
ToD is required; however, Cable Labs has made some modifications that relax this condition. Therefore, it is possible that other cable modem vendors will come online even though they do not pass ToD. If you have Baseline Privacy Interface (BPI) enabled, BPI will be an additional requirement.
Q. Where can I get the Cisco templates for the DOCSIS or BPI DOCSIS configuration files bronze.cm, silver.cm, gold.cm, and platinum.cm?
A. You can get the templates here:
These are the specifications of the templates:
DOCSIS cm File Downstream Speed Upstream Speed Priority CPEs bronze.cm 128000 64000 1 1 bronze-bpi.cm silver.cm 512000 128000 3 1 silver-bpi.cm gold.cm 2048000 512000 6 1 gold-bpi.cm platinum.cm 10000000 1024000 7 3 platinum-bpi.cm
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.