Internet Draft Analysis of Existing QoS Solutions November 2002 Internet Engineering Task Force H. de Meer INTERNET-DRAFT Piers O'Hanlon Expires May 2003 University College London, UK G. Feher University of Budapest, Hungary N. Blefari-Melazzi University of Perugia, Italy H. Tschofenig Siemens, AG G. Karagiannis D. Partain V. Rexhepi L. Westberg Ericsson November 2002 Analysis of Existing QoS Solutions draft-demeer-nsis-analysis-03.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. de Meer, et al. Expires May 2003 [Page 1] Internet Draft Analysis of Existing QoS Solutions November 2002 Distribution of this memo is unlimited. 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 * Traffic Engineering Tunnels and RSVP de Meer, et al. Expires May 2003 [Page 2] Internet Draft Analysis of Existing QoS Solutions November 2002 Table of Contents 1 Introduction ................................................. 4 2 Issues Used in the Analysis .................................. 6 3 End-to-end per-flow resource reservation protocol ............ 6 4 Integrated Services over Differentiated Services ............. 9 5 Statically-assigned trunk reservations based on DiffServ ..... 14 6 Dynamic trunk reservations with Aggregated RSVP .............. 17 7 Traffic Engineering Tunnels and RSVP ......................... 20 8 Conclusions .................................................. 22 9 References ................................................... 25 10 Acknowledgments ............................................. 28 11 Editors' Addresses .......................................... 28 de Meer, et al. Expires May 2003 [Page 3] Internet Draft Analysis of Existing QoS Solutions November 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. In the practical sense such a QoS architecture may also provide means for accounting and charging and therefore placing incentives on limiting resource reservation requests. "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 de Meer, et al. Expires May 2003 [Page 4] Internet Draft Analysis of Existing QoS Solutions November 2002 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 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 de Meer, et al. Expires May 2003 [Page 5] Internet Draft Analysis of Existing QoS Solutions November 2002 reservation. 2. Issues Used in the Analysis The main goal of this analysis is to bring the observations on the main existing QoS solutions related to reservation state management, scalability, support for mobility and security issues in order to point out the differences and open issues. The existing IP QoS solutions explained in this draft will be analysed in terms of: * Reservation State Depending on the set-up, maintenance and release a reservation state can be: - hard state where the resources are released by means of explicit release - soft state that needs to be refreshed in certain periods in time, otherwise it will be released. Soft state can also be released by means of explicit release messages. * Scalability Scalability can be defined as the ability to increase the number of reservation states in a network entity, while maintaining the required network performance. However, scalability is not only related to the number of the reservation states, but also to the number of messages that need to be processed, number of hand-offs in case of mobility, CPU utilization, etc. * Support for Mobility * Security Issues 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 data path, and it can be used by an application to signal its QoS requirements to nodes (participating in the signaling) along the path. This type of protocol is typically initiated per flow by an application at the beginning of a communication session. A flow (in RSVP) is typically identified by the combination of the source and destination IP address, transport layer protocol, and source/destination port number. Other flow de Meer, et al. Expires May 2003 [Page 6] Internet Draft Analysis of Existing QoS Solutions November 2002 identifications are also possible as for example IPSec (when used end-to-end between the two communicating end-points) then some of the previously mentioned header information is not available to interior nodes. Hence the flow identification is limited IP addresses and the available SPI as described in [RFC2207]. The resources reserved per flow by such a protocol for a certain communication session will be used for all packets belonging to that particular flow. 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 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 Reservation State ----------------- RSVP reservation state is per-flow soft state. This per-flow reservation state is identified by means of the flow identifier, which is a combination of the source and destination IP address, transport layer protocol, and source/destination port number. de Meer, et al. Expires May 2003 [Page 7] Internet Draft Analysis of Existing QoS Solutions November 2002 The reservation state management is a combination of the soft state principle and explicit release. As explained above the reserved resources will be released if not refreshed in a certain period of time. The explicit release of resources in RSVP[RFC2205]is done by means of RESV TEARDOWN and PATH TEARDOWN message that can only be sent by the receiver end-host or sender-end host respectively. In RSVP, the success of resource request is reported by a successful admission control function. The amount of initially reserved resources can be modified during the duration of RSVP session by means of RSVP refresh messages and the modify function in traffic admission control. Scalability ----------- In the research community it is a well known fact that RSVP [RFC2205] does not scale well in large networks due to per-flow reservation state management. Due to this 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 (see also [ChNe98]). In terms of number of messages that need to be processed, in RSVP there are seven types of messages defined 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 host 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. In terms of CPU utilization at the 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. Add ref. Support for Mobility -------------------- de Meer, et al. Expires May 2003 [Page 8] Internet Draft Analysis of Existing QoS Solutions November 2002 RSVP does not support mobility and as such it is not designed to support handovers. In a handover event a new signaling session needs to be re-initiated. Issues related to the Mobile IP and RSVP are explained in detail in [To01], [Pa01]. Security Issues --------------- [RFC2747] provides authentication, integrity and replay protection of the entire RSVP message in a hop-by-hop fashion by using the INTEGRITY object for RSVP. Based on the principle of chain-of-trust the signaling messages are protected hop-by-hop from one signaling endpoint to the other. The Policy Object may additionally contain an INTEGRITY object which provides protection of the object inside this object between two policy aware nodes. The functionality and the structure of the POLICY_DATA element a re described in [RFC2205]. Additionally the POLICY_DATA object allows user authentication (by including various types of credentials in the AUTH_DATA attribute). Replay protection in RSVP is done with the help of the 64-bit sequence number field included in the INTEGRITY object. Sequence number resynchronization in case of a crashed or rebooted host is done with the Integrity Handshake mechanism. The starting sequence number is set with the establishment of the security association. RSVP assumes that most security associations are already available before the protocol execute. This seems to be feasible within the internal network. Authentication of a user either to first-hop router or the Policy Decision Point (PDP) is very likely based on Kerberos. This allows Kerberos service tickets to be used to establish a session key between the two communicating parties. A detailed description of the RSVP security properties can be found at [Ts02]. For more analysis on RSVP security issues see [Ha02]. 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 de Meer, et al. Expires May 2003 [Page 9] Internet Draft Analysis of Existing QoS Solutions November 2002 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 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 de Meer, et al. Expires May 2003 [Page 10] Internet Draft Analysis of Existing QoS Solutions November 2002 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 allocated using Aggregated RSVP. Other approaches related to the bandwidth broker concept are still very immature and will not be discussed here. 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. IntServ and DiffServ can almost orthogonally combined with each other in either mode as discussed here. Reservation State ----------------- The IntServ model is based on soft state and time out of reservations. Explicit release of resources is possible as well. The Diffserv reservation state depends on whether the resources are assigned statically or dynamically. In case of static resource allocation there will be no need for resource reservation mechanisms, while in case of dynamic resource allocation the reservation state depends on the dynamic resource reservation protocol used. Thus the reservation state may be managed in a soft state manner as is the case of RSVP or it may be hard state as well. In IntServ domains reservation states can be dynamically changed. But it is not certain what happens if an increase de Meer, et al. Expires May 2003 [Page 11] Internet Draft Analysis of Existing QoS Solutions November 2002 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. 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. Scalability ----------- In [RFC2998] DiffServ network elements are introduced to improve scalability in core networks. This is true if Diffserv is statically provisioned. But in case of dynamic provisioning, signalling and provisioning overhead may reduce scalability again. Especially, scalability may be affected in case per-flow traffic classification and marking is performed at the core routers. Support for Mobility -------------------- Intserv does not support mobility and as such it is not designed to support handovers. In a handover event a new signalling session needs to be initiated. Same as Intserv, Diffserv was not designed for mobility support. While for the dynamic provisioned Diffserv some support can still be provided, with static Diffserv mobility is not at all possible unless some overprovisioning of resources is used. de Meer, et al. Expires May 2003 [Page 12] Internet Draft Analysis of Existing QoS Solutions November 2002 Security Issues --------------- It has often been mentioned that security protection has implications are important for signaling messages itself and for the subsequent data messages. The subsequent paragraphs elaborate summarize these i ssues briefly. - Protection of Data Messages In the context of packet marking with DSCPs there is a danger for a network to receive packets which are improperly marked without the required authentication and authorization. This is particularly true if the task of packet marking is delegated to an untrusted end-host. Section 7.2 of [RFC2998] discusses security considerations for host marking. Possible threats are resource theft and denial of service attacks. One concern, which is often mentioned, is that the DSCP is a mutable field and not protect protected by IPSec AH i.e. the DSCP in the outer packet header is not protected by AH (and no the entire outer packet header is unprotected in case of IPSec ESP). In case of tunnel mode the marking in the inner header is protected. It however heavily depends on the type of processing applied when encapsulating and decapsulating the packet. Issues related to DiffServ and Tunnels (including IPSec protected data traffic) are described in [RFC2983]. Special care must be taken at the edges of a network where the incoming data traffic is subject to admission control and accounting. It must be insured that end-hosts are not able to inject data traffic into the internal network without proper verification. - Protection of Signaling Messages If RSVP is used to assist nodes with their DSCP marking by distributing the code points to end-hosts or to edge devices as described in [RFC299] then RSVP's security protection with data origin authentication, integrity and replay protection as provided with the INTEGRITY object is used. Where RSVP signaling starts and ends has trust and therefore key management implications. However this issue heavily depends on a particular architecture. de Meer, et al. Expires May 2003 [Page 13] Internet Draft Analysis of Existing QoS Solutions November 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, the resource management is likely to be quite difficult. This is due to 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 as it will be difficult to configure the trunked reservations statically and at the same time utilize the network efficiently. In order to achieve this signaling would be required. 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 de Meer, et al. Expires May 2003 [Page 14] Internet Draft Analysis of Existing QoS Solutions November 2002 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. 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 May 2003 [Page 15] Internet Draft Analysis of Existing QoS Solutions November 2002 Reservation State ----------------- With DiffServ, the QoS is signalled in the DS field of the data packets. RFC2475 does not explicitly reserve resources, thus it consequently does not explicitly release resources. There is no specification of feedback mechanisms regarding success of QoS requests in RFC2475. However, local QoS edge devices may provide feedback at a higher level. 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. 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. Scalability ----------- 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. 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. Support for Mobility -------------------- Diffserv does not have any support for mobility. In case of statically assigned trunk reservations support for mobility is a difficult network management problem. Due to handover requirements 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. de Meer, et al. Expires May 2003 [Page 16] Internet Draft Analysis of Existing QoS Solutions November 2002 Security Issues --------------- Regarding the security of DiffServ marking the same considerations apply as described in Section 3 security issues. In case that no end-user hosts are involved and DiffServ domains are located in the core of the network stronger trust assumptions prevent some of the problems described. Since the scenario described in this Section is lacking a signaling protocol and only statically provisioned networks are used other security considerations are not applicable (especially those with regard to signaling). 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 May 2003 [Page 17] Internet Draft Analysis of Existing QoS Solutions November 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]. Reservation State ----------------- RSVP Aggregation reservation state is per-aggregate-flow soft state. The reservation state management is a combination of the soft state principle and explicit release. As explained above the reserved resources will be released if not refreshed in a certain period of time. The explicit release of resources is done by means of explicit release messages that are send by the Aggregator/ DeAggregator respectively. The amount of initially reserved resources can be modified during the duration of RSVP session by means of RSVP aggregation refresh messages and the modify function in traffic admission control. Scalability ----------- 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. The reservation setup by means of RSVP aggregation requires certain interactions. These interactions are linearly proportional to the number of the supported aggregated flows. 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]). de Meer, et al. Expires May 2003 [Page 18] Internet Draft Analysis of Existing QoS Solutions November 2002 * 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. 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 this is accomplished on a per aggregate basis. Support for Mobility -------------------- RSVP Aggregation does not support mobility and as such it is not designed to support handovers. When applied in mobile networks, in a handover event a new signaling session needs to be re-initiated. Security Issues --------------- RSVP Aggregation as described in [RFC3175] uses signaling between two endpoints (typically between the edges of a network) other than the typical end-to-end host endpoints. Hence there is very little need to address user authentication (or also application identity representation) with the help of the POLICY_DATA object. Security protection of signaling messages is therefore heavily based on the INTEGRITY object which is applied in a hop-by-hop mode. de Meer, et al. Expires May 2003 [Page 19] Internet Draft Analysis of Existing QoS Solutions November 2002 7. Traffic Engineering Tunnels and RSVP Traffic engineering function enables efficient and reliable network operations as well as optimal utilization of expensive network resources in large networks. Multiprotocol Label Switching (MPLS) [RFC 2702] is an advanced packet forwarding mechanism used for traffic engineering. MPLS assign labels to packets that determine the forwarding of the packets, differently from the Layer 3 forwading which is based on routing tables. This packet forwarding will create topology driven paths through the network as each MPLS-capable router, called also Label Switching Router (LSR), forwards the packets that it receives based on the label. In this way the Label Switched Paths (LSP) are set between ingress/egress pairs of MPLS- capable routers. Several flows can be forwarded along the same LSP, provided that they are assigned the same label at the ingress node of the LSP. Due to this feature the LSP may be treated as tunnels [RFC3209]. RSVP-TE [RFC3209] describes the RSVP extensions needed for establishing LSPs tunnels in MPLS. The LSP tunnels enable a variety of network optimization policies as they can be routed explicitly in order to avoid congestion, bottlenecks and network failures. There can be several LSP tunnels set by means of RSVP-TE between two endpoints. All the packets, regardless of the traffic flow they belong to, which are assigned the same label as the LSP by a particular ingress node will be routed through this tunnel. The packets with the same label value belong to the same forwarding equivalence class (FEC) [RFC2702]. The extensions to RSVP are five new objects (LABEL_REQUEST (Path), LABEL (Resv), EXPLICIT_ROUTE (Path), RECORD_ROUTE (Path,Resv), SESSION_ATTRIBUTE (Path))added to PATH and RESV messages respectively. Although RSVP-TE protocol is to be used mainly in traffic engineering it can be also used in any application using aggregation based on labels. Reservation State ----------------- The RSVP-TE Reservation state is a per LSP tunnel state. As in RSVP, the reservation state management is a combination of the soft state principle and explicit release. Note that the RSVP-TE can be used to setup LSP tunnels without allocating any resources, that is without resource reservations. de Meer, et al. Expires May 2003 [Page 20] Internet Draft Analysis of Existing QoS Solutions November 2002 The LSP tunnels and the resource reservation are maintained by means of refresh messages sent by the endpoints of the LSP tunnel. The explicit release of LSP tunnels and resource reservations respectively is done by means of explicit release messages that are send by the endpoints. Scalability ----------- The number of the RSVP-TE messages is linearly proportional to the number of the supported LSP tunnels. Note that the number of supported LSP tunnels is much less than the number of micro-flows. RSVP-TE installs and maintains one state per label, i.e. per LSP tunnel. The packet flow classification and filtering will be done based on this label only, which is much more simple and scalable than the RSVP itself. However this requires a mechanism based on label switching such as MPLS. Support for Mobility -------------------- RSVP-TE does not support mobility and as such it is not designed to support handovers. When RSVP-TE is used in the core network then mobility is usually not a problem. However using RSVP-TE in the access network effects roaming mobile nodes that may require new labels and the re-mapping into other LSP tunnels. Security Issues --------------- If RSVP-TE is used to distribute MPLS labels within a single administrative domain then security protection as described in [RFC2747] can be used. However, [RFC2747] requires that key mangement is done offline. Within a single administrative domain this might be reasonable approach. It is furthermore assumed that each node knows its next MPLS node along the path either due to pre-configuration or because of supplied route object. The protection offered by [RFC2747] offers data origin authentication, integrity and reply protection. Confidentiality protection and other security properties such as (identity confidentiality, etc.) is not provided but might not required in this context. If the signaling exchange is limited to a single administrative domain then the concept of network topology hiding is also not applicable. Handling of de Meer, et al. Expires May 2003 [Page 21] Internet Draft Analysis of Existing QoS Solutions November 2002 policies as described in [RFC3182] does not seem to be used. Authorization, which is typically an important step in RSVP when used for QoS, does not seem to play an important role if RSVP-TE is only used for label distribution. If the label distribution is not limited to a single administrative domain then additional security mechanisms require considerations. In such a case it must not be possible for an unauthorization entity to add, modify or remove LPS. A full range of attacks would be possible without proper protection. To allow secure data communication between different MPLS domains over IP domains IPSec protection of MPLS data packets might be used as described in [RoCl02]. An interesting approach for applying IPSec protection to MPLS packets is described in [Sen02]. An accompanying draft explains a procedure to establish the required security associations is described in[Sendoi02]. Additional MPLS specific security issues are described in [Beh02]. 8. Conclusions This draft provides a brief analysis of existing IP QoS solutions and accompanying signalling issues. This analysis is done in terms of reservation state, scalability, mobility support and security issues in order to point out pending and open issues of existing IP QoS solutions. RSVP as given in [RFC2205] is a flexible well-designed protocol that works well for applications for which it was intended. But, it has not been widely deployed due to issues such as complex reservation state management, scalability, etc. Furthermore, RSVP includes more functionality than what is required in some IP networks, where the QoS problem is significantly more simpler to solve (see [WQOSREQ]). In these networks, the tradeoff between performance and functionality is one of the key issues and the majority of the functionality in RSVP will not be required. This is because of the following reasons: * 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 de Meer, et al. Expires May 2003 [Page 22] Internet Draft Analysis of Existing QoS Solutions November 2002 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, i.e. these protocols will be sender-initiated. In this case, there is no need for PATH messages usage. This reduces the number of states in the routers (no Path State is required). 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. Thus, by removing multicast support, reservation styles, complex merging and state management RSVP is more lightweight in terms of implementation complexity, state maintenance and protocol processing. Sender-initiated reservations are also possible. A more detailed investigation is provided in [Fu02]. * Single operator edge-to-edge intradomain network 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. 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. 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 de Meer, et al. Expires May 2003 [Page 23] Internet Draft Analysis of Existing QoS Solutions November 2002 [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 network topology, the number of Aggregators/Deaggregators and the number of DiffServ Code Points (DSCPs) used. When considering networks with large number of flows, the number of the aggregated RSVP reservation states within such a network will be significant. RSVP-TE [RFC3209] describes the RSVP extensions needed for establishing LSPs tunnels in MPLS. The LSP tunnels enable a variety of network optimization policies as they can be routed explicitly in order to avoid congestion, bottlenecks and network failures. There can be several LSP tunnels set by means of RSVP-TE between two endpoints. All the packets, regardless of the traffic flow they belong to, which are assigned the same label as the LSP by a particular ingress node will be routed through this tunnel. The packet classification and scheduling is done based on this label de Meer, et al. Expires May 2003 [Page 24] Internet Draft Analysis of Existing QoS Solutions November 2002 only, which is much more simple and scalable than the RSVP itself. However this requires a mechanism based on label switching such as MPLS. This analysis points out pending and open QoS signalling issues related to reservation state management, scalability, support for mobility and security issues of the main existing IP QoS solutions ([RFC2205], [RFC2998], [RFC2475], [RFC3175], [RFC3209]). Given this analysis, we believe that appropriate standardization should take place to create the necessary protocols for QoS signalling. 9. 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. [Ha02] Tschofenig, H., "RSVP Security Properties", Internet Draft, work in progress. draft-tschofenig-rsvp-sec-properties-00.txt, 2002 [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. [PaKa02] Partain, D., Bergsten, A., Greis, M., Karagiannis, G., Manner, J., Murphy, J., Pan, P., Rexhepi, de Meer, et al. Expires May 2003 [Page 25] Internet Draft Analysis of Existing QoS Solutions November 2002 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. [RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 de Meer, et al. Expires May 2003 [Page 26] Internet Draft Analysis of Existing QoS Solutions November 2002 Reservations", IETF RFC 3175, 2001. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell M., McManus, J., "Requirements for Traffic Engineering Over MPLS", IETF RFC 2702, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", IETF RFC3209, 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. [To02] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Internet Draft, work in progress. draft-thomas-seamoby-rsvp-analysis-00.txt, 2001. [ChNe98] Chiueh, T., Neogi, A., "Performance Evaluation of An RSVP-Capable Router," in IEEE Real-Time Application and Technology Symposium, June 1998. http://www.ecsl.cs.sunysb.edu/tech_reports.html [Pa01] Paskalis, S., et al., "RSVP Mobility Proxy", Internet Draft, work in progress, draft-paskalis-rsvpmp-00.txt, December 2001. [RoCl02] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y., Sargor, C.: "Use of PE-PE IPsec in RFC2547 VPNs", Internet draft, work in progress, draft-ietf-ppvpn-ipsec-2547-02.txt, August 2002. [Beh02] Behringer, M.: "Analysis of the Security of the MPLS Architecture", Internet draft, work in progress, draft-behringer-mpls-security-02.txt, June 2002. [Sen02] Senevirathne, T.: "Secure MPLS - Encryption and Authentication of MPLS payloads", Internet draft, work de Meer, et al. Expires May 2003 [Page 27] Internet Draft Analysis of Existing QoS Solutions November 2002 in progress, draft-tsenevir-smpls-02.txt, July 2002. [Sendoi02] Senevirathne, T.: "Secure MPLS Domain of Interpretation for ISAKMP", Internet draft, work in progress, draft-tsenevir-smpls-doi-01.txt, July 2002. 10. Acknowledgments Thanks to Istvan Cselenyi, Pontus Wallentin, Geert Heijenk and Giussepe Bianchi for reviewing this draft and providing useful input. 11. 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 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 de Meer, et al. Expires May 2003 [Page 28] Internet Draft Analysis of Existing QoS Solutions November 2002 Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6; 81739 Munchen; Germany Email: Hannes.Tschofenig@mchp.siemens.de 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 May 2003 [Page 29]