In order for a user to access a service offered by a provider—whether that service is telephony or simple data access—there must be a communications link between that user and the service provider's facilities. In this chapter from Digital Telephony Over Cable, the authors look at the essential facilities provided by DOCSIS modems operating on an HFC access network.

This sample chapter is excerpted from Digital Telephony Over Cable.

The KEK is a two-key triple DES encryption key that the CMTS uses to encrypt
Traffic Encryption Keys (TEKs) it sends to the modem. Traffic encryption keys
are used for encrypting user data traffic. CM and CMTS use message authentication
keys to authenticate, via a keyed message digest, the key requests and responses
they exchange.

SP-BPI+-I02-990731

In order for a user to access a service offered by a provider—whether
that service is telephony or simple data access—there must be a communications
link between that user and the service provider's facilities. On a cable
network, that link is implemented through the cable modem, or CM, located in
the user's residence, and the Cable Modem Termination System, or CMTS,
located in the headend. All traffic between the user and the network travels
over this CM-CMTS link.

The CM-CMTS link is not symmetric. Cable modems are not at all like the ordinary
analog modems commonly used for low-speed access over analog telephone lines.
Rather, they are complex devices that act as clients to the CMTS, which in turn
directs in real-time exactly how the each CM on the access network is to behave.

The DOCSIS Specifications

Early cable modems were designed according to specifications developed by
individual manufacturers using proprietary protocols. Although many of these
modems worked well, because each manufacturer adopted a different protocol it
was impossible for them to interoperate. Since the cable modem communicates with
a CMTS, this meant that once a service provider decided on a particular
vendor's CMTS, its customers were immediately locked into using only cable
modems from the same vendor. Because several vendors were competing to produce
CM-CMTS pairs, the market was fragmented and the hardware was relatively
expensive.

In order to standardize the CM-CMTS protocols, a consortium of cable operators
was formed. This consortium was called the Multimedia Cable Network System,
or MCNS,1 and
its stated goal was to prepare "a series of interface specifications that
will permit the early definition, design, development and deployment of data-over-cable
systems on an [sic] uniform, consistent, open, non-proprietary, multi-vendor
interoperable basis". These specifications are collectively referred to
as the Data-Over-Cable Service InterfaceSpecifications or "DOCSIS".

Note that the original emphasis was on data over cable. The first
version of DOCSIS was designed to support only ordinary data communication.
Telephony communication has requirements over and above those needed for data
(in particular, telephony requires guaranteed Quality of Service and enhanced
privacy); support for these requirements was added in version 1.1 of the DOCSIS
specifications.

The current version of the DOCSIS specifications may be
downloaded from
http://www.cablemodem.com.
Table 3-1 lists the versions that were current at the time this book was
written. The DOCSIS specifications are intended to define the behavior of Cable
Modem and Cable Modem Termination System devices in sufficient detail that
products conforming to the specifications will be interoperable. The
specifications are not designed to imply any particular method of implementing
these devices.

PacketCable telephony is designed to run over DOCSIS version 1.1 or later.
Theoretically, the entire PacketCable network is independent of the underlying
layers and infrastructure. In theory, PacketCable could be implemented to run
over a completely different technology such as DSL or wireless. However, when
the PacketCable telephony network was being designed, the strengths and
weaknesses of DOCSIS 1.1 were taken into account, so that many of the design
decisions reflect the assumption that DOCSIS 1.1 is being used over the access
network.

The relationship between PacketCable and DOCSIS is shown in Figure
3-1. All current implementations of PacketCable use the Quality of Service
"hooks" provided by DOCSIS and discussed later in this chapter. In
principle, DOCSIS and PacketCable can be completely decoupled: PacketCable could
be built on a completely different access technology. Similarly, a totally different
telephony architecture could be constructed on top of DOCSIS. However, as of
this writing, there is no indication that any vendor intends to separate the
PacketCable telephony "application" from the underlying DOCSIS transport.

Note that in this chapter, we will be discussing the behavior of cable
modems, not of MTAs. In the current release of PacketCable, these are intended
to be embedded in the same device, since there is no standard API that allows a
cable modem to be driven by an external MTA. This sometimes leads to a certain
level of sloppiness when referring to CMs and MTAs. However, in the future MTAs
and CMs will migrate to become physically distinct entities and a clear
distinction will have to be made. The cable modem will remain the point where
the home network interfaces to the cable, and it will continue to function as
described in this chapter.