Ad hoc coalitions in U.S. and Europe working on standards -- Efforts afoot to merge Internet, voice network
techweb.com
September 14, 1998, Issue: 1025
Section: Systems & Software
Loring Wirbel
Littleton, Colo. - Convergence between cyberspace and the telephone
network may be at hand. Several new standards efforts have sprung up in
hopes of providing an interface between Internet Protocol (IP)
switching-and-routing hardware and Signaling System 7, the digital intelligent
switching protocol at the heart of conventional, circuit-switched telephony.
This flurry of efforts to link packet and circuit switching involves numerous ad
hoc coalitions, many of which are submitting standards proposals to the
International Telecommunications Union (ITU) and Internet Engineering Task
Force (IETF). Key contenders include the IP Device Control spec and the
Open Settlement Protocol.
Separately, the European Telecommunication Standards Institute (ETSI) has
formalized its efforts for IP-telephony links under the so-called Project
Tiphon. The Open Settlement Protocol (OSP)-backed by Cisco Systems,
3Com, Gric Communications, iPass and TransNexus-will be integrated with
ETSI's Project Tiphon work.
The Tiphon group is trying to focus on practical interworking solutions, rather
than development of proprietary protocols, said Rajeev Gupta, director of
engineering at the emerging-technologies group of Trillium Digital Systems Inc.
(Los Angeles).
Even as the OSP project within Tiphon looks at call-control issues for
carriers, a separate effort in IETF and ITU is defining a way to standardize the
interfaces between an IP gateway and a Signaling System 7 (SS7) switch.
Backed by a consortium led by Level 3 Communications Inc. (Omaha, Neb.),
the IP Device Control (IPDC) initiative leverages earlier efforts by Sun
Microsystems Inc. and other companies to develop a packet standard called
Diameter.
Diameter was an extension of the Radius authentication protocol, but a forum
promoting IPDC stretched it even further, to apply to thin clients attempting to
interface with circuit-switched networks. Level 3's Littleton working group
presented the specs to ITU and IETF in mid-August.
The various efforts are at such a nascent stage that it's difficult to tell how they
will mesh with each other, or with existing efforts such as the Voice Over IP
Forum. What is clear from the outset, however, is that the new protocol suites
will mean less work for semiconductor vendors and OEMs developing
real-time IP products-but more work for the protocol-stack developers who
specialize in signaling and call-control middleware. "From a stack provider's
perspective, it means more work and more business, and from our customers'
perspectives, it means a safer bet for standardized products," said Ethan
Harris, president of Harris & Jeffries Inc.
Vendors like H&J, Trillium and Telogy Networks Inc. are keeping a close eye
on all the efforts, waiting for a clear path to emerge.
"The need for standards was there, and the effort will mean more work and
more opportunities for us, particularly in developing interfaces to our Golden
Gateway [voice-over-IP] product," said Lynn Anne Miller, director of
corporate marketing at Telogy. "We are also waiting to see how this work
might converge with the PacketCable standards efforts for cable networks."
Harris said that stack developers have learned from sometimes bitter
experience to look before they leap. H&J, he said, took a measured risk in
developing stacks for Switched Multimegabit Data Service and
Multi-Protocol Over ATM, only to see SMDS disappear in the wake of
ATM, and MPOA get virtually overridden by technology favored by Cisco
Systems.
"The IP and SS7 issues may be similar," Harris said. "In essence, IPDC puts
the basic plumbing in place for standardizing gateway functions-undoubtedly a
good thing. But the instant you do that, it has an impact on OSS and other
higher-layer services. There's a potential for building a Tower of Babel."
Gupta of Trillium predicted that the IETF may claim priority rights to consider
IPDC issues, because the organization considers anything related to Internet
protocols as its domain. In addition, many OEMs working on IPDC are data
specialists just learning about circuit-switched signaling. The ITU will play an
important secondary approval role to make sure that control protocols are
compatible with existing signaling methods, Gupta predicted.
IPDC, a suite of protocols rather than a single protocol, has been promoted in
both ITU and IETF by a coalition formed in midsummer called the Technical
Advisory Council (TAC). The framework for the standard as well as some of
the base and signaling protocols stemmed from work on a base
protocol-Diameter-done by Allan Rubens of Ascend Communications Inc.
and Pat Calhoun of Sun.
The IPDC effort expanded as Level 3's voice-network engineering group
pulled together several supporters for TAC. They include 3Com, Alcatel,
Ascend, Cisco, Ericsson, Lucent Technologies, Nortel, Selsius Systems,
Stratus Computer (now part of Ascend), Tekelec and Vertical Networks.
The syntax developed for Diameter was used for authentication, authorization
and accounting. TAC combined this effort with separate protocol
development for connection control, device management, IP media control
and IP signaling transport.
The intent was to sit below transport-interface standards like H.323, the LAN
standard for videoconferencing, and to use existing call-signaling standards
such as Q.931.
IPDC spells out details of how signaling backhaul and connection control is
performed between a media-gateway controller and a media gateway. The
node that performs packet interpretation for the IPDC suite is defined as a
"gatekeeper," and can be integrated with an existing gateway system or
multipoint control unit. It can also be implemented as a standalone hardware
system.
Logically, IPDC signaling takes place between a gateway and a gateway
controller, while native SS7 signaling takes place between a gateway
controller and a circuit switch. Physically, however, a gatekeeper function can
be implemented in a variety of ways, making it likely that vendors will produce
hybrid packet/circuit switches in a number of configurations.
The base IPDC protocol is transparent to protocols at the transport layer, and
can be used with both TCP and UDP. Only two types of simplified packets
are sent under IPDC: a header-only packet and a packet carrying a header
along with several attribute-value pairs, which define particular aspects of a
call.
For example, the IP Media Control protocol under IPDC uses attribute-value
pairs to alert the gateway controller to send a message to the media gateway
to generate such telephony-oriented events as a ring, a busy signal or DTMF
generation. In the case of media control, TAC has even defined a scripting
language to be used within an IPMC control packet.
This also works for performing an actual call setup, putting an IP switching or
routing device in the position of indirectly managing call setup and clearing.
The IP Signaling Transport protocol under IPDC can operate in a native
mode, in which the gateway maintains external signal engines to the switched
telephone network. In this mode, events are translated into Q.931 signaling
and encapsulated into a protocol data unit. Alternatively, signaling can operate
in tunneled mode, in which the media gateway does not terminate lower levels
of the call.
Remote management
TAC members are touting the greater flexibility possible in central-office
equipment as intelligence gets put back in the network nodes owned by a
service provider, including IP-only nodes. This will allow remote management
of systems such as modem banks and fax servers.
IPDC drafts already have been presented to IETF, as well as the ITU's Study
Group 16. But 16 months' worth of presentations to Study Group 16 by
another body, ETSI's Tiphon, complicates matters somewhat.
Tiphon's 30 members include the vast majority of TAC members, increasing
the likelihood of standards coordination. But aspects of gateway call
control-including the Open Settlement Protocol completed as part of Tiphon's
ninth general meeting in Portland, Ore., on Sept. 2-create overlaps between
the TAC and Tiphon work.
Though Tiphon originally planned to be SS7-centric, its work turned to a
variety of generalized circuit-to-packet interworking functions-so much so that
Trillium brought a proposal to the Portland meeting calling for specific
ISDN/SS7 User Part-to-H.323 interworking functions. Gupta said Trillium
was hoping to see more specific interworking proposals growing out of the
Tiphon work.
Copyright r 1998 CMP Media Inc. |
