Internet Engineering Task Force Marc Greis INTERNET-DRAFT Haihong Zheng draft-greis-qos-signaling-requirements-00.txt Nokia Research Center Jukka Manner University of Helsinki Requirements for QoS Signaling 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. Abstract This draft proposes a set of requirements for QoS signaling protocols. These requirements are derived both from past experience with existing QoS signaling protocols as well as new challenges which arise for QoS signaling e.g. from mobile, wireless and cellular networks. Greis, Zheng, Manner [Page i] INTERNET-DRAFT Requirements for QoS Signaling November 2001 1. Introduction Even though the IETF has created a QoS signaling protocol (RSVP [1]), a widespread deployment of QoS signaling protocols (like RSVP [1]) in the Internet has not occurred so far, mostly due to perceived and real shortcomings of this protocol. If a new QoS signaling protocol is to be created or if an existing one is to be modified to alleviate this situation, it is necessary to first produce a set of requirements which cover all potential problem areas. 2. Requirements for a QoS Signaling Protocol A list of requirements for QoS signaling protocols is presented in this section. Since IP mobility and next generation wireless networks create additional challenges for QoS signaling protocols, many of the requirements below describe these particular challenges. 2.1. Must have small overhead and allow for efficient bandwidth usage QoS signaling messages must have a small overhead. This is especially important for wireless links with expensive and limited bandwidth. This implies that the QoS information needs to be compact (i.e., no redundant and unnecessary information) and encoded efficiently. 2.2. Must have small overhead and allow for efficient bandwidth usage The QoS signaling protocol should allow the processing of the QoS signaling messages to be as simple as possible. This is especially important on mobile hosts with limited resources and power. This simplicity requirement may also help to reduce the delay of the QoS signaling procedure. Furthermore, the QoS parameters must be understandable, simple, but also intuitive to the "user" (e.g. end user or API developer) or communicating partners. 2.3. Must be flexible and extensible It must be possible to include special parameters for different access technologies in the QoS signaling protocol. Also, it must be possible to extend the QoS signaling protocol to adapt to future access technologies. Greis, Zheng, Manner [Page 1] INTERNET-DRAFT Requirements for QoS Signaling November 2001 This implies that the signalling protocol and the information it carries must be de-coupled from each other. 2.4. Must enable QoS negotiation between the host and the network in an efficient manner "QoS negotiation" in this context describes the process of an actual negotiation which may take place between a host and the network, i.e. the QoS request from the host would be seen as a proposal, which can be either accepted, rejected or downgraded by the network, the last option leaving it up to the host, if it wants to establish the communication based on the downgraded QoS. The QoS signaling protocol should allow QoS negotiation between the end node and the network or the remote endpoint in an efficient way. The efficiency can be measured by delay, bandwidth required, etc. Delay can in this context result from the number of round trip times, the processing time, and the size of the signaling messages. 2.5. Must allow QoS setup for duplex connections and simplex connections, both in the upstream and downstream direction For the case where the QoS is only required on the upstream direction (i.e. the direction from the end host towards the network), the QoS signaling only needs to trigger QoS establishment in this direction. For the application where the QoS is only required in the downstream direction (e.g., streaming application without feedback channel), the QoS signaling only needs to trigger QoS setup in this direction. Therefore, the QoS signaling protocol should allow QoS setup for these simplex connections. Also, QoS setup for duplex connections is required, where applications require QoS setup in both directions. 2.6. Must allow explicit QoS release After call termination, unneeded states related to the QoS signaling in the network should be released as soon as possible. The QoS signaling protocol must allow a host to send a QoS release request explicitly. Also, in the case where the host is a mobile node, it may be the responsibility of the network to remove old reservations at the old access point after handovers. It must be possible to implement such mechanisms in the network. Greis, Zheng, Manner [Page 2] INTERNET-DRAFT Requirements for QoS Signaling November 2001 2.7. Must allow efficient QoS re-establishment after handover Handover is an essential aspect in wireless networks. After handover, QoS may need to be completely re-established or partially re- established due to route change. The re-establishment may be requested by the mobile node itself or triggered by the access point that the mobile node attached to. In the first case, the QoS signaling should allow efficient QoS re-establishment after handover. Re-establishment of QoS after handover should be as quick as possible so that the mobile node does not experience service interruption or QoS degradation. The re-establishement should be localized, and not require end-to-end signalling, if possible. 2.8. Must enable other network entities to generate QoS request on behalf of a node A QoS request is normally generated by the node that requires QoS. However, in some cases, it is beneficial to send a QoS request by another network entity (a proxy) on behalf of the node. As an example, in a wireless network with limited bandwidth, the initial QoS request may be sent from the node itself, while the following ones sent after handover or for refresh purposes may be generated by the access router that keeps the QoS request state for the mobile node. The QoS signaling protocol must enable such a scenario. 2.9. Must be compatible with different QoS technologies used in the network Different QoS technologies, e.g, DiffServ, IntServ, MPLS, may be used in different or even the same network domains. The QoS signaling should be compatible with different QoS technologies (both existing signalling and provisioning mechanisms). More specifically, the QoS parameters included in the QoS signaling must be common for different QoS technologies or it must be possible to convert them to the specific parameters used in different QoS technologies. 2.10. Must allow QoS authorization and policy control QoS authorization and policy control provide operators with service control. QoS signaling must include necessary information to be used for the network to authorize the QoS request and perform policy control. Greis, Zheng, Manner [Page 3] INTERNET-DRAFT Requirements for QoS Signaling November 2001 2.11. Must support common security features This includes privacy and anonymity support as well as the integrity of signalling packets. 2.12. Must allow authentication of the QoS request QoS requests need to be authenticated before QoS authorization is performed. QoS signaling must be able to carry necessary information used by the network to authenticate the QoS request. 2.13. Must provide hooks for accounting QoS signaling protocol should include necessary information for the network to collect charging data for a specific user. 2.14. Must be independent from different mobility protocols Although the QoS signaling may be able to take advantage of specific mobility protocols for optimized operation, it should be designed independently from mobility protocols in the sense that it can still perform the same functionality when one or more of these mobility protocols are not used. 2.15. Minimal changes required in intermediate hosts This is a generic requirement of any mechanism that is used in routers, for example. The lighter the implementation, the more likely it will work efficiently. This is especially true for basic routers. 2.16. The QoS signalling and provisioning mechanisms must be decoupled from each other The QoS signalling mechanism should be decoupled from the mechanism used to provide the requested service (e.g. queueing mechanisms), which, among other things, allows the use of edge-to-edge mechanisms for resource control between different domains. 2.17. The access network structure must be invisible to end hosts The implementation of QoS in the access network network, including network topology, should not be visible to the end hosts. The QoS Greis, Zheng, Manner [Page 4] INTERNET-DRAFT Requirements for QoS Signaling November 2001 interface shall only reflect the "bearer requirements" that a host can request. Any mechanism or combination of mechanisms can be used together to provide the overall QoS. 2.18. The signalling must interwork with routing mechanisms A QoS signalling mechanism should support QoS routing in order to spread the load of congested network paths on alternate paths. Furthermore, the signalling mechanism should allow for setting QoS on multiple paths, for example, for multiple downstream paths. 2.19. Must not expect symmetric routing The QoS signalling mechanism must not assume symmetric routing for upstream and downstream directions. IP routing is commonly asymmetric, and only symmetric by coincidence. 2.20. Scalability must not be compromised The signalling mechanism must scale with the number of hosts sending QoS requests for an even greater number of flows. This may include minimizing the number of resource reservations managed. 2.21. Must interwork with IP tunneling The QoS signalling and provisioning mechanisms must operate in networks that make use of IP tunneling, but also IPSec. The signalling messages need to be visible to the network QoS nodes, but also the data packets that would need a specific QoS need to be identified. 2.22. Must support end-to-end, edge-to-edge and end-to-edge signalling The signalling mechanism must work end-to-end, but also, if needed, more locally, i.e. end-to-edge as well as edge-to-edge. The requirement also includes the potential need for signalling towards "middle-boxes" on the transport layer, e.g. firewalls and NATs. Greis, Zheng, Manner [Page 5] INTERNET-DRAFT Requirements for QoS Signaling November 2001 2.23. Interwork with non-QoS aware network paths The signalling messages must be transported through non-QoS aware core networks, for example, the signalling can still trigger QoS requests on access links on both ends, while the connecting core network may for example be over-provisioned. 2.24. Must support different types of QoS requests It must be possible to signal different service types: o reservations (both shared and dedicated), o reservationless (relative priority-based, drop precedences), 2.25. Must work with changing IP addresses of (mobile) hosts Mobile hosts may need to change their CoA while QoS is provisioned for them. The signalling mechanism must allow to change the identification information related to provisioned QoS to keep the QoS allocated to a mobile host's flows, either upstream or downstream. 2.26. Must support both unicast and multicast Both the support of unicast and multicast connections is desired. However, the implementation of the multicast features should not compromise the requirement for simplicity. 2.27. Must deal with IP fragmentation gracefully The possibility that signaling messages may be fragmented needs to be taken into account. The signaling protocol must deal with this issue in a simple and efficient manner. Acknowledgements A number of requirements were taken from the following Internet Drafts (in order of decreasing importance): 1) draft-bradner-nsis-bof-00.txt Greis, Zheng, Manner [Page 6] INTERNET-DRAFT Requirements for QoS Signaling November 2001 2) draft-ietf-mobileip-qos-requirements-01.txt 3) draft-westberg-rmd-cellular-issues-00.txt The authors of this draft would like to acknowledge the requirements raised in the above mentioned drafts by the authors of the drafts and by the people contributing requirements in the NSIS BOF held at the 50. IETF meeting. References [1] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001 [2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP", draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress, August 2001 [3] Partain, D., et al, "Resource Reservation Issues in Cellular Radio Access Networks", draft-westberg-rmd-cellular- issues-00.txt, Work in Progress, June 2001 Author's Addresses Marc Greis Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374 0629 Email: marc.greis@nokia.com Haihong Zheng Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894 4232 Email: haihong.zheng@nokia.com Greis, Zheng, Manner [Page 7] INTERNET-DRAFT Requirements for QoS Signaling November 2001 Jukka Manner University of Helsinki P.O. Box 26, FIN-00014 Helsinki Finland Phone: +358 9 191 44210 Email: jukka.manner@cs.helsinki.fi Greis, Zheng, Manner [Page 8]