Chapter 14: Multimedia Applications

PCMM Components

The first step in understanding how PCMM works is to look at what the various contributing components are. Figure 14-1 is a high-level illustration of the devices involved in providing PacketCable Multimedia services.

Figure 14-1

PacketCable Multimedia Components

As you can see from the diagram, seven components are used to provide PCMM services:

• Multimedia clients
• Application Server
• Application Manager
• Policy Server
• Cable modem termination system (CMTS)
• Cable modem (CM)
• Record Keeping Server (RKS)

The following sections describe these components in further detail.

PacketCable Multimedia Clients

Logically, the multimedia client is the device using a multimedia service. One example would be a software application on a personal computer providing streaming audio or video, such as Internet radio or perhaps a movie. Another example is a gaming console connected to the Internet to play against an opponent across the country. Another example is a video camera and monitor used to provide a video conferencing service. And yes, another example is an MTA used to provide telephony service.

Usually, multimedia client devices are not provided by the MSO and are located at the customer’s premises, so they are untrusted devices. These devices connect to the MSO network through the cable modem. This connection could be Ethernet, USB, or wireless. The exception to this is a multimedia client embedded in the cable modem itself, such as the embedded MTA you are no doubt familiar with by now.

PacketCable multimedia clients are categorized as one of three types:

• Client Type 1—Client type 1 is what most of today’s multimedia clients are. These clients have no knowledge or awareness of PacketCable, DOCSIS, or even QoS. In fact, this client type is commonly referred to as QoS-unaware. These clients are generic IP networking applications such as PC applications and gaming consoles.

  These devices are at the mercy of the application manager to set up quality of service resources. You’ll learn more about application managers later in the chapter.

• Client Type 2—Client type 2 devices are similar to the embedded MTA devices used in PacketCable telephony. These devices are aware of PacketCable, DOCSIS, and QoS but they also require an application manager to do the QoS resource allocation and part of the authorization. However, this type of client still does much of the QoS resource manipulation. This type of client is commonly referred to as Push model.

• Client Type 3—The third type of multimedia client is also PacketCable QoS-aware. The difference between it and a type 2 device is that these devices do not need an application manager to set up QoS resources. These devices use the Resource Reservation Protocol (RSVP) to communicate directly with the CMTS to set up QoS. This type of client is commonly referred to as Pull model.

Currently, only client type 1 devices have been fully defined in the PCMM specifications. Consequently, they are the focus of this chapter.

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

As you can see, several of the commands are the same as in PacketCable 1.x. The Gate Set message is used to initialize and modify gates as well as to control and update the state of a gate on the CMTS. The Gate Info message is used to query gate status, and the Gate Delete message is used to delete specific gates and their associated DOCSIS service flows. In PCMM, DOCSIS service flows and their associated gates on the CMTS are deleted via the receipt of a Gate Delete message from the PS. This is different from PC 1.x, where service flows and gates are usually deleted based on DOCSIS signaling from the MTA, and the Gate Delete message is used only under error conditions.

Notice that the Gate Allocation messages have been removed, as well as the Gate Open and Gate Close messages. Remember, the Gate Open and Gate Close messages were used by the CMTS to notify the CMS when a gate was committed or deleted. In PCMM, this functionality is rolled into the Gate Report State message, which notifies the PDP of gate changes that are not the result of a Gate Set message. One example: If a type 2 or 3 multimedia client commits its resources, the CMTS sends out a Gate Report State message to the policy server. Another example when this message would be sent is the expiration of a timer. Another use of the Gate Report State message is for notification of a gate reaching its traffic volume limit.

The PDP-Config message can be used when the COPS connection is first established. If the PDP is an Application Manager, this message contains the AMID(s) that are used by the PDP, and if the PDP is a Policy Server, this message contains the PSID(s) that are used by the PDP. This information allows a PEP to associate gate states for a PDP when the previous COPS connection is lost.

A PDP can request synchronization between its gate database and a PEP gate database by sending a Synch-Request message. Parameters such as the AMID, PSID, and Subscriber Identifier are specified in the Synch-Request as filtering criteria indicating which gate’s information should be returned. A Synch-Report message is returned to the PDP for each gate matching the criteria. As you might imagine, the response to a synchronization request can consist of many responses; the PEP indicates it has finished sending responses by sending a Sync-Complete message. You find two types of synchronization requests: full and incremental. If it receives a full synchronization request, the PEP returns information for all active gates matching the filtering criteria. An incremental request returns only the information for gates whose state has recently changed. This is used in situations where the COPS connection was recently lost. When it receives an incremental synchronization request, the PEP returns information for all gates with an outstanding unconfirmed Gate-Report-State message.

The Msg-Receipt message is used by the PDP to tell the PEP that it has successfully received a message that the PEP indicated required acknowledgement. The PEP indicates it requires an acknowledgement by including the Message Receipt Key object in the message it sends to the PDP.

Application Manager Identifier (AMID)

This 4-byte identifier is defined on the Application Manager and is unique within a service provider. Because a single AM can be used in multiple service provider networks, the AM would have an AMID for each service provider. The AMID consists of a 2-byte Application Manager Tag followed by a 2-byte Application Type. Logically, the tag identifies the AM, and the type identifies the type of application for which the gate is used. The Application Type values used are up to the service provider; the only exception is the value zero, which is reserved to indicate no defined application association. The policy server uses the AMID to associate Gate messages received from the CMTS with a particular AM and application type.

Subscriber Identifier

The IP address representing the subscriber could be the IP address of the client CPE device or of the cable modem. If private addresses are used on the client CPE device and NAT is performed, the CM address is used instead of the CPE address. This parameter associates QoS information with a particular subscriber to help prevent denial-of-service attacks.

Gate Identifier

The 4-byte gate identifier is assigned by the CMTS; remember, in PCMM this refers a single unidirectional gate.

Gate Specification

The PCMM gate specification is quite different than the one used in telephony. The parameters related to packet classification and traffic characteristics have been removed and put into other objects, namely the classifier and traffic profile objects. The gate specification object format is shown in Figure 14-4.

Figure 14-4

PCMM Gate Specification Format

The Session Class field identifies the relative priority of the gate. Higher priority gates could preempt lesser priority gates if resources were congested, much like how emergency 911 calls can receive preferential treatment over ordinary phone calls in PacketCable telephony. The authorized, reserved, and committed timers work the same way as the T1, T7, and T8 timers in PacketCable telephony. The committed recovery timer is the amount of time a gate can remain in the inactive state after the AM or PS is notified.

Classifier/Extended Classifier

One or more classifiers identify the packets that utilize the gate. Two types of classifiers are currently defined in the PCMM specification, the standard classifier and the extended classifier. Figure 14-5 depicts the format of the standard classifier object.

Figure 14-5

PCMM Standard Classifier Format

As you can see, the standard classifier field consists of the following parameters: IP protocol, source and destination IP addresses, source and destination port numbers, DSCP/TOS field and mask, and priority. If one of these parameters is set to zero, it is considered wildcarded, where all values match. The priority parameter establishes order in applying multiple classifiers. If multiple standard classifiers are used for the same gate, they must all be included in the Gate Set message. If the classifiers associated with a gate need to be modified, a new Gate Set message is required; the classifiers in this new message overwrite any existing classifiers.

Unlike standard classifiers, extended classifiers have operation actions associated with them so individual classifiers can be added, deleted, activated, and inactivated. Extended classifiers also allow for ranges of IP addresses and port numbers to be specified. The use of extended classifiers over standard classifiers is preferred. Figure 14-6 illustrates the format of the Extended Classifier object.

Figure 14-6

PCMM Extended Classifier Format

If the Activation State field is equal to 0 (Inactive), the classifier must not be used to map traffic, and if it is equal to 1 (Active), it must be used. The Action field has the following possible values: 0 (Add), 1 (Replace), 2 (Delete), and 3 (No change).

Traffic Profile

The traffic characteristics of a gate can be defined in one of three ways in PCMM: by an RSVP flow specification (S-Type = 1), by a DOCSIS service class name (S-Type = 2), or by DOCSIS specific parameterization (S-Type = 3).

The RSVP flow specification method is similar to the method used in PacketCable telephony. The second method is simply a named DOCSIS service class. The traffic profile parameters are defined on the CMTS under the same service class name. One key difference exists here compared to how service class names are used in DOCSIS. In DOCSIS, additional parameters can be defined with the service class name overriding the parameters defined on the CMTS. This is not permitted in PCMM. The third method is where the traffic profile is defined directly by DOCSIS Tag/Length/Value (TLV) parameters.

In most situations, any one of these methods can be used. An exception is if you want to use the UGS-AD or nRTPS DOCSIS service scheduling types. These cannot be created using RSVP flow specs; therefore, you must use either the named service flow or DOCSIS TLV method. As you can see, using the RSVP flow spec method has some inherent limitations in its ability to map to DOCSIS parameters. The other two methods do not have these limitations because they are also specified using DOCSIS parameters.

A benefit of using the service class name method is that QoS information is logged in to the ServiceFlowLogTable in the QoS Management Information Base (MIB). This occurs only when the named service class method is used. The service class name method is also useful in situations where a particular service might vary slightly from location to location. For example, if a “boost” service in one market uses a maximum downstream rate of 5 Mbps and a “boost” service in another market uses a maximum downstream rate of 4 Mbps, a named service class called “boost” can exist on the CMTS devices in each market with the appropriate definition. This way, the PCMM devices do not need to be configured for these market differences. Also service class names can be used for the communication between the AM and PS, so the AM doesn’t need to know the specific details on how to create QoS resource envelopes.

Up to three resource envelopes can be defined in the traffic profile object: one for authorized resources, one for reserved resources, and one for committed resources. A bit field, called the Envelope field, indicates which resource envelopes are included–the LSB is for authorized resources, the next bit is for reserved resources, and the next bit is for committed resources. Of course, if resources are to be activated immediately, then all three of these resource envelopes would be included and the same.

The presence of a reserved resource envelope causes the CMTS to initiate DOCSIS DSX messaging to place these resources in the admitted state. The presence of a committed resource envelope causes the CMTS to initiate DOCSIS DSX messaging to place these resources in the active state.

A limitation with the service class name method is that the same name must be used for all three resource envelopes. Therefore, this method can be used only when all three envelopes share a common set of parameters.

Remember from Chapter 12 that two types of services are defined by RSVP flows specs: controlled load and guaranteed. The guaranteed service is for applications that are delay sensitive and is defined by a traffic spec (TSpec) and resource spec (RSpec), and the controlled load service is for applications that require some amount of bandwidth but are not delay sensitive and are defined by only a TSpec. Chapter 12 defined the TSpec and RSpec parameters. PacketCable telephony is defined using the guaranteed service. Streaming video and interactive gaming are also sensitive to delay and would also be defined as a guaranteed service. An example of an application using a controlled load service is a web-based bandwidth on demand service.

If your AM defines a guaranteed service using RSVP flow specs, this gets converted to either a UGS or RTPS DOCSIS service flow. A controlled load service gets converted to a BE DOCSIS service flow.

---

Note – Whether or not a UGS or RTPS service flow results depends on whether the Reserved Rate (R) and Bucket Rate (r) parameters are equal. If they are, that means the bandwidth rate is constant; hence, a UGS flow results. Otherwise, an RTPS flow results. For more details on how RSVP flow specifications are mapped into DOCSIS parameters, please refer to section 9 of the PacketCable Multimedia specification.

---

Event-Generation-Info

This object works the same as in telephony (see Chapter 12) and passes along RKS information to the CMTS or policy server. This includes primary and secondary RKS server IP addresses and port number, as well as a billing correlation identifier.

Volume-Based Usage Limit

This object specifies the maximum amount of data in kilobytes that can traverse a gate. Bytes are counted from after the DOCSIS MAC header HCS to the end of the CRC—that is, the “Ethernet” portion of the DOCSIS header counts, but the DOCSIS header and extended headers do not.

---

Note – The CMTS is not responsible for enforcing this limit, but it does send a message to the PS/AM when this limit is reached.

---

Time-Based Usage Limit

This object specifies the maximum amount of time gate resources can remain committed. It is in units of seconds.

---

Note – The CMTS is not responsible for enforcing this limit, however.

---

Opaque Data

This object contains arbitrary data the PS or AM wants to associate to a gate. The CMTS stores this information but does nothing else with it.

Gate Time Info

This object contains the total amount of time (in seconds) the gate was committed. This information can be queried by the PS and/or AM.

Gate Usage Info

This object contains an octet counter representing the number of kilobytes that have traversed the gate. Again, bytes are counted from the DOCSIS header HCS to the end of the CRC. This information can be queried by the PS and/or AM.

PacketCable Error

This object consists of a 2-byte error code and a 2-byte error subcode. Currently defined error codes are shown in Table 14-3.

Table 14-3 Error Codes

The error subcode conveys further information about the error. For example, for error codes 6, 7, and 17 this field contains the S-Num and S-Type values of the object missing or invalid.

Gate State

This object conveys the current state of the gate and consists of a 2-byte state field and a 2-byte reason field. This parameter is sent in a Gate Report State message. The values of the state field are 1 (Idle/Closed), 2 (Authorized), 3 (Reserved), 4 (Committed), and 5 (Committed Recovery). Logically, the reason field contains the reason the gate is in this state and has the values shown in Table 14-4.

Table 14-4 Reason Codes

Version Info

This object contains the major and minor version numbers of PacketCable multimedia the application is using. Both fields are 2-byte integers. The current specification has a major version number of 2 and a minor version number of 0.

PSID

This object is a 4-byte integer that uniquely identifies the Policy Server.

Synch Options

A PDP can ensure its database is synchronized with a PEP by issuing a synchronization request to it. This object consists of a 1-byte Report Type followed by a 1-byte Synch Type. The Report Type can be either 0, telling the PEP to return standard report data, or 1, telling the PEP to return complete gate data. The Synch Type can be 0, indicating full synchronization, or 1, indicating incremental synchronization.

Msg Receipt Key

This object is a 32-bit integer assigned by the PEP. When it is included in a message, it tells the PDP to confirm receipt of the message.

PCMM Message Flow Template

Okay, now that you know the basics of PCMM, it’s time to look at an example of what the messaging might look like in a PCMM session. For the purposes of this discussion a PCMM session starts when a subscriber initiates an application requiring QoS and finishes when the subscriber’s application is finished. For example, in PacketCable telephony a multimedia session equates to a phone call.

For this example it is assumed that the multimedia application is not PacketCable QoS-aware, so you know this means the multimedia client is a legacy type 1 device. Again, examples of these client types include applications running on a personal computer such as streaming audio and video, gaming consoles, and IP phones. This client device would be connected to a cable modem via the modem’s LAN interface (Ethernet, USB, wireless, and so on). Figure 14-7 depicts what this messaging might look like, and the list that follows details the nine steps depicted in this message flow.

Figure 14-7

PCMM Session Message Flow Example

1. In Step 1 the client (either directly or via an application server) and the AM exchange messaging, which indicates the request to create a new session. Remember, this signaling is out of the scope of PCMM, but some possible protocols include MGCP and SIP. These protocols can be used to create audio and/or video multimedia connections on the multimedia client. Another possible application is HTML, where the client simply opens a web browser to the server, requesting some kind of QoS on-demand service.

2. At some point the AM figures out what the required QoS parameters are and signals a policy server for their creation. This is done by sending a Gate Set message, which identifies the subscriber and contains the classifier, gate specification, and traffic profile parameters needed to achieve the desired QoS.

3. When the PS receives the Gate Set, it checks to see whether that AM is authorized to make such a request. It does this by applying predefined policies. 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 initiates a Gate Set to the CMTS where the subscriber’s cable modem is connected. So as you can see, the AM doesn’t need to know which CMTS the subscriber’s modem is attached to; the PS figures this out instead. This is an enhancement to PacketCable telephony where the CMTS must be defined on the CMS (aggregation table on the BTS).

4. Similarly, the CMTS checks to see whether that PS is authorized and, if so, checks to see whether the requested resources can be granted. If all of this is true, the CMTS then creates a gate, assigns a gate identifier, and converts the COPS parameters to DOCSIS parameters. If a reserved resource envelope is included, the CMTS signals the service flow creation to the cable modem concerning the admission of these resources. If a committed resource envelope is included, the CMTS signals the service flow creation/modification to the cable modem concerning the activation of these resources.

   The creation and modification of DOCSIS resources is done using the DOCSIS dynamic service flow messages. So, the three-way handshake of a DSA-REQ, DSA-RSP, and DSA-ACK is used to create a DOCSIS service flow, and the three-way handshake of a DSC-REQ, DSC-RSP, and DSC-ACK is used to modify a DOCSIS service flow. In this case, the gates and service flows are created, reserved, and committed all in the same step. This is because of the initial Gate Set message sent from the AM containing all three resource envelopes; alternatively, the AM could have done this in multiple steps using multiple Gate Set messages.

   If the service flow and gate creation process are successful, the CMTS notifies the PS of this in the Gate Set Acknowledgement message. If this process is unsuccessful, a Gate Set Error message indicating the reason for failure is returned instead. The PS then relays this message to the AM.

5. At this point, the multimedia session’s QoS resources are active, so the AM relays this information back to the client device. Again, the signaling used to accomplish this is out of the scope of PCMM.

   Note that it is entirely possible no coordination exists between the application signaling and the QoS setup. Therefore, the client could have started sending data traffic before QoS was available; in this case, the traffic would have traversed the default BE service flows before the QoS was committed.

6. When the client is finished with the multimedia session, the client device signals this information to the AM.

7. The AM then requests the deletion of QoS resources by sending a Gate Delete message to the PS.

8. The PS in turn forwards this information to the appropriate CMTS in a Gate Delete message.

9. The CMTS receives this message and immediately requests deletion of the DOCSIS service flows by sending a DSD-REQ to the CM. The CM acknowledges the deletion of the service flow(s) by sending a DSD-RSP back to the CMTS.

---

Note – If the CMTS receives a DSD-REQ from the CM before this point, the service flows are deleted, but the gate still remains active until the PS/AM signals for gate deletion.

---

Now that the CMTS knows the service flows are successfully deleted, it deletes the gate and sends a Gate Delete Acknowledgement to the PS confirming this. If there was a problem in the gate deletion, a Gate Delete Error message is sent instead.

Finally, the PS forwards this message back to the AM.

PCMM Message Flow Example

The previous call flow template is a fairly good indication of what a PCMM session might look like. This section shows a real-world example of the life of a PCMM session. In this case, the application is a bandwidth-on-demand or Speed Preview service where a subscriber is temporarily given an increase in QoS for their high-speed data (HSD) service. The subscriber activates the Speed Preview service via a web page managed by the service provider. Traces of messages are examined to help you gain a greater understanding of how PCMM works. These message traces can also help you see how PCMM differs from PacketCable 1.x. Figure 14-8 illustrates the messaging used for the creation of the PCMM session, and the list that follows describes each step of the message flow.

Figure 14-8

PCMM Session Message Flow Example Part I

1. As soon as the AM receives the HTTP request, it verifies that this particular subscriber is authorized for the service and determines what the required QoS parameters are for the Speed Preview service. In this case, the service corresponds to the creation of an upstream gate as well as a downstream gate. First, the AM signals the policy server for the creation of the upstream gate using a Gate Set message. Figure 14-10 shows this message.

   Figure 14-10

   Gate Set (Upstream)

   Notice that this message is sent to port 3918 on the policy server, and the COPS client type indicates PacketCable Multimedia. The PacketCable Multimedia parameters are contained with COPS Client Specific Decision Data objects. The first parameter is the Transaction ID, which identifies this message as a Gate Set. This parameter is followed by the Application Manager ID referencing the AM and application type and the subscriber ID referencing the user of the PCMM session. The next parameter is the Gate Specification. The Flags subparameter identifies this gate as for the upstream direction (remember, if the least significant bit in this field is set, this indicates an upstream gate). The session class parameter indicates the gate is of the lowest priority. All the timer values are set to 0, meaning these timers never expire. As you’ll soon see, all resources for this gate are immediately activated; therefore, timers T1 and T2 do not apply. Recall from the previous step that one of the parameters used when creating the gate was duration. This multimedia session is designed to be set up for this time period, regardless of whether the subscriber actually uses it; therefore, timer T3 is also set to 0. Because timer T3 isn’t used, timer T4 isn’t needed either, so it is also set to 0. The traffic profile type used in this case is the DOCSIS parameters for an upstream Best Effort Service. Figure 14-11 shows the details of this parameter.

   Figure 14-11

   Traffic Profile Gate Set (Upstream)

   The envelope parameter is equal to 7, meaning authorized, reserved, and committed resource envelopes are all included. As you can tell, the parameters of all three of these resource envelopes are identical. This tells the PS and, ultimately, the CMTS that DOCSIS resources are to be immediately admitted and activated. After the traffic profile parameter is the classifier parameter. In this case, a standard classifier is used that simply states to match all traffic with a source IP address matching the subscriber (that is, CPE) IP address. The last parameter is the opaque data parameter, which specifies arbitrary data the AM wants to be associated with the gate.

2. When the PS receives the Gate Set, it checks to see whether that AM is authorized to make such a request. It then applies any predefined policies, such as making sure the creation of this gate does not violate any limits identified for this subscriber. The PS also does a lookup for this subscriber IP to determine what CMTS the subscriber is connected to. After it has this information, the PS sends a Gate Set message to the CMTS. In this case, this message is nearly identical to the Gate Set message sent from the AM. Remember, though, that this is not necessarily always the case.

3. Upon receiving the Gate Set message, the CMTS checks to see whether the requested resources can be granted. In this case this check is successful. Because the requested resources are to be immediately reserved and activated, the CMTS initiates the DSA message exchange to the cable modem where the subscriber is located. Figure 14-12 shows the DSA-REQ message.

   Figure 14-12

   DSA-REQ (Upstream)

4. The CMTS then lets the PS know the service flow and gate creation was successful by sending a Gate Set Acknowledgement message, as shown in Figure 14-13.

   Figure 14-13

   Gate-Set Ack (Upstream)

   As you can see, this message indicates the policy was successfully installed on the CMTS, and the gate identifier for the upstream QoS is returned in the Gate Set Ack message. This is so the AM and PS can refer to this gate in future messages. Upon receiving this message, the PS sends a Gate Set Ack of its own to the AM.

5. The AM then starts a similar process for the creation of downstream QoS resources for the client. Figure 14-14 shows the resulting Gate Set message.

   Figure 14-14

   Gate Set (Downstream)

   As you can see, in this case the Flags field indicates this is a Downstream Gate. The traffic profile in this case is a DOCSIS-based definition for a Downstream Service Flow. Figure 14-15 shows the details of this parameter.

   Figure 14-15

   Traffic Profile, Gate Set (Downstream)

   As was the case with the upstream traffic profile definition, identical authorized, reserved, and committed resource envelopes are included. A standard classifier is set up to match all packets destined for the subscriber’s IP address.

6. Upon receiving this message, the PS performs any predefined policy checks and, if successful, generates a Gate Set message to the CMTS for the creation of the downstream gate. In this case, this message is nearly identical to the Gate Set message in the previous step.

7. As it did with the upstream request, the CMTS authorizes the required downstream resources, and then admits and activates the corresponding DOCSIS resources. Figure 14-16 shows the resulting DSA-REQ sent to the cable modem.

   Figure 14-16

   DSA-REQ (Downstream)

   As expected, the QoS parameter set specifies that the resources are admitted and activated and the classifier state is activated. Also a service flow ID and classifier ID are assigned to this QoS. The modem then sends a DSA-RSP message indicating this request is successful, and the CMTS responds to this message with a DSA-ACK. Knowing that the Gate Set was successful, the CMTS sends a Gate Set Acknowledge message to the PS containing the gate identifier. The PS in turn forwards this information to the AM.

8. The multimedia session is now active, and the subscriber is enjoying the use of the enhanced QoS resources. However, eventually the duration time allocated to the subscriber expires, and the multimedia session must be deleted. Figure 14-17 illustrates the messaging used to accomplish this.

   Figure 14-17

   PCMM Session Message Flow Example, Part II

9. The first thing the AM does is request the PS for the current status of the upstream gate by sending a Gate Info message as shown in Figure 14-18.

   Figure 14-18

   Gate Info (Upstream)

   Notice the Gate ID is the value returned by the CMTS in the Gate Set Acknowledge message at the end of Step 3.

10. To retrieve all the gate information for the AM, the PS needs to issue a Gate Info message of its own to the CMTS. This parameter looks nearly identical to the previous Gate Info message.

    The CMTS then collects all the required information and returns it to the PS in a Gate Info Ack message, as shown in Figure 14-19.

    Figure 14-19

    Gate Info Ack (Upstream)

    As you can see, all the parameters from the Gate Set used for the creation of this gate, as well as some additional parameters, are included in this message. The Gate State parameter indicates the gate is currently committed. The Gate Time Info message indicates the gate has been committed for 59 seconds (remember, the application was initially set up for a duration of 1 minute). The Gate Usage Info message indicates no traffic has used this gate. Upon receiving this information, the PS creates a similar message and sends it to the AM.

11. At this point, the AM knows the time for the upstream gate has expired, so the AM requests the deletion of the upstream QoS resources by sending a Gate Delete message to the PS. Figure 14-20 shows this message.

    Figure 14-20

    Gate Info Ack (Upstream)

12. The PS then in turn passes this information to the CMTS in a Gate Delete message.

13. The CMTS receives this message and immediately requests deletion of the upstream DOCSIS service flow by sending a DSD-REQ to the CM. Figure 14-21 shows this message.

    Figure 14-21

    DSD-REQ (Upstream)

    Because you have only a single service flow to delete in this request, the Service Flow ID is put in that field instead of in the TLV data. Recall that with PacketCable 1.x, both the upstream and the downstream service flows are deleted with the same message; therefore, the service flow IDs are put in the TLV data. The CM acknowledges the deletion of the service flow by sending a DSD-RSP back to the CMTS.

    Now that the CMTS knows the service flow is successfully deleted, it deletes the gate and sends a Gate Delete Acknowledgement to the PS confirming this. The PS then forwards this message back to the AM.

15. A similar process then occurs for the downstream multimedia gate. First, the AM queries the PS for gate information by sending a Gate Info message.

16. To get this information the PS initiates a Gate Info message of its own to the CMTS. The CMTS honors this request by putting all the downstream gate information in a Gate Info Ack message and sends this to the PS. Among the information in this message are the Gate Time Info and Gate Usage Info fields, indicating how long the gate has been committed and the amount of traffic that has traversed it. After receiving this information, the PS sends the data to the AM in a Gate Info Ack message.

17. Knowing that the time setup for the gate has expired, the AM sends a Gate Delete message to the PS requesting the removal of this gate.

18. The PS then services this request by sending a Gate Delete message to the CMTS.

19. This triggers the CMTS to send a DSD-REQ message to the cable modem concerning the deletion of the downstream service flow. The cable modem responds to this message with a DSD-RSP message, indicating the service flow has been deleted. This triggers a Gate Delete Ack message to be sent to the PS, which in turn triggers a Gate Delete Ack message to be sent to the AM.

Event Messaging

As you know, tracking QoS resources is a vital element of PacketCable and just like with PacketCable, telephony event messaging to a Record Keeping Server (RKS) is used with PCMM. PacketCable event messaging uses the Accounting-Request and Accounting-Response messages defined in the IETF RADIUS protocol. In PCMM, both the CMTS and the Policy Servers send event messages to the RKS. The main differences between event messaging in PCMM and event messaging in PacketCable telephony are that the messages have been generalized and specifics to telephony have been classified as optional.

As you’ll learn in Chapter 15, “Lawful Intercept,” PacketCable telephony uses 14 event messages. Most of these are optional in PCMM, with only QoS Reserve, QoS Commit, QoS Release, and Time Change being mandatory. The first three messages are generated by the CMTS, and the Time Change message can be sent by either a CMTS or PS. Also three new messages have been added for use by policy servers: Policy Request, Policy Delete, and Policy Update.

Logically, the PS sends a Policy Request message whenever a new policy is created. This is whenever it receives the CMTS response to a Gate Set message. The PS sends a Policy Delete when it learns of a policy deletion; that is, a Gate Delete from the AM, a Gate Delete Acknowledge from the CMTS, or a Gate Report State from the CMTS indicating the release of QoS resources. The Policy Update message is sent when the AM modifies gate policy parameters such as traffic profile or classifiers.

Security

Just like with PacketCable telephony, PacketCable Multimedia also defines security between components. In Chapter 16, “PacketCable Network Design Considerations,” you’ll learn all about the security mechanisms used in PacketCable telephony, and many of these same protocols and concepts apply to PCMM. Therefore, only a very high-level description of these mechanisms is mentioned here.

The following interfaces should all be protected using the IPsec Encapsulation Security Payload (ESP) protocol:

• PS-CMTS

• AM-PS

• CMTS-RKS

• PS-RKS

All of these interfaces must support the Internet Key Exchange (IKE) key management protocol utilizing preshared keys. Optionally, IKE with certificates and Kerberized IPsec can be implemented.

PCMM Configuration on a Cisco CMTS

By now you should have a good understanding about how PCMM works. The next part of this chapter covers related provisioning steps on a Cisco CMTS. Chapter 13, “Analyzing, Implementing, and Troubleshooting DQoS,” covered the process of configuring PacketCable telephony on Cisco CMTSs in detail. You’ll see that many of the commands used in PCMM are similar.

The most basic step, and the only essential one, is to enable PacketCable Multimedia operation on the CMTS:

Router(config)#packetcable multimedia

Without this command, the CMTS does not respond to or generate PCMM COPS commands, and PacketCable multimedia operation does not exist. As soon as this command is entered, the CMTS attempts to establish a COPS connection on the TCP connection created by the PCMM policy server.

To specify PCMM timer values (optional), use the following command:

Router(config)#packetcable timer multimedia T1 timer-value

Timer T1 is defined in milliseconds, and you might recall it is the amount of time resources can remain in the authorized state. This timer is typically set by the PS in the GATE-SET message. The value specified here is used only if this parameter is not specified (that is, set to 0) by the PS. If unspecified on the CMTS, the default value of 200 seconds is assumed.

Recall that one of the ways to define traffic profiles is by using DOCSIS service class names. When a device (such as a PS or CMTS) receives a request containing a service class name, it looks up the name in its configuration database to resolve it into the specific DOCSIS service flow parameters. Consequently, this name and its mapping must exist on the device receiving the request (PS or CMTS). On a Cisco CMTS, service class names are configured in global configuration mode using the cable service class command. Configuration for the Speed Preview service flows used in the call flow example is as follows:

cable service class 100 name SpeedPreview_US
cable service class 100 upstream
cable service class 100 max-rate 2300000
cable service class 100 min-packet-size 64
cable service class 100 admission-timeout 0
cable service class 100 activity-timeout 0
cable service class 101 name SpeedPreview_DS
cable service class 101 downstream
cable service class 101 max-rate 17500000
cable service class 101 min-packet-size 64

You can determine the values of these service classes with the show cable service-class ID verbose command as demonstrated here:

C0103-7246VXR#show cable service-class 100 verbose
Index:                                  100
Name:                                   SpeedPreview_US
Direction:                              Upstream
Traffic Priority:                       0
Maximum Sustained Rate:                 2300000 bits/sec
Max Burst:                              3044 bytes
Minimum Reserved Rate:                  0 bits/sec
Minimum Packet Size                     64 bytes
Admitted QoS Timeout                    0 seconds
Active QoS Timeout                      0 seconds
Maximum Concatenated Burst:             1522 bytes
Scheduling Type:                        Best Effort
Request/Transmission Policy:            0x0
IP ToS Overwrite [AND-mask,OR-mask]:    0xFF,0x0
Parameter Presence Bitfield:            {0xE48, 0x0}
C0103-7246VXR#sh cable service-class 101 v
Index:                                  101
Name:                                   SpeedPreview_DS
Direction:                              Downstream
Traffic Priority:                       0
Maximum Sustained Rate:                 17500000 bits/sec
Max Burst:                              3044 bytes
Minimum Reserved Rate:                  0 bits/sec
Minimum Packet Size                     64 bytes
Admitted QoS Timeout                    200 seconds
Active QoS Timeout                      0 seconds
Scheduling Type:                        Undefined
Max Latency:                            0 usecs
Parameter Presence Bitfield:            {0x248, 0x0}

Verifying and Troubleshooting PCMM on a Cisco CMTS

The commands used to verify and troubleshoot PCMM on a Cisco CMTS for the most part are the exact same commands used to verify and troubleshoot PacketCable telephony. These commands were covered in detail in Chapter 13, so please refer to that chapter for more information.

• Use the show cops servers command to see that the COPS connection to the PS is established (the client type should be 32778).

• If the COPS connection is not there, you can check to see whether the PS has opened the TCP connection (to port 3918 on the CMTS) using the show tcp brief command.

• The show packetcable global command tells you whether PCMM is enabled and the value of timer T1.

• The show packetcable gate command shows you information on PCMM gates, just as it did with PC 1.x gates. The multimedia keyword can be used to just show PCMM gates if you have both types on the CMTS. The following is some sample output of PCMM gates:

  C0103-7246VXR#show packetcable gate multimedia summary 
  GateID    i/f     SubscriberID   GC-Addr        State     Type  SFID(us) SFID(ds)
  37938     Ca5/0   24.34.240.247  172.18.98.62   COMMIT    MM             222      
  54322     Ca5/0   24.34.240.247  172.18.98.62   COMMIT    MM    221      
  Total number of Multimedia gates = 2
  Total Gates committed(since bootup or clear counter) = 92
  

  C0103-7246VXR#show packetcable gate 54322 <- Detailed information for Upstream PCMM gate

  GateID                 : 54322
      Subscriber ID      : 24.34.240.247
      COPS server handle : 0x644754F8
      State              : COMMIT
        Upstream
        classifier       :
          protocol       : 0
          priority       : 64
          src addr/port  : 24.34.240.247/0
          dest addr/port : 0.0.0.0/0
          dscp-tos/mask  : 0x0 0x0
        gate spec        : flags 0x1
        dscp-tos/mask    : 0x0 0x0
        timer t1(s)      : 200 
        timer t2(s)      : 0 
        timer t3(s)      : 0 
        timer t4(s)      : 0 
        session class    : 0x0
        Traffic Profile  : Best Effort.
    
  

  Authorized : <- Below is the Authorized Resource Envelope

  Traffic Priority 0x0
  Req Transmission Policy 0x0
        Max Sustain Rate 2300000
            Max Burst        3044
        Min Rate         0
        Min pkt size     64
     
  

  Reserved : <- Below is the Reserved Resource Envelope

  Traffic Priority 0x0
  Req Transmission Policy 0x0
        Max Sustain Rate 2300000
            Max Burst        3044
        Min Rate         0
        Min pkt size     64
     
  

  Committed : <- Below is the Committed Resource Envelope

  Traffic Priority 0x0
  Req Transmission Policy 0x0
        Max Sustain Rate 2300000
            Max Burst        3044
        Min Rate         0
        Min pkt size     64
  

  C0103-7246VXR#show packetcable gate 37938 <- Detailed information for Downstream PCMM gate

  GateID                 : 37938
      Subscriber ID      : 24.34.240.247
      COPS server handle : 0x644754F8
      State              : COMMIT
        Downstream
        classifier       :
          protocol       : 0
          priority       : 64
          src addr/port  : 0.0.0.0/0
          dest addr/port : 24.34.240.247/0
          dscp-tos/mask  : 0x0 0x0
        gate spec        : flags 0x0
        dscp-tos/mask    : 0x0 0x0
        timer t1(s)      : 200 
        timer t2(s)      : 0 
        timer t3(s)      : 0 
        timer t4(s)      : 0 
        session class    : 0x0
        Traffic Profile  : Downstream.
     
  

  Authorized : <- Below is the Authorized Resource Envelope

        Traffic priority 0
        Max Sustain Rate 17500000
        Max Burst        3044
        Min Rate         0
        Min pkt size     64
        DS Latency       0
     
  

  Reserved : <- Below is the Reserved Resource Envelope

        Traffic priority 0
        Max Sustain Rate 17500000
        Max Burst        3044
        Min Rate         0
        Min pkt size     64
        DS Latency       0
     
  

  Committed : <- Below is the Committed Resource Envelope

        Traffic priority 0
        Max Sustain Rate 17500000
        Max Burst        3044
        Min Rate         0
        Min pkt size     64
        DS Latency       0
  

• The show packetcable gate counter multimedia command tells you the number of PCMM gates committed since the CMTS was last reset or the counter was cleared (this can be done with the command clear packetcable gate counter commit multimedia).

• DOCSIS Service Flows, Classifiers, and SIDs created as a result of PCMM can be seen using the same commands described in the last chapter.

• Use the show controller cable x/y downstream command to view statistics on DSX messages. For PCMM, you see hits on the Request and Acknowledgement counters for DSA and DSC messages because these always originate from the CMTS for PCMM client type 1 devices.

• The debugging of DOCSIS service flow creation as a result of PCMM can be seen with the same commands that are used for PC 1.x, as described in Chapter 13.

• Likewise, the debugging of COPS gate messaging for PCMM can be seen with the same commands that are used for PC 1.x DQoS. The following is an example of the debug packetcable gate control command output used with the debug packetcable subscriber sub IP verbose command:

  Aug 10 20:22:06.984: Pktcbl(mm): Received GATE SET message, tid=0x6DCE
  Aug 10 20:22:06.984: --- Pktcbl(mm): Received GCP message ------
  Aug 10 20:22:06.984: TRANSACTION ID       : Object.[snum/stype/len 1/1/8]
  Aug 10 20:22:06.984:     transaction id   : 0x6DCE
  Aug 10 20:22:06.984:     gcp cmd          : 4 (GATE SET)
  
  Aug 10 20:22:06.984: AM ID                : Object.[snum/stype/len 2/1/8]
  Aug 10 20:22:06.984:     AM ID            : 1
  Aug 10 20:22:06.984: SUBSCRIBER ID (IPV4) : Object.[snum/stype/len 3/1/8]
  Aug 10 20:22:06.984:     Addr             : 24.34.240.247
  Aug 10 20:22:06.984: GATE SPEC            : Object.[snum/stype/len 5/1/16]
  Aug 10 20:22:06.984:     flag             : 0x1
  Aug 10 20:22:06.984:     dscp             : 0x0
  Aug 10 20:22:06.984:     dscp tos mask    : 0x0
  Aug 10 20:22:06.984:     Timers  t1       : 0,  t2 : 0
  Aug 10 20:22:06.984:             t3       : 0,  t4 : 0
  
  Aug 10 20:22:06.984:     session class    : 0x0
  Aug 10 20:22:06.984: TRAFFIC PROFI
  C0103-7246VXR#LE      : Object.[snum/stype/len 7/3/80]
  Aug 10 20:22:06.984:     envelope         : 0x7
  Aug 10 20:22:06.984:     service number   : 0x0
  Aug 10 20:22:06.984:     Authorized :
  Aug 10 20:22:06.984: Traffic Priority   : 0
  Aug 10 20:22:06.984: Request Xmit Policy: 0x0
  Aug 10 20:22:06.984: Max Sustained Rate : 2300000
  Aug 10 20:22:06.984: Max Burst          : 3044
  
  Aug 10 20:22:06.984: Min Reserved Rate  : 0
  Aug 10 20:22:06.984: Min Pkt Size       : 64
  Aug 10 20:22:06.984:     Reserved   :
  Aug 10 20:22:06.984: Traffic Priority   : 0
  Aug 10 20:22:06.984: Request Xmit Policy: 0x0
  Aug 10 20:22:06.984: Max Sustained Rate : 2300000
  Aug 10 20:22:06.984: Max Burst          : 3044
  Aug 10 20:22:06.984: Min Reserved Rate  : 0
  Aug 10 20:22:06.984: Min Pkt Size       : 64
  Aug 10 20:22:06.984:     Committed  :
  
  Aug 10 20:22:06.984: Traffic Priority   : 0
  Aug 10 20:22:06.984: Request Xmit Policy: 0x0
  Aug 10 20:22:06.984: Max Sustained Rate : 2300000
  Aug 10 20:22:06.984: Max Burst          : 3044
  Aug 10 20:22:06.984: Min Reserved Rate  : 0
  Aug 10 20:22:06.984: Min Pkt Size       : 64
  Aug 10 20:22:06.984: CLASSIFIER           : Object.[snum/stype/len 6/1/24]
  Aug 10 20:22:06.984:     protocol         : 0x0
  Aug 10 20:22:06.984:     dscp             : 0x0
  Aug 10 20:22:06.984:     dscp tos mask    : 0x0
  Aug 10 20:22:06.984:     src/port         : 24.34.240.247 0
  Aug 10 20:22:06.984:     dest/port        : 0.0.0.0 0
  Aug 10 20:22:06.984:     priority         : 64
  Aug 10 20:22:06.984: OPAQUE               : Object.[snum/stype/len 11/1/12]
  Aug 10 20:22:06.984:     data             : [33 36 34 31 39 31 38 00 ]
  Aug 10 20:22:06.984: --------------------------------------
  Aug 10 20:22:06.984: Pktcbl(mm): Change profile 0 qos 0
  
  Aug 10 20:22:06.996: Pktcbl(mm): Building GCP message, added obj TRANSACTION ID      ; len:8 padding:0
  Aug 10 20:22:06.996: Pktcbl(mm): Building GCP message, added obj AM ID               ; len:8 padding:0
  Aug 10 20:22:06.996: Pktcbl(mm): Building GCP message, added obj SUBSCRIBER ID (IPV4); len:8 padding:0
  Aug 10 20:22:06.996: Pktcbl(mm): Building GCP message, added obj GATE ID             ; len:8 padding:0
  Aug 10 20:22:06.996: Pktcbl(mm): Building GCP message, added obj OPAQUE              ; len:12 padding:0
  Aug 10 20:22:06.996: Pktcbl(mm): Built GCP message, GATE SET ACK        , length: 44, copsLen 72
  Aug 10 20:22:06.996:  --- Pktcbl: Sending GCP message ------
  Aug 10 20:22:06.996: TRANSACTION ID       : Object.[snum/stype/len 1/1/8]
  Aug 10 20:22:06.996:     transaction id   : 0x6DCE
  Aug 10 20:22:06.996:     gcp cmd          : 5 (GATE SET ACK)
  
  Aug 10 20:22:06.996: AM ID                : Object.[snum/stype/len 2/1/8]
  Aug 10 20:22:06.996:     AM ID            : 1
  
  Aug 10 20:22:06.996: SUBSCRIBER ID (IPV4) : Object.[snum/stype/len 3/1/8]
  Aug 10 20:22:06.996:     Addr             : 24.34.240.247
  Aug 10 20:22:06.996: GATE ID              : Object.[snum/stype/len 4/1/8]
  Aug 10 20:22:06.996:     GateID           : 37942 (0x9436)
  Aug 10 20:22:06.996: OPAQUE               : Object.[snum/stype/len 11/1/12]
  Aug 10 20:22:06.996:     data             : [33 36 34 31 39 31 38 00 ]
  Aug 10 20:22:06.996:  --------------------------------------
  Aug 10 20:22:07.016: Pktcbl(mm): Received GATE SET message, tid=0x6DCF
  Aug 10 20:22:07.016: --- Pktcbl(mm): Received GCP message ------
  Aug 10 20:22:07.016: TRANSACTION ID       : Object.[snum/stype/len 1/1/8]
  
  Aug 10 20:22:07.016:     transaction id   : 0x6DCF
  Aug 10 20:22:07.016:     gcp cmd          : 4 (GATE SET)
  Aug 10 20:22:07.016: AM ID                : Object.[snum/stype/len 2/1/8]
  Aug 10 20:22:07.016:     AM ID            : 1
  Aug 10 20:22:07.016: SUBSCRIBER ID (IPV4) : Object.[snum/stype/len 3/1/8]
  Aug 10 20:22:07.016:     Addr             : 24.34.240.247
  Aug 10 20:22:07.016: GATE SPEC            : Object.[snum/stype/len 5/1/16]
  Aug 10 20:22:07.016:     flag             : 0x0
  Aug 10 20:22:07.016:     dscp             : 0x0
  Aug 10 20:22:07.016:     dscp tos mask    : 0x0
  
  Aug 10 20:22:07.016:     Timers  t1       : 0,  t2 : 0
  Aug 10 20:22:07.016:             t3       : 0,  t4 : 0
  Aug 10 20:22:07.016:     session class    : 0x0
  Aug 10 20:22:07.016: TRAFFIC PROFILE      : Object.[snum/stype/len 7/8/80]
  Aug 10 20:22:07.016:     envelope         : 0x7
  Aug 10 20:22:07.016:     service number   : 0x0
  Aug 10 20:22:07.016:     Authorized : 
  Aug 10 20:22:07.016: Traffic Priority   : 0
  
  Aug 10 20:22:07.016: Max Sustained Rate : 17500000
  Aug 10 20:22:07.016: Max Burst          : 3044
  Aug 10 20:22:07.016: Min Reserved Rate  : 0
  Aug 10 20:22:07.016: Min Pkt Size       : 64
  Aug 10 20:22:07.016: Max Latency        : 0
  Aug 10 20:22:07.016:     Reserved   :
  Aug 10 20:22:07.016: Traffic Priority   : 0
  Aug 10 20:22:07.016: Max Sustained Rate : 17500000
  Aug 10 20:22:07.016: Max Burst          : 3044
  Aug 10 20:22:07.016: Min Reserved Rate  : 0
  
  Aug 10 20:22:07.016: Min Pkt Size       : 64
  Aug 10 20:22:07.016: Max Latency        : 0
  Aug 10 20:22:07.016:     Committed  :
  Aug 10 20:22:07.016: Traffic Priority   : 0
  Aug 10 20:22:07.016: Max Sustained Rate : 17500000
  Aug 10 20:22:07.016: Max Burst          : 3044
  Aug 10 20:22:07.016: Min Reserved Rate  : 0
  Aug 10 20:22:07.016: Min Pkt Size       : 64
  Aug 10 20:22:07.016: Max Latency        : 0
  Aug 10 20:22:07.016: CLASSIFIER           : Object.[snum/stype/len 6/1/24]
  
  Aug 10 20:22:07.016:     protocol         : 0x0
  Aug 10 20:22:07.016:     dscp             : 0x0
  Aug 10 20:22:07.016:     dscp tos mask    : 0x0
  Aug 10 20:22:07.016:     src/port         : 0.0.0.0 0
  Aug 10 20:22:07.016:     dest/port        : 24.34.240.247 0
  Aug 10 20:22:07.016:     priority         : 64
  Aug 10 20:22:07.016: OPAQUE               : Object.[snum/stype/len 11/1/12]
  
  Aug 10 20:22:07.016:     data             : [33 36 34 31 39 31 38 00 ]
  Aug 10 20:22:07.016: --------------------------------------
  Aug 10 20:22:07.016: Pktcbl(mm): Change profile 0 qos 0
  Aug 10 20:22:07.040: Pktcbl(mm): Building GCP message, added obj TRANSACTION ID      ; len:8 padding:0
  Aug 10 20:22:07.040: Pktcbl(mm): Building GCP message, added obj AM ID               ; len:8 padding:0
  Aug 10 20:22:07.040: Pktcbl(mm): Building GCP message, added obj SUBSCRIBER ID (IPV4); len:8 padding:0
  Aug 10 20:22:07.040: Pktcbl(mm): Building GCP message, added obj GATE ID             ; len:8 padding:0
  Aug 10 20:22:07.040: Pktcbl(mm): Building GCP message, added obj OPAQUE              ; len:12 padding:0
  Aug 10 20:22:07.040: Pktcbl(mm): Built GCP message, GATE SET ACK        , length: 44, copsLen 72
  Aug 10 20:22:07.040:  --- Pktcbl: Sending GCP message ------
  
  Aug 10 20:22:07.040: TRANSACTION ID       : Object.[snum/stype/len 1/1/8]
  Aug 10 20:22:07.044:     transaction id   : 0x6DCF
  Aug 10 20:22:07.044:     gcp cmd          : 5 (GATE SET ACK)
  Aug 10 20:22:07.044: AM ID                : Object.[snum/stype/len 2/1/8]
  Aug 10 20:22:07.044:     AM ID            : 1
  Aug 10 20:22:07.044: SUBSCRIBER ID (IPV4) : Object.[snum/stype/len 3/1/8]
  Aug 10 20:22:07.044:     Addr             : 24.34.240.247
  Aug 10 20:22:07.044: GATE ID              : Object.[snum/stype/len 4/1/8]
  Aug 10 20:22:07.044:     GateID           : 54326 (0xD436)
  Aug 10 20:22:07.044: OPAQUE               : Object.[snum/stype/len 11/1/12]
  Aug 10 20:22:07.044:     data             : [33 36 34 31 39 31 38 00 ]
  Aug 10 20:22:07.044:  --------------------------------------
  

• Finally, many of the test commands covered in Chapter 13 can also be used to troubleshoot the COPS connectivity between the CMTS and PS.

Chapter Summary

The PacketCable Multimedia (PCMM) specifications provide a generalized framework for enabling DOCSIS QoS services for a wide range of multimedia applications. PCMM is unaware of the application specifics; hence, it does not specify application details such as signaling and provisioning. The possible range of PCMM applications includes real-time applications such as videoconferencing, interactive gaming, streaming media, and telephony, as well as non real-time applications such as web-based bandwidth on demand and Speed Preview.

There are seven components in the PCMM architecture: clients, Application Server (AS), Application Manager (AM), Policy Server (PS), CMTS, CM, and RKS. Three types of multimedia clients exist:

• Type 1 is referred to as “QoS-unaware” because it knows nothing about the PacketCable network it is using.

• Type 2 is referred to as “Push model” because it is QoS-aware but relies on other components such as the AM and PS to push QoS policies to the CMTS.

• Type 3 is referred to as “Pull model” because it is QoS-aware and able to trigger the CMTS to pull QoS policies from the PS.

Currently, only type 1 clients are fully defined in PCMM. The AS is an intermediary device that initiates multimedia sessions on behalf of clients. The Application Manager figures out the resources needed by a client and conveys this information to a Policy Server. The Policy Server applies rules to requests from the AM, such as checking CMTS usage and subscriber QoS restrictions. The CMTS, cable modem, and RKS event messaging server perform similar functions in PCMM that they do in PacketCable 1.x. However, significant differences in how these functions are performed do exist. For example, in PCMM dynamic DOCSIS service flow creation is initiated from the CMTS, unlike in PacketCable 1.x, where they are initiated from the embedded MTA.

COPS is used in two places in PCMM–between the AM and PS and between the PS and CMTS. Consequently, a PCMM network is split into service control domains (SCDs) and resource control domains (RCDs). An SCD is a logical grouping of elements that provide an application, and an RCD is the logical grouping of elements providing connecting to QoS resources.

Like PacketCable telephony, the DOCSIS network must be at least DOCSIS 1.1 capable in PCMM. However, the use of DOCSIS in PCMM varies from its previous use. In addition to the unsolicited grant services (UGS and UGS-AD), the polling services are also permitted (RTPS and nRTPS). The Real-Time Polling Service is used for jitter-sensitive applications that transmit variable-sized packets. The Non Real-Time Polling Service is used for applications that are sensitive to packet loss and require regular transmission opportunities but can tolerate packet jitter. Also through the manipulation of certain DOCSIS service flow parameters, the Best Effort scheduling type can also be used in PCMM to provide QoS.

The COPS messaging and parameters used in PCMM are significantly different than those in PacketCable telephony. The COPS protocol is still used for resource allocation and authorization, but in PCMM it is also used for resource reservation and commitment. Among the objects defined in COPS for PCMM are gate specifications, classifiers, and traffic profiles. PCMM gate specifications contain timer values as well as parameters such as gate priority and DSCP overwrite settings, and classifiers determine the type of packets permitted to use a PCMM gate. A traffic profile defines the QoS resources required for the application and can be defined by RSVP flow specifications, DOCSIS TLV parameters, or DOCSIS service class names. Traffic profiles can contain authorized resource envelopes, reserved resource envelopes, and committed resource envelopes. The presence of reserved and committed resource envelopes triggers DOCSIS messages to the cable modem connected to the PCMM subscriber. Also objects exist that can be used to track gate bandwidth use and the time in which PCMM gates are active. The use of event messaging for real-time billing and packet encryption for added security also exist in PCMM, just as they did in telephony.

PCMM configuration and troubleshooting commands on a Cisco CMTS are similar to the corresponding commands used for PacketCable telephony. Show commands exist, which output the current status and details of PCMM gates and their DOCSIS service flows. Debug commands exist, which output the COPS and DOCSIS messaging used to create QoS for PCMM sessions.

Chapter Review

1. True or False: The Application Manager doesn’t need to know the CMTS to which its clients are physically connected.

   Answer: True. It relies on the Policy Server to figure this out.

2. True or False: PCMM defines the protocol used between the AM and PS devices.

   Answer: True. The COPS protocol is used.

3. True or False: PCMM defines the protocol used between the AM or AS and the client devices.

   Answer: False. This is out of the scope of PCMM.

4. True or False: If a PCMM gate is set up using a DOCSIS service class name defined on the CMTS, certain QoS parameters can also be overwritten using DOCSIS TLV parameters.

   Answer: False

5. True or False: The way in which PCMM is configured, verified, and debugged on a Cisco CMTS is nearly identical to the way these things are done for PacketCable telephony.

   Answer: True

6. True or False: A PCMM gate identifier refers to the combination of an upstream gate and a downstream gate.

   Answer: False. In PCMM, gates are always unidirectional.

7. True or False: The types of event messages used in PCMM are different than those used in PC telephony.

   Answer: True. Messages specific to the telephony application have been removed and messages sent from the PS have been added.

8. True or False: The CMTS initiates the deletion of a gate that exceeds its configured volume usage limit or exceeds its time usage limit.

   Answer: False. The CMTS is not responsible for enforcing these limits.

9. True or False: If the CMTS receives a PCMM gate specification with a timer T1 value of 0, this means the resources remain authorized until torn down by the PS.

   Answer: False. This means the CMTS provisioned value is used.

10. What type of multimedia client uses RSVP to set up its QoS?

    Answer: Type 3

11. For each of the following possible PCMM applications, identify the DOCSIS scheduling type (UGS, UGS-AD, RTPS, nRTPS, or BE) that makes the most sense:

    1. Video telephony

    2. On-demand minimal bandwidth guaranteed service

    3. Standalone telephony MTA implementing VAD

    4. Interactive gaming

    Answer: a) RTPS, b) BE, c) UGS-AD, d) RTPS

12. When is a Policy Server a COPS PDP and when is it a COPS PEP?

    Answer: The PS is a Policy Decision Point for the resource control domain in its communication with the CMTS and a Policy Enforcement Point for the service control domain in its communication with the AM.

13. What is the purpose of the Gate Report State message?

    Answer: It is sent by the CMTS to alert the PS of a change in the resource status of a gate because of events like client messaging and timer expiry.

14. What is the TCP port used for PCMM, and why is it different than the one used for PC telephony?

    Answer: 3918. So both applications can simultaneously exist without interfering with each other.

15. What could a Deep Packet Inspection (DPI) device be used for in a PCMM network?

    Answer: To initiate PCMM session requests based on inspected packets (such as voice/video RTP streams)

16. Under what situation would an incremental synchronization request be sent by a PDP?

    Answer: To recover gate information after the COPS connection is lost

17. What is a reason for using extended classifiers over standard classifiers?

    Answer: So individual classifiers can be added, activated, or deleted without having to resend the entire list of classifiers, or they could be used to specify a range of IP addresses and port numbers.

18. Why can’t traffic profiles using RSVP flow specs be used to trigger the creation of UGS-AD and nRTPS service flows?

    Answer: Because of limitations in the ability to map flow spec parameters into DOCSIS parameters

19. What Cisco IOS command can be used to see the active list of PCMM gates?

    Answer: show packetcable gate multimedia summary

Copyright © 2007 Pearson Education. All rights reserved.