MMUSIC Internet Draft J.C. Rojas S. Leroy Document: draft-rojas-mmusic-qosreq-00.txt Alcatel Expires: December, 2002 M. Holdrege Verison June 2002 Requirements for the QoS negotiation at the Application Layer < draft-rojas-mmusic-qosreq-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 [1]. 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 document identifies requirements for an end-to-end negotiation of the Quality of Service (QoS) aspects of each media component of a multi-media session at the application level, before requesting the transport layer for bearer setup. It is believed that in the future, QoS will be one of the major differentiators in the context of a new generation of multi-media services based on the IP technology. As such, QoS cannot be considered anymore as a matter of bearer handling only, but it has also to include the application layer. Moreover, QoS has to be considered as part of the media component description, and therefore, to be negotiated or re-negotiated during the session life. Conventions used in this document Rojas et al. Expires - December 2002 [Page 1] QoS negotiation at Application Layer June 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [11]. Table of Contents 1. Introduction...................................................2 2. Motivation.....................................................3 3. Requirements...................................................4 3.1 Functional requirements....................................4 3.2 Expressiveness requirements................................6 3.3 Dependency requirements....................................7 3.4 Performance requirements...................................7 4. Exclusions.....................................................7 5. Conclusion.....................................................8 Security Considerations...........................................8 References........................................................9 Acknowledgments..................................................10 Author's Addresses...............................................10 1. Introduction The Session Initiation Protocol, SIP [3] is an application-layer control protocol for creating, modifying and terminating sessions such as Internet multimedia conferences, Internet telephone calls and multimedia distribution. The SIP messages used to create sessions carry a session description, which allows participants to agree on a set of compatible media types. The session description, commonly formatted in SDP [4], is a well-defined format for conveying sufficient information to discover and participate in a multimedia session. Although SIP [3] and SDP [4] offer an attractive set of mechanisms for multimedia session control and description, several IETF drafts have already shown the need for extensions to these protocols, especially for delivering services with guaranteed end-to-end Quality of Service (QoS). Moreover, some existing drafts propose already extensions to SDP or SDPng to cover such needs [10][11]. Finally, draft [7] recognized that there is a requirement from the IETF Multiparty Multimedia Session Control (MMUSIC) working group to specify additional QoS parameters for SDPng. The current SDPng draft also mentions QoS parameters as one of the possible extensions [12]. This draft is organised as follows. Section 3 delineates the motivations for QoS at application layer. Section 4 describes the Rojas et al. Expires - December 2002 [Page 2] QoS negotiation at Application Layer June 2002 requirements themselves, which are split in four sub-sets: functional requirements, expressiveness requirements, dependency requirements, and performance requirements. Section 5 handles the Exclusions, that is, what this draft is not asking for, in order to avoid any misunderstanding. Section 6 analyses the security issues raised by the negotiation of QoS information. Finally, section 7 summarises and concludes this work. It has to be noted that it should be possible to apply the requirements presented in this document to any session signalling protocol; therefore, not only SIP has to be taken into account but also other protocols like SAP, RTSP, Megaco, etc. 2. Motivation It is now generally accepted that in the future, Quality of Service (QoS) will be one of the main differentiator aspects to provide high-quality voice and in general, multi-media services over an integrated IP network. Thus, service providers are becoming more and more aware of the possibility of getting new revenues by selling new services and not only some transport capacity. The main consequence is that QoS cannot be considered anymore as a transport layer matter only. The Application layer has to be also involved in the negotiation of the service characteristics, including the QoS level to be delivered to the end-users. Depending on the characteristics of each media component of the multi-media session, the QoS requirements will be very likely different, as e.g. between voice, video on one side, and instant messaging and application sharing on the other side. Even for well- known codecs, the QoS requirements could be different according to the end-user expectations, and the related subscription profile. From this point of view, QoS has to be considered as part of the description of the media components in the multi-media session. In the SIP model, the characteristics of the media components provided in the session description are negotiated at the beginning of the session using a standard procedure based on the Offer/Answer model [8], and next, it can be re-negotiated at any moment, by any of the involved end-users. This means that the QoS aspects of each media component can be negotiated and renegotiated following existing rules and procedures. It has to be noted that this negotiation at the application level does not include the transport level. End-users are intended to Rojas et al. Expires - December 2002 [Page 3] QoS negotiation at Application Layer June 2002 agree on "what to do", before actually trying to do it. In other words, end-users are intended to negotiate the media component characteristics including the network aspects, before asking the transport network to allocate the corresponding resources. 3. Requirements This section describes the requirements for QoS negotiation at the application layer. For the sake of simplicity, the set of requirements has been split into four sub-sets, as described below: - Functional requirements, that is, requirements having a functional meaning for the application layer. - Expressiveness requirements, that is, requirements catching the type of QoS information to be exchanged. - Dependency requirements, that is, requirements describing the dependence of the QoS negotiation procedures and other layers, protocols, and technologies. - Performance requirements, that is, requirements on the global performances concerning the session establishment. 3.1 Functional requirements - End-to-end QoS negotiation at the application layer. Session control elements of all the involved parties SHALL be able to participate in the negotiation process (end-user, local access network, service provider), before going down to the transport layer to setup the corresponding bearers. Which parties participate in the QoS negotiation is dependent on the applied service domain and policy management model, and is outside the scope of this document. - QoS negotiation per media component. It MUST be possible to describe the requested QoS level for each media component separately, in order to ensure a maximum of flexibility. This requirement does not preclude in anyway the possibility to have a mechanism allowing to specify the QoS requirement globally for the entire multi-media session. - Explicit QoS information exchange Sometimes, it is possible to derive some QoS information directly from the codec, when the latter and the related service are well known. However, several IETF drafts have shown that this is not always possible [10][11], since it depends strongly on the codec implementation, and the application itself. Rojas et al. Expires - December 2002 [Page 4] QoS negotiation at Application Layer June 2002 Therefore, it SHALL be possible to exchange explicit QoS information between all the involved parties to negotiate the QoS level to be delivered. Any parameter or protocol element to be defined to convey QoS information at the application levels SHALL always be considered as optional parameters. The fallback strategy SHOULD always be the current situation, where no QoS can be explicitly signaled at the application level. This way of doing guarantees full backward compatibility. Do note however that in some cases, the service provider could be unable to fullfill the contractual obligation with the customer, if explicit QoS information cannot be exchanged. - Target QoS level and Minimum QoS level. It SHALL be possible to negotiate two different levels of QoS: the Target QoS, that is, the level of QoS that SHALL be provided to the end-user, and the Minimum QoS, that is, the level of QoS under which the contractual definition of the service is definitely violated. The case of a single QoS level is covered using a Minimum QoS level equal to the Target QoS level. In case of temporary congestion, the network is authorised to adapt the QoS up to the Minimum QoS level without re-negotiating the session description. At any later point, the network may upgrade the QoS again to achieve the desired target QoS level. Do note that Best Effort has not to be considered as synonym of bad quality, but as the level were there is no guaranteed QoS. As an example, a given service could be provided with a certain level of QoS, but accepting to be downgraded to Best Effort, in case of temporary network congestion. The word "temporary" has a commercial meaning and scope; its definition is therefore out of the scope of this document. - Successful establishment of media components. An end-user SHALL be able to specify for each media component whether successful establishment of the corresponding bearer with a specific level of QoS is required for the session completion. Do note that this requirement is already covered by the pre-conditions mechanism [5]. - Synchronisation between the application layer and the bearer layer. It SHALL be possible to correlate the resources authorized by the application layer and the actual network resources requested by the end-user at bearer setup. Do note that this requirement is already covered by the media authorisation mechanism [6]. Rojas et al. Expires - December 2002 [Page 5] QoS negotiation at Application Layer June 2002 - Personal mobility. The QoS negotiation procedure SHALL be possible also in case of personal mobility, that is, regardless of the network access point where the end-user is connected to the network. - Roaming scenario. The QoS negotiation procedure SHALL be applicable for both the roaming and the non-roaming scenarios, that is, regardless if the end-user is connected to the home network or to a visited network. In the latter case, a roaming agreement is assumed between both networks. The specification of such roaming agreement is out of the scope of this document. 3.2 Expressiveness requirements - Application layer view of the QoS information. The QoS information to be used in the negotiation process at the application layer SHALL reflect the application layer perception of the service to be provided. The application is totally unaware of the transport technology (IP headers, MPLS labels, etc.), and the actual methods used in the transport network generating transport overhead (IP tunnels, IPsec headers, authentication information, etc.). This means that e.g., a bandwidth specification indicates the application layer requirements to provide the given service, and therefore, not including transport headers. - Traffic Information and Sensitivity Information. It SHALL be possible to describe separately two types of QoS related information : the Traffic Information and the Sensitivity Information. Per application QoS level/codec combination the Traffic Information specifies the amount and characteristics of resources that the transport network should provide, typically bandwidth, burstiness, maximum packet size, etc. The Sensitivity Information specifies the constraints for implementing the media component in the transport network with respect to the Traffic Information, typically delay, jitter, packet loss ratio, etc. - QoS Parameters and QoS Classes. It SHALL be possible to convey QoS information related to the Sensitivity aspects using well-defined QoS Parameters (delay, packet loss, etc.), or using QoS Classes, seen as an abbreviated notation form of a well-defined set of QoS parameters. - Standard QoS Classes and Private QoS Classes. QoS Classes MAY be defined as a set of standard values, Rojas et al. Expires - December 2002 [Page 6] QoS negotiation at Application Layer June 2002 especially for well known media components like voice, and the associated codecs. Nevertheless, it SHALL be possible to exchange non-standard QoS information between two end-points , and therefore having a meaning only for those end-points. In other words, it SHALL be possible to define a standardised way of carrying non-standard QoS information. One concrete example of the Private QoS Classes is the relation between the end-user and the service provider, allowing the latter to sell a package of services, including globally a QoS level definition. In this case, the service provider is responsible of translating the Private QoS Class into a standard set of QoS information, expressed either as QoS Parameters or Standard QoS Classes. 3.3 Dependency requirements - Independence of the session signalling protocol. The QoS description of the media components MUST not be related to any given session signalling protocol like e.g. SIP, SAP, RTSP, etc. - Independence of the network technology. The QoS description of the media components MUST be independent of the actual technology used in the transport network. As an example, the QoS description negotiated at the application layer MUST not encompass transport technology specific information like a DiffServ Code Point (DSCP), or an MPLS Label. - Relation with the transport network architecture. There SHALL not be any restriction about what architecture to use for network/transport resource signalling/provisioning at session initiation time. Additionally, the session signalling (together with the session description, and including the QoS information) MAY take a different network path than data in the user plane. 3.4 Performance requirements - Session establishment delay. The impact of the QoS negotiation procedure on the performances of session establishment MUST be limited as much as possible. Therefore, new messages exchanges have to be avoided, if possible. 4. Exclusions - Relation to bearer control protocols. The requirements expressed in this document do not interfere Rojas et al. Expires - December 2002 [Page 7] QoS negotiation at Application Layer June 2002 with the development of protocols and mechanisms in the bearer transport layer, including QoS handling. The latters are covered by other IETF working groups, like e.g. the recently created NSIS group [9]. - Mapping on IP bearer parameters. The mapping between the QoS information negotiated at the application layer, and the IP QoS information to be provided to the transport layer is considered as part of the commercial strategy of the service provider or the application. Therefore, this mapping has to be considered out of the scope of these requirements. - Terminal mobility. The Application QoS negotiation procedure is not related in anyway to the terminal mobility, in case of radio based access networks. The main reason is that handling of radio connection is a transport issue, and not an application issue; therefore, the radio segment is intended to be handled separately, using specific procedures. Do note however that a loss of radio, or a bad radio quality can imply the re-negotiation of the session description, and therefore, including the QoS aspects. 5. Conclusion This document described a set of requirements related to the end-to- end negotiation at the application layer, of the Quality of Service of each media component of a multi-media session. The QoS negotiation is performed before requesting the transport layer for bearer setup; therefore, the requirements described in this document do not overlap the scope of other IETF working groups, like e.g. NSIS. QoS is considered as part of the media component description; therefore, it should be possible to integrate the QoS negotiation procedure to already standardised procedures. Security Considerations Generally speaking, the fact of negotiating the QoS characteristics at the application layer SHOULD not bring new security issues, as it is proposed that in case of SIP, the negotiation process SHALL be based on the existing Offer-Answer model. The ongoing work to secure the existing session description SHOULD cover the security aspects of the QoS negotiation at the application layer. Rojas et al. Expires - December 2002 [Page 8] QoS negotiation at Application Layer June 2002 A man-in-the-middle attack could be possible if an entity in the middle of two end-users modify the QoS information being exchanged for negotiation purposes. Integrity protection can be used to avoid these type of attacks. An entity controlling resource reservation devices can be an easy target for a denial of service attack upon reception of unathenticated requests carrying QoS information. Any QoS information exchange SHOULD be authenticated. References 1 1 Bradner S, "The Internet Standard Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2..Bradner S., "Key words for use in RFCs to Indicate Requirement levels", BCP 14, RFC 2119, March 1997. 3 Rosenberg J., Schulzrinne H., Handley M., Schoooler E., "SIP, session Inintiation Protocol", draft-ietf-sip-rfc2543bis-09.txt, work in progress 4 M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-10.txt, work in progress 5 W. Marshall et al., "Integration of resource management and SIP", draft-ietf-sip-manyfolks-resource-07.txt, work in progress 6 W. Marshall et al., "SIP Extensions for Media Authorisation", draft-ietf-sip-call-auth-06.txt, work in progress 7 Kutscher, Ott, Bormann and Curcio, "Requirements for Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng- req-01.txt, Expired draft. 8 Rosenberg J., Schulzrinne H., "An offer/answer model with SDP", draft-rosenberg-mmusic-sdp-offer-answer-02.txt, Work in Progress. 9 Brunner M., "Requirements for QoS Signaling Protocols", draft-ietf-nsis-req-02.txt, Work in Progress 10 Bos L. et al., "SDPng extensions for Quality of Service Negotiation", draft-bos-mmusic-sdpng-qos-00.txt, Work in Progress Rojas et al. Expires - December 2002 [Page 9] QoS negotiation at Application Layer June 2002 11 Guenkova, T. et al., "Efficient End-to-End QoS Signaling - concepts and features", draft-guenkova-mmusic-e2enp-sdpng-00.txt, work in progress 12 Kutscher et al. "Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng-04.txt, Work in progress. Acknowledgments This document is a result of an ongoing discussion among people from Alcatel and Verison. We would hereby like to thank all the people who provided valuable comments and input that improved the quality of this document. Funding for the RFC Editor function is currently provided by the Internet Society. Author's Addresses Suresh Leroy Alcatel Francis Wellesplein 1 2018 Antwerpen Belgium Phone: +32 3 240 85 50 Email: Suresh.Leroy@Alcatel.be Juan-Carlos Rojas Alcatel Le Mail 44708 Orvault Cedex France Phone: +33 2 5178 1282 Email: Juan-Carlos.Rojas@Alcatel.fr Matt Holdrege Verison 223 Ximeno Avenue Long Beach, CA 90803 U.S.A. Email: Matt.Holdrege@verizon.net Full Copyright statement Rojas et al. Expires - December 2002 [Page 10] QoS negotiation at Application Layer June 2002 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Rojas et al. Expires - December 2002 [Page 11]