Quality of Service Architectures for Wireless Networks: IntServ and DiffServ Models Indu Mahadevany and Krishna M. Sivalingamz  School of Electrical Engineering and Computer Science Washington State University Pullman, WA 99164 yE-mail: [email protected]. zE-mail: [email protected]. Phone: (509)-335-3220. Fax: (509)-335-3818 ;

Abstract Guaranteeing Quality of Service (QoS) in the Internet has been proposed using two different models – the Integrated services (IntServ) model and the Differentiated services (DiffServ) model. IntServ uses the per-flow approach to provide guarantees to individual streams, while DiffServ provides aggregate assurances for a group of applications. Both these models have been designed to work for wired networks. Our aim is to identify modifications that need to be made to make them suitable for wireless networks. In this paper, some possible modifications to the IntServ and DiffServ models for use with wireless networks are presented. A description of an experimental testbed built to implement and test the proposed enhancements, and results from the testbed are also provided.

1 Introduction The current Internet architecture with its best effort service model is inadequate for new classes of applications that need Quality-of-Service (QoS) assurances. Solutions to providing QoS and accommodating the large number of users range from providing substantial network bandwidth increase to using various bandwidth management approaches. While the big versus managed bandwidth debate goes on, many Quality of Service (QoS) mechanisms are being proposed to manage bandwidth and provide service assurances. The basic way to provide QoS is to provide differential service for certain packet-level or session-level treatment for: (i) giving one user priority over another, and/or (ii) to control the bandwidth usage of certain users so that QoS can be assured.  Corresponding Author. Part of the research was supported by Air Force Office of Scientific Research grants F-49620-97-1-0471 and F49620-99-1-0125, and by Telcordia Technologies (formerly Bellcore).

Traffic management to provide differential services follows two different approaches [1]: (i) Reservationbased: In this model, network resources are explicitly identified and reserved. Network nodes classify incoming packets and use the reservations to provide QoS. The Integrated Services (IntServ) model [2] is based on this approach. (ii) Reservation-less: In this model, resources are not explicitly reserved. Instead, traffic is differentiated into a set of classes, and network nodes provide priority-based treatment based on these classes. The Differentiated Services (DiffServ) model [3] is based on this approach. There are various IETF (Internet Engineering Task Force) groups working on the definition, implementation and performance evaluation of the IntServ and DiffServ models. Currently both these methodologies have been designed for use with wired networks. With the growing use and popularity of the wireless data networks, it is important that these mechanisms be extended to suit the wireless domain as well. To achieve this, the major features of wireless networks must be considered namely: (i) High losses, (ii) Low bandwidth, (iii) Battery power constraints and (iv) Mobility. In this paper, enhancements of the IntServ and DiffServ approaches for use with wireless networks are discussed. There have been other efforts on reservation which are not based on the IntServ or DiffServ models [4]. An experimental testbed using 2Mbps Lucent WaveLAN cards and CBQ scheduling has been set up with systems running FreeBSD. A description of the implementation and preliminary results from different experiments are presented in this paper.

2 IntServ and DiffServ Framework An introduction to IntServ and DiffServ models and the differences between them are discussed in this section.

2.1 Integrated Services The IntServ [2] model identifies three main categories of services that can be provided to users: (i) Best effort services are characterized by absence of a QoS specification and the network delivers the best possible quality, (ii) Guaranteed services provide users with an assured amount of bandwidth, firm end-to-end delay bounds, and no queueing loss for flows1 , and (iii) Controlled load services assure that the users will get service that is as close as possible to the one received by a best-effort service in a lightly loaded network. For the current Internet architecture to support IntServ capability, two features are required [2]: (i) A method to communicate the application’s requirements to network elements along the path and to convey QoS management information between network elements and the application. (ii) Individual network elements (subnets and IP routers) along the data packet path must support mechanisms to control the QoS delivered to these packets. QoS support mechanisms at network elements can be provided by various packet classifying and scheduling mechanisms. Some examples include Class Based Queueing (CBQ) [5] and Weighted Fair Queueing. The communication of the flow requirements is done using ReSerVation Protocol (RSVP) [6]. RSVP is a signaling mechanism to carry the QoS parameters from the sender to the receiver to make resource reservations along the path. The mechanism works as follows: (i) The sender of an application sends PATH messages containing the traffic specifications to the receiver(s) of the application that will use this reservation. (ii) The receiver receives this PATH message and sends RESV message to the sender specifying the flow it wants to receive. (iii) As the RESV message flows back to the sender, reservations are made at every node along the way. If at any point along the path the request cannot be supported, that request is blocked. (iv) At every router/host along the way, path and reservation states are maintained for every application session. Periodically sent PATH and RESV messages refresh the path and reservation states. The basic features of IntServ (and RSVP) can be summarized as: (i) it provides per-flow reservation, (ii) each application (flow) reserves resources using RSVP to signal QoS requirements, (iii) quantitative QoS based on the traffic descriptors is provided for every flow, and (iv) every node along the path from the sender to the receiver maintains state information.

1A

flow is an application session between a sender and a receiver.

2.2 Differentiated Services While IntServ provides per-flow guarantees, DiffServ follows the philosophy of mapping multiple flows into a few service levels – an approach termed as Class of Service (CoS). The 8-bit TOS (Type of Service) field in the IP header has been included to support packet classification. Recently a new format and use of TOS field for packet classification has been proposed as part of the DiffServ architecture [3]. The TOS byte is divided into 6 bit Differentiated Services Code Point (DSCP) field and a 2-bit unused field. A service type is constructed by a combination of: (i) setting DSCP bits in the IP header at network boundaries, (ii) using these bits to determine how packets are forwarded by the nodes inside the network, and (iii) conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. DiffServ is realized by mapping the DSCP contained in the IP packet header to a particular treatment or per-hop behavior (PHB), at each network node along its path. There are various PHBs being defined. For example, Assured Forwarding Service (AF PHB) [7] gives the customer the assurance of a minimum throughput, even during periods of congestion. DiffServ does not have any end-to-end signaling mechanism and works based on a service level agreement between the provider and the user. All packets from a user are marked to specify the service level agreement and are treated accordingly. The components of a DiffServ network include packet classifiers, a traffic profile and traffic conditioners. The basic features of a DiffServ architecture are summarized as: (i) multiple flows are mapped to a single service level, (ii) qualitative QoS assurances are provided to applications using various service levels, and (iii) state information about every flow need not be maintained along the path.

3 IntServ and DiffServ for Wireless Networks A Quality-of-Service architecture that extends Diffserv and Intserv to wireless networks should consider these main network characteristics: (i) High losses, (ii) Low bandwidth, (iii) Battery power constraints and (iv) Mobility. The enhancements for IntServ and DiffServ that consider these factors are discussed in this section. In this study, wireless data networks based on a campus-based network architecture are considered as shown in fig. 1. The campus network is composed of various departmental subnets that are connected to a campus subnet, which is connected to the Internet. The campus is divided into various regions and each region (or cell) has

a base station (BS) serving all mobiles within its coverage region. The BS provides the mobile with connectivity to the wired world. When a mobile moves to another region, it is handed off to the BS serving that region.

Internet

R1

Campus Network Departmental Network

R2 R4

R3

Subnet A

BS

BS

Subnet B

BS

Subnet C

BS

BS

BS

Figure 1: Architecture of a Campus Network.

3.1 Enhancements Common to IntServ and DiffServ Framework QoS parameters for typical applications include bounds for bandwidth, packet delay, packet loss rate, and jitter. Certain additional parameters that deal with problems unique to wireless and mobile networks are required. They are enumerated below. Losses in Wireless Networks: Packet loss in a mobile environment is an important issue to consider because of the limited bandwidth of a wireless network and the possible fading and blackout situations that can occur when a mobile moves from one cell to another. It will be advantageous to applications if they can characterize a way in which packets should be dropped in such cases. The QoS parameter “loss profiles” [8] gives applications an opportunity to choose between a bursty loss or a distributed loss in case of an overloaded situation. An audio application may choose to have a bursty loss because the output is still tangible if a few words are dropped. A distributed loss is better for a video application because it will appear as a flicker on the screen. Power Restrictions: Mobile systems use limited power batteries and hence have power restrictions that must be taken care of. The network interface card of the computer consumes almost 14% of the total power [9]. Transmitting and receiving of packets expend power and will have to be controlled when the mobile battery power is low. Therefore, the BS needs to be aware of the power situation in the mobile so that it can change the way data is sent to the mobile. The “power level” parameter informs the BS about the battery power situation in the mobile and the BS

changes the way it schedules packets based on the “power profiles” parameter. The power profile parameter categorizes the way packets must be sent in a low power situation. While some applications would like to reduce the average rate of sending data others may choose to send some important packets as in layered video. Mobility: Maintaining a reservation when a mobile moves between regions is a challenge because of possible blackout situations during handoff. A scheme is required to define how smooth this transition should be since it affects the QoS of an application. The “probability of seamless communication” parameter [8] defines the nature of breaks that can be allowed in the service. Based on this parameter, advance buffering at the neighboring cells must be made so that the data is available when the mobile moves into that region. QoS parameters that are specific to wireless and mobile networks, and are common to both IntServ and DiffServ models were introduced in this section. The factors that are individual to the two approaches are discussed next.

3.2 Modifications to IntServ Scheme Using the current refresh scheme for RSVP signaling messages imposes a lot of burden on the wireless/mobile networks. Resources are reserved on a particular route between a sender and destination in this scheme and any change in route caused by mobility will result in data flowing across paths where reservations are not made. This destroys any QoS guarantees and thus changes to the resource reservation mechanism are necessary. Bandwidth Restrictions: One of the major concerns with soft-state protocols like RSVP is scalability. Many RSVP flows across the wireless link can cause a lot of control information to flow across the wireless link. With wireless networks currently being low bandwidth systems, this is a point of concern. RSVP refresh messages are periodically sent to detect any underlying network changes like route changes. Since there is only one wireless hop between a mobile and a BS, refresh messages need not be sent as often on the wireless link. This will help reduce the amount of control information on the link. Power Restrictions: Minimal use of the transceiver to send/receive packets is required to conserve power. All data packets need to be sent whereas we can control the amount of control information that is sent on the wireless link. For example, all RSVP refresh messages can be sent only in one direction – from the mobile to the BS. This prevents the mobile from receiving unnecessary control messages. Also information like battery power level can be sent as part of these refresh messages. Mobility: Mobility introduces the need to make reservations in advance between neighboring BSs because a mobile may move into one of their regions. Making reserva-

tions just before a mobile moves into a cell may be disadvantageous because: (i) resources may not be available, and (ii) data can be delayed/lost during the period it takes to setup a new reservation. The concept of “passive reservations” [10] is used here to maintain reservations during mobility. Passive reservations are made from the BS of the cell where the mobile currently resides to all neighboring BSs. The mobile may move into any one of these cells and use the resource. This means the reservations made to some of the neighboring cells may not be used. To eliminate the wastage of resources that can occur, passive reservations can be used by other mobiles in the cells until the mobile in question needs to use the reservation. More details of the modifications to this scheme can be found in [11, 12].

3.3 Modifications to DiffServ Scheme Various features of wireless networks require that a lightweight signaling protocol be added to the Diffserv model as discussed below. Need for Signaling Information: DiffServ architecture does not require end-to-end signaling and follows an implicit admission control mechanism. In wireless networks a simple signaling scheme would be required and advantageous because: (i) static provisioning is not enough because user mobility necessitates dynamic allocation of resources, (ii) the sender must know the limitations of the wireless link for better performance, and (iii) information on local conditions like power status of the mobile etc. need to be sent occasionally between the BS and the mobile. A signaling protocol that can be used is a modified ICMP (Internet Control Message Protocol). The modified ICMP protocol is scalable and generates reduced control traffic when compared to RSVP [13]. Classification of packets within a flow: Currently DiffServ provides a mechanism to treat all packets within a flow equally. A distinction can be made between a packet which is in/out of profile but all in-profile packets are treated the same. In many situations, it may be necessary to distinguish the various packets within a particular flow. This is because some packets from a flow could be more important than the others and a local condition like power level warrants its use. The packets in a flow must be distinguishable based on information in the DSCP field. One bit (or two bits) of the DSCP field is chosen to convey the relative importance of packets. This section summarized the modifications to the Diffserv and Intserv models for extending them to wireless and mobile networks. Details of an experimental testbed based on the various enhancements proposed are provided in the next section.

4 Experimental Testbed The experimental testbed has three Pentium systems that operate as base stations. Each base station is equipped with an Ethernet card and a 2.4GHz WaveLAN [14] ISA card. The base stations are in adjacent cells and the different Network Identifiers (NwID) of the WaveLAN cards identify the cells. The testbed also has two mobiles which are equipped with 2.4GHz PCMCIA WaveLAN cards. All the systems run FreeBSD 2.2.2. The testbed uses RSVP code version 4.2a2 [15] and alternate queueing package version 0.4.2 [16]. FreeBSD WaveLAN drivers that support roaming are used in the system. The link level beacons produced by the base stations help the mobiles identify a particular cell. Modified IntServ and DiffServ implementations incorporating the enhancements as described in section 3 are used in the testbed (Software can be obtained from [17].). The testbed uses various traffic generating applications to test the architecture.

4.1 Experimental Results In this section results from some of the experiments conducted on the testbed are presented. We include results from the experiments on mobility and results from different bandwidth compensation schemes. More details of the various experiments conducted can be obtained from [11–13]. Mobility in Wireless Networks The allocation of bandwidth in DiffServ and IntServ mechanisms during mobility are discussed here. Accommodating Mobility with DiffServ: The experiments show two methods of accommodating a new mobile in a cell. In the first case, a certain percentage of the bandwidth is reserved for the new mobiles entering the area. In the second case, a lower priority application is asked to relinquish some of its bandwidth for the new application. The experimental setup consists of a sender (wired host), two base stations and two mobiles. The working of both the scenarios are described with the use of fig. 2(a) and (b). In fig. 2(a), User 1 and 2 are users in the system. At time instance shown as (2) a new mobile enters this region and uses the new-mobile class (shown as (3) in the figure). After the characteristics of this new flow are obtained, the application is placed in a different class named user 3 (shown as (4) in the figure). In fig. 2(b) User 1 and 2 are users in the system. At time instance shown as (2), a new mobile enters this region and a low priority application user 2 is asked to relinquish some of its bandwidth. Conveying of various information

during mobility uses the modified ICMP protocol. Total Traffic 1

1 (1) (5)

(2)

User 1 & User 2

Traffic (Mbps)

Traffic (Mbps)

1.5

User1

0.5

(3)

(1)

0.5 (3)

(4)

(2)

User 3

Mobile

0

new-mobile

0

0 0

10

(a)

20

30

40

50

100

150

200

Time (sec)

Time (sec)

(1)

Traffic (Mbps)

User2

Figure 3: Bandwidth Allocation During Mobility in IntServ Networks.

User 1

0.4

(2)

User 3

0.2

User 2

0 0

10

(b)

20

30

Time (sec)

Figure 2: Bandwidth Allocation During Mobility in DiffServ Networks. Accommodating Mobility with IntServ: While bandwidth allocation for new mobiles is made in DiffServ, IntServ requires that signaling be done to reserve resources. As mentioned earlier, every BS makes passive reservation with the neighboring BSs on behalf of the mobile. These passive reservations can be used by other applications in the cell until the mobile in question requests the data. Initially User1 and User2 are sending data that was reserved for them (shown as (1) in the figure). After that, User1 starts sending more data than what was alloted to it (shown as (2) in the figure). User1 is provided the necessary bandwidth because the reservation made for the Mobile is passive and is not yet used by the Mobile. We thus see that unused reserved bandwidth is not wasted if another application needs it. After handoff occurs, the mobile moves into the BS’s region and the passive reservation is made active (shown as (3) in the figure). Now the Mobile starts sending data and so the bandwidth of User1 reduces to its reserved rate. User2 is conforming to its reserved rate and hence is not affected. High Losses in Wireless Networks Experiments done on compensation of bandwidth during

high losses using the DiffServ approach is discussed here. With high loss rates, even though the sender (BS or mobile) is sending the amount of data that is agreed upon, the receiver may not get this required rate. There is a need to compensate such classes with extra bandwidth when necessary. Compensation can be provided in two ways: (i) by increasing the bandwidth of a particular class while reducing the equivalent amount from the compensation class, or (ii) by allowing some packets from the flow that needs to be compensated to use the code point of the compensation class. The experimental setup consisted of a sender, a BS and a mobile. The receiver monitors the bandwidth received and sends information to the BS which uses the reserved compensation bandwidth to provide additional bandwidth. Both the methods mentioned above are discussed with the use of fig. 4(a) and (b) which denote the cases (i) and (ii) mentioned above respectively. Fig. 4(a) shows how compensation is provided for any class that requires extra bandwidth. Initially the user class is sending data at a rate of around 0.23 Mbps while the bandwidth of the compensation class is around 0.4 Mbps. At time instant denoted as (1) in the figure, a feedback from the receiver arrives and there is a need to compensate the particular user class. The bandwidth of the compensation class is reduced to around 0.18 Mbps while the user gets this extra bandwidth to send data at the rate of 0.4 Mbps. After the class has been compensated for a while, the user class reverts to its original rate (denoted as (2) in fig. 4(a)). The method of re-marking some packets in a flow to use the compensation bandwidth is shown with the help of fig. 4(b). At the instant denoted as (1), a bandwidth report arrives from the mobile and there is a need to compensate the class with extra bandwidth. A fraction of the input packets that need to be compensated are re-marked as the

compensation class and sent. The bandwidth of the original class is maintained at 0.2 Mbps and data is sent at this rate. Effectively between the instant (1) and (2), the user class is able to send 0.3 Mbps of data (0.2 Mbps from the original allotment and 0.1 Mbps from the compensation class). User class Compensation Class

Traffic (Mbps)

0.4

0.2

1

20

40

60

80

User Class Compensation Class

Traffic (Mbps)

[5] S. Floyd and V. Jacobson, “Link-sharing and resource management models for packet networks,” IEEE/ACM Transactions on Networking, vol. 3, pp. 365–386, Aug. 1995.

[7] D. Clark and J. Wroclawski, “An Approach to Service Allocation in the Internet.” Internet draft: draft-clark-diff-svcalloc-00.txt, July 1997.

Time (sec)

(a)

[4] S. K. Das, N. K. Kakani, R. Jayaram, and S. K. Sen, “Reservation Mechanisms for Mobile Nodes in the Internet,” in Proc. IEEE Vehicular Technology Conference, 1999. (To Appear).

[6] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala, “RSVP: A New Resource ReSerVation Protocol,” IEEE Network, vol. 7, pp. 8–18, Sept. 1993.

2

0 0

[3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Services.” IETF draft, draft-ietf-diffserv-arch-01.txt, Aug. 1998.

[8] S. Singh, “Quality of Service guarantees in mobile computing,” Computer Communications, vol. 19, pp. 359–371, Apr. 1996. [9] M. Stemm and R. H. Katz, “Measuring and reducing energy consumption of network interfaces in hand-held devices,” IEICE Transactions on Fundamentals of Electronics, Communications, and Computer Science, Aug. 1997.

0.2

0.1

1

2

0 0

20

(b)

40

60

80

Time (sec)

Figure 4: Compensation for Classes with High Losses.

5 Summary This paper discussed the enhancement of Integrated and Differentiated service approaches for QoS in the Internet to be extended for wireless networks. These extensions have been implemented in a experimental testbed. Some experimental results based on the allocation of bandwidth during mobility and compensation during losses were discussed as an example of the working of the schemes. More details on results from various experiments can be found in [12, 17].

Acknowledgments The authors thank Dr. C. S. Raghavendra for his support.

References [1] “Trillium IP Quality of Service white paper.” http://www.trillium.com/whats-new/wp ipqos.html. [2] J. Wroclawski, “The Use of RSVP with IETF Integrated Services.” RFC 2210, Sept. 1997.

[10] A. K. Talukdar, B. R. Badrinath, and A. Acharya, “MRSVP: A Reservation Protocol for an Integrated Services Packet Network with Mobile Hosts.” Tech report TR-337. Rutgers university. [11] I. Mahadevan and K. M. Sivalingam, “An Experimental Architecture for providing QoS guarantees in Mobile Networks using RSVP,” in Proc. IEEE PIMRC ’98, (Boston, MA), Sept. 1998. [12] I. Mahadevan and K. M. Sivalingam, “An Architecture for QoS guarantees and routing in wireless/mobile networks,” in Proc. ACM Intl. Workshop on Wireless Mobile Multimedia (WoWMoM), (Dallas, TX), pp. 11–20, Oct. 1998. [13] “Quality of Service in Wireless Networks using Enhanced Differentiated Services Approach.” http://www.eecs.wsu.edu/˜imahadev/techreport/TRDAWN-99-01.ps. [14] “Wavelan Cards.” http://www.wavelan.com. [15] “RSVP code rel4.2a2.” ftp://ftp.isi.edu/rsvp/release. [16] “Code for alternate queueing altq-0.4.2.” http://www.csl.sony.co.jp/person/kjc/kjc/software.html. [17] “Home page of Indu http://www.eecs.wsu.edu/˜imahadev.

Mahadevan.”