PacketCable, now a year old, is on its way to specifying a
supporting infrastructure for real-time, packet-based applications, targeting Internet
Protocol (IP) telephony over cable systems as an initial application -- and there's more
in store after that.
"Our wider mission is to enable packet-based
multimedia services over cable plant," said David Reed, Cable Television Laboratories
vice president for strategic assessment. PacketCable, he added, "will provide a
versatile tool-kit for configuring a network infrastructure to support these new services.
The end-game in configuring the network is to guarantee
on-time delivery of data packets -- above and beyond the "best effort" at timely
delivery which still characterizes the public Internet, Reed said.
Using the PacketCable architecture, a service provider can
assure end-to-end quality of service "by managing the features and functionalities of
the various network components," Reed said. These devices -- which include connection
management servers and network gateways -- carry traffic within the IP domain and also
interconnect with other networks, such as the public telephone network.
Services that become possible under PacketCable "can
be anything that requires real-time connectivity," Reed noted. "PacketCable,
when it is completed, is how cable operators will be able to participate fully in the IP
or Internet growth explosion."
In what CableLabs is calling "Phase 1,"
PacketCable is writing the specification that will let real-time multimedia services
overlay on top of a DOCSIS (Data Over Cable Service Interface Specification) network, said
David Bukovinsky, CableLabs' director, for PacketCable. The forthcoming DOCSIS 1.1
standard's support for quality of service
mechanisms is one required element of the Phase 1 interface
specs, he added.
Parts of the Phase 1 spec -- now being revised after a
vendor review process -- may be released as early as December, with the full spec to
follow during 1999, officials said. A Phase 2 of spec will follow, focused on the added
requirements of running a SOHO (small office/home office) business. Phase 3 will target
two-way video-conferencing.
Creating the PacketCable toolkit means specifying an
infrastructure upon which real-time applications can be built, Bukovinsky said. Required
items include quality of service signaling, security mechanisms within client applications
and network servers, and a comprehensive provisioning infrastructure for client
initialization and service creation. Once these are in place, innovative packet-based
applications may be developed.
IP telephony requires only what's called a "thin
client" device at the customer site, with most of the "call-signaling"
intelligence residing out in the network, Bukovinsky said. Currently, CableLabs is
considering two types of "thin clients."
For the relatively "rich clients" of the later
two phases, CableLabs and its vendor collaborators are likely to favor more
"distributed" protocols, which locate some of the call-signaling function in
devices on the customer premises, such as PCs. One of the protocols under study at
CableLabs is based on the International Telecommunications Union's H.323 standard, Reed
said.
"Long term, it makes sense to have a lot of
functionality distributed, because the subscriber can specify some pretty complex call
treatments," said Bukovinsky. "Then again, the phone has always been a fairly
simple device. How complex do you want to make things if your grandmother is the one
making the call?"
Of the centralized and distributed call-signaling
approaches, "our goal is to have an architecture that actually specifies both,"
Bukovinsky said. Meanwhile, the other infrastructure protocols to be specified -- quality
of service, security and provisioning -- "remain identical across both signaling
architectures," he said.
Reed said he's optimistic that cable operators who are now
deploying circuit-switched telephony "for time-to-market reasons" will be able
to migrate to PacketCable-compliant equipment when it's available in small amounts, two
years or so from now.
This column was written by Robert Wells for CableLabs.
