Cisco CMTS Feature Guide
DOCSIS 1.1 for the Cisco CMTS

Table Of Contents

DOCSIS 1.1 for the Cisco CMTS

Contents

Prerequisites for DOCSIS 1.1 Operations

Restrictions for DOCSIS 1.1 Operations

Information about DOCSIS 1.1

Feature Overview

Baseline Privacy Interface Plus

Concatenation

Dynamic MAC Messages

Enhanced Quality of Service

Fragmentation

Interoperability

Payload Header Suppression

DOCSIS 1.1 Quality of Service

Service Flow

Service Class

Packet Classifiers

Packet Header Suppression Rules

Quality of Service Comparison

Benefits

How to Configure the Cisco CMTS for DOCSIS 1.1 Operations

Configuring Baseline Privacy Interface (optional)

Prerequisites

Downloading the DOCSIS Root Certificate to the CMTS (required)

Adding a Manufacturer's Certificate as a Trusted Certificate (optional)

Adding a Certificate as a Trusted Certificate Using the Command Line Interface

Adding a Certificate as a Trusted Certificate Using SNMP Commands

Adding a Manufacturer's or CM Certificate to the Hotlist (required)

Adding a Certificate to the Hotlist Using the Command Line Interface

Adding a Certificate to the Hotlist Using SNMP Commands

Enabling Concatenation (optional)

Enabling DOCSIS Fragmentation (optional)

Using Enhanced Rate Bandwidth Allocation (ERBA) Support for DOCSIS 1.0 Cable Modems

Configuring Downstream ERBA Settings for DOCSIS 1.0 Cable Modems

Enabling DOCSIS 1.1 Downstream Maximum Transmit Burst on the Cisco uBR10012 Router with PRE2 Modules

Monitoring DOCSIS Operations

Monitoring the DOCSIS Network

Displaying the Status of Cable Modems

Displaying a Summary Report for the Cable Modems

Displaying the Capabilities of the Cable Modems

Displaying Detailed Information About a Particular Cable Modem

Monitoring the RF Network and Cable Interfaces

Displaying Information About the Mac Scheduler

Displaying Information About QoS Parameter Sets

Displaying Information About Service Flows

Displaying Information About Service IDs

Monitoring BPI+ Operations

Displaying the Current BPI+ State of Cable Modems

Displaying the BPI+ Timer Values on the CMTS

Displaying the Certificate List on the CMTS

Command Summary

Configuration Examples for DOCSIS 1.1 Operations

DOCSIS 1.1 Configuration for Cisco uBR7246VXR Router (without BPI+)

DOCSIS 1.1 Configuration for Cisco uBR7246VXR Router (with BPI+)

DOCSIS 1.1 Configuration for Cisco uBR10012 Router (with BPI+)

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance


DOCSIS 1.1 for the Cisco CMTS


Revised: June 6, 2007, 0L-1467-08

This document describes how to configure the Cisco CMTS router for Data-over-Cable Service Interface Specifications (DOCSIS) 1.1 operations.

Feature Specifications for DOCSIS 1.1 Operations

Feature History
Release
Modification

12.1(4)CX

DOCSIS 1.1 support was introduced for Cisco uBR7200 series routers.

12.1(7)CX1

Several DOCSIS 1.1 MIBs were updated, reflecting changes in the DOCSIS 1.1 specification. The cable submgmt default command was also added, to set the default value of the attributes in DOCS-SUBMGT-MIB.

12.2(4)XF1
12.2(4)BC1

DOCSIS 1.1 support was introduced for the Cisco uBR7100 series, Cisco uBR7200 series, and Cisco uBR10012 routers on the Release 12.2 BC train.

12.2(4)BC1b

N+1 redundancy during DOCSIS 1.1 operations was supported on the Cisco uBR10012 router.

12.2(8)BC2

The show cable modem mac command was enhanced to show the DOCSIS capabilities and provisioned state of each cable modem.

12.2(11)BC1

N+1 redundancy during DOCSIS 1.1 operations was supported on the Cisco uBR7200 series router.

12.2(11)BC2

The packetcable authorize vanilla-docsis-mta command was supported to allow DOCSIS 1.1 cable modems to use UGS service flows when PacketCable operations have been enabled.

12.3(13a)BC

Added support for Enhanced Rate Bandwidth Allocation (ERBA) for DOCSIS 1.0 cable modems, to include the following new configuration command and show command enhancement:

cable qos pro max-ds-burst burst-size

show cable qos profile n [verbose]

Refer to the "Using Enhanced Rate Bandwidth Allocation (ERBA) Support for DOCSIS 1.0 Cable Modems" section.

12.3(21)BC

Added support for an enhanced version of ERBA on the Cisco uBR10012 router. Refer to the "Using Enhanced Rate Bandwidth Allocation (ERBA) Support for DOCSIS 1.0 Cable Modems" section.

Supported Platforms

Cisco uBR7100 series, Cisco uBR7200 series, Cisco uBR10012 universal broadband routers.


Finding Support Information for Platforms and Cisco IOS Software Images

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.

Contents

Prerequisites for DOCSIS 1.1 Operations

Restrictions for DOCSIS 1.1 Operations

Information about DOCSIS 1.1

How to Configure the Cisco CMTS for DOCSIS 1.1 Operations

Monitoring DOCSIS Operations

Command Summary

Configuration Examples for DOCSIS 1.1 Operations

Additional References

Prerequisites for DOCSIS 1.1 Operations

To support DOCSIS 1.1 operations, the CMTS must be running Cisco IOS Release 12.1(4)BC1 or later Cisco IOS 12.2 BC Release, and the cable modem must also support the DOCSIS 1.1 feature set. In addition, before you power on and configure the Cisco CMTS, check the following points:

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

Ensure that your Cisco CMTS is installed according to the instructions provided in the appropriate Hardware Installation Guide. The chassis must contain at least one port adapter to provide backbone connectivity and one Cisco cable line card to serve as the RF cable TV interface.

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 virtual private networks (VPNs); and dialup access servers, telephone circuits and connections and other equipment if supporting telco return.

Ensure that DHCP and DOCSIS 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 configuration files. Optionally, ensure that your servers can also download updated software images to DOCSIS 1.0 and DOCSIS 1.1 cable modems.

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.

Ensure that the system clocks on the Cisco 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 Cisco CMTS, which could interfere with BPI+ operations. In particular, this could prevent the proper verification of the digital certificates on the CM.

After these prerequisites are met, you are ready to configure the Cisco CMTS. This includes, at a minimum, configuring a host name and password for the Cisco CMTS and configuring the Cisco CMTS to support IP over the cable plant and network backbone.


Caution If you plan to use service-class-based provisioning, the service classes must be configured at the Cisco CMTS before cable modems attempt to make a connection. Use the cable service class command to configure service classes.

Restrictions for DOCSIS 1.1 Operations

DOCSIS 1.1 operations includes the following restrictions:

Baseline Privacy Interface Plus Requirements

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

Also, 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.


Note 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.


BPI+-Encrypted Multicast Not Supported with Bundled Subinterfaces on the Cisco uBR10012 Router

The current Cisco IOS releases do not support using BPI+ encrypted multicast on bundled cable subinterfaces on the Cisco uBR10012 router. Encrypted multicast is supported on bundled cable interfaces or on non-bundled cable subinterfaces, but not when a subinterface is bundled on the Cisco uBR10012 router. This restriction does not apply to Cisco uBR7200 series routers.

BPI+ Not Supported with High Availability Configurations

The current Cisco IOS releases do not support using BPI+ encrypted multicast on a cable interface when the interface has also been configured for N+1 (1:n) High Availability or Remote Processor Redundancy Plus (RPR+) High Availability redundancy.

In addition, BPI+ is not automatically supported after a switchover from the Working cable interface to the Protect cable interface, because the cable interface configurations that are required for BPI+ encryption are not automatically synchronized between the two interfaces. A workaround for this is to manually configure the Protect cable interfaces with the required configurations.

Cable Interface Cards

DOCSIS 1.1 traffic is supported on Cisco uBR-MC1XC and Cisco uBR-MC28C cable interface line cards. The Cisco uBR-MC11 (FPGA) and Cisco uBR-MC16B line cards do not support DOCSIS 1.1.

Cable Privacy Hotlist CLI Not Supported on Cisco uBR10012 Router

The cable privacy hotlist command is not supported on the Cisco uBR10012 router. To add a manufacturer's or CM certificate to the hotlist on the Cisco uBR10012 router, use SNMP commands to set the appropriate attributes in DOCS-BPI-PLUS-MIB. See the "Adding a Certificate to the Hotlist Using SNMP Commands" section.

DOCSIS Root Certificates

The Cisco CMTS supports only one DOCSIS Root CA certificate.

Maximum Burst Size

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.


Performance

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.

Provisioning

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.

Registration

A DOCSIS 1.1 CMTS must handle the existing registration Type/Length/Value parameters 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 the 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.0 cable modem registers with a DOCSIS 1.1 CMTS, the registration request explicitly requests all nondefault service-class parameters in the registration. The absence of an indirect service class reference eliminates the need for the DOCSIS 1.1 TLVs and eliminates the need to establish a local registration acknowledge wait state.

When a DOCSIS 1.1 CMTS receives a registration request from a DOCSIS 1.0 cable modem, it responds with the DOCSIS 1.0 style registration response and does not expect the cable modem to send the registration-acknowledge MAC message.

Information about DOCSIS 1.1

Feature Overview

DOCSIS 1.1 Quality of Service

Benefits

Feature Overview

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.

The DOCSIS 1.1 specification provides the following feature enhancements over DOCSIS 1.0 networks:

Baseline Privacy Interface Plus

Concatenation

Dynamic MAC Messages

Enhanced Quality of Service

Fragmentation

Interoperability

Payload Header Suppression

Baseline Privacy Interface Plus

DOCSIS 1.0 introduced 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. DOCSIS 1.1 enhances these security features with BPI Plus (BPI+), which includes the following enhancements:

X.509 Digital certificates provide secure user identification and authentication. The Cisco CMTS supports both self-signed manufacturer's certificates and certificates that are chained to the DOCSIS Root CA certificate.

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

1024-bit public key with Pkcs#1 Version 2.0 encryption.

Support for encrypted multicast broadcasts, so that only authorized service flows receive a particular multicast broadcast.

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


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


Concatenation

Concatenation allows a cable modem to make a single time-slice request for multiple upstream packets, sending all of the packets in a single large burst on the upstream. Concatenation can send multiple upstream packets as part of one larger MAC data frame, allowing the cable modem to make only one time-slot request for the entire concatenated MAC frame, reducing the delay in transmitting the packets on the upstream channel. This avoids wasting upstream bandwidth when sending a number of very small packets, such as TCP acknowledgement packets.

Dynamic MAC Messages

Dynamic Service MAC messages allow the cable modem to dynamically create service flows on demand. These messages are DOCSIS link layer equivalents of the higher layer messages that create, tear down, and modify a service flow.

The DOCSIS 1.1 dynamic services state machine supports the following messages:

Dynamic Service Add (DSA)—This message is used to create a new service flow.

Dynamic Service Change (DSC)—This message is used to change the attributes of an existing service flow.

Dynamic Service Deletion (DSD)—This message is used to delete an existing service flow.


Note These messages are collectively known as DSX messages.


Enhanced Quality of Service

DOCSIS 1.1 provides enhanced quality of service (QoS) capabilities 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 and service class 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.

Upstream service flows can be assigned one of the following QoS scheduling types, depending on the type of traffic and application being used:

Best-effort—Data traffic sent on a non-guaranteed best-effort basis. This type of service flow is similar to the method used in DOCSIS 1.0 networks.

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

Non-real-time polling service (nrtPS)—Similar to the rtPS type, in that the cable modem is guaranteed regular opportunities to request data bursts of varying length, except that the CMTS can vary the time between its polling of the cable modem depending on the amount of traffic and congestion on the network.

Unsolicited grants (UGS)—Constant bit rate (CBR) or committed information rate (CIR) traffic, such as voice, that is characterized by fixed-size packets at fixed intervals, providing a guaranteed minimum data rate.

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.

Fragmentation

DOCSIS fragmentation allows the upstream MAC scheduler to slice large data requests to fit into the scheduling gaps between UGS (voice slots). This prevents large data packets from affecting real-time traffic, such as voice and video.

Fragmentation reduces the run-time jitter experienced by the UGS slots when large data grants preempt the UGS slots. Disabling fragmentation increases the run-time jitter, but also reduces the fragmentation reassembly overhead for fragmented MAC frames.


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.


Interoperability

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

Payload Header Suppression

Payload header suppression (PHS) conserves link-layer bandwidth by suppressing repetitive or redundant packet headers on both upstream and downstream service flows. PHS is enabled or disabled per service flow, and each service flow can support a separate set of PHS rules that determine which parts of the header are suppressed. This ensures that PHS is done in the most efficient manner for each service flow and its particular type of application.

DOCSIS 1.1 Quality of Service

The DOCSIS 1.1 QoS framework is based on the following objects:

Service flow—A unidirectional sequence of packets on the DOCSIS link. Separate service flows are used for upstream and downstream traffic, and define the QoS parameters for that traffic.

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 associated with that service class.

Packet classifier—A set of packet header fields used to classify packets onto a service flow to which the classifier belongs. The CMTS uses the packet classifiers to match the packet to the appropriate service flow.

Payload header suppression (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. PHS increases the bandwidth efficiency by removing repeated packet headers before transmission.

See the following sections for more information on these components.

Service Flow

In DOCSIS 1.1, the basic unit of QoS is the service flow, which is a unidirectional sequence of packets transported across the RF interface between the cable modem and CMTS. A service flow defines a set of QoS parameters such as latency, jitter, and throughput assurances, and these parameters can be applied independently to the upstream and downstream traffic flows. This is a major difference from DOCSIS 1.0 networks, where the same QoS parameters were applied to both the downstream and upstream flows.


Note DOCSIS 1.0 networks used service IDs (SIDs) to identify the QoS parameter set for a particular flow. DOCSIS 1.1 networks use the service flow ID (SFID) to identify the service flows that have been assigned to a particular upstream or downstream. DOCSIS 1.1 networks still use the term SID, but it applies exclusively to upstream service flows.


Every cable modem establishes primary service flows for the upstream and downstream directions, with a separate SFID for the upstream and the downstream flows. The primary flows maintain connectivity between the cable modem and CMTS, allowing the CMTS to send MAC management messages at all times to the cable modem.

In addition, a DOCSIS 1.1 cable modem can establish multiple secondary service flows. The secondary service flows either can be permanently created (by configuring them in the DOCSIS configuration file that is downloaded to the cable modem), or the service flows can be created dynamically to meet the needs of the on-demand traffic, such as voice calls. Permanent service flows remain in effect, even if they are not being used, while dynamic service flows are deleted when they are no longer needed.

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 network. Every service flow is identified by an SFID, while upstream service 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.

Service Class

Each service flow is associated with a service class, which defines a particular class of service and its QoS characteristics, such as the maximum bandwidth for the service flow and the priority of its traffic. The service class attributes can be inherited from a preconfigured CMTS local service class (class-based flows), or they can be individually specified when a cable modem dynamically requests a service flow and the CMTS creates it.

The DOCSIS 1.1 service class also defines the MAC-layer scheduling type for the service flow. The schedule type defines the type of data burst requests that the cable modem can make, and how often it can make those requests. The following types of schedule types are supported:

Best-effort (BE)—A cable modem competes with the other cable modems in making bandwidth requests and must wait for the CMTS to grant those requests before transmitting data. This type of service flow is similar to the method used in DOCSIS 1.0 networks.

Real-time polling service (rtPS)—A cable modem is given a periodic time slot in which it can make bandwidth requests without competing with other cable modems. This allows real-time transmissions with data bursts of varying length.

Non-real-time polling service (nrtPS)—A cable modem is given regular opportunities to make bandwidth requests for data bursts of varying size. This type of flow is similar to the rtPS type, in that the cable modem is guaranteed regular opportunities to request data bursts of varying length, except that the CMTS can vary the time between its polling of the cable modem, depending on the amount of traffic and congestion on the network.

Unsolicited grant service (UGS)—A cable modem can transmit fixed data bursts at a guaranteed minimum data rate and with a guaranteed maximum level of jitter. This type of service flow is suitable for traffic that requires a Committed Information Rate (CIR), such as Voice-over-IP (VoIP) calls.

Unsolicited grant service with activity detection (UGS-AD)—Similar to the UGS type, except that the CMTS monitors the traffic to detect when the cable modem is not using the service flow (such as voice calls when nobody is speaking). When the CMTS detects silence on the service flow, the CMTS temporarily switches the service flow to an rtPS type. When the cable modem begins using the flow again, the CMTS switches the flow back to the UGS type. This allows the CMTS to more efficiently support VoIP calls.

Each service flow is assigned a single service class, but the same service class can be assigned to multiple service flows. Also, a cable modem can be assigned multiple service flows, allowing it to have multiple traffic flows that use different service classes.

Packet Classifiers

In DOCSIS 1.0 networks, a cable modem used only one set of QoS parameters for all of its traffic, so the CMTS simply had to route packets to and from the appropriate cable modems. In DOCSIS 1.1 networks, however, cable modems can be using multiple service flows, and each service flow can be given a different level of service. To quickly assign upstream and downstream packets to their proper service flows, the CMTS uses the concept of packet classifiers.

Each packet classifier specifies one or more packet header attributes, such as source MAC address, destination IP address, or protocol type. The classifier also specifies the service flow to be used when a packet matches this particular combination of headers. Separate classifiers are used for downstream and upstream service flows.

When the CMTS receives downstream and upstream packets, it compares each packet's headers to the contents of each packet classifier. When the CMTS matches the packet to a classifier, the CMTS then assigns the proper SFID to the packet and transmits the packet to or from the cable modem. This ensures that the packet is assigned its proper service flow, and thus its proper QoS parameters.

Figure 7-1 illustrates the mapping of packet classifiers.

Figure 7-1 Classification Within the MAC Layer

Packet Header Suppression Rules

Because many data and real-time applications may use fixed values in their packet header fields, DOCSIS 1.1 supports PHS to suppress the duplicate portions of the packet headers when a group of packets is transmitted during a session. Each service flow can support a separate set of PHS rules that determine which parts of the header are suppressed.

When PHS is being used, the transmitting CMTS suppresses the specified headers in all the packets for that service flow. The receiving CMTS then restores the missing headers before forwarding the packets on to their ultimate destination.

Proper use of PHS can increase the efficiency of packetized transmissions, especially for real-time data that is encapsulated by other protocols, such as VoIP traffic.

Quality of Service Comparison

This section summarizes the differences in QoS between DOCSIS 1.0, DOCSIS 1.0+, and DOCSIS 1.1 networks.


Note Cisco CMTS routers running Cisco IOS Release 12.1(4)CX or later can transparently interoperate with cable modems running DOCSIS 1.0, DOCSIS 1.0+ extensions, or DOCSIS 1.1. If a cable modem indicates at system initialization that it is DOCSIS 1.1-capable, the Cisco CMTS router uses the DOCSIS 1.1 features. If the cable modem is not DOCSIS 1.1-capable, but does support the DOCSIS 1.0+ QoS extensions (for example, a Cisco uBR924 cable access router running Cisco IOS Release 12.1(1)T or later release), the Cisco CMTS automatically supports the cable modem's requests for dynamic services. Otherwise, the cable modem is treated as a DOCSIS 1.0 device.


DOCSIS 1.0

DOCSIS1.0 uses a static QoS model that is based on a class of service (CoS) that is preprovisioned in the DOCSIS configuration file that is downloaded to the cable modem. The CoS is a bidirectional QoS profile that applies to both the upstream and downstream directions, and 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 identifies the cable modems that are allowed to transmit on the network. In DOCSIS 1.0 networks, each cable modem is assigned only one SID for both the upstream and downstream directions, creating a one-to-one correspondence between a cable modem and its SID. All traffic originating from, or destined for, a cable modem is mapped to that particular 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, has a limited ability to 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+

In response to the limitations of DOCSIS 1.0 networks 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.

Cisco's DOCSIS 1.0+ extensions include the following DOCSIS 1.1 features:

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 uBR925 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.

Interoperability with Different Versions of DOCSIS Networks

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 CMTS, nor will they interfere with operation of DOCSIS 1.1 features.

Table 7-1 shows the interoperability of a DOCSIS 1.1 CMTS with different versions of cable modems.

Table 7-1 DOCSIS 1.1 Interoperability 

For this configuration...
The result is...
DOCSIS 1.1 CMTS with DOCSIS 1.0 cable modems

DOCSIS 1.0 cable modems receive DOCSIS 1.0 features and capabilities. BPI is supported if available and enabled on the CMTS.

DOCSIS 1.1 CMTS with DOCSIS 1.0+ cable modems

DOCSIS 1.0+ cable modems receive basic DOCSIS 1.0 support. BPI is supported if available and enabled on the CMTS. In addition, DOCSIS 1.0+ 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 CMTS with DOCSIS 1.1 cable modems

DOCSIS 1.1 cable modems receive all the DOCSIS 1.1 features listed in this document. BPI+ is supported if 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.

Baseline Privacy Interface Plus Enhancement

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 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.

Dynamic Service Flows

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 QoS 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.

Concatenation

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 packet. This reduces the delay in transferring the packet burst upstream.

Enhanced QoS

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 cable modem to isolate different types of traffic into different DOCSIS service flows. Each flow could be receiving a different QoS service from CMTS.

Fragmentation

Fragmentation splits large data packets so that they fit into the smaller time slots inbetween UGS slots. This 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.

Multiple Subflows per SID

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

Payload Header Suppression (PHS) allows the CMTS and cable modem to suppress repetitive or redundant portions in packet headers before transmitting on the DOCSIS link. This conserves 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.

Service Classes

The use of the service class provides the following benefits for a DOCSIS 1.1 network:

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.


How to Configure the Cisco CMTS for DOCSIS 1.1 Operations

See the following sections for the configuration tasks for DOCSIS 1.1 operations. Each task in the list is identified as either required or optional.

Configuring Baseline Privacy Interface (optional)

Downloading the DOCSIS Root Certificate to the CMTS (required)

Adding a Manufacturer's Certificate as a Trusted Certificate (optional)

Adding a Manufacturer's or CM Certificate to the Hotlist (required)

Enabling Concatenation (optional)

Enabling DOCSIS Fragmentation (optional)

"Using Enhanced Rate Bandwidth Allocation (ERBA) Support for DOCSIS 1.0 Cable Modems" section


Note This section describes only the configuration tasks that are specific for DOCSIS 1.1 operations. For complete configuration information, see the software configuration documents listed in the "Additional References" section.


Configuring Baseline Privacy Interface (optional)

BPI+ encryption is by default enabled for 56-bit DES encryption on all cable interfaces. If BPI+ encryption has been previously disabled, or if you want to reconfigure BPI+ encryption on a cable interface on the CMTS, use the following procedure.


Note If you have disabled BPI+ encryption on a cable interface, and a cable modem attempts to register on that interface using BPI+ encryption, the CMTS will reject its registration request, displaying a %UBR7200-4-SERVICE_PERMANENTLY_UNAVAILABLE error message. The show cable modem command will also show that this cable modem has been rejected with a MAC status of reject(c).


Prerequisites

BPI+ encryption is supported on all Cisco CMTS images that include "k1", "k8", or "k9" in its file name or BPI in the feature set description. All BPI images support 40-bit and 56-bit DES encryption.

By default, BPI+ encryption is enabled for 56-bit DES encryption. Also, when a cable modem is running DOCSIS 1.1 software, BPI+ encryption is enabled by default, unless the service provider has disabled it by setting the Privacy Enable field (TLV 29) in the DOCSIS configuration file to 0. Therefore, both the CMTS and cable modem are set to use BPI+ encryption when using the default configurations.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface cable x/y

4. cable privacy

5. cable privacy 40-bit-des

6. cable privacy accept-self-signed-certificate


Caution Cisco strongly recommends that this above command remain unconfigured, as it bypasses DOCSIS BPI+ certificates. Otherwise, self-signed certificates provide workaround registration for cable modems that are not compliant with DOCSIS BPI+ certificates. This functionality is strictly intended for troubleshooting of a short duration or in the context of additional security measures.

7. cable privacy authenticate-modem

8. cable privacy authorize-multicast

9. cable privacy mandatory

10. cable privacy oaep-support

11. cable privacy kek {grace-time seconds | life-time seconds}

12. cable privacy tek {grace-time seconds | life-time seconds}

13. exit

14. exit

DETAILED STEPS

 
Command
Purpose

Step 1 

enable

Example:

Router> enable

Router#

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Router(config)#

Enters global configuration mode.

Step 3 

interface cable x/y

Example:

Router(config)# interface cable 6/0

Router(config-if)#

Enters interface configuration mode for the cable interface line card at this particular slot.

Step 4 

cable privacy

Example:

Router(config-if)# cable privacy

Router(config-if)#

(Optional) Enables BPI+ 56-bit DES encryption on the cable interface (default).

Step 5 

cable privacy 40-bit-des

Example:

Router(config-if)# cable privacy 48-bit-des

Router(config-if)#

(Optional) Enables BPI+ 40-bit DES encryption on the cable interface. Cisco does not recommend this option for production systems because 40-bit encryption is not as secure as the 56-bit DES or 168-bit 3DES encryption algorithms.

Step 6 

cable privacy accept-self-signed-certificate

Example:

Router(config-if)# cable privacy accept-self-signed-certificate

Router(config-if)#

(Optional) Allows cable modems to register using self-signed manufacturer certificates, as opposed to the default of allowing only manufacturer's certificates that are chained to the DOCSIS root certificate.


Caution Cisco strongly recommends that this command remain unconfigured, as it bypasses DOCSIS BPI+ certificates. Otherwise, self-signed certificates provide workaround registration for cable modems that are not compliant with DOCSIS BPI+ certificates. This functionality is strictly intended for troubleshooting of a short duration or in the context of additional security measures.

Note By default, the CMTS does not accept self-signed certificates. In the default configuration, if a cable modem attempts to register with self-signed certificates, the CMTS will refuse to allow the cable modem to register.

Step 7 

cable privacy authenticate-modem

Example:

Router(config-if)# cable privacy authenticate-modem

Router(config-if)#

(Optional) Enables BPI+ encryption on the cable interface and uses the Cisco IOS Authentication, Authorization and Accounting (AAA) service together with BPI to authenticate the CMs.

Step 8 

cable privacy authorize-multicast

Example:

Router(config-if)# cable privacy authorize-multicast

Router(config-if)#

(Optional) Enables BPI+ encryption on the cable interface and uses AAA protocols to authorize all multicast stream (IGMP) join requests.

Note If you use this command to authorize multicast streams, you must also use the cable privacy authenticate-modem command to enable AAA services on the cable interface.

Step 9 

cable privacy mandatory

Example:

Router(config-if)# cable privacy mandatory

Router(config-if)#

(Optional) Enables BPI+ encryption on the cable interface and requires baseline privacy for all CMs. If a CM does not enable BPI or BPI+ encryption in its DOCSIS configuration file, it will not be allowed to come online.

Step 10 

cable privacy oaep-support

Example:

Router(config-if)# cable privacy oaep-support

Router(config-if)#

(Optional) Enables BPI+ encryption on the cable interface and enables Optimal Asymmetric Encryption Padding (OAEP). This option is enabled by default. Disabling this option could have a performance impact.

Step 11 

cable privacy kek {grace-time seconds | life-time seconds}

Example:

Router(config-if)# cable privacy kek grace-time 480

Router(config-if)# cable privacy kek life-time 302400

Router(config-if)#

(Optional) Configures the grace-time and life-time values for the key encryption keys (KEKs) for BPI+ operations on all cable interfaces.

grace-time seconds1 —(DOCSIS 1.0 BPI only) The amount of time before the KEK key expires that the CM should begin renegotiating a new key. The valid range is 60 to 1800 seconds, with a default of 600 seconds (10 minutes).

life-time seconds—The maximum amount of time, in seconds, that a KEK key can be considered valid. The valid range is 300 to 604,8000, with a default of 604,800 seconds (7 days).

Step 12 

cable privacy tek {grace-time seconds | life-time seconds}

Example:

Router(config-if)# cable privacy tek grace-time 1800

Router(config-if)# cable privacy tek life-time 86400

Router(config-if)#

(Optional) Configures the grace-time and life-time values for the traffic encryption keys (TEKs) for BPI+ operations on all cable interfaces.

grace-time seconds1—(DOCSIS 1.0 BPI only) The amount of time before the TEK key expires that the CM should begin renegotiating a new key. The valid range is 60 to 1800 seconds, with a default of 600 seconds (10 minutes).

life-time seconds—The maximum amount of time, in seconds, that a TEK key can be considered valid. The valid range is 180 to 604,8000, with a default of 43,200 seconds (12 hours).

Step 13 

exit

Example:

Router(config-if)# exit

Router(config)#

Exits interface configuration mode.

Note Repeat steps Step 3 through Step 13 for each cable interface.

Step 14 

exit

Example:

Router(config)# exit

Router#

Exits global configuration mode.

1 The KEK and TEK grace-time values apply only to DOCSIS 1.0 cable modems using BPI encryption. Cable modems that are running DOCSIS 1.1 software configure the grace-time values in their DOCSIS configuration files, and those values automatically override the CMTS settings. If a DOCSIS 1.1 configuration file does not specifically contain the grace-time values, the cable modem defaults to 600 seconds, which is the value that the CMTS then uses for the modem.

You can also configure the following additional timers for BPI+ operations in the DOCSIS configuration file for each cable modem. As a general rule, you do not need to specify these timers in the DOCSIS configuration file unless you have a specific reason for changing them from their default values.

Table 7-2 Individual Cable Modem BPI+ Timer Values

Timer
Description

Authorize Wait Timeout

The amount of time a cable modem will wait for a response from a CMTS when negotiating a KEK for the first time.

Reauthorize Wait Timeout

The amount of time a cable modem will wait for a response from a CMTS when negotiating a new KEK because the Authorization Key (KEK) lifetime is about to expire.

Authorization Grace Timeout

The grace period for reauthorization (in seconds).

Authorize Reject Wait Timeout

The amount of time a cable modem must wait before attempting to negotiate a new KEK if the CMTS rejects its first attempt to negotiate a KEK.

Operational Wait Timeout

The amount of time a cable modem will wait for a response from a CMTS when negotiating a TEK for the first time.

Rekey Wait Timeout

The amount of time a cable modem will wait for a response from a CMTS when negotiating a new TEK because the TEK lifetime is about to expire.


Downloading the DOCSIS Root Certificate to the CMTS (required)

DOCSIS 1.1 allows cable modems to identify themselves using a manufacturer's chained X.509 digital certificate that is chained to the DOCSIS root certificate. To enable the use of these digital certificates in the DOCSIS network, you must download the DOCSIS root certificate from the Verisign website and copy it to the bootflash on the Cisco CMTS router.


Tip For more information about the DOCSIS root certificate provided by Verisign, see the information at the following URL:

http://www.verisign.com/products/cable/index.html



Note This document previously claimed that the Cisco CMTS supports only one root certificate. This information has changed effective with Cisco IOS Release 12.3(9a)BC. In this IOS release and later releases in the 12.3 BC train, you may load the DOCSIS root certificate and a EuroDOCSIS or PacketCable root certificate. Cisco recommends that the EuroDOCSIS PacketCable root certificates be copied into bootflash.

In prior Cisco IOS Releases, with the prior limitation, EuroDOCSIS or PacketCable devices could still come online, however, if they used self-signed manufacturer's digital certificates.


To download the DOCSIS root certificate to the Cisco CMTS, which is required if any cable modems on the network are using chained certificates, use the following procedure:


Step 1 Download the DOCSIS root certificate from the DOCSIS certificate signer, Verisign. At the time of this document's printing, the DOCSIS root certificate is available for download at the following URL:

http://www.verisign.com/products/cable/root.html

Step 2 Verisign distributes the DOCSIS root certificate in a compressed ZIP archive file. Extract the DOCSIS root certificate from the archive and copy the certificate to a TFTP server that the CMTS can access.


Tip To avoid possible confusion with other certificates, keep the file's original filename of "CableLabs_DOCSIS.509" when saving it to the TFTP server.


Step 3 Log in to the Cisco CMTS using either a serial port connection or a Telnet connection. Enter the enable command and password to enter Privileged EXEC mode:

Router> enable 

Password: <password>

Router# 

Step 4 Use the dir bootflash command to verify that the bootflash has sufficient space for the DOCSIS root certificate (approximately 1,000 bytes of disk space):

Router# dir bootflash: 

Directory of bootflash:/ 

    1  -rw-     3229188   Dec 30 2002 15:53:23  ubr7200-boot-mz.122-11.BC2.bin 

3407872 bytes total (250824 bytes free)
Router# 


Tip If you delete files from the bootflash to make room for the DOCSIS root certificate, remember to use the squeeze command to reclaim the free space from the deleted files.


Step 5 Use the copy tftp bootflash command to copy the DOCSIS root certificate to the router's bootflash memory. (The file must be named "root-cert" on the bootflash for the CMTS to recognize it as the root certificate.)

Router# copy tftp bootflash: 

Address or name of remote host []? tftp-server-ip-address 
Source filename []? CableLabs_DOCSIS.509 
Destination filename [CableLabs_DOCSIS.509]? root-cert 
Loading CableLabs_DOCSIS.509 from tftp-server-ip-address (via FastEthernet0/0): !
[OK - 996/1024 bytes]

996 bytes copied in 4.104 secs (249 bytes/sec)
Router# 


Tip If you are using Cisco IOS Release 12.2(4)BC1 or later software release, you can also copy the root certificate to a PCMCIA Flash Disk (disk0 or disk1). However, because Flash Disks are unsecure and easily removed from the router, we recommend that you keep the root certificate in the bootflash for both operational and security reasons.


Step 6 Verify that the DOCSIS root certificate has been successfully copied to the bootflash memory:

Router# dir bootflash: 

Directory of bootflash:/

    1  -rw-     3229188   Dec 30 2002 15:53:23  ubr7200-boot-mz.122-11.BC2.bin 
    2  -rw-         996   Mar 06 2002 16:03:46  root-cert

3408876 bytes total (248696 zxbytes free)
Router# 

Step 7 (Optional) After the first cable modem has registered using BPI+, you can use the show crypto ca trustpoints command to display the Root certificate that the CMTS has learned:


Note The show crypto ca trustpoints command does not display the root certificate until after at least one cable modem has registered with the CMTS using BPI+ encryption. Alternatively, you can use the unsupported command test cable generate in privileged EXEC mode to force the CMTS to register the root certificate.


Router# show crypto ca trustpoints 

Root certificate
  Status: Available
  Certificate Serial Number: D54BB68FE934324F6B8FD0E41A65D867
  Key Usage: General Purpose
  Issuer: 
    CN = DOCSIS Cable Modem Root Certificate Authority
     OU = Cable Modems
     O = Data Over Cable Service Interface Specifications
     C = US
  Subject Name: 
    CN = "BPI Cable Modem Root Certificate Authority "
     OU = DOCSIS
     O = BPI
     C = US
  Validity Date: 
    start date: 07:00:00 UTC Mar 27 2001
    end   date: 06:59:59 UTC Jan 1 2007



Tip To display all certificates (Root, Manufacturers, CM) that the CMTS has learned, use the show crypto ca certificates command.


Adding a Manufacturer's Certificate as a Trusted Certificate (optional)

To DOCSIS specifications allow operators to control which manufacturer's and CM certificates are allowed on each CMTS by marking them as either trusted or untrusted. You can add a certificate to the list of trusted certificates on the Cisco CMTS using either CLI commands or SNMP commands, as described in the following sections:

Adding a Certificate as a Trusted Certificate Using the Command Line Interface

Adding a Certificate as a Trusted Certificate Using SNMP Commands


Note Unless you cannot use SNMP to configure the cable modem, or have a particular application that requires the use of CLI commands to add certificates, you should also use the SNMP method to add certificates to a cable modem.


Adding a Certificate as a Trusted Certificate Using the Command Line Interface

To add a manufacturer's certificate to the list of trusted certificates on the CMTS, use the following procedure:

SUMMARY STEPS

1. enable

2. configure terminal

3. cable privacy add-certificate manufacturer hex-data

4. exit

DETAILED STEPS

 
Command
Purpose

Step 1 

enable

Example:

Router> enable

Router#

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Router(config)#

Enters global configuration mode.

Step 3 

cable privacy add-certificate manufacturer hex-data

Example:

Router(config)# cable privacy add-certificate manufacturer 0001020304050CFD0E0F0A01EB02BC0304

0F019E020D230C04CD050B060A07080AF102E30405


Router(config)#

(Optional) Specifies the hexadecimal data for the manufacturer CA certificate to be added as a trusted certificate. Enter the actual certificate contents as hexadecimal data in the hex-data string. Enter multiple lines as needed, and use a blank line to terminate the string.

Step 4 

exit

Example:

Router(config)# exit

Router#

Exits global configuration mode.

Adding a Certificate as a Trusted Certificate Using SNMP Commands

You can also use an SNMP manager to create and add certificates to the CMTS list of trusted certificates by manipulating the tables and attributes in the DOCS-BPI-PLUS-MIB. To add a manufacturer's certificate, add an entry to the docsBpi2CmtsCACertTable table. Specify the following attributes for each entry:

docsBpi2CmtsCACertStatus—Set to 4 to create the row entry.

docsBpi2CmtsCACert—The hexadecimal data, as an X509Certificate value, for the actual X.509 certificate.

docsBpi2CmtsCACertTrust—An Integer value from 1 to 4 specifying the certificate's trust status: 1=trusted, 2=untrusted, 3= chained, 4=root. Specify 1 for certificates that should be trusted and 3 for chained certificates that should be verified with the root certificate.

Similarly, to add a CM certificate to the list of trusted certificates, add an entry to the docsBpi2CmtsProvisionedCmCertTable table. Specify the following attributes for each entry:

docsBpi2CmtsProvisionedCmCertStatus—Set to 4 to create the row entry.

docsBpi2CmtsProvisionedCmCert—The hexadecimal data, as an X509Certificate value, for the actual X.509 certificate.