PCMM Environment Overview
The PacketCable Multimedia (PCMM) specification defines a standards-based way to deliver premium quality of service (QoS)–enhanced services across the radio frequency (RF) portion of a cable network. The PCMM capabilities of the SRC software along with Juniper Networks routers provide an end-to-end solution that seamlessly links the cable operator’s RF domain with IP edge and core QoS services.
Key services supported in this environment include:
Bandwidth on demand and variable bandwidth
QoS-enabled streaming media, including video on demand and video telephony
Residential voice over IP (VoIP)
Multicast audio and video applications
Peer-to-peer controls and protection services
Figure 5 depicts the PCMM architectural framework. The basic roles of the various PCMM components are:
Application manager—Provides an interface to policy server(s) for the purpose of requesting QoS-based service on behalf of a subscriber or a network management system. It maps session requests to resource requests and creates policies.
Policy server—Acts as a policy decision point and policy enforcement point and manages relationships between application managers and cable modem termination system (CMTS) devices.
CMTS device—Cable modem termination system. Performs admission control and manages network resources through Data over Cable Service Interface Specifications (DOCSIS) service flows.
Client—Represents endpoints, such as PC applications, that can send or receive data.
Record-keeping server—Receives event messages from other network elements, such as the policy server or CMTS device, and acts as a short-term repository for the messages. It can also assemble event messages into coherent sets or call detail records, which are then made available to other back office systems, such as billing, fraud detection, and other systems.
In the PCMM architecture, a client requests a multimedia service from an application manager. The application manager relays the request to a policy server. The policy server is then responsible for provisioning the policies on a CMTS device. Based on the request, the policy server records an event that indicates the policy request. The request can include network resource records, and the policy server can provide the records to a record-keeping server, such as a RADIUS accounting server.
The policy server may also provide functions such as tracking resource usage and tracking the authorization of resources on a per-subscriber, per-service, or aggregate basis.
The DOCSIS protocol is the standard for providing quality of service for traffic between the cable modem and CMTS devices. The CMTS device is the head-end in the DOCSIS architecture, and it controls the operations of many cable modems. Two channels carry signals between CMTS devices and cable modems:
Downstream channels—Carry signals from the CMTS head-end to cable modems.
Upstream channels—Carry signals from the cable modems to the CMTS head-end.
The DOCSIS protocol defines the physical layer and the Media Access Control (MAC) protocol layer that is used on these channels.
A cable modem usually uses one upstream channel and an associated downstream channel. Upstream channels are shared, and the CMTS device uses the MAC protocol to control the cable modem’s access to the upstream channel.
The DOCSIS protocol uses the concept of service flows to support QoS on upstream and downstream channels. A service flow is a unidirectional flow of packets that provides a particular quality of service. Traffic is classified into a service flow, and each service flow has its own set of QoS parameters. The SRC software is compliant with the following upstream service flow scheduling types, as defined in the PacketCable Multimedia Specification PKT-SP-MM-I03-051221.
Best effort—Used for standard Internet traffic such as Web browsing, e-mail, or instant messaging.
Non-real-time polling service (NRTPS)—Used for standard Internet traffic that requires high throughput, and traffic that requires variable-sized data packets on a regular basis, such as high-bandwidth File Transfer Protocol (FTP).
Real-time polling service (RTPS)—Used for applications such as Moving Pictures Experts Group (MPEG) video.
Unsolicited grant service (UGS)—Used for real-time traffic that generates fixed-size data packets on a periodic basis. Applications include VoIP.
Unsolicited grant service with activity detection (UGS-AD)—Used for applications such as voice activity detection, also known as silence suppression.
Downstream service flows are defined through a similar set of QoS parameters that are associated with the best-effort scheduling type on upstream service flows.
The PCMM specification uses the concept of clients and defines a client as a logical entity that can send or receive data. The SRC software supports type 1 and type 2 clients.
The PCMM specification defines two resource reservation models for each client type—a single phase and a dual phase. The SRC software supports the single-phase model.
Client Type 1 Single Phase Resource Reservation Model
Type 1 clients represent endpoints, such as PC applications or gaming consoles, that lack specific QoS awareness or signaling capabilities. Type 1 clients communicate with an application manager to request a service. They do not request QoS resources directly from the multiple service operator (MSO) network.
Client type 1 entities support the proxied-QoS with policy-push scenario of service delivery defined in PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH). In this scenario, the application manager requests QoS resources on behalf of the client, and the policy server pushes the request to the CMTS device. The CMTS device sets up and manages the DOCSIS service flow that the application requires, and might also set up and manage the cable modems.
Figure 6 shows the message flow in an application scenario for the client type 1 single-phase resource reservation model.
Client Type 2 Single Phase Resource Reservation Model
Type 2 clients represent endpoints that have QoS awareness or signaling capabilities. Type 2 clients communicate with an application manager to request a service and to obtain a token to present for requesting QoS resources directly from the MSO network.
Client type 2 entities support the client-requested QoS with policy-push scenario of service delivery defined in PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH). In this scenario, the application manager requests QoS resources on behalf of the client, and the policy server pushes the request to the CMTS device. The CMTS device sets up and manages the DOCSIS service flow that the application requires. After the CMTS device sets up the policy, the client can request QoS resources directly from the CMTS device as long as the request is authorized by the policy server.
Figure 7 shows the message flow in an application scenario for the client type 2 single-phase resource reservation model.
SRC Software in the PCMM Environment
Figure 8 shows the SRC software in the PCMM environment. The SAE is an application manager that can manage a PCMM-compliant policy server and/or a CMTS device on behalf of applications. The SAE has an embedded policy server that is not fully PCMM-compliant, but it can manage CMTS devices without requiring an external policy server.
The SRC software supports three types of policies that you can use to define traffic profiles between the CMTS device and the cable modem:
DOCSIS parameters—Specifies the traffic profile through DOCSIS-specific parameters. You select the type of service flow that you want to offer, and then configure QoS parameters for the service flow.
Service class name—Specifies the name of a service class that is configured on the CMTS device.
FlowSpec—Defines the traffic profile through an Resource Reservation Protocol (RSVP)-like parameterization scheme. FlowSpecs support both controlled-load and guaranteed services.
You can also mark packets and then install policies that handle the marked packets in a certain way. The mark action sets the ToS byte in the IP header of IPv4 traffic or the traffic-class field in the IP header of IPv6 traffic.
For more information about traffic profiles, see Delivering QoS Services in a Cable Environment.
End-to-End QoS Architecture
The previous sections show how the SRC software supports QoS in the cable operator’s RF domain, which encompasses the connection from the cable modem to the CMTS device. Using the SRC software along with Juniper Networks routers, you can link the RF domain to the subscriber and service edge domains.
IP subscriber edge domain—Includes the IP network from the CMTS device to the edge router that typically connects to the cable operator’s regional access network. (See Extending QoS to the Subscriber Edge Domain.)
IP service edge domain—Typically includes the IP network that connects the data center that houses service delivery applications to a backbone or directly to a cable head-on facility. (See Extending QoS to the Service Edge Domain .)
By provisioning services across a network path, you can deliver a particular level of service for specified types of traffic. Figure 9 shows a typical high-level architecture of a cable operator and how the SRC software and Juniper Networks routers can be deployed to deliver end-to-end QoS services.
Extending QoS to the Subscriber Edge Domain
The subscriber edge domain includes subscriber edge routers that aggregate CMTS devices. To support QoS in subscriber edge domains, QoS must be enabled across the subscriber edge into the core or regional access network. When the SRC software receives a service request, it performs service authorization, which can include admission control. It then sends policies to the appropriate CMTS device and subscriber edge router interface.
In addition to the QoS services required in the RF domain, service policies in the subscriber edge domain that must be available for provisioning at this point include:
Policy routing to best-of-breed appliances and premium paths
Rate limiting, traffic shaping, and marking
Admission control (edge resources and core resources)
Captive portal and Web redirect capabilities
Filtering and routers running Junos OS–based firewall services
Routers running Junos OS virtual private network (VPN) services
Extending QoS to the Service Edge Domain
The service edge domain includes service edge routers that aggregate applications. To support QoS in service edge domains, the SRC software sends policies to a service edge router that provides for enhanced service delivery to the service origination edge for centralized or hosted services, such as multimedia or VoD.
In addition to the QoS services required in the RF domain, service policies in the service edge domain that must be capable of being provisioned at this point include:
Policy routing to best-of-breed appliances and premium paths
Rate limiting, traffic shaping (called hierarchical queuing in JunosE software), and marking
Filtering and routers running Junos OS–based firewall services
Routers running Junos OS VPN services
Provisioning End-to-End Services
The following sections provide examples of how you can use the SRC software to provision services for video applications. Although the examples show one SAE managing all the network devices, separate SAEs could manage each device and provide the same service.
Example for Videoconferencing Services
You can configure services to mark traffic forwarded from specified systems, and then apply an end-to-end service level for that traffic. Figure 10 shows a scenario in which videoconferencing is delivered in a PCMM environment.
To ensure a specified level of service from each client PC to the videoconference server and then to each client PC participating in the videoconference, you could configure the following types of services:
A service that provides policies to mark packets with a specified type of service for the videoconferencing software.
A service that provides policies for the type of service specified for CMTS device.
A service that provides policies for the type of service specified for the routers running Junos or JunosE Software.
An infrastructure service for each service.
An aggregate service that contains the three infrastructure services as fragment services.
This configuration marks packets that the CMTS device receives from both client and server, and applies forwarding policies on the CMTS device and on the routers running JunosE or Junos OS for packets sent to and received from the videoconferencing server.
Example for Video-on-Demand Services
You can configure services to provide server-to-client service for traffic sent from a video-on-demand server to client PCs. Figure 11 shows a scenario in which video on demand is delivered in a PCMM environment.
To ensure a specified level of service from the video-on-demand server to the client PC, you could configure the following types of services:
Services that provide bandwidth-on-demand (BoD) policies for traffic that is being forwarded from the video-on-demand server through:
Routers running Junos OS
A script service that sets up the Multiprotocol Label Switching (MPLS) path and delivers the specified service level for traffic that is being forwarded from the video-on-demand server through the MPLS domain.
An infrastructure service for each value-added and script service.
An aggregate service that contains all the infrastructure services as fragment services.
This configuration applies BoD policies to routers running JunosE or Junos OS, the MPLS domain, and the CMTS device, and sets up the MPLS path from router running Junos OS (2) to router running Junos OS (1).