Chapter 14: Multimedia Applications

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