DOCSIS 1.1 for Cisco uBR905/uBR925 Cable Access Routers and Cisco CVA122 Cable Voice Adapters

This document describes the support for version 1.1 of the Data-over-Cable System Interface Specification (DOCSIS 1.1) in Cisco IOS Release 12.2(15)CZ for the Cisco uBR905 and Cisco uBR925 cable access routers and Cisco CVA122 cable voice adapter. This document focuses on the new software and the changes to the existing software architecture that provide DOCSIS 1.1 support. This document also describes Cable Modem Termination System (CMTS) to cable modem interoperability and provides instructions for migrating from DOCSIS 1.0 to DOCSIS 1.1.


Release	Modification
12.2(15)CZ	The DOCSIS 1.1 feature set was introduced for the Cisco uBR905 and Cisco uBR925 cable access routers and Cisco CVA122 cable voice adapter.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.

Prerequisites for DOCSIS 1.1 Support

Before you implement a DOCSIS 1.1 network, ensure that the following are true for your cable network:

Note

To update the digital certificates, you must also obtain the Cisco DOCSIS 1.1 Cable Modem Certificate Upgrade CD-ROM (part number UBR/CVA-CERT-UPG). This one CD-ROM works with the Cisco uBR905 and Cisco uBR925 cable access routers and Cisco CVA122 Cable Voice Adapters.

•

Ensure that your network supports reliable broadband data transmission. Your plant must be swept, balanced, and certified to NTSC or appropriate international cable plant recommendations. Ensure that your plant meets all DOCSIS downstream and upstream RF requirements.

•

Ensure that your CMTS is installed and configured to support DOCSIS 1.1 operation.

•

Ensure that all other required headend or distribution hub routing and network interface equipment is installed, configured, and operational, based on the services to support. This includes all routers, servers (DHCP, TFTP, and ToD), network management systems, and other configuration or billing systems. This includes IP telephony equipment including gatekeepers and gateways; backbone and other equipment if supporting VPN; and dialup access servers, telephone circuits and connections, and other equipment if supporting telco return.

•

Ensure that the system clocks on the CMTS and on the time-of-day (ToD) servers are synchronized. If this does not occur, the clocks on the CMs will not match the clocks on the CMTS, which could interfere with BPI+ operations. In particular, this could prevent the proper verification of the digital certificates on the CM.

•

The DOCSIS specifications require that when the DOCSIS configuration file enables BPI+ encryption, the configuration file must also include a value for the Baseline Privacy Configuration Settings Option field (TLV 17). If this field is not included when BPI is enabled, the router rejects the BPI configuration. If MAC debugging is enabled (using the debug cable-modem mac command), the router also displays the displays the debugging message CMAC_LOG_BPKM_REQUIRED_TLV17_ABSENT on the console.

•

Ensure that DHCP and DOCSIS 1.1 configuration files have been created and pushed to appropriate servers such that each cable modem, when initialized, can transmit a DHCP request, receive an IP address, obtain TFTP and ToD server addresses, and download DOCSIS 1.1 configuration files. Optionally, ensure that servers are available to download Cisco IOS Release 12.2(15)CZ software images to Cisco uBR905 and Cisco uBR925 cable access routers and Cisco CVA122 cable voice adapters to enable DOCSIS 1.1 operation.

•

Ensure that customer premises equipment (CPE)—cable modems or set-top boxes, PCs, telephones, or facsimile machines—meet the requirements for your network and service offerings.

•

Familiarize yourself with your channel plan to ensure assigning of appropriate frequencies. Outline your strategies for setting up bundling or VPN solution sets, if applicable, to your headend or distribution hub. Know your dial plan if using H.323 for VoIP services and setting up VoIP-enabled cable modem configuration files. Obtain passwords, IP addresses, subnet masks, and device names, as appropriate.

•

To use SNMPv3, the SNMP manager must support the MD5 encryption protocol and the noauthnoPriv, authNoPriv, or authPriv authentication modes. Also, the manager must be able to generate random numbers, public numbers, and secret keys as specified by RFC 2786, Diffie-Hellman USM Key.

Restrictions for DOCSIS 1.1 Support

The Cisco uBR905 and Cisco uBR925 cable access routers and Cisco CVA122 cable voice adapters must be running Cisco IOS Release 12.2(15)CZ (or later release) to support DOCSIS 1.1. The CMTS must also support the DOCSIS 1.1 feature set.

BPI+ encryption and authentication must be supported and enabled by both the cable modem and the CMTS. In addition, the CMTS and cable modem must contain a digital certificate that conforms to the DOCSIS 1.1 and BPI+ specifications.

Also, the DOCSIS specifications require that when the DOCSIS configuration file enables BPI or BPI+ encryption, the configuration file must also include a value for the Baseline Privacy Configuration Settings Option field (TLV 17). If this field is not included when BPI is enabled, the router rejects the BPI configuration. If MAC debugging is enabled (using the debug cable-modem mac command), the router also displays the displays the CMAC_LOG_BPKM_REQUIRED_TLV17_ABSENT debugging message on the console.

Tip

Previously, the maximum concatenated burst size parameter could be set to zero to specify an unlimited value. In a DOCSIS 1.1 environment, this parameter should be set to a nonzero value, with a maximum value of 1522 bytes for DOCSIS 1.0 cable modems.

If a cable modem attempts to register with a maximum concatenation burst size of zero, the DOCSIS 1.1 CMTS refuses to allow the cable modem to come online. This avoids the possibility that a DOCSIS 1.0 cable modem could interfere with voice traffic on the upstream by sending extremely large data packets. Since DOCSIS 1.0 does not support fragmentation, transmitting such data packets could result in unwanted jitter in the voice traffic.

In addition, DOCSIS 1.1 requires that the maximum transmit burst size be set to either 1522 bytes or the maximum concatenated burst size, whichever is larger. Do not set the maximum concatenation burst size to values larger than 1522 bytes for DOCSIS 1.0 cable modems.

Note

This change requires you to change any DOCSIS configuration files that specify a zero value for the maximum concatenation burst size. This limitation does not exist for DOCSIS 1.1 cable modems unless fragmentation has been disabled.

The format and content of the TFTP configuration file for a DOCSIS 1.1 cable modem are significantly different from the file for a DOCSIS 1.0 cable modem. A dual-mode configuration file editor is used to generate a DOCSIS 1.0 style configuration file for DOCSIS 1.0 cable modems and a DOCSIS 1.1 configuration file for DOCSIS 1.1 cable modems.

A DOCSIS 1.1 CMTS is designed to handle the existing registration TLVs from DOCSIS 1.0 cable modems as well as the new type TLVs from DOCSIS 1.1 cable modems. A DOCSIS 1.0 and DOCSIS 1.1 cable modem can successfully register with the same DOCSIS 1.1 CMTS.

A DOCSIS 1.1 cable modem can be configured to make an indirect reference to a service class that has been statically defined at the CMTS, instead of explicitly asking for particular service class parameters. When this registration request is received by a DOCSIS 1.1 CMTS, it encodes the actual parameters of the service class in the registration response and expects a DOCSIS 1.1-specific registration-acknowledge MAC message from the cable modem.

When a DOCSIS 1.1 cable modem registers with a DOCSIS 1.0 CMTS, it responds with DOCSIS 1.0 style registration messages and does not use the DOCSIS 1.1 feature set.

DOCSIS 1.0 cable modems lack the ability to explicitly request and provide scheduling parameters for advanced DOCSIS 1.1 scheduling mechanisms, such as unsolicited grants and real-time polling. DOCSIS 1.1 cable modems on the same upstream channel can benefit from the advanced scheduling mechanisms and a DOCSIS 1.1 CMTS can still adequately support voice traffic from DOCSIS 1.1 cable modems with DOCSIS 1.0 cable modems on the same upstream channel.

Information About DOCSIS 1.1 Support

DOCSIS 1.1 is the first major revision of the initial DOCSIS 1.0 standard for cable networks. Although the initial standard provided quality data traffic over the coaxial cable network, the demands of real-time traffic such as voice and video required many changes to the DOCSIS specification. DOCSIS 1.1 also includes support for the Baseline Privacy Interface Plus (BPI+) features, which improves and enhances the DOCSIS 1.0 BPI security and authorization mechanisms.

Note

At the time of publication, the DOCSIS 1.1 and BPI+ specifications are still being finalized. See the CableLabs specifications web site ( http://www.cablemodem.com/specifications.html) for the current status on these specifications.

DOCSIS 1.1 Overview

The DOCSIS 1.1 specification provides the following functional enhancements over DOCSIS 1.0 coaxial cable networks:

•

Enhanced quality-of-service (QoS) to give priority for real-time traffic such as voice and video:

–

The DOCSIS 1.0 QoS model (a service ID [SID] associated with a QoS profile) has been replaced with a service flow model that allows greater flexibility in assigning QoS parameters to different types of traffic and in responding to changing bandwidth conditions.

–

Support for multiple service flows per cable modem allows a single cable modem to support a combination of data, voice, and video traffic.

–

Greater granularity in QoS per cable modem in either direction, using unidirectional service flows.

–

Dynamic MAC messages create, modify, and delete traffic service flows to support on demand traffic requests. The CMTS can also dynamically change the upstream and downstream channels that the cable modem is using to proactively deal with potential congestion or noise problems.

–

Committed information rate (CIR)—Guaranteed minimum bandwidth for data traffic.

–

Real-time polling (RTPS)—Real-time service flows, such as video, that produce unicast, variable-size packets at fixed intervals.

–

Unsolicited grants (UGS)—Constant bit rate (CBR) traffic, such as voice, that is characterized by fixed-size packets at fixed intervals.

–

Unsolicited grants with activity detection (USG-AD)—Combination of UGS and RTPS, to accommodate real-time traffic that might have periods of inactivity (such as voice using silence suppression). The service flow uses UGS fixed grants while active, but switches to RTPS polling during periods of inactivity to avoid wasting unused bandwidth.

•

Service flows for Voice-over-IP (VoIP) calls can be flexibly created using the following methods:

–

Dynamic quality-of-service (DQoS)—The router is initialized with a primary upstream service flow and a primary downstream service flow. When a VoIP call is made, the router sends a request for a UGS service flow with a Dynamic Service Addition Request (DSA-REQ) message. After the call, the router deletes the service flow using a Dynamic Service Deletion Request message (DSD-REQ) message.

–

Provisioned quality-of-service (PQoS)—The router is initialized with a primary upstream service flow, a primary downstream service flow, and two secondary upstream service flows that are reserved for VoIP calls. The router keeps the secondary flows in the admitted state until a VoIP call is made. The router then activates the appropriate flow with a Dynamic Service Change Request (DSC-REQ) message with a classifier for UGS service that specifies the IP parameters needed for the voice call. After the call, the router deletes the classifier and deactivates the service flow by sending another DSC-REQ message.

Note

If the CMTS does not support DOCSIS 1.1 dynamic services, the router can also use the previous DOCSIS 1.0+ mechanisms to create VoIP calls.

•

Enhanced time-slot scheduling mechanisms to support guaranteed delay and jitter-sensitive traffic on the shared multiple access upstream link.

•

Payload header suppression (PHS) conserves link-layer bandwidth by suppressing unnecessary packet headers on both upstream and downstream traffic flows.

•

Layer 2 fragmentation on the upstream prevents large data packets from affecting real-time traffic, such as voice and video. Large data packets are fragmented and then transmitted in the time slots that are available between the time slots used for the real-time traffic.

•

Concatenation allows a cable modem to send multiple MAC frames in the same time slot, as opposed to making an individual grant request for each frame. This avoids wasting upstream bandwidth when sending a number of very small packets, such as TCP acknowledgement packets.

•

Advanced authentication and security through X.509 digital certificates and Triple Data Encryption Standard (3DES) dual public key encryption.

•

Support for IP multicast encryption and for Internet Group Management Protocol (IGMP) groups.

•

Secure software download allows a service provider to remotely upgrade a cable modem's software, without risk of interception or alteration.

–

Authentication based on the HMAC-MD5 or HMAC-SHA algorithms that ensures that each packet is from a valid source.

–

An improved security model that provides for a larger number of security levels, with a greater granularity in determining per-user access.

•

DOCSIS 1.1 cable modems can coexist with DOCSIS 1.0 and 1.0+ cable modems in the same network—a DOCSIS 1.1 CMTS provides the levels of service that are appropriate for each cable modem.

Baseline Privacy Interface Plus

DOCSIS 1.0 included a Baseline Privacy Interface (BPI) to protect user data privacy across the shared-medium cable network and to prevent unauthorized access to DOCSIS-based data transport services across the cable network. BPI encrypts traffic across the RF interface between the cable modem and CMTS, and also includes authentication, authorization, and accounting (AAA) features.

BPI supports access control lists (ACLs), tunnels, filtering, protection against spoofing, and commands to configure source IP filtering on RF subnets to prevent subscribers from using source IP addresses that are not valid. These lists can be implemented either through CLI commands or by setting SNMP attributes through the DOCSIS configuration file.

DOCSIS 1.1 enhances these security features with Baseline Privacy Interface Plus (BPI+), which includes the following enhancements:

•

X.509 digital certificates provide secure user identification and authentication. Each DOCSIS 1.1 cable modem contains a certificate that uniquely identifies it to the CMTS. This certificate is chained to the manufacturer's digital certificate, which securely authenticates the cable modem. The manufacturer's certificate in turn is chained to and verified by the DOCSIS certificate authority (CA) root certificate.

•

Key encryption uses 168-bit Triple DES (3DES) encryption that is suitable for the most sensitive applications.

•

1024-bit public key exchange Pkcs#1 Version 2.0 encryption to ensure the secure generation and transmission of the public encryption keys between the CMTS and CM.

•

Encryption of multicast broadcasts allows users to receive only those broadcasts they are authorized to use.

•

Secure software download, using a Pkcs#7 digital signature, allows a service provider to upgrade a cable modem's software remotely, without the threat of interception, interference, or alteration.

Note

BPI+ is described in the Baseline Privacy Interface Plus Specification (SP-BPI+-I08-020301), available from CableLabs ( http://www.cablelabs.com).

X.509 Digital Certificates

BPI+ uses digital certificates and a public key infrastructure (PKI) that are based on the International Telecommunications Union (ITU) X.509 Version 3.0 standard. The key components of the X.509 standard are the following:

•

Digital certificate—Uniquely identifies the cable modem. The digital certificate contains the following information:

–

Certificate effective date and expiration Date—Give the range of dates for which the certificate is valid.

–

User public key—Allows other entities, such as the CMTS, to verify the certificate.

–

Issuer certificate authority (CA) name and signature—Provide a way of verifying that the certificate and keys have not been altered.

A DOCSIS 1.1 cable modem contains two digital certificates programmed into it at the factory: a cable modem certificate that uniquely identifies it, and a manufacturing certificate that identifies the cable modem's manufacturer (in this case, Cisco Systems).

•

Public and private keys—Keys used to sign and verify the certificate. The cable modem uses its private key to sign its digital certificate to create an unforgeable digital signature that identifies the signer. Other entities, such as the CMTS, use the public key to unsign and verify the certificate. For security, the cable modem never transmits or displays its private key, but the public key is included as part of the certificate to allow for its verification.

Note

The cable modem's private and public keys are never changed after being programmed at the factory.

•

Digital signature—Created when a private key signs a digital certificate. The digital signature becomes part of the certificate, allowing the CMTS to verify that the certificate came from the cable modem claiming to have issued it.

•

Certificate authority (CA)—To prevent users from creating their own certificates and private key and public key pairs, each certificate is also signed by an issuing CA. After the CMTS verifies a digital certificate with the cable modem's public key, it then verifies that the certificate has been properly signed by the issuing CA. This process continues until the CMTS can verify the certificate against a known and trusted CA (typically the root CA).

•

Root CA—A known and trusted CA that serves as the ultimate verification for a digital certificate. For DOCSIS 1.1 cable modems, the root CA is the DOCSIS Root CA certificate, which is available from Verisign at http://www.verisign.com/products/cable/root.html. The root CA is self-signed, which does not present a security problem because it is originating at a known and trusted source.

•

DOCSIS root code signing CA—Similar to the Root CA but used to verify the digital certificates that are used whenever a DOCSIS 1.1 cable modem downloads new software code.

During BPI+ initialization, the cable modem sends both of its signed digital certificates, the cable modem certificate (CMC) and the manufacturer's certificate (MC), to the CMTS. The CMTS verifies the cable modem certificate against the manufacturer's certificate, and then verifies the manufacturer's certificate against the DOCSIS Root CA certificate. This chain of verifications ensures that the CMTS can securely identify and authenticate each cable modem.

In addition, the CMTS can check the certificates against a Hot List of invalid certificates. The Hot List, which can be maintained by trusted authorities, such as a service provider or CA, can list certificates for individual cable modems that might have been stolen, hacked, or otherwise compromised. The list can also contain manufacturer's certificates for models of cable modems that the service provider does not support.

If all certificate verifications are successful, the CMTS begins the public key exchange process, which allows data encryption and decryption to begin.

Public Key Exchange

The secure use of X.509 digital certificates depends on both the cable modem and the CMTS possessing the proper encryption and decryption keys. For security and flexibility, DOCSIS 1.1 uses a dual-key public key exchange: the first set of keys, key encryption key (KEK), are used to encrypt and transmit the second set of keys, traffic encryption key (TEK), which are then used to encrypt and decrypt data.

Both sets of keys have a limited lifetime and must be renewed periodically. When a key reaches approximately half its lifespan, the cable modem begins the process to request a new set of keys. While the new set of keys is being exchanged, the cable modem can continue to use the old set to encrypt and decrypt data. The KEK keys have a longer lifetime than the TEK keys to ensure that the cable modem and CMTS will always be able to obtain new TEK keys, allowing data transmissions to continue without interruptions.

Secure Software Download

DOCSIS 1.1 supports secure software download to allow a service provider to remotely upgrade a cable modem's software without risk of interception or alteration. Secure software download also prevents users from upgrading the cable modem to unauthorized software images.

The manufacturer digitally signs the software image using a Pkcs#7 digital signature that is encrypted using the Rivest-Shamir-Adleman (RSA) algorithm and secure hash algorithm-1 (SHA-1). This digital signature is chained to the DOCSIS root code signing certificate so that it can be easily verified.

The cable operator can optionally also digitally sign the software image in a similar manner, using another digital signature that is chained to the DOCSIS root code signing certificate. This allows cable operators greater control over which software images are used on the cable network.

The cable operator initiates the software download by filling in the software filename and TFTP server fields (TLVs 9 and 21) in the DOCSIS configuration file that it sends to the cable modem during registration. You can also initiate a software download by using SNMP commands. In either case, the cable modem then requests the specified file and downloads it from the specified TFTP server.

The cable modem verifies the manufacturer's digital signature and, if present, the cable operator's digital signature, using the code verification certificates (CVCs) provided in the DOCSIS configuration file. If the signatures are valid, the cable modem loads and runs the software.

When a cable modem is running DOCSIS 1.1 software, it must use the secure software download feature to download a software image through the DOCSIS configuration file or through SNMP commands. Even if you disable BPI+, a DOCSIS 1.1 cable modem still accepts only digitally signed software images that can be verified through the secure software download process.

Note

The secure software download feature does not prevent a user with console or Telnet access, and who knows the proper passwords, from loading an unsigned software image directly into the cable modem's Flash memory by using the copy tftp command.

•

The Cisco uBR905, Cisco uBR925, or Cisco CVA122 must be running a DOCSIS 1.1 software image.

If the cable modem is currently running a DOCSIS 1.0 software image, you cannot use the secure software download to upgrade to a DOCSIS 1.1 image. Instead, you must use the DOCSIS 1.0 software upgrade process to load an unsigned DOCSIS 1.1 software image. Then you will be able to use the secure software download process to load a digitally signed DOCSIS 1.1 software image.

•

The desired software image must be digitally signed by the manufacturer. The cable operator can also optionally digitally sign the image. Unsigned images cannot be loaded using the secure software download process.

Note

You cannot use the copy tftp command to load digitally signed images into the Flash memory on the cable modem.

•

You must load at least one CVC into the cable modem through the DOCSIS configuration file. The cable modem uses the CVC to verify that a downloaded software image is from the proper manufacturer and has not been altered during transmission. You can load two types of CVCs into the cable modem:

–

Manufacturer's CVC (M-CVC)—Verifies that the downloaded software image has been digitally signed by the manufacturer (Cisco Systems). The M-CVC is loaded into the cable modem by specifying TLV 32 (MFG CVC) in the DOCSIS configuration file.

–

Cosigner's CVC (C-CVC)—Verifies that the downloaded software image has been digitally signed by both the manufacturer (Cisco Systems) and the cable operator. The C-CVC is loaded into the cable modem by specifying TLV 33 (MSO CVC) in the DOCSIS configuration file.

If you load the M-CVC into the cable modem, you can download only those software images that Cisco Systems has digitally signed. If you load the C-CVC into the cable modem, you can download only those software images that Cisco Systems and the cable operator have digitally signed.

Note

A DOCSIS 1.1 cable modem must use the secure software download feature when upgrading its software image through the DOCSIS configuration file or through SNMP commands. However, users can still use CLI commands to copy an unsigned software image from a TFTP server, if they know the enable password and are allowed console or Telnet access.

After the cable modem loads and runs the DOCSIS 1.1 image, the cable modem must use the secure software download process for all future upgrades. In particular, this means that the cable modem cannot be downgraded to a DOCSIS 1.0 software image unless the manufacturer provides a digitally signed DOCSIS 1.0 image. After downgrading to a DOCSIS 1.0 image, you cannot use the secure software download process again until you have upgraded the cable modem to a new DOCSIS 1.1 image.

Tip

Cisco IOS software images that include "cvc" as part of the software image filename (ubr925cvc-k9o3sv9y5-mz) are digitally signed. Unsigned software images do not have "cvc" as part of the filename (ubr925-k9o3sv9y5-mz). If you are using secure software download, you must use a digitally signed image (includes "cvc"). If you are not using secure software download, you must use an unsigned image (does not include "cvc").

DOCSIS 1.1 Quality-of-Service

DOCSIS 1.1 implemented a number of changes to allow great flexibility in the ability of a cable modem and service provider to transmit almost any combination of data traffic and real-time traffic, such as voice and video. These changes required a fundamental shift in how a cable modem requests service and how traffic can be transmitted across the cable network.

Overview

•

Service class—A collection of settings maintained by the CMTS that provide a specific QoS service tier to a cable modem that has been assigned a service flow within a particular service class.

•

Service flow—A MAC-layer transport service that provides unidirectional transport of packets to upstream packets transmitted by the cable modem or to downstream packets transmitted by the CMTS. A service flow is characterized by a set of QoS parameters such as latency, jitter, and throughput assurances.

•

Packet classifier—A set of packet header fields used to classify packets onto a service flow to which the classifier belongs. When a packet is presented to the DOCSIS MAC layer at the CMTS or cable modem, it is compared to a set of packet classifiers until a matching classifier is found. The SFID from this classifier is used to identify the service flow on which the packet will be sent.

•

PHS rule—A set of packet header fields that are suppressed by the sending entity before transmitting on the link, and are restored by the receiving entity after receiving a header-suppressed frame transmission. Payload header suppression increases the bandwidth efficiency by removing repeated packet headers before transmission.

In the upstream direction, the output queues at the cable modem get remotely served by the CMTS MAC scheduler, based on DOCSIS 1.1 slot scheduling constraints such as grant-interval and grant-jitter. In the downstream direction, the CMTS packet scheduler serves the flow queues depending on the flow attributes like traffic priority, guaranteed rate, and delay bound.

DOCSIS 1.1 adds several new MAC scheduling disciplines to provide guaranteed QoS for real-time service flows on the multiple access upstream channel. Multiple grants per interval helps in supporting multiple subflows (such as voice calls) on the same SID. Multiple subflows per SID reduces the minimum SID requirement in cable modem hardware.

The CMTS is responsible for supporting QoS for all cable modems in its control. The traffic in the downstream is assumed to be a combination of voice, committed information rate (CIR) data, and excess burst best-effort data. To provide QoS support, the following functions must be performed:

•

Packet classification—Mapping packets to service flows based on header information

The admission control block helps the overall downstream QoS block to track the current bandwidth reservation state on a per-downstream basis. Decisions can be made whether to admit or reject a request for a new service flow on that DS channel, based on this reservation state and the QoS guarantees requested by the new service-flow.

IP packet classifiers help in filtering out unique service flows on an interface for differential QoS treatment. Rather than doing per-cable modem downstream rate shaping, DOCSIS 1.1 software provides rate shaping at a much more granular level of individual service flows of the cable modem.

Note

Cisco uBR905 and uBR925 cable access routers and Cisco CVA122 cable voice adapters running Cisco IOS Release 12.2(15)CZ can transparently interoperate with CMTS routers running DOCSIS 1.0, DOCSIS 1.0+ extensions, or DOCSIS 1.1.

Service Flows and Packet Classifiers

Every cable modem establishes a primary service flow in both the upstream and downstream directions. The primary flows maintain connectivity between the cable modem and the CMTS at all times.

In addition, a DOCSIS 1.1 cable modem can establish multiple secondary service flows. The secondary service flows either can be permanently created (they persist until the cable modem is reset or powered off) or can be created dynamically to meet the needs of the on-demand traffic being transmitted.

A service flow gets created at the time of cable modem registration (a static service flow) or as a result of a dynamic MAC message handshake between the cable modem and the CMTS (a dynamic service flow). At any given time, a service flow might be in one of three states (provisioned, admitted, or active). Only active flows are allowed to pass traffic on the DOCSIS link.

Each service flow has a set of QoS attributes associated with it. These QoS attributes define a particular class of service and determine characteristics such as the maximum bandwidth for the service flow and the priority of its traffic. The class of service attributes can be inherited from a preconfigured CMTS local service class (class-based flows), or they can be individually specified at the time of the creation of the service flow.

Every service flow also has a unique (unique per DOCSIS MAC domain) identifier called the service flow identifier (SFID). The upstream flows in the admitted and active state have an extra Layer 2 SID associated with them. The SID is the identifier used by the MAC scheduler when specifying time-slot scheduling for different service flows.

Each service flow has multiple packet classifiers associated with it, which determine the type of application traffic allowed to be sent on that service flow. Each service flow can also have a payload header suppression (PHS) rule associated with it to determine which portion of the packet header will be suppressed when packets are transmitted on the flow.

Dynamic Channel Change

DOCSIS 1.1 supports Dynamic Channel Change (DCC) requests, which allow the CMTS to change the upstream or downstream frequency that the cable modem is using. This allows the CMTS to move cable modems to another channel when the current one is either becoming congested or is encountering growing noise problems that could eventually force the cable modems offline.

The Cisco uBR905 and Cisco uBR925 cable access routers and the Cisco CVA122 Cable Voice Adapter automatically support DCC requests when running Cisco IOS Release 12.2(15)CZ.

Dynamic Quality-of-Service

DOCSIS 1.1 adds support Dynamic Services MAC-layer messages that provide for Dynamic QoS (DQoS) between the cable modem and the CMTS. These messages are DOCSIS link-layer equivalents of the higher-layer messages that create, tear down, and modify a service flow. These messages are collectively known as DSX messages to represent the three types of dynamic service messages:

•

Dynamic Service Change (DSC)—Changes the attributes of an existing service flow. These changes can include the following:

–

Adding, setting, or deleting payload header suppression (PHS) rules for the service flow.

The DSX state machine module on the cable modem manages the several concurrent dynamic service transactions between cable modems and the CMTS. The DSX state machine supports all three DOCSIS1.1 DSX MAC messages (DSA, DSC, DSD).

Provisioned QoS

Provisioned QoS (PQoS) allows the cable modem to create the service flows it needs for voice calls and other real-time traffic at the time it registers with the CMTS, without actually using the bandwidth for those flows. The service flow is kept in the admitted state and is activated only when the cable modem signals a voice call using the DOCSIS 1.1 Dynamic Service Request (DSC-REQ) message. Bandwidth is used only when the voice call is actually in progress.

To use PQoS services, you must configure the cable modem with secondary service flows for VoIP calls. (If you do not define any secondary service flows, DQoS is used instead of PQoS). You can use any voice signaling that is supported by the cable modem for VoIP traffic.

Table 1 compares how the router sets up and tears down VoIP calls when using DQoS and PQoS:

Table 1 Comparison of DQoS and PQoS Call Setup and Teardown Operation
Quality-of-Service Type	VoIP Signaling Type	Call Setup Description
Dynamic QoS	H.323	Sends DSA at off-hook and DSD at on-hook.
Dynamic QoS	SGCP/MGCP/SIP	Sends DSA at off-hook, DSC when the call setup parameters are received from the gateway, and DSD at on-hook.
Provisioned QoS	H.323	Sends DSC at off-hook to activate the provisioned service flows and DSD at on-hook.
Provisioned QoS	SGCP/MGCP/SIP	Sends DSC at off-hook to activate the provisioned service flows, a second DSC when the call setup parameters are received from the gateway, and DSD at on-hook.

Service Flow Manager

The Service Flow Manager is a new module that manages different activities related to service flows on a cable interface. Typical events include the creation of new DOCSIS service flows, modification of the attributes of existing service flows, and the deletion of service flows.

Quality-of-Service Comparison

Quality-of-service (QoS) is a measure of performance for a transmission system that reflects its transmission quality and service availability. This section describes the differences in QoS between DOCSIS 1.1 and DOCSIS 1.0 and 1.0+.

DOCSIS 1.0

DOCSIS 1.0 uses a static QoS model that is based on a class of service (CoS) that is preprovisioned in the TFTP configuration file for the cable modem. The CoS is a bidirectional QoS profile that has limited control, such as peak rate limits in either direction and relative priority on the upstream.

DOCSIS 1.0 defines the concept of a service identifier (SID), which specifies the devices allowed to transmit and which provides device identification and CoS. In DOCSIS 1.0, each cable modem is assigned only one SID, creating a one-to-one correspondence between a cable modem and the SID. All traffic originating from, or destined for, a cable modem is mapped to that cable modem's SID.

Typically, a DOCSIS 1.0 cable modem has one CoS and treats all traffic the same, which means that data traffic on a cable modem can interfere with the quality of a voice call in progress. The CMTS, however, can prioritize downstream traffic based on IP precedent type-of-service (ToS) bits. For example, voice calls using higher IP precedence bits receive a higher queueing priority (but without a guaranteed bandwidth or rate of service). A DOCSIS 1.0 cable modem could increase voice call quality by permanently reserving bandwidth for voice calls, but then that bandwidth would be wasted whenever a voice call is not in progress.

DOCSIS 1.0+ Extensions

In response to the limitations of DOCSIS 1.0 in handling real-time traffic, such as voice calls, Cisco created the DOCSIS 1.0+ extensions to provide the more important QoS enhancements that were expected in DOCSIS 1.1. In particular, the DOCSIS 1.0+ enhancements provide basic Voice-over-IP (VoIP) service over the DOCSIS link.

•

Multiple SIDs per cable modem, creating separate service flows for voice and data traffic. This allows the CMTS and cable modem to give higher priority for voice traffic, preventing the data traffic from affecting the quality of the voice calls.

•

Cable modem-initiated dynamic MAC messages—Dynamic Service Addition (DSA) and Dynamic Service Deletion (DSD). These messages allow dynamic SIDs to be created and deleted on demand, so that the bandwidth required for a voice call can be allocated at the time a call is placed and then freed up for other uses when the call is over.

•

Unsolicited grant service (CBR-scheduling) on the upstream—This helps provide a higher-quality channel for upstream VoIP packets from an Integrated Telephony Cable Modem (ITCM) such as the Cisco uBR924 cable access router.

•

Ability to provide separate downstream rates for any given cable modem, based on the IP-precedence value in the packet. This helps separate voice signaling and data traffic that goes to the same ITCM to address rate shaping purposes.

•

Concatenation allows a cable modem to send several packets in one large burst, instead of having to make a separate grant request for each.

Caution

All DOCSIS 1.0 extensions are available only when using a cable modem (such as the Cisco uBR924 cable access router) and CMTS (such as the Cisco uBR7200 series universal broadband router) that supports these extensions. The cable modem activates the use of the extensions by sending a dynamic MAC message. DOCSIS 1.0 cable modems continue to receive DOCSIS 1.0 treatment from the CMTS.

SNMPv3 Support

DOCSIS 1.1 also requires support of v3 of the Simple Network Management Protocol (SNMPv3). SNMPv3 offers a number of significant improvements over SNMPv1 and SNMPv2:

•

DES 56-bit encryption that encrypts each packet to prevent interception or alteration intransit. SNMP attributes can be set and retrieved without exposing confidential information on a public network.

•

Authentication based on the HMAC-MD5 or HMAC-SHA algorithms that ensures that each packet is from a valid source.

•

An improved security model that provides for a larger number of security levels, with a greater granularity in determining per-user access. Each SNMPv3 user belongs to a group, which defines the security model and security level for its users. This includes the level of access to SNMP objects and the list of notifications that users can receive.

SNMPv3 Diffie-Hellman Kickstart

To ensure SNMPv3 security, the Multi-Service Operator (MSO) must perform an initialization procedure the first time the cable modem comes online. This procedure, which the DOCSIS 1.1 specification refers to as the SNMPv3 Diffie-Hellman Kickstart, sends a public key to the cable modem as part of the DOCSIS configuration file. The cable modem creates a secret number and encrypts it using the public key it received in the configuration file.

The cable modem then publishes the encrypted number to the CMTS, which uses its private key to decrypt it so as to produce the cable modem's secret number. This secret number becomes a shared secret value that the CMTS and CM can use to exchange SNMPv3 encryption keys.

MIB Enhancements

DOCSIS 1.1 also expands the MIB support for SNMP management, including the following changes and additions to the DOCSIS 1.0 MIB structure:

Additional DOCSIS 1.1 Features in Cisco IOS Release 12.2(15)CZ

The following sections describe the DOCSIS 1.1 software features that appear in Cisco IOS Release 12.2(15)CZ.

Concatenation

Concatenation allows the cable modem to make a single time-slice request for multiple packets and send all packets in a single large burst on the upstream. Concatenation was introduced in the upstream receive driver in DOCSIS1.0+ releases.

Fragmentation

Grant fragmentation allows the upstream MAC scheduler to slice large data requests to fit into the scheduling gaps between UGS (voice slots). This reduces the jitter experienced by the UGS slots when large data grants preempt the UGS slots. The grant fragmentation gets triggered in the MAC scheduler, and fragment reassembly happens in the upstream receive driver.

Note

DOCSIS fragmentation should not be confused with the fragmentation of IP packets, which is done to fit the packets on network segments with smaller maximum transmission unit (MTU) size. DOCSIS Fragmentation is Layer 2 fragmentation that is primarily concerned with efficiently transmitting lower-priority packets without interfering with high-priority real-time traffic, such as voice calls. IP fragmentation is done at Layer 3 and is primarily intended to accommodate routers that use different maximum packet sizes.

IP Multicast Support

By default, a DOCSIS CMTS transmits IP multicast traffic without encryption. All DOCSIS cable modems receiving that multicast traffic must forward it to its attached CPE devices, without regard to whether any of the devices have requested the traffic. This can waste network bandwidth and require network devices to waste processor power in forwarding and processing undesired multicast traffic.

A DOCSIS 1.1 CMTS can instead use the Internet Group Management Protocol (IGMP) to maintain the multicast group memberships of its DOCSIS 1.1 cable modems. BPI+ encryption is used to encrypt the multicast packets so that only the cable modems with the appropriate public keys can decrypt the packets and forward them to their attached customer premises equipment (CPE) devices.

If a cable modem has not been granted the decryption keys for a particular multicast service flow, it does not forward the traffic to its CPE devices. This ensures that only authorized subscribers can receive the multicast traffic, and prevents cable modems from loading down their local networks by forwarding unnecessary multicast traffic.

DOCSIS 1.1 uses the concept of Security Associations (SA), which are dynamically created and maintained to provide the service flows required to transmit IP multicast traffic on the downstream. A cable modem sends an SA Map Request message to request the SA for the downstream service flow that is carrying the desired multicast traffic.

If the cable modem is not authorized to receive the multicast traffic, or if the traffic is not available on BPI+ encrypted SA, the CMTS sends an SA Map Reject message. The cable modem then does not repeat any further SA Map Requests for this particular multicast traffic. However, if the traffic is available on an unencrypted service flow, it begins forwarding that traffic to its CPE devices.

If the cable modem is authorized to receive the multicast traffic, and if the traffic is available, the CMTS replies with an SA Map Reply message to provide the information that allows the cable modem to receive the multicast traffic. The SA Map Reply message contains the SA identifier (SAID) for the traffic and the cryptographic suite that is necessary to decrypt the multicast traffic.

If the cable modem supports the cryptographic suite being used, it sends a Key Request to the CMTS, requesting the public keys it needs to decrypt the multicast service flow. If the CMTS replies with a Key Reply that contains the requested public keys, the cable modem begins decrypting the multicast traffic and forwarding it to its attached CPE devices.

The multicast traffic can be mapped to the cable modem's primary SA, a static SA, or a dynamically created SA. One service flow can support multiple multicast traffic flows, each with its own SAID. Multicast traffic mapped to a primary SA can be received only by the cable modem that is assigned the associated primary service flow. Multicast traffic mapped to static and dynamic SAs can be received by all cable modems that are assigned the associated secondary service flows.

Payload Header Suppression and Restoration

The PHS feature is used to suppress repetitive or redundant portions in packet headers before transmission on the DOCSIS link. This is a new feature in the DOCSIS1.1 MAC driver. The upstream receive driver is now capable of restoring headers suppressed by cable modems, and the downstream driver is capable of suppressing specific fields in packet headers before forwarding the frames to the cable modem.

Migrating from Earlier Versions of DOCSIS

DOCSIS 1.1 cable modems have additional features and better performance than earlier DOCSIS 1.0 and 1.0+ models, but all three models can coexist in the same network. DOCSIS 1.0 and 1.0+ cable modems will not hamper the performance of a DOCSIS 1.1 cable modem, nor will they interfere with operation of DOCSIS 1.1 features. There is full forward and backward compatibility in the standards.


For this configuration...	The result is...
DOCSIS 1.1 cable modems with DOCSIS 1.0 CMTS	Cable modems receive DOCSIS 1.0 features and capabilities. BPI is supported if it is available and enabled on the CMTS.
DOCSIS 1.1 cable modems with DOCSIS 1.0+ CMTS	Cable modems receive basic DOCSIS 1.0 support. BPI is supported if it is available and enabled on the CMTS. In addition, cable modems also receive the following DOCSIS 1.1 features: •Multiple SIDs per cable modem •Dynamic Service MAC messaging initiated by the cable modem •Unsolicited grant service (UGS, CBR-scheduling) on the upstream •Separate downstream rates for any given cable modem, based on the IP-precedence value •Concatenation
DOCSIS 1.1 cable modems with DOCSIS 1.1 CMTS	Cable modems receive all the DOCSIS 1.1 features listed in this document. BPI+ is supported if it is available and enabled on the CMTS.

Benefits

DOCSIS 1.1 includes a rich set of features that provide advanced and flexible QoS capabilities for various types of traffic (voice, data, and video) over the cable network. It also provides enhanced security and authentication features.

The Plus (+) version of the Baseline Privacy Interface (BPI+) in DOCSIS 1.1 provides a set of extended services within the MAC sublayer that increase performance and system security. Digital certificates provide secure authentication for each cable modem, to prevent identity theft on the basis of MAC and IP addresses. Advanced encryption provides a secure channel between the cable modem and the CMTS, and secure software download allows a service provider to upgrade the software on cable modems, without the threat of interception, interference, or alteration of the software code.

The dynamic creation, modification, and deletion of service flows allows for on-demand reservation on Layer 2 bandwidth resources. The CMTS can now provide special dynamic QoS (DQos) to the cable modem dynamically for the duration of a voice call or video session, as opposed to the static provisioning and reservation of resources at the time of cable modem registration. This provides a more efficient use of the available bandwidth.

The cable modem concatenates multiple upstream packets into one larger MAC data frame, allowing the cable modem to make only one time-slot request for the entire concatenated MAC frame, as opposed to requesting a time slot for each individual packet. This reduces the delay in transferring the packet burst upstream.

Extensive scheduling parameters allow the CMTS and the cable modem to communicate QoS requirements and achieve more sophisticated QoS on a per service-flow level.

Different new time-slot scheduling disciplines help in providing guaranteed delay and jitter bound on shared upstream. Activity detection helps to conserve link bandwidth by not issuing time slots for an inactive service flow. The conserved bandwidth can then be reused for other best-effort data slots.

Packet classification helps the CMTS and the cable modem to isolate different types of traffic into different DOCSIS service flows. Each flow could be receiving a different QoS service from the CMTS.

Provisioned QoS (PQoS) allows the cable modem to create service flows for voice calls and other real-time traffic at the time it registers with the CMTS, without actually using the bandwidth for those flows. When such a service flow is specified in the DOCSIS configuration file, the cable modem creates a flow that uses the DOCSIS 1.1 unsolicited grant service (UGS). The service flow, however, is not activated until the cable modem signals the voice call using the DOCSIS 1.1 Dynamic Service Change Request (DSC-REQ) message. Bandwidth is used only when the voice call is actually in progress.

The MAC scheduler fragments data slots to fill the gaps in between UGS slots. Fragmentation reduces the jitter experienced by voice packets when large data packets are transmitted on the shared upstream channel and preempt the UGS slots used for voice. Fragmentation splits the large data packets so that they fit into the smaller time slots available around the UGS slots.

This feature allows the cable modem to have multiple calls on a single hardware queue. This approach scales much better than requiring a separate SID hardware queue on the cable modem for each voice call.

Payload header suppression (PHS) allows the CMTS and the cable modem to suppress repetitive or redundant portions in packet headers before transmitting on the DOCSIS link. This helps to conserve link bandwidth, especially with types of traffic, such as voice, where the header size tends to be as large as the size of the actual packet.

The QoS attributes of a service flow can be specified in two ways: either explicitly by defining all attributes, or implicitly by specifying a service class name. A service class name is a string that the CMTS associates with a QoS parameter set.

•

It allows operators 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 might need to be set differently for two different CMTSs to provide the same service. As another example, service profiles could be changed by time of day.

•

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.

•

It allows higher-layer protocols to create a service flow by its service class name. For example, telephony signaling might direct the cable modem to instantiate any available provisioned service flow of class G.711.

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.

� By indirectly referring to a set of traffic parameters by specifying a service class name.

The service class name is expanded to its defined set of parameters at the time the CMTS successfully admits the service flow.

Secure software download ensures that the cable modem downloads only the proper software image from a properly authenticated server. The software transfer is encrypted to prevent users and hackers from intercepting the download and substituting their own software image in its place.

How to Configure DOCSIS 1.1 Support

The Cisco uBR905 and Cisco uBR925 cable access routers and Cisco CVA122 cable voice adapters automatically support all DOCSIS 1.1 features when running Cisco IOS Release 12.2(15)CZ. Many DOCSIS 1.1 features, however, must be specifically enabled through the DOCSIS configuration file that is downloaded to the router at initialization time. Special configuration is also needed to use provisioned quality-of-service (PQoS) for VoIP calls.

See the following sections for the configuration tasks for each feature. Each tasks in the list is identified as either required or optional.

Creating a DOCSIS 1.1 Configuration File

No special configuration is needed to enable basic DOCSIS 1.1 operation, but the DOCSIS configuration file can be used to control which DOCSIS 1.1 features are enabled and used during a session.

In addition to enabling the different DOCSIS 1.1 features, special fields in the DOCSIS configuration files are needed to enable SNMPv3 operation and to configure the router for the secure software download procedure. The following sections describe these procedures:

These procedures assume that you are using the Cisco DOCSIS Configurator Tool, version 3.6 or later, to generate the DOCSIS 1.1 configuration files for the cable modems. This tool is available on Cisco.com at http://www.cisco.com/cgi-bin/tablebuild.pl/cpe-conf.

DOCSIS 1.1 Feature Configuration

A DOCSIS 1.1-capable cable modem informs the CMTS that it is capable of DOCSIS 1.1 operation by sending a DHCP request that includes option 60, Vendor Class Identifier, with a value of "docsis1.1:xxxxxxx", where xxxxxxx is an ASCII string with the hexadecimal encoding of the encoding of the modem's capabilities. This field informs the CMTS of the following information:

The option 60 message does not enable DOCSIS 1.1 operation but only informs the CMTS of the cable modem's capabilities. To enable the different DOCSIS 1.1 features, you must specifically enable the following options in the DOCSIS configuration file:

Note

For more information about these parameters, see Appendix D, "CM Configuration Interface Specification," in the DOCSIS 1.1 specification, Data-Over-Cable Service Interface Specifications Radio Frequency Interface Specification (SP-RFIv1.1-I08-020301).

Configuring the SNMPv3 Diffie-Hellman Kickstart Public Key

Before a DOCSIS 1.1 cable modem can initiate BPI+ encryption, it must be configured with a shared public key that allows it to securely transfer the BPI+ encryption keys with the CMTS. Use the following procedure to configure the Cisco uBR905, Cisco uBR925, or Cisco CVA122 with the required public key.

The DOCSIS 1.1 specification refers to this procedure as SNMPv3 Diffie-Hellman Kickstart. This procedure needs to be done only once, unless the public keys are changed on the CMTS, or the Cisco uBR905, Cisco uBR925, or Cisco CVA122 is moved to a different CMTS that uses a different public key.

Step 1

Use your SNMPv3 manager software to generate a 128-byte (1024-bit) public key for the CMTS.

Step 2

Add this public key to a DOCSIS configuration file along with the built-in DOCSIS operator "docsisOperator" in the "SnmpV3 Kickstart Value" field (TLV 34). Put the "docsisOperator" value in field 34.1 and the public key in field 34.2.

For example, if you are creating an ASCII file and using the Cisco DOCSIS Configurator tool to convert it into the binary DOCSIS configuration file, you would specify lines such as the following:

To enter this data directly into the Configurator tool, click on the SNMP tab and enter this data into the first available row in the "SNMP V3 Kickstart Value" table. Figure 2 shows an example of this using version 3.7 of the Cisco DOCSIS Configurator tool. Figure 3 shows an example of this using version 4.0 of the Cisco Broadband Configurator tool.

Figure 2 Entering the Kickstart Values into Cisco DOCSIS Configurator Version 3.7

Figure 3 Entering the Kickstart Values into Cisco Broadband Configurator Version 4.0

Tip

Enter the hexadecimal digits of the public key separated either by spaces or by hyphens, and without a "0x" hexadecimal prefix. The public key must contain exactly 128 hexadecimal bytes.

Step 3

After entering all other required values into the DOCSIS configuration file, reset the Cisco uBR905, Cisco uBR925, or Cisco CVA122, and download the DOCSIS configuration file to it.

Configuring for Secure Software Download

Before a DOCSIS 1.1 cable modem can perform a secure software download, it must be configured with the code verification certificates (CVCs) that allow it to securely transfer the software file from the CMTS. The manufacturer's CVC (M-CVC) verifies that the software image has been properly signed by the manufacturer (in this case, Cisco Systems). The optional cosigner's CVC (C-CVC) verifies that the software image has been signed by the Multi-Service Operator (MSO) that is providing the cable network.

Use the following procedure to configure the Cisco uBR905, Cisco uBR925, or Cisco CVA122 with the required certificates.

Step 1

Add the manufacturer's CVC to a DOCSIS configuration file in the "Manufacturer Code Verification Certificate" field (TLV 32). If using the graphical interface of the DOCSIS Configurator tool, enter the CVC data directly into the Configurator tool by clicking the Miscellaneous tab and entering the data in the "Manufacturer CVC" field. See Figure 4.

Figure 4 shows an example of this using version 3.7 of the Cisco DOCSIS Configurator tool. Figure 5 shows an example of this using version 4.0 of the Cisco Broadband Configurator tool.

Tip

Enter the hexadecimal digits of the public key separated either by spaces or by hyphens, and without a "0x" hexadecimal prefix. The public key must contain exactly 128 hexadecimal bytes.

You can also create an ASCII file and use the DOCSIS Configurator tool to convert it into the binary DOCSIS configuration file. However, if the M-CVC contains more than 254 bytes, you must break it apart into successive fields, with each field except the last containing exactly 254 bytes.

The following shows a typical example of an M-CVC that is greater than 254 bytes:

If you are using Release 3.7 or later of the DOCSIS Configurator tool, you can also specify TLV 320, which allows you to specify the location of the actual M-CVC binary file on the local disk. The Configurator then reads the file and saves the CVC as part of the DOCSIS configuration file. This avoids having to convert the CVC into a hexadecimal format, as shown above.

For example, if you are running the DOCSIS Configurator on a Windows workstation, and you have saved the M-CVC in the file D:\CiscoM.cvc, use the following line into the ASCII file:

Step 2

If required, add the optional cosigner's code verification certificate (C-CVC) to a DOCSIS configuration file in the Co-Signer's code verification certificate field (TLV 33). To enter this data directly into the Configurator tool, click on the Miscellaneous tab and enter this data in the Co-signer CVC table (see Figure 4).

If you are creating an ASCII configuration file and converting it into the binary DOCSIS configuration file, and if the C-CVC contains more than 254 bytes, you must break it apart into successive TLV 33 fields, and each field except the last must contain exactly 254 bytes. The following shows a typical example of an C-CVC that is greater than 254 bytes:

If you are using Release 3.7 or later of the DOCSIS Configurator tool, you can also specify TLV 330, which allows you to specify the location of the actual C-CVC binary file on the local disk. The Configurator then reads the file and saves the CVC as part of the DOCSIS configuration file. This avoids having to convert the CVC into a hexadecimal format, as shown above.

For example, if you are running the DOCSIS Configurator on a Windows workstation, and you have saved the C-CVC in the file D:\MSO.cvc, use the following line into the ASCII file:

Note

If you use TLV 320 or TLV 330, you must specify the location of the actual CVC file, in its binary, encoded form. Do not specify a text file with a hexadecimal dump of the CVC.

Step 3

After entering all other required values into the DOCSIS configuration file, reset the Cisco uBR905, Cisco uBR925, or Cisco CVA122, and download the DOCSIS configuration file to it.

Performing a Secure Software Download

Use the following procedures to download a digitally signed software image to the router using the secure software download procedure.

These procedures assume that the required CVCs have been downloaded to the router (see the "Configuring for Secure Software Download" section) and that the router is already running a DOCSIS 1.1 software image.

Note

If the cable modem did not receive a valid CVC in the DOCSIS configuration file, the secure software download fails with the debug message "Boot file is current." This indicates that the cable modem is continuing to use the current software image. Verify that the DOCSIS configuration file contains a valid CVC for the software image being downloaded.

Table Of Contents

DOCSIS 1.1 for Cisco uBR905 and Cisco uBR925 Cable Access Routers and Cisco CVA122 Cable Voice Adapters

Contents

Prerequisites for DOCSIS 1.1 Support

Restrictions for DOCSIS 1.1 Support

Information About DOCSIS 1.1 Support

DOCSIS 1.1 Overview

Baseline Privacy Interface Plus

X.509 Digital Certificates

Public Key Exchange

Secure Software Download

DOCSIS 1.1 Quality-of-Service

Overview

Service Flows and Packet Classifiers

Dynamic Channel Change

Dynamic Quality-of-Service

Provisioned QoS

Service Flow Manager

Quality-of-Service Comparison

DOCSIS 1.0

DOCSIS 1.0+ Extensions

SNMPv3 Support

SNMPv3 Diffie-Hellman Kickstart

MIB Enhancements

Additional DOCSIS 1.1 Features in Cisco IOS Release 12.2(15)CZ

Concatenation

Fragmentation

IP Multicast Support

Payload Header Suppression and Restoration

Migrating from Earlier Versions of DOCSIS

Benefits

How to Configure DOCSIS 1.1 Support

Creating a DOCSIS 1.1 Configuration File

DOCSIS 1.1 Feature Configuration

Configuring the SNMPv3 Diffie-Hellman Kickstart Public Key

Configuring for Secure Software Download

Performing a Secure Software Download