PCMM

By any measure, the PacketCable 1.x effort within the CableLabs working group has been an enormous success. With multiple products certified or qualified for every network element, and deployments in excess of 100,000 subscribers, both the architecture and the process have been validated. However, one shortcoming of the PacketCable 1.x architecture is that by being highly prescriptive in not just what the network elements are, but also in how the applications function, the ability of cable operators to innovate new services and take advantage of "off-the-shelf" products is limited. The challenge for operators is how to take advantage of recent innovation in addition to tried-and-true off-the-shelf products without reducing themselves to being a "big dumb pipe." PacketCable Multimedia (PCMM) addresses at least part of this problem. Fundamentally, PCMM currently is designed to provide quality of service (QoS) to nonQoS aware endpoints in a secure, authenticated and trusted way. Another important aspect of the PCMM architecture is that it leverages the large installed base of Data Over Cable Service Interface Specification (DOCSIS) 1.1 and 2.0 cable modems and cable modem termination systems (CMTSs). This allows new services to be deployed with minimal operational expense as the need for truck rolls to turn up a new service is reduced or even eliminated in most cases. Because the PCMM architecture is not prescriptive in how applications function, a large number of different applications have been demonstrated, and even more are planned. Let’s examine several of those applications, how they can be deployed and what issues face operators as they plan to move from the lab, to trial, to commercial deployment. Architecture introduction In order to understand the applications, a brief description of the overall architecture and the role that each network element plays is necessary. For more detailed information, refer to PacketCable Multimedia Specification (PKT-SP-MM-I01-030627) and PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH-V01-030627). For simplification purposes, some new concepts within the framework of the PCMM specification are introduced even though they are not pulled out explicitly in the specification. Cable modem: One of the primary requirements for PCMM is that it must run with any DOCSIS 1.1 certified customer premises equipment (CPE) device. This means that unlike PacketCable 1.x, where the CPE initiates the QoS requests, the cable modem must support DOCSIS DSx messages initiated from the CMTS. No change should be required in hardware or software for a DOCSIS 1.1 modem to be able to operate in a PCMM deployment. CMTS: Unlike the cable modem, the CMTS must implement new functionality in order to support PCMM. It must interface with an external entity to receive QoS requests for a particular application, and it must initiate the DOCSIS DSx messaging with the appropriate modem. It must also send new PCMM event messages to an external entity when QoS is initiated, changed or terminated. Policy server: The policy server is a new element in the PCMM architecture. In many ways it is similar to the gate controller in the PacketCable 1.x environment. The policy server interfaces with the application and makes policy decisions based on the application requirements and cable operator rule sets. It is responsible for requesting that the appropriate CMTS provide the QoS and must provide the necessary information for the CMTS to do so. The policy server usually is a stateful entity. It can maintain state on the outstanding QoS requests for an application and resources currently used on the CMTS. Application manager: The application manager is the entity that interfaces between the application and the policy server. The application manager uses a well-defined interface to communicate policy requests to the policy server. Application server: A new concept being introduced here is that of an application server. Unlike PacketCable, which ties the application layer into the QoS layer, PCMM keeps these entities separate. For simplification purposes, I define an application server as a network element that provides the application level functionality. This entity may in turn embed an application manager (similar to the PacketCable Model), use existing proprietary interfaces to communicate with an application manager or have no awareness that an external QoS infrastructure exists. For illustrative purposes we’ll now discuss four different applications and how they might utilize the PCMM architecture. Those applications are: SIP-based video phones One of the advantages that cable networks have over the plain old telephone service (POTS) network for video phones is that as an Internet protocol (IP)-based service, it has the ability to provide more functionality by using IP’s robust set of features, such as routabilty. While many attempts have been made to provide low cost personal video phone capability to residential customers, to date, none has been widely successful. Similar to voice, video telephony must demonstrate high quality, low latency and low loss of information on the bearer path. When done over IP, this means that both the video and the voice channels of the video call must have minimal packet loss, low latency and minimal jitter. A QoS reservation over the hybrid fiber/coax (HFC) access network is necessary to ensure these requirements are met. As with all the applications described in this article, the modem, CMTS and policy server need to reside in the network. In this particular application, SIP-based video phones need to be in place, and a signaling control layer needs to exist (either in the form of SIP proxies or a softswitch capable of supporting SIP endpoints). Finally, an interface with the public switched telephone network (PSTN) is necessary if the service is viewed as a superset of a residential telephony deployment. A pre-PCMM working video telephony architecture in an IP environment consists of SIP video phones, a SIP proxy, and media gateways with SIP interfaces. The main component missing for deployment in a PCMM environment is an interface between a SIP proxy and the application manager. In building this application, a number of alternatives were explored. For the purpose of this discussion, we’ll use the approach of an application manager embedded within the application server, a SIP proxy in this case. In this application, calls are set up as normal, with one notable exception. When the initial invite comes in, the proxy must communicate with its application manager "module," which then must send a common open policy service (COPS) request to the policy server. The policy server subsequently communicates with the CMTS to obtain the requested QoS. The CMTS, in turn, establishes the bandwidth to the modem. Upon completion of this process, each element is informed that the request was successful, and ultimately the call is allowed to be set up with QoS. There are a number of issues that need to be addressed in this model: Minimizing call setup time: Unfortunately, there is no "silver bullet" answer here. Addressing this problem requires a multifaceted approach. First, a robust architecture to address failover scenarios is required. The policy server and application manager must proactively detect that the entity that they are communicating with is no longer active, so that transmission timeouts are minimized or eliminated for this application. Beyond that, not much else can be done except to optimize the performance of each step of the transaction and enforce an allocated processing duration budget to each step. Maintaining call state: One of the reasons that an embedded application manager was chosen for this application is that it allows the application manager to interface directly with the call control layer. As part of the normal clean-up logic for an abnormal termination, the SIP proxy would communicate with the embedded application manager. The embedded application manager would then trigger QoS tear-downs with the policy server in the event that a single abnormal termination of a call is detected. One way that the abnormal termination would be detected is through a registration timeout of the endpoint involved in the call. Since SIP does not mandate how abnormal terminations are detected, individual proxy servers will implement their own solutions in this regard. Another scenario is a loss of call control, such as when a proxy server has a catastrophic failure. This is one reason that the timers are implanted on the CMTS. If the CMTS detects that no traffic has passed over a flow for a configurable measure of time, then the gate will be torn down by the CMTS, and the policy server is informed. The T1, T2 and T3 timers handle QoS reservations timeouts in the authorized, reserved and committed states, respectively. Scalability: There are two main concerns about scalability for the video phone application. First is the scalability of the call control plane, given that it must be call stateful in this application. The second is the scalability of the policy server. Fortunately, the issue of scaling a proxy server, even a call stateful proxy server, is a solved problem. There are real-world deployments of SIP applications supporting in excess of one hundred thousand endpoints. One reason for this is that the segmentation is easier. The SIP clients can be configured to register with a specific SIP proxy server, and routing can be performed in a hierarchical fashion. If the proxy doesn’t know about a particular destination, it can proxy the INVITE to the next level in the hierarchy, which will route it appropriately. In this fashion, a large distributed SIP network can be constructed, with each proxy being responsible for supporting a limited number of endpoints. The reason that policy server scalability becomes an issue is that in an environment with tens or hundreds of thousands of endpoints over hundreds of CMTSs, it is unlikely that a single policy server will be able to support all devices. The simplest approach to this problem is to establish an N-to-1 mapping of SIP proxies to policy servers, where each policy server supports one or more SIP proxies. In turn, each policy server supports one or more CMTSs. By taking advantage of the segmentation already used for the proxy servers and tying the policy server segmentation to mimic it, there is a reduction of the scalability problem to one where the policy server must only support at least as many endpoints as a proxy server can. Given the current state of the market for policy servers, this is not an unreasonable assumption. SIP-based MTAs One problem with deploying a PacketCable 1.x voice solution is that it requires new functionality and hardware in CPE devices. These devices embed multimedia terminal adapter (MTA) functionality into a DOCSIS cable modem (hence the name embedded MTA, or EMTA). While this provides an enormous amount of application control, it has the disadvantage of requiring replacing existing CPE devices in an "up-sell" situation. Primarily for this reason, cable operators long have desired the ability to put a standalone MTA into their residential service offering. This device would connect to the universal serial bus (USB) or Ethernet port of an existing DOCSIS cable modem and provide the same residential service offered via an EMTA. One significant issue with this is that there is no "open interface" between the MTA portion and the modem portion of an EMTA. In fact, call setups and interactions assume a tight coupling between these components. This makes it difficult to impossible to design an MTA that can communicate with the modem for the purposes of having the modem request QoS on its behalf. Further, given the emergence of services such as Vonage, a large number of inexpensive analog telephony adapters (ATAs) has emerged. These devices are primarily SIP-based endpoints, not media gateway control protocol (MGCP)-based endpoints. Given these realities, it is desirable to pursue an alternate course for supporting MTAs. For this application, the architecture will be very similar to the architecture described for the SIP video phone application. In fact, the exact same architecture could be used to support the MTAs as was discussed previously. However, for illustrative purposes, a slightly different architecture will be described. It should be noted, however, that either of these architectures could be used to support both applications. As in the SIP video phone application, a policy server, CMTS and modem must exist in the network. In addition, an application manager, application server and MTAs are needed. In this architecture, the application server is represented as a softswitch that is capable of acting as a back-to-back user agent (B2BUA) to simultaneously support network-based call signaling (NCS) endpoints and SIP endpoints. For discussion purposes, assume that the softswitch is a fully PacketCable 1.x compliant call management server (CMS) and that the back-end infrastructure for off-net capabilities is in place. A slightly different approach is taken for the application manager. This time, instead of embedding the application manager in the CMS, we will instead have a "stand-alone" application manager (SAM). This SAM will appear to the SIP-based CPE as if it were a SIP proxy. The CPE will communicate directly with the SAM, which will be responsible for forwarding all SIP messages to the softswitch. The advantage of this approach is that it can be layered transparently into an existing PacketCable deployment without modification of the existing CMS. Since both MTAs and NCS EMTAs share a common call control plane, "hair pinning" of SIP calls to NCS calls through the PSTN for two customers on the same network is unnecessary. One significant issue of this architecture is the need for the SAM to be scalable and highly reliable since it maintains session state; losing a SAM can cause problems. The second issue is the inherent need for a mechanism for the CMTS to be able to support both PacketCable 1.x and PCMM requests simultaneously. While this problem is not exclusive to this application, it will be discussed here. Simultaneous support While the PCMM specification implicitly allows a CMTS to support both PCMM and PacketCable simultaneously, one of the inherent benefits of having a policy server that is aware of the complete QoS state for a CMTS is lost if multiple unrelated servers request QoS from the same CMTS. The dilemma is that policy servers as defined in the specification do not support PacketCable 1.x. One alternative is for the policy server to have the ability to "proxy" PacketCable dynamic QoS (DQoS) requests. In this case, the CMS would communicate its COPS messages requesting QoS for PacketCable to the policy server rather than directly to the CMTS. The policy server would need to have an interface to receive the COPS message, abstract the necessary QoS information for its state and then send it on to the CMTS using PCMM messaging. Having the policy server sit in the middle of the path in this fashion allows it to get a complete view of the QoS state for the CMTS, without having to make modifications to a deployed residential voice service. This solution, of course, has several disadvantages. First, it introduces a certain amount of delay into the call signaling. It makes the policy server an integral part of the voice offering, dramatically increasing the need for a highly available and scalable policy server. Second, it is a "nonstandard" mechanism. The existing specifications for PacketCable 1.x do not provide for this "middleman" approach to COPS messages. However, given that the actual interfaces for each of the existing components (CMS and CMTS) do not change, this may be acceptable to operators. Console gaming service Given the enormous popularity of gaming and the tremendous interest in online gaming, support for a service targeted at gamers is highly desirable to some operators. Current revenue estimates for all gaming (console, PC and hand-held) now exceed $20 billion annually and continue to grow. Online gaming falls into two main categories. The first is where the client (PC or gaming console) registers with a central server and all communications are with that server. The second is one where a central server is used for coordinating a "peer network," where the session is established either in a completely distributed fashion or with one "peer" acting as a server for a small number of users (typically fewer than 10) who participate in a shared session. Gaming is an interesting application because many of the existing games are designed to operate in a low-bandwidth environment. However, like voice applications, they are highly sensitive to latency. For this reason, they are ideal candidates for a low bandwidth DOCSIS real-time polling service (RTPS). This guarantees that the console game always obtains at least the minimum bandwidth needed, and when it’s needed (minimum latency), despite other potential congestion on the access network. Gamers are usually very savvy users who understand network latency. In fact, many game clients have built-in support for measuring "ping times" to the server. A difference of a few hundred milliseconds in ping times can be an enormous advantage to a gamer. The issue with targeting a service at gamers is that, unlike the MTA or video phone application, one must assume that the operator has no control over either endpoint. This means that either modifying the application server or changing the client to point it at a "proxy" server is not viable. One mechanism that some vendors are pursuing is to modify existing network elements that already are capable of detecting application traffic flows to send PCMM COPS messages to a policy server. This, in many ways, is a simpler problem for these vendors to solve because gaming applications can be identified easily. This is in contrast to many of the peer-to-peer (P2P) sharing applications, which disguise themselves to avoid detection. Again, the elements for a gaming service are the modem, CMTS and policy server. The application manager is a stand-alone device that monitors all network traffic in order to identify the setup and tear-down of gaming applications. In this instance, the CPE and the game server are completely independent of the QoS enabling service and therefore unaware of it. The obvious issue is scalability of the application manager. Since it must monitor all traffic, it must detect in near real time that a gaming session is being established and communicate that to the policy server. Given that several vendors have demonstrated that they can monitor applications similar to this at or near line rate, it is reasonable to assume that this problem is solvable. The second less obvious issue is that these application managers typically sit on a network interface upstream from the CMTS. This means that if a gaming application is pure P2P (that is, no coordination with a central server) and all of the clients are on the same CMTS, the application setup may never be detected. While this problem could be solved by forcing all traffic to go external to the CMTS, the likelihood of this scenario is small enough that it will be left in the "to be addressed in the future" category. Bandwidth on demand The final application also is one of the simplest. This is a bandwidth-on-demand service. This type of service allows either a user to request higher bandwidth or a service to allocate higher bandwidth automatically. This request can be for a particular application or for all traffic. Two examples are automatically allocating higher bandwidth for traffic to download a streaming video from the operator site or a "turbo" button to increase all traffic bandwidth temporarily for a user. For the purposes of this example, the assumption is that the operator has direct control over the application server. As such, it will interface directly to a SAM or will embed the application manager functionality. Typically, it will use existing interfaces such as extensible markup language (XML) or proprietary application programming interfaces (APIs) to interface to a SAM. In this scenario, as with the other architectures, the CMTS, modem and policy server need to be in place. In this architecture, the client is either a PC or a particular application running on the PC. Looking at the first scenario of a specific application getting higher bandwidth for itself, consider a cable operator that has a streaming service allowing users to "tune in" to the local high-school football game from their PCs. The user would go to the operator Web site and select the video. The Web server would have an embedded application that, when the user clicks on the link, communicates to the application manager that the user at a specified IP address has requested to view the video. The application manager would then request that the policy server allocate higher bandwidth for that traffic flow by setting up a DOCSIS service-flow associated with the specific endpoint and the video server. The second example is one where the user requests higher bandwidth by visiting a Web site and hitting a "turbo" button. Again, the Web server signals to the application manager to allocate higher bandwidth, this time for a particular user/IP address. The application manager would then inform the policy server of this request. In this case, it is more typical that, as opposed to setting up service flows, the policy server would request a new service class for all traffic for a particular cable modem. The biggest issue for these types of applications is mapping the user to the appropriate CMTS. Unlike the previous examples where segmentation could be established based on the geographic location of the servers, in most of these examples all users would go to the same centralized Web server or cluster of Web servers. While there are multiple ways to address this, the two easiest ways are to map to the appropriate CMTS based on the IP address of the requesting PC or a lookup based on the userid of the user. Requiring a logon for either of these services would not be unreasonable. General issues The actual implementations of the applications described here are relatively straightforward in a PCMM environment. The PCMM specification is general enough to support the wide variety of applications and different models for supporting application managers. However, moving these from a "lab experiment" to a deployable service will require a tremendous amount of back-end support. Services will need to be provisioned within the applications, billing and customer care interfaces will need to be developed, and troubleshooting tools and methods and procedures will need to be developed. These issues are beyond the scope of this article, but will be faced as these applications move into real-world deployments. Conclusion PCMM provides a viable, though yet unproven, architecture for deploying truly differentiated services over a cable infrastructure. The wide variety of applications that already have been demonstrated show that the growth and deployment of these services is likely to proceed at a breakneck pace. As the capabilities of providing QoS to nonQoS-aware applications becomes evident, the demand will only increase. In order for operators to be ready for these demands, they must make sure that the underlying infrastructure for supporting PCMM, specifically the policy server and CMTS, are stable, scalable and reliable. Chris Maloney is senior manager for Cisco Systems. Email him at [email protected]. Did this article help you? Email comments to [email protected].