Side_1_360

If we were using IPv6, we could set the flowID

in the packet and identify the ClassID with the

flowID. If we were using only Linux routers,

we could decode in all routers the flowID from

the ClassID in the IP-packet. As we are using

CISCO routers and IP v4, there is a problem:

CISCO-routers decode the flow from an address

in IP version 4. In QUASI-IntServ RSVP estab-

lishes a pipe between two MRPs and the core

routers use the address of the user traffic to

decide which flow the packet uses. We had to

replace the original address by an MRP address

and store the original address into the padding

field. We use the padding field also for storing

the time stamp and the Class ID. In the receiving

MRP the original address is restored. This is

made with NAT and surprisingly it is rather fast.

Figure 6 shows the content of the padding field.

There are the necessary time stamp and ClassID,

but for IPv4 we have also stored the original

addresses there. The receiving MRP restores

the original addresses.

The QoS Software converts the QUASI-model

Class to network class or ClassID (CID). The IP-

packet is marked by setting the CID and the

packet is sent forward. If the (protocol, port)-pair

is not in the table, no marking is done.

In the implemented version, the user can access

the service table and select the AC/QC to his

application. A natural way to do this in a real

system is to use a WWW-page for user selection

of the AC/QC, as was done in the DiffServ im-

plementation. Mapping applications to AC/QC

is not an easy matter. We have mapped applica-

tions using the port number and the IP-address

of packets coming to the MRP. There are special

cases that have not been treated: Mbone is IP-

on-IP. It is currently not supported. Separating

RTP traffic from other UDP traffic, such as

DNS, is not treated. The problem is that RTP

does not have a protocol number, nor does it

have a well-known port number. It may be best

to separate other UDP traffic and treat the re-

maining part as RTP traffic and give it good

quality.

The QUASIMODO project made a number of

tests to see if the QUASI-IntServ implementa-

tion works. The test network is very simple hav-

ing only two MRPs, and we cannot say if the

software actually works in a larger network. It

was shown that in the test network it performed

fine, and the dynamic bandwidth allocation

made by the Management server could adopt the

network to changes in traffic load within the

time scale of the bandwidth modifications.

One goal of the QUASI-model was to provide

several classes which have clear differences in

quality. In the QUASI-IntServ implementation

RSVP reservations guarantee the bandwidth

allocations for AC/QC. They are similar to Diff-

Serv in providing quality for an aggregate of

connections, not for an individual user’s flow.

They are a bit better than DiffServ because if the

core network changes, the RSVP reservations

are rerouted. We should not have the problem

with congestion in the core network. However,

do we see class differentiation in this model?

There is a reserved bandwidth for each RSVP

pipe and the routers respect the reservations. If

the offered traffic to a pipe does not exceed the

reserved bandwidth, we will get very good qual-

ity for all classes. Users of flexible sources

(TCP) see the effect of the bandwidth as data

flows slower if there is less bandwidth. Users of

unflexible sources (UDP) would see either good

quality or bad quality depending on the admis-

sion control mechanism. We could overdimen-

sion worse quality pipes by admitting more traf-

fic than could be carried with good quality, or

we could intentionally drop packets just to make

the service differentiation. For QUASI-IntServ

it may be better to use blocking in the following

way. Best effort class is worse than NPL-classes

Source

Address

Dest

Address

Class

Id

Time

Stamp

Dest

Address

Dest

Port

IP

Level

Source

Port

Dest

Port

Transport

Level

MRP Dest

Address

MRP Dest

Port

Figure 6 IP packet structure
after processing in the MRP