Side_1_360

implemented at several places. Basically a single

queue may suffice for each link, being served

according to a first-in-first-out discipline.

As also shown, a separation between forwarding

and routingis made; routing referring to ex-

changes of routing information (by routing pro-

tocols) to set up routing tables, and forwarding

referring to sending packets on according to the

information in the routing tables.

The traffic flows carried by the node may have

different characteristics, e.g. in terms of packet

lengths, bit rates, use of transport protocols, and

so forth. Combining all these in the same buffer

and on the same link may pose additional chal-

lenges, as described in several accompanying

papers in this issue of Telektronikk. Hence, other

service models – Differentiated Services and

Integrated Services – have been defined, as

treated in the following chapters.

4 Differentiated Services

Differentiated Services (DiffServ) is promoted

as a service architecture supporting a scalable

way to achieve relative service and QoS levels in

an IP network. DiffServ operates on aggregated

flows by dividing the traffic flows into a set of

classes. The DiffServ architecture is defined in

[RFC2475], see Figure 16.

This is to support multiple traffic flows between
the same sender and receiver(s) allowing the
application to adapt to congestion. A framework
is stretched out in that document, integrating con-
gestion management for all types of applications
and transport protocols. This is done by main-
taining parameters reflecting the network condi-
tion, like throughput, round-trip delay, etc. and
making this information accessible from the app-
lications through an API as shown in Figure 14.

The main components, as depicted, are the API,
the congestion controller and the scheduler. The
congestion controller adjusts transmission rates
based on estimates of the network condition,
which is obtained from the applications (via the
API). The scheduler divides the bandwidth
amongst the different traffic flows

3 Best-Effort

From the outset a single class of serving IP
packets was present. At the same time this was
referred to as best-effort, implying that each
node along the path was doing its best to trans-
port the packet towards its destination. A fairly
simple router implementation may then be ade-
quate as schematically depicted in Figure 15.

Packets entering the router are to be forwarded
to the output link. Buffers (queues) may be

Figure 14 Framework for

congestion manager, adapted

from [ID_cm]

Figure 15 Schematic

illustration of router

for best effort

HTTP FTP RTP 1 RTP 2

TCP 1 TCP 2 UDP

IP

Scheduler

Congestion

Controller

API

routing

forwarding

input output

routing

protocol

user data