Internet Draft Analysis of Existing QoS Solutions November 2001 Internet Engineering Task Force H. de Meer INTERNET-DRAFT University College London, UK Expires May 2002 G. Feher University of Budapest, Hungary N. Blefari-Melazzi University of Perugia, Italy G. Karagiannis D. Partain L. Westberg Ericsson November 2001 Analysis of Existing QoS Solutions draft-demeer-nsis-analysis-00.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. Copyright Notice de Meer, et al. Expires May 2002 [Page 1] Internet Draft Analysis of Existing QoS Solutions November 2001 Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo gives 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 on networks 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 protocol * Integrated Services over Differentiated Services * Statically assigned trunk reservations based on Differentiated Services * Dynamic trunk reservations with Aggregated RSVP 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 de Meer, et al. Expires May 2002 [Page 2] Internet Draft Analysis of Existing QoS Solutions November 2001 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 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 de Meer, et al. Expires May 2002 [Page 3] Internet Draft Analysis of Existing QoS Solutions November 2001 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. 2. 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 [RFC2210], [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 de Meer, et al. Expires May 2002 [Page 4] Internet Draft Analysis of Existing QoS Solutions November 2001 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. The RSVP protocol uses additional messages either to provide information about the QoS state 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 An overview of the RSVP functionality includes: * End-to-end reservation with aggregation of path characteristics such as fixed delay. * The same type of reservation functionality in all routers. Only policy handling separates the edge of the domain from other routers. * Multicast and unicast reservations with receiver initiated reservations. RSVP makes reservations for both unicast and many-to-many multicast applications, adapting dynamically to changing routes as well as to group membership. * Shared reservations for multiple flows. * Support for policy handling to handle multi-operator situations since more than one operator will be responsible for RSVP's operation. * Flexible object definitions. RSVP can transport and maintain traffic and policy control parameters that are opaque to RSVP. Each RSVP message may contain up to fourteen classes of attribute objects. Furthermore, each class of RSVP objects de Meer, et al. Expires May 2002 [Page 5] Internet Draft Analysis of Existing QoS Solutions November 2001 may contain multiple types to specify further the format of the encapsulated data. Moreover, the signalling load generated by RSVP on the routers is directly proportional to the flows processed simultaneously by these routers. Furthermore, processing of the individual flows in the networking infrastructure may impose a significant processing burden on the machines, thus hurting throughput. These issues make it reasonable to question the scalability and performance in a large network that supports a huge number of users. * Support for uni-directional reservations, but not bi-directional. (In some wireless subnetworks, the initiation of the reservations is done on a bi-directional basis.) * Re-scheduling of signaling message in every router. The re-scheduling of session refresh messages (aggregated and non aggregated ones) depend on the router's own refresh period timer. This means, for example, that when a session refresh message arrives at a router at the beginning of a refresh period it might have to be re-scheduled for re-sending to the next hop at the end of the refresh period. * Signalling initiation of RSVP error indication messages: Any time that an erroneous situation occurs a router initiates an RSVP error message. In case of wireless networks, when a mobile host moves or the connection moves from one base station to another, it could force the communication path to change its (source/destination) IP address. The change of IP address will require that RSVP establish a new RSVP session through the new path that interconnects the two end points involved in the RSVP session and release the RSVP session on the old path. During this time, the end-to-end data path connection is incomplete (i.e., QoS disruption), and it will negatively affect the user performance. RSVP 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 May 2002 [Page 6] Internet Draft Analysis of Existing QoS Solutions November 2001 * 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 signaling 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. 3. 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 de Meer, et al. Expires May 2002 [Page 7] Internet Draft Analysis of Existing QoS Solutions November 2001 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 (see Section 4). 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 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 de Meer, et al. Expires May 2002 [Page 8] Internet Draft Analysis of Existing QoS Solutions November 2001 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 drawbacks described in Section 2, 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 allocated using Aggregated RSVP. This will be discussed in Section 5. Other approaches related to the bandwidth broker concept are still very immature and will not be discussed here. 4. Statically-assigned trunk reservations based on Differentiated Services 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 particular, and focusing on DiffServ [RFC2475], an important open point is that such an architecture lacks a standardized admission control scheme, and does not intrinsically solve the problem of controlling congestion in the Internet. As previously explained in Section 3, the edge nodes in the customer network will not be aware de Meer, et al. Expires May 2002 [Page 9] Internet Draft Analysis of Existing QoS Solutions November 2001 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]. Upon overload in a given service class, all flows in that class suffer a potentially harsh degradation of service. "A Framework for Integrated Services Operation over Diffserv Networks" [RFC2998] recognizes this problem and points out that "further refinement of the QoS architecture is required to integrate DiffServ network services into an end-to-end service delivery model with the associated task of resource reservation". It is thus suggested [RFC2990] to define an "admission control function which can determine whether to admit a service differentiated flow along the nominated network path". In the following we expand on this issue, in the framework of the typical hybrid reference network shown in Figure 1, which includes a DiffServ region in the middle of a larger network supporting IntServ end-to-end. Notice that some of the following considerations also apply to an all DiffServ network. In Figure 1, the source host Tx, the destination host Rx, the Edge Routers (ER) and the Border Routers (BR) execute the functions listed in [RFC2998]. In particular, we assume that both sending and receiving hosts use RSVP to communicate the quantitative QoS requirements of QoS-aware applications running on the hosts. Obviously, admission control in the IntServ subnetworks is signalled using RSVP. ________ ______________ ________ / \ / \ / \ / \ / \ / \ |---| | |---| |---| |---| |---| | |---| |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | |---| | |-- | |---| |---| |---| | |---| \ / \ / \ / \________/ \______________/ \________/ IntServ region DiffServ region IntServ region Figure 1: Sample Network Configuration Requests for IntServ services must be mapped onto the underlying capabilities of the DiffServ network region. Aspects of such mapping include [RFC2998]: 1. selecting an appropriate PHB, or a set of PHBs, for the de Meer, et al. Expires May 2002 [Page 10] Internet Draft Analysis of Existing QoS Solutions November 2001 requested service 2. performing appropriate policing (perhaps including shaping or remarking) at the edges of the DiffServ region 3. exporting IntServ parameters from the DiffServ region (e.g., for the updating of ADSPECs) 4. performing admission control on the IntServ requests that takes into account the resource availability in the DiffServ region. 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]. To this end, point 4 above, i.e., the admission control function is key. In fact, QoS aware services require that the amount of arriving traffic be limited by suitable admission control. Two issues are of interest [WROCHA]: * the method used by the DiffServ cloud to determine whether sufficient resources are available * the method used by the overall network to query the DiffServ cloud about this availability Within the cloud, the admission control "mechanism" is closely related to resource provisioning. If some form of static resource provisioning is used, the admission control function can be performed by any network component that is aware of this allocation, such as a properly configured boundary router. If resource allocation within the network cloud is dynamic (e.g., a dynamic "bandwidth broker" or signalling protocol) then this protocol can also perform the admission control function by refusing to admit new traffic when it determines that it cannot allocate appropriate new resources. The key to providing absolute, quantitative QoS services within a de Meer, et al. Expires May 2002 [Page 11] Internet Draft Analysis of Existing QoS Solutions November 2001 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 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. In reality, all four options may be useful in different circumstances. In any case, there need to be entities that are able to allow or refuse service requests, possibly on the basis of resource utilization. In other words, we also need an admission control function acting on the DiffServ cloud. We can proceed along two different routes: * Define an admission control function that is also able to operate WITHIN the DiffServ cloud. This could solve our problem even in the case of isolated or all DiffServ networks (that is, not part of an end-to-end RSVP loop). * Export suitable characteristics of the Diffserv cloud toward the IntServ part so that admission control can be performed by the latter (that is, by RSVP). In considering the second of these possibilities, in order to do this de Meer, et al. Expires May 2002 [Page 12] Internet Draft Analysis of Existing QoS Solutions November 2001 to provide Guaranteed Service, it would be necessary to export the "error terms", referred to as C and D in the specification, which would allow the customer to calculate the bandwidth to request from the network in order to achieve a particular queuing delay target. The difficulty in characterizing the parameters C and D is that, unlike the IntServ model, where the C and D terms are a local property of the router, in the case of DiffServ these terms depend not only on the topology of the cloud, but also on the internal traffic characteristics of potentially all traffic in the cloud handled with the PHB chosen to support the Guaranteed Service. 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 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]) 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]. In conclusion, providing QoS aware service over a DiffServ cloud without admission control functions able to operate within the cloud itself potentially leads to severe inefficiencies. In fact, the "worst case" provisioning model targeting a particular utilization bound results in substantially more overprovisioning than the "point- to-point" provisioning using an estimated traffic matrix, which in turn is potentially more inefficient than explicit point-to point bandwidth allocation using signalled admission control. de Meer, et al. Expires May 2002 [Page 13] Internet Draft Analysis of Existing QoS Solutions November 2001 This brings us to option 1 above, the definition of an admission control function within the DiffServ region. To this end, we cannot use explicit per flow signalling, for obvious reasons (this would lead to a stateful architecture). Similarly, we do not want to modify the basic router operation by introducing packet marking schemes or forcing routers to parse and interpret higher layer information. What we would like to do is to implicitly convey the status of inner DiffServ routers to the edges of the cloud (or to the end points, when the DiffServ net is an isolated one), by means of scalable, DiffServ compliant procedures, so that suitable devices can make appropriate admission control decisions without violating the DiffServ paradigm. A possible way to do this has been proposed in [RMD] and [BiaBle]. 5. 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 May 2002 [Page 14] Internet Draft Analysis of Existing QoS Solutions November 2001 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]. With regards to aggregated RSVP, 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 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. de Meer, et al. Expires May 2002 [Page 15] Internet Draft Analysis of Existing QoS Solutions November 2001 * 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. 6. Conclusions This draft gives 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. 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. 7. 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. [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. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., de Meer, et al. Expires May 2002 [Page 16] Internet Draft Analysis of Existing QoS Solutions November 2001 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. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", IETF RFC 2475, December 1998. [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. [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. de Meer, et al. Expires May 2002 [Page 17] Internet Draft Analysis of Existing QoS Solutions November 2001 8. Acknowledgments Thanks to Vlora Rexhepi, Istvan Cselenyi, Pontus Wallentin, Geert Heijenk and Giussepe Bianchi for reviewing this draft and providing useful input. 9. 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 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 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 de Meer, et al. Expires May 2002 [Page 18] Internet Draft Analysis of Existing QoS Solutions November 2001 Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@era.ericsson.se Table of Contents 1 Introduction .................................................... 2 2 End-to-end per-flow resource reservation protocol ............... 4 3 Integrated Services over Differentiated Services ................ 7 4 Statically-assigned trunk reservations based on Differentiated Services ..................................................... 9 5 Dynamic trunk reservations with Aggregated RSVP ................. 14 6 Conclusions ..................................................... 16 7 References ...................................................... 16 8 Acknowledgments ................................................. 18 9 Editors' Addresses .............................................. 18 de Meer, et al. Expires May 2002 [Page 19]