October 1996
By Tony Rybczynski and Ravi Narayanan,
Nortel Multimedia Networks
ATM Gets Real About Real-Time Apps
ATM boasts a comprehensive set of specs governing real-time traffic
[
The Spec Sheet
]
Time to play a little word association: When a net manager hears
ATM the first response is... real-time. No surprise there: ATM was
billed from the beginning as a way to handle delay-sensitive voice,
video, and multimedia applications. Listen a little longer, though,
and adjectives like "overrated" and "expensive" begin to crop up.
There are other schemes out there, some networkers say, that offer the
same quality-of-service capabilities as ATM--for a fraction of the
price.
Maybe so, but in this case the gut reaction is the right one. Fact
is, ATM boasts a comprehensive set of standards that specifically
address real-time traffic. These include a range of service classes
for transporting various types of data, as well as circuit-emulation
capabilities that describe a way for apps requiring T1/E1 circuits to
run over ATM nets. There are various delay-control algorithms, and
work is under way on methods for handling voic
e natively over ATM.
Also being addressed is integration of schemes like TCP/IP's RSVP
(resource reservation protocol) with ATM's class of service (COS)
mechanisms.
All of these approaches will work together, which makes ATM a good
choice for running real-time applications end-to-end. And that's
something that a simple word or two can't convey.
Real-Time Realities
Getting a read on real-time applications--and the requirements they
place on the network--means looking at the basics. In short, real-time
apps (whether video, telephony, data, or a combination of these) have
very tight delay constraints. Networking nuisances like excessive
end-to-end delays, delay variations (which result in jerky sound or
video), and insufficient bandwidth hurt the usefulness of the
application.
Right now, the dominant real-time applications in business are
telephony and videoconferencing. Picturetel Corp. (Danvers, Mass.)
estimates that there were 42,000 group videoconferencing systems
deployed i
n 1995. The total number in use is expected to more than
double by 1998.
Desktop videoconferencing, on the other hand, still has some
catching up to do. Telespan Publishing Corp. (Altadena, Calif.)
estimates that in 1995 fewer than 100,000 desktops were equipped with
videoconferencing capabilities. However, the explosive growth of
dedicated Ethernet--along with announcements by Intel Corp. (Santa
Clara, Calif.) and Microsoft Corp. (Redmond, Wash.) to back the new
H323 video-over-IP standard--could result in 10 percent of all desktops
having videoconferencing capabilities by the end of the decade.
Moreover, IP-based audio and video broadcasts are becoming
increasingly common. These applications tend to be of two types.
First, there are the non-real-time transfers of MPEG (Motion Picture
Experts Group) or audio-video interleaved files, which are decoded on
the client platform and played back locally. Then there are real-time
streaming applications, in which the remote server decodes the
informat
ion on the fly.
There's also a range of emerging real-time applications, such as
business TV, collaborative computing, instrument and process control,
parallel system interconnect, distributed simulations, and network
games. All of these have very strict timing and quality-of-service
requirements, and all can be run over ATM.
And for all of these applications, minimizing delay is the name of
the game. ATM offers three ways to go about it. First, it guarantees
that the delay and delay-variation constraints of the application are
met on individual links. Second, it guarantees delay and
delay-variation constraints and bandwidth requirements are met on an
end-to-end basis. Finally, it defines a way to allocate adequate
bandwidth to meet application needs.
Concerning COS
That's where ATM's COS definitions come in. ATM defines several
service classes, which essentially are mechanisms for transporting
traffic with different network requirements. These include unspecified
bit rate (U
BR), constant bit rate (CBR), variable bit rate-real time
(VBR-RT), variable bit rate-non-real time (VBR-NRT), and available bit
rate (ABR). Of these, CBR and VBR-RT are the two service classes
applicable to real-time applications.
The CBR service category is used by connections that request a
fixed amount of bandwidth, characterized by a PCR (peak cell rate)
value that is available throughout the duration of the connection. The
source may emit cells at or below the PCR at any time and for any
duration. This category is intended for real-time
applications--including those the ATM Forum calls circuit emulation
services (CES), which require tightly constrained cell transfer delay
and cell delay variation characteristics. Still, CBR is not restricted
to these applications. The real-time VBR service category is intended
for such time-sensitive applications as voice and video. Sources are
inherently bursty and transmit at a rate that varies with time.
Traffic parameters are PCR, SCR (sustainable cell rate)
, and MBS
(maximum burst size). Cells that are delayed beyond the value
specified by CTD (cell transfer delay) are assumed to be of
significantly less value to the application.
Emulation Specification
Service categories are just the beginning, however. ATM also
defines a way for circuits to be emulated over an ATM network. The ATM
Forum has specified two types of CES environments--unstructured and
structured.
Unstructured mode operates across a T1/E1 interface on the full
1.544/2.048-Mbit/s stream; end-to-end performance monitoring is
optional. This mode supports ATM Adaptation Layer 1 (AAL 1) cells
only, and it assumes no particular line framing and no alignment
between bytes and cells. Structured mode operates across a T1/E1
interface on n364 streams with or without channel-associated
signaling. It supports multiple framing types, including extended
super frame (ESF).
So far, so good. But circuit emulation isn't the end of the game.
Since real-time services have traditional
ly been supported in the WAN
via circuit-based techniques, it's natural to map these circuits to
CBR virtual circuits (VCs) using circuit emulation. There's a
disadvantage here: Bandwidth has to be dedicated for this type of
traffic whether it consists of useful information or not. This acts as
a disincentive to corporate networkers who might otherwise implement
circuit emulation as a long-term strategy. For example, a T1 circuit
requires 1.74 Mbit/s of ATM bandwidth when transmitted in circuit
emulation mode.
However, VBR-RT standards already have been defined for MPEG-2 on
ATM for video-on-demand applications. In addition, standards for
running voice over VBR-RT VCs will likely be completed by the end of
1997. Some vendors already deliver VBR-RT voice, and for some carriers
it's the basis of the service offering.
Another way that real-time traffic could be transported is by
leveraging new APIs (application program interfaces) such as Winsock
2.0, across which applications can signal quality-
of-service
requirements. ATM Signaling 3.0/3.1 allows the user to specify the
following parameters for real-time connections:
called party number;
class of
service requested (CBR, VBR-RT, and others);
connection configuration (point-to point or
point-to-multipoint);
forward and backward peak cell
rates (in cells per second);
forward and backward
sustainable cell rates (in cells per second in the case of VBR-RT
connections);
forward and backward maximum burst
size in the case of VBR-RT connections.
With Signaling 4.0, users
can additionally request CTD requirements. (The forum also has
completed version 4.0 of the user-network interface [UNI]
specification, but most products implement UNI 3.0/3.1.)
The call request is received by the network, which then determines
whether it has the resources to support the requested COS. The request
is signaled to the called party, which can change some
of the
parameters of the call (such as the PCR value). If the modification is
successful, the call is established.
Going End-to-End
How is ATM able to do all of this? It uses small, fixed-length
cells, so it can ensure there's a minimum interaction between
real-time and non-real-time traffic. All switching takes place in the
hardware, which increases ATM's scalability. Hardware-based
multiple-emission and discard priority-queuing schemes allow for the
differentiation between the requirements of real-time and
non-real-time services. In a typical switch implementation, ATM
services are separated according to their cell delay and cell
delay-variation requirements.
But link-by-link delay controls are not enough: End-to-end delay
controls also are needed. ATM meets these requirements via standards
that define COS-sensitive connection admission controls (CACs),
routing, and bandwidth reservation. It's those first two that are most
critical when it comes to real-time services.
The
key thing to remember here is that each class of service has
different requirements for bandwidth, transfer delay, and delay
variation--and CACs define ways for the switch to accept or reject a
call based on the network's ability to support the requested quality
of service. A generic CAC algorithm furnishes a common interpretation
of bandwidth metrics. Once a VC has been established across the
network, network resources have to be reserved and the quality of
service guaranteed for the duration of the connection.
The ATM Forum's private network-to-network interface (PNNI)
standard is a routing protocol that provides topology distribution
mechanisms based on advertisement of link metrics and attributes,
including bandwidth metrics. It uses a multilevel hierarchical routing
model that brings scalability to large networks. These are
general-purpose and are not specific to real-time services running on
ATM.
PNNI supports COS-sensitive source routing, with specific details
added along the route duri
ng call setup. Not all links necessarily
work with all service categories. Thus there are multiple steps in the
routing process--which means that the network must predict the impact
of new connections on established links. Parameters used as part of
the path computation process include the destination ATM address,
traffic class, traffic contract, quality-of-service requirements, and
link constraints.
Metrics that are part of the ATM routing system are specific to the
traffic class and include maximum cell transfer delay, maximum cell
delay variation, and maximum cell-loss ratio (which are related to
quality-of-service metrics). They also include bandwidth-related
parameters, such as the available cell rate and administrative weight.
To compute the path, network devices have to perform an overall
network impact assessment, determining how to avoid loops, minimize
rerouting attempts, and use various policies to select routes.
Real-Time IP
Applications that take advantage of ATM COS alr
eady are being
developed for specific industries (like film). As the desktop ATM
market grows, and as APIs like Winsock 2.0 become more common, we can
expect more general-purpose, real-time applications that can run in
this environment. However, networking of real-time services running
over IP on LAN-attached devices is becoming a much bigger market.
The IP protocol stack is an attractive platform for real-time
application developers. As a result, the IETF has defined an
integrated services architecture (ISA)--it serves as a framework
permitting networks to meet certain quality-of-service requirements
for IP-based applications. ISA includes such protocols as RSVP, which
make it possible to signal bandwidth requests for particular
applications.
The ATM Forum and IETF also are working on ways to map RSVP to ATM
COS mechanisms. These standards will probably be ready in time for the
likely deployment of real-time IP applications in enterprise
networks.
COS mapping from IP to ATM can be don
e at the edge of the ATM
network or in a workstation in a couple of ways--implicitly (by flow)
or explicitly (via RSVP).
RSVP is both a resource-request signaling mechanism that can be
used by the end-device, and a protocol for requesting bandwidth
allocation in an IP network. RSVP builds on the concept of flows,
which are unidirectional and can have multiple recipients. Two
services are currently defined: guaranteed service (intended for
real-time applications), which furnishes bandwidth and delay
guarantees for the length of the refresh cycle (typically 30 seconds);
and controlled-load service, which provides minimum delay guarantees
only.
RSVP is based on receiver-initiated reservation requests, with the
idea that the receiver knows its own capacity and will use the COS.
This might at first appear to be a mismatch with ATM's
caller-initiated model. But it's generally a nonissue since the sender
performs actual allocation of resources--for example, selecting the
compression rate for video.
RSVP control traffic needs some level of delivery guarantee, and it
might be able to use best-effort UBR VCs (and potentially ABR VCs).
The user's real-time data flows would use CBR or VBR-RT VCs as
appropriate to the application.
While RSVP does support multiple heterogeneous receivers on a
point-to-multipoint connection, all of the points on an ATM
point-to-multipoint VC have to operate at the same COS (practically
speaking, this would be the highest COS of the users involved). If
multiple COS operation is required, it could be done via multiple
VCs.
RSVP control and data flows follow IP routing, which is
complemented by packet forwarding and flow scheduling functions
required by RSVP (typically done in hardware). In mapping RSVP to ATM,
the intent is to take full advantage of ATM COS and ATM SVCs. The path
for how RSVP-based IP flows map to ATM may in fact be Classic IP to
MPOA (Multiprotocol Over ATM), and then to MPOA with I-PNNI
(integrated private network-to-network interface). E
ven in I-PNNI, the
problem of determining shortcuts for connectionless traffic over the
connection-oriented portions of the network is hardly trivial. But
I-PNNI can make this more automatic, since IP and ATM topologies are
known everywhere.
Another dimension to RSVP is support for multicasting. Different
multicast ATM architectures (e.g., server and mesh VC models) have
been proposed. Over the longer term, COS support will be incorporated
in the Multicast Address Resolution Server (MARS) for multicasting
over nonbroadcast networks, like those based on ATM.
Several areas are a little more problematic. One approach, the RSVP
soft-state (which requires the application to refresh its COS request
cycle periodically), allows end-users involved in, say, a
point-to-multipoint communication to renegotiate quality-of-service
parameters dynamically. RSVP also has provisions for best-effort
receivers, which don't issue actual RSVP requests. With ATM, network
resource allocation is performed via a hard-st
ate approach during VC
setup; the advantage is that quality of service can be guaranteed for
the duration of the call. While parameter renegotiation is addressed
in Signaling 4.0, renegotiation once the VC is established can be
accomplished only by setting up new VCs.
Voice Over ATM
With networks moving rapidly away from circuit switching,
voice-over-packet networks are inevitable. ATM is the most suitable
technology for this kind of network.
While CBR can be used, VBR-RT VCs recognize the inherently bursty
nature of voice communication. There are periods of silence that, when
dealt with appropriately, can lead to increased efficiency. These
silences arise when a particular trunk is idle, say, during off-peak
hours; when a call is up but only one person is talking; and when a
call is up but no one is talking. The ATM Forum's VTOA (Voice and
Telephony Over ATM) working group is now turning its attention to AAL
for VBR voice.
The addition of more bandwidth-effective voice codin
g (e.g.,
standard voice is coded using 64-kbit/s pulse-code modulation) is
economically attractive--particularly over long-haul circuits and T1
ATM interfaces. Various compression schemes have been standardized;
making them dynamic gives the net manager the opportunity to free up
bandwidth when there's congestion .
Another way of enhancing voice over ATM is to perform voice
switching over SVCs. This requires interpreting PBX signaling, and
routing of voice calls to the appropriate destination PBX. The
advantage? Connection admission controls can be applied to new voice
calls; when there's network congestion, calls can be rerouted over the
public network.
Video Highlights
While circuit-based videoconferencing streams (including JPEG
running at about 10 Mbit/s) can be handled by standard circuit
emulation using AAL 1, the ATM Forum has specified the use of VBR-RT
VCs using AAL 5 for MPEG-2 on ATM for video-on-demand
applications.
MPEG is a set of standards addressing coding of
video and
surround-sound audio signals, as well as synchronization of video and
audio signals during the playback of MPEG data. Such data runs in the
2- to 15-Mbit/s range (with occasional bursts) corresponding to VCR
and broadcast quality. MPEG-1 was targeted at VHS-quality video and
audio. MPEG-2 targets applications requiring broadcast-quality video
and audio, in addition to high-definition TV.
MPEG-2 coding can result in two modes: program streams, which
comprise variable-length packets carrying a single program or multiple
programs with a common time base; and transport streams, consisting of
188-byte packets that contain multiple programs.
In both cases, time stamps are in-serted into MPEG-2 packets during
the encoding and multiplexing process. MPEG-2 assumes a constant delay
model across the network, thus allowing the decoder to follow the
original encoder source clock.
Tony Rybczynski is director of strategic marketing and Ravi Narayanan is senior manager for ente
rprise marketing at Nortel Multimedia Networks (Richardson, Texas).
[
Home
]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
| 
