| Local area networks are relatively simple
because one technology -- Ethernet -- won dominant market share in the
late 80s and has sustained LAN development since then. Yes, there are some
token ring systems. And yes, there have been occasional challenges -- FDDI
and then ATM for some campus backbones. But they all pale in the face of
Ethernet, as it has scaled from 10 Mbps to 100 Mbps to Gigabit. The result
is simplification for the IT director -- many potential vendors but only
one technology, and thus the ability to select only one or two vendors if
desired.
In the past three years, a similar simplification has happened to data
protocols for new applications. IP (Internet Protocol) has won. As
recently as four years ago, developers dealt with a profusion of protocols
-- SPX/IPX for Novell applications, SNA for IBM applications, DECnet for
DEC applications, and so on. Today, IP is the only protocol that an
applications developer would consider for a new data communications
application. This vastly simplifies everyone's lives.
However, when you turn to wide area networks (WANs), there are myriad
services and protocols in use. New applications may run on IP, but old
applications are still widely deployed. In addition, IP needs a transport
layer, and many transports are deployed. So we see a variety of leased
lines and public network services, using a profusion of protocols: PPP,
X.25, frame relay, ATM, packets-over-SONET, and completely proprietary
protocols. But there is hope. Simplification in the WAN will take a few
years to emerge, but it's coming, and early signs should be visible this
year.
TODAY'S LEGACY
The first wide area networks were built on leased lines carrying data
at 1,200 bps, 9,600 bps, or 56 Kbps, and eventually at T1 and higher
speeds. The choice of protocols was typically dictated by the equipment
vendor. As the need for remote access to IBM mainframes grew dramatically,
the WAN protocols were based on IBM's System Network Architecture (SNA).
DEC equipment focused on DECnet, and so on.
In due course, shared public data services emerged, first using the
X.25 protocol, then frame relay, and (more recently) ATM protocols. In
each case, these public data services provide private "virtual"
circuits that reproduce leased line behavior, at least in part. In other
words, to carry SNA, DECnet, or IP traffic from one site to another, an IT
director leases a virtual circuit instead of a real physical connection.
Among such shared data services, frame relay is the leader. But private
(non-shared) leased lines still dominate most large corporations' WANs. To
further complicate things, most frame relay virtual circuits are actually
carried on ATM backbones.
Today, an IT director with multiple locations is likely to run a
mixture of leased-line facilities and frame relay circuits with separate
networks for the historic SNA traffic and for newer IP applications, and
an entirely separate solution for voice communications. There are some
exceptions -- the integration of all services onto an ATM network, for
example -- but typically an IT director will be running multiple
semi-independent networks. And when choosing WAN services, he or she faces
a profusion of offerings, and a confusion of metrics: committed
information rate, peak rate, burst rate, sustained rate, drop rate,
latency, delay, etc. What's needed is significant simplification, and
there is some hope that this will happen, albeit a bit more slowly than
most IT directors would like.
CLASSES OF SERVICE
Perhaps the most pervasive legacy application protocol is SNA. Most large
corporations have multiple mainframe applications that communicate with
simple terminals using SNA. Many of these applications are considered
mission-critical. And, many of them require specific network performance
guarantees to deliver acceptable results. Consider a call center where
agents are accepting orders. What would happen to the efficiency of that
call center, for example, if the agents had to wait many seconds for a
screen pop? After installing CTI equipment to shave a few seconds off of
each call, we'd obviously like our agents to be able to access mainframe
data in a fraction of a second, not in 8 to 10 seconds. With a
"best-effort" service like IP, a screen refresh can be delayed
by a large file transfer. SNA on the other hand, is able to reserve
bandwidth and provide the needed delivery guarantees.
Voice telephony has different requirements -- notably, very low
latency, much lower than that of traditional data communications
applications. Without it, voice quality degrades and the service becomes
unusable. So today, high-quality voice over IP (VoIP) services use
dedicated IP networks, but most voice traffic remains on traditional voice
networks.
Even totally IP-centric applications such as Web browsing and e-mail
benefit from separate classes of service, for example, giving priority to
Web browsing. After all, e-mail and bulk file transfers can wait seconds
or even minutes if necessary, but Web browsing is interactive.
ATM supports different classes of service today, so ATM can support
multiple applications on one WAN. However, from the IT director's point of
view, it's done by running separate networks over separate virtual
circuits from one ATM WAN provider. What's needed are application-level
quality of service (QoS) choices on the one network where all new
applications are deployed -- the IP network. What's needed are
differential services at the IP level.
DIFFERENTIAL SERVICES AND VIRTUAL CIRCUITS FOR IP
The good news is that working groups within the IETF (Internet Engineering
Task Force) have defined both differential services (DiffServ) and a form
of virtual circuits. Multi-protocol label switching (MPLS) provides paths
that are secure "tunnels" through a public IP network, from one
corporate site to another, for example, similar to virtual circuits in a
frame relay or an ATM cloud. And with IP DiffServ and appropriate traffic
engineering, carriers will be able to offer service guarantees for these
MPLS paths.
When deployed, MPLS paths will allow an IT director to order wide area
IP services from a single vendor if desired, where specific classes of IP
traffic (that is, specific IP applications) receive specific service
guarantees. This technology will roll out over the next few years and
result in a major simplification for the WAN.
In addition to supporting classes of service, MPLS paths also provide
security. IP networks have an image problem because of security problems
with the public Internet, the most well known IP network. But using MPLS,
traffic on the label-switched path is isolated from the rest of the
traffic on the IP network. Of course, encryption is also available and is
being deployed, but just the act of separating traffic goes a long way
towards addressing security concerns.
SIMPLER AND LESS EXPENSIVE
Combining all applications on a single network will also save IT directors
money in the most expensive part of their network -- the access loop.
Since deregulation, there are innumerable carriers deploying new fiber.
And, with the advent of dense wavelength division multiplexing, an
enormous amount of bandwidth is coming on-line, at least in the
long-distance network.
But the access loop is a different story. Here there is a dearth of
fiber, and the copper cables are owned by entrenched monopolies. So,
access bandwidth remains the most expensive part of a WAN. Indeed, some
WAN service providers bill only for access bandwidth, providing
long-distance transport for zero incremental cost. With further
competition in the local loop, this situation should improve. And at least
there is more than one local monopoly -- the telephone company owns the
copper and the cable company owns the coax. However, cost cutting in this
area remains slower than in any other part of the network.
Clearly, combining voice and mission-critical data with e-mail and file
transfers on a single access loop is a major cost savings. Once this is
possible, IT directors need only sign up for an IP access service for each
of their locations. Within that access pipe, they'll specify applications
that require special services, and they'll specify a given amount of
bandwidth per special service. It's the special services that will cost
money.
The remaining access bandwidth will be available for best-efforts
traffic, between corporate sites and to and from the public Internet. If
you sign up for enough premium services, it's likely the best-efforts
services will be free. The carrier will take care of provisioning multiple
label-switched paths between the regional offices and corporate
headquarters unless the IT director wants to retain control of this
function.
While it will be possible to offer many different classes of service
(and smart marketeers can put many fancy names on even a single service),
it's likely that only three or four classes of service will be needed to
meet most needs. Examples might be a low-latency service for VoIP traffic,
a guaranteed bandwidth allocation for mission-critical applications,
Internet access with some preferences (for Web browsing), and best efforts
(for e-mail and non-critical file transfer, and everything else).
Simplifying customers' needs to this level allows carriers to provide
corporations with an IP-only network that supports their applications.
Corporations only pay for the contracted access and for those QoS
guarantees they desire. Most likely, the corporate IT department will
provision their desired services themselves using a Web browser and the
carrier's secure Web server. Then they can also reconfigure services as
needed.
Of course, legacy SNA networks won't change immediately, but when they
have to change for other reasons, they'll migrate to IP as well. And
meanwhile, IT directors can tunnel their legacy SNA traffic through an IP
service with response-time guarantees. With VoIP gateways, or an IP-PBX,
voice can also be supported by a service that guarantees less than 70 ms
latency and less than 0.01 percent packet drop -- more than adequate for
toll-quality voice performance.
A REALITY TODAY
Since MPLS is not yet widely deployed, and since the traffic
engineering for IP differential services is still in development, interim
techniques are emerging. An immediate approach to differential IP services
has appeared in the form of bandwidth management equipment that maps IP
QoS to ATM virtual circuits. ATM QoS and ATM traffic engineering are well
understood, and ATM networks are widely available today. By automatically
mapping IP applications to ATM virtual circuits, a service provider can
provide differential IP services today -- the carrier deals with the ATM
details, the customer sees only IP services with performance guarantees.
As MPLS and DiffServ become more widely deployed and traffic
engineering is refined, IP QoS will migrate from being delivered using ATM
technology, to being delivered using MPLS and DiffServ technology. But
either way, wide area differential IP services will emerge this year. WAN
simplification is underway.
Brough Turner is senior vice president of technology at Natural
MicroSystems, a leading provider of hardware and software technologies for
developers of high-value telecommunications solutions. For more
information, call Natural MicroSystems at 508-620-9300, or visit the
company's Web site at www.nmss.com.
E-mail to the author (addressed to [email protected])
is also welcome. |