Side_1_360

worse quality. This would require an additional

protocol so that it could be done dynamically by

adjusting the limiters to measured traffic vol-

umes and their burstiness. It is possible to im-

prove the DiffServ implementation in these

respects, but these are important scalability

problems in DiffServ as a technical solution to

the QUASI-model. We should stress that the

QUASI-model requirements of class differentia-

tion in some way and ability to receive good

quality are very natural from the business point

of view for a service of several quality classes.

A simple solution to the class differentiation is

to offer only two classes and best effort. Then

class differentiation should be easy. QUASI-

MODO wanted to offer more classes as techni-

cally the possible number of different classes is

quite large in DiffServ.

4.2 IntServ Concerns

This paper describes the QUASI-IntServ imple-

mentation. IntServ is not a natural choice for the

QUASI-model: IntServ is end-to-end and the

QUASI-model is MRP-to-MRP. IntServ is also

considered unscalable. While this opinion may

not be permanent, as scalability only needs to be

sufficient to the expected size of the network and

is affected by performance of RSVP, it is gener-

ally thought to be true at least for the near future.

Therefore we had to solve the scalability prob-

lem and the natural way is to group several

RSVP flows together to a reserved pipe. A pipe

is similar to a Virtual Path in ATM: VP can con-

tain several Virtual Circuits. Doing this implies

that we must add admission control to accept a

flow to a pipe. In ATM there is a Source Traffic

Descriptor, but we only have a very rough char-

acterisation of sources by the Application Cate-

gory. It means that the admission control must

be rough. How much sense there is in to creating

a poor man’s ATM in this way can be pondered

on, but if an implementation of the QUASI-

model is made along IntServ, this is probably

the way it would be done.

The laboratory testbed, shown in Figure 3, is

quite useful for describing the QUASI-IntServ

implementation. There are two MRPs, which in

Figure 3 are Linux PCs running RetHat-6.2. The

operator’s core network is made out of CISCO

routers and one Linux PC. It was very good that

we included the CISCO routers into the core net-

work, since in this way we had to solve inter-

working problems of Linux RSVP and CISCO

RSVP. Our method of making reservations be-

tween MRPs would also have worked better, and

we would have overlooked a practical problem,

were it not for the CISCO routers. CISCO

routers namely decode the RSVP flow from an

address in IPv4 and we needed a clumsy address

translation, to be explained in Figure 6.

There is also a Linux PC used as a Management

Server. It collects NPL measurements from the

MRPs and makes the RSVP reservations be-

tween MRPs. The user’s subnetworks are real-

ised as two Linux PCs and two Sun Worksta-

tions running different applications. The network

links are made with 10 Mbit/s Ethernet. Imple-

mentation of the QUASI-IntServ consists of new

software, which was written to the MRPs and to

the Management Server. It is only some source

files of new software, but inserting the software

to the Linux kernel to monitor the NPL parame-

ters required some effort. Figure 4 shows the

architecture of this software.

The user agent registers users to the MRP dae-

mon process with a special registration protocol.

There is a simple admission control where the

MRP daemon estimates from the number of

existing connections whether it can accept a new

connection to a desired AC/QC. The user can

select AC/QC pairs to his application and

Figure 4 Architecture of
QUASI-IntServ software

User agent

processes

Management

server

User network A Provider network User network B

MRP

daemon

process

MRP

daemon

process