Side_1_360

For each ClassID the MRP keeps count of all
packets which have arrived for a given class and
all packets which are dropped for a given class.
The ratio of discarded packets and all packets is
passed every 16 minutes to the data collecting
system. After the time slot of 16 minutes, the
counters are zeroed.

The loss measurement was tested and found
working. It is accurate by definition and scales
very well to small loss ratios. In test traffic
methods of measuring loss ratios, like in CISCO
SAA Loss measurement, there is a problem
since losses are not well evaluated for small loss
ratios as only few samples are used. Using more
samples increases the load of the loss measure-
ment. We can take an example; in SAA a test
call creates 3700 bytes of traffic. If the loss
probability is 1% we should require about 10
packets lost in 1000 seconds to be able to get
a sufficient statistics, meaning 10 kbit/s of test
traffic. If the number of MRPs is 100, then each
MRP must generate and receive 1 Mbit/s of test
traffic for this one AC/QC. Measuring small loss
probabilities, say 10-5, would not be possible
with test traffic. Whether IP will never require
better loss ratios than about 3 %, sufficient for IP
voice, is an interesting question considering the
requirements for loss in ATM. In any case the
ability to monitor losses should not be the limit-
ing factor.

We expected to see some more differences in
test traffic and live traffic measurements, but it
turned out that in the test traffic measurements
made with CISCO’s SAA tool in the DiffServ
implementation were sufficiently precise for
delay, jitter and for sufficiently high loss proba-
bilities also for loss. There are theoretical cases
when differences in test traffic characteristics
and user traffic characteristics lead to differ-
ences, also when these traffic types are routed
differently, but we did not observe anything
alarming in this respect.

5.3 Example Test

Seven tests were performed for the measurement
and management methods of the QUASI-model.
We only present one test here, the test 7 in
[P906-5] made by Denis Karpov and Imad
Ossaily. This test would verify whether the
dynamic re-allocation of RSVP reservations
based on NPL measurements works in the net-
work in Figure 3. The test consisted of 3 time
slots, each lasting 16 minutes. The tests were
made eight times, so Table 4 contains 8 mea-
surement values and their average in boldface.
There are two MRP points in Figure 3, and the
table shows the delay and jitter values between
the MRPs to one direction for two classes of
traffic, the premium class and the basic class.
Packet losses do not occur for the premium or

basic classes. In the test the RSVP allocations

are originally set to 3 Mbit/s for the premium

class and 1 Mbit/s for the basic class. Then six

512 kbit/s premium class sources and four 256

kbit/s basic class sources are added during a 16

minute time slot. The network adapts to the

changed traffic conditions by changing RSVP

allocations if the measured values are higher

than 95 % of target values. In the second time

slot of 16 minutes a best effort source of

5 Mbit/s is added and in the third time slot the

best effort source is raised to 7 Mbit/s. The tar-

get values for delay and jitter for the premium

class are 10 ms and 40 ms, for the basic class the

target values are 17 ms and 65 ms. In the test the

target values are always achieved. Some service

differentiation is seen between the classes seen

on high traffic load.

6 QUASI-model and Charging

A number of processes are involved from captur-

ing the usage to creating a bill to be sent to a

customer. A layered model can represent these

processes. The charging and accounting refer-

ence model used in P906-GI is illustrated in

Figure 7.

Each layer represents a specific basic functional-

ity, which is configurable by using parameters

supplied by specific policy definitions.

The metering layertracks and records the usage

of resources by observing the traffic flows. The

metering policy, used for configuring the meter-

ing layer, specifies the attributes of the traffic

flows to be observed. In a connectionless net-

Figure 7 A Charging and

Accounting Model used in

P906

Billing Policy

User/Service specific

requirements

Billing Layer

Billing Configuration

(e.g. bill template)

Charged data

Charging Policy

Charging specific

requirements

Charging Layer

Charging Configuration

(e.g. charging formula)

Accounting data

Accounting Policy

Accounting

requirements

Accounting Layer

Accounting Configuration

(e.g. collector address)

Collected data

Collecting Policy

Collecting

requirements

Collecting Layer

Collecting Configuration

(e.g. meter address/

placement)

Metered data

Metering Policy Metering Layer

Meter Configuration

(e.g. metering intervals)

PI

DI

DI

PI = Policy Interface

CI = Configuration Interface

DI = Data Interface