MMUSIC working group L. Bos Internet Draft S. Leroy Document: draft-bos-mmusic-sdpng-qos-00.txt J-C Rojas Expires: September 2002 L. Thiebaut J. Vandenameele Alcatel P.Veenstra KPN R. Brook Samsung Electronics M. Holdrege Sonus Networks Inc. SDPng extensions for Quality of service negotiation 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 document describes a framework that allows end- users/applications to inform each other and negotiate about the QoS characteristics of the media components in a session, prior to its establishment. The QoS negotiation is modeled after the existing codec negotiation and as such becomes an integral part of the existing SDPng Offer/Answer model. The QoS information is exchanged at session set-up time using two new types of SDPng extensions between the end-users sites. Apart from the end hosts also some Bos draft-bos-mmusic-sdpng-qos-00.txt 1 SDPng extensions for QoS negotiation September 2002 authorized intermediate proxies controlling the session set-up MAY participate to the QoS negotiation. Secondly this document proposes SDPng extensions which allow the end-user to request an ordered list of preferred QoS levels per media stream during the QoS negotiation. The first type of extensions, called TI (Traffic Information), characterizes the traffic type of the bearer associated with the media stream. TI is typically related to bandwidth and packet size. The second type of extensions, called SI (Sensitivity Information), characterizes the sensitivity level of the service requested by the end-user with respect to the QoS information carried in the first type of SDPng extensions. SI is typically related to delay, jitter and packet loss. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Conventions used in this document...............................3 2. Introduction....................................................3 3. Terminology.....................................................5 4. QoS information to be carried in SDPng..........................6 4.1. First SDPng extension: TI (Traffic Information)...............6 4.2. Second SDPng extension: SI (Sensitivity Information)..........7 4.3. Encoding of QoS extensions in SDPng...........................8 4.3.1. QoS Parameter format........................................8 4.3.2. The QoS Class format........................................9 4.3.3. The QoS Flavour format......................................9 5. QoS negotiation procedure......................................10 5.1. Principles of the QoS negotiation procedure..................10 5.2. Offer/Answer versus Offer/Counter-Offer/Answer model for QoS negotiation.......................................................10 5.2.1. Current SDP codec negotiation..............................10 5.2.2. Proposed SDPng QoS negotiation.............................11 5.2.2.1 Simple UAC-UAS scenario...................................12 5.2.2.2. UAC-Proxy Server-UAS scenario............................12 5.3. Relationship with transport level QoS provisioning...........14 5.4. QoS preconditions - Coupling with manyfolks..................14 5.5. Scenario examples............................................15 5.5.1. Example 1: Simple UAC-UAS scenario.........................15 5.5.2. Example 2: UAC-Proxy Server-UAS scenario...................16 6. Security considerations........................................16 7. Conclusions....................................................17 8. Acknowledgements...............................................17 9. References.....................................................18 10. Author's Addresses............................................18 11. Full copyright statement......................................19 Bos draft-bos-mmusic-sdpng-qos-00.txt 2 SDPng extensions for QoS negotiation September 2002 1. Conventions used in this document 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]. 2. Introduction There is a whole range of applications that requires a phase of session/application level signaling before setting up network-layer resources/QoS. Examples are Internet telephony calls, multimedia conferencing (e.g. created via SIP), broadcast scenarios (e.g. announced via SAP), streaming applications (e.g. controlled via RTSP), etc. Typically the application level signaling messages used to create or modify those types of sessions carry session descriptions, which allow participants to exchange end-system capabilities and agree on a set of compatible media types. The session description, commonly formatted in SDP [2] or in the future in SDPng [6], is a well-defined format for conveying sufficient information to discover and participate in the session. Some applications (e.g. Internet phone calls, ad-hoc multiparty conferencing) require a dynamic exchange of the session description to allow participants to exchange end-system capabilities and negotiate/agree on a set of compatible media types. Other applications (e.g. loosely coupled conferences or broadcast scenarios) don't require a negotiation phase. For example via SAP a previously created (and typically fixed) session description can be disseminated to a potentially large audience. Only the interested members of the audience that support all the parameters specified by the session description contained in SAP, will join the announced session. The same SDPng QoS extensions can be used both for applications that require negotiation (e.g. SIP, BICC) or dissemination (e.g. SAP, RTSP) of the session description. As the dissemination case can be seen as a simplified one-way negotiation, the rest of this document will focus on the SDPng QoS negotiation procedure. The SIP protocol is used as example. Although SIP [1] and SDP [2] 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 provisioning end-to-end Quality of Service for high- quality IP telephony and multimedia services. In essence these recent proposals have recognized the need to enhance the co- ordination between the session signaling layer, which controls access to multimedia specific services, and the resource management layer, which controls access to network resources. [4] describes SIP extensions for media authorization for correlating the resources authorized by the session signaling architecture with Bos draft-bos-mmusic-sdpng-qos-00.txt 3 SDPng extensions for QoS negotiation September 2002 the actual network resources requested by the UA for the media components. Manyfolks [3] describes SDP extensions that allow end- users to check before continuing with the session set-up if establishing network QoS or security associations was successful for the individual media streams. But the manyfolks SDP extensions/preconditions don't allow expressing which level of network QoS is required. Currently simply no mechanism exists to specify at session control level per media stream the QoS requirements that reflect the true end-user expectations. Since the purpose of the SDP[2]/SDPng[6] protocol is to carry the actual session and media stream description, extensions to this protocol seem the natural way to carry this QoS information. In this way all applications using the SDPng session description (e.g. SIP, BICC, SAP, RTSP, MEGACO, ą) can benefit from the same QoS extensions. The need to add QoS information to SDPng has already been recognized in the SDPng requirements draft [4] and the SDPng draft on requirements for session description and capability negotiation [5]. This document makes a specific proposal for those additional QoS information fields in SDPng. However for backward compatibility with the current SDP version and timely market introduction of the proposed QoS extensions together with the manyfolks extensions, the authors believe that similar QoS extensions to SDP would be most useful. The final goal of the true and-to-end QoS provisioning architecture is to deliver the end-user for each media stream a QoS that corresponds exactly to the level of "Quality" he wishes to experience. Currently however we are still far from this goal. Network operators or service providers may want their SIP proxies to be able to "screen" SIP/SDP messages (e.g. to enforce local QoS policy control or to check the user's QoS subscription profile). But unfortunately the QoS the user really wants can not be derived accurately from the codec and the optional b parameter in SDP. Even if SIP proxies of local access/service provider force themselves in the SIP signaling path (e.g. Record Route), today they can not fully control the QoS requirements associated with all session set-ups. This because some media simply are not associated with a codec (e.g. white board) or are associated with a codec the proxy doesnĘt know (e.g. new applications). Since today end-users can not negotiate/reach a QoS agreement at session set-up, there is no way to ensure that in both access networks the end-users will initiate a bearer set-up request with the same QoS. Therefore it is impossible for service providers to deliver "predictable end-to-end QoS" to their customers. And thus they can not really charge for QoS today. All these problems are solved with the proposed solution of QoS negotiation via SDPng extensions. Service providers ideally would like to sell QoS packages (e.g. Gold/Silver quality). Before starting to watch a movie for example, Bos draft-bos-mmusic-sdpng-qos-00.txt 4 SDPng extensions for QoS negotiation September 2002 an end-user may want to choose between different qualities and prices. The business model for long distance calls is already proven. Some telephony networks already offer users the choice between the traditional phone connection and the IP-based one, where the latter is cheaper but of worse quality. It is reasonable to assume that users may also be willing to pay for a differentiation in quality based on other parameters like destination (business/private call), expected duration of the session, etc. Service providers might also want to adapt the QoS based on other parameters (e.g. time of day/week, busy/non busy hour, destination, service settings). The proposed solution even creates further room for differentiation between service providers by allowing them to define their own QoS levels/packages. The proposal enables end-users to express to the network and to negotiate with each other the "Quality" they find acceptable for each media stream of the requested multimedia session. It also provides a way for the network to check at session control level whether the QoS levels acceptable to both end-users are compliant with e.g. the users' subscription profile, service settings, policies in the local access,... . It is important to understand also that this document does not describe a way to use SIP/SDPng messages for QoS provisioning. The SDPng QoS negotiation occurs independently of and prior to the QoS provisioning itself (e.g. RSVP [8], MPLS [10]). This document is organized as follows. Section 3 provides a definition list. Section 4 introduces the two new types of SDPng extensions. Section 5 explains the QoS negotiation procedure and gives some examples scenarios. Section 6 covers the security considerations. Section 7 wraps up with the conclusions highlighting the main advantages of the proposed approach. 3. Terminology The following is a list of terms used with a specific meaning in this document. - Local access provider: entity locally providing the end-user access to the network - Service provider: entity offering services to end-users - Subscription: commercial agreement specifying the characteristics of service delivery between the service provider and the customer, possibly including QoS information - Service settings: service specific information that can be set to different values by service provider - Interface: reference point between two session signaling elements - Roaming: possibility to get access to the network via different Bos draft-bos-mmusic-sdpng-qos-00.txt 5 SDPng extensions for QoS negotiation September 2002 local access providers - Session level: session signaling level in the protocol stack, controlling access to applications/services (e.g. SIP) - Transport level: resource management level in the protocol stack, controlling access to network resources (e.g. RSVP) This document also uses the following terminology as defined in [1]: User Agent Client (UAC), User Agent Server (UAS), User Agent (UA), Session, call, Offer/Answer model, Offer/Counter-offer/Answer model. 4. QoS information to be carried in SDPng The goal is that the QoS information carried in SDPng reflects exactly the "Quality" level "as the end-user wants to perceive it". In order to ensure a maximum of flexibility, it SHALL be possible to negotiate the QoS for each media stream of a given multimedia session. Two types of SDPng extensions are needed during the QoS negotiation; TI (Traffic Information) and SI (Sensitivity Information). With each codec corresponds one TI level. The end-user (or some default settings or application running on the end-user terminal) SHOULD be able to specify per media stream and per codec an ordered set of acceptable SI QoS levels. Per codec/TI a list of SI levels is possible. The set of acceptable SI values are listed in decreasing order of preference in SDPng. This allows for prioritization during negotiation. Although there is only one QoS negotiation per SIP transaction for both send and receive directions, the QoS requirements itself can be different in the send and receive directions. 4.1. First SDPng extension: TI (Traffic Information) The first SDPng QoS extensions, called TI (Traffic Information), define the traffic type of the bearer associated with the media stream. The parameters characterizing TI are peak bit rate, sustainable bit rate, maximum packet size and maximum burst size. TI carries the QoS information that in normal situations can be more or less derived from the codec. However there are cases where some media streams are not associated with codecs (e.g. white board) or cases where the intermediate session control entities do not recognize the codec being used (e.g. use of new codecs). Carrying TI explicitly in SDPng still provides intermediate session control entities (e.g. SIP proxies) knowledge/control on the bearer requirement of the session being established. It relieves the requirement for all involved session control elements to know the mapping from a codec to the transport level requirement (TI) of this codec. This facilitates the introduction of new codec types. Bos draft-bos-mmusic-sdpng-qos-00.txt 6 SDPng extensions for QoS negotiation September 2002 TI is always represented in SDPng under the form of parameters with their respective values: o peak bit rate o sustainable bit rate o maximum packet size o maximum burst size 4.2. Second SDPng extension: SI (Sensitivity Information) The second SDPng QoS extensions, called SI (Sensitivity Information), define the sensitivity of the service with respect to the QoS information carried in TI. The parameters characterizing SI are maximum end-to-end delay, maximum end-to-end delay variation and maximum packet loss ratio. For a certain bearer defined by TI, SI unambiguously determines the quality "as the end-user wants to perceive it", SI allows making the differentiation between low, media, high quality. Three different formats that can be used to represent SI in SDPng: - QoS Parameters format: A standardized set of well-known parameters unambiguously describing the sensitivity (SI) requirement for a particular codec corresponding with TI for a given media stream in a session. The SI QoS parameters are: o maximum end-to-end delay o maximum end-to-end delay variation o maximum packet loss ratio - QoS Class format: A standardized abbreviation for the SI QoS parameter format. Knowing the codec, a QoS class can be directly and unambiguously translated to a predefined set of SI QoS parameters with well- defined values. An example QoS class for audio for PCM codec (G.711) could be "TIPHON PSTN type voice quality". QoS class values MUST be defined by an internationally recognized standards body. - QoS Flavour format: A standardized way of sending specific non-standard information describing SI for particular TI/codec. The QoS Flavour format is used in cases where two involved session control peer elements would like to exchange non-standard (e.g. service/provider specific) QoS information. The usage of the QoS Flavour is always assuming a pre-defined and well-understood interpretation of the QoS information sent over the considered interface. Therefore, the list of possible QoS Flavour values that may be exchanged on a given interface has to be previously defined by a common agreement between the involved parties. Examples of the QoS Flavour format are Gold/Silver/Bronze quality, Low/Medium/High quality,... Bos draft-bos-mmusic-sdpng-qos-00.txt 7 SDPng extensions for QoS negotiation September 2002 A session control element can use different formats to represent the same SI information depending on which other session control element it is interfacing with. For example, a service provider can use the QoS Flavour form on the interface with the end-user and use a standardized form (QoS parameters or QoS Class) on the interface with a network operator. The service provider is assumed to perform the translation between the different representation forms. 4.3. Encoding of QoS extensions in SDPng The QoS extensions are encoded in SDPng using