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![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![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.
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.
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![Figure 14-12]()
DSA-REQ (Upstream)
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![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.
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![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![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.
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.
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![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.
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![Figure 14-17]()
PCMM Session Message Flow Example, Part II
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![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.
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![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.
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![Figure 14-20]()
Gate Info Ack (Upstream)
The PS then in turn passes this information to the CMTS in a Gate Delete message.
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![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.
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.
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.
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.
The PS then services this request by sending a Gate Delete message to the CMTS.
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.