How PacketCable Provides Security and QoS in VoIP Deployments

It's hard to turn on the television or listen to the radio these days without hearing an advertisement for digital phone service. Broadband providers are rapidly growing their telephony subscriber base by utilizing their IP infrastructure to provide service at a much smaller cost than that of the legacy Public Switched Telephone Network (PSTN).

According to the National Cable & Telecommunications Association (NCTA), there were approximately 9.5 million residential cable telephony customers by the end of 2006; up from ~5.9 million at the end of 2005 and ~3.8 million at the end of 2004. Service providers with no direct control of the broadband network are in the mix as well with VoIP service offerings.

So, how do the technologies used to provide VoIP telephony work and what differentiates one service provider's offering from another?

Two differentiating metrics are security and quality of service (QoS). In this article, you will learn how cable providers utilize PacketCable to ensure a high level of QoS and security for their customers. You will also see how third party service providers are unable to provide these same services.

What is PacketCable you may ask? In 1988 the Cable Television industry formed a non-profit research and development consortium called CableLabsTM to help them integrate emerging technologies into their business. One of the projects identified by CableLabs is PacketCable. The PacketCable project defines an architecture for delivering real-time multimedia services over a bidirectional cable plant. The initial phases of PacketCable focus on the specific service of residential telephony.

The diagram below depicts how VoIP service provider networks are typically implemented.

In the upper left-hand portion of the figure, is Subscriber 1 who has telephony service from the local cable company. This cable company, commonly referred to as a Multiple System Operator (MSO) has chosen to implement PacketCable.

As you can see in the diagram, there are several components in the PacketCable architecture:

  • Cable modem termination system (CMTS)
  • Call agent (CA)
  • Media gateway (MG)
  • Signaling gateway (SG)
  • Cable modem equipped with telephony support (otherwise known as the embedded Multimedia Terminal Adapter - eMTA)

PacketCable functional areas include the following:

  • Mechanisms for eMTA provisioning
  • Call signaling
  • Voice stream encoding and transport
  • Dynamic QoS (DQoS)
  • Resource accounting
  • Security

A majority of VoIP cable deployments utilize most, if not all, of the functional aspects defined in the PacketCable architecture.

Subscribers 2, 3, and 4 also have a VoIP telephony service except their service is not using a PacketCable implementation. Subscribers 2 and 3 both have high-speed Internet access from their cable MSO, but their telephony service is from a third party: Provider X.

Subscriber 2 is using a standalone Multimedia Terminal Adapter (sMTA), which is simply a device with traditional telephony ports and a LAN connection (Ethernet, USB, wireless) to connect to a cable modem.

Subscriber 3 is using a PC software application for his/her telephony service. As with the sMTA case, the PC is connected to a cable modem through some sort of LAN connection. The MSO controls the operation and configuration of the CMTS and cable modems. Since the MSO is not providing the telephony service in both of these cases, it cannot differentiate the voice traffic from other types of traffic.

Note: Another release of PacketCable called PacketCable Multimedia could be used to provide some measure of QoS and security to third party applications, but this would require a Service Level Agreement (SLA) between the MSO and the third party provider and is outside the scope of this article.

Subscriber 4 is shown to illustrate how a VoIP customer from one provider can talk to a VoIP customer from another provider over an IP backbone. Subscriber 4 may or may not be a cable VoIP customer; this subscriber is shown to detail how different providers can interconnect securely and provide QoS for the traffic they exchange.

So, how are QoS and security different for subscriber 1's service compared to subscriber 2's and subscriber 3's services? In order to fully understand this you need to be familiar with the way IP packets are sent across a DOCSIS cable plant.

DOCSIS is another CableLabs project, which defines the mechanisms and protocols used to provide IP connectivity over a two-way cable plant. Two RF communication channels are used: a downstream channel for data sent from the CMTS to a group of cable modems, and an upstream channel for data sent from these cable modems to the CMTS.

On the downstream channel, data is seen by all the DOCSIS devices (cable modems, set-top boxes, etc.) on a particular cable plant. DOCSIS devices and the CPE host devices behind them have MAC addresses enabling each DOCSIS device to identify packets destined for itself and its hosts. Because the upstream channel is shared among multiple devices (typically in the hundreds), upstream bandwidth is divided into timeslots which are allocated by the CMTS to particular DOCSIS devices for particular transmission types.

Timeslot intervals can be dedicated to a single device (unicast) or made available for any device to use (broadcast). Transmission types include "data grants" for sending IP packets (which are typically unicast) and "bandwidth requests" (which are typically broadcast). When a cable modem needs to transmit a packet, it uses a broadcast request interval to ask the CMTS for a data grant of a certain size. If the request gets through to the CMTS and the CMTS determines it can honor the request, it will assign a data grant for that modem.

As you might imagine, if there are several modems trying to send upstream data, there is a good chance broadcast requests will collide and need to be retransmitted before one successfully gets through to the CMTS. Even if the request is heard by the CMTS, it may be unable to honor the request due to a lack of available upstream bandwidth. At the very least, the request may be delayed for a while until the CMTS can honor it. Consequently, this type of upstream scheduling is referred to as "Best Effort" because service is not guaranteed.

"Best Effort" service is used for high-speed data Internet traffic. It is also used for voice telephony if you have VoIP service from a provider other than your cable company, such as the case with subscribers 2 and 3. "Best Effort" services are not well suited for real-time applications like voice. These applications are sensitive to packet delays and drops.

Another DOCSIS upstream service known as the "Unsolicited Grant Service" (UGS) is much better suited for voice. With UGS, the CMTS periodically gives a modem (in this case a PacketCable eMTA) dedicated data grants of a fixed size to send voice packets. The eMTA doesn't need to transmit any request packets for these data grants as they are unsolicited. These grants will be continually provided to the eMTA whether they are used or not. If they aren't being used, such as when the eMTA is idle, this is a waste of upstream bandwidth. Thus, UGS flows are not nailed up and instead are dynamically created when a phone call is made and torn down when the call is over. Parameters in the call signaling messages used to create, modify, and delete VoIP calls trigger the dynamic creation, modification, and deletion of the QoS enabled UGS flow - hence this is called dynamic QoS (DQoS).

In addition to the creation of the upstream UGS flow, a separate QoS enabled downstream flow is dynamically created for voice packets. The CMTS gives these downstream flows preferential treatment over other types of downstream flows; this is typically done through the implementation of a Low Latency Queue (LLQ).

Three protocols are used to provide PacketCable DQoS:

  • DOCSIS between the eMTA and CMTS
  • Common Open Policy Service (COPS) protocol between the CA and CMTS
  • Network-based Call Signaling (NCS) protocol between the CA and eMTA

The COPS protocol is used to create and authorize a logical concept known as a "gate" on the CMTS before any QoS is set up for voice calls. An identifier for the gate must be included in the MTAs request for QoS before the CMTS will allow it. Consequently, any requests for QoS without legitimate gate identifiers will be rejected at the CMTS and no QoS will be provided for these "bad" requests. In a deployment without COPS you must either allow all QoS requests or none because you are unable to differentiate between "good" and "bad" requests.

PacketCable DQoS also gives a MSO the ability to mark voice packets by setting DSCP codepoints as they leave the CMTS. Packets can then be identified for QoS treatment across the MSO's IP backbone. Voice packets from third party devices will not be marked and will not receive QoS treatment across the MSO IP backbone.

Referring back to the diagram, subscriber 1's eMTA will have a UGS upstream flow and a QoS enabled downstream flow dynamically set up whenever a phone call is made or received and voice packets will be marked. Subscriber 2's CM and subscriber 3's CM will not have QoS enabled flows for their phone calls and voice packets will not be marked. Notice in these cases no call signaling messaging occurs between the MSO's CMTS and Provider X's CA or between the CMTS and the CMs. The dotted green lines represent the QoS enabled voice flow for subscriber 1 and the dotted red lines represent the non-QoS enabled voice flows for subscribers 2 and 3.

If subscriber 1 is talking to someone who has service in the PSTN, QoS is provided for the entire path from the eMTA thru the CMTS to the MG. If subscriber 1 is talking to someone who has service in a different VoIP network, such as subscriber 4, QoS and security can still exist end-to-end. In this case, the MSO and VoIP Provider Y would need to have a SLA in place.

The Session Border Controller (SBC) between the networks handles functions like DSCP remarking and IP address/UDP port translations. The SBC can also generate resource accounting information. The voice flows from subscriber 2 and 3 will receive no special QoS or security treatment across the MSO's DOCSIS or IP networks. In fact, the firewall between the Internet and the Provider X is the first place where any value-added services could potentially be implemented.

You've just learned how PacketCable gates provide security by authorizing DQoS requests. This is just one of many security mechanisms addressed in PacketCable. Denial of service attacks and theft of service attacks are undoubtedly among the greatest concerns of any service provider. Theft of service attacks include "cloned" devices masquerading as legitimate ones in order to steal service as well as attempts to "listen in" on legitimate users in order to learn private information.

A denial of service attack is where a malicious user attempts to prevent the service of legitimate users. This could be by overloading the network with traffic or by intercepting user traffic and re-routing it. As an example, suppose someone is able to redirect all call signaling traffic intended for the call agent to a dummy one that "black holes" the traffic.

The PacketCable secure method for provisioning MTAs uses digital certificates to establish security keys that ensure other PacketCable functionality (i.e. provisioning, call signaling) is securely communicated. These certificates allow devices to be authenticated and security associations to be established preventing the possibility of cloning. If these security associations incorporate encryption algorithms then it is now nearly impossible for another party to decrypt the inter-device communication.

During the PacketCable provisioning process sensitive information such as configuration file names and content can be encrypted and authenticated as well. In a non-PacketCable environment these safeguards may not be in place and there is a risk that the security of the client telephony device could be compromised.

In summary, PacketCable provides both quality of service and security by guaranteeing bandwidth in a timely manner, marking voice packets, and ensuring only authorized devices are able to use the network. PacketCable allows a cable MSO to be more than just a raw bit provider and gives them a significant edge over other service providers that have no control over the MSO's transport network.

About the author:

Jeff Riddel is a Network Consulting Engineer within Cisco's Broadband Advanced Services team. He has several years of experience providing broadband consulting & testing expertise to the major US cable companies as well as several international cable companies. Jeff has worked on various Cisco VoIP products and solutions and is a Cisco Certified Internetworking Expert (CCIE), a Cisco Cable Communications Specialist (CCCS), and a member of the Society of Cable Telecommunications Engineers (SCTE). Additionally, Jeff has a BS and a MS degree in Electrical Engineering from the Georgia Institute of Technology. Jeff's recent publication, PacketCable Implementation, is on sale now and can be purchased at bookstores, computer/electronic stores, online booksellers, or at

PacketCable Implementation
Jeff Riddel, CCIE No. 12798
ISBN: 1587051818
Pub Date: 2/9/2007
US SRP $75.00
Publisher: Cisco Press
Read Chapter 12* of this book.

*Reproduced from the book PacketCable Implementation. Copyright© [2007], Cisco Systems, Inc.. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other uses.