QoS in multi-service IP networks

QoS in multi-service IP networks Vasco Nuno Sousa Simões Pereira Department of Informatics Engineering of the University of Coimbra vasco@dei.uc.pt Abstract Today, an increasing number of applications and services are migrating from their usual mediums to embrace a new multi-services Internet. At the same time Internet also grows out of its original scope to create a new generation of mobile users. All this changes are creating new needs. New services like video streaming or Voice over IP (VoIP), demand guarantees that Internet Protocol (IP) was not designed to assure. In this paper, Quality of Service will be addressed as a response to the new emerging needs, trying to assure users a new level of experience. Some techniques available today like IntServ and DiffServ will be explained and considerations will be made about the new challenges and ways to solve them. 1. Introduction Quality of service (QoS) is a broad term used to describe the overall experience a user or application will receive over a network. International Telecommunication Union s Telecommunication branch s (ITU-T s) defines Quality of Service as the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs and also as the collective effect of service performances, which will determine the degree of satisfaction of a user of service. [1] The growth of Internet brought with it an increasing demand for new kinds of services, as well as the vast audience it created increased the will of developers and operators to get a share of the newborn market. At the same time new contents were digitalized, previous analogue services became digital and a new demand for mobile solutions was created. The aim is now to create a multi-service data network that can deliver to the end user, new and old services, with a quality that is at least equal to the one that services through different mediums offer today. However, IP networks, the most probable convergence platform (the only that has already demonstrated its validity via a worldwide acceptance as the basis technology for the Internet), were not designed to support services that depend on strict rules of quality of service to be deployed. In this paper we will start by trying to give some leads on how to measure the quality in a data network, either by technical measures as by perceptive results. Next we will overview the mechanisms that today, try to assure a determined QoS in IP networks. Finally some of the challenges that are still open will be exposed, together with new approaches that are trying to solve them. This paper was made in the scope of the MSc. on Informatics and Systems, 2003/2005 edition, and tries to expose some of the research work carried out during Seminar I by the author, in the area of Communications and Telematic especially in what concerns QoS over Data Networks. 2. Why do we need QoS? Looking to the near past, we will find a mixture of different networks each dedicated to a particular application or service. We had a telephone line for voice communication (POTS Plain Old Telephony System), an IP network for Internet, a multi-protocol LAN (e.g. Internet Protocol - IP, Internetwork Packet Exchange - IPX), Integrated Services Digital Network (ISDN) line for video-conferencing, cable or analogue wireless for TV, the examples are many. With all this different channels the need for QoS was small or almost negligible, since the traffic in each particular network was very similar and was fine-tuned to meet the particular needs for each application or service. The explosive growth of the Internet together with the digitalization of all kinds of contents, and the need to reduce operational costs and/or improve profit margins is now changing the scenario. The new keyword is convergence. Convergence to a multiservice network will enable network operators to provide a new sort of interactive, multimedia and real-

time services, while using more efficiently the installed capacity. Furthermore, as a result of this process, it will be possible to reduce the costs of having different kinds of technologies and equipment. At the same time, service providers will also benefit from this convergence as they gain access to a wider audience with a very small overhead, due to the fact that all services use the same communications platform, as well as to a universal storage solution for different types of contents. The ultimate goal will then be the ability to provide all services to different access methods with minimum changes (e.g. TV in mobile devices, interactive TV with Internet access). The end user will gain by having access to a new type of interactive integrated services with similar or better experience than before, through only one medium. The success of the Internet, with its wide-scale adoption, the fact of not being owned by any group, and the ability to run over multiple link layer technologies (e.g. Asynchronous Transfer Mode - ATM, Ethernet, Point-to-Point Protocol - PPP, Multi- Protocol Label Switching - MPLS), makes IP the ideal choice for the end-to-end convergence layer to be created. Furthermore, Internet itself, due to user pressure and business opportunities, is already bringing to IP platform many applications and services, helping the expected convergence. Nevertheless, the convergence of different types of traffic to an IP based solution, in the same network, while having the clear benefits exposed, also brings new problems that were not addressed earlier. The IP protocol was initially designed to move data packets from one place to other without concerns about the time the packet takes in the journey, using a besteffort approach. The best-effort model means that every packet in the network is treated equally. If we think of real-time applications, like video streaming or voice applications, we can understand that this approach is no longer valid. The best-effort approach used in today s Internet has varying amounts of packets loss and random delays which are inadmissible in this new kind of multi-service IP network. One of the usual but misleading approaches to the problem of having different kinds of traffic with different needs, over the same network, is to think that the solution can be obtained by increasing the available bandwidth. While it is true that an infinite bandwidth would theoretically solve our problems, we must bear in mind that high capacity connections are not available through all network, from source to destination of traffic. Although installing this new bandwidth in backbones could be relatively easy (if money is available) it will take a long time to upgrade the all network, especially in the parts next to users. Also, there is the risk of having one piece of the network with a restricted bandwidth, leading to unpredictable results in the global network, since this discontinuity in the high bandwidth network would be a potential bottleneck for a great amount of traffic. Another problem is that by using an over dimensioned bandwidth solution, the network needed to be dimensioned according to peak hour traffic, leaving a large amount of capacity without use most of the time. Also, as wireless networks become more and more important, another bandwidth problem arises. Wireless networks have limited capacity as a result of restrictions on the radio frequencies and on the portable equipment that is used (due to the energy needs to sustain high rates of transmission). To sum up, to avoid the bandwidth solution, we can recall Moore s Law in one of its corollaries: As you increase the capacity of any system to accommodate user demand, user demand will increase to consume system capacity [2]. For all that has been stated it is clear that a new kind of approach must be used in IP networks. In order to guarantee the QoS that the user needs, a new kind of techniques must be applied to services whose differentiation will permit the network to accommodate heterogeneous application requirements and fulfil user expectations. At the same time differentiated pricing for Internet services must be made possible. 3. Measuring QoS The QoS requirements of users connected to a data network are a statement of the level of quality the users expect to get from the applications they run or from the services they subscribe. But, how can we estimate service quality? This question is important as the user must be able to quantify or, at least, identify, if the service he is paying for is the one he is getting. The Service Level Agreement (SLA) made with the network operator must be based on a mutual understanding of how the quality of that service is going to be measured. Usual measurements like delays or lost packages percentages, although meaningful for network technicians, may have no immediate meaning to an ordinary user. A user that is using a point-to-point real-time communication over the Internet like VoIP (Voice over IP) does not want to know if any of the data packages with audio samples were lost during the transmission, what he wants is to be able to talk with no perceptive flaws, to have the service available when he needs it and to have a reasonable call set-up time. End user experienced quality is as strongly tied to

intrinsic requirement of the service, as is to subjective factors. Measures of end user service quality experience that were made by researchers in speech telephony (with results that can be extrapolated to other services) revealed that user experienced quality is not a constant in time when quality varies, i.e., memory of momentary poor quality fades with time [1]. They also found that the way poor quality affects the quality perception of a service, depends on the psychological context and on the importance that the usage of the service had. So, there are many subjective and psychological factors that can affect user experience. One of the obvious conclusions of this research is that there should always be a high quality communication medium at user disposal for some particular situation, even if it results in a higher bill. Some of the most important QoS parameters that can be measured and monitored are network availability, bandwidth, packet delay, jitter and packet loss. Network availability can have a tremendous impact over QoS, even during small periods of time, due to the discontinuity of the service. To prevent this from happening network operators need to have redundant equipment. As for bandwidth allocation, we must differentiate two different types: Available bandwidth and Guaranteed bandwidth. Available bandwidth means that the user can have a peak of bandwidth of certain width but that amount is not guaranteed in the SLA (Service Level Agreement) with the network operator. This is the case of common ADSL (Asymmetric Digital Subscriber Line) or cable networks. The user may, in case of low traffic, get the maximum bandwidth, but there will be times when this bandwidth will not be achieved. SLA with Guaranteed bandwidth is usually more expensive since the network operator ensures that a minimum bandwidth width and a burst bandwidth are always available. Delay is the time datagrams take from the origin to destiny and depends not only on fixed delays (application delay, transmission over physical medium) but also from variable delays (queuing delays, contention with other traffic at each network node). Although small amounts of delay may be tolerated by applications, big delays may compromise applications such as voice and video. The measure of the delay variation between consecutive datagrams is called jitter. If jitter is not bounded, real-time and delay-sensitive applications (e.g. video streaming), where applications expect a fairly constant rate between consecutive packets, can be greatly affected. Finally, packet loss, the number of packets lost in the network, via errors in the physical medium or by packets drop policies in network nodes due to congestion, as is easily understandable, can dramatically affect QoS. Service quality requirements depend on specific characteristics of each service, therefore changing from one to another. However, some important and relevant characteristics can be pointed (with some examples of services that depend on them): Service availability (e.g. telephony, electronic payments) Continuity (e.g. critical for mobile phones during handovers moving from one base station to other) Protocol Data Unit (PDU) Delivery time (e.g.: crucial for telephony, video streams, interactive application) Throughoutput (e.g.: for file downloads) Support for continuous PDU Transmission (e.g. VoIP) Support for reliable delivery (e.g. downloads, application data) Support for variable transfer rate (e.g. applications with momentary burst needs like VoIP with silence suppression) In order to receive adequate service quality support, applications need to transmit to the network their needs. This can be done by signalling protocols or based on a SLA between the network operator and the end user. Internet Engineering Task Force (IETF) has specified in the Resource Reservation Protocol (RSVP) signalling protocol two kinds of traffic descriptors: Traffic Specification (TSpec) - describes traffic properties like burstiness of a flow Requirement Specification (RSpec) describes service quality support requirements as end-to-end delay, delay jitter and packet loss bounds. If only SLA is applied, the application type is detected at network edge and application defaults are used. 4. QoS Techniques over IP The Internet Protocol (IP) was developed to take each data packet from origin to destination in a way that is neither connection-oriented (there is no connection established between sender and receiver, the message goes to the network with a destination address and hopefully will arrive destination) nor reliable. As a result, the network does not guarantee, at IP protocol level, that a packet of data is delivered to

destination. In case of any error, loss or excessive delay during the trip of the packet, IP just ignores it. This kind of service is called best-effort or unreliable service. All these problems are addressed in upper layers of the protocol stack. The Transmission Control Protocol (TCP) addresses the reliability problem by implementing a retransmission scheme which permits a packet that do not reach destination to be resent by the origin. However, under congestion, and despite some new improvements, like adaptation to available bandwidth, the performance is still poor. User Datagram Protocol (UDP) adds nothing to the reliability of the transmission. It is indicated to realtime traffic as it does not have a retransmission scheme, which is many times useless because when data finally comes, is too late to use it. So, the only way we can guarantee some QoS through the besteffort model is by over-dimensioning the network. QoS is all about giving some traffic higher priority over other traffic. Next we will describe two IETF approaches that provide service quality support in IP by assigning priority to Internet traffic: hop-by-hop based on reservation (Integrated Services) and packet marking at edges of network (Differentiated Services). 4.1. Integrated Services (IntServ) IntServ is an IETF framework, developed to provide multi-service support in the Internet [3]. The two service models currently defined for IntServ are Controlled-Load [4] and Guaranteed QoS [5]. Additionally, IntServ also defines a signalling protocol used to make resources reservation through the network, the Resource Reservation Protocol (RSVP) [6]. Controlled-load service support as stated in [4] provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded. To provide this QoS, clients requesting controlled-load service must provide the intermediate network elements with an estimation of the data traffic they will generate - the TSpec. In return, the service provides the network resources the client needs. In the case that client's traffic fall outside TSpec parameters, the QoS provided to the client may exhibit characteristics indicative of overload, including large numbers of delayed or dropped packets [4], since excess traffic is delivered in a best-effort basis (if sufficient resources exist). Assuming that the network is functioning correctly, applications using controlledload service may assume that, end-to-end network behaviour will resemble a non congested best effort service approach, with similar packet loss ratio and packet transfer delay. Controlled-load was designed to be conceptually simple. The drawback is that it cannot provide guarantees on maximum packet delay and is not able to give distinct treatment to different kinds of application QoS requirements. Guaranteed QoS is another implementation of IntServ that provides firm (mathematically provable) bounds on end-to-end datagram queuing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. [5]. Guaranteed QoS is invoked by sending to each network element the specification of the traffic flow, given by TSpec and RSpec. Given the flow description, each service element (e.g. routers) will calculate its internal parameters to provide support for the new data flow. By combining all the information from every element along the path, it is possible do know the maximum delay a datagram can take from origin to destiny. To create a guaranteed reservation along the network path, is necessary to use a signalling protocol like RSVP, to manually configure routers or to use a network management protocol like SNMP (Simple Network Management Protocol). In order to maintain the delay completely controlled every element in the network path should support guaranteed service. However, clear benefits can be obtained if only on part of that path is covered with guaranteed services although the maximum delay can no more be assured. The way guaranteed services control delay is based in the control of queuing delays, which are the variable part of the total delay (total delay= fixed delay + queuing delay). The other part, the fixed delay, is a property inherent of the path chosen and includes transmission delay, processing in routers, etc. When all network elements conform to the specifications of guaranteed services, and the traffic flow stays within its specified traffic parameters, a sufficient level of bandwidth is assured, with no queuing loss for all conforming datagrams. All datagrams that fail the traffic specification will be treated as best-effort datagrams. In this manner, guaranteed services can provide a clear bound for maximum delay whereas it can not assure a minimal or average delay. This service, which provides added guarantees over controlled-load, is intended for applications that need an assurance from the network that datagrams will be delivered with a maximum predictable delay (e.g. video-streaming).

One of the main problems of IntServ is the enormous amount of information that must be kept in each of the network nodes. Although not very perceptible in low traffic networks, when we talk about high traffic networks, with thousands of simultaneous flows, the need to maintain the necessary flow information and to access router database entries implies a great amount of overhead. Figure 1 Integrated Services reference model with RSVP (simplified) [2] [3] [6] Every resource reservation system needs a signalling protocol to the setup of resource reservations in the network. IntServ Framework defines Resource Reservation Protocol (RSVP) [6] as a service quality signalling scheme to be used by the communication endpoints to request service from the network. A simplified scheme of IntServ model with RSVP, showing in the upper level the reservation process and in the lower level the traffic forwarding process, is presented in Figure 1. Nevertheless, RSVP is independent from IntServ model and can be applied to other QoS services, just as IntServ can be used with other signalling protocols. RSVP operates on top of IPv4 or IPv6, in the transport layer of the protocol stack, not transporting application data but rather working as an Internet control protocol like ICMP (Internet Control Message Protocol), or routing protocols. It can both work with unicast and multicast applications, adapting dynamically to changing group membership or changing routes. In order to make the needed resource reservation, the sender sends Path messages, which record the route packets travel to receiver, together with traffic characterization information (the Path message is required to carry a sender TSpec, which defines the traffic characteristics of the data flow that the sender will generate). When the packet reaches destination the upstream reservation process begins. A Resv (RSVP Reservation Request) message is then sent by the receiver, to reserve the needed capacity from the network, travelling the same path that previous Path message travelled. After the reservation completes application data may be sent. Since the RSVP performs a soft state reservation along the network path, it is necessary that the receiver does a periodic reservation refresh, or the reserved capacity will expire. RSVP does not need to be supported by all the routers along the path, but, in such case, reservation will not be made and potential congestion problems may arise. 4.2. Differentiated Services (DiffServ) DiffServ [7] does not provide a guaranteed service (also called hard QoS) as IntServ, but a statistical QoS (also called soft QoS). Contrasting to IntServ it does not require any end-to-end reservation or signalling. Instead, DiffServ provides QoS by aggregating traffic in different service classes, each corresponding to a specific per-hop forward behaviour (PHB) along the nodes in the network path. Per-hop behaviours are defined to permit that a group of data receives the same type of forward treatment, therefore providing different QoS to competing data streams. To accomplish this, traffic entering a differentiated services-capable network is marked by setting the Differentiate Services Code Point (DSCP) in the IP header Differentiated Services Field (DS) of each data packet. DS is a replacement of the IPv4 Type of Service (ToS) field and the IPv6 Traffic Class Octet [8], used in the context of DiffServ. The structure of the DS field, as shown in Figure 2, is composed of six bits used as a code point (DSCP), leaving two bits unused. DiffServ compliant nodes must select PHB by matching against all DSCP field, ignoring the two remaining bits. DS field 0 1 2 3 4 5 6 7 DSCP Figure 2 DS field [8] To mark the data packets a Classifier and Traffic Conditioner is used, as depicted in Figure 3. Based on SLAs a traffic stream is selected by the Classifier that forwards the packets to a Meter (if a profile is in use, the Meter measures the traffic stream to see if it conforms to the profile) or directly to the Marker. The Marker sets the appropriate DSCP field and finally the Shaper may delay some or all of the packets so that the stream comply with the traffic profile. In the case that the Shaper runs out of buffer, some packets may be discarded.

Classifie Marker Shaper/Dropper Packets Meter Figure 3 Packet Classifier and Traffic Conditioner in a DiffServ edge node [7] By making most flow operations (including classification, policing, marking and shaping) at the network edges, DiffServ removes most of the work from the network core, which must only look up the IP header of data packets for the DiffServ class. Each marked packet receives from each node in the network a differentiated treatment, corresponding to a specified QoS. In a network, we can have any number of different Differentiated Services Domains, each with different service policies. At the edges of each of the domains packets may be remarked to comply with new policies in use. It is through PHB that the service differentiation is accomplished in core networks. PHBs define the treatment each of the packets will receive between two adjacent routers. There are two standardized PHBs classes, the Expedited Forwarding (EF) [9] and the Assured Forwarding (AF) [10], distinguished by the DSCP field in IP packets. There is also a DSCP corresponding to a best effort treatment (default). Each of this PHB defines the actual mechanisms to implement. Expedited Forwarding may be used to provide a building block for low loss, low delay, and low jitter services [9], appearing to endpoints like a virtual leased line. To accomplish this, marked packets should encounter short or empty queues, which also lead to a low packet loss. The implementation of this PHB require network elements to be able to limit the rate of incoming EF traffic. Assured Forwarding [10] provides four forward traffic classes (AF1-AF4), each with three drop precedences. For each class some bandwidth and buffered capacity are allocated. There is no pre-defined forwarding priority ordering for each class, depending on resources allocated, implementation and traffic mapped to the PHB class. Drop precedence s provide prioritization in the case of congestion. By prioritizing packets in core network elements and provisioning service quality at network edge, DiffServ implements QoS in the network, providing also good scaling properties. In spite of being studied as the basis for future general-purpose multi-service network in QBone (QoS testbed of Internet2) [1], DiffServ still has many problems. One of the problems is that it does not provide intra-class fairness, i.e., it is not assured that flows of data belonging to the same class receive an equal treatment. This is due to the fact that there is no policy to distribute bandwidth between service instances that compose a service aggregate traffic. Other problem is that there are no means to limit the number of service instances within one traffic aggregate in a domain. Also, a differentiated servicescapable network may be constituted by many DiffServ domains. Each domain (that may be controlled by a different network operator) will aggregate traffic and assign priorities according to its own policy, being difficult to predict the overall performance. 5. New Challenges and new approaches Although the techniques described to provide QoS over IP can provide an adequate solution for many of the present needs, they do not address completely the new challenges. The increasing number of services, each with particular needs for QoS, poses major problems to existing QoS techniques. Users want to have access to different kinds of information and entertainment, to be able to use a vast number of applications, with as much transparency, i.e., with as least technical difficulties, as possible, and with understandable billing. All kinds of services should also be available over a common platform, but be adapted to each of the possible user contexts (home user, mobile, etc.). To live up to expectations of future users, more guarantees must be provided by the network. However, the demand for more complex QoS control leads to more delays over the network, as more processing is needed (e.g. to manage queues, classify datagrams). DiffServ tries to avoid this problem by doing all major operation at the edge of the network, leaving the core with more light operations. However, problems still exist to be solved like intra-class fairness and inter-domain compatibility. As for IntServ, it lacks the scalability provided by DiffServ, as pointed earlier, and must be based on advanced signalling capabilities between network nodes to set up the required reservation (IntServ Guaranteed QoS), or is just too simple to provide for completely different degrees of QoS requirements (IntServ Controlled-load). Finally, the best-effort approach only provides QoS for an over-dimensioned network, a scenario difficult to obtain.

Also, the increasing demand for processing power in order to achieve good quality performance, in a scenario of high traffic, is leading to hardware based QoS implementations. Pure software mechanism can no longer provide the speed needed to queues and traffic classifiers, resulting in poor performance, traffic delays and possibly lost packets. So, a combination between flexibility and performance must be achieved. 5.1. Streaming Support and Mobility We can outline two major challenges for future networks: Streaming support and Mobility. Streaming support is required by applications like real-time multimedia services in which each instance is made up of a stream of data in the network. One of the goals is to be able to distribute these multimedia streams using multicast (one-to-many) multimedia sessions, to a group of heterogeneous receivers, some of them mobile. The question is how the stream can be sent to different users, some with wireless links, without overloading the network, while giving the quality needed to groups of heterogeneous clients [11]. Today, sources of multimedia content, deliver copies of the same stream, each with a different quality level, in order to satisfy different types of clients, leading to a bandwidth waste. Another problem is to assure that each of the different streams (that constitute the same service), have a fair treatment, giving each receiver its required quality level. The mobile paradigm does not live without more specific QoS mechanisms. However, providing QoS, other than best effort, is a challenging issue in a network that have mobile senders and receivers. As an example we can considerer one of the new mobile networks, the Mobile Ad-Hoc Networks (MANETS) [12]. In these networks the constant topology exchanges, together with link breaks and not constant link capacity makes it impossible to provide guarantees with hard QoS, nor even with statistical QoS like DiffServ, due to the changes of the network status. Both IntServ and DiffServ, described earlier, require accurate link state and topology, not being able to respond to the new needs. The mechanisms to provide QoS under these conditions are still object of research, many of them combining properties of DiffServ and IntServ [12]. 5.2 LCT approach: Q3M and SAPRA Some of the challenges described, in the area of streaming support and mobility, are currently being researched in the Laboratory of Communication and Telematics (LCT) of the University of Coimbra, under the projects SAPRA (Session Aware Popularity-based Resource Allocation) [13] and Q3M (QoS Architecture for Mobile Multicast Multimedia Services) [11]. Q3M, a partnership between LCT and DoCoMo Euro-Labs, pretends to adapt mobile operators IP networks, to the delivery of multimedia streaming services to mobile users, without overloading the network and by supplying different quality to different clients. Q3M will develop a new architecture that combines provider goals with the mobile client needs. This architecture will use SAPRA as the signalling protocol that distributes resources along the network. SAPRA protocol proposes to make a fairly distribution of resources along a DiffServ multicast environment, with just a small network overhead. In this environment each multimedia stream should be encoded in a scalable way, being composed of cumulative layers, each adding more quality to the previous. In this manner, a sender only sends a stream to all receivers and each receiver only listens to the layers it needs to achieve the required quality. To accomplish this goal SAPRA addresses actual DiffServ problems namely the need to provide each specific multimedia stream belonging to the same DiffServ class, a fair usage of resources. To achieve this objective, SAPRA has an agent and a marker in each DiffServ edge router. The agent is responsible for computing each stream fair rate in respect to the number of receivers, while the marker assigns different drop precedents to traffic. 6. Conclusion The convergence to a multi-service IP data network poses new requirements. This new delivery channel must transport different kinds of traffic, with specific needs, according to different SLA, as well as give the final user the support for pricing models that are understandable and fair. Besides, the new demand for mobility adds even more problems and questions, because users want to access the same services that were accessible from traditional desktops even at cost of adapted quality. To make this scenario a reality, QoS must be provided in the network. However, the existing QoS techniques available today, like the described IntServ and DiffServ do not fully respond to the new challenges and need to be adapted to new scenarios. In this context, many new approaches to QoS problems are now being subject to intense

research, trying to respond to the new paradigms of modern society and business. The QoS technique to be found should be effective end-to-end, easy to install and configure and far from a nightmare to maintain. 7. References [1] Raïsänen, Vilho, Implementing Service Quality in IP Networks, John Wiley & Sons, England, 2003 [2] Peuhkuri, Markus, IP Quality of Service, Helsinki University of Technology, Laboratory of Telecommunications Technology, May 1999 [3] Braden, R., Clark, D., Shenker, S., Integrated Services in the Internet Architecture: an Overview, Request for Comments (Informational) RFC 1633, IETF Network Working Group, June 1994 http://www.ietf.org/rfc/rfc1633.txt [4] Wroclawski, J., Specification of the Controlled-Load Network Element Service, Request for Comments (Standards Track) RFC 2211, IETF Network Working Group, September 1997. http://www.ietf.org/rfc/rfc2211.txt [5] Shenker, S., Partridge, C., Guerin, R., Specification of Guaranteed Quality of Service, Request for Comments (Standards Track) RFC 2212, IETF Network Working Group, September 1997. http://www.ietf.org/rfc/rfc2212.txt [6] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., Resource ReSerVation Protocol (RSVP), Request for Comments (Standards Track) RFC 2205, IETF Network Working Group, September 1997. http://www.ietf.org/rfc/rfc2205.txt [7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., An Architecture for Differentiated Services, Request for Comments (Informational) RFC 2475, IETF Network Working Group, December 1998. http://www.ietf.org/rfc/rfc2475.txt [8] Nichols, K., Blake, S., Baker, F., Black, D., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Request for Comments (Standards Track) RFC 2474, IETF Network Working Group, December 1998. http://www.ietf.org/rfc/rfc2474.txt [9] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Boudec, J.Y. Le, Courtney, W., Davari, S., Firoiu, V., Stiliadis, D., An Expedited Forwarding PHB (Per-Hop Behavior), Request for Comments (Standards Track) RFC 3246, IETF Network Working Group, March 2002. http://www.ietf.org/rfc/rfc3246.txt [10] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., Assured Forwarding PHB Group, Request for Comments (Standards Track) RFC 2597, IETF Network Working Group, June 1999. http://www.ietf.org/rfc/rfc2597.txt [11] QoS Architecture for Mobile Multicast Multimedia Services (Q3M), Q3M Project Plan, Laboratory of Communications an Telematics, University of Coimbra, Future Networking Laboratory, DoCoMo Euro-Labs, Draft document. [12] Chlamtac, I., Conti, M., Liu, J., Mobile ad-hoc networking: imperatives and challenges, Ad Hoc Networks 1, 2003, pp. 13-64. [13] Mendes, P., Schulzrinne, H., Monteiro, E., "Session- Aware Popularity-based Resource Allocation for Assured Differentiated Services, Proceedings of the 2 nd IFIPTC6 Networking Conference, Pisa, May 2002 14 IEEE Proceedings Author Guidelines for 8.5x11 inch Manuscripts http://www.computer.org/cspress/instruct.htm