Internet Draft Analysis of Existing QoS Solutions May 2002 Internet Engineering Task Force H. de Meer INTERNET-DRAFT Piers O'Hanlon Expires November 2002 University College London, UK G. Feher University of Budapest, Hungary N. Blefari-Melazzi University of Perugia, Italy G. Karagiannis D. Partain V. Rexhepi L. Westberg Ericsson May 2002 Analysis of Existing QoS Solutions draft-demeer-nsis-analysis-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. de Meer, et al. Expires November 2002 [Page 1] Internet Draft Analysis of Existing QoS Solutions May 2002 Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo provides a brief analysis of existing IP quality of service (QoS) solutions and the implied signalling issues. This analysis is intended to point out open issues in QoS signalling. Moreover, this analysis is done in order to understand whether the strict QoS requirements imposed by future fixed and mobile applications are satisfied by the existing IP QoS solutions. The existing IP QoS solutions can be categorized as follows: * End-to-end per-flow resource reservation protocols * Integrated Services over Differentiated Services * Statically assigned trunk reservations based on Differentiated Services * Dynamic trunk reservations with Aggregated RSVP de Meer, et al. Expires November 2002 [Page 2] Internet Draft Analysis of Existing QoS Solutions May 2002 Table of Contents 1 Introduction ................................................. 4 2 Criteria used in the analysis ................................ 6 3 End-to-end per-flow resource reservation protocol ............ 6 3.1 Analysis based on requirements in [Brun02] ................. 7 3.2 Analysis based on open issues in [Brun02] .................. 14 3.3 Analysis based on requirements in [PaKa02] ................. 15 4 Integrated Services over Differentiated Services ............. 16 4.1 Analysis based on requirements in [Brun02] ................. 18 4.2 Analysis based on open issues in [Brun02] .................. 25 4.3 Analysis based on requirements in [PaKa02] ................. 26 5 Statically-assigned trunk reservations based on DiffServ ..... 28 5.1 Analysis based on requirements in [Brun02] ................. 30 5.2 Analysis based on open issues in [Brun02] .................. 36 5.3 Analysis based on the requirements in [PaKa02] ............. 37 6 Dynamic trunk reservations with Aggregated RSVP .............. 38 6.1 Analysis based on the requirements in [Brun02] ............. 39 6.2 Analysis based on open issues in [Brun02] .................. 45 6.3 Analysis based on requirements in [PaKa02] ................. 47 7 Conclusions .................................................. 48 8 References ................................................... 51 9 Acknowledgments .............................................. 53 10 Editors' Addresses .......................................... 53 de Meer, et al. Expires November 2002 [Page 3] Internet Draft Analysis of Existing QoS Solutions May 2002 1. Introduction QoS support in IP networks can be traced back to the seminal Sigcomm92 paper on the "Integrated Service Packet Network" model (ISPN) by Clark, Shenker and Zhang [CSZ92]. Roughly, the ISPN model is built on four columns: * A QoS specification and requirements description, which could be seen as a description of a service level agreement that must be honored by a given QoS architecture. * Mechanisms for admission control or traffic conditioning when resources are finite and contention may arise. * Scheduling and other mechanisms to be in place at the network nodes to enforce preferential forwarding and processing of data packets. Network resources must be in place to assure the specified QoS. * Signalling and service interfaces to convey information on preferences and expectations (requirements) of data packet processing and forwarding from applications to relevant control elements of network resources and from there back to the applications. Finally, a QoS architecture is needed that integrates all four columns into an end-to-end solution. At this point nothing is precluded in terms of the interpretation of such an end-to-end architecture. The requirement for an end-to-end QoS solution does not necessarily mean that a single resource reservation signalling protocol must be applied end-to-end. In fact, it is most likely that the end-to-end QoS management architecture will consist of many interoperable and concatenated QoS management architectures rather than one global end-to-end QoS infrastructure. "Next Steps for the IP QoS Architecture" [RFC2990] for example, recognizes that, "both the Integrated Services architecture and the Differentiated Services architecture have some critical elements in terms of their current definition which appear to be acting as deterrents to widespread deployment... There appears to be no single comprehensive service environment that possesses both service accuracy and scaling properties". This statement sums up the reasons behind both the proposal of hybrid architectures composed of IntServ and DiffServ regions (with the associated problems related to mapping and interworking procedures between different regions) and the de Meer, et al. Expires November 2002 [Page 4] Internet Draft Analysis of Existing QoS Solutions May 2002 necessity/opportunity of improving/upgrading the IntServ and DiffServ paradigms. Well-known interpretations are IntServ, DiffServ and even heterogeneous interpretations such as IntServ over DiffServ. Other interpretations may still be to come. Each column, however, may be realized differently in each interpretation. For example, resources may be claimed based on the granularity of flows or aggregates. Signalling would similarly reflect the right level of granularity and could be implicit or explicit. For example, RSVP [RFC2205], one of most prominent signalling protocols has been adopted within the IntServ architecture for resource reservations. Admission control could be explicit by or implicit by overprovisioning and conditioning, etc. In this draft a brief analysis is given of existing IP QoS solutions and the implied signalling issues. The analysis is intended to point out open QoS signalling issues (column 4). Where needed, we will also touch on related admission control or traffic conditioning issues. The main goal of this analysis is to understand whether the strict QoS requirements imposed on networks by future fixed and mobile applications are satisfied by the existing IP QoS solutions. The main existing IP QoS solutions can be categorized as follows: * End-to-end per-flow resource reservation protocol: uses a per-flow resource reservation signalling protocol that is applied in an end-to-end communication path. * Integrated Services over Differentiated Services: a framework that provides end-to-end QoS using the IntServ model over heterogeneous networks. * Statically assigned trunk reservations based on Differentiated Services: several individual reservations are aggregated into a common reservation trunk that is statically configured. * Dynamic trunk reservations with Aggregated RSVP: several individual reservations are aggregated into a common reservation trunk. Additionally, these trunks are dynamically configured by using a signalling protocol that manages various mechanisms for dynamic creation of an aggregate reservation. de Meer, et al. Expires November 2002 [Page 5] Internet Draft Analysis of Existing QoS Solutions May 2002 2. Criteria used in the analysis This section lists the criteria that are used for analyzing the existing QoS solutions explained in this draft. These criteria are: * The requirements in "Requirements for QoS Signalling Protocols" [Brun02]. * Several open issues included in [Brun02]. * Several requirements included in "NSIS QoS Signalling Requirements" [PaKa02] 3. End-to-end per-flow resource reservation protocol An end-to-end per-flow resource reservation signalling protocol is applied in an end-to-end communication path, and it can be used by an application to make known and reserve its QoS requirements to all the network nodes in this path. This type of protocol is typically initiated by an application at the beginning of a communication session. A communication session is typically identified by the combination of the IP destination address, transport layer protocol type and the destination port number. The resources reserved by such a protocol for a certain communication session will be used for all packets belonging to that particular session. Therefore, all resource reservation signalling packets will include details of the session to which they belong. The end-to-end per-flow resource reservation signalling protocol most widely used today is the Resource Reservation Protocol (RSVP) (see [RFC2205]). The main RSVP messages are the PATH and RESV messages. The PATH message is sent by a source that initiates the communication session. It installs states on the nodes along a data path. Furthermore, it describes the capabilities of the source. The RESV message is issued by the receiver of the communication session, and it follows exactly the path that the RSVP PATH message traveled back to the communication session source. On its way back to the source, the RESV message may install QoS states at each hop. These states are associated with the specific QoS resource requirements of the destination. The RSVP reservation states are temporary states (soft states) that have to be updated regularly. This means that PATH and RESV messages will have to be retransmitted periodically. If these states are not refreshed then they will be removed. RSVP uses additional messages either to provide information about the QoS state de Meer, et al. Expires November 2002 [Page 6] Internet Draft Analysis of Existing QoS Solutions May 2002 or explicitly to delete the QoS states along the communication session path. RSVP uses in total seven types of messages: * PATH and RESV messages * RESV Confirm message * PATH Error and RESV Error messages * PATH Tear and RESV Tear messages 3.1. Analysis based on requirements in [Brun02] This section describes the analysis of RSVP (described in [RFC2205]) using the criteria that are based on the requirements in [Brun02]. The number enclosed between the brackets is the section number in [Brun02] where the requirement is described. For the complete description of these requirements, refer to [Brun02]. [5.1.1] - Applicability for different QoS technologies: RSVP was developed to be used in the Integrated Services architecture, although it can be used with other QoS technologies as well. However, even though the information exchanged over the signalling protocol is detailed enough and useful for various QoS technologies, there is still a need for mapping of this information into understandable format for other QoS technologies, e.g. mapping of IntServ type of services to DiffServ type of services. [5.1.2] - Resource availability information on request: RSVP does not have functionality that makes it possible to query for available resources without performing a reservation of the resource. [5.1.3] - Modularity: RSVP is a flexible protocol in the sense that it defines a flexible set of objects. However, RSVP does not support modularity as it does not allow for more lightweight implementations, if fewer features are needed in certain parts of the network. de Meer, et al. Expires November 2002 [Page 7] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.1.4] - Decoupling of protocol and information it is carrying: RSVP does not support this requirement. The signalling protocol(s) is not separated from the QoS control information it is transporting. [5.1.5] - Reuse of existing QoS provisioning: From the RSVP perspective, this requirements is irrelevant as the motivation for it is not to 're-invent the wheel' but to reuse existing QoS functions and protocols for QoS provisioning within a domain/subdomain unchanged, to which RSVP belongs as well. [5.1.7] - Independence of signalling and provisioning paradigm: RSVP provides independence of signalling and provisioning mechanisms. [5.2.1] - Free placement of QoS Initiator and QoS Controllers functions: RSVP is designed as a protocol that is initiated and terminated by end hosts. This means that the QoS Initiator and QoS Controllers reside at the end hosts, and they cannot be placed freely in the communication path. However, extensions to RSVP (e.g., RSVP proxy, RSVP-TE, IntServ over DiffServ) have made it possible to apply the protocol in scenarios other than end-to-end signalling scenarios, such as edge-to-edge, (e.g., just within one providers domain), user-to-network (from end system into the network, ending, e.g., at the entry to the network and vice versa), network-to-network (e.g., between providers). [5.2.2] - No constraint of the QoS signalling and QoS Controllers to be in the data path: RSVP does not fulfill this requirement as the signalling is bound to the data path. [5.2.3] - Concealment of topology and technology information: RSVP supports this requirements as it can be forwarded transparently through the network. [5.3.1] - Explicit release of resources: de Meer, et al. Expires November 2002 [Page 8] Internet Draft Analysis of Existing QoS Solutions May 2002 RSVP supports explicit release of resources by means of RESV TEARDOWN message. [5.3.2] - Possibility for automatic release of resources: After failure, RSVP partially supports this feature since the reservation state management is a combination of the soft state principle and explicit release. The reserved resources will be released if not refreshed in a certain period of time. This means that in case of a failure there will be no refresh messages sent and as a result the resources will be released. However, automatic release of the resources is not supported in RSVP. PATH TEARDOWN can only be sent by the sender end host and the RESV TEARDOWN message can only be sent by the receiver end-host. [5.3.3] - Possibility for automatic re-setup of resources after recovery: RSVP does not support this requirement. [5.3.4] - Prompt notification of QoS violation in case of error or failure to QoS Initiator and QoS Controllers: RSVP supports this requirement by means of error messages, i.e. PATH Error and RESV Error and also Error Object. [5.3.5] - Feedback about success of request for QoS guarantees: In RSVP, the success of resource request is reported by a successful admission control function. However, there is no further information given related to it. [5.4.1] - The signalling protocol and QoS control information should be application independent: RSVP itself is application independent, but the applications that use RSVP to signal their requirements to network elements have to be RSVP-aware. [5.5.1] - Mutability information on parameters: RSVP supports this requirement by means of ADSPEC object in the PATH message. [5.5.2] - Possibility to add and remove local domain information: de Meer, et al. Expires November 2002 [Page 9] Internet Draft Analysis of Existing QoS Solutions May 2002 RSVP is a flat protocol with the same functionality in every node in the communication path. As such it does not support this requirement. [5.5.3] - Independence of reservation identifier: RSVP does not support this requirement as the reservation is identified by means of the flow identifier. [5.5.4] - Seamless modification of already reserved QoS: RSVP supports this requirement by means of refresh messages and the modify function in traffic admission control. [5.5.5] - Signalling must support quantitative, qualitative, and relative QoS specifications: This requirement is supported by RSVP as it enables signalling for IntServ services, i.e. Guaranteed and Controlled service. [5.6.1] - Scalability in the number of messages received by a signalling communication partner (QoS initiator and controller): There are seven types of messages defined in RSVP that are needed for setting up, maintaining and releasing the RSVP signalling session. All of these messages are sent per-flow, thus the number of messages received by a signalling communication partner increases linearly proportional to the number of flows, i.e. RSVP signalling sessions. This may scale well in those type of networks where the number of flows is modest, but it will introduce scalability problems in networks with a large number of flows. [5.6.2] - Scalability in number of hand-offs: RSVP does not support hand-offs, therefore nothing can be said related to this requirement. [5.6.3] - Scalability in the number of interactions for setting up a reservation: The reservation setup by means of RSVP requires two interactions: - PATH message sent from the sender to the receiver - RESV message sent from the receiver to the receiver This needs to be done for each flow. As in the previous requirement this will scale well in those type of networks where de Meer, et al. Expires November 2002 [Page 10] Internet Draft Analysis of Existing QoS Solutions May 2002 the number of flows is modest, but it may introduce scalability problems in network with a large number of flows. [5.6.4] - Scalability in the number of states per entity (QoS initiators and QoS controllers): RSVP installs one reservation state per flow. This means that the number of states increases linearly with the number of flows. This introduces severe scalability problems in the networks where the number of flows is large. [5.6.5] - Scalability in CPU use (end terminal and intermediate nodes): RSVP is a receiver-initiated protocol designed for unicast and multicast reservations. As such the RSVP "soft" state maintenance is complex as it needs to support dynamic membership changes in the multicast group, i.e. reservation state merging and maintenance. This requires complex processing that will most probably affect the CPU utilization. Furthermore the CPU utilization will also be affected by the per-flow filtering/classification of the data traffic required in RSVP. [5.6.6] - Low latency in setup: The reservation setup in RSVP is dependent on the RTT of signalling messages. However, this RTT in any case will be shorter than of common IP packets as the RSVP signalling messages are sent with the IP router alert option set that enables faster processing in the routers. [5.6.7] - Allow for low bandwidth consumption for signalling protocol: Not applicable. [5.6.8] - Ability to constrain load on devices: RSVP does not support this requirement. [5.7.1] - Aggregation capability, including the capability to select and change the level of aggregation: RSVP does not support this requirement. de Meer, et al. Expires November 2002 [Page 11] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.7.2] - Flexibility in the placement of the QoS initiator: RSVP does not support this requirement. [5.7.3] - Flexibility in the initiation of re-negotiation (QoS change requests): RSVP supports this requirement by means of refresh messages and modify admission control functions. [5.7.4] - Uni / bi-directional reservation: RSVP does support uni-directional reservation, but it does not support bi-directional reservations. [5.8.1] - The QoS protocol must provide strong authentication: RSVP supports this requirement by means of the Integrity object [RFC2747]. [5.8.2] - The QoS protocol must provide means to authorize resource requests: RSVP supports this requirement by means of the Policy object. [5.8.3] - The QoS signalling messages must provide integrity protection: RSVP supports this requirement by means of the Integrity object. [5.8.4] - The QoS signalling messages must be replay protected: RSVP supports this requirement by means of Path State Base (PSB) and Reservation State Base (RSB). [5.8.5] - The QoS signalling protocol must allow for hop-by-hop security: RSVP supports this requirement by means of the Integrity object [RFC2747]. [5.8.6] - The QoS protocol should allow identity confidentiality and location privacy: RSVP supports this requirement by means of the Integrity object. de Meer, et al. Expires November 2002 [Page 12] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.8.7] - The QoS protocol should prevent denial-of-service attacks against signalling entities: RSVP supports this requirement by means of the Integrity object. [5.8.8] - The QoS protocol should support confidentiality of signalling messages: RSVP supports this requirement by means of the Integrity object. [5.8.9] - The QoS protocol should provide hooks to interact with protocols that allow the negotiation of authentication and key management protocols: RSVP supports this requirement by means of the Integrity object. [5.8.10] - The QoS protocol should provide means to interact with key management protocols: RSVP supports this requirement partially as the key management is actually used in the Integrity object. [5.10.1] - Interworking with IP tunneling: RSVP supports RSVP tunneling [RFC2746]. [5.10.2] - The solution should not constrain either to IPv4 or IPv6: RSVP supports this requirement. [5.10.3] - Independence from charging model: RSVP supports this requirement. [5.10.4] - The QoS protocol should provide hooks for AAA protocols: RSVP does not support this requirement. [5.11.1] - Ability to assign transport quality to signalling messages: RSVP supports this requirement by means of IP router alert option, because given this and RSVP protocol number, the RSVP signalling messages are processed faster in the routers. This enables certain transport quality. de Meer, et al. Expires November 2002 [Page 13] Internet Draft Analysis of Existing QoS Solutions May 2002 3.2. Analysis based on open issues in [Brun02] This section describes the analysis of RSVP (described in [RFC2205]) using the criteria that are based on the open issues in [Brun02]. The number in brackets is the number of the open issue used in [Brun02], where the issue is described. For the description of these open issues, refer to [Brun02]. [2] - Open issue 2: Sender/receiver initiation, Sender initiated a MUST, receiver initiated a MAY: RSVP is a receiver-initiated protocol, thus it does not support this requirement. [8] - Open issue 8: Bi-directional data path setup with one QoS request: RSVP does not support bi-directional data path setup with a single QoS request. It can only support bi-directional requests as a combination of two single uni-directional requests. [33] - Open issue 33: Highest possible network utilization: RSVP provides high network utilization up to the point where the scalability of the network is not affected. [36] - Open issue 36: Independence of reservation identifier: RSVP does not support this requirement (see above). [53] - Open issue 53: this open issue is a requirement described in Section 5.1.16. of [PaKa02] - Error handling and redundancy considerations: RSVP supports this requirement by means of the error signalling messages. [55] - Open issue 55: this open issue is a requirement described in Section 5.2.2. of [PaKa02] - Allow local QoS information exchange between two border nodes: RSVP is an end-to-end protocol and as such does not support any information exchange between the border nodes. de Meer, et al. Expires November 2002 [Page 14] Internet Draft Analysis of Existing QoS Solutions May 2002 [59] - Open issue 59: this open issue is a requirement described in Section 5.3.4. of [PaKa02] - "Ability to deal with severe congestion": RSVP supports this requirement. [60] - Open issue 60: this open issue is a requirement described in Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment after handover": RSVP does not support mobility. As such it does not allow efficient QoS re-establishment after handover as in these cases it needs to re-initiate a new signalling session. 3.3. Analysis based on requirements in [PaKa02] This section describes the analysis of RSVP (described in [RFC2205]) using the criteria that are based on the requirements described in [PaKa02]. The number enclosed between the brackets is the section number in [PaKa02] where the requirement is described. For the complete description of these requirements, refer to [PaKa02]. [5.2.3] - Allow generation of local QoS signalling messages: RSVP does not support generation of local QoS signalling messages. [5.3.1.1] - Modular: RSVP is not modular. [5.3.1.2] - Simple: RSVP is very flexible, and can be applicable in many and different scenarios. This increases its complexity. [5.3.1.3] - Minimal Impact on Performance: Due to its complexity RSVP impacts the performance of the interior nodes. [5.3.2] - Ability to deal with mobility (handover): de Meer, et al. Expires November 2002 [Page 15] Internet Draft Analysis of Existing QoS Solutions May 2002 RSVP cannot efficiently support this requirement. [5.3.3] - On-demand, dynamic signalling for efficient network utilization: RSVP provides on-demand and dynamic signalling. [5.3.4] - Ability to deal with severe congestion: RSVP is able to support severe congestion solutions. [5.3.5] - Optimize for unicast transport: RSVP is not optimized for unicast reservations. [5.3.6] - Ability to transparently traverse an interior node: This requirement can be supported by RSVP when traversing non-RSVP aware nodes. [5.3.7] - Use of a simple QoS parameter: RSVP uses more than one QoS parameters (TSPEC, RSPEC, ADSPEC). 4. Integrated Services over Differentiated Services The IntServ over DiffServ architecture addresses the problem of providing end-to-end QoS using the IntServ model over heterogeneous networks. In this scenario, DiffServ is one of these networks providing edge-to-edge QoS. The IntServ over DiffServ architecture allows at least two different possible deployment strategies. The first is based on statically allocated resources in the DiffServ domain. In this strategy, the DiffServ domain is statically provisioned. Furthermore, with this strategy the devices in the DiffServ network region are not RSVP (or any other dynamic signalling) aware. However, it is considered that each edge node in the customer network consists of two parts. One part of a node is a standard IntServ that interfaces to the customer's network region and the other part of the same node interfaces to the DiffServ network region. All edge nodes in the customer network maintain a table that indicates the capacity provisioned per SLS (Service Level Specification) at each DiffServ service level. This table is used to make admission control decisions de Meer, et al. Expires November 2002 [Page 16] Internet Draft Analysis of Existing QoS Solutions May 2002 on IntServ flows that cross the DiffServ region. A disadvantage of this approach is that the edge nodes in the customer network will not be aware of the traffic load in the nodes located within the DiffServ domain. Therefore, a congestion situation on a communication path within the DiffServ domain cannot be detected by any of these edge nodes. Congestion within a DiffServ domain may arise due to difficulties in static provisioning [RFC2990]. Repeated steps of aggregations/disaggregations of traffic aggregates or other stochastic disturbances may adversely affect the QoS. In contrast to the IntServ architecture, no mathematical proof of a reliable QoS delivery by DiffServ architectures has yet been provided. An immediate conclusion is to take such possibilities into account from the outset. Accordingly, further improvements could be achieved by providing congestion signalling from within such a DiffServ domain to the border between the two administrative domains in question. As is the case with TCP control, it is anticipated that (some) "subscribers" to such a disturbed service would back off and thus improve the traffic load situation within the domain. Appropriate signalling mechanisms would be needed that reflect violation of a specified QoS level. If subscribers do back off the original QoS level would be resumed. Feedback information and signalling is needed in the next generation of a DiffServ architecture that delivers its specified classes of service by a combination of resource provisioning and cooperation with the subscribers. This would be similar to native TCP/IP environments, but with integrated DiffServ characteristics. While resource provisioning is static and does cover the most common and regular case of QoS support, feedback signalling and adaptation or dynamic conditioning would deal with the (hopefully) rare event of insufficient provisioning. Note that the original service specification would explicitly entail the possibility of a reduction in the advertised DiffServ bandwidth and the expectation of subscribers to back off according the to needs of reestablishing a DiffServ QoS class. More details of this concept is given in [DO01]. The second possible strategy is based on dynamically allocated resources in the DiffServ domain. According to [RFC2998], this can be done using RSVP-aware DiffServ routers. However, this approach has most of the RSVP drawbacks, and per-microflow state information is kept in the intermediate routers. Furthermore, dynamic provisioning may be too slow to respond quickly enough to congestion events. Alternatively, resources in the DiffServ domain can be dynamically de Meer, et al. Expires November 2002 [Page 17] Internet Draft Analysis of Existing QoS Solutions May 2002 allocated using Aggregated RSVP. Other approaches related to the bandwidth broker concept are still very immature and will not be discussed here. 4.1. Analysis based on requirements in [Brun02] This section describes the analysis of the IntServ over DiffServ protocol described in [RFC2998] using the criteria that are based on the requirements in [Brun02]. The number enclosed between the brackets is the section number in [Brun02] where the requirement is described. For the complete description of these requirements, refer to [Brun02]. [5.1.1] - Applicability for different QoS technologies: IntServ architecture provides a means for end-to-end QoS over heterogeneous networks. In particular, a network element that supports DiffServ can be seen as network element of a specific type in the total end-to-end path. [5.1.2] - Resource availability information on request: RSVP as the signalling protocol can be used to capture resource availability information for the IntServ capable network segments. In cases where the DiffServ domain is also RSVP aware, this information would also be available for DiffServ subnets. RSVP is seen as a method for dynamic provisioning and for providing feedback information on resource availability. However, RSVP by itself does not support this requirement as it does not check the resource availability without actual resource reservation. [5.1.3] - Modularity: IntServ is designed to accommodate signalling protocols other than RSVP. In fact, IntServ, RSVP and services classes are all separable. IntServ is the specific architecture or model, RSVP the specific signalling mechanism, and two service classes have been defined (others were discussed, and could still be invented). Similar arguments apply to DiffServ: provisioning can be static or dynamic, signalling can be distributed and in band (RSVP) or out of band and centralized, or combinations thereof. Conditioning can be static or dynamic, and most combinations thereof are possible. de Meer, et al. Expires November 2002 [Page 18] Internet Draft Analysis of Existing QoS Solutions May 2002 IntServ and DiffServ can almost orthogonally combined with each other in either mode as discussed here. [5.1.4] - Decoupling of protocol and information it is carrying: RSVP can be used as a more general signalling vehicle and applied in other contexts and convey information other than what is needed for Controlled Load and Guaranteed Services. In particular, RSVP can be used to perform bandwidth (or more general profile-based) reservations in DiffServ domains, that is, for behavior aggregates. [5.1.5] - Reuse of existing QoS provisioning: Overprovisioning, static or dynamic provisioning, all apply equally well. Important for provisioning is mapping on the underlying link technology. Note, one type of "link" could be DiffServ within an end-to-end IntServ path. But other link technologies have to be taken into account for provisioning as well, eg. 802.1, 802.11, etc. (see RFC 2815). [5.1.7] - Independence of signalling and provisioning paradigm: This does not seem to be true as signalling has widely been used for provisioning in DiffServ (and of course in IntServ) This is probably often the case if BW resources other than best-effort type are involved. [5.2.1] - Free placement of QoS Initiator and QoS Controllers functions: QoS controllers are the network elements, e.g., the routers and links. QoS initiators are the applications on the attached hosts. But network elements can be more complex entities such as whole sub-networks. In [RFC2998] it does not seem to be anticipated to have complete freedom in placement of initiators and controllers. Some flexibility may be availble, however: edge vs. border, vs. node, for example. [5.2.2] - No constraint of the QoS signalling and QoS Controllers to be in the data path: In the IntServ domain QoS signalling and control are performed in the data path while in DiffServ domains possible segments within the end-to-end path allow both forms: signalling and control in- de Meer, et al. Expires November 2002 [Page 19] Internet Draft Analysis of Existing QoS Solutions May 2002 band or out-of-band or a combination of both. [5.2.3] - Concealment of topology and technology information: This does not seem to be generally the case, in particular in the mapping process. [5.3.1] - Explicit release of resources: The IntServ model is based on soft state and time out of reservations. Explicit release is possible, however, in some DiffServ networks with an implementation of dynamic SLAs (dynamic conditioners such as in the Adaptive Segmented Adaptation framework). [5.3.2] - Possibility for automatic release of resources after failure: IntServ supports automatic release of resources after failure or any other event making the reservation obsolete. If the reservation state is not refreshed repeatedly it will expire automatically. IntServ is fail safe in that respect. This is not true for DiffServ network elements. [5.3.3] - Possibility for automatic re-setup of resources after recovery: An automatic recovery has not been incorporated. [5.3.4] - Prompt notification of QoS violation in case of error / failure to QoS Initiator and QoS Controllers: A prompt notification is missing in this framework. In the IntServ model failures or QoS violations are noticed when refreshment of reservation state fails. QoS violation in the DiffServ network element has not yet been considered widely, at least not in RFC2998. This is probably the greatest lack of signalling element in the whole framework as presented in RFC2998. Signalling is almost exclusively reserved for the set-up phase. Further operational feedback possibilities are widely ignored, both implicit or explicit. Best-effort TCP/IP would not work without feedback and adaptation. Therefore, neglecting it in QoS architectures may not be wise. [5.3.5] - Feedback about success of request for QoS guarantees: de Meer, et al. Expires November 2002 [Page 20] Internet Draft Analysis of Existing QoS Solutions May 2002 This is provided in IntServ, widely realized in dynamically provisioned DiffServ with RSVP as the signalling mechanism. [5.4.1] - The signalling protocol and QoS control information should be application independent: Similar to RSVP. [5.5.1] - Mutability information on parameters: This does not seem to hold for the framework as discussed in RFC2998. [5.5.2] - Possibility to add and remove local domain information: This is certainly the case for DiffServ network elements. Maybe it can be extended however. Extensions are possible in terms of additional control information that can be exploited by signalling such as RSVP. In particular, for specific link types, congestion avoidance strategies, etc. However, that seems to be lacking in RFC2998. It could, however, easily be extended, it seems. IntServ also allows some local domain info to be manipulated. [5.5.3] - Independence of reservation identifier: This can be accomplished only within the DiffServ domain but not end-to-end. [5.5.4] - Seamless modification of already reserved QoS: In IntServ domains reservation states can be dynamically changed. It should be seamless. But it is not certain what happens if an increase of reservation fails, if that could lead to a disruption. Change of reservation state in DiffServ clouds is not always possible. DiffServ network regions may be statically provisioned. A dynamic change of reservation state may be disruptive in RSVP- aware DiffServ regions as, for example, admission control and paths may be decoupled in case only edge routers are RSVP-capable. If interior routers are also RSVP-capable, more detailed reservation state information can be signalled and modified explicitly. [5.5.5] - Signalling must support quantitative, qualitative, and relative QoS specifications: de Meer, et al. Expires November 2002 [Page 21] Internet Draft Analysis of Existing QoS Solutions May 2002 IntServ and RSVP support quantitative (guarantee), qualitative (controlled load) and relative (best effort) services. In DiffServ, EF and various AF classes fulfill these requirements. With appropriate mappings (guarantee over EF) end-to-end services can be generated. [5.6.1] - Scalability in the number of messages received by a signalling communication partner (QoS initiator and controller): DiffServ network elements are introduced to improve scalability in core networks. Open issues are signalling and provisioning overhead that could reduce scalability again if applied dynamically. [5.6.2] - Scalability in number of hand-offs: Not applicable. [5.6.3] - Scalability in the number of interactions for setting up a reservation: Same arguments as in [5.6.1]. [5.6.4] - Scalability in the number of state per entity (QoS initiators and QoS controllers): Same arguments as in [5.6.1]. [5.6.5] - Scalability in CPU use (end terminal and intermediate nodes): Question of where to perform traffic classification and marking. Most efficiently done at the edges and end hosts. [5.6.6] - Low latency in setup: Static provisioning and admission control helps in DiffServ. IntServ is relatively slow (including RSVP). [5.6.7] - Allow for low bandwidth consumption for signalling protocol: Out-of-band signalling would be most suitable here. [5.6.8] - Ability to constrain load on devices: de Meer, et al. Expires November 2002 [Page 22] Internet Draft Analysis of Existing QoS Solutions May 2002 Conditioning in many forms is a prerequisite. [5.7.1] - Aggregation capability, including the capability to select and change the level of aggregation: Clearly supported in RFC2998 framework as BA, aggregated RSVP or flow-based RSVP are all included mechanisms. [5.7.2] - Flexibility in the placement of the QoS initiator: Not supported. [5.7.3] - Flexibility in the initiation of re-negotiation QoS change requests): It is included in the framework: IntServ allows re-signalling at any time. Possible in DiffServ with dynamic signalling and provisioning mechanisms based on RSVP. [5.7.4] - Uni / bi-directional reservation: Only unidirectional reservations are supported. [5.8.1] - The QoS protocol must provide strong authentication: Security received only limited consideration. However, RSVP security is considered in [RFC2747] and applies fully here. Furthermore, host marking issues and self-protection of network elements are discussed in DiffServ networks. Each DS domain controls access and modification of packets whilst entering and traversing its network. The DS field is not protected by IPsec Authentication Header, as it is an excluded field. IntServ is more concerned only with contract fulfillment and policing accordingly. [5.8.2] - The QoS protocol must provide means to authorize resource requests: See explanation [5.8.1]. [5.8.3] - The QoS signalling messages must provide integrity protection: See explanation [5.8.1]. de Meer, et al. Expires November 2002 [Page 23] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.8.4] - The QoS signalling messages must be replay protected: See explanation [5.8.1]. [5.8.5] - The QoS signalling protocol must allow for hop-by-hop security: See explanation [5.8.1]. [5.8.6] - The QoS protocol should allow identity confidentiality and location privacy: See explanation [5.8.1]. [5.8.7] - The QoS protocol should prevent denial-of-service attacks against signalling entities: See explanation [5.8.1]. [5.8.8] - The QoS protocol should support confidentiality of signalling messages: See explanation [5.8.1]. [5.8.9] - The QoS protocol should provide hooks to interact with protocols that allow the negotiation of authentication and key management protocols: Not specified. [5.8.10] - The QoS protocol should provide means to interact with key management protocols: Not specified. [5.10.1] - Interworking with IP tunneling: IP tunneling is an inherent concept in the framework. In particular, RSVP may possibly be tunneled through DiffServ elements. Could apply at any link, but not necessarily. [5.10.2] - The solution should not constrain either to IPv4 or IPv6: This requirement is supported by [RFC2998]. de Meer, et al. Expires November 2002 [Page 24] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.10.3] - Independence from charging model: Not specified. [5.10.4] - The QoS protocol should provide hooks for AAA protocols: Not specified. [5.11.1] - Ability to assign transport quality to signalling messages: Not applicable within the DiffServ domain. 4.2. Analysis based on open issues in [Brun02] This section describes the analysis of the IntServ over DiffServ protocol described in [RFC2998] using the criteria that are based on the open issues in [Brun02]. The number in brackets is the number of the open issue used in [Brun02], where the issue is described. For the description of these open issues, refer to [Brun02]. [2] - Open issue 2: Sender/receiver initiation Sender initiated a MUST, receiver initiated a MAY: This requirement cannot be supported by [RFC2998]. [8] - Open issue 8: Bi-directional data path setup with one QoS request: This requirement is not supported by [RFC2998]. [33] - Open issue 33: Highest possible network utilization: This requirement cannot be supported within the DiffServ domain. [36] - Open issue 36: Independence of reservation identifier: It can only be applied within the DiffServ domain, but it cannot be supported end-to-end. [53] - Open issue 53: this open issue is a requirement described in Section 5.1.16. of [PaKa02] - Error handling and redundancy de Meer, et al. Expires November 2002 [Page 25] Internet Draft Analysis of Existing QoS Solutions May 2002 considerations: This requirement cannot be supported within the DiffServ domain. [55] - Open issue 55: this open issue is a requirement described in Section 5.2.2. of [PaKa02] - Allow local QoS information exchange between two border nodes: The two border nodes are able to exchange information between the border nodes, but this information is not local. [59] - Open issue 59: this open issue is a requirement described in Section 5.3.4. of [PaKa02] - "Ability to deal with severe congestion": This requirement cannot be supported within the DiffServ domain. [60] - Open issue 60: this open issue is a requirement described in Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment after handover": Not applicable. 4.3. Analysis based on requirements in [PaKa02] This section describes the analysis of the IntServ over DiffServ protocol described in [RFC2998] using the criteria that are based on the requirements in [PaKa02]. The number enclosed between the brackets is the section number in [PaKa02] where the requirement is described. For the complete description of these requirements, refer to [PaKa02]. [5.2.3] - Allow generation of local QoS signalling messages: This is partly fulfilled for DiffServ network elements: borders and edges can interchange roles. [5.3.1.1] - Modular: Modular within the DiffServ domain. [5.3.1.2] - Simple: de Meer, et al. Expires November 2002 [Page 26] Internet Draft Analysis of Existing QoS Solutions May 2002 Simplicity is of equal concern as efficiency. But there is a tradeoff: signalling vs. bandwidth, for example (static vs. dynamic) [5.3.1.3] - Minimal Impact on Performance: It is always considered, at least implicitly. [5.3.2] - Ability to deal with mobility (handover): Not applicable. [5.3.3] - On-demand, dynamic signalling for efficient network utilization: Inside the DiffServ domain this requirement is not supported (or is partially supported). [5.3.4] - Ability to deal with severe congestion: This scenario is mostly missing in RFC2998. Dynamic signalling has been limited to set-up functions: provisioning or resource reservations and feedback in that situation, but not during operation and possible interactions with users or subscriber.s [5.3.5] - Optimize for unicast transport: Multicast is of major concern. IntServ (RSVP) naturally supports multicast and group communication. That is why receiver-based resource reservations are of importance. In DiffServ, however, so far unicast is the only form of communication that is supported. It is an open research issue to provide heterogeneity support in DiffServ for multicast. Some effort has been spent in RFC2998 looking into this issue. [5.3.6] - Ability to transparently traverse an interior node: [RFC2998] supports this requirement. [5.3.7] - Use of a simple QoS parameter: The simpler the better, but this is only implicitly discussed in RFC2998. de Meer, et al. Expires November 2002 [Page 27] Internet Draft Analysis of Existing QoS Solutions May 2002 5. Statically-assigned trunk reservations based on DiffServ The [RFC2475] defines an architecture for implementing scalable service differentiation in the Internet, denoted as Differentiated Services (DiffServ). This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [RFC2474]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. A significant problem in deploying an end-to-end per-flow resource reservation signalling scheme is its scalability. This can be solved by aggregating (trunking) several individual reservations into a common reservation trunk. The reservation trunks can either be statically or dynamically configured. When the reservation trunks are statically configured, no signalling protocol is required for performing the reservation of network resources but is likely to be a difficult management problem. However, due to the different mobility requirements (such as handover) and QoS requirements (such as bandwidth) that the multi-bitrate applications impose on a network that supports mobile users, it will be difficult to configure the trunked reservations statically and at the same time utilize the network efficiently. In principle, the availability of DiffServ per-hop behaviors along with mechanisms to statically or dynamically limit the absolute level of traffic within a traffic class allows the DiffServ network cloud to act as a network element within the Integrated Services framework. In other words, an appropriately designed, configured and managed DiffServ network cloud can act as one component of an overall end-to- end QoS controlled data path using the Integrated Services framework, and therefore support the delivery of IntServ QoS services [WROCHA]. The key to providing absolute, quantitative QoS services within a DiffServ network is to ensure that at each hop in the network the resources allocated to the PHBs used for these services are sufficient to handle the arriving traffic. This can be done through a variety of mechanisms ranging from static provisioning to dynamic per-hop signalling within the cloud. Two situations are possible: * With per-cloud provisioning, sufficient resources are made available in the network so that traffic arriving at an ingress point can flow to "any" egress point without violating the PHB resource allocation requirements. In this de Meer, et al. Expires November 2002 [Page 28] Internet Draft Analysis of Existing QoS Solutions May 2002 case, admission control and traffic management decisions need not be based on destination information. * With per-path provisioning, resources are made available in the network to ensure that the PHB resource allocation requirements will not be violated if traffic arriving at an ingress point flows to one (in the unicast case) specific egress point. This requires that admission control and resource provisioning mechanisms take into account the egress point of traffic entering the network, but results in more efficient resource utilization. The per-cloud vs per-path decision is independent of decisions about static vs. dynamic provisioning. It is often assumed that dynamic provisioning is necessarily per-path, while static provisioning is more likely to be per-cloud. Hence, the existence of upper bounds on delay through the cloud implies centralized knowledge about the topology of the cloud and traffic characterization. These considerations imply that determination of the bound on the delay through the DiffServ cloud should be performed off-line, perhaps as part of a traffic management algorithm, based on the knowledge of the topology, traffic patterns, shaping policies, and other relevant parameters of the cloud [WROCHA]. However, this turns out to be a rather difficult task. Barring new results on delay bounds, the amount of traffic requiring end-to-end Guaranteed service (like) across the DiffServ cloud should be rather small, potentially leading to severe inefficiencies. Additionally, to provide a strict delay bound, the utilization factor of the bandwidth allocated to this traffic has to be deterministically bounded on all links in the network. This can be either ensured by signalled admission control (such as using dynamic resource reservation, e.g., [RMD], [BiaBle]) or by a static provisioning mechanism. It should be noted that if provisioning is used, then to ensure deterministic load/service rate ratio on all links, the network should be strongly overprovisioned to account for possible inaccuracy of traffic matrix estimates [WROCHA]. de Meer, et al. Expires November 2002 [Page 29] Internet Draft Analysis of Existing QoS Solutions May 2002 5.1. Analysis based on requirements in [Brun02] This section describes the analysis of the DiffServ architecture described in [RFC2475] using the requirements in [Brun02]. The number enclosed between the brackets is the section number in [Brun02] where the requirement is described. For the complete description of these requirements, refer to [Brun02]. [5.1.1] - Applicability for different QoS technologies: RFC2475 is being utilized by a number of QoS technologies. It is designed as flexible framework and is suited to deployment in a variety of approaches to QoS. [5.1.2] - Resource availability information on request: RFC2475 does not provide explicit APIs or functionality to make resource information available. However, higher level controller entities may provide such information but this is not in the explicit scope of RFC2475. [5.1.3] - Modularity: RFC2475 provides the basic QoS mechanisms, but does not specify how QoS is specified, thus the modularity issue is more relevant to higher level QoS controlling entities. [5.1.4] - Decoupling of protocol and information it is carrying: Not applicable. [5.1.5] - Reuse of existing QoS provisioning: RFC2475 in itself does not specify the mapping to underlying QOS mechanisms. However, the ISSLL working group specified mappings to a limited number of underlying technologies. [5.1.7] - Independence of signalling and provisioning paradigm: The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. RFC2475 specifies the architecture of the DiffServ deployment in terms of DiffServ domains. This de Meer, et al. Expires November 2002 [Page 30] Internet Draft Analysis of Existing QoS Solutions May 2002 specification does not limit the variety of deployable signalling and provisioning paradigms. [5.2.1] - Free placement of QoS Initiator and QoS Controllers functions: Not applicable. [5.2.2] - No constraint of the QoS signalling and QoS Controllers to be in the data path: With DiffServ, the QoS is signalled in the DS field of the data packets, thus the signalling is tied to the data path. However independent QoS controllers are possible outside the data path. [5.2.3] - Concealment of topology and technology information: RFC2475 does not provide features for topology discovery. [5.3.1] - Explicit release of resources: RFC2475 does not explicitly reserve resources, thus it consequently does not explicitly release resources. [5.3.2] - Possibility for automatic release of resources after failure: Not applicable. [5.3.3] - Possibility for automatic re-setup of resources after recovery: Not applicable. [5.3.4] - Prompt notification of QoS violation in case of error / failure to QoS Initiator and QoS Controllers: Although not in scope of RFC2475, a mechanism to provide notification of QoS failure would be seen as an important facility provided by higher level QoS controller subsystem. [5.3.5] - Feedback about success of request for QoS guarantees: There is no specification of feedback mechanisms regarding success of QoS requests in RFC2475. However, local QoS edge devices may de Meer, et al. Expires November 2002 [Page 31] Internet Draft Analysis of Existing QoS Solutions May 2002 provide feedback at a higher level. [5.4.1] - The signalling protocol and QoS control information should be application independent: RFC2475 does not specify any application dependent mechanisms as it operates at the IP level. [5.5.1] - Mutability information on parameters: RFC2475 specifies that the QoS for a given packet is determined by the Per Hop Behavior assigned to it as a result of its code point. Thus, since the PHBs are assigned independently, the choice of code point cannot affect the PHB. However, if a certain code point becomes overloaded then QoS of the associated PHB may suffer. [5.5.2] - Possibility to add and remove local domain information: Not applicable. [5.5.3] - Independence of reservation identifier: The value of the reservation identifier (the DS code point) is completely independent of the IP address and flow ID. The actual mapping of such an identifier is consistent within one DS domain. [5.5.4] - Seamless modification of already reserved QoS: Since RFC2475 relies upon out-of-band creation of the PHB in a domain, the QoS modification would be seamless. However, the setup of PHB parameters is out scope of RFC2475. [5.5.5] - signalling must support quantitative, qualitative, and relative QoS specifications: Not applicable. [5.6.1] - Scalability in the number of messages received by a signalling communication partner (QoS initiator and controller): RFC2475 signals QoS implicitly and thus does not have a signalling overhead. [5.6.2] - Scalability in number of hand-offs: de Meer, et al. Expires November 2002 [Page 32] Internet Draft Analysis of Existing QoS Solutions May 2002 Not applicable [5.6.3] - Scalability in the number of interactions for setting up a reservation: Not applicable [5.6.4] - Scalability in the number of state per entity (QoS initiators and QoS controllers): RFC2475 specifies a framework for providing QoS through the use of packet marking, thus the QoS is implicitly signalled. This approach scales well in terms of network state, though to achieve reliable QoS guarantees the network requires careful provisioning. [5.6.5] - Scalability in CPU use (end terminal and intermediate nodes): Not applicable. [5.6.6] - Low latency in setup: Not applicable. [5.6.7] - Allow for low bandwidth consumption for signalling protocol: Not applicable. [5.6.8] - Ability to constrain load on devices: Not applicable. [5.7.1] - Aggregation capability, including the capability to select and change the level of aggregation: The traffic entering a DiffServ domain can be aggregated in a specific traffic class (i.e., PHB). However, there is no method for selecting and changing the level of aggregation. [5.7.2] - Flexibility in the placement of the QoS initiator: Not applicable. de Meer, et al. Expires November 2002 [Page 33] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.7.3] - Flexibility in the initiation of re-negotiation (QoS change requests): Not applicable. [5.7.4] - Uni / bi-directional reservation: Not applicable. [5.8.1] - The QoS protocol must provide strong authentication: There is no authentication for the DS field. There is no way to prevent tampering or determine if the DS field has been tampered with. It is assumed that each DS domain controls access and modification of packets whilst entering and traversing its network. The DS field is not protected by IPsec Authentication Header, as it is an excluded field. [5.8.2] - The QoS protocol must provide means to authorize resource requests: Not applicable. [5.8.3] - The QoS signalling messages must provide integrity protection: Not applicable. [5.8.4] - The QoS signalling messages must be replay protected: Not applicable. [5.8.5] - The QoS signalling protocol must allow for hop-by-hop security: Not applicable. [5.8.6] - The QoS protocol should allow identity confidentiality and location privacy: Not applicable. [5.8.7] - The QoS protocol should prevent denial-of-service attacks against signalling entities: de Meer, et al. Expires November 2002 [Page 34] Internet Draft Analysis of Existing QoS Solutions May 2002 Not applicable. [5.8.8] - The QoS protocol should support confidentiality of signalling messages: Not applicable. [5.8.9] - The QoS protocol should provide hooks to interact with protocols that allow the negotiation of authentication and key management protocols: Not applicable. [5.8.10] - The QoS protocol should provide means to interact with key management protocols: Not applicable [5.10.1] - Interworking with IP tunneling: RFC2475 defines the DS field in the TOS octet of the IP header, and the traffic class octet in IPv6. These fields are excluded from IPsec Authentication Header which means that IPsec does not provide authentication or protection of these fields. [5.10.2] - The solution should not constrain either to IPv4 or IPv6: The DS field for IPv4 and IPv6 is defined in RFC2474. [5.10.3] - Independence from charging model: RFC2475 does not specify any charging model, thus it is completely independent on this issue. [5.10.4] - The QoS protocol should provide hooks for AAA protocols: RFC2475 does not explicitly define AAA hooks, though it is not excluded. [5.11.1] - Ability to assign transport quality to signalling messages: Not applicable de Meer, et al. Expires November 2002 [Page 35] Internet Draft Analysis of Existing QoS Solutions May 2002 5.2. Analysis based on open issues in [Brun02] This section describes the analysis of the DiffServ architecture described in [RFC2475] using the criteria that are based on the open issues in [Brun02]. The number in brackets is the number of the open issue used in [Brun02], where the issue is described. For the description of these open issues, refer to [Brun02]. [2] - Open issue 2: Sender/receiver initiation, Sender initiated a MUST, receiver initiated a MAY: Not applicable. [8] - Open issue 8: Bi-directional data path setup with one QoS request: Not applicable. [33] - Open issue 33: Highest possible network utilization: In DiffServ architecture over-provisioning has to be used, therefore it is expected that this requirement cannot be fulfilled by the DiffServ architecture. [36] - Open issue 36: Independence of reservation identifier: Not applicable. [53] - Open issue 53: this open issue is a requirement described in Section 5.1.16 of [PaKa02] - Error handling and redundancy considerations: This requirement cannot be fulfilled by the DiffServ architecture. [55] - Open issue 55: this open issue is a requirement described in Section 5.2.2. of [PaKa02] - Allow local QoS information exchange between two border nodes: The DiffServ architecture is not possible to exchange local QoS information. [59] - Open issue 59: this open issue is a requirement described in Section 5.3.4. of [PaKa02] - "Ability to deal with severe de Meer, et al. Expires November 2002 [Page 36] Internet Draft Analysis of Existing QoS Solutions May 2002 congestion": The DiffServ architecture it is not able to support this requirement. [60] - Open issue 60: this open issue is a requirement described in Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment after handover": Not applicable. 5.3. Analysis based on the requirements in [PaKa02] This section describes the analysis of the DiffServ architecture described in [RFC2475] using requirements in [PaKa02] (see Section 2). [5.2.3] - Allow generation of local QoS signalling messages: Not applicable. [5.3.1.1] - Modular: The DiffServ architecture is modular since the complexity is moved at the edges of the domain and the functionality in the interior nodes is quite simple. [5.3.1.2] - Simple: The DiffServ architecture is simple. [5.3.1.3] - Minimal Impact on Performance: The DiffServ architecture does not use any dynamical protocol therefore, the performance of an interior node is not affected. [5.3.2] - Ability to deal with mobility (handover): It is not able to support this requirement. [5.3.3] - On-demand, dynamic signalling for efficient network utilization: It is not able to support this requirement. de Meer, et al. Expires November 2002 [Page 37] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.3.4] - Ability to deal with severe congestion: It is not able to support this requirement. [5.3.5] - Optimize for unicast transport: Not applicable. [5.3.6] - Ability to transparently traverse an interior node: Not applicable. [5.3.7] - Use of a simple QoS parameter: Not applicable. 6. Dynamic trunk reservations with Aggregated RSVP The reservation trunks can be dynamically configured by using a signalling protocol that manages various mechanisms for dynamic creation of an aggregate reservation, classification of the traffic to which the aggregate reservation applies, determination of the bandwidth needed to achieve the requirement, and recovery of the bandwidth when the sub-reservations are no longer required. The first router that handles the aggregated reservations could be called an Aggregator, while the last router in the transit domain that handles the reservations could be called a Deaggregator. The Aggregator and Deaggregator functionality is located in the edge nodes. In particular, an Aggregator is located in an ingress edge node, while a Deaggregator is located in an egress edge node, relative to the traffic source. The aggregation region consists of a set of aggregation-capable network nodes. The Aggregator can use a policy that can be based on local configuration and local QoS management architectures to identify and mark the packets passing into the aggregated region. For example, the Aggregator may be the base station that aggregates a set of incoming calls and creates an aggregate reservation across the edge-to-edge domain up to the Deaggregator. In this situation the call signalling is used to establish the end-to-end resource reservations. Based on policy, the Aggregator and Deaggregator will decide when the Aggregated states will be refreshed or updated. de Meer, et al. Expires November 2002 [Page 38] Internet Draft Analysis of Existing QoS Solutions May 2002 One example of a protocol that can be used to accomplish QoS dynamic provisioning via trunk reservations is the RSVP Aggregation signalling protocol specified in [RFC3175]. 6.1. Analysis based on the requirements in [Brun02] This section describes the analysis of the RSVP aggregation protocol described in [RFC3175] using the requirements in [Brun02]. [5.1.1] - Applicability for different QoS technologies: The RSVP aggregation protocol [RFC3175] is optimized for the Differentiated Services (DiffServ) QoS technology. [5.1.2] - Resource availability information on request: This requirement cannot be supported by [RFC3175] [5.1.3] - Modularity: RSVP aggregation [RFC3175] can aggregate multiple end to end micro-flows but this aggregation is not accomplished in a modular way. [5.1.4] - Decoupling of protocol and information it is carrying: This requirement is supported by [RFC3175]. The objects that include QoS information are standardized, but the information included in these objects can be dynamically modified. [5.1.5] - Reuse of existing QoS provisioning: This requirement cannot be supported by [RFC3175] [5.1.7] - Independence of signalling and provisioning paradigm: This requirement cannot be satisfied by [RFC3175] since the QoS signalling carries information that is specific for the QoS paradigm used in each router (that supports this protocol) [5.2.1] - Free placement of QoS Initiator and QoS Controllers functions: This requirement cannot be supported by [RFC3175] due to the fact de Meer, et al. Expires November 2002 [Page 39] Internet Draft Analysis of Existing QoS Solutions May 2002 that the aggregation domain has to be determined and consequently the placement of the aggregator and deaggregator will be on the user data path. [5.2.2] - No constraint of the QoS signalling and QoS Controllers to be in the data path: This requirement cannot be supported by [RFC3175] due to the fact that the aggregator/deaggregator must be located on the user data path. [5.2.3] - Concealment of topology and technology information: This requirement is supported by [RFC3175]. [5.3.1] - Explicit release of resources: This requirement is supported by [RFC3175]. [5.3.2] - Possibility for automatic release of resources after failure: This requirement can be supported by [RFC3175] [5.3.3] - Possibility for automatic re-setup of resources after recovery: This requirement cannot be supported by [RFC3175]. Only the aggregator or deaggregator can initiate the initiation or the refresh of the resources after recovery. [5.3.4] - Prompt notification of QoS violation in case of error / failure to QoS Initiator and QoS Controllers: This can be accomplished by using the PATHerror or RESVerror messages. [5.3.5] - Feedback about success of request for QoS guarantees: This feature is supported by [RFC3175] [5.4.1] - The signalling protocol and QoS control information should be application independent: RSVP aggregation protocol by itself is application independent. de Meer, et al. Expires November 2002 [Page 40] Internet Draft Analysis of Existing QoS Solutions May 2002 However, the applications that use RSVP aggregation to signal their requirements to network elements have to be RSVP aggregation-aware. [5.5.1] - Mutability information on parameters: The RSVP aggregation protocol supports this requirement by means of ADSPEC object in the PATHaggr message. [5.5.2] - Possibility to add and remove local domain information: The RSVP aggregation protocol is able to add and remove local domain information (between the aggregator and deaggregator). [5.5.3] - Independence of reservation identifier: The RSVP aggregation protocol does not support this requirement as the reservation is identified by means of the aggregated flow identifier. [5.5.4] - Seamless modification of already reserved QoS: RSVP aggregation protocol supports this requirement by means of the modify function in traffic admission control. [5.5.5] - Signalling must support quantitative, qualitative, and relative QoS specifications: This requirement is supported by RSVP aggregation protocol as it enables signalling for IntServ services, i.e. Guaranteed and Controlled service. [5.6.1] - Scalability in the number of messages received by a signalling communication partner (QoS initiator and controller): The number of the RSVP aggregation messages are linearly proportional to the number of the supported aggregated flows. Note that the number of aggregated flows is much less than the number of micro-flows. [5.6.2] - Scalability in number of hand-offs: RSVP aggregation protocol does not support hand-offs, therefore nothing can be said related to this requirement. de Meer, et al. Expires November 2002 [Page 41] Internet Draft Analysis of Existing QoS Solutions May 2002 [5.6.3] - Scalability in the number of interactions for setting up a reservation: The reservation setup by means of RSVP aggregation requires certain interactions. These interactions are linearly proportional to the number of the supported aggregated flows. [5.6.4] - Scalability in the number of state per entity (QoS initiators and QoS controllers): RSVP installs one reservation state per aggregate. This means that the number of states increases linearly with the number of aggregates. However, in a DiffServ-based domain the number of the aggregated RSVP sessions depends on: * The number of Aggregators/Deaggregators: this depends on the number of the edge nodes used. For example, in an IP-based wireless network, the number of the edge nodes can depend on the the number of based stations and controlling gateways. In cellular networks, the number of controlling gateways is high, and the number of base stations is in the range of thousands (see [PaKa01]). * The network topology used: when the communication is performed in a meshed way (that is, all-to-all), it will imply that many communication paths will have to be maintained by the network simultaneously. * The number of DiffServ Code Points (DSCPs) used: more than one traffic class will be supported within a network. Therefore, the number of the aggregated RSVP reservation states within such a network will be significant. [5.6.5] - Scalability in CPU use (end terminal and intermediate nodes): RSVP aggregation protocol is a receiver-initiated protocol designed for unicast and multicast reservations. As such, the RSVP aggregation "soft" state maintenance is complex as it needs to support dynamic membership changes in the multicast group, i.e. reservation state merging and maintenance. This requires complex processing that will most probably affect the CPU utilization. However, compared to RSVP, the CPU utilization will be less affected by the filtering/classification of the data traffic since de Meer, et al. Expires November 2002 [Page 42] Internet Draft Analysis of Existing QoS Solutions May 2002 this is accomplished on a per aggregate basis. [5.6.6] - Low latency in setup: The reservation setup in RSVP aggregation is dependent on the distance between aggregator and deaggregator and on the end to end RTT of (the end to end) RSVP signalling messages. However, this RTT in any case will be shorter than of common IP packets as the RSVP signalling messages are sent with the IP router alert option set that enables faster processing in the routers. [5.6.7] - Allow for low bandwidth consumption for signalling protocol: Not applicable [5.6.8] - Ability to constrain load on devices: The RSVP aggregation protocol supports this requirement by aggregating many flows into few aggregated flows. [5.7.1] - Aggregation capability, including the capability to select and change the level of aggregation: The RSVP aggregation protocol supports this requirement. [5.7.2] - Flexibility in the placement of the QoS initiator: The RSVP aggregation protocol does not support this requirement. [5.7.3] - Flexibility in the initiation of re-negotiation (QoS change requests): The RSVP aggregation protocol supports this requirement by means of refresh messages and modify admission control functions. [5.7.4] - Uni / bi-directional reservation: The RSVP aggregation protocol supports uni-directional reservation, but it does not support bi-directional reservations. [5.8.1] - The QoS protocol must provide strong authentication: The RSVP aggregation protocol supports this requirement by means de Meer, et al. Expires November 2002 [Page 43] Internet Draft Analysis of Existing QoS Solutions May 2002 of the Integrity object [RFC2747]. [5.8.2] - The QoS protocol must provide means to authorize resource requests: The RSVP aggregation protocol supports this requirement by means of the Policy object. [5.8.3] - The QoS signalling messages must provide integrity protection: The RSVP aggregation protocol supports this requirement by means of the Integrity object [RFC2747]. [5.8.4] - The QoS signalling messages must be replay protected: The RSVP aggregation protocol supports this requirement by means of Path State Base (PSB) and Reservation State Base (RSB). [5.8.5] - The QoS signalling protocol must allow for hop-by-hop security: The RSVP aggregation protocol supports this requirement by means of the Integrity object [RFC2747]. [5.8.6] - The QoS protocol should allow identity confidentiality and location privacy: The RSVP aggregation protocol supports this requirement by means of the Integrity object. [5.8.7] - The QoS protocol should prevent denial-of-service attacks against signalling entities: The RSVP aggregation protocol supports this requirement by means of the Integrity object. [5.8.8] - The QoS protocol should support confidentiality of signalling messages: The RSVP aggregation protocol supports this requirement by means of the Integrity object. [5.8.9] - The QoS protocol should provide hooks to interact with de Meer, et al. Expires November 2002 [Page 44] Internet Draft Analysis of Existing QoS Solutions May 2002 protocols that allow the negotiation of authentication and key management protocols: The RSVP aggregation protocol supports this requirement by means of the Integrity object. [5.8.10] - The QoS protocol should provide means to interact with key management protocols: The RSVP aggregation protocol supports this requirement partially as the key management is actually used in the Integrity object. [5.10.1] - Interworking with IP tunneling: The RSVP aggregation protocol does not specify how RSVP aggregation tunneling should be performed. [5.10.2] - The solution should not constrain either to IPv4 or IPv6: The RSVP aggregation protocol supports this requirement. [5.10.3] - Independence from charging model: The RSVP aggregation protocol supports this requirement. [5.10.4] - The QoS protocol should provide hooks for AAA protocols: The RSVP aggregation protocol does not support this requirement. [5.11.1] - Ability to assign transport quality to signalling messages: The RSVP aggregation protocol supports this requirement by means of RSVP-E2E-IGNORE protocol number, the RSVP signalling messages are processed faster in the routers. This enables certain transport quality. 6.2. Analysis based on open issues in [Brun02] This section describes the analysis of the RSVP aggregation protocol described in [RFC3175] using the open issues in [Brun02]. The number in brackets is the number of the open issue used in [Brun02], where the issue is described. For the description of these de Meer, et al. Expires November 2002 [Page 45] Internet Draft Analysis of Existing QoS Solutions May 2002 open issues, refer to [Brun02]. [2] - Open issue 2: Sender/receiver initiation, Sender initiated a MUST, receiver initiated a MAY: The RSVP aggregation protocol is a receiver-initiated protocol, thus it does not support this requirement. [8] - Open issue 8: Bi-directional data path setup with one QoS request: RSVP aggregation protocol does not support bi-directional data path setup with a single QoS request. It may support bi- directional request only as a combination of two single uni- directional requests. [33] - Open issue 33: Highest possible network utilization: The RSVP aggregation protocol provides high network utilization up to the point where the scalability of the network is not affected. [36] - Open issue 36: Independence of reservation identifier: The RSVP aggregation protocol does not support this requirement (see above). [53] - Open issue 53: this open issue is a requirement described in Section 5.1.16 of [PaKa02] - Error handling and redundancy considerations: The RSVP aggregation protocol supports this requirement by means of the error signalling messages. [55] - Open issue 55: this open issue is a requirement described in Section 5.2.2. of [PaKa02] - Allow local QoS information exchange between two border nodes: The RSVP aggregation protocol supports this requirement, since local QoS information can be exchanged between the aggregator and deaggregator. [59] - Open issue 59: this open issue is a requirement described in Section 5.3.4. of [PaKa02] - "Ability to deal with severe congestion": de Meer, et al. Expires November 2002 [Page 46] Internet Draft Analysis of Existing QoS Solutions May 2002 The RSVP aggregation protocol supports this requirement. [60] - Open issue 60: this open issue is a requirement described in Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment after handover": The RSVP aggregation protocol does not support mobility. As such it does not allow efficient QoS re-establishment after handover as in these cases it needs to re-initiate a new signalling session. 6.3. Analysis based on requirements in [PaKa02] This section describes the analysis of the aggregated RSVP protocol described in [RFC3175] using the requirements in [PaKa02]. The number enclosed between the brackets is the section number in [PaKa02] where the requirement is described. For the complete description of these requirements, refer to [PaKa02]. [5.2.3] - Allow generation of local QoS signalling messages: The RSVP aggregation protocol can support aggregated RSVP messages that can be seen as local QoS messages. [5.3.1.1] - Modular: RSVP aggregation [RFC3175] can aggregate multiple end to end micro-flows but this aggregation is not accomplished in a modular way. [5.3.1.2] - Simple: The RSVP aggregation protocol, like RSVP, is very flexible and can be applicable in many different scenarios. This increases its complexity. [5.3.1.3] - Minimal Impact on Performance: Due to its complexity the RSVP aggregation protocol impacts the performance of the interior nodes. [5.3.2] - Ability to deal with mobility (handover): The RSVP aggregation protocol cannot support efficiently this de Meer, et al. Expires November 2002 [Page 47] Internet Draft Analysis of Existing QoS Solutions May 2002 requirement. [5.3.3] - On-demand, dynamic signalling for efficient network utilization: The RSVP aggregation protocol provides on-demand and dynamic signalling. [5.3.4] - Ability to deal with severe congestion: The RSVP aggregation protocol, like RSVP, is able to support severe congestion solutions. [5.3.5] - Optimize for unicast transport: The RSVP aggregation protocol is not optimized for unicast reservations. [5.3.6] - Ability to transparently traverse an interior node: This requirement cannot be supported by the RSVP aggregation protocol. [5.3.7] - Use of a simple QoS parameter: RSVP aggregation uses more than one QoS parameters (TSPEC, RSPEC, ADSPEC). 7. Conclusions This draft provides a brief analysis of existing IP QoS solutions and accompanying signalling issues. This analysis is done in order to understand whether the strict QoS requirements imposed by future fixed and mobile applications on networks are satisfied by the existing IP QoS solutions. RSVP [RFC2205] includes much more functionality and complexity than is required in some IP networks. The QoS problem in such networks is significantly simpler to solve (see [WQOSREQ]). The tradeoff between performance and functionality is one of the key issues in such networks, and the majority of the functionality in RSVP is not required. This is true for five reasons: de Meer, et al. Expires November 2002 [Page 48] Internet Draft Analysis of Existing QoS Solutions May 2002 * Most of the QoS sensitive applications do not use the multicast capabilities of RSVP. Supporting only unicast and one-to-many multicast reservations is a reasonable tradeoff, since they are considerably simpler than many-to-many multicast reservations. Note that even for the one-to-many multicast reservations capability, it should be ensured that this type of reservation will not outweigh the requirement for simplicity and scalability. Without the many-to-many reservation support, protocols do not necessarily have to be receiver-oriented. In this case, there is no need for the PATH messages. This reduces the number of states in the routers. Furthermore, no reverse direction (backward) routing is required. Such protocols perform one pass only during the setup instead of the two passes and therefore speed up the reservation initiation. Additionally, the initiation of bi-directional reservations in combination with many-to-many reservations is very complex. * Edge-to-edge with one operator does not require policy handling in the interior routers. * Path characteristics and flexible traffic parameters and QoS definitions could be solved by network dimensioning and edge functionality. * The huge number of per-microflow states in intermediate routers might cause severe scalability problems. * Initiation or re-scheduling of signalling messages might load intermediate interior routers severely. There are different reservation protocol approaches, where it is sufficient that edge routers and/or signalling end-points initiate or re-schedule all the signalling messages. In this case, the intermediate interior routers only forward the messages and use a dedicated field of the message to signal to other routers. This approach lightens the load on the intermediate interior routers. The DiffServ architecture [RFC2475] does not specify a full QoS signalling protocol. It specifies a framework with an implicit QoS signalling mechanism, which requires out of band Per Hop Behavior set up. de Meer, et al. Expires November 2002 [Page 49] Internet Draft Analysis of Existing QoS Solutions May 2002 The IntServ over DiffServ architecture [RFC2998] allows at least two different possible deployment strategies. The first is based on statically allocated resources in the DiffServ domain. A main disadvantage of this approach is that the edge nodes in the customer network will not be aware of the traffic load in the nodes located within the DiffServ domain. The second possible strategy is based on dynamically allocated resources in the DiffServ domain. According to [RFC2998], this can be done using RSVP-aware DiffServ routers. However, this approach has most of the drawbacks of RSVP, and per- microflow state information is kept in the intermediate routers. With regards to aggregated RSVP [RFC3175], even if the reservation is based on aggregated traffic, the number of re-negotiations of the allocated resources due to mobility (handover) does not decrease and each re-negotiation of resources has the same performance requirements as the per-flow reservation procedure. Note that the aggregated RSVP solution may use a policy to maintain the amount of bandwidth required on a given aggregate reservation by taking account of the sum of the underlying end-to-end reservations, while endeavoring to change it infrequently. However, such solutions (policies) are very useful assuming that the cost of the overprovisioned bandwidth is not significant, since this implies the need for a certain "slop factor" in bandwidth needs. In certain networks, where overprovisioning is not practical due to high costs of transmission links, a more dynamic QoS provisioning solution is needed. Furthermore, the aggregated RSVP scheme is receiver initiated and cannot support bi-directional reservations. In the aggregated RSVP scheme the resource reservation states stored in all the RSVP-aware edge and interior nodes represent aggregated RSVP sessions or trunks of RSVP sessions. Therefore, the number of the resource reservation states in the aggregated RSVP scheme compared to the (per-flow) RSVP scheme is decreased. However, in a DiffServ-based domain the number of the aggregated RSVP sessions depends on: * The number of Aggregators/Deaggregators: this depends on the number of the edge nodes used. For example, in an IP-based wireless network, the number of the edge nodes can depend on the the number of based stations and controlling gateways. In cellular networks, the number of controlling gateways is high, and the number of base stations is in the range of de Meer, et al. Expires November 2002 [Page 50] Internet Draft Analysis of Existing QoS Solutions May 2002 thousands (see [PaKa01]). * The network topology used: when the communication is performed in a meshed way (that is, all-to-all), it will imply that many communication paths will have to be maintained by the network simultaneously. * The number of DiffServ Code Points (DSCPs) used: more than one traffic class will be supported within a network. Therefore, the number of the aggregated RSVP reservation states within such a network will be significant. This analysis points out pending and open QoS signalling issues in the existing QoS solutions. Given these results, we believe that appropriate standardization should take place to create the necessary protocols for QoS signalling. 8. References [BiaBle] G. Bianchi, N. Blefari_Melazzi, "A Migration Path to provide End-to-End QoS over Stateless Networks by Means of a Probing-driven Admission Control", Internet Draft, work in progress, draft-bianchi-blefari-end-to-end-QoS-xx.txt, 2001. [Brun02] Brunner, M., "Requirements for QoS Signaling Protocols" Internet Draft, work in progress, draft-ietf-nsis-req-01.txt, 2002. [CSZ92] Clark, D.D., Shenker, S., Zhang, L, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism", Proc. ACM SIGCOMM'92, August 1992. [DO01] De Meer, H., O'Hanlon, P, ''Segmented Adaptation of Traffic Aggregates'', 9th Int'l Workshop on Quality of Service, IWQoS'01, Karlsruhe, 2001. [PaKa01] Partain, D., Karagiannis, G., Wallentin, P., Westberg, L., "Resource Reservation Issues in Cellular Radio Access Networks", Internet Draft, work in progress, draft-westberg-rmd-cellular-issues-xx.txt, 2001. de Meer, et al. Expires November 2002 [Page 51] Internet Draft Analysis of Existing QoS Solutions May 2002 [PaKa02] Partain, D., Bergsten, A., Greis, M., Karagiannis, G., Manner, J., Murphy, J., Pan, P., Rexhepi, V., Westberg, L., Zheng, H., "NSIS QoS Signalling Requirements", Internet Draft, work in progress, draft-partain-nsis-requirements-xx.txt, 2002. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", IETF RFC 2205, 1997. [RFC2210] Wroclawski, J., "The use of RSVP with IETF integrated Services", IETF RFC 2210, 1997. [WQOSREQ] Westberg, L., Karagiannis, G., Partain, D., "QoS Signalling Requirements for Wireless Networks", Internet Draft, work in progress, draft-westberg-nsis-wireless-requirements-xx.txt, 2001. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", IETF RFC 2475, December 1998. [RFC2476] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC2990] G. Huston, "Next Steps for the IP QoS Architecture", RFC2990, November 2000. [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and Felstaine, E., "A Framework for Integrated Services Operation Over DiffServ Networks", RFC 2998, November 2000. de Meer, et al. Expires November 2002 [Page 52] Internet Draft Analysis of Existing QoS Solutions May 2002 [RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", IETF RFC 3175, 2001. [RMD] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G., Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource Management in Diffserv Framework", Internet draft, work in progress, draft-westberg-rmd-framework-xx.txt, 2001. [WROCHA] Wroclawski,J., Charny, A.,: "Integrated Service Mappings for Differentiated Services Networks", Internet Draft, work in progress, draft-ietf-issll-ds-map-01.txt, 2001. 9. Acknowledgments Thanks to Istvan Cselenyi, Pontus Wallentin, Geert Heijenk and Giussepe Bianchi for reviewing this draft and providing useful input. 10. Editors' Addresses Hermann De Meer Department of Electronic & Electrical Engineering University College London Torrington Place London WC1E 7JE Great Britain EMail: H.DeMeer@ee.ucl.ac.uk Piers O'Hanlon Department of Electronic & Electrical Engineering University College London Torrington Place London WC1E 7JE Great Britain EMail: P.OHanlon@cs.ucl.ac.uk Gabor Feher Budapest University of Technology and Economics Department of Telecommunications and Telematics Magyar tudosok korutja 2.; H-1117 Budapest; Hungary Phone: +36 1 463 2187 de Meer, et al. Expires November 2002 [Page 53] Internet Draft Analysis of Existing QoS Solutions May 2002 EMail: feher@ttt-atm.ttt.bme.hu Nicola Blefari-Melazzi DIEI, University of Perugia Via G. Duranti 93, 06125 Perugia, ITALY Tel: +39 075 585 3630 EMail: blefari@diei.unipg.it Georgios Karagiannis Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Georgios.Karagiannis@eln.ericsson.se David Partain Ericsson Radio Systems AB P.O. Box 1248 SE-581 12 Linkoping Sweden EMail: David.Partain@ericsson.com Vlora Rexhepi Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Vlora.Rexhepi@eln.ericsson.se Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@era.ericsson.se de Meer, et al. Expires November 2002 [Page 54]