The following text is copyright 1998 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.

Combing architectural differences

By Scott Bradner

Network World, 08/31/98

The architecture of the Internet is different from that of the public
telephone network in the same way that the architecture of Internet
applications can be quite different from that of like applications that
run over telephony networks. Two examples of such applications
come to mind: PBX-based telephony and electronic data interchange.

A traditional PBX consists of a small number of interconnected core
systems, only one of which local telephones typically need to connect
with. Placing a call involves making a connection from one phone to
the PBX and sending a command (a series of digits to select the target
of the call) to the PBX, which then connects to the target phone.

In a traditional EDI environment, one customer connects to a server at
an EDI service provider, typically over a dial-up or dedicated line, and
deposits a specially formatted message on the server addressed to
another customer of the same EDI service provider. The message
transfer is completed when the other company calls in, or initiates
contact over a dedicated line.

Both of these examples involve a user connecting to a core server
which then controls the transaction with a second user. This model is
considerably different from that used by most Internet-based
applications, which tend to be peer-to-peer.

When sending e-mail using the traditional Internet model, an e-mail
client on my local computer connects to an e-mail server on the target
machine to transfer the message. This model has been augmented
somewhat by the addition of local post office protocol servers at many
locations, but even so, the network does not need dedicated servers
that act as exchange points. The communication is end-to-end rather
than end-to-middle and then middle-to-end.

Both PBX and EDI services are now moving to the Internet and
vendors are proposing two very different strategies for offering such
services. One strategy is to just replace the dial-up and dedicated lines
with Internet connections.

In this model all of the communication still goes through a core
server. In the case of a PBX-oriented telephony service, this means
that Internet-enabled phones would connect to a PBX server in the
local network and request a connection through the server to a target
Internet phone.

But there is no requirement to do this over the Internet. An
Internet-enabled phone could connect directly to another Internet
phone over the 'Net. The only infrastructure components needed
besides the network itself are some simple name resolution services.

In some cases, such as with EDI, the central server can perform
auditing functions. But even here, if the correspondents trusted each
other, no core server would be needed.

I expect to see Internet-oriented PBX telephony and EDI offerings
based on central-server and peer-to-peer architectures. But I anticipate
that the peer-to-peer model will, like the distributed architecture of the
Internet itself, be the successful long-term model. Those who think
they are going to make money running or building core servers for
these functions will have a hard time because these people do not
understand the 'Net's underlying architecture.

Disclaimer: As an aggressively decentralized institution Harvard rarely
encounters the problems of centralized services, but in any case, the
above observations are my own