VTT INFORMATION
TECHNOLOGY
Figure 2.
Figure 3.
1.
Figure 4.
Resource Reservation and
Service Quality
Version 3.0
13.12.99
-2–
Resource Reservation and Service Quality
Version history
Version
Date
Author(s)
< 1.0
29.10.98
Jan Lucenius
1.0
11.12.98
Jan Lucenius
1.1
30.12.98
Jan Lucenius
minor changes
1.2
15.1.99
Jan Lucenius
minor changes
2.0
11.3.99
Jan Lucenius
Structure changed – still not final
Jan Lucenius
minor changes
2.1
Description
2.2
20.10.99
Jan Lucenius and
Juha Koivisto
structural changes
2.3
27.10.99
Jan Lucenius and
Juha Koivisto
spelling corrections etc.
2.4
01.11.99
2.5
...9.12.99
Jan Lucenius and
Juha Koivisto
Text about test results and QoS API
included
2.6
10.12.99
Jan Lucenius and
Juha Koivisto
Chapter about experiments and
points to study updated
3.0
13.12.99
Jan Lucenius and
Juha Koivisto
Minor editorial changes. Final
deliverable.
Diffserv chapter reorganised
Inspection status
Accepted by
Contact information
Jan Lucenius
VTT Information Technology
P.O. Box 1202, FIN-02044 VTT, Finland
Street Address: Otakaari 7 B, Espoo
Tel. +358 9 4561, fax +358 9 456 7013
Email: Jan.Lucenius@vtt.fi
Web: http://www.vtt.fi/tte/
Signature
Date
Resource Reservation and Service Quality
-3–
Copyright © VTT Information Technology 1998. All rights reserved.
The information in this document is subject to change without notice and does not represent a commitment on the part of VTT
Information Technology.
End of editable fields
Resource Reservation and Service Quality
-4–
ABSTRACT
The steadily increasing use of internet is reflected in varying quality of service seen from the user pointof-view. The communication has slowed down to a part of the capasity of the communication channel
and especially real-time communication may become unintelligible. Another trend is that internet
provision is becoming more commercial, instead of resource equally available for all almost for free.
For those reasons, different scenarios to provide quality of service or at least different service classes to
the internet have been developed. These developments are here studied, particularly the use of RSVP, but
also alternative or complementary scenarios. The first chapter of this report is an introduction to the
problem and possible solutions. After that, the Intserv framework with use of RSVP is studied, especially
how this concept performs over different kinds of sub-networks The pros and cons with RSVP are
outlined. After that, the Diffserv concept and use of TOS bits are outlined. End-to-end networks with
both diffserv and intserv regions are studied in chapter 4, which also gives some points, on how these
two approaches should be combined. Next, alternative solutions which may improve QoS, but are outside
the scope of the previous concepts, are outlined. Finally, a test scenario for MOSES and points for
further study are specified.
Resource Reservation and Service Quality
-5–
TABLE OF CONTENTS
1 Introduction ...............................................................................................................................................7
1.1 Purpose of this report .................................................................................................................................... 7
1.2 QoS in Internet .............................................................................................................................................. 7
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
What is QoS? ....................................................................................................................................................... 7
Classification of applications / traffic .................................................................................................................. 8
Delay .................................................................................................................................................................... 8
Jitter and Bandwidth ............................................................................................................................................ 8
Data loss .............................................................................................................................................................. 9
1.3 Providing better quality of service into internet ............................................................................................ 9
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.3.9
Integrated services ............................................................................................................................................... 9
RSVP ................................................................................................................................................................... 9
Priority based QoS ............................................................................................................................................... 9
Diffserv .............................................................................................................................................................. 10
DRP ................................................................................................................................................................... 10
Process priorities in the user's workstation ........................................................................................................ 11
AREQUIPA ....................................................................................................................................................... 11
Switching ........................................................................................................................................................... 11
Alternative approaches....................................................................................................................................... 12
2 RSVP and Intserv ....................................................................................................................................13
2.1 Description of RSVP ................................................................................................................................... 13
2.1.1
Intserv ................................................................................................................................................................ 13
2.2 Service commitments .................................................................................................................................. 13
2.2.1
2.2.2
2.2.3
2.2.4
Guaranteed service ............................................................................................................................................. 14
Controlled load service ...................................................................................................................................... 14
Implementation of traffic control ....................................................................................................................... 14
RSVP and charging ............................................................................................................................................ 16
2.3 LANs[1] ...................................................................................................................................................... 16
2.3.1
2.3.2
Ethernet .............................................................................................................................................................. 16
FDDI, Token ring .............................................................................................................................................. 16
2.4 Frame Relay, SDMS [1] .............................................................................................................................. 16
2.5 ATM [3] ...................................................................................................................................................... 17
2.5.1
2.5.2
2.5.3
IPSOFACTO...................................................................................................................................................... 19
Tag switching [1] ............................................................................................................................................... 20
NetFlow switching [1] ....................................................................................................................................... 20
2.6 Mobile connections ..................................................................................................................................... 20
2.6.1
Mobile IP and RSVP ......................................................................................................................................... 20
2.7 Slow connections (Dial-up, PPP) ................................................................................................................ 21
2.8 Reservation styles and scalability of RSVP ................................................................................................ 21
2.8.1
Reservation styles .............................................................................................................................................. 21
2.9 Discussion ................................................................................................................................................... 22
3 Diffserv ...................................................................................................................................................24
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Diffserv........................................................................................................................................................ 24
Use of TOS field in RFC1349 and Mgen .................................................................................................... 25
Diffserv Code points ................................................................................................................................... 26
Assured forwarding ..................................................................................................................................... 27
Expedited forwarding .................................................................................................................................. 28
Interoperability PHB group ......................................................................................................................... 28
Feedback in Diffserv ................................................................................................................................... 28
Bandwidth brokers ...................................................................................................................................... 29
SIMA ........................................................................................................................................................... 30
4 Intserv and Diffserv combined ................................................................................................................32
4.1 Sample Network with Intserv and Diffserv Regions [5] ............................................................................. 32
4.2 QoS API ...................................................................................................................................................... 34
Resource Reservation and Service Quality
-6–
4.3 Bandwidth Broker ....................................................................................................................................... 36
5 Points to study / test setup .......................................................................................................................37
5.1
5.2
5.3
5.4
5.5
5.6
Linux traffic control .................................................................................................................................... 37
Process priorities ......................................................................................................................................... 38
Router priorities .......................................................................................................................................... 39
Intserv .......................................................................................................................................................... 40
Diffserv........................................................................................................................................................ 40
Different methods combined and compared ............................................................................................... 40
6 Summary / Conclusions ..........................................................................................................................42
7 References ...............................................................................................................................................43
Resource Reservation and Service Quality
-7–
1 INTRODUCTION
Networks are steadily becoming faster and new techniques are evolving. At the same time also the
amount of users in internet increases and ever faster computers also utilize the networks more. The
increased load on the network then "eats up" the advantage of the faster technology. This causes longterm variations in the quality experienced by the users. Additionally there are of course short-term
variations. The requirement to introduce different service quality or at least different service classes also
on internet connections rises both from commercial viewpoint, i.e. that the load on the network should be
more reflected in the charging and that some user's traffic could be privilegied according to how much
they pay, and from the needs of the users to ensure good quality for traffic of critical applications. On the
other hand, driven to eccess this may also be the end of internet as a "free data highway" for everybody,
which certainly is one of the main IT accelerator.
1.1 Purpose of this report
The aim of this report is to

give an overview on different techniques to provide QoS for IP connections

study when resource reservation is useful, particularly when the connection spans different kinds of
sub-networks

specify possible tests setups for the MOSES project and possible future projects.
As the IP test network in VTT/TTE as well as the Mediapoli network will be built using Cabletron
Smartswitch technology, and the existing internal ATM network in VTT/TTE uses FORE switches, etc.
references especially to these equipment and their management software are inserted at some places in
the text. However this does not mean that FORE or ATM based approaches at all really would be
implemented, at least not in the MOSES project.
1.2 QoS in Internet
1.2.1
What is QoS?
Quality certainly means different things to different people. In the case of communication the definition
of QoS also depends on where the viewpoint is focused. For the information consumer, the point is to
receive the information he wants to access correctly and/or intelligibly and as fast as possible, or at the
correct time, depending on the application. Another point of quality is also that connections can be
established as fast and reliably as expected.
All bits transferred are not equally important. For example a few bits answering the question "are you
alive" or about some business worth millions are considerably more valuable than an email message in
general or the bits in a video stream. In general, the more bits are transferred, the less we want to pay per
bit. Still, the purely technical requirements on the transfer channel for the video stream are considerably
higher.
The quality requirements of the transferred information are reflected on the quality requirements on the
communication channel, or reverse, constraints in the communication channel result in reduced quality
on the received information or in some cases, that some information cannot be transferred at all. The
bottlenecks may of course also be in the sender's and receiver's servers/terminals themselves, and it may
be difficult to tell the reason for bad quality of information. This study focuses though on the quality
parameters of the network, like bandwidth, delay, packet loss probability etc. Of course there may be
other views on quality of service which are more or less outside the scope of this report.
Resource Reservation and Service Quality
1.2.2
-8–
Classification of applications / traffic
Roughly applications can be divided into real-time and non-real-time (data) applications. Non-real-time
applications (e.g. ftp) are typically not very sensitive to delay but require error-free transfer. Usually TCP
with its resending mechanism takes care of that. When transferring huge files, the available bandwidth
should also be utilized as well as possible. With typical real-time applications the situation is reversed.
Some erroneous or lost data may be tolerated. There are different categories of real-time applications
regarding their sensitivity to delay, jitter and bandwidth. Those parameters are studied further below.
The communication configuration (point-to-point, multicast, multipoint-to-multipoint, etc.) will also have
an impact on the quality requirements. Especially non-realtime communication may also be of
connectionless type, consist of (rather short) datagrams, like e.g. http, or be more connection oriented,
like telnet or ftp. The division between connectionless and connection oriented communication is not
very clear, as it varies from layer to layer. However, it is clear that the quality of service requirements are
different and perhaps more critical for hugh stream-like transfers than for short messages transferred at
random from here and there. But even in transaction processing, where short messages are sent in both
directions, delays may be quite critical. Another, maybe less important classification criteria is whether
the communication is sender or receiver initiated. Such aspects may have an impact on how the required
service quality can be provided by the network.
Real-time communication, which generally means audio and/or video may be divided into playback
applications and interactive applications. Depending on the coding, the applications may also require an
output at fixed bit rate or the bit-rate may vary.
The applications in Integrated Services architecture [22] are divided into real-time applications and
elastic applications. Elastic applications are the typical ones for internet: Telnet, FTP, X etc. . Real-time
applications, in turn are described as either intolerant or tolerant, depending on their sensitivity to loss of
fidelity.
1.2.3
Delay
Delay means here the overall delay (latency) between the retrieving/generation of the information at the
sender's side and the storing or reproducing of it at the receiver's side. Totally it includes such as
encoding delays or fetching delays (depending on whether the information was stored in advance),
transferring delay (through the whole path) and decoding delay.
If the maximum delay was known in advance, all packets could be buffered, and the playback point
(delay between the sent packet and the replayed one) of the application set to exactly the maximum delay
so no packets would be late or lost. However, a trade-off between interactivity and playback quality has
to be considered in determining the playback point. For interactive communication like in an audio
conference, the total delay should not exceed 0.25 s. [1]
The absolute delay doesn't matter in playback applications, where the roles of sender and receiver are
fixed, for example in a TV transmission. Some video tools support this distinction and allow the user to
switch between interactive mode and lecture mode.
1.2.4
Jitter and Bandwidth
Jitter is specified as the variation in delay between different information packets.
Jitter and bandwidth are two quality of service (QoS) parameters that need to be controlled to support
QoS for playback applications. Enough bandwidth must be available on the path for the average transmit
rate plus a little extra so bursts can be cleared quickly. If the bandwidth is not sufficient, packets are
dropped as soon as the queuing capacity is exhausted.
Resource Reservation and Service Quality
-9–
In playback applications all incoming data is buffered to remove jitter. The signal is then replayed at
some designated playback point. Well-known playback applications are the video tool vic and the audio
tool vat. Adaptive applications move the playback point so that the signal is replayed as soon as possible
while the data loss rate is acceptable. Thus, adaptive playback applications work well on moderately
loaded datagram networks.
The bandwidth requirement may not be fixed, but some "rate-adaptive" playback applications may
change their coding scheme according to network service available. Applications like CU-SeeMe and
RealPlayer can retrieve both intelligible audio and video even at modem speed. RealPlayer sites often
provide different streams for different speeds.
1.2.5
Data loss
In some cases buffering according to the worst case delay may also imply low network utilization [22]. If
the application is tolerant to some packet loss, there is then a trade-off between network utilization,
quality and delay.
If the net is heavily loaded, congestion may result, leading to jitter and packet loss. At certain times of
the day, some MBone audio multicasts are unintelligible because of more than 30% packet loss [1].
1.3 Providing better quality of service into internet
The internet spans over subnetworks using different technologies. The performance of the data transfer
depends much on how the different flows are handled within these networks, e.g. access mechanisms,
queueing mechanisms etc. used. A simple or even complicated approach for end-to-end QoS does not
help alone. Even these approaches are not yet ready. This report gives an overview but can naturally not
answer all questions, the research topic is nearly endless.
1.3.1
Integrated services
The original internet service model is very simple and it does not provide any support for quality of
service (QoS) or bandwidth sharing in the network. The Integrated Services, described in RFC 1633 [22]
proposes to extend the service model with two additional categories of service: guaranteed and controlled
load in addition to the traditional best effort service, in order to support also real-time and other
performance critical applications.
1.3.2
RSVP
Resource ReSerVation Protocol (RSVP) , described in RFC 2205 [8] is a part of this concept. "The
RSVP protocol is used by a host to request specific qualities of service from the network for particular
application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS)
requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the
requested service." RSVP requests will result in resources being reserved in each node along the data
path, if the nodes can handle reservations, and the resources are available, of course.
1.3.3
Priority based QoS
Another approach to implement QoS, is to use priorities alone, especially if guarantees are not required.
In internet routers (here the Cabletron SmartSwitch Router is used as example [35]) QoS policies can be
set according to the following parameters:

Layer 2 (bridging layer)
 MAC addresses (source and destination)
 VLAN ID
Resource Reservation and Service Quality
- 10 –

The priorities (7 levels) can be set on specific incoming ports.
 Layers 3 (IP)
 IP addresses (source and destination)
 Type of service (TOS)
 incoming interface
 Layer 4
 UDP/TCP port (source and destination)
 protocol (TCP or UDP)
In Cabletron SmartSwitch Routers (SSR) four priority queues are implemented: control, high, medium
and low. Priority scheduling can be either strict (default) where higher priority throughput is assured at
the expense of lower ones, or weighted fair queuing, where the throughput for all four priorities is
distributed based on percentages.
The UDP/TCP port identifies the application and is thus more usable for QoS classification than for
example address based policies. With the exception of TOS, the other parameters would assume that
applications that require certain QoS are always run from the same addresses. It is possible to request the
administrator to adjust the priorities for specific address, TCP/UDP port or TOS settings. This, however,
seems as a very "primitive" approach.
1.3.4
Diffserv
Diffserv [41, 5] is another concept aimed to differentiate traffic in internet. It does not require end-to-end
signalling. In the differentiated services traffic entering a network is classified and possibly conditioned
at the boundaries of the network, and assigned to different classes or behaviour aggregates. Each
behaviour aggregate is identified by a single DS codepoint, i.e. value of the TOS field in the IP header.
Within the core of the network, packets are forwarded according to the per-hop behaviour (PHB)
associated with the DS codepoint.
According to the Diffserv architecture [41] services can be implemented through the following
components:

packet classification at the edge of the stub Diffserv networks;

packet marking or packet re-marking at network boundaries (the DS -differentiated services – field is
used for the service identification);

packet forwarding inside a given Diffserv domain according to the current content of the DS;

traffic conditioning at the network boundaries according to the requirements of each service, e.g.
monitoring, policing and shaping.
There are still technical problems with DS bits ( TOS bits). First, they are handled differently in
different networks, depending on which if any Diffserv approach is used and even on choices of the
specific ISP. For the second, current applications cannot set the TOS bits. Interfaces for setting TOS bits
are available for Linux [51] and in Microsoft Windows systems. In Windows 2000 the GQoS API is
included [52], for Windows 95 and NT4, there is the QoS API by Intel available for Winsock 2 [53].
1.3.5
DRP
Dynamic Reservation Protocol (DRP) is another protocol for the same purpose as RSVP. The main
difference is that DRP is sender based whereas RSVP is receiver based. DRP is on development stage,
i.e. implementations do not yet exist, at least not available in public.
Resource Reservation and Service Quality
1.3.6
- 11 –
Process priorities in the user's workstation
In MOSES project it has also been studied whether flows could be prioritized in the user's workstation in
the case where there are two or more simultaneous information flows. If the reception of these flows are
handled by different software programs, the easiest way is to adjust the priorities of the corresponding
processes. When fewer TCP acknowledgements are sent from the slower process, this should cause the
sender to slow down. In the MOSES tests, the difference was clearly noticeable only when additional
load was put on the processor. In that case, contradictory to what one would expect (Juha's paradox), the
quality of the higher prioritized flow was considerably improved on the cost of the other flow [54].
1.3.7
AREQUIPA
Application REQusted IP over ATM [17] specifies a method for allowing ATM-attached hosts that have
direct ATM connectivity to set up end-to-end IP over ATM. This allows the requesting applications to
benefit from ATM's ability to guarantee the quality of service (QoS). Arequipa can be used to implement
integrated services (INTSERV) over ATM link layers.
1.3.8
Switching
Internetworking vendors have announced several new routing solutions that combine network layer
routing with link layer switching. Decisions are then made per flow, not per packet, and most network
layer processing can be eliminated. Promising approaches are NEC's IPSOFACTO, Ipsilon Networks' IP
Switching as well as Cisco Systems' Tag Switching and NetFlow Switching.
Switching is not as such a technique which give quality differentiation, but improves performance in
general compared with conventional router technique. In particular, the mismatch between the IP
protocols and ATM are handled with new switching techniques.
see also [18, 19, 1 , 21 ].
 IP switching [1]
IP switching is a technology developed by Ipsilon Networks ([23], [24]). It is designed for ATM-based IP
networks. Support for frame relay is planned. IP switching aims to optimize IP throughput by switching
most traffic across the ATM network, bypassing the routing infrastructure.
IP switching works as follows. Each IP node sets up a default virtual channel on each of its ATM
physical links. This virtual channel (VC) is used to forward packets in the normal, non-optimized
manner. An IP Switch Controller decides which of the packets arriving on the default VC belong to a
long-lived flow, like ftp, telnet, WWW or real-time data. Long-lived flows are worth optimizing by
giving them their own virtual channel and switching them on the ATM level. Short-lived traffic (e.g.
DNS queries, SNMP queries, SMTP data) continues to be forwarded on the default VC. A flow is
characterized by a source - destination pair and other header fields as configured. Once the IP Switch
Controller has identified a flow, it asks the upstream IP node to send that traffic on a new ATM virtual
channel. Independently, the downstream IP Switch Controller will have identified the flow in the same
way and requests that the traffic be sent on a new virtual channel. At this point, the flow does not use the
default VC any more. It is isolated to a particular input channel and a particular output channel. The flow
can then be optimized by ``cut-through'' switching in the ATM hardware, bypassing the routing software
and the associated processing overhead. When a flow is switched on the ATM level, packets do not need
to be reassembled from cells. This decreases transmit delays. The general concept is that long-lived flows
are switched on the ATM level while short-lived traffic is routed as usual.
Resource Reservation and Service Quality
- 12 –
 Tag switching [1]
Tag switching is a proprietary technology proposed by Cisco Systems ([25]). Among other goals, it aims
to simplify the forwarding decision of routers by using a label-swapping technique, thus improving
performance. Tag switching can be implemented over many media types and is independent of network
layer protocols.
Tag switching works as follows. At the edge of a tag-switched network, a tag is applied to each packet. A
tag has only local significance. When a packet is received by a tag switch (a router or ATM switch with
tag switching software), the switch performs a table look-up in the tag table (Tag Information Base, TIB).
An entry in the tag table consists of an incoming tag and one or more tuples of the form (outgoing tag,
outgoing interface, outgoing link level information (e.g. MAC address)). The tag switch replaces the tag
in the packet with the outgoing tag and replaces the link level information. The packet is then sent out on
the given outgoing interface. The Tag Information Base is built at the same time as routing tables are
populated, not when the tag is needed for the first time. This allows flows to be switched starting with the
first packet.
Label swapping is much faster than routing because the network layer is not involved. Switching
bypasses the router's processor. Label swapping can be done in constant time, because it is exact match.
In contrast, a routing table lookup is best match and thus in the order of O(log n). Tag switching is
criticized by some experts because IP packets are not left intact.
 IPSOFACTO
IPSOFACTO (IP Switching Over Fast ATM Cell Transport) is a scheme developed by NEC for mapping
IP flows directly over ATM switches [4, 30, 36]. The establishment of a cell-level switched path is a
purely local decision. This approach is different than CLIP, where QoS renegotiation would need new
VC setup. IP control messages are never switched in IPSOFACTO but are sent and received on a
predefined control VC and will therefore be forwarded through the switch controller.
NEC and GMD Fokus have implemented RSVP on IPSOFACTO, with different classes from the Intserv
model appropriately mapped to ATM traffic classes. Thus, the ATM cell-scheduling hardware is used to
provide QoS guarantees to IP flows. The implementation has been completed and some results are
available.
ITHACI (Internet and ATM: Experiments and Enhancements for Convergence and Integration) is a twoyear ACTS project of field trials aimed at refining the way ATM integrates IP traffic. It started in March
1998. The project evaluates existing and new IP switching solutions: a new architecture to be developed
by Alcatel-Bell, tag-switching as developed by Cisco and IPSOFACTO as developed by NEC. Each
technology will be enhanced with multicast, QoS, host mobility and resource management.
1.3.9
Alternative approaches
Since LAN bandwidth is relatively inexpensive, it is probably cheaper to add bandwidth than to have a
complex reservation mechanism. There are three possibilities to deal with QoS for future LANs:
1. new hardware that supports QoS guarantees.
2. upgrade LANs to support priorities and deploy the link layer reservation mechanism as proposed by
the ISSLL working group.
3. over-provision networks and do without guarantees.
Resource Reservation and Service Quality
- 13 –
2 RSVP AND INTSERV
2.1 Description of RSVP
Resource reservation protocol (RSVP) is described in RFC 2205 [8]. It works in short as follows.
Each sending RSVP host sends PATH messages describing the traffic characteristics for the unicast or
multicast sessions (sender Tspec). RSVP capable routers along the way add path state to the path
messages. Receivers of the data flows send back RESV messages, which are transferred towards the
sender of the path message through the same routers in the reverse direction. (Next Hop Resolution
Protocol (NHRP) may be used to find the next router along the path for the PATH and RESV messages,
see [19 , 20 , 32]). The RESV messages specify the characteristics of the data flow (flowspec) that the
receiver requests from the network. Each router along the path checks whether the request can be
accepted, i.e. the requested resources provided. If so is the case, the RESV message is forwarded
upstreams. This will result in resources being reserved in each node along the data path, if the nodes can
handle reservations, and the resources are available, of course. . If there is a problem, a RESV ERROR
message is sent to the sender of the RESV message.
Generally PATH and RESV messages are resent with 30 s interval (for each session). If the reservation
state is not continuously updated, the routers should clear the reservations. Reservation states may also
be immediately cleared using PATH TEAR message (sent by the information sender) or RESV TEAR
message (sent by the information receiver) when the application ends.
A survey of RSVP/QoS implementations is presented in [30]
2.1.1
Intserv
Traditionally, IP service provides the same quality of service to every packet. Integrated Services expand
this service model so that applications can choose an appropriate service ( [22]). The services that are
specified so far are best-effort service, guaranteed service (specified in [26]) and controlled load service
(specified in [27]). Other services, for example controlled delay, have been proposed but haven't gained
acceptance.
Important elements of Intserv are [6] :
 parameters for forwarding mechanisms that are appropriate for real-time information
 a setup protocol that allows establishing special forwarding treatment for real-time information flows
( RSVP),
 a transport protocol for real-time information (RTP/RTCP).
Integrated Services also include controlled link sharing which addresses the sharing of link bandwidth for
example during congestion.
At each hop in an intserv network, the generic intserv service requests are interpreted in a form
meaningful to the specific media. For example, at an ATM hop, a virtual curcuit (VC) of the correct type
(CBR, ABR or VBR) is established. At an 802.1 hop, the intserv service type is mapped to an appropriate
802.1p priority level. [5]
2.2 Service commitments
Because different kind of networks are specified by different standards organizations, the provision of
service commitments require a separate study for each kind of link in a heterogenous network.
Resource Reservation and Service Quality
2.2.1
- 14 –
Guaranteed service
Guaranteed service is used by rigid intolerant applications. It provides a firm bound on delay and no
packet loss for a flow that conforms to its token bucket specification. Guaranteed service does not
attempt to minimize jitter. It merely controls the maximum queuing delay. An application can then set its
playback point so that all packets arrive in time.
In [1] it is believed that this estimated total worst-case delay is not well suited as a quantitative
guarantee.
First, it is often impossible to estimate upper limits on delay in a network element. The worst case may or
may not be known. For instance, the maximum waiting time for a slot on a time-sliced link can be easily
calculated. Also, the maximum service interruption caused by a routing update will be known. In other
cases, the worst case is caused by unexpected behaviour or events. Unexpected delays cannot be
estimated, resulting in overly optimistic worst-case delays and possible violation of reservations.
Second, it is impossible to control link layer queuing or to estimate delay bounds for link layer elements.
Link layer devices are transparent for network layer protocols, but queuing at the link level might lead to
significant delay variation. On most legacy LANs, it is impossible to provide service guarantees.
Third, the total worst-case delay of the path is the sum of the individual worst-case delays. Although it is
very unlikely that a packet experiences worst-case delay in all network elements, a guarantee must take
this case into account. The total worst-case delay can easily add up to several seconds. This will render
the service useless. It is hard to imagine an application that is willing to accept delays of several seconds
but cannot tolerate any packet loss. A reliable TCP connection would be more appropriate for such
applications.
2.2.2
Controlled load service
Controlled load service is the service designed for adaptive, tolerant applications. No quantitative
guarantees are given, but the service under overload is about as good as best-effort service on a lightly
loaded network.
A client provides the network with the token bucket specification of the traffic it will generate. The
network ensures that enough resources will be available for that flow, as long as the flow conforms to the
specification. Queuing delays are not significantly larger than the time it takes to clear a maximum burst
at the requested transmission rate.
2.2.3
Implementation of traffic control
In addition to the reservation setup protocol, the reference implementation framework proposed in [22]
includes three other components: the packet scheduler, the admission control routine and the classifier.
These three components implement the traffic control. See Figure 1!
The packet scheduler manages the forwarding of different packet streams using a set of queues and other
mechanisms like timers. It is implemented at the output driver level of a typical operating system, and
corresponds to the link layer protocol. The details of the scheduling algorithm may be specific to the
particular output medium.
The classifier maps the incoming packets into different classes, according to parameters in the protocol
headers, incoming ports, etc.. Packets in the same class are treated equally by the packet scheduler. The
implementation of the classes are local to the router.
Admission control implements the decision algorithm that a router or host uses to determine whether a
new flow can be granted the requested QoS without impacting guarantees. Admission control is invoked
at each node to make a local accept/reject decision, at the time a host requests a real-time service along
some path. The admission control algorithm must be consistent with the service model.
- 15 –
Resource Reservation and Service Quality
_____________________________________________________________
|
____________
____________
___________
|
|
|
|
| Reservation|
|
|
|
|
|
Routing |
|
Setup
|
| Management|
|
|
|
Agent
|
|
Agent
|
| Agent
|
|
|
|______._____|
|______._____|
|_____._____|
|
|
.
.
|
.
|
|
.
.
_V________ .
|
|
.
. | Admission| .
|
|
.
. | Control | .
|
|
V
. |__________| .
|
|
[Routing ]
V
V
|
|
[Database]
[Traffic Control Database]
|
|=============================================================|
|
|
|
_______
|
|
|
__________
|
|_|_|_|_| => o
|
|
| |
|
|
Packet
|
_____
|
|
====> |Classifier| =====>
Scheduler
|===>|_|_|_| ===>
|
| |__________|
|
_______
|
|
|
|
|
|_|_|_|_| => o
|
| Input |
Internet
|
|
| Driver |
Forwarder
|
O u t p u t
D r i v e r
|
|________|__________________|_________________________________|
Figure 1.
Implementation Reference Model for Routers [22]
A possible implementation framework is given by the Integrated Services working group [1]. The
scheduling algorithm weighted fair queuing (WFQ) is an important building block. WFQ is used to
isolate flows from each other. Each WFQ flow has a separate queue and packets are scheduled so that
each flow receives a constant fraction of the link bandwidth during congestion.
Weighted round robin is only fair in terms of packets sent by each flow, not in terms of bandwidth used
by each flow. For that reason, weighted round robin cannot be used to isolate flows, and the more
complex WFQ algorithm is used.
Figure 2.
Hierarchical traffic control
Resource Reservation and Service Quality
- 16 –
At the top level, each guaranteed service flow gets its own WFQ queue (figure 2). Thus, guaranteed
flows are strictly separated from each other and from the rest of the traffic. All other traffic is assigned to
a pseudo WFQ flow. Within this flow, controlled load traffic and best-effort traffic are separated by
priority. The network only admits a certain amount of controlled load traffic to ensure that best-effort
service is not completely preempted. Within the controlled load class, subclasses with different delay
bounds are provided, separated by priority. To clear bursts, a higher-priority class can temporarily
borrow bandwidth from a lower-priority class. Thus, priorities allow sharing of bandwidth in one
direction and isolation in the other direction. Within each subclass, the overall delay is minimized by
simple FIFO scheduling. Flows within a subclass should all have similar traffic characteristics, so when
there is a burst in one flow, the other flows can share the delay without being too much delayed
themselves.
Class based queueing (CBQ) is also commonly used together with RSVP.
2.2.4
RSVP and charging
In [47] an approach for including charging in RSVP is presented. Information about prices and other
charging details are included in the POLICY_DATA objects of the RSVP messages. The approach used
is called Edge pricing which means that the user should be charged only by the first network provider.
2.3 LANs[1]
For resource reservation, link layer switches also need to have bandwidth allocators that keep track of
reservations. A protocol is needed so bandwidth allocators can talk to each other. A requester module
translates a layer 3 reservation into a layer 2 reservation. It provides the interface between a layer 3
reservation protocol (such as RSVP) and the bandwidth allocator. Although the complexity of link layer
resource reservation can be reduced by centralizing part of the mechanism, it still seems to be a
considerable overhead.
2.3.1
Ethernet
It is obvious that shared media with CSMA/CD access protocols cannot provide any service guarantees.
CSMA/CD makes it impossible to predict when and how much a station will be able to send. The current
trend in ethernet networking is ``micro-segmentation'', where each host has its own ethernet segment.
This increases the bandwidth available for each host. However, without priorities, reserved and
unreserved flows cannot be separated.
The IEEE is currently working on standards for expedited traffic classes in bridges/switches. The
proposed standard requires three priority bits in the ethernet frame header. On shared ethernets with
priority, at least some statistical guarantees can be given. To provide deterministic guarantees, ethernet
would have to be deployed in a switched full duplex topology with priority. This means that there are
only two devices on a segment, the host and the bridge/switch, and there is no access contention.
2.3.2
FDDI, Token ring
FDDI and token ring offer priorities in their current form. Thus, they have the potential to support QoS
guarantees. To use this potential in subnetworks, a signaling mechanism is needed. The ISSLL working
group (Integrated Services on Specific Link Layers) in the IETF describes a framework in [28].
2.4 Frame Relay, SDMS [1]
What looks like a dedicated point-to-point link to a router might actually be just a virtual point-to-point
link in a frame relay network. A router knows the capacity of the physical link, but it is not aware of the
service contract with the frame-relay network. Each frame relay PVC has a CIR (Committed Information
- 17 –
Resource Reservation and Service Quality
Rate) associated with it. The network will give priority treatment to this amount of bandwidth. Traffic
exceeding the CIR is marked ``discard-eligible''. The portion of reserved traffic that exceeds the CIR is
likely to be dropped, violating the reservations. Integrated Services routers will need some kind of CIR
discovery to avoid this disastrous situation.
Another issue is queuing on the link layer. While routers see dedicated serial links, the reality might be a
shared network, such as a frame relay network. Queuing delays in frame relay switches are not under
control of any network layer mechanism. Contention is not uncommon in frame relay networks, and the
CIR is not a 100% bandwidth guarantee. This means that Integrated Services network elements cannot
control all queuing delays and packet losses. They can't even estimate the delays, because they don't see
link layer switches. In the case of guarantees service, this will either result in under-estimated total delay
estimates (if delay in the frame relay switch is not taken into account) or in over-estimated worst-case
estimates (if the worst-case delay of the frame relay switch is taken into account). Controlled load will
promise service as in a lightly loaded network, although queuing at frame relay switches can cause
significant delay variation.
A similar problem arises with centralized switched technologies like SMDS (Switched Multimegabit
Data Service). The way switches deal with temporary overload is queuing.
2.5 ATM [3]
There are some basic differences between the RSVP/INTSERV model and ATM. In RSVP the quality
requirements are stated by the receiver, from which RESV messages are sent through the routers among
the path against the sender. In ATM, the required QoS is requested by the sender. In ATM the
reservations are also explicitely done for a VC at the connection setup, and are maintained until the
connection is released, whereas in the RSVP concept, the routers starts a timer, which must be
continuously updated with PATH and RESV messages. If the messages are left out, and the timer
expires, the resources are freed for other connections. The update requirement means also, that
applications can change their QoS dynamically, whereas the reservations by ATM are static over the
duration for the connection.
In ATM, VCs are also set up between the sender and the receiver, and are not later possible to be shared
by other receivers of the same data flow. RSVP allows more than one receivers of the same data flow to
share the same bandwidth (multicast and broadcast connections). RSVP is also assigned with
heterogenity of applications in mind. The differences are summarized in table t1.
Table t1 Differences in QoS approaches between ATM and RSVP
QoS is requested
Reservation is
variable QoS
connection management
reservation styles
heterogenity
scalability
RSVP
by receiver
separated from routing
dynamic
dynamic (soft states)
fixed and shared
supported
merging
ATM
by sender
concurrently with VC-setup
static
static (hard states)
fixed
not supported
?
In cases where there are several LISes supported in the same ATM network, there is a problem with
RSVP. As the path is setup between the sender and receiver on hop-by-hop basis, it may not pass directly
through the ATM network, but through several routers of the different LISes. Figure 3 outlines the
problem. This would be a vaste of resources both in the ATM switches and in the routers. The
intermediate routers would also cause unnecessary extra delay to the data. To overcome this problem,
shortcut methods over the ATM network should be used (see figure 4 !).
- 18 –
Resource Reservation and Service Quality
Figure 3.
Several LISs in an ATM network
Figure 4.
VC shortcut
In ATM any common standard multicast solution doesn't exist. Trials are MARS and the FORE-specific
SPANS protocol. Point-to-multipoint connections can, however, be used by RSVP. Suppose there is a
connection between A and B in figure 5. If a RESV message is received from C, A could add this to the
multicast session using the ADD-PARTY message. However, each leaf would get the same QoS, which
is in conflict with the heterogenity requirement of RSVP. If there are a lot of receiving nodes, also the
signalling could cause additional load on A.
In ForeThought 5.0 [38] it is possible to specify different QoS types (CBR, VBR, UBR, shared) and
parameters for LANE connections. It is also possible to specify a treshold in cells per second where VC
shortcuts are established. LANE VC shortcuts apply inside the ELAN. For connections to destinations
outside the host's ELAN, MPOA shortcuts can be established when traffic exceeds the MPOA treshold.
- 19 –
Resource Reservation and Service Quality
MPOA shortcuts do not apply QoS parameters. The flows to which MPOA and LANE VC parameters
apply are described by destination IP address, protocol used and destination port number.
E
F
A
VC shortcuts
B
C
Figure 5.
2.5.1
Point-to-multipoint session
IPSOFACTO
IPSOFACTO (IP Switching Over Fast ATM Cell Transport) is a scheme developed by NEC for mapping
IP flows directly over ATM switches [4, 30, 36]. This approach is different than CLIP, where QoS
renegotiation would need new VC setup. IP control messages are never switched in IPSOFACTO but are
sent and received on a predefined control VC and will therefore be forwarded through the switch
controller. As a result of processing these control messages, a per-flow forwarding state is established.
The RECV messages trigger a call admission procedure at the controller followed by mapping the IP
flow to an appropriate cell-level QoS within each switch. The merging of RSVP requests as well as QoS
renegotiations by local modification of ATM-level traffic shapers is possible.
IPSOFACTO supports IP multicast which is a fundamental requirement for efficient RSVP-based service
provision. The direct use of IP multicast protocols on top of ATM entirely eliminates the need for
complex protocols emulating a broadcast network on top of a non-broadcast multiple access (NBMA)
networks.
Currently, the mapping of RSVP over IPSOFACTO still suffers some limitations. First, the GSMP
protocol, which is used to control the ATM hardware, has no support for QoS and a second version of the
protocol with QoS enhancements is still to be defined. Second, only a limited support of RSVP
reservation styles is possible, due to the lack of multipoint-to-point VC in the ATM hardware. Third, the
receiver heterogeneity needs to be limited to avoid exhaustion of the VC space and excessive amounts of
identical data travelling on different VCs.
NEC and GMD Fokus have implemented RSVP on IPSOFACTO, with different classes from the Intserv
model appropriately mapped to ATM traffic classes. Thus, the ATM cell-scheduling hardware is used to
provide QoS guarantees to IP flows. The implementation has been completed and some results are
available.
Resource Reservation and Service Quality
2.5.2
- 20 –
Tag switching [1]
To ensure proper tag allocation, all routers/tag switches on the path must be RSVP capable. The property
of transparent non-RSVP clouds is lost. At a non-RSVP capable tag switch, the chain of labels assigned
to a reserved flow breaks and the tag switch has to apply a tag using destination-based routing. This
causes delay, because the packet is routed, not switched. Moreover, once packets follow the best-effort
chain of tags, tag switches ``blindly'' switch them to their destination as best-effort traffic, even though
downstream tag switches might be RSVP-capable and have allocated tags for that flow. For that reason,
either all or none of the routers in a tag-switched network should be RSVP capable.
Another problem is setting up path state. Path messages are always sent to the same destination address
as the data. Before a reservation is set up, path messages are switched on the best-effort chain of tags
according to destination-based routing. Because the goal of tag switching is to bypass network layer
routing, tag switches just look at the tags, not at packet headers. Unless otherwise told, tag switches don't
know whether a packet is a data packet or an RSVP path message that should cause them to set up path
state. To solve this problem, the tag edge router must assign a special tag to path messages. One approach
would be to use a special tag that means ``Do not tag-switch'', so routers are forced to look into the
packets and can take the appropriate action.
When tag switching is implemented over ATM, VC identifiers are used as tags. Tag switching is then
done on the ATM level. All heterogeneity issues described for IP switching also apply to tag switching.
Most other media allow different QoS on each branch of a multicast tree, thus heterogeneous reservations
don't present a problem.
2.5.3
NetFlow switching [1]
Netflow switching is as another technique developed by Cisco Systems to reduce per-packet overhead
associated with routing. The idea of NetFlow switching is to identify end-to-end flows and then apply
these services to the flow, not to single packets.
To speed up routing of RSVP flows, packet scheduling on a per-flow basis would be most useful. Cisco
plans to offer this in the future by integrating NetFlow switching and weighted fair queuing. NetFlow
switching could also be a first step towards per-flow accounting.
2.6 Mobile connections
2.6.1
Mobile IP and RSVP
Mobile IP (MIP) [55] enables the host to move between different subnetworks. The principle is in brief
as follows. While the mobile workstation is in its home network, the messages to it are routed through
the home agent (HA) directly. When it is in an other domain, it must select a foreign agent (FA) and
register its 'care of address' (COA) with the HA through the FA. When a correspondent node (CN = the
other end of the communication) sends a packet to the mobile host, the packet first arrives at the HA. The
HA forwards the packet via the FA to the mobile host's COA using tunneling. Generally the packets from
the mobile host to the CN are, however, not sent via the tunnel and the HA, but directly to the CN. The
extra hops caused by routing each packet through the HA have been considered a problem already from
the start but so far no solution for that is not foreseen before IPv6. This problem does not apply if the
mobile node is 'at home' as it then uses its permanent IP address.
Let us think of what that means for resource reservations using RSVP. The PATH messages are tunneled
via the HA, whereas the RESV messages would be passed directly. Thus, reservations would either be
rejected (because they have never seen the PATH message) or at most, accepted at the routers that are
used in both directions, unless even those will complain that the route or interface differs. At least no
reservations would be made through the tunnel.
Resource Reservation and Service Quality
- 21 –
The solution is to combine MIP and RSVP using a special arrangement, where also the RESV messages
are sent back via the HA. There exist an implementation for Linux where this has been done [56].
2.7 Slow connections (Dial -up, PPP)
Real-time applications over slow links such as modem or ISDN links are addressed in the ISSLOW
architecture [6]. There are at least three problems:
 the amount of overhead in the protocols; for example HDLC/PPP - IP - UDP - RTP: 44 bytes
 the long delay, 1500 bytes packet at 28.8 kbit/s takes 400 ms
 negotiation protocols between routers (or hops and routers)
A compression algorithm for Ipv6 has been developed by Degermark et. Al [33], which compresses
successive IP headers. An other compression scheme is described by Casper and Jacobson [34], which
acts on IP/UDP/RTP. Both operate on hop-by-hop. See also PPP-multilink protocol [31].
Main components of isslow are:
 a real-time encapsulation format for asynchronous and synchronous low-bitrate links,
 a header compression architecture optimized for real-time flows,
 elements of negotiation protocols used between routers (or between hosts and routers), and
 announcement protocols used by applications to allow this negotiation to take place.
The compressor can operate best if it can make use of information that clearly identifies real-time
streams and provides information about the payload data format in use. In routers, this consent must be
installed as router state; in hosts, it must be known to their networking kernels. Sources of real-time
information flows are already describing characteristics of these flows to their kernels and to the routers
in the form of TSpecs in RSVP PATH messages. Since these messages make use of the router alert
option, they are seen by all routers on the path.
Additional RSVP objects could be defined that are included in PATH messages by those applications
that desire good performance over low-bitrate links.
As compression techniques will improve, a negotiation between the two peers on the link would provide
the best flexibility in implementation complexity and potential for extensibility. The peer routers/hosts
can decide which real-time packet streams are to be compressed, which header fields are not to be sent at
all, which multiplexing information should be used on the link, and how the remaining header fields
should be encoded. PPP, a well-tried suite of negotiation protocols, is already used on most of the lowbitrate links and seems to provide the obvious approach. Cooperation from PPP is also needed to
negotiate the use of real-time encapsulations between systems that are not configured to automatically do
so.
2.8 Reservation styles and scalability of RSVP
2.8.1
Reservation styles
The following styles are currently defined ([8]):
Resource Reservation and Service Quality
- 22 –
 Wildcard-Filter (WF) Style
A WF-style reservation creates a single reservation shared by flows from all upstream senders. The
reservation is propagated upstream towards all sender hosts, and it automatically extends to new senders
as they appear. Symbolically, a WF-style reservation request can be represent by:
WF( * {Q})
where the asterisk represents wildcard sender selection and Q represents the flowspec.
 Fixed-Filter (FF) Style
An FF-style reservation request creates a distinct reservation for data packets from a particular sender,
not sharing them with other senders' packets for the same session. The representation for an elementary
FF reservation request is:
FF( S{Q})
where S is the selected sender. RSVP allows multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is the `sum' of Q1, Q2, ... for all requested senders.
 Shared Explicit (SE) Style
An SE-style reservation creates a single reservation shared by selected upstream senders. Unlike the WF
style, the SE style allows a receiver to explicitly specify the set of senders to be included. An SE
reservation request can be represented by:
SE( (S1,S2,...){Q} )
where Q is a flowspec and S1, S2, ... a list of senders.
Which style should be used?
WF and SE style reservations are appropriate for multicast applications in which multiple data sources
are unlikely to transmit simultaneously, for example an audio conference. Each receiver might issue a
WF or SE reservation request for twice the bandwidth required for one sender (to allow some overspeaking). The FF style, which creates distinct reservations for the flows from different senders, is
appropriate for simultaneous video signals. The RSVP rules disallow merging of different reservation
styles, because they are either fundamentally incompatible or may lead to problems.
2.9 Discussion
One scaling issue is the overhead in large multicast sessions[1]. This is solved by RSVP. Because of the
different reservation styles, the amount of control traffic in RSVP and the reservation state scales better
than linearly with the number of senders in large multicast sessions. In multicast sessions the PATH
message is also sent as a multicast message. RESV messages from the receivers on the branch for the
same flow are merged at the network node, so that only one RESV message is sent upstream. Thus,
RSVP also scales better than linearly with the number of receivers in a session.
Another scaling issue is the overhead for a large number of multicast sessions. The number of RSVP
control messages processed by each router is proportional to the number of QoS flows going through the
router. Reservation state is kept on a per-flow basis. Thus, managing state and processing control
messages scales linearly with the number of flows. However, managing reservation state puts a heavy
Resource Reservation and Service Quality
- 23 –
strain on routers with large interfaces. RSVP messages are sent quite infrequently, typically once per 30
s. The protocol is neither more complicated as typical routing protocols.
In the RSVP/Intserv approach each packet is classified onto the right flow. This may require much
processing of the routers, especially as they have to look far into the packet. In experiments in the Faster
Pro project and also in Helsinki Telephone Company [50] performance degradation have been realized
when there are many competing flows. This is especially true if the flows come from different interface
on the router. Experiments in the Faster Pro projectshow also, that the proper adjustment of the bucket
size is critical, a too small bucket size may result in dropped packets [49]. With proper adjustment of the
bucket size of the routers the controlled load service is almost as good in a heavy loaded network as best
effort in a moderately loaded network. Surprisingly, if the capacity of a serial link is too high, Intserv
does not always work properly. A common opinion is thus, that this approach, if more widely used, is
feasible for the edge routers, where the number of flows are still manageable, and also bandwidth may be
more limited, but not in the core network routers, as they have to handle a lot of flows, the switching and
routing processes have to be faster (and thus as simple as possible), and even a lot of bandwidth is
available.
In edge routers (at least some of) the packets should in any case be checked for policy and security,
especially as internet is becoming more and more commercialized. Compared with all this, RSVP should
not be an impossible task. However, on the long run it may require hardware and software optimizations.
The Integrated Services working group argues that special services and predictable quality of service are
necessary for the class of playback applications. Reservations ensure that the network does not accept
more traffic than it can handle and applications receive their desired quality of service. Others believe
that the congestion problem can be solved with adaptive applications and hierarchical encodings alone.
Receivers can adjust their playback point to deal with varying delay.
If there is no congestion, resource reservation is not worth the effort. Buffering is a more effective way to
remove the small amount of jitter that is caused by queuing in an uncongested network. Van Jacobson
estimates in [16] that a buffer of only 800 bytes is needed to remove jitter from a transcontinental voice
conversation.
One argument against RSVP is also that a simple priority scheme, which gives higher priority to realtime traffic, is sufficient. In [22] it is stressed that priority is only an implementation mechanism, not a
service model. Thus, a priority scheme would work in some cases, but not always provide the features
wanted. Also the choice of queueing mechanism will certainly affect performance, but this is a static
choice of the network administrator.
Internet purists oppose any state in the Internet, soft or hard. RSVP requires a considerable amount of
state, thus limits scalability. RSVP has a set-up phase to convey parameters (and state) to the network, a
conversation phase and a tear-down phase. This closely resembles the call model in a telephone network,
which is considered a step backwards.
Resource Reservation and Service Quality
- 24 –
3 DIFFSERV
3.1 Diffserv
Diffserv [5, 44,45] is a complement to the Intserv model. It does not require end-to-end signalling, it
classifies packets to one or a small number of aggregated flows based on the setting of a bit in the TOS
field of the IP header. It is designed to work together with Intserv networks. The Diffserv services
include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and
those based on relative performance (e.g., "class" differentiation). Services can be constructed by a
combination of:
-
setting bits in an IP header field at network boundaries (autonomous system boundaries, internal
administrative boundaries, or hosts),
-
using those bits to determine how packets are forwarded by the nodes inside the network, and
-
conditioning the marked packets at network boundaries in accordance with the requirements or rules
of each service.
The requirements or rules of each service must be set through administrative policy mechanisms. A
differentiated services-compliant network node includes a classifier that selects packets based on the
value of the DS field Setting of the DS field and conditioning of the temporal behaviour of marked
packets need only be performed at network boundaries.
Diffserv's use of codepoints differs from that of RFC 1349 in that the codes only indicate PHBs, which
may be domain or even router specific, i.e. a setting of a single bit can not be mapped to any special
meaning like bandwidth maximation, etc.
Diffserv distinguish three types of traffic:
a. Quantitative (explicitly signaled) QoS application traffic
b. Qualitative (implicitly signaled) QoS application traffic
c. All other (best-effort) traffic
Quantitative QoS applications rely on explicit admission control for their traffic, at the edges of the
Diffserv network. The traffic is assured tight QoS.
Traffic from qualitative QoS applications is provided with implicit admission control as a result of
policing at ingress points. No explicit feedback is provided to applications. The traffic is assures loose
QoS.
The following diagram illustrates the major functional blocks of a Diffserv router:
Resource Reservation and Service Quality
- 25 –
+--------------+
| Diffserv
|
Mgmt | configuration|
<------>| & monitoring |---------------SNMP,| | interface
|
|
COPS | +--------------+
|
etc. |
|
|
|
|
|
|
v
v
| +----------+
+-------+
+---------+
+-------+
data | |ingress
|
|routing|
|egress
|
|queuing|
------->|-classif. |-->|
|-->|-classif.|-->| stuff |-->
| |-TCB
|
+-------+
|-TCB
|
+-------+
| +----------+
+---------+
|
^
^
|
|
|
| +----------+
|
-->|
|
|
------->| RSVP
|-------------------RSVP |(optional)|
cntl +----------+
msgs
Figure 6.
Major blocks of a Diffserv router [40]
In this diagram, a Traffic Conditioning Block (TCB) represents a combination of metering, marking,
shaping and dropping elements.
Different operators may use different Diffserv PHB classes. For example one operator may allocate
packets to different classes based on price and another based on applications.
3.2 Use of TOS field in RFC1349 and Mgen
The Type of service (TOS) octet in the IPv4 header and the Traffic Class octet in the IPv6 header has
been traditionally intended for indicating quality requirements or class of service for the IP packet. The
coding of this octet has sligthly varied in the versions presented by different RFCs. The latest mgen
version is a practical example of how to use the TOS octet.
Mgen is a program for generating multicast flows. It supports RSVP. Version 3.2 is also supports setting
of TOS bits [57].
- 26 –
Resource Reservation and Service Quality
0
1
2
3
4
5
6
+-----+-----+-----+-----+-----+-----+-----+-----+
|
|
|
|
|
PRECEDENCE
|
TOS
| MBZ |
|
|
|
|
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 7.
7
TOS byte in Mgen.
Mgen divides the Type-of-Service byte in the IP header into three sections shown in figure 7. The values
for the different fields are listed in the tables below:
Table t2.
TOS: (these are the ones defined in RFC 1349 [58] obsoleted by RFC 2474 [59])
1000
0100
0010
0001
0000
------
IPTOS_TOS_MASK
0x1E
IPTOS_TOS(tos) ((tos) & IPTOS_TOS_MASK)
IPTOS_LOWDELAY
0x10
IPTOS_THROUGHPUT
0x08
IPTOS_RELIABILITY
0x04
IPTOS_LOWCOST
0x02
normal service
IPTOS_MINCOST IPTOS_LOWCOST
TOS
TOS
TOS
TOS
TOS
=
=
=
=
=
16
8
4
2
0
Table t3.
Precedence:
111
--
111
110
101
100
011
010
001
000
---------
IPTOS_PREC_MASK
IPTOS_PREC(tos)
IPTOS_PREC_NETCONTROL
IPTOS_PREC_INTERNETCONTROL
IPTOS_PREC_CRITIC_ECP
IPTOS_PREC_FLASHOVERRIDE
IPTOS_PREC_FLASH
IPTOS_PREC_IMMEDIATE
IPTOS_PREC_PRIORITY
IPTOS_PREC_ROUTINE
0xe0
TOS = 224
((tos) & IPTOS_PREC_MASK)
0xe0
TOS = 224
0xc0
TOS = 192
0xa0
TOS = 160
0x80
TOS = 128
0x60
TOS = 96
0x40
TOS = 64
0x20
TOS = 32
0x00
TOS = 00
Example:
If Type of service = 164 or 0xa4, the Precedence would be IPTOS_PREC_CRITIC_ECP, the TOS would
be IPTOS_RELIABILITY and the bits would be set as follows 1010010. (Linux allows only even TOS
values.)
3.3 Diffserv Code points
In the Differentiated services (diffserv) concept the structure of the TOS field the IPv4 header or traffic
class octet in the IPv6 header is redefined. The resulting DS field, specified in RFC 2474 [44] is
presented in figure 8:
- 27 –
Resource Reservation and Service Quality
0
1
2
3
4
5
6
7
+---+---+---+---+---+---+---+---+
|
DSCP
| CU
|
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint
CU:
currently unused
Figure 8.
DS field
[44] assigns eight recommended codepoints ('xxx000'). The default PHB is '000000'. Codepoints '
xxxx11' and ' xxxx01' are reserved for experimental and local use.
The bits in the DS field may for example indicate requirements on delay, throughput, reliability or cost.
In Diffserv, DSCPs may indicate such as drop preference and forwarding preference. DSCPs may also be
changed depending on whether the packet is conformant or non-conformant with the SLA or service
profile.
A DS domain normally consists of one or more networks under the same administration; for example, an
organization's intranet or an ISP. The administration of the domain is responsible for ensuring that
adequate resources are provisioned and/or reserved to support the SLAs offered by the domain. It is
important that the DSCPs are not conflicting within a DS domain. However, in different domains,
different DSCPs may be used if packets are remarked at the network borders.
3.4 Assured forwarding
Companies using internet may want to have an assurance that IP packets within this intranet are
forwarded with high probability and that packets are not reordered, as long as the does not exceed the
subscribed information rate (profile). Assured Forwarding (AF) PHB group is a means for a provider DS
domain to offer different levels of forwarding assurances for IP packets received from a customer DS
domain. [42]. Four AF classes are defined, where each AF class is in each DS node allocated a certain
amount of forwarding resources (buffer space and bandwidth). Within each AF class IP packets are
marked (again by the customer or the provider DS domain) with one of three possible drop precedence
values. In case of congestion, the drop precedence of a packet determines the relative importance of the
packet within the AF class. Table t4 below summarizes the recommended AF codepoint values.
Table t4.
AF codepoint values
Class 1
Class 2
Class 3
Class 4
+----------+----------+----------+----------+
Low Drop Prec
| 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec
| 001110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+
Resource Reservation and Service Quality
- 28 –
3.5 Expedited forwarding
The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end
service through DS domains. [43]. This service emulates a "virtual leased line" and has also been
described as Premium service.
The codepoint used for EF is ' 101110'
3.6 Interoperability PHB group
A new internet draft by Kilkki and Ruutu [48] describes a PHB group which may be used for
interoperability between service providers (PHB-i). The principle is to use unambiguous scales for
importance and urgency of the packets. This PHB may either be used only for interoperability purposes
or as the only PHB in a domain or partially within the domain. PHB-i combined with other PHB groups
works as follows:
Edge node sets the DS field of each IP packet coming from local customers as defined in any PHB
specification.
Part of the packets with non-PHB-i marking can use PHB-i mechanisms inside network nodes by means
of a temporary mapping to PHB-i model.
Packets coming from other domains primarily use the PHB-i group.
Core node implementation includes both conventional methods with appropriate mechanisms, like
weights, and traffic handling mechanisms for packets with PHB-i marking.
Codepoint recommended for the PHB-i group are shown in table t5
Table t5. Recommended codepoints for PHB-i
+------------+----------------+
|
|
Urgency
|
| Importance |
0
1
|
+------------+----------------+
|
7
| 111011 111111 |
+ - - - - - - - - - - - - - - +
|
6
| 110011 110111 |
|
5
| 101011 101111 |
|
4
| 100011 100111 |
|
3
| 011011 011111 |
|
2
| 010011 010111 |
|
1
| 001011 001111 |
+ - - - - - - - - - - - - - - +
|
0
| 000011 000111 |
+------------+----------------+
3.7 Feedback in Diffserv
Research reports have shown that diffserv may result in unfair and inefficient resource sharing [61].
There are at least three causes for this:
No isolation of flows inside the core network, flows are forwarded using one or a few PHBs. Since flows
are indistinguishable within a shared buffer, aggressive flows may deprive other flows of resources.
No dynamic control at diffserv boundary.
Reliance on only transport protocol to react: TCP flows generally receive poorer service than UDP.
Resource Reservation and Service Quality
- 29 –
One suggestion to overcome this is proposed in [61], the feedback controlled diffserv (FC-DS). In this
concept, the boundary routers should periodically probe the core of the network to obtain the current
state information, which is used for adaptive TC (ATC). The ingress node adjust its policy
parameters/traffic conditioners to achieve a more fair control on incoming traffic. The interior nodes
needs a load monitoring function. When it receives a probe/report packet, it updates the packet with its
current load information and forwards it to other connected nodes. The packet is returned by the egress
router, which may also (optionally) perform TCA functions.
The probe/report could either be implemented as a completely new control packet, as an extension of the
IP header of some selected packet, or as a new RSVP packet, with a special object for this purpose.
Another such approach is proposed in a one year older internet draft "1-bit enhanced diffserv" [62]. This
proposal makes the "unused" bits of TOS byte, which are reserved for explicit congestion notification
(ECN). As the name says, these bits/this bit may be used to indicate congestion. The idea is that ECN
enabled routers could set the ECN bit on a packet instead of dropping it. The destination then sets the
ECN bit in the acknowledgement to notify the source. The source responds by cutting its window size.
The ECN mechanism may also give some protection against denial-of-service attacks against diffserv
networks. (See [61] for details!). In addition, it is suggested to use a RED-plus-penalty-box (RED =
random early detection), for detecting misbehaving connections. This combines RED with an accounting
technique. This method is though, not completely conformant with the diffserv framework, as it also may
apply to the IN-profile packets of a misbehaving connection.
A sample ECN-enhanced diffserv may work as follows: At network edges, out-of-profile packets are
marked by default, and dropped during congestion. An ECN-capable interior router drops out-of-profile
packets during congestion and sets ECN on in-profile packets on the same flows whose out-of-profile
packets were dropped. The ECN-capable egress router sends a notification packet back, when it detects
the ECN. The egress router also clears the ECN-bit on the packet going forward to the next network
domain (unless this network shares the same codespace as end-to-end ECN). In case packets travel in a
tunnel, the ECN bits would also have to be copied from the internal header to the outer header at the
tunnel entrance, and copied back from the outer to the internal header at the tunnel exit (otherwise ECNbits set by the routers, through which the packets are tunneled, will be lost).
In Differentiated Services the TOS bits are set at the sender side of the network. At receiver's access link
this setting might not reflect how the receiver wants the incoming traffic prioritized. In [45] an idea to
have receiver acknowledgements in Diffserv is presented.
For this dynamic Diffserv Ack Protocol (DAP) an ACK message is specified, which is used by the
receiver to acknowledge to next-hop router that it wants to accept the Diffserv flow. Otherwise the flow
continues as a Best-Effort flow. The receiver may send the Ack beforehand or when it gets the first DSmarked packet.
ACK messages should be forwarded upstream until they reach a router that has not been configured as a
"last hop router", i.e. it does not understand the ACK message. The forwarding issues can be defined in
service level agreements (SLAs).
3.8 Bandwidth brokers
Closely related to Diffserv is the bandwidth broker concept [60]. QoS support is made of three basic
parts: defining packet treatment classes, specifying the amount of resources for each class, and sorting all
incoming packets into their corresponding classes. Diffserv effort addresses both the first and third issues
above. Bandwidth Brokers address the second issue by keeping track of the current allocation of marked
traffic and interpreting new requests in the light of the policies and current allocation. Particularly if
there are many users who like to get better QoS, there must be some means to decide which users are
preferred. Bandwidth broker servers act as repositories for policy database. It interfaces with the routers
and instructs what to tag. This is especially relevant for the egress routers. The bandwidth brokers in
Resource Reservation and Service Quality
- 30 –
adjacent network domains communicate which each other in order to interchange information about
resources needed. The ISPs need to have bilateral service level agreements (SLA). Thus, a bandwidth
broker functions can be divided in intra-domain and inter-domain resource management. The first
handles requests from users and applications and the second for provisioning and allocating resources at
network boundaries.
The components of a bandwidth broker are shown in figure 9. Bandwidth brokers are foreseen to be in
production in year 2000.
Figure 9.
Architecture of a bandwidth broker [60]
3.9 SIMA
Simple Integrated Media Access (SIMA) service is a new simple approach for traffic management in the
Diffserv style. It is described in [37]. It is at internet-draft stage. According to the SIMA concept each
customer shall define only two issues before a connection establishment: a nominal bit rate (NBR) and
the selection between real-time and non-real-time service classes. NBR has two purposes: it forms the
basis of charging, and it defines how the network capacity is divided among different connections during
overload situations. SIMA distinguishes three elementary service types, one for reliable high quality
connections, one for connections with less stringent quality requirements, and one for data connections
Resource Reservation and Service Quality
- 31 –
which can adapt their bit rate. The service specification is further divided into several smaller parts. As
opposed to most service specifications, charging is the starting point of the SIMA concept.
The bit-rate related charge is a function of the NBR, and NBR may be assigned at different levels. For
example permanent NBR may be assigned to an interface or an organization, the next level of NBR is
assigned to a user (or IP-address) and the bottom level to a flow (determined for instance by a pair of IP
address and port number).
The other part of the SIMA service concept is the possibility to request real-time (rt) or non-real-time
(nrt) service. If a real-time service is requested, the SIMA network attempts to offer as short delay and
small delay variation as possible. The cost of this may, however, be increased cell loss ratio during peak
rates.
A potential difficulty with the SIMA service is that the customer cannot precisely know what the QoS of
a flow will be because rapid traffic variations may bring about unexpected changes of QoS. However,
even in the case of services using resource reservation the actual quality of flows using certain quality
class may vary significantly, because the quality can only be determined by using statistical parameters.
For constant bit-rates SIMA distinguishes 7 quality levels:
7 = reserved for non-SIMA services with resource reservation
6 = excellent quality: negligible packet loss ratio
5 = high quality: packet losses only during exceptional traffic peaks
4 = good quality: small packet loss ratio even during busy hour
3 = moderate quality: usually small packet loss ratio except during busy hours
2 = satisfactory quality: from time to time very high packet loss ratio
1 = suitable for best-effort traffic during busy hour
0 = unusable during busy hour, but suitable for best-effort traffic during non-busy hours
The charge of priority level j will be X*2^(j-4), if the charge of level 4 is X, and if the charging is
proportional to NBR. However, quality level 0 can be in practice obtained free of charge.
The traffic control information is conveyed purely by the SIMA packets (or cells), which means that
there is no need to have any separate control information transported between different network nodes.
- 32 –
Resource Reservation and Service Quality
4 INTSERV AND DIFFSERV COMBINED
4.1 Sample Network with Intserv and Diffserv Regions [5]
Figure 10 shows a sample network configuration where (at least some of the routers in) the stub networks
are Intserv capable and (at least some of the routers in) the transit network Diffserv capable.
/ Stub \
/ Transit \
/ Stub \
/ Network \
/ Network
\
/ Network \
|---| |
|---|
|---|
|---|
|---|
| |---|
|Tx |-|
|ER1|---|BR1|
|BR2|---|ER2|
|-|Rx |
|---| |
|-- |
|---|
|---|
|---|
| |---|
\
/
\
/
\
/
\
/
\
/
\
/
Figure 10.
Sample Network Configuration
Routers internal to the Diffserv network are assumed to provide a set of 'per-hop-behaviours' (PHBs).
Within the Intserv regions QoS applications invoke specific end-to-end service levels by using RSVP
signaling to configure 'MF' classifiers which operate on IP addresses and port numbers. Within the
Diffserv regions of the network, traffic is allotted service based on the contents of the DS-field in packet
headers. Therefore, it is necessary to mark DS-fields before their packets are submitted to the Diffserv
network.
1. Hosts may directly mark DS-fields in the transmitted packets of QoS applications.
2. Routers external to the Diffserv network may mark DS-fields on behalf of QoS applications based on
MF classification. This will be done based on top-down configuration of the marking router's MF
classifier/marker (by manual configuration or via automated configuration scripts) or based on
standard signaling between QoS applications and the marking router's classifier/marker.
End-to-end QoS requires that quantitative QoS applications and RSVP capable Intserv nodes be
explicitly informed of admission control failure in the Diffserv network. This enables them to take
corrective action and to avoid overdriving the Diffserv network.
The edge routers are special routers at the boundary between the RSVP/Intserv region and the Diffserv
region can be modelled as consisting of two halves; the standard RSVP half and the Diffserv half. The
RSVP half is at least partially RSVP capable; it is able to process PATH and RESV messages but it is
not necessarily required to store full RSVP state and it is not required to provide MF classification. The
Diffserv half of the router provides the interface to the admission control function, 'DACS' (Diffserv
admission control service). Boundary routers in the example illustrated, are not required to run RSVP.
Resource Reservation and Service Quality
- 33 –
Leaf routers within the stub networks may or may not be Intserv capable. If they are not Intserv capable,
we assume that they are not capable of per-flow identification, signaling, and admission control and, in
that case, will pass RSVP messages (requesting per-flow QoS) unhindered.
The transit network is not capable of per-flow identification, signaling, and admission control. It provides
two or more levels of service based on the DS-field in the packet headers. It also carries RSVP messages
transparently.
Two possible schemes are proposed for mapping of Intserv - to - Diffserv service levels, static, "default
mapping" (well-known mapping) and "customer-specified-mapping" where the edge devices of the
Diffserv region may modify the well-known mapping.
End-to-end QoS is established as follows:
1. The RSVP PATH message is sent normally from the sender towards ER1. Standard RSVP processing
will be applied at the RSVP capable nodes. The PATH state is installed at ER1.
2. The PATH message is sent transparently through the Diffserv network, and then towards the sender.
Standard RSVP processing will be applied at the RSVP capable nodes of the receiving stub network.
3. The receiver sends the RSVP RESV message towards the sender. Standard RSVP processing is
applied in the stub network. If the message is not rejected in it is carried transparently through the
transit network to ER2.
4. In ER2 the RESV message triggers the DACS processing. If the RESV message is admitted, i.e. the
requested resources are available, the DACS updates the available capacity for the service class, by
subtracting the approved resources from the available capacity.
5. The RESV message continues towards the sender, with standard RSVP processing in the RSVP
capable nodes.
6. At the sending host, the QoS process receives the RESV message. It interprets receipt of the message
as an indication that the specified traffic has been admitted for the specified Intserv service type (in
the RSVP enabled regions of the network) and for the corresponding Diffserv service level (in the
Diffserv enabled regions of the network). It begins to set the DS-field in the headers of transmitted
packets, to the value which maps to the Intserv service type specified in the admitted RESV message.
In the example described, the hosts mark the DS-byte. If the application is RSVP capable but not Diffserv
capable, this is not possible. It is also possible to mark the DS field at intermediate routers. In this case,
intermediate routers may use the RSVP signaling to configure an MF classifier and marker. Therefore,
the configuration of MF classifiers and markers is dynamic (minimizing the management burden) and
full resource and policy based admission control can be applied.
The disadvantages of marking the DS-field at intermediate routers are that full MF classifiers are
required at the intermediate nodes and that responsibility for traffic separation is shifted away from the
host.
The study above assumes that the stub networks are Intserv-compliant and the transit network is Diffservcompliant. Of course also other combinations are possible. These situations have been studied in [46]. A
summary of the advantages and drawbacks of these combinations is presented in table t6.
- 34 –
Resource Reservation and Service Quality
Table t6. Diffserv vs. Intserv in stub and transit networks.
Scenario
client stub – transit – server stub
advantages +
drawbacks -
1 Diffserv- Diffserv - Diffserv
- uniform QoS
mechanism
- scalability
- no end-to-end
QoS signalling
2 Intserv – Intserv -Intserv
- end-to-end QoS
- possible scaling
problems
3 Intserv – Diffserv - Intserv
4 Diffserv – Intserv - Diffserv
- scaling issues are
alleviated by the use of
aggregation and/or
Diffserv
5 Diffserv – Intserv – Intserv and
6 Intserv – Diffserv - Diffserv
Diffserv preferable
where scalability is
critical
notes
- possible scaling
problems on highend servers
described above
- overhead
associated with
establishment
and operation of
aggregated tunnels
IntServ mechanism
may be used to set up
aggregated reserved
bandwidth tunnels in
the transit network,
with or without the
use of tag-switching
allow applications to
support signaled QoS
which gets mapped
into an appropriate
Diffserv tunnel
Clearly, the RSVP/Intserv approach provides better granularity to QoS handling on the cost of more
processing power required, whereas Diffserv establishes more fixed priorities, based on charging or
policy. It is likely that if future networks and applications will support QoS, some mixed solutions can be
expected, e.g. using RSVP but with a simplier priority scheme, or using Intserv in the edge networks and
Diffserv in the core network. One possibility is that the sending application or some intermediate router
could translate the flow spec indicated in the RSVP RESV message to some corresponding setting TOS
bits (DSCP) dynamically. This would allow different solutions in different networks but also require
some common understanding of the meaning of the DSCPs, to avoid changing them at intermediate
network borders.
4.2 QoS API
In order to provide a more generic platform for QoS for internet applications, an API specification that is
independent of both vendors and the underlying QoS approach would be desirable.
Interfaces for setting TOS bits are available for Linux [51] and in Microsoft Windows systems. In
Windows 2000 the GQoS API is included [52], for Windows 95 and NT4, there is the QoS API by Intel
available for Winsock 2 [53]. However, the Winsock2 [39] QoS SP is of course platform dependent.
- 35 –
Resource Reservation and Service Quality
Application
3rd party
traffic
management
application
Winsock2
GQoS API
QoS SP
Protocol
Stack
traffic.dll
Traffic Control
API Interface
(TCI)
Packet
Scheduler
Netcard
Figure 11.
The QoS-enabled stack [39]
The RSVP API (RAPI, Scrapi) is another candidate, but this one is made specifically for the ISI RSVP
implementation and is implemented in a way which should make it easier to make applications
RSVP/intserv compliant. The technical details of the underlying QoS method, e.g. RSVP should be
hidden from the application. The number of parameters in RSVP are too many for the user to understand.
This may also be true for the application developers.
Of course, even if RSVP is a good candidate for the signalling protocol between or beneath the QoS SPs,
also other protocols or perhaps even other approaches may be used, for example signalling to a
bandwidth broker, described in the next section.
The request for some QoS level comes from the application making use of the QoS API, but this may not
necessarily be the user application itself, it may also be some management application acting on behalf of
the user. This is already true for the RSVP API! One idea is also to hack some RSVP implementation to
translate the application needs to QoS commands for the routers/switches in the access network.
To specify an API, which would be as independent as possible sounds like a difficult task. As already
explained in this report, QoS can be provided using either local decisions or signalling or both. The QoS
SP should enable both methods and has thus interfaces to the application, with the protocol stack and
with traffic control facilities.
Resource Reservation and Service Quality
- 36 –
The approach could be something like in figure 11. Possibly, the QoS SP could consist of some upper,
generic part with different plug-ins or lower layer for the specific QoS approaches (Intserv, Diffserv,
ATM, etc.) .
4.3 Bandwidth Broker
The bandwidth broker could possibly act as a gateway between intserv and Diffserv network regions. A
bandwidth broker could also allow the user (or receiving application) to signal quality requirement by
other means, e.g. email, via a command line interface (bandwidth broker client) or interactively via a web
site. An other question is whether ISP managers would allow generic users to interfare with the
bandwidth broker even if it would be secure enough and hidden behind for example a web site. In any
case it is clear that the user interface for generic users has to be very simple, in opposite to that for
network managers and specialists which should give a fine-grained control over the network performance
and QoS parameters. (However, the same holds also for RSVP.) It is also clear that in heavy loaded
networks, all users' request cannot be fulfilled.
Resource Reservation and Service Quality
- 37 –
5 POINTS TO STUDY / TEST SETUP
This section briefly describes the test systems that were set up in the Moses project at VTT. More
detailed specifications of these systems and the test results are in the referenced documents. In addition,
some test systems that were not fully built in the project are described here for further study.
The tests at VTT had to be made using existing equipment, as there were not enough resources to buy
additional equipment. Particularly this means to use Mediapoli network and small internal network links.
Mostly Sun and Linux workstations have been used, windows based workstations would have been an
alternative. As the Cabletron router does not yet support intserv, a Linux based PC was setup as router
for internal experiments. (The Cabletron router can, however, be set to prioritize traffic based on TOS
bits.)
An ATM subnetwork with either LANE or CLIP would also have been an alternative, but such test
setups have deliberately been left out of this project, partly because of the decreasing interest for ATM
and partly because the study still have concentrated quite much on intserv, which is not supported (at
least yet) by the FORE and FSR switches at VTT.
Points left for further study are the mapping of intserv and diffserv and the bandwidth broker
implementation.
Unfortunately there has been more problems than foreseen with the traffic control, and also other
software bugs which have prevented experiments to be carried out as originally planned.
5.1 Linux traffic control
iproute2 [66] is a Linux software package that can be used to control the sending, forwarding and
receiving of IP packets. This kind of low-level traffic control software can be used alone, or it can be
used as a component to implement diffserv or intserv QoS support.
In these experiments, iproute2 traffic control software (tc) was placed in several places of the test
network, but only in one place at a time: the sending host, a router between the sender and the receiving
host, a router in the LAN close to the receiving host (figure 12), or in the receiving host. The test
configurations are described in [63]. The goal was to improve the quality of a selected data flow (MP3
sound) at the expense of other flows (http download). The results indicate, for example, that traffic
control can be useful even when it is available only in the receiving host or network.
- 38 –
Resource Reservation and Service Quality
10 Mbit/s
tc
38 kbit/s
• Netscape
Router
10 Mbit/s
• http server
• MP3 player
• MP3 server
(24 kbits/s)
Figure 12.
A Linux traffic control experiment
5.2 Process priorities
FTP client
UDP sink
UDP source
Prioritise flows by
modifying process
priorities in the receiving
host
Figure 13.
Process priorities test
FTP server
- 39 –
Resource Reservation and Service Quality
This test evaluates a method that lets an end user have an effect on how the limited network bandwidth is
divided between his applications. The tested method prioritises selected data flows by modifying only the
CPU processing priorities in the receiver host. The method relies on the properties of the TCP to slow
down less urgent data streams, and does not require any extra support from the network or modifications
to existing applications. Measurements to test the method are described and the results are discussed in
[54]. The results indicate that the method works in several cases. The difference was clearly noticeable
only when additional load was put on the processor. In that case, contradictory to what one would expect,
the quality of the higher prioritized flow was considerably improved. The flow which is given lower
priority is slightly slowed down but continues with full speed when the higher priority flow is ended.
Also, as expected, if the priority of some process is low and the processor is heavy loaded, lost packets
and increased delay may be the result.
On fast links, if the processor is not heavy loaded, different flows do not have much effect on each other,
and so no extra prioritizing is required.
5.3 Router priorities
The purpose of this experiment is to see if and how much IP packet priorities on Cabletron routers affect
the speed of file transfer from one host to another. In particular, the effect of prioritising packets on only
one router near the network bottleneck is tested.
st1-053
10M
switch
1G
router
1G
router
1G
csc-rtr1-11
10M
linguine
router
Figure 14.
Router priority test network
The configuration depicted in figure 14 was tested. Files were transferred from st1053.vtt.mediapoli.com to linguine.tte.vtt.fi, or in the opposite direction. csc-rtr1-11.otaverkko.fi, which is
one of the routers on the way from st1-053 to linguine, was configured to give different priorities to IP
packets. The results are described in [63] and indicate that high-priority packets flow faster but not much
faster than low-priority packets.
Resource Reservation and Service Quality
- 40 –
5.4 Intserv
Unfortunately the Cabletron routers/switches are not currently RSVP compliant. RSVP support is
expected year 2000, i.e. too late for MOSES project.
Several RSVP implementations exist, some of which are free of charge[30]. In addition RSVP calls are
implemented to adapsock, which is the socket interface of the Videkom videoconferencing application.
The interesting point is to study it over different, heterogenous links, of which some maybe do not
support RSVP. When the communication occurs over fast ethernet links, as tried between two Sun
workstations in different VLANs through the Mediapoli Cabletron router, reservation do not seem to be
needed.
In the pilot network in VTT, several different network configurations could be set up. The test network is
outlined in figure 15. As the Cabletron switch is not RSVP-capable, a Linux PC based RSVP-capable
router is inserted. Unfortunately the latest RSVP software for Linux does not work for the PPP link
because of some bug. The previous versions, on the other hand, do not seem to support traffic control.
Because of this, the RSVP experiment between anakin and amidala failed. It is planned to carry out
experiments together between VTT and LUT over Mediapoli and Funet.
RSVP over mobile links would certainly be interesting. One such PD implementation exist.
Unfortunately it is told be difficult to set up and it is implemented for a totally different Linux version as
those used at VTT/TTE2. Thus, it seems that this experiment will not be carried out in the MOSES
project.
5.5 Diffserv
At least with mgen it is now possible to set TOS bits, but in the old fashion. Using this feature, it should
be possible to test the impact of these on the QoS. Diffserv is actually more complicated than that, but is
foreseen to be more widely supported in the near future. Now, it is however, possible to prioritise traffic
statically and this could give some hints for diffserv.
A point not actually addressed here, is how diffserv would perform for mobile terminals and in wireless
networks. Especially if DS bits are not set by the mobile host, how would the first router classify the
traffic? And how would diffserv work together with mobile IP?
5.6 Different methods combined and compared
QoS mechanisms, such as intserv and diffserv, have been studied extensively. But when different QoS
mechanisms are used together in complex networks, many new problems are encountered.
A drawback using different approaches along the path, is that either hosts (applications) or edge routers
must be able to set the appropriate parameters, e.g. type of service (TOS). The mapping between
parameters used in RSVP and in lower layers requires further study, especially for low bit-rate links.
The test setup could be the one in figure 15. Mgen is maybe the easiest application to use for the tests,
but also audio and video streams or other applications like web browsing can be tested. The client and
server are on different VLANs (as such tests inside the same VLAN is not of much interest, other than
perhaps simply for comparison). It is also planned, that some of the experiments should be carried out
together between VTT and LUT via Mediapoli and Funet.
One interesting thing to study, would be how the applications perform with priorities alone, either based
on TOS field value or some other precedence, without RSVP compared to the cases where RSVP is used
in the edge VLANs and priorities across the Cabletron switch /Mediapoli or compared to best-effort
approach.
- 41 –
Resource Reservation and Service Quality
The planned tests, of which all will not be carried out here, are described in [65].
Linux ws
(amidala)
st1-053 (cello)
(212.68.2.53)
Solaris ws
st1-051
(212.68.2.51)
Solaris ws
st1-034
(192.168.1.1)
Cabletron
switch
Linux
GW/router
transit network
Mediapoli, Funet
Linux ws
ppp link
Sun ws
(anakin)
Cisco router at
LUT
SUN ws
celegorm ?(157.24.23.63)
Figure 15.
Suggestion for test setup in MOSES
Resource Reservation and Service Quality
- 42 –
6 SUMMARY / CONCLUSIONS
A lot of the current research addresses IP over ATM, which seems to be difficult because of the
differences in the structures. On the other hand ATM already provides QoS and is as such promising. At
least by FORE, QoS can somehow be used by LANE but not by classical IP. Different solutions are
under study, but any consensus does not exist. For example AREQUIPA and IPSOFACTO seem to be
interesting approaches.
Another question is whether there should be flow state in the network or not. Basically that means Intserv
or some kind of Diffserv solution.
RSVP is strongly coupled to the Intserv concept, but is also suggested as a generic protocol for signalling
resource needs inside the network.
In most cases (ethernet) it is not possible to provide guaranteed service, but controlled service may be
feasible. There might even be a trend towards relative service contracts instead of absolute.
For the reservations to work in an end-to-end fashion, it is not necessary required that all routers and
switches on the way understand RSVP. If RSVP is not supported in some subnetwork "cloud", Diffserv
or some similar technique, which provides QoS classification is needed. Currently, this is the case on
most long-distance connections. Alternatively, if the subnetwork where RSVP is not supported, provides
enough bandwidth for all cases, and is not a bottleneck, it should not either be a hinder for RSVP. In any
case they should not lose the PATH and RESV messages but forward them. One reason for the interest in
the Diffserv approach is that is not believed that all ISPs would support RSVP. The Diffserv solution
allows each ISP to implement the policies more or less independently, though the structure in this case
also becomes complicated.
In order to make use of possible dynamic QoS features in the future, the QoS choices/scale should be
presented to the user in a way that is easy to understand. Either the applications could support QoS
directly or some separate tools could be available. This application would use a QoS API, outlined in
section 4.2. The QoS management application in the user's workstation might also interact with
bandwidth brokers of the ISPs (see section 4.3!). Bandwidth brokers, described in might be used to
communicate QoS management data between network domains.
Studies have mostly shown that Intserv might be feasible especially for real-time flows on rather slow
links in the access network, especially when there are not too much competing flows, whereas it is likely
that it is not feasible in the backbone/core network.
Resource Reservation and Service Quality
- 43 –
7 REFERENCES
1
U. Schwantag. An Analysis of the Applicability of RSVP. Diploma Thesis. University of
Oregon and University of Karlsruhe. June 1997. http://networkservices.uoregon.edu/~ursula/thesis/thesis.html
2
B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan, S. Blake, "Use of Label
Switching With RSVP", IETF Internet-Draft <draft-ietf-mpls-rsvp-00.txt>, March 1998.
3
Andreas Köpsel. RSVP over ATM. Ein Vortrag im Rahmen des Seminars
Breitbandkommunikationsnetze, Sommersemester 1997. Technische Universität Berlin,
Fachgebiet TKN, http://www-tkn.ee.tu-berlin.de/~koepsel/RSVP-exposee/RSVPexposee.html
4
http://eratosthenes.informatik.uni-mannheim.de/informatik/pi4/events/qosws/programm/griffoul.html
5
Y. Bernet et. al. A Framework for Use of RSVP with Diff-serv Networks. June 1998.
<draft-ietf-diffserv-rsvp-00.txt>
6
C. Bormann. Providing integrated services over low-bitrate links. Universitaet Bremen
TZI. August 1998. <draft-ietf-issll-isslow-04.txt>
8
R. Braden et. al: RFC 2205. Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification, September 1997.
http://src.doc.ic.ac.uk/computing/internet/rfc/rfc2205.txt
16
Van Jacobson. The MBone - Interactive Multimedia on the Internet, Feb 17, 1995. Slides.
17
RFC2170. W. Almesberger, J. Le Boudec, P. Oechslin. Application REQuested IP over
ATM (AREQUIPA), LRC, DI-EPFL, Switzerland, July 1997.
http://src.doc.ic.ac.uk/computing/internet/rfc/rfc2170.txt
18
P. Väänänen, R. Ravikanth. Framework for Traffic Management in MPLS Networks.
<draft-vaananen-mpls-tm-framework-00.txt>. http://dcn.soongsil.ac.kr/~jinsuh/draft/draftvaananen-mpls-tm-framework-00.txt
19
M. Ohta. Simple Unified Networking. Tokyo Institute of Technology. March 1997.
http://www.dmi.tut.fi/projects/fasterpro/documents/RSVP/Draft/draft-ohta-sun-01.txt
20
J. Jormakka, K. Heikkinen, N. Kosminin. Performance Modelling, QoS Measurements and
QoS Routing on a Middleware platform, LUT. <qosmodel.ps>
21
R. Jain. Multimedia networking. (slides). The Ohio State University.
22
R. Braden, D. Clark, and S. Shenker. Integrated Services in the Internet Architecture: an
Overview. Request for Comments (Informational) RFC 1633, Internet Engineering Task
Force, June 1994
23
P. Newman, W. L. Edwards, R. E. Hoffman, F. Ching Liaw, T. Lyon, and G. Minshall.
RFC 1953: Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0, May
1996.
24
IP Switching: The Intelligence of Routing, the Performance of Switching, February 1996.
Ipsilon Networks white paper. http://www.ipsilon.com/productinfo/wp-ipswitch.html
25
Yakov Rekhter, Bruce Davie, Dave Katz, Eric Rosen, George Swallow, and Dino
Farinacci. Tag Switching Architecture - Overview. Internet Draft, Jan 1997. Work in
progress. <draft-rekhter-tagswitch-arch-00.txt>.
- 44 –
Resource Reservation and Service Quality
26
S. Shenker, C. Partridge, and R. Guerin. Specification of guaranteed quality of service.
Internet Draft, Feb 1997. Work in progress. <draft-ietf-intserv-guaranteed-svc-07.txt>.
27
J. Wroclawski. Specification of the controlled-load network element service. Internet
Draft, Nov 1996. Work in progress. <draft-ietf-intserv-ctrl-load-svc-04.txt>.
28
A. Ghanwani, J. W. Pace, and V. Srinivasan. A Framework for Providing Integrated
Services Over Shared and Switched LAN Technologies. Internet Draft, April 1997.
Work in progress. <draft-ietf-issll-is802-framework-01.txt>
29
S. Berson, L. Berger. IP Integrated Services with RSVP over ATM. Fore systems.
November 1996. < draft-ietf-issll-atm-support-02.txt> http://eantc.prz.tuberlin.de/Documents/Standards/IETF/internet-drafts/draft-ietf-issll-atm-support-02.txt
30
G. Gaines, M. Festa. A Survey of RSVP/QoS Implementations. July 1998.
<ietf_rsvp_qos_survey_02.txt> http://www.iit.nrc.ca/IETF/RSVP_survey/ietf_rsvpqos_survey_02.txt
31
K. Sklower et. al. RFC 1990. The PPP Multilink Protocol (MP).
http://src.doc.ic.ac.uk/computing/internet/rfc/rfc1990.txt
32
J.V. Luciani. Next hop Resolution Protocol. (slides). Memphis IETF, April 1997.
http://www.ietf.org/proceedings/97apr/int/ion-nexthop-resolution/sld001.htm
33
M. Degermark, B. Nordgren. IP Header Compression <draft-degermark-ipv6-hc-06.txt>
http://www.kashpureff.org/nic/drafts/draft-degermark-ipv6-hc-06.txt
34
S. Casner, V. Jacobson. Compressing IP/UDP/RTP Headers for Low-Speed Serial Links.
< draft-ietf-avt-crtp-05.txt > http://www.kashpureff.org/nic/drafts/draft-ietf-avt-crtp-05.txt
35
SmartSwitch Router User Reference Manual
36
A. Acharya & al. Dynamic OoS for IP switching using RSVP over IPSOFACTO.
ftp://ftp.focus.gmd.de/pub/step/is-ipso/rsvp_ipsofacto.ps.gz
37
K. Kilkki, "Simple Integrated Media Access (SIMA)", Internet Draft.
kalevi-simple-media-access-01.txt>, June 1997.
38
ForeRunner HE/200E/LE ATM Adapters for the PC User's Manual (BETA Copy)
39
Microsoft®. Windows NT Server. Windows Quality of Service Technology. White Paper
40
draft-ietf-diffserv-model-00.txt
41
RFC2475 Differentiated Services architecture
42
RFC2597 Assured Forwarding
43
RFC2598 Expedited forwarding
44
RFC2474 Nichols, K. & al. Definition of the Differentiated Services Field (DS Field in the
IPv4 and IPv6 Headers. December 1998.
http://src.doc.ic.ac.uk/computing/internet/rfc/rfc2474.txt
45
Ohlman B, Koskelainen P. Receiver control in Differentiated services. <draft-ohlmanreceiver-ctrl-diff-01.txt>. 30 september 1998
46
Mehra, A, Verma, D. Architectural Considerations for DiffServ Servers . <draft-mehradiffserv-servers-00.txt>
47
Karsten M, et. al. An Embedded Charging approach for RSVP, GMD IPSI, 1998
<draft-
Resource Reservation and Service Quality
- 45 –
48
Kilkki K., Ruutu J. Interoperability PHB Group. Internet draft, October 1999. <draftkilkki-diffserv-interoperability-00.txt>
49
Harju J. et al. Measurements about the Quality of Controlled-Load Service, TUT.
50
Isomäki M., Tuominen J., End-to-End Quality of service for Real-time Voice in Corporate
IP networks – an Architecture an Test Results. Proceedings of the 8th summer School on
Telecommunications, 13 August 1999, LUT, Finland. pp. 1 – 20.
51
Radhakrishnan S. Quality of Service support for Linux. University of Kansas, December
25, 1998.
52
Quality of service and windows . http://channels.microsoft.com/hwdev/network/qos/
53
Intel® PC-RSVP. http://intel.com/ial/rsvp/
54
Koivisto J., Lucenius J. Using process priorities and TCP to prioritise Flows. Proceedings
of the 8th summer School on Telecommunications, 13 August 1999, LUT, Finland. pp 27
– 34.
55
Koivisto J. Mobility management in Future Communication Systems. v 1.0, VTT
Information Technology, 1999-10-07.
56
Mobile IP at NUS. http://mip.ee.nus.edu.sg/
57
MGEN-3.2 User's Guide. http://manimac.itd.nrl.navy.mil/MGEN/MgenUserGuide.html
58
P. Almquist. "Type of Service in the Internet Protocol Suite." RFC 1349 1992, (obsoleted)
60
Sreekantan D., Rao D. Implementation of a Bandwidth Broker System for Resource
Management in Differentiated Services. http://www.ittc.ukans.edu/~kdrao/845/
61
Chow K, Leon-Garcia A. A Feedback control Extension to Differentiated Services.
Internet-draft, March 1999. <draft-chow-diffserv-fbcrtl-00.txt, .ps .pdf>
62
Kalynaraman S. et al. A One-bit Fedback Enhanced Differentiated Services Architecture.
Internet draft. March 1998. <draft-shivkuma-ecn-diffserv-00.txt>
63
Moses Qos demo <qos-demos.ppt>
64
IP Packet Priority Experiment 1, project report
65
Lucenius J., Koivisto J. Quality of service tests in MOSES project, Task 3. (<test-setup2008.doc>)
66
iproute2 software package. ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/iproute22.2.4-now-ss990824.tar.gz