Chapter 14: Multimedia Applications

Application Server (AS)

In many cases, it is beneficial to have another device handle the multimedia session requests on behalf of the client. This device is known as the Application Server (AS). You just learned that a majority of today's PCMM clients are of type 1, which know nothing about QoS or PacketCable. So for these clients, an AS is typically used to initiate multimedia sessions. The AS might or might not be managed by the MSO. The means in which session requests are communicated from the client to the AS is unspecified by PCMM.

Application Manager (AM)

The device that handles PCMM requests from clients (either directly or via an AS) is the Application Manager (AM). In addition to coordinating client application requests, an AM maintains application-level state and is the device responsible for applying service policies. Because clients and AS devices are typically untrusted, the AM also authenticates incoming requests.

Just as the communication protocol between the client and AS is unspecified in PCMM, the communication protocol between the client and AM is also unspecified. The protocol used between the AS and AM is specified and is the PacketCable Multimedia Web Service Interface Specification (PKT-SP-MM-WS). This specification defines the use of a SOAP/extensible markup language (SOAP/XML)-based web services interface for AS to AM communication. Please refer to this specification for the details on how this communication is done.

One example of an AM is a call agent. A call agent communicates with clients (in this case, gateways) using a signaling protocol such as Media Gateway Control Protocol (MGCP) or SIP. Remember, in PCMM the protocol used between the AM and clients is undefined. When a gateway wants to make a phone call, it contacts the call agent using the signaling protocol. The call agent then determines whether the gateway is authorized to make the call and figures out how to route the call. The call agent can also determine the QoS resources required for the call and signal this information to another device. Recall this is done in PacketCable 1.x by converting SDP information into RSVP flow specifications sent in COPS messages. In PCMM this other device is the policy server, and the protocol used to send this policy information is COPS.

Another sample AM is a simple web server. Suppose this server receives HTML requests from a client for an application such as streaming media. After the server determines whether the client is authorized to receive the media, it figures out the QoS resources required and sends this information to the policy server.

Yet another example might be a gaming console that signals a server to initiate a game against an opponent in another geographic area. In this case, a proprietary protocol is usually used between the gaming console and the server. The gaming server authorizes the gaming console, determines the required QoS resources, and sends this information to the policy server.

In all these cases, if everything is successful, a gate identifier referring to the QoS resources is eventually returned to the AM. It's important to remember that the gate identifier is not sent to PCMM client type 1 devices from the AM. These clients are "QoS-unaware," so they wouldn't know what to do with this information. Instead, the AM reserves and commits resources on behalf of the client. The signaling protocol between the client and the application manager can be used to determine when the AM should reserve or commit resources, however.

The AM might not know the entire details on how to signal the policy server for QoS for an application. In this case, it might simply use a Service Name in the request to the Policy Server (PS) and let the PS handle converting the Service Name into the various QoS parameters. Obviously, for this to work common service names need to be configured on the AM and PS components.

Policy Server (PS)

The Policy Server is the device responsible for taking the service requests from the AM and converting them into resource policy requests used to set up quality of service resources on a CMTS.

The PS also applies policy rules to requests received from the AM. Sample policies include limits on the number of gates allocated to a subscriber, limits on the types of QoS available to a subscriber, limits on which applications a policy server accepts, and limits on the impact of service on a particular CMTS. Assuming all checks pass, the PS figures out where that subscriber is and "pushes" a policy to the CMTS where the subscriber's cable modem is connected. So as you can see, the AM doesn't need to know what CMTS the subscriber's modem is attached to; the PS figures this out instead.

The PS also functions as a proxy between the AM and CMTS as it sees all the QoS messages to and from these devices. Because of this, an MSO might elect to deploy PS devices in a hierarchical fashion to satisfy scalability and redundancy concerns. In this case, some policy servers can be used to make per-subscriber policy decisions, others to make per-CMTS policy decisions, others to make per-region policy decisions, and so on.

Policy servers can also be classified as "stateful" or "stateless," similar to the SIP proxy servers discussed in Chapter 9, "Call Management Server Signaling Protocol (CMSS)." A stateful PS keeps track of gates and resources and can be used to notify you when resources become scarce. Stateless policy servers do not have the ability to track resources, but as a tradeoff they are simpler to implement.

So what component is like the Policy Server in PacketCable 1.x? The answer is the Gateway Controller (GC) component of the CMS. This is the COPS server that controls gate creation on a CMTS. The call agent component of the CMS that controls telephony call states is similar to the AM.

Cable Modem Termination System (CMTS)

The CMTS is the COPS Policy Enforcement Point (PEP) for premium DOCSIS resources in PacketCable Multimedia, just as it is in PacketCable telephony. It communicates policy information with one or more Policy Servers for the authorization of resources. This information can either be "pushed" to the CMTS by the PS or "pulled" to the PS from the CMTS, depending on the client type. Currently, only client type 1 devices are supported, so policy information is always "pushed" to the CMTS in PCMM. Also with client type 1 devices, DOCSIS DSX messages will always initiate from the CMTS as these messages are triggered by the policy information "pushed" by the PS. This is a key difference from PacketCable 1.x, where the DSX messaging initiates from the MTA. The CMTS can be instructed to track DOCSIS resource use based on time requirements and traffic volume requirements.

Cable Modem (CM)

The requirement of a cable modem in PacketCable Multimedia is the same as it is in PacketCable telephony; it must operate in at least DOCSIS 1.1 mode. The clients are generally assumed to be non-embedded (as opposed to the embedded MTA defined in PacketCable 1.x that interfaces directly with the DOCSIS layer). Thus, all client communication is done through the CM using protocols over ordinary IP.

RKS

The RKS component also serves a similar function as it did in PacketCable telephony. It uses event messaging to keep track of QoS resources. The difference here is that messages come from policy servers as well as CMTSs. Also event messaging in PCMM is generalized because several of the messages and parameters previously defined are meaningful only for the telephony application.

Service and Resource Control Domains

Many of the concepts in this chapter are related to the concepts introduced in Chapter 12, "DQoS Architecture and Framework." One of these concepts was the COPS terminology of Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs).

A PDP is the COPS server requesting or denying a policy creation, and the PEP is the COPS client where the policy is applied. Remember that in PacketCable 1.x the CMTS is the PEP, and the gate controller function of the CMS is the PDP. In PCMM, COPS is used in two places; hence, you have two sets of PDP/PEP relationships. The CMTS is a PEP in its communication with the PS, and the PS in the PDP in its communication with the CMTS. But the PS is a PEP in its communication with the AM, and the AM is the PDP.

Because policy servers perform both COPS functions, the multimedia specification separates the policy domains into a resource control domain (RCD) and a service control domain (SCD). Figure 14-1 illustrates how these different domains apply to PCMM.

The RCD is the logical grouping of elements that provide connectivity (that is, CMTS, CM, Hybrid Fiber Coaxial [HFC] network) and network resource-level policy management (that is, Policy Server) along the packet forwarding paths to and from a client. In the RCD, the CMTS is the PEP and the PS is the PDP.

The SCD is the logical grouping of elements that offer applications and content (that is, Application Servers and Application Managers) to service subscribers (clients). The SCD is associated more with the higher-level concept of services than with physical DOCSIS resources. In the SCD, the PS is the PEP and the AM is the PDP. Multiple SCDs can operate in a single RCD, and a single SCD can operate in multiple RCDs. For example, in a particular cable division, both a gaming application and a videoconferencing application might be available. Likewise, the gaming application might be available in multiple cable divisions.

For example, assume you have a type 1 multimedia client wanting to use a particular application. It signals this to the AM (either directly or via the AS). The AM then makes decisions based on SCD policies on whether or not the client is authorized to use the application. If it is, the AM figures out what the required QoS resources are for the application and issues a request to a PS. The PS then makes a decision based on RCD policies on whether or not the client is authorized to use the proposed QoS resources. If it is, the request is sent to the CMTS where the client is connected. Then, if the CMTS has the physical resources to grant the request, it does so, and it sends the gate identifier to the PS. The PS then in turn forwards this information back to the AM. Thus, the PS proxies QoS requests between the AM and CMTS. In fact, the PS translates SCD parameters into RCD parameters, and vice versa.

PCMM DOCSIS Usage Considerations

The use of the DOCSIS 1.1 protocol in PCMM is virtually the same as it is in PacketCable telephony. You have authorized, reserved, and committed resource envelopes, and gates are used to correlate DOCSIS service flow requests to these resource envelopes.

The main difference is that upstream scheduling types in addition to the Unsolicited Grant Service (UGS) and Unsolicited Grant Service with Activity Detection (UGS-AD) types discussed previously can also be used. Specifically, the Real-Time Polling Service (RTPS) and Non Real-Time Polling Service (nRTPS) are used. Also note that the Best Effort (BE) upstream scheduling type can be used to provide premium QoS services through the use of DOCSIS parameters such as traffic priority and minimum reserved rate. In other words, you can guarantee, restrict, or prioritize bandwidth on a BE flow using QoS.

Remember that all downstream service flows are Best Effort, but these same DOCSIS parameters can be used to provide QoS. So, refer to Chapter 12 or the DOCSIS specifications for the details on those parameters.

The RTPS service is designed for real-time applications that generate variable-sized data at periodic intervals. It works by providing periodic dedicated request opportunities. The modem then uses these request opportunities to specify the size of the data grants it requires. This service type is well-suited for applications such as MPEG video. The nRTPS service is designed for non real-time applications requiring variable-sized data grants on a regular basis. These applications are ensured request opportunities even during congestion periods. One difference between nRTPS and RTPS is that the jitter between successive requests does not matter for nRTPS because its applications are not sensitive to delay variations. Also the polling interval used in nRTPS flows is typically much greater (that is, less frequent) than it is with RTPS.

Service flow parameters used to define RTPS, nRTPS, and BE services include

• Service Identifier—The 14-bit service identifier is assigned by the CMTS to reference the upstream service flow. It is used in the bandwidth allocation messages to identify the user of a data or request opportunity. It is also used in the DOCSIS extended header to reference the device sending the packet.

• Service Flow Scheduling Type—This field identifies the scheduling service for upstream data and request transmissions. This is where the service flow is identified as a Best Effort (2), Non Real-Time Polling (3), Real-Time Polling (4), UGS-AD (5), or UGS (6) service.

• Request/Transmission Policy—This field is a bitmap that controls when and how the service flow can transmit data and data requests. A bit value of 1 indicates true, and a bit value of 0 indicates false. The lower nine bit positions are defined as shown in Table 14-1.

Table 14-1 Request/Transmission Policy Bits

• Nominal Polling Interval—Interval in microseconds for dedicated request opportunities; used in the RTPS and nRTPS services to give the CM uncontested opportunities to signal the CMTS.

• Tolerated Poll Jitter—Amount of time in microseconds the polling interval is permitted to vary from the Nominal Polling Interval. This parameter is used for the RTPS service type.

• Minimum Reserved Traffic Rate—Can be used for BE, RTPS, and nRTPS service flows; the minimum rate in bits per second reserved for the service flow. The packet size is from after the DOCSIS Header Check Sequence to the cyclic redundancy check (CRC) at the end of the packet. In other words, the "Ethernet" portion of the DOCSIS overhead is included, but the general 6-byte DOCSIS header and any DOCSIS extended headers are not.

• Maximum Sustained Traffic Rate—Can be used for BE, RTPS, and nRTPS service flows. The token bucket (R) parameter for rate-limiting packets is expressed in bits per second. Packet size is calculated the same as in the previous parameter.

• Traffic Priority—Used for nRTPS and BE service flows; defines the service flow priority. If multiple service flows exist that are identical in all QoS parameters besides priority, the higher priority service flow is given preference. If not included, the default priority of 0 is used. For example, if you have 10 residential users configured with a Best Effort service of priority 0 and 10 commercial services users configured with a Best Effort service of priority 3, the CMTS services data grants from the commercial services users before the residential users.

In PCMM, the use of service class names to define dynamic flows is also permitted. You'll see more about how this is done later in the chapter. The concept and use of service class names is defined in the DOCSIS RFI specification. A service class name can be defined in the DOCSIS modem configuration file instead of all the class of service or service flow QoS parameters. The modem then sends this name in the DOCSIS registration request to the CMTS. On the CMTS, this service class name is also defined along with its corresponding QoS parameters. After the CMTS receives the registration request, it looks up the service class name and returns its parameters to the modem in the registration response message. Thus, a cable operator can simplify its modem provisioning by just using service class names in configuration files corresponding to the customer's level of service; for example, you might have a "Bronze," "Silver," and "Gold" service. The details of these service levels are defined on each CMTS and could be different on different CMTSs if desired.

Not only can static flows make the use of service class names, but dynamic flows can as well. In this case, the service class name is included in the DOCSIS dynamic service flow messages.

---

Note - When a flow is defined with a service class name, additional QoS parameters can be defined as well. If the same parameters are defined on the CMTS and with the service class name, the parameters defined with the name take precedence. For example, if a Max Sustained Rate of 512 kbps is defined in a modem configuration file along with a service class name of "Bronze," and in the CMTS definition of service class name "Bronze" the Max Sustained Rate is defined as 256 kbps, the modem's Max Sustained Rate is 512 kbps.

---

PCMM COPS Usage Considerations

The COPS protocol is used in two places in PCMM:

• Between the application manager and policy server

• Between the policy server and CMTS

The use of the COPS protocol in PCMM is a bit different than the use of it in PacketCable telephony. First of all, remember that a PacketCable 1.x gate referred to two gates--one upstream and one downstream--sharing the same gate identifier. In PCMM, gates are truly unidirectional, and a gate ID refers to either an upstream gate or a downstream gate. Also previously a gate was used to define the authorized envelope of resources for an embedded MTA; in PCMM, gates can be used to define the reserved and committed resource envelopes as well as the authorized envelope. Remember, the committed or active envelope is always less than or equal to the reserved or admitted envelope, which is in turn always less than or equal to the authorized envelope.

The common header for each COPS packet is similar to the format used in PacketCable telephony; the only difference is that the client type is set to a different value, as shown in Figure 14-2.

Figure 14-2

PCMM COPS Header Format

After this header are a number of objects in the form shown in Figure 14-3.

Figure 14-3

PCMM COPS Object Format

COPS Initialization

The initialization process in PCMM is almost the same as in PacketCable telephony. One difference is that the PEP (CMTS or PS) listens on TCP port 3918 as opposed to port 2126 in telephony.

---

Note - This allows a CMTS to support PacketCable telephony and PCMM simultaneously without interfering with each other.

---

After the TCP session is established, the PEP sends a COPS Client-Open (OPN) message to the PDP; in this message, the PEP identifies itself and includes the Version Info object. The PDP then responds with a Client-Accept (CAT) message containing the value of the Keep-Alive timer. The PEP then responds to this message with a Request (REQ) message to the PDP.

As is the case with PacketCable telephony, the PDP must be configured with the location of the PEP; however, the PEP does not need to be configured with the location of the PDP for the COPS connections to be established. This is assuming that IP Security (IPsec) is not being used for the COPS connection. If IPsec is being used, both the PDP and PEP need to be explicitly configured to have a security association between them.

PEP to PDP Heartbeats

As with PacketCable 1.x, keepalive messages (message type 9—KA) are sent from the PEP to the PDP periodically. The PDP responds to these keepalive messages by sending a keepalive message back to the PEP. If the PDP fails to receive a keepalive message from the PEP by the keepalive timer value, it assumes the connection has been lost. It then attempts to reestablish the TCP connection, which if successful causes the PEP to reinitialize the COPS connection. Similarly, if the PEP fails to receive the keepalive echo from the PDP, it assumes the connection has been lost and listens for a new TCP connection.

PacketCable Multimedia Objects in COPS

Remember that in PacketCable 1.x PacketCable gate messages sent from the CMS to the CMTS are sent in COPS Decision (DEC) messages, and PacketCable gate messages sent from the CMTS to the CMS are sent in COPS Report State (RPT) messages. In this case, the CMS is the PDP and the CMTS is the PEP. The same rules apply in PCMM—that is, PCMM gate messages sent from the PDP to the PEP are sent in COPS DEC messages, and PCMM gate messages sent from the PEP to the PDP are sent in COPS RPT messages.

As shown in Figure 14-3, PacketCable objects sent in DEC messages are included in Client Specific Decision Data objects (C-Num 6, C-Type 4) and PacketCable objects sent in RPT messages are included in Signaled Client SI objects (C-Num 9, C-Type 1). In either case, these objects begin with a 2-byte length field followed by another 1-byte object number and 1-byte subtype definition. These are referred to as the S-Num and S-Type, respectively.

PacketCable Multimedia COPS objects are as follows:

• Transaction Identifier (S-Num = 1, S-Type = 1)

• Application Manager Identifier (AMID) (S-Num = 2, S-Type = 1)

• Subscriber Identifier (S-Num = 3, S-Type = 1)

• Gate Identifier (S-Num = 4, S-Type = 1)

• Gate Specification (S-Num = 5, S-Type = 1)

• Classifier/Extended Classifier (S-Num = 6, S-Type = 1, 2)

• Traffic Profile (S-Num = 7, S-Type = 1, 2, 3, 4, 5, 6, 7, 8)

• Event-Generation-Info (S-Num = 8, S-Type = 1)

• Volume-Based Usage Limit (S-Num = 9, S-Type = 1)

• Time-Based Usage Limit (S-Num = 10, S-Type = 1)

• Opaque Data (S-Num = 11, S-Type = 1)

• Gate Time Info (S-Num = 12, S-Type = 1)

• Gate Usage Info (S-Num = 13, S-Type = 1)

• PacketCable Error (S-Num = 14, S-Type = 1)

• Gate State (S-Num = 15, S-Type = 1)

• Version Info (S-Num = 16, S-Type = 1)

• Policy Server Identifier (PSID) (S-Num = 17, S-Type = 1)

• Synch Options (S-Num = 18, S-Type = 1)

• Msg Receipt Key (S-Num = 19, S-Type = 1)

The following sections describe these PacketCable Multimedia COPS objects in greater detail.

Transaction ID

This object correlates responses to commands. It consists of a 2-byte transaction identifier followed by the 2-byte gate command type. The gate command type identifies the DQoS message type. Table 14-2 shows the possible values.

Table 14-2 PCMM DQoS Message Types