Contents Telektronikk - Telenor

frames where the router is destination are
identified as outgoing traffic.
These definitions assume that the internal
traffic on the LAN does not go via the
router; which is usually true, unless the
router also acts as an internal server or
several LAN segments are connected
directly to the router. In the latter case,
filter functions in the protocol analyser
can be utilized to extract the WAN traffic,
see [2].
2.3 Technical constraints
The fact that the observation point for
these measurements is on the LAN side
of the router, as illustrated in Figure 2.1,
yields that the measurement data obtained
cannot represent the WAN link traffic
exactly. Also, the actual WAN link traffic
will be less than the theoretical WAN
link capacity. These two issues are due to
the parameters listed below:
- The LAN protocol overhead. Ethernet
has 18 bytes overhead, plus a padding
to ensure a minimum frame size of 64
bytes; the maximum data field (payload)
size being 1500 bytes. Token
Ring has 20 bytes overhead, but no
minimum frame size requirement; the
token hold time limits the maximum
frame size.
- The WAN protocols overhead. The
most common protocols on OSI layer
2 are the SDLC family, with 6 bytes
overhead and unlimited data field; and
the Point-to-Point Protocol (PPP),
which has 8 bytes overhead and 1500
bytes as maximum data field. X.25, a
layer 3 protocol, adds another 3 bytes
to the layer 2 protocol it is superimposed
over; and the data field being
maximum 128 or 1024 bytes. LAN
data fields that exceed the WAN data
field size will be split into several
WAN frames. WAN protocols can also
be router specific.
- The router configuration, where the
buffer sizes, the encapsulation of LAN
data fields into WAN frames, and the
encapsulation of WAN data fields into
LAN frames are of particular interest.
- The WAN window size, which restricts
the number of unacknowledged
frames or packets that the receiving
end can buffer up.
- The control frames in a WAN protocol,
which will steal capacity from the
payload.
- Routing information interchanged
among routers on the WAN link, using
LAN
Observation Point
protocols such as RIP, IGRP and
OSPF, is not visible from the observation
point.
- LAN broadcast containing the router
address will be measured, but will not
be transmitted on the WAN link. This
has proven to be of little significance
in the measurements conducted here.
Since all these parameters will vary from
case to case, it is not possible to calculate
the exact WAN link utilization for each
LAN interconnection based on the obtained
measurement data; and it is not the
objective of this study. The objective is
to identify the LAN sites as traffic
sources to the WAN links, and therefore,
we do not wish to look into the different
mechanisms of WAN protocols, which
can be proprietary router specific protocols.
Figure 2.1 illustrates the simplified topological
situation, where the external LAN
traffic must be transmitted over the single
WAN-link. More complex LAN and
WAN topologies may complicate the
interpretation of the measurement data
obtained. [2] provides examples of such
complex topologies and how to deal with
them.
Since the filtering of the traffic to and
from the router is done by use of the
MAC-address, these measurements are
restricted to routed networks. Bridged
networks use end-to-end MAC-addressing,
and these measurements are therefore
unsuited for such networks.
2.4 Some considerations about
the integration time
The integration time or integration
period is defined as the time period over
which measurement data are collected.
When the integration time is completed,
the data obtained in that time period are
stored, data registers are reset, and a new
integration time begins. Introducing an
integration time yields statistical limita-
In
Out
Remote
router
WAN
Figure 2.1 Observation point for LAN interconnection measurements
tions as all the figures will be accumulated
over that time period. Taking the average
over the integration time will hide
extreme values of the metrics given in
Section 2.1.
Hence, the ability to reproduce bursty
traffic behaviour is dependent on the
integration time: the shorter the integration
time is, the better the traffic description
becomes. Examples in [2] show that
the highest traffic load peaks are reduced
to about half the size when the integration
time increases from 1 second to 10
seconds. Increasing the integration time
further to 1 minute yields yet another
halving of the traffic peaks. However, the
total number of bytes and average traffic
load per hour or day are independent of
the integration time.
Clearly, an integration time in the order
of microseconds or milliseconds is
required to obtain all details about the
traffic dynamics. In [6], the interactive
‘think and turn-around’ time is found to
be between 150 and 200 milliseconds;
and the time length of a burst is in the
order of 100 milliseconds. The maximum
end-to-end delay the user can accept is
related to the subjective perception of the
quality of service.
WAN link measurement tools are capable
of managing integration times down to
1 minute, which is insufficient for reproducing
the dynamic pattern of the LAN
traffic described in the paragraph above.
Choosing the appropriate integration
time is a trade off between the reproduction
of the exact traffic pattern and the
data storage available. The nature of the
measurement task, where the protocol
analyser is left out at the customers’ site,
did not give the opportunity to first find
the busiest periods and then just store the
traffic during these hours, which would
reduce the demand for storage capacity.
Also, diurnal traffic graphs are of interest,
so that the measurements had to take
place 24 hours per day. Otherwise, a trig-
131