Advanced Provisioning for Commercial Opportunities: VoIP, VPN and T-1

Manual and end user-driven device configuration leave much to be desired. Here’s how to move this game to the next level. The HFC network has advanced in technical capacity several times in just the past five years, going deeper, increasing bandwidth, and becoming a multi-service, multimedia cable asset. What hasn’t changed much in the past five years is the way we provision the added services as new products for the subscriber. The products being provisioned today are highly focused on residential subscribers. The residential customer is well-served by standards such as DOCSIS and PacketCable, for both the devices the customer uses and how to provision those devices on the cable network. Commercial business customer products such as T-1s, virtual private networks (VPNs) and business voice over Internet protocol (VoIP), represent the single largest, non-entertainment, cable customer-base opportunity. These commercial products are served in some cases by non-industry specifications or standards. As more technologies influence both the commercial and residential subscriber, we are becoming more concerned with how to provision the next application and its associated device. Supporting the device activation and subscriber management of these new products requires an advanced provisioning system capable of moving with new standards and supporting both the cable network today and new networks that cable will sell its products across. What is advanced provisioning? Advanced provisioning provides real time, fully redundant device provisioning for PacketCable, DOCSIS, and CableHome standards. Advanced provisioning must also support third-party device provisioning and new session initiation protocol (SIP) device and user agent provisioning, enabling new products to be provisioned from the existing cable headend. Advanced provisioning plays a critical role within commercial services, particularly T-1 services, VoIP services, and VPNs. Headend provisioning systems must have an extensive application programming interface (API) set for integration with other operational support systems (OSSs) and service provisioning systems. These include workflow systems, customer service representative (CSR) systems, billing interface systems and inventory systems. (See Figure 1.) The toolbox Device provisioning only begins with dynamic host configuration protocol (DHCP). To get the job done, we need an entire toolbox of network protocols and systems at our disposal. Every device on a cable broadband network must receive IP address and configuration information to get online. (See Figure 2.) The scalability, redundancy, interfaces and flexibility of a device provisioning solution determine the type of products, number of products and quality of services an operator can offer. CableLabs specifies provisioning for DOCSIS modem, embedded (e)-DOCSIS devices and PacketCable multimedia terminal adapter (MTA) devices. To provision DOCSIS and PacketCable devices, we need DHCP initially to discover the device and learn its capabilities. Advanced provisioning then processes the relationship between the device requesting an IP address and the subscriber and the services for which the subscriber has paid. This event triggers a dynamic configuration to be built based on both the device capabilities and the subscriber’s purchased service plan. Along the way, we need to register devices within domain name system (DNS), transfer the generated configuration using trivial file transfer protocol (TFTP), supply a clock reference using time of day (ToD) protocol, and in certain cases perform Kerberos encryption services. Commercial subs A cable operator acquiring the commercial subscriber requires the tools to deploy and provision cable technology so as to offer products superior to what the customer receives today from the phone company. The range of devices used to reach these customers and offer T-1, VPN and VoIP services is a considerable challenge in both device provisioning and subscriber management, because many devices used are outside of existing cable industry standards today. T-1 services represent significant revenue for most major local exchange carriers (LECs). While symmetrical 1.5 Mbps in a T-1 or otherwise 3 Mbps of data throughput may seem easily trumped in the DOCSIS world, the functionality within the 3 Mbps T-1 is the secret. Individually selectable in increments of 64 kbps, 23 DS-0s make up a T-1 primary rate interface (PRI). The signaling and line operations embedded within the T-1 are enablers of multiple types of services, adding significant value to the physical interface. The T-1 and PRI represent a number of products, including converged access (voice and data), Centrex (central office-based private branch exchange, or PBX, features), and digital trunk or private line (PRI and T-1 data facility interconnect). Offering a T-1 circuit today over cable requires provisioning of nonstandard devices. Legacy provisioning systems often do not have the capability to incorporate emerging T-1 circuit emulation device provisioning. This leaves the cable operator to have overlay provisioning systems or worse, manual entry and activation of T-1 customer premises devices. Consider a small business with two locations. Each location averaging six lines can easily support all their telephony service at each location to the attached phone sets and support an inter-office phone network by each location having a low-cost PBX terminate a T-1 facility. This design is achieved by each site’s PBX breaking apart the usage of DS-0s within the T-1 from the LEC. Some DS-0s will be dedicated for inbound/outbound phone service at either site, and some will be dedicated for site-to-site trunking. The customer may be motivated to leave the LEC; however, the majority of customers will want to know four basics—whether they can preserve their investments, keep their public phone number, maintain their internal dialing plan, and save money by switching to cable. Emerging T-1 functionality for cable (see Figure 3) serves this example in addition to other uses for T-1 circuits, specifically the legacy installed base of T-1 customer premises equipment (CPE) routers in need of fractional or full rate T-1 data service. Available T-1 circuit emulation solutions as an integrated DOCSIS access device (IDAD) within the modem need to be provisioned from the headend like all other DOCSIS-based services. This IDAD services CPE Ethernet and CPE T-1 native interface presentation. In the DHCP process, an IDAD tells advanced provisioning services of its additional integrated or embedded functionalities, similar to an embedded MTA (EMTA) provisioning operation. Advanced provisioning systems capable of supporting PacketCable and DOCSIS standard devices as well as multi-vendor pre-standard options are fundamental to provisioning the services in the emulated T-1 IDAD example. DOCSIS VPN Within existing DOCSIS technology and other standards are the necessary tools for serving a managed VPN service, with a low-cost Ethernet presentation. Known as business services over DOCSIS (BSoD), this CableHome initiative leverages what we already have today in cable modem investments through advanced provisioning, allowing for logically separated Layer 2 VPN (L2VPN) services in a point-to-point model or a point-to-multipoint service model, depending on revision of DOCSIS and termination of the customer Ethernet domain. (See Figure 4.) The combination of existing DOCSIS modem functionality and advanced provisioning that enables L2VPN functionality will serve most commercial customer product needs today, leaving the cost of multi-protocol label switching (MPLS) technologies higher in the network where it can be absorbed across a greater number of subscribers. Advanced provisioning solutions treat the association of a subscriber assigned cable modem during the provisioning process to create the general extension information sub-type parameter for L2VPN services. This will modify how a cable modem treats association of CPE side traffic toward the cable modem termination system (CMTS). Effectively, a virtual local area network (VLAN) tag is now within Ethernet payload headers originating in the CPE, preserved over the DOCSIS domain, finally re-encapsulated into the network services interface or wide area network (WAN) side of a CMTS and pushed as tagged VLAN trunk. Multiple VPNs are enabled within a single tagged trunk to a L2VPN provider edge services switch in the aggregation network. This would enable the cable network to use lowest cost existing DOCSIS CPE technology, existing CMTS technology, and effectively terminate a stacked VLAN domain per CMTS. This design scales well given concentration of commercial subscribers within a CMTS. NonPacketCable MTA provisioning Many customers require more lines than those offered within a PacketCable EMTA device. Additionally, line presentations may be foreign exchange station (FXS)-based and not align directly to the residentially focused provisioning and services deployed in PacketCable architectures. Some functionality relates to Centrex. Centrex represents much of the functionality within a PBX; however, there is no PBX on the customer premises. The best solution to Centrex may be IP Centrex to serve commercial customers of all sizes and configurations, ideally presented by DOCSIS cable modem. IP Centrex will require the use of IP phones at the customer premises, and the likely scenario will be that the customer premises is implementing network address translation (NAT) after the cable modem for the LAN. Instead of IP Centrex with the previously mentioned caveats and requirements, we may leverage advanced provisioning to a customer premises MTA device providing FXS lines. FXS standalone MTA vendors typically support H.323, media gateway control protocol (MGCP) and SIP. Implementation of MGCP within the MTA is not likely PacketCable MGCP/NCS-based. Endpoint registration with the call management server (CMS) becomes the next issue. This is resulting in a desire to support SIP VoIP lines in the commercial domain because most stand-alone MTAs include robust SIP version 2.0 line functionality. (See Figure 5.) The obvious challenge, after interoperation with either the existing CMS or by implementing a SIP proxy server, is provisioning for standalone SIP MTAs. There is presently no single provisioning standard for SIP MTA devices. Provisioning of SIP MTA devices is further complicated when the device is behind a NAT gateway. The SIP device will require vendor-specific configuration data such as SIP user name and SIP password, encryption, and per-line configuration, all based on the services the subscriber has paid for. Per line configuration is not dissimilar to a PacketCable MTA. Each line in a SIP device needs to know its call line identification, digit map processing rules if applicable, and of course the phone number of each line or its extension. This necessitates the need for an advanced provisioning solution to address the DOCSIS cable modem, the standalone SIP MTA, their relationship to one another with the subscriber; and to support this provisioning from the current headend. Challenges In the case of a NAT firewall or other routed device, most SIP endpoints would believe they are in conversation with the other endpoint when they are in fact referencing the source IP address of the NAT router. While there are some workarounds for this, the problem remains of what to do when a SIP endpoint is behind a NAT gateway and the device requires provisioning information from the headend. (See Figure 6.) If DHCP options could be preserved through the CPE NAT gateway, Option 120 would tell a SIP stand-alone, nonPacketCable MTA where to locate its proxy/registrar server. This, however, is not possible with most CPE NAT gateways. CableHome represents a real solution to SIP device visibility when combined within advanced provisioning solution in the headend. Assigning the MAC address of an MTA to a subscriber record from the back office OSSs in the headend to advanced provisioning services at DHCP boot time, the CableHome portal in the CPE may allow a stand-alone MTA to participate on the LAN pass-through interface. This offers the MTA a public IP address directly from the headend. In the example with IP Centrex, IP phones and clients of any type to the IP Centrex service could also be directed to the LAN pass-through interface, thus removing the need for symmetrical port management systems. (See Figure 7.) With neither the combination of advanced provisioning from the headend with vendor-specific implementations of SIP and NAT traversal techniques, nor the use of CableHome device functionalities, the cable operator is left to manual and often end user-driven device configuration. This is undesirable because any solution whose success relies on the end user enabling it will ultimately not become a mass market, cost-effective product in the cable system. Summary The ability to offer new services, commercial or residential, business or entertainment, is in most ways tied directly to the ability to provision the service, dynamically associated with a subscriber with specific provisioning unique per subscriber device. Advanced provisioning solutions provide all the tools necessary to deploy all forms of new IP-based services including commercial VPN, T-1 products, and SIP VoIP based on the architectures we have already deployed from DOCSIS and PacketCable. Chris Busch is VP Broadband Technology for Incognito Software. Reach him at [email protected].