Contents Telektronikk - Telenor

174
Synthetic load generation for ATM traffic measurements
BY BJARNE E HELVIK
Abstract
The only way to validate the performance
of an ATM based network is
extensive traffic measurements. Obviously,
if such measurements shall be
meaningful, they must be carried out
under a load with characteristics similar
to that of real traffic. The network
performance measures obtained, e.g.
cell loss, delay and jitter, will depend
heavily on the load put on the system.
The paper starts with a brief discussion
of this issue. Next, an introduction
to modelling of ATM traffic sources is
given. Various approaches to traffic
generation is outlined, before the modelling
framework on which the STG is
based, is presented. The STG (Synthesised
Traffic Generator) is an ATM
traffic generator, which is designed to
generate a traffic load as realistic as
possible, and thereby enable trustworthy
ATM system measurements. The
source type models include the
behaviour of physical sources and the
formation of ATM cell streams done
by the terminal equipment. How such
source type models may be established
is discussed and exemplified. In the
STG, time varying traffic mixes
towards various destinations may be
defined. These are denoted load scenarios.
One STG can generate the multiplexed
traffic stemming from up to
2047 independent sources. A nearly
infinite number of independent and
reproducible cell load sequences, with
the same statistical properties, may be
generated for each scenario. The paper
concludes with a sketch of how the
STG functionality may be extended.
1 Introduction
Today, there are few who doubt that the
coming generation of high capacity networks
and switching systems, both in the
public and private domain, will be based
on the ATM (Asynchronous Transfer
Mode) principle. In the public domain
switches from various manufacturers are
tested in trial networks and “ATM solutions”
are heavily marketed for local area
networks. However, ATM is new and
unproven – also with respect to traffic
engineering. The capacity (bandwidth)
on demand idea underlying ATM poses a
wide range of challenges. The characteristics
of the load put on the systems are
partly unknown and new call handling
and switching techniques are introduced.
At the same time very strict requirements
are put on network performance/quality
of service parameters like cell loss frequencies
and cell delays. In spite of the
enormous effort put into traffic research
related to ATM during the last years, our
possibilities to perform a thorough validation
of the traffic carrying capabilities
of these new systems is restricted.
- A sufficiently detailed mathematical
analysis under realistic assumptions is
impossible, even for small systems.
- Full scale simulations are too demanding
with respect to computer time. This
is, to a large extent, caused by the
enormous number of cells that pass
through the system relative to the number
of events occurring during the
same time. Work is going on toward
special “speed-up techniques”, see [1].
However, this evaluation technology is
not yet mature.
- Measurements and experimentation
then remain as our prime means to
gain confidence in this new and not yet
fully proven transfer technology.
Types of measurements that will be
carried out are for instance:
⋅ Validation of equipment, like the
cell carrying capability of a switch,
the jitter it introduces in a cell
stream, its fairness with respect to
service impairments caused to various
connections, etc.
⋅ Design decisions and trade-offs, like
determining the appropriate size of
packets on various protocol levels,
the (possible) forward error correction
(FEC) needed for some real
time services, etc.
⋅ QoS cross-influence between services
(source-types). For instance, is
there a difference in the service
impairments when a high quality
video connection competes in the
network with mainly data connections,
constant bitrate connections
(CBR) or other video connections
when the average load is the same.
⋅ Investigation of acceptable loading
under various traffic mixes to validate
connection acceptance control
(CAC) functionality.
When carrying out measurements, it is
necessary to be able to register for
instance the delay of various information
units (cells, transport packets, video
frames, etc.) through the network as well
as the cell loss associated with the same
units. Note, however, that the traffic load
put on the system is the most important
constituent with respect to the results
obtained. The best approach is of course
to put controlled, real traffic on the system.
This, however, is not feasible. Real
traffic can not be kept sufficiently stable
and be varied with respect to load and
mix to obtain controlled and accurate
results. A realistic loading of a system
requires an array of independent generators,
each producing the traffic stemming
from a large number of independent
sources. In addition to established
sources/services, it should be possible to
load ATM systems with traffic from
foreseen, but not yet available services,
and traffic corresponding to various
choices with respect to service specifications
and terminal equipment design.
High level requirements for an ATM traffic load generator
- The traffic load should stem from a large number of independent sources (at least
1000), each with its unique virtual circuit (VC), payload, etc.
- The models of the sources should be physically interpretable, reflect both the information
transfer caused by the application/service, and the protocols and equipment
of the end systems. The model(s) should be adaptable to a wide range of source
types, e.g. speech, variable bitrate coded video, various kinds of data traffic, and
new and yet unknown services/equipment.
- The generated traffic must reproduce the short and long term properties of real traffic,
i.e. the range from microseconds to hours.
- It should be possible to define load scenarios with a mix of traffic from many different
types of sources with different and time-varying traffic interests.
- A nearly infinite number of independent and reproducible generations of each scenario
should be possible.
- The underlying traffic model(s) should enable a compact and efficient hardware
implementation.