Side_1_360

change it at any time. The MPR daemon process
measures the NPL parameters and sends them
every 16 minutes to the Management server
through a TCP socket interface. The Manage-
ment server receives the measured values, puts
them to a file for the charging application, and
calculates with some algorithm new reservations
between the MRPs and starts scripts in the
MRPs to refresh and to modify the RSVP reser-
vations.

When the network is initialised, RSVP reserva-
tions are made between the MRPs. As band-
width in a practical IP-network is limited and
traffic variations could be rather high, we did
not set up one-to-one reservations between each
MRP for each class but instead configured each
MRP to accept up to a given limit traffic coming
from all other MRPs. In the laboratory network
this difference cannot be seen as there are two
MRPs only. After each 16 minute time slot the
RSVP reservations are modified by the manage-
ment server based on the measured NPL values.
In the implementation the management server
collects the measurement values from each MRP
every 16 minutes, but to minimise management
traffic we could have sent a trap only if the NPL
value measurements show exceptionally bad or
good results. There is a small protocol guaran-
teeing that a user of a better class will also
receive good quality, not only be able to send it:
the receiving MRP stores the class of each exist-
ing connection to a table. Provided that there is
a response or reverse flow which sends the cor-
rect receiver’s class to the sender’s MRP, the
received quality will also be good.

User traffic must be accepted to a reserved pipe
by the MRP, which then must keep tables of

users and active connections. There is a simple

admission control, but it is currently rough.

Figure 5 shows the structure of the MRP dae-

mon. IP-packets come from a user’s application

without any quality markings. When these pack-

ets enter the MRP, in Figure 5 the Access Node,

the MRP daemon looks at a table where for each

registered user are kept the assignments of IP

packets with given protocol and port number to

an AC/QC pair. The AC/QC pair is mapped one-

to-one to a ClassID, which is the quality class

identifier that the technical solution understands.

The packet is marked with the ClassID. The

ClassID also gives the MRP number because

of the way the ClassIDs are assigned: they are

unique to the extent that a receiving MRP can

know which MRP sent a packet with a given

ClassID. If there is no entry for a given user or

(protocol, port)-pair, no marking is done, and the

packet will be best effort.

The MRP daemon also sets a time stamp into the

IP-packet. This time stamp enables calculation

of the delay and jitter from a short term delay

variation. We need to time-synchronise the

MRPs with some protocol like NTP (Network

Time Protocol). As all MRPs are in one opera-

tor’s network, we can assume that NTP can be

used and is sufficiently accurate: 10 ms is a suf-

ficient accuracy to the QUASI-model, and that

can be reached.

A packet with a given ClassID is mapped to a

correct RSVP reservation selected by the routing

mechanism. The reservations are already set in

the beginning and modified in a slow pace with

updates every 16 minutes, they are not made

when a user starts his connection. This is for

scalability reasons.

Figure 5 Architecture of the

ACCESS NODE Linux PC MRP daemon

(MRP)

End system

QoS Window

QC/AC Selection

User ́s

Network

Router,

Firewall,

Proxies

Table of Services

Protocol Port Number ClassID

TCP ftp_port QCx,ACx

TCP www_port QCy,ACy

UCP ftp_port QCz,ACz

QoS

Software

(Netfilter)

Intserv mapping

RSVP-daemon

Logical connection

IP packet

with CID and

TimeStamp

marked

IP packets

Physical connection