The Data-over-Cable Service Interface Specifications (DOCSIS) 1.1 standard gives Cable Service Providers the opportunity to deploy a whole new suite of sophisticated multimedia and real-time services. Before these services can be deployed, it is important that current data services are able to be migrated from a DOCSIS 1.0 operating environment to a DOCSIS 1.1 operating environment. (Best Effort is defined below.)

This document describes how to convert a currently working DOCSIS 1.0 system to a DOCSIS 1.1/DOCSIS 1.0 hybrid system, and then finally to a totally DOCSIS 1.1 based system. This document also discusses commonly used Cisco IOS® software commands that have been modified, enhanced, or replaced in DOCSIS 1.1 enabled Cisco IOS.

This document will primarily focus on migrating existing Best Effort Data services from a DOCSIS 1.0 environment to a DOCSIS 1.1 environment.

Hardware and Software Versions

The information in this document is based on the software and hardware versions below.

The DOCSIS 1.0 based Cisco IOS software used to prepare this document was 12.1(10)EC1. In this document, any captured CLI session that was run on a CMTS running 12.1(10)EC1 will have router prompt uBR7246VXR_1.0.

The DOCSIS 1.1 based Cisco IOS software used to prepare this document was 12.2(4)BC1a. In this document, any captured CLI session that was run on a CMTS running 12.2(4)BC1a will have router prompt uBR7246VXR_1.1.

The hardware used to prepare this document was a uBR7246VXR, however all Cisco CMTS platforms are capable of running DOCSIS 1.1 Cisco IOS software, subject to memory requirements and Cable line card hardware revisions as specified in the relevant platform Release Notes.

New Functionality Provided by DOCSIS 1.1

Although this document will not go into detail about deploying new functionality available in DOCSIS 1.1, it is worthwhile briefly discussing some of the new concepts and capabilities that DOCSIS 1.1 brings to a Data over Cable environment.

Service Flows

In a DOCSIS 1.0 environment a Cable Modem was associated with a Service Identifier (SID). By configuring the appropriate parameters in a DOCSIS configuration file, the SID could be associated with a Quality of Service Profile that applied to both upstream and downstream traffic between the Cable Modem and the CMTS.

DOCSIS 1.1 introduces the concept of Service Flow and a Service Flow Identifier (SFID). A Service Flow represents either an upstream or a downstream flow of data which can be uniquely identified by a SFID. Each Service Flow can be assigned it's own Quality of Service parameters known as a QoS Parameter Set. The major impact of this is that the upstream and downstream Class of Service are decoupled, or independent of each other, in DOCSIS 1.1. The term SID is still used in DOCSIS 1.1 and corresponds to an upstream service flow in a DOCSIS 1.1 environment.

In the most basic kind of configuration a Cable Modem will be assigned a Primary downstream SFID and a Primary upstream SFID, each with its own unique QoS Parameter Set which defines the Class of Service attributes of that SFID. The Primary upstream SFID will also have a corresponding Primary SID. These Service Flows are primarily responsible for passing MAC management and keepalive traffic between the Cable Modem and the CMTS.

Multiple Service Flows can be assigned per cable modem in either the upstream or downstream direction, and each of these Service Flows can correspond to different a QoS Parameter Set with different characteristics. This is conducive to allowing the Cable Modem to accommodate for multiple kinds of data traffic at once, such as standard Internet traffic and Voice over IP (VoIP).

Dynamic Service Establishment and Advanced Upstream Scheduling Services

In DOCSIS 1.0 systems Cable Modems needed to contend for permission to make transmissions and compete with other Cable Modems for bandwidth. This mode of operation was known as a Best Effort service. This was suitable for classic Internet applications such as email and web browsing, which are applications that have no particular requirements for latency, jitter, or, in many, cases throughput.

Modern IP enabled services such as VoIP and MPEG Video over IP have a requirement for an assured rate of throughput, as well as strict requirements for latency and jitter, which could not be provided in a Best Effort environment. In addition, these kinds of services are not typically always active and, as such, resources to accommodate them need only be allocated when these services are required. For this reason DOCSIS 1.1 provides a range of modes for Cable Modem data transmission that can be initiated and terminated dynamically to accommodate these advanced IP services. Each of these modes can be applied to a DOCSIS 1.1 QoS Parameter Set which will define the characteristics of a Service Flow.

Unsolicited Grant Service (UGS) - A Service Flow is created that allows a Cable Modem to transmit fixed size bursts of data at a guaranteed rate and with a guaranteed level of jitter by providing periodic transmission opportunities to the Cable Modem for fixed sized frames. This kind of Service Flow is particularly suitable for Voice over IP applications.

Real-Time Polling Service (rtPS) - A Service Flow is created giving a periodic opportunity for a Cable Modem to request permission to transmit data by polling one Cable Modem for a bandwidth request, rather than all modems. This satisfies applications that have a requirement for real time data transmission as well as allowing the cable modem to transmit data bursts of varying length. This kind of Service Flow is particularly suitable for MPEG video over IP.

Unsolicited Grant Service with Activity Detection (UGS/AD) - This kind of Service Flow is a combination of UGS and rtPS and is useful for services that require a UGS style of fixed size and fixed rate transmission opportunities, but have significant periods where no data is being sent. One good example of this might be a Voice over IP phone call where up to 50% or more of the call may be silence and require no data transmission. While words are being spoken and packetized voice needs to be transmitted, the Cable Modem receives UGS style grants from the CMTS. When there is silence, the CMTS detects the absence of data and switches to a rtPS style mode, which temporarily frees up upstream bandwidth. When the conversation restarts and the Cable Modem needs to transmit more packetized voice, the Cable Modem transmits a further request to the CMTS via an rtPS granted opportunity and then the UGS style grants recommence.

Non-Real-Time Polling Service - This kind of Service Flow is like the rtPS, however polling will typically occur at a much lower rate and may not necessarily be periodic. This applies to applications that have no requirement for a real time service but may need an assured high level of bandwidth. An example of this may be a bulk data transfer or an Internet Gaming application.

Each of these kinds of Service Flows may be active for a Cable Modem simultaneously ensuring that real time and non real time applications can seamlessly coexist.

Classifiers

DOCSIS 1.1 provides a mechanism for Cable Modems and the CMTS to direct different kinds of IP traffic into different Service Flows, and hence provide different levels of service to different kinds of traffic. Classifiers can be defined based on Source or Destination MAC address, 802.1Q VLAN ID, 802.1P priority, EtherType, Source and Destination IP address or network, IP Protocol Type, Source or Destination Port number, IP Type of Service Bits and any combination thereof.

A simple example of how a classifier might be used would be to match VoIP traffic from a particular source IP address and UDP port and to direct that traffic into a dynamically created Service Flow that had a QoS Parameter Set providing a UGS mode of data transmission.

Fragmentation

In DOCSIS 1.0 environments, Cable Modems could not split large Ethernet frames into multiple fragments for transmission at different times. This meant that at low upstream channel widths and symbol rates, other Cable Modems would potentially have to wait for a long time for large frames to be transmitted before being able to make their own transmissions. This kind of delay due to serialization of large frames is not acceptable for real time applications as it increases jitter and latency.

DOCSIS 1.1 introduces the ability for cable modems to divide large frames of data into smaller parts so that data from real time services can be interleaved with larger pieces of data from non real time services. This ensures that jitter and latency requirements for real time services are able to be guaranteed even on channels with a low symbol rate or high congestion.

Payload Header Suppression

Many kinds of real time applications, such as VoIP, may use fixed values in packet header fields over the course of a session or transaction. DOCSIS 1.1 introduces Payload Header Suppression (PHS) which can be used by a transmitting entity to suppress packet header fields with a fixed value. These fields are then restored by the receiving entity, hence saving bandwidth during the transmission.

This feature would typically be used in conjunction with one of the UGS style services described above to decrease the overhead associated with the Ethernet/IP/UDP encapsulation of real time packetized data.

Baseline Privacy Plus

A simple traffic encryption scheme called Baseline Privacy (BPI) was available in DOCSIS 1.0 to provide rudimentary data security and data integrity checking services.

This scheme has been greatly enhanced in DOCSIS 1.1 to produce Baseline Privacy Plus (BPI+). The major architectural improvement in BPI+ is the use of X.509 Digital Certificates and the Public Key Infrastructure (PKI). By using unique Digital Certificates, which are permanently stored within each Cable Modem by the modem manufacturer, end users are inhibited from falsifying their Cable Modem's identity and stealing or interrupting service.

The other major advantage of BPI+ is support for encrypted multicast sessions. Rather than having multicast traffic able to be received by all users on a cable segment, BPI+ allows Cable Service providers to be able to control access to multicast streams on a per cable modem basis by sharing details of how to decrypt the multicast streams with authorized modems.

Next Section>>>

Updated: Dec 09, 2002

Document ID: 22030

Migrating Simple Data over Cable Services to DOCSIS 1.1

Contents

Introduction