RSVP etc - · Web viewIf 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

VTT INFORMATION TECHNOLOGY

Resource Reservation and Service Quality

Version 3.0 13.12.99

Resource Reservation and Service Quality - 2 –

Version history

Version Date Author(s) Description< 1.0 29.10.98 Jan Lucenius1.0 11.12.98 Jan Lucenius1.1 30.12.98 Jan Lucenius minor changes1.2 15.1.99 Jan Lucenius minor changes2.0 11.3.99 Jan Lucenius Structure changed – still not final2.1 Jan Lucenius minor changes2.2 20.10.99 Jan Lucenius and

Juha Koivistostructural changes

2.3 27.10.99 Jan Lucenius and Juha Koivisto

spelling corrections etc.

2.4 01.11.99 Diffserv chapter reorganised2.5 ...9.12.99 Jan Lucenius and

Juha KoivistoText about test results and QoS API included


Chapter about experiments and points to study updated


Minor editorial changes. Final deliverable.

Inspection status

Accepted by Signature Date

Contact information

Jan LuceniusVTT Information TechnologyP.O. Box 1202, FIN-02044 VTT, FinlandStreet Address: Otakaari 7 B, Espoo Tel. +358 9 4561, fax +358 9 456 7013Email: [email protected]: http://www.vtt.fi/tte/


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


ABSTRACT

The steadily increasing use of internet is reflected in varying quality of service seen from the user point-of-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.


TABLE OF CONTENTS

1 Introduction.......................................................................................................................................... 71.1 Purpose of this report..............................................................................................................................71.2 QoS in Internet........................................................................................................................................7

1.2.1 What is QoS?................................................................................................................................................ 71.2.2 Classification of applications / traffic............................................................................................................ 81.2.3 Delay............................................................................................................................................................ 81.2.4 Jitter and Bandwidth..................................................................................................................................... 81.2.5 Data loss....................................................................................................................................................... 9

1.3 Providing better quality of service into internet........................................................................................91.3.1 Integrated services........................................................................................................................................ 91.3.2 RSVP............................................................................................................................................................ 91.3.3 Priority based QoS........................................................................................................................................ 91.3.4 Diffserv....................................................................................................................................................... 101.3.5 DRP............................................................................................................................................................ 111.3.6 Process priorities in the user's workstation...................................................................................................111.3.7 AREQUIPA................................................................................................................................................ 111.3.8 Switching.................................................................................................................................................... 111.3.9 Alternative approaches................................................................................................................................ 12

2 RSVP and Intserv............................................................................................................................... 142.1 Description of RSVP.............................................................................................................................14

2.1.1 Intserv......................................................................................................................................................... 142.2 Service commitments............................................................................................................................15

2.2.1 Guaranteed service...................................................................................................................................... 152.2.2 Controlled load service................................................................................................................................ 152.2.3 Implementation of traffic control................................................................................................................. 152.2.4 RSVP and charging..................................................................................................................................... 17

2.3 LANs[1]................................................................................................................................................172.3.1 Ethernet...................................................................................................................................................... 172.3.2 FDDI, Token ring........................................................................................................................................ 18

2.4 Frame Relay, SDMS [1]........................................................................................................................182.5 ATM [3]...............................................................................................................................................18

2.5.1 IPSOFACTO............................................................................................................................................... 202.5.2 Tag switching [1]........................................................................................................................................ 212.5.3 NetFlow switching [1]................................................................................................................................. 21

2.6 Mobile connections...............................................................................................................................212.6.1 Mobile IP and RSVP................................................................................................................................... 21

2.7 Slow connections (Dial-up, PPP)...........................................................................................................222.8 Reservation styles and scalability of RSVP............................................................................................23

2.8.1 Reservation styles....................................................................................................................................... 232.9 Discussion.............................................................................................................................................23

3 Diffserv............................................................................................................................................... 253.1 Diffserv.................................................................................................................................................253.2 Use of TOS field in RFC1349 and Mgen...............................................................................................263.3 Diffserv Code points.............................................................................................................................273.4 Assured forwarding...............................................................................................................................283.5 Expedited forwarding............................................................................................................................293.6 Interoperability PHB group...................................................................................................................293.7 Feedback in Diffserv.............................................................................................................................293.8 Bandwidth brokers................................................................................................................................303.9 SIMA....................................................................................................................................................31

4 Intserv and Diffserv combined............................................................................................................ 334.1 Sample Network with Intserv and Diffserv Regions [5].........................................................................334.2 QoS API...............................................................................................................................................354.3 Bandwidth Broker.................................................................................................................................37


5 Points to study / test setup................................................................................................................... 385.1 Linux traffic control..............................................................................................................................385.2 Process priorities...................................................................................................................................395.3 Router priorities....................................................................................................................................405.4 Intserv...................................................................................................................................................415.5 Diffserv.................................................................................................................................................415.6 Different methods combined and compared...........................................................................................41

6 Summary / Conclusions...................................................................................................................... 437 References.......................................................................................................................................... 44


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 long-term 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.


1.2.2 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.

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

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.

1.3.6 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.

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 two-year 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.


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.


2.2.1 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.


_____________________________________________________________ | ____________ ____________ ___________ | | | | | 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

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 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 RSVPRSVP ATM

QoS is requested by receiver by senderReservation is separated from routing concurrently with VC-setupvariable QoS dynamic staticconnection management dynamic (soft states) static (hard states)reservation styles fixed and shared fixedheterogenity supported not supported


scalability merging ?

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 !).

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. 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.

Figure 5. Point-to-multipoint session

2.5.1 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.

AE F

B

CVC shortcuts


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.

2.5.2 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.

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 low-bitrate 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 scalabili ty of RSVP

2.8.1 Reservation styles

The following styles are currently defined ([8]):

Wildcard-Filter (WF) StyleA 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) StyleAn 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) StyleAn 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 over-speaking). 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 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 real-time 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.


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:


+--------------+ | 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].


0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TOS | MBZ | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+

Figure 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])

IPTOS_TOS_MASK 0x1E IPTOS_TOS(tos) ((tos) & IPTOS_TOS_MASK)1000 -- IPTOS_LOWDELAY 0x10 TOS = 160100 -- IPTOS_THROUGHPUT 0x08 TOS = 80010 -- IPTOS_RELIABILITY 0x04 TOS = 40001 -- IPTOS_LOWCOST 0x02 TOS = 20000 -- normal service TOS = 0 IPTOS_MINCOST IPTOS_LOWCOST

Table t3. Precedence:

111 -- IPTOS_PREC_MASK 0xe0 TOS = 224 IPTOS_PREC(tos) ((tos) & IPTOS_PREC_MASK)111 -- IPTOS_PREC_NETCONTROL 0xe0 TOS = 224110 -- IPTOS_PREC_INTERNETCONTROL 0xc0 TOS = 192101 -- IPTOS_PREC_CRITIC_ECP 0xa0 TOS = 160100 -- IPTOS_PREC_FLASHOVERRIDE 0x80 TOS = 128011 -- IPTOS_PREC_FLASH 0x60 TOS = 96010 -- IPTOS_PREC_IMMEDIATE 0x40 TOS = 64001 -- IPTOS_PREC_PRIORITY 0x20 TOS = 32000 -- IPTOS_PREC_ROUTINE 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:


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 | +----------+----------+----------+----------+


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 Interoperabili ty 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.

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 ECN-bits 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 DS-marked 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


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


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 reservation6 = excellent quality: negligible packet loss ratio 5 = high quality: packet losses only during exceptional traffic peaks4 = good quality: small packet loss ratio even during busy hour3 = moderate quality: usually small packet loss ratio except during busy hours2 = satisfactory quality: from time to time very high packet loss ratio1 = suitable for best-effort traffic during busy hour0 = 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.


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.


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 Diffserv-compliant. 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.


Table t6. Diffserv vs. Intserv in stub and transit networks.

Scenarioclient stub – transit – server stub

advantages + drawbacks - notes

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 - possible scaling problems on high-end servers

described above

4 Diffserv – Intserv - Diffserv - scaling issues are alleviated by the use of aggregation and/or Diffserv

- 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

5 Diffserv – Intserv – Intserv and6 Intserv – Diffserv - Diffserv

Diffserv preferable where scalability is critical

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.


Application

QoS SP

traffic.dll

Netcard

PacketScheduler

ProtocolStack

3rd partytraffic

managementapplication

Winsock2GQoS API

Traffic ControlAPI Interface

(TCI)

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.


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.


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.


Figure 12. A Linux traffic control experiment

5.2 Process priorit ies

Figure 13. Process priorities test

38 kbit/s

• MP3 player

• Netscape

10 Mbit/s 10 Mbit/sRouter

• MP3 server (24 kbits/s)

• http server

tc

FTP serverUDP sourceFTP clientUDP sink

Prioritise flows by modifying process priorities in the receiving host


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.

Figure 14. Router priority test network

The configuration depicted in figure 14 was tested. Files were transferred from st1-053.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.

10M

switch 1G router 1G router 1G csc-rtr1-11

linguine router

st1-053 10M


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.


The planned tests, of which all will not be carried out here, are described in [65].

Figure 15. Suggestion for test setup in MOSES

transit networkMediapoli, Funet

Solaris ws

Linux ws

Cabletron switch

Linux GW/router

Linux ws(amidala)

Sun ws(anakin)

Cisco router at LUT

SUN ws

st1-034 (192.168.1.1)

st1-053 (cello)(212.68.2.53)

Solaris ws

st1-051 (212.68.2.51)

celegorm ?(157.24.23.63)

ppp link


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.


7 REFERENCES

1 U. Schwantag. An Analysis of the Applicability of RSVP. Diploma Thesis. University of Oregon and University of Karlsruhe. June 1997. http://network-services.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/RSVP-exposee.html

4 http://eratosthenes.informatik.uni-mannheim.de/informatik/pi4/events/qos-ws/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/draft-vaananen-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>.


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.tu-berlin.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_rsvp-qos_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. <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-ohlman-receiver-ctrl-diff-01.txt>. 30 september 1998

46 Mehra, A, Verma, D. Architectural Considerations for DiffServ Servers . <draft-mehra-diffserv-servers-00.txt>

47 Karsten M, et. al. An Embedded Charging approach for RSVP, GMD IPSI, 1998

http://src.doc.ic.ac.uk/computing/internet/rfc/rfc2474.txt


48 Kilkki K., Ruutu J. Interoperability PHB Group. Internet draft, October 1999. <draft-kilkki-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-setup-2008.doc>)

66 iproute2 software package. ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss990824.tar.gz

ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss990824.tar.gz

ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss990824.tar.gz

http://www.ittc.ukans.edu/~kdrao/845/

http://manimac.itd.nrl.navy.mil/MGEN/MgenUserGuide.html

http://mip.ee.nus.edu.sg/

http://intel.com/ial/rsvp/

http://channels.microsoft.com/hwdev/network/qos/