In addition to flow metering, different other
types of QoS and performance measurements
and indicators will be important. The most im-
portant of these types of measurements will be:
- Measurements of end-to-end delay and the
variation of the end-to-end delay; - Measurements of packet losses in the network;
- Reports about buffer threshold crossings and
faults.
These measurements are necessary to control
that the QoS requirements for the different traf-
fic classes are fulfilled.
Measured data in a node could be:
- Number of packets and octets;
- Intentional loss (RED, policy, contract
enforcement); - Unintentional loss (buffer overflow);
- Other, e.g. delay statistics through a router.
The integration time for rate measurements
depends on the type of traffic we are measuring.
The higher the requirement for packet loss /
delay performance, the smaller is the window
size needed. As a consequence real-time traffic
should be measured in shorter intervals than
what would be necessary for typical TCP traffic.
Although measurements are believed to be more
important in the future and constitute a basic part
of the control framework presented in the next
section, the most important questions related to
how measurements can be performed remain
open. Fundamental questions are the cost of
implementing monitoring hardware in the
routers and possible technology constraints
related to monitoring at high speed. What mea-
surement time intervals should in fact be used
is also an item for further study.
In a network domain deploying MPLS parameter
setting for the different LSPs may not be an easy
task. Due to the fact that the traffic to be carried
on an LSP is more or less unknown it will be
difficult to set these parameters in advance based
for instance on the SLS. To overcome this prob-
lem it will be necessary to monitor the traffic at
the edge node of the LSP as discussed above.
We assume that the capacity reservation is based
on the signalled values at set-up of an LSP and
that the traffic entering the LSP is policed
according to these parameters. Furthermore
we assume that these parameters will be used
to divide the capacity among different traffic
classes (e.g. to set the different rates or weights
in the routers to get the desired traffic perfor-
mance).The protocols deployed for setting up LSPs
allow different traffic parameters like peak rate
and committed rate with associated tolerances to
be set. However, due to the fact that the traffic
on an LSP will consist of a superposition of traf-
fic from many users it will be nearly impossible
to set the appropriate traffic parameters for a
given LSP. Generally, it will be difficult to set
more than one single bit-rate parameter per LSP.
In addition one needs to have a certain tolerance
on this bit-rate due to the fact that traffic may
stem from many sources and therefore may have
unfortunate phasing. Consequently, we propose
to base the control framework on the monitoring
of one bit-rate parameter Committed Data Rate
(CDR) and policed by a bucket with rate CDR
and tolerance parameter Committed Burst Size
(CBS). Excess Burst Size (EBS) may also be
used for elastic traffic (i.e. two buckets).We assume that the LSP parameters will be
updated based on observed threshold crossings
according to the following scheme. At set-up a
set of initial parameters will be provided. These
may be taken as an initial guess based for in-
stance on experience from similar LSPs. Once
an LSP is set up the traffic monitoring will be
triggered. Based on the measurements performed
per LSP, it may be necessary to renegotiate the
parameters for the LSPs. Resetting of parameters
should be on a rather long time scale (compared
to the packet arriving times) to avoid rapid
changes and possible instabilities.Traffic monitoring is a basis for estimation of
CDR for a given LSP. In advance we have a set
of predefined limiting values for CDR, say C 1 ,
C 2 , ..., Cn. The number of levels must be limited
to avoid too rapid changes. We assume that the
estimate of bit-rate fluctuates rather slowly as a
function of time (minutes or hours). This can for
instance be achieved by using some kind of
weighting.Figure 4 Estimated traffic as a
function of timeMbit/stimeCnC 1