The Cable Access Link
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 Interface Specifications 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.
Table 3-1DOCSIS Specifications
|
SP-BPI1-I02-990731 |
Baseline Privacy Plus Interface Specification—Specifies security over the cable access network. |
|
SP-CMTRI-I01-970804 |
Cable Modem Telephony Return Interface Specification—Specifies the use of telephone lines for upstream information flow. |
|
SP-CMTS-NSII01-960702 |
Cable Modem Termination System–Network Side Interface Specification—Specifies how the network interfaces with HFC. |
|
TR-DOCS-OSSIW08-961016 |
Operations Support System Framework for Data Over Cable Services—Specifies a high-level framework for OSS for data services over cable. |
|
SP-RFIv1.1-I02-990731 |
Radio Frequency Interface Specification—Provides a low-level description of communication between a cable modem and the Cable Modem Termination System. |
|
SP-OSSI-RFI-I03-990113 |
Operations Support System Interface Specification Radio Frequency Interface—RF Interface MIBs |
|
SP-OSSI-BPI-I01-980331 |
Operations Support System Interface Specification Baseline Privacy Interface MIB–Privacy MIBs |
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.
){kind=link}
Figure 3-1 DOCSIS and PacketCable
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.