Internet Service Quality: A Survey and Comparison of the IETF Approaches

Transcription

1 Internet Service Quality: A Survey and Comparison of the IETF Approaches María E. Villapol and Jonathan Billington Cooperative Research Centre for Satellite Systems University of South Australia SPRI Building, Mawson Lakes, Adelaide SA 5095 Tel: Fax: maria@spri.levels.unisa.edu.au and jb@spri.levels.unisa.edu.au Abstract The Internet provides a best-effort transfer service with no service guarantees. In the last few years, however, there has been growing interest in providing Quality of Service (QoS) guarantees in the Internet. It has been mainly driven by multimedia and real-time applications, which require a certain level of service. Thus, the IETF 1 is working on the development of new proposals for supporting these applications by improving service quality. They include the Internet Integrated Services and Differentiated Services. In this paper, they are described and compared in terms of scalability, signalling support, service taxonomy, granularity of service provision, scope of the service, service coordination, and service differentiation. INTRODUCTION Traditionally, Internet applications use best-effort service with no service guarantees. In the last decade, however, new applications have emerged. These applications, such as multimedia applications, generate not only data but also images, video, and voice. They also require different levels of quality of service (QoS) regarding, for example, delay and throughput. The original TCP/IP model [13][17] is not able to accommodate the performance required for those applications properly. The Internet Engineering Task Force (IETF) 1, a volunteer organisation that sets the standards for the Internet, has worked on improving and extending the TCP/IP model to support multimedia and real-time applications on the Internet. The effort of the IETF may be broadly divided into the development and revision of the Internet protocols and the definition of a service model. Braun [10][11] surveys recent and current protocols intended to support those applications. For example, it describes the new version of the Internet Protocol (IP version 6- IPv6), the Resource Reservation Protocol (RSVP), and the Real-Time Transport Protocol (RTP). Hutchison et al [21] review three Internet protocols (RSVP, IPv6, and RTP) in terms of their beneficial and disadvantageous features for multimedia applications. A service model includes a set of mechanisms and protocols for managing network resources in order to avoid network congestion conditions which can degrade the agreed service performance level of applications. The IETF has proposed two Internet Service models. The former is called the Internet Integrated Services (IntServ) model [8]. The latest proposal is the Differentiated Services (DiffServ) model [7]. 1 See Internet Engineering Task Force (IETF) s home page at 1

2 Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Liv e Protocol Header Checksum Source Address Destination Address Options Padding Precedence D T R IHL: Internet Header Length D: Delay T: Throughput R: Reliability Figure 1: The TOS field in the IP header. Hassan et al [18] surveys the technologies to support QoS in the Internet. The paper includes a brief description of the IntServ and DiffServ models. Huston [20] reviews the IntServ and DiffServ models and analyses them, pointing out some of their weaknesses such as excessive network load (IntServ) and no explicit admision control (DiffServ). Bernet [4] provides an overview of the RSVP and DiffServ models and presents the benefits of combining those technologies. Similarly, this paper is focused on the Internet Service Models (ie IntServ and DiffServ models) rather than individual protocols, however, it describes them in more detail. Also, it compares them based on the following criteria: scalability, signalling support, service taxonomy, granularity of service provision, scope of the service, service coordination, and service differentiation. This paper is structured as follows. Firstly, initial work on providing QoS support on the Internet is overviewed. After that, the different Internet Service Models are described. Then, those models are compared. Finally, the conclusions of the paper are presented. QOS SUPPORT ON THE INTERNET: INITIAL EFFORTS Type of Service field In the original Internet architecture, some QoS support was provided by means of the Type of Service (TOS) field in the IP 2 header (see fig. 1). The TOS field is intended to provide an indication of the quality of service desired for a packet. The IP specification [14] defines the following abstract service parameters: precedence (P), delay (D), throughput (T), and reliability (R). These parameters are placed in the TOS field as shown in figure 1 3. Precedence bits indicate the importance of the packet. Since, the length of the precedence sub-field is 3 bits, 8 levels of priority have been defined [14]. The delay bit indicates that prompt delivery is required for a packet. The 2 The term IP refers to IP version 4 (the current version), while IPv6 refers to IP version 6. 3 The meaning and use of the rest of the IP header fields may be found in [14]. 2

3 Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Liv e Protocol Header Checksum Source Address Destination Address Options Padding Precedence TOS 0 IHL: Internet Header Length TOS: Type of Service Figure 2: Redefined TOS field in the IP header based on RFC throughput bit indicates that a high data rate must be used for the packet. Finally, reliability indicates if ensured delivery is important for the packet. The TOS field defines the treatment of the packets by routers in the network. Thus, the intermediate nodes decide when a packet will be forwarded, according to the priority value (precedence bits) in the packet s header and the three flag bits (ie D,T, and R bits). Redefined Type of Service The three QoS parameters defined in the TOS field (ie D,T, and R) cannot be optimised simultaneously. For example, a path which provides the lowest delay may not be the one which provides the highest throughput. Thus, in [1], the TOS field is redefined by changing some aspects of its semantics. It also specifies the handling of the TOS field in routers and host, which was missing in RFC 791 [14]. The new format of the TOS field is shown in figure 2. Only the TOS bits (bits 3-6 in figure 1) have been redefined. The values of these four bits, which will be referred to as the TOS field, are defined as a single enumerated value. The default TOS values specified are: minimise delay, maximise throughput, maximise reliability, minimise monetary cost and normal service 4. As in RFC 791 [14], the throughput, delay, reliability, and cost are abstract parameters and specify just qualitative QoS more than quantifiable values. For example, minimise delay means that the network will attempt to choose the path with the lowest delay. Also, as in RFC 791 [14], IP nodes (ie. host and routers) supporting RFC 1349 [1] should choose the appropriate path over which the packet is forwarded according to the TOS value. Nodes may also use the TOS field for handling packets as described in [1]. For example, packets which have been marked to have a minimise delay may be assigned to preferential queues on the output ports. 4 Almquist [1] does not preclude the use of other TOS values. 3

4 It appears that the TOS field as defined in both RFC 791 [14] and RFC 1349 [1] has been used little in the past. RECENT APPROACHES FOR SUPPORTING QOS ON THE INTERNET QoS support provided by the TOS field (as defined in RFC 791 [14] or RFC 1349 [1]) does not meet the needs of the real-time and multimedia applications. Firstly, it just provides qualitative QoS guarantees, while some applications need some quantitative levels of service performance, for example, bandwidth. Secondly, the mechanisms required to achieve quality of service levels were not well explained. Thus the IETF has worked on creating a service model. The proposed service models are the Internet Integrated Services (IntServ)[8] and the Differentiated Services (DiffServ) [7] models. They are described in this section. Internet Integrated Services Model The IntServ model [8] (fig. 3) is intended to support real-time and non-real time Internet services. Users are able to explicitly request some quantitative QoS guarantees, so their applications can operate in an acceptable way over a certain period of time. The model provides both a mechanism which conveys users QoS requirements (reservation protocol) and one which decides if the network can meet those requirements (traffic control). Traffic control functions are performed by the admission control, packet scheduler, and classifier. The components of the IntServ model interact in order to control the traffic in the network and reserve and negotiate different service classes along the communication path. As shown in figure 3, it comprises a host communicating with an Internet router [8]. The host and router systems are the same except that the application block in the host is replaced by a routing block in the router. Each of those blocks is described below: a. Applications: request specific QoS from the network. b. Reservation process: a set of procedures to reserve resources (eg bandwidth and buffer space) along the path of the data flows. The Resource Reservation Protocol (RSVP) has been adopted by the IETF for the IntServ model [8][9]. c. Classifier: classifies IP packets according to a set of service classes and assigns them to different queues. d. Packet scheduler: determines which of the set of IP packets will be served next. e. Admission Control: decides whether there are sufficient resources available to grant the requested QoS for a data flow. A data flow is a distinguishable packet stream which results from a single user/application activity and requires the same QoS [8]. f. Policy Control: decides if the user requesting a reservation is permitted to do so. Policy control mechanisms may involve, for example, the identity of the user and application, traffic and data rate requirements, and security considerations[16]. g. Routing process: determines the route along which the packets will be forwarded. 4

5 Application RSVP signaling RSVP signaling Data flow RSVP process Policy Control Routing Process RSVP process Policy Control Admission Control Admission Control Classifier Classifier Packet Scheduler Packet Scheduler Host Router Figure 3: Internet Integrated Service model. Classes of Service The Integrated Services Work Group (WG) has defined several classes of service [8]. The IETF distinguishes between real-time applications and elastic applications. The former may receive either a guaranteed or predictive service. The guaranteed service offers both delay and data rate guarantees. In contrast, the predictive service provides a fairly reliable delay bound which may be computed based on predictions of other flows. It is intended for applications which may accept some minimum guaranteed service, such as adaptive applications which may tolerate, for example, a certain amount of packet delay and loss. Elastic applications don t expect to receive any guarantees from the network. They will receive the traditional best-effort service provided by TCP/IP networks. Thus, the following classes of service are currently defined: a. Guaranteed service [25]: is for guaranteed delay-bound real-time applications. It provides guaranteed data rate and delay. Also, data packets conforming to their traffic specifications 5 will not be discarded because of queue overflow. The guaranteed service only controls the maximum queuing delay. Other delays which are fixed delays such as transmission delay and propagation delays may be determined by the setup mechanisms. This service is intended for applications which have firm time constraints, such as telephony and medical images. b. Controlled-Load Service [27]: corresponds to the predictive real-time service. Nodes (eg routers) which have committed to providing a controlled-load service should offer a service which approximates that provided by a best-effort service under lightly loaded conditions. A high percentage of delivered packets should not exceed a minimum transit delay and should arrive at their destination successfully (ie there is a low probability of packet loss). Controlled-load service may be used for applications such as video conferencing and Internet real-audio. c. Best effort service: corresponds to elastic applications and is the current service provided by the Internet. 5 A traffic specification includes the traffic characteristics of a data flow such as peak packet rate. 5

6 Resource Reservation Protocol The Resource Reservation Protocol (RSVP) [9] is a signalling protocol developed to create and maintain resource reservations on each link along the transport path. It is also used by a host to request a particular QoS for each application. The design principles of RSVP are outlined in [28]. A detailed description of those principles is beyond the scope of this paper. However, the main characteristics of RSVP, which are closely related to those principles, are summarised as follows: a. Receiver-based: receivers initiate the resource reservation along the path between the source and destination of a data flow, since receivers know the resource availability and limitations [9]. b. Soft-state reservations: the reservations along a path are considered non permanent, so they must be refreshed periodically. If a reservation is not refreshed before a timeout occurs, the reservation is cancelled, so, the reservations may adapt to dynamic routing changes and the QoS reserved for a flow may be changed at any time. c. Flow oriented: RSVP reserves resources on a flow basis. d. Unidirectional: RSVP reserves resources in one direction. e. Heterogeneous receivers: each receiver requests resources to support its own QoS requirements. f. Support of multicast sessions: RSVP makes resource reservations for both unicast and multicast applications. Sessions and dataflows A session is a data flow with a particular destination and transport-layer protocol and is identified by an IP destination address (unicast or multicast) of the data flow, IP protocol ID, and destination port (optional) (eg UDP/TCP destination port field) [9]. Traffic and QoS parameters The RSVP specification defines a reservation request in terms of a filter specification (filter spec) and a flow specification (flow spec) [9]. The former defines the sequence of packets or data flow to receive the QoS specified in a flow specification. A filter specification together with a session ID is used to identify a flow which will receive the QoS. The latter defines a desired QoS for the flow and defines its traffic characteristics. It includes a service class, a Reservation specification (Rspec), and a Traffic specification (Tspec). A traffic specification (Tspec) defines the traffic characteristics of the flow, for example, the peak rate. A request specification (Rspec) defines the reservation (ie. desired QoS) characteristics of the flow, for example, the service rate. The formats of a Tspec and Rspec are not defined by the RSVP specification. 6

7 Path message PathTear message ResvErr message ResvConf message Data flow Router dowstream Router Sender Host upstream Resv message ResvTear message PathErr message Figure 4: Flow of RSVP messages. Receiver Host A filter specification is used by the classifier to assign the data flow to a queue and a flow specification is used by the packet scheduler to allocate the corresponding QoS and to schedule packets based on their traffic characteristics. Soft state RSVP soft state reservations deal with occasional loss of RSVP messages and route changes at any point on the path of a data flow. Thus, reservation and path states set up by RSVP along the route of a data flow must be refreshed periodically, otherwise they will be removed. The refresh timeout determines when a refresh message must be generated, while the cleanup timeout determines the maximum period of time that a node waits to receive a refresh message, before it removes the associated state information. RSVP operation RSVP uses several messages in order to create, maintain, and release state information for a session between one or more senders and one or more receivers. Figure 4 shows a flow of RSVP messages on a simple unicast network, while figure 5 shows RSVP operation over a multicast network. In general, sequences of packets travelling in opposite directions may follow different routes In RSVP, reservation requests travel from receivers to the sender(s), in the opposite direction to the user data flow for which such as reservation is being requested. Path Messages are used to set up a route for the reservation requests along the same path of the corresponding data flow (figure 5 (a)). They set up and maintain path information (eg the IP address of the previous host and traffic characteristics of a data flow). The path is refreshed as a result of either a state refresh timeout or the modification of a path state (as mentioned before). Once a path is established, a node periodically (ie every refresh timeout period) sends path refresh messages (ie Path messages) downstream (figure 5 (a)). 7

8 path resv path B resv B path Host (sender) A path C path Hosts (receivers) Host (sender) resv A resv C resv Hosts (receivers) a) Path messages are sent by a node (ie host, router) periodically through the network b) Resv messages are sent by a node periodically through the network pathtear pathtear B B A A C C pathtear resvtear resvtear pathtear pathtear resvtear Host (sender) Hosts (receivers) Host (sender) Hosts (receivers) c) A pathtear message may be sent by a node through the network router Figure 5: Overview of RSVP operation. d) A resvtear message may be sent by a node through the network Resv messages travel upstream from the receiver(s) to the sender (figure 5 (b)). They carry reservation requests (e.g. for bandwidth and buffers) used to set up reservation state information along the route of a data flow. At any intermediate node, a reservation request may be rejected by Admission Control because there are not sufficient resources to guarantee the requested QoS. Also, reservation requests which arrive at a router are merged. The aim of merging is to control the overhead of reservation messages by making them carry more than one flow and filter specification [9][28]. Thus, the effective filter and flow specifications, which are carried in a reservation message, are the result of merging reservations from several requests. Merging is a complex process [9][16] which will not be described further here. The reservation is refreshed as a result of either a state refresh timeout or the modification of a reservation state (as mentioned before). Like path states, reservation states need to be refreshed. Thus, a receiver periodically sends reservation refresh messages (ie Resv messages) to the sender (figure 5 (b)). RSVP tear down messages are intended to speed up the removal of path and reservation state information from the nodes. They may be triggered because a state timeout occurs (as explained before) or an application wishes to finish a session (ie service preemption). A PathTear message travels downstream from a sender to the receiver(s) and deletes any path state information and dependent reservation state associated with the session and sender (figure 5 (c)). A ResvTear message travels from a receiver to a sender and removes any reservation information state associated with one or more data flows (figure 5 (d)). 8

9 DSCP CU DSCP: differentiated services codepoint CU: currently unused Figure 6: Differentiated Services Field. In addition, there are two error messages, Path Error and Resv Error, which are used to report problems associated with processing or installing Path/Resv information or to report administratively defined constraints imposed on the setup of a reservation state [9][16]. They travel hop-by-hop from the point where the error was found. Optionally, a receiver may ask for a confirmation for its reservation by including a RESV conformation object 6 in the Resv message (ie reservation request). A ResvConf message is used to notify the receiver that the reservation request was successful. Differentiated Services Model The Differentiated Services WG is working on the specification of a new service model, called Differentiated Services (DiffServ) [3][7]. The main problem of the IntServ proposal is that it is not scalable across large networks. The DiffServ model is intended to solve the scalability problem by aggregating traffic. Large flows with similar service requirements are aggregated. Traffic entering a network is classified and marked in order to receive a specific quantitative or qualitative QoS. DiffServ Codepoint DiffServ redefines the IPv4 TOS octet and the IPv6 Traffic Class octet [23]. The new defined field is called, Differentiated Service field (DS field). The 8-bit DS field is divided into a DS codepoint and currently unused (CU) fields (see figure 6). Packets that enter the DiffServ network are marked with a DS codepoint (DSCP). The CU field is reserved. A collection of packets which have the same DS codepoint (DSCP), travel in the same direction and traverse the same link are referred as a behaviour aggregate (or traffic aggregate)[7]. 6 A RSVP message comprises a message header and a set of objects. Objects contain information necessary to process the message at each RSVP node it arrives [9][16]. 9

10 Meter packets Classifier Marker Shaper/ Dropper Figure 7: View of the classifier and traffic conditioner. DiffServ functional architecture The Diffserv architecture comprises a number of functional elements known as per-hop behaviours, packet classifiers and traffic conditioners. They are implemented in several nodes (eg routers) along the network. Those components are described in the next paragraphs. Per-hop behaviour (PHB) A per-hop behaviour (PHB) is the means by which a sequence of packets obtains some level of service. It may be seen as the differential treatment which a packet will receive. It may be defined in terms of network resources (ie buffer), traffic characteristics (eg delay, loss), etc.. [7], and it is implemented in nodes through several queue management and packet scheduling mechanisms. Packet classifiers A packet classifier (fig. 7) selects the packets in a input traffic stream by using either the DS codepoint of the packet header or a combination of one or more header fields, such as IP destination address, IP source address, DS field, and IPv6 flow ID and/or other packet attributes. After that, it forwards them to an element of traffic conditioner for further processing. Thus, a classifier splits an input traffic stream into one or more output streams [5][7]. Traffic conditioner A traffic conditioner is an entity which performs control functions intended to enforce traffic rules. It may contain meters, markers, droppers, and shapers. Figure 7 shows a view of the classifier and the traffic conditioner components. Those components are described briefly as follows 7 : a. Meters: are used to monitor the arrival time of packets in order to verify that they are conforming to their traffic characteristics in the traffic characteristic agreement (ie traffic profile). The meter provides the resulting information to the other components of the traffic conditioner. 7 For more detailed information see [5] [7]. 10

11 Source Destination Core routers Core routers Egress router Ingress router DS Domain DS Domain Figure 8: Differentiated services network. b. Markers: set the DS codepoint field in the IP packet to a particular value. For example, it may mark packets which have been classified by the classifier as a member of a particular flow. It also may re-mark previously marked packets which, for example, are not conforming to their traffic profile (see meters). c. Shapers: delay packets in a traffic stream by using buffers, so the traffic conforms to its traffic profile. d. Droppers: discard some or all the packets in a traffic stream so that the traffic stream conforms to its traffic profile. Differentiated Services Network Architecture The functional elements of the DiffServ architecture may be implemented in different nodes in a network; they are shown in figure 8. A node (eg a router) which is enabled to support differentiated services functions is called a DS node [7]. A DiffServ specification classifies the nodes according to their location in a DiffServ region and the functions they perform. The following terminology applies to a DiffServ network. A DS domain includes a set of DS nodes which operate with a common set of differentiated service provisioning policies and share the same boundary nodes. A differentiated service provisioning policy defines how traffic handling mechanisms are configured in core and edge nodes to provide a range of services [7]. DS boundary nodes, also called edge nodes, interconnect a DS domain with either another DS domain or a non-ds domain. Traffic enters a domain through a DS edge ingress node and leaves the domain from a DS edge egress node. DS nodes in a domain which may be connected to boundary nodes are called interior nodes or core nodes. For example a campus or corporate network may be a DS domain. 11

12 The core nodes implement limited differentiated services functions. They apply the appropriate PHB to packets in a traffic stream based on their DSCP. Edge nodes, in addition, perform traffic classification and conditioner functions. Service definition Providers (DS domain) and customers (eg local users and adjacent networks) must negotiate agreements with respect to the level of service which will be given to customers. Such agreements are called Service Level Agreements (SLA). A SLA is a complex contract which includes overall service features such as network availability guarantees, payment models, billing mechanisms, etc [3]. The Service Level specification (SLS) is part of a SLA. The SLS comprises the technical specification of the service [3]. It includes, for example, Traffic Conditioning Agreement (TCA) parameters, encryption services, routing constraints, and pricing and billing mechanisms [3]. A TCA specifies classifier and conditioning rules as well as traffic stream characteristics (ie traffic profile) such as rate and burst size. Classes of Service The DiffServ WG has defined several classes of services so far [19][22][23]. They are defined in terms of PHBs and include Expedited Forwarding, Assured Forwarding, and Best-Effort Forwarding. a. Expedited Forwarding: provides a virtual leased line end-to-end service, which is characterised by low loss, low latency, low jitter, and assured bandwidth. It is also called premium service [24]. It may suit applications such as video broadcast, voice-over-ip, and virtual private networks. b. Assured Forwarding: provides a service based on an expected usage profile [12]. This profile indicates the level of performance (service assurance) uncertainty the user may tolerate (user expectation) [12], more than a strict guarantee (like RSVP may provide). During periods of congestion some packets may still be dropped, but it may be acceptable for the user. Heinanen et al [19] define several assured forwarding classes, and within each class also define several drop precedence values. The drop precedence values determine which packets are likely to be dropped during periods of congestion. In order to provide a level of forwarding assurance, a certain amount of resources (bandwidth and buffer space) are allocated for an assured forwarding class, and each IP packet must be marked with a drop precedence value [19]. c. Best-Effort Forwarding: is the default service given when there is no other agreement in place. It corresponds to the common best-effort service with no QoS guarantees [23]. 12

13 IntServ DiffServ Model/ Criteria Scalability Limited by reservation states From small to large networks Signalling support Use RSVP No required Service Taxonomy Mostly Quantitative QoS Absolute QoS Quantitative and Qualitative QoS Mostly relative QoS Granularity of Per-Flow Aggregate traffic Service Provision Scope of the Service Unicast and Multicast paths Anywhere in the network Service End-to-end QoS Per-hop (local) Coordination provision Service Differentiation Several IP header fields DSCP field Table 1: Comparison of the proposed approaches. COMPARISON OF THE APPROACHES There is no consensus within the Internet Community about which service model should be used in the Internet. The models presented are not exclusive solutions, contrarily, but complementary proposal for service differentiation. Thus the IETF is working on integrating some of these approaches. For example, Bernet et al [6] have proposed a framework for provision of end-to-end QoS using both the IntServ and DiffServ models. Those approaches may be integrated [6]. In addition, an approach may be an alternative implementation technology in some part of the whole network, for example, as intradomain implementation. In order to compare the above approaches, the authors have selected several criteria which have been already used to describe the functionality of the Internet Services Models (for example, see [4][7][15][20][26]). The criteria are: scalability, signalling support, service taxonomy, granularity of service provision, scope of the service, service coordination, and service differentiation. `Table 1 shows a comparison of the IntServ and DiffServ models based on those criteria. Scalability Given that the Internet is a worldwide network, it is desirable that any service model be deployable in very large networks. One of the limitations of the IntServ model is its scalability in large networks due to the reliance of RSVP on per-flow state and processing on each RSVP-capable node. The number of states on each node scales in proportion of the existing reservations. However, some solutions to this problem are being developed by the IETF [2]. They are intended to aggregate reservation states. The differentiated services model is intended to improve the IntServ architecture by overcoming the scalability problem. In order to do that, the core nodes functions related 13

14 to Differentiated Services must be as simple as possible, while the most complex functions must be implemented in the boundary nodes which process lower volumes of traffic. These functions include shaping, marking, and dropping. Also, in order to avoid a large number of states in each node, the DiffServ model offers services for aggregate traffic instead of on a per-flow basis. Signalling support The IntServ model relies on RSVP to create and maintain reservation states along the communication paths. In contrast, DiffServ architecture does not include any mechanism for signalling QoS request between DS nodes and/or domains. However, in order to manage the allocation of network resources which are shared between several users simultaneously, the concept of bandwidth brokers has been introduced in [24][26]. Service Taxonomy QoS requests may be classified as quantitative and qualitative. In the former, the specific characteristics of the traffic (eg data peak rate) and QoS parameters (eg bandwidth) are known. Otherwise, the specific characteristics of the qualitative QoS requirements are not defined. The service request is given in an abstract way, for example, an application may request a higher-priority service. QoS requests may be also categorised as absolute or relative [15]. The former is intended to provide total performance levels, so a QoS request is rejected if the network is not able to provide the requested performance (ie the required resources are not available). In the latter, the only guarantee provided is that higher priority packets will receive better service than lower priority packets. The level of service provided by the network depends on the load of the network. It is intended that applications will adapt to the network load changes by modifying their performance needs. The IntServ model offers a service which is mostly quantitative. However, it may also provide qualitative services. In addition, the IntServ model provides absolute performance levels of service. QoS requests signalled by RSVP may be accepted or not by the admission control component of each affected node. The DiffServ model is intended to offer both quantitative and qualitative QoS [3]. It also provides a service which is mostly based on relative guarantees [3]. DiffServ approach, as defined in [7], is not able to provide absolute service guarantees [4]. It relies on careful network-wide resource provision to provide the offered QoS. Provisioning may include, for example, the addition or removal of physical resources 8. The network administrator must study the network topology and traffic routing in order to compute the provisioned requirements. It is called top-down provisioning in [4]. Admission control is provided implicitly by policing the ingress traffic at a node. However, Teitelbaum et al [26] describe some mechanisms which may be used to provide absolute performance levels of 8 See [3] for more details about provisioning and configuration in a Differentiated Services network. 14

15 service by using Bandwidth Brokers (BBs). BBs manage the allocation and utilisation of network resources. Granularity of Service Provision Connection oriented protocols, such as ATM, service is provided for a connection. In contrast, in connectionless networks such as IP networks, granularity of service provision is not well-defined. Service may be provided, for example, for a packet, for a data flow, or for an aggregated traffic. Granularity of service provision is closely related to the number of QoS states which must be maintained in each node of the network. For example, for a per-flow service, the number of states is proportional to the number of active data flows. As the service is provided for more aggregated traffic (grosser granularity), the QoS states at each node are reduced. However, the QoS enjoyed by each data flow member of the aggregated traffic will dependent on the behaviour of other data flows in the same aggregate [4]. As shown in table 1, the IntServ approach is per-flow oriented, while the DiffServ approach offers service for aggregated traffic. Scope of the service Service may be provided for unicast or multicast traffic. The IntServ model supports both unicast and multicast sessions [9]. In a DiffServ network, service may be provided anywhere in the network based on per-hop resource provisioning. Multicast or unicast traffic crossing DS nodes receives the required service. However, the support of multicast traffic in differentiated services introduce some problems of network resource provisioning. Since the Internet supports dynamic multicasting, where receivers may dynamically join a group while a flow is in progress, network resource provisioning along the multicast tree may be difficult. In other words, the amount of network resources which will be consumed by multicast traffic may not be easy to predict in advance [3][7]. Service Coordination In order to satisfy the QoS needs of the different applications running on the Internet, the components of any QoS architecture must interact in a coordinated way. In an IntServ network, an end-to-end session is established using a signalling mechanism, such as RSVP. In contrast, in a DiffServ network, all mechanisms required for service provision work locally (per-hop) and local decisions are not communicated to other nodes. Service Differentiation As mentioned before, there are different grades of service granularity. The set of packets which are intended to receive specific service guarantees must be classified in order to 15

16 receive the corresponding level of service. IntServ model uses several IP header fields to identify the data flow which will receive the guaranteed level of service. DiffServ model mainly uses the DSCP field to distinguish between different aggregated traffic. CONCLUSIONS The Internet architecture is evolving in order to support the QoS needs of real-time and multimedia applications. Those changes may be grouped into extension and/or development of new protocols and definition of Internet Services Models. This paper is focused on the two service models created by IETF, which are the Internet Integrated Services and Differentiated Services models. The IntServ model is a per-flow approach which provides end-to-end QoS. It comprises traffic handling mechanisms such as admission control, and packet scheduling and a QoS signalling protocol such as RSVP. The main problem of this model is the scalability to large networks due to per-flow packet classification and handling in intermediate nodes. The DiffServ model is the most recent approach for providing QoS guarantees in the Internet. It is intended to solve the scalability problem of the IntServ model by using aggregated traffic and simplifying the functions of some routers in the network. In this paper, the service models were compared. The comparison shows the main differences of the models in terms of scalability, signalling support, service taxonomy, granularity of service provision, scope of the service, service coordination, and service differentiation. Finally, more work is required to provide better insight into how these two approaches may be reconciled and combined to provide better QoS guarantees for users, which parts of the two models are complementary and which parts are competitive, and, if competition, which approach is better and why according to what criteria. ACKNOWLEDGMENT This work was carried out with financial support from the Commonwealth of Australia through the Cooperative Research Centres Program. REFERENCES [1] Almquist P. Type of Service in the Internet Protocol Suite. RFC 1349, IETF, July, [2] Baker F., Iturralde C., Le Faucheur F., and Davie B. Aggregation of RSVP for IPv4 and IPv6 Reservations. IETF Internet Draft, March, [3] Bernet Y. et al. A Framework for Differentiated Services, IETF Internet Draft, February,

17 [4] Bernet Y. The Complementary Roles of RSVP and Differentiated Services in the Full- Service QoS Network. IEEE Communications Magazine, February, 2000, Vol. 38, 2, pp [5] Bernet Y., Smith A., Blake S., and Grosman D. A Conceptual Model for DiffServ Routers. IETF Internet Draft, March, [6] Bernet Y. et al. A Framework for Integrated Services Operation Over DiffServ Networks. IETF Internet Draft, March, [7] Blake S. et al. An Architecture for Differentiated Services, RFC 2475, IETF, December [8] Braden R., Clark D., and Shenker S. Integrated Services in the Internet Architecture: an Overview. RFC 1633, IETF, June, [9] Braden R. et al. Resource Reservation Protocol (RSVP) -- Version 1: Functional Specification. RFC 2205, IETF, Sept., [10] Braun T. Internet Protocols for Multimedia Communications- Part I. IEEE Multimedia, 1997, Vol. 4, No. 3, pp [11] Braun T. Internet Protocols for Multimedia Communications-Part II. IEEE Multimedia, 1997, Vol. 4, No. 4, pp [12] Clark D. and Fang W. Explicit Allocation of Best Effort Packet Delivery Service, IEEE/ACM Transactions on Networking, August, 1998, Vol. 6, No. 4, pp [13] Comer D. Internetworking with TCP/IP. Prentice Hall, [14] DARPA. Internet Protocol, RFC 791, IETF, September, [15] Dovrolis C. and Parameswaran R. Case for Relative Differentiated Services and the Proportional Differentiation Model, IEEE Network, Sep/Oct, 1999, Vol. 13, No. 5, pp [16] Durham D. and Yavatkar R. Inside the Internet's Resource Reservation Protocol. Wiley, USA, [17] Feit S. TCP/IP. McGraw-Hill, [18] Hassan M. and Tokin B. Technologies Supporting Quality of Service in the Internet. Telecommunication Journal of Australia, Australia, 1999, Vol. 49, No. 1, pp [19] Heinanen J., Baker F., Weiss W., Wroclawski J. Assured Forwarding PHB Group, IETF RFC 2597, June, [20] Huston G. Quality of Service - Fact or Fiction?. The Internet Protocol Journal. CISCO Systems, March, 2000, Vol. 3, No. 1, pp [21] Hutchison D., El-Marakby, and R. Mathy L. A Critique of Modern Internet Protocols: The Issue of Support for Multimedia. Proc. Second European Conference on Multimedia Applications, Services and Techniques (ECMAST'97), Milan, Italy, May, [22] Jacobson V., Nichols K., and Poduri K. An Expedited Forwarding PHB. IETF RFC 2598, June, [23] Nichols K., Blake S., Baker F., and Black D. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, IETF, December, [24] Nichols K., Jacobson V., and Zhang L. A Two-bit Differentiated Services Architecture for the Internet IETF Internet Draft, April,

18 [25] Shenker S., Partridge C., and Guerin R. Specification of Guaranteed Quality of Service, RFC 2212, IETF, September, [26] Teitelbaum B. et al. Internet2 Qbone: Building a Testbed for Differentiated Services. IEEE Network, Sep./Oct. 1999, Vol. 13, No. 5, pp [27] Wroclawski J. Specification of the Controlled-Load Network Element Service, RFC 2211, IETF, Sept., [28] Zhang L., Estrin D., and Zappala D. RSVP: A New Resource Reservation Protocol, IEEE Network Magazine, Sept./Oct., 1993, Vol.7, pp