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 <option>, as was already suggested in the last example of section 3.1.2 in [6]. This section shows, for each of the three different formats explained in section 4.2, how the SDPng QoS extensions could be incorporated in that example. 4.3.1. QoS Parameter format <cfg> <component name="audio1" media="audio"> <alt name="AVP-audio-0"> <rtp:session format="rtp-avp-0"> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"> <option name="TI" pbr="29" sbr="29" mps="72" mbs="72"> <suboption type="SI-parm" name="SI1" me2ed="80" me2edv="10" mplr="2E-2"/> <suboption type="SI-parm" name="SI2" me2ed="120" me2edv="20" mplr="2E-2"/> </option> </rtp:udp> </rtp:session> </alt> </component> </cfg> This example indicates that for the component "audio1" there is only one acceptable codec "AVP-audio-0". But with this one codec there are two acceptable QoS levels, specified in parameter format respectively as SI1 and SI2. The first set (TI, SI-parm-1) has the highest preference. The above TI parameters are defined as follows: pbr: Peak Bit Rate, expressed in kilobits per second sbr: Sustainable Bit Rate, expressed in kilobits per second mps: Maximum Packet Size, expressed in bytes mbs: Maximum Burst Size, expressed in kilobits The above SI parameters are defined as follows: me2ed : Maximum end-to-end delay, expressed in milliseconds me2edv: Maximum end-to-end delay variation,expressed in milliseconds mplr : Maximum Packet Loss Ratio Bos draft-bos-mmusic-sdpng-qos-00.txt 8 SDPng extensions for QoS negotiation September 2002 4.3.2. The QoS Class format <cfg> <component name="audio1" media="audio"> <alt name="AVP-audio-0"> <rtp:session format="rtp-avp-0"> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"> <option name="TI" pbr="29" sbr="29" mps="72" mbs="72"> <suboption type="SI-class" name="SI1" body="TIPHON" cl="Narrowband HIGH"/> </option> </rtp:udp> </rtp:session> </alt> </component> </cfg> This example indicates that for the component "audio1" there is only one acceptable codec "AVP-audio-0". For this single codec there is also only one acceptable QoS level, specified in class format, the "TIPHON PSTN audio" quality. "TIPHON Narrowband HIGH" is an example of the QoS class defined by TIPHON corresponding with classical PSTN audio quality. 4.3.3. The QoS Flavour format <cfg> <component name="audio1" media="audio"> <alt name="AVP-audio-0"> <rtp:session format="rtp-avp-0"> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"> <option name="TI" pbr="29" sbr="29" mps="72" mbs="72"> <suboption type="SI-flav" name="SI1" flav="Gold"/> <suboption type="SI-flav" name="SI2" flav="Silver"/> <suboption type="SI-flav" name="SI3" flav="Bronze"/> </option> </rtp:udp> </rtp:session> </alt> </component> </cfg> This example indicates that for the component "audio1" there is only one acceptable codec "AVP-audio-0". But with this one codec there are three acceptable QoS levels, specified in flavour format as "Gold", "Silver" and "Bronze" quality. Gold has the highest preference. "Gold Quality", "Silver Quality" and "Bronze Quality" are examples of QoS Flavours defined by a service provider. Bos draft-bos-mmusic-sdpng-qos-00.txt 9 SDPng extensions for QoS negotiation September 2002 5. QoS negotiation procedure The purpose of this section is to explain the QoS negotiation procedure and to provide some example scenarios. The general principles behind the QoS negotiation procedure are described in section 5.1. Section 5.2 explains that the QoS negotiation is modelled after existing SDPng codec negotiation and shows how it becomes an integral part of the SDPng Offer/Answer or Offer/Counter- Offer/Answer model. Section 5.3 provides example QoS negotiation scenarios. 5.1. Principles of the QoS negotiation procedure Allowing end-users to choose/agree upon a different QoS for the same type of communication (e.g. audio call) on a per session basis, requires QoS (TI and SI) to be negotiable between end-users at the session signaling level. All parties executing control on the session signaling (i.e. end- user, service provider executing service control and local access network executing policy control) SHALL be able to participate in the QoS negotiation process. This is to ensure that the QoS negotiation results in a set of TI and SI values that have been agreed truly end-to-end at session level so that subsequently at the transport level QoS provisioning can be started based on end-to-end QoS agreement. 5.2. Offer/Answer versus Offer/Counter-Offer/Answer model for QoS negotiation This draft refers to [1] for the definition of the roles played by participants in SIP communications. This document also refers to [3] for the definition of certain SIP extensions (e.g. SIP 183-session- progress). Using this terminology, a simple SIP transaction can be modeled as a communication between a UAC and a UAS. A UAC is a logical entity initiating the SIP transaction with a request (e.g. SIP INVITE) and a UAS is a logical entity that responds to a SIP request (e.g. SIP 200-OK or SIP 183-session-progress), generally acting on behalf of some user. 5.2.1. Current SDP codec negotiation As described in [7], SDP negotiation within SIP follows an "offer- answer" model. One side (offerer) offers an SDP that provides its own view of the session, and the other side (answerer) answers the SDP with a matching one. The offer can be differentiated in sending and receiving directions by marking media streams as send-only or receive-only. If no marking is present the default is both send and receive. According to [7] SDP negotiation may occur in two ways, which are referred to as Offer/Answer versus Offer/Counter- Offer/Answer model: - Offer/Answer model The offerer offers an SDP. The answerer is only allowed to reject Bos draft-bos-mmusic-sdpng-qos-00.txt 10 SDPng extensions for QoS negotiation September 2002 or to restrict the offer. In the latter case, the answer contains an SDP that is a sub-set of the original SDP proposed by the offerer (the number of "m=" lines remains the same). In the common example of codec negotiation, the UAC offers the list of codecs the UAC is willing to use in the SDP of the SIP INVITE. UAS answers with an SDP in the SIP 200-OK (or SIP 183-session- progress) containing only that subset of the original list of codecs that the UAS is willing to use. - Offer/Counter-Offer/Answer model The offerer offers an SDP. The answerer makes a Counter-Offer with additional elements or capabilities not listed in the original SDP offer. The Counter-Offer contains an SDP that may be a super-set of the original SDP proposed by the offerer (even when the number of "m=" lines remains the same). In the common example of codec negotiation, the UAS answers with an SDP in the SIP 200-OK (or SIP-183-session-progress) containing additional codecs, not listed in the SDP of the SIP INVITE received from the UAC. In both cases, the final result of the codec negotiation is a list of codecs for a given media stream; any of those codecs can be freely used during the session without sending a SIP message. 5.2.2. Proposed SDPng QoS negotiation The QoS negotiation is modelled after the existing codec negotiation and as such becomes an integral part of the existing SDPng Offer/Answer or Offer/Counter-Offer/Answer model. The offerer determines per media stream a set of acceptable QoS levels, expressed in SDPng per media component and per codec/TI as an ordered set SI values. The list of acceptable SI QoS values, called "Requested QoS", is carried in the SDPng offer in one of three formats (QoS Parameter, QoS Class or QoS Flavour) and in decreasing order of preference, to allow prioritization during negotiation. +---------+ Requested QoS +----------+ | |--------------------->| | | offerer | Negotiated QoS | Answerer | | |<---------------------| | +---------+ +----------+ Offer/Answer model +---------+ Requested QoS +----------+ | |--------------------->| | | | Extended QoS | | | offerer |<---------------------| Answerer | | | Negotiated QoS | | | |--------------------->| | +---------+ +----------+ Offer/Counter-Offer/Answer model Bos draft-bos-mmusic-sdpng-qos-00.txt 11 SDPng extensions for QoS negotiation September 2002 Figure 1: Basic versus Enhanced QoS offer-answer model In the Offer/Answer model (see top of Figure 1) the answerer is only allowed to reject or restrict the "Requested QoS". The UAS SHOULD use the QoS value with the highest preference that is acceptable to it. The SDPng answer contains a "Negotiated QoS", that is a sub-set of the original "Requested QoS". The "Negotiated QoS" is equal to the "Requested QoS" in case the UAS accepts to support all the QoS values originally proposed by the UAC. The UAS MUST list the "Negotiated QoS" levels in the same relative order they were present in the "Requested QoS" to guarantee that the same QoS level is used by both User Agents. In the Offer/Counter-Offer/Answer model (see bottom of Figure 1) the answerer MAY extend the "Requested QoS" with additional QoS levels not listed in the original "Requested QoS". In this case, the Counter-Offer contains an "Extended QoS", that MAY be a super-set of the original "Requested QoS" proposed by the offerer. The offerer selects a subset "Negotiated QoS" of the "Extended QoS" and sends this "Negotiated QoS" back to the answerer. In both cases, the final result of the QoS negotiation is the "Negotiated QoS"; a decreasing ordered list of QoS (TI and SI) values per media stream retained for the session. Any of those negotiated TI/SI combinations can be freely used during the session without sending a SIP message. 5.2.2.1 Simple UAC-UAS scenario A simple example (Figure 2) is direct UAC to UAS communication according to the QoS Offer-Answer model. The "Requested QoS" is carried in the SIP INVITE, the "Negotiated QoS" in the SIP 200-OK or SIP 183-session-progress. +-----+ SIP INVITE, SDPng "Requested QoS" +-----+ | |-------------------------------------------->| | | | SIP 200-OK or SIP 183-session-progress | | | UAC | SDPng "Negotiated QoS" | UAS | | |<--------------------------------------------| | | | ACK or PRACK | | | |-------------------------------------------->| | +-----+ +-----+ Figure 2: Simple UAC - UAS scenario 5.2.2.2. UAC-Proxy Server-UAS scenario According to [1], SIP requests can be sent directly from a UAC to a UAS or they can traverse one or more proxy servers along the way. Also from [1] we learn that a proxy can indicate that it wants to remain in the request path via a Record-Route header field. [1] also Bos draft-bos-mmusic-sdpng-qos-00.txt 12 SDPng extensions for QoS negotiation September 2002 states that proxies MAY modify any part of the SIP message - including the SDP - that are not integrity-protected, except those needed to identify call legs. The above statements, quoted from [1], have the following implications on the QoS Offer/Answer model. Firstly the simple UAC- UAS model (Figure 2) does not suffice. One or more proxy servers, possibly operated by different providers, MAY be in the signaling path between UAC and UAS (Figure 3). Some proxies (e.g. proxy in local access network executing policy control and proxy operated by the userÆs Internet service provider executing service control) MAY Record-Route themselves, so that they can screen the SDPng QoS negotiation, and MAY decide to modify the QoS being negotiated. +-----+ +--------+ +-----+ | | SIP INVITE | | SIP INVITE | | | | SDPng | | | | | | "Requested QoS" | | SDPng "Modified QoS" | | | |------------------->| |----------------------->| | | UAC | SIP 200-OK or | proxy | SIP 200-OK or | UAS | | | SIP 183 | SIP | SIP 183 | | | | SDPng | | | | | | "Negotiated QoS" | server | SDPng "Negotiated QoS" | | | |<-------------------| |<-----------------------| | | | ACK or PRACK | | ACK or PRACK | | | |------------------->| |----------------------->| | +-----+ +--------+ +-----+ Figure 3: UAC - Proxy Server - UAS scenario Figure 3 shows the impact of intermediate proxies on the Offer- Answer model. Proxies MAY modify the "Requested QoS" received from the UAC to a "Modified QoS" based on different criteria. Such criteria could include information regarding subscription profile of the user, specific service settings, time of day/week or any other local network policies. Of course the UAS may also perform a final restriction on the set of QoS values resulting in the "Negotiated QoS". Thus, the "Negotiated QoS" will equal the "Requested QoS" only if the "Requested QoS" was compliant with the subscriber profile/service settings, not conflicting with local network policies and acceptable to the UAS. In the Offer-Answer model proxies are only allowed to make modifications in the sense of restrictions. The only exception is when the UAC does not include a "Requested QoS" in the SIP INVITE message. In this case a SIP proxy in the end-userÆs service provider domain MAY propose a "Modified QoS" itself. If the UAC does not specify a "Requested QoS" in the session set up, the "Modified QoS" MAY be deduced by the userÆs service provider either implicitly from access information about the UAC (terminal capabilities, Bos draft-bos-mmusic-sdpng-qos-00.txt 13 SDPng extensions for QoS negotiation September 2002 applications in terminal, access type, etc.), or from subscription or service information (the userÆs service provider can propose subscription packages with different levels of QoS for the different media streams involved in a communication service). 5.3. Relationship with transport level QoS provisioning On the response path (Figure 3) the "Negotiated QoS" is distributed (in a SIP 200-0K or SIP 183-session-progress) to all involved session control elements between UAS and UAC side. At this point, proxies in the local access networks MAY use this "Negotiated QoS" information to inform the transport layer about the QoS/resources that have been authorized by the session layer for each media stream of the multimedia session. This topic is however not the subject of this document. [4] Already describes SIP extensions for media authorization which enable this correlation between the resources authorized by the call/session signaling architecture and the actual network resources requested by the UA at resource reservation/QoS provisioning. 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. Since in an IP network session signaling (e.g. SIP/SDP) usually follows another route than the data path, a proposal to integrate them indeed would make no sense. During the SDPng QoS negotiation step end-users simply agree on the QoS they would prefer but no resource reservation /QoS provisioning is carried out yet for that particular session. The proposed SDPng QoS extensions are a way to make sure that existing QoS provisioning mechanisms (e.g. RSVP, DiffServ, MPLS) receive correct and complete input, enabling them to reserve the resources with a QoS that matches exactly the end-user expectations. After all parties (end-user, local access network, service provider) involved in the session signaling have agreed upon the QoS, appropriate QoS has to be provisioned in the network to deliver this QoS. Therefore UAC and UAS need to be able to translate the final TI and SI values negotiated at session/service level into the correct transport level QoS parameters, in order to trigger the corresponding QoS provisioning mechanisms (e.g. RSVP, DiffServ). 5.4. QoS preconditions - Coupling with manyfolks Manyfolks [3] defined the "qos" attribute SDP extension, that indicates whether end-to-end resource reservation is optional or mandatory, and in which direction (send, recv, or sendrecv). The assumption is that similar extensions will also exist in SDPng. An end-user should be able to specify for each media stream whether the successful establishment of a bearer "with a specific QoS" is required. This is enabled by co-ordinating the simultaneous usage of the mandatory or optional SDPng manyfolks extensions with the SDPng QoS extensions defined in this document. Bos draft-bos-mmusic-sdpng-qos-00.txt 14 SDPng extensions for QoS negotiation September 2002 According to manyfolks [3] in case resource reservation is required as a precondition before proceeding with the session, it is necessary to replace the SIP 200-OK in Figure 2 by a SIP 183- session-progress and the SIP ACK by a SIP PRACK. When the "qos" attribute indicates mandatory, this means that the participant who has received the session description does not proceed session setup until resource reservation has been completed in the specified direction. This document extends manyfolks [3] in the following way. If the "qos" attribute is set to mandatory, the SDPng QoS extensions allow participants to indicate that resources need to be reserved end-to- end, not only in which direction, but also WITH WHICH QUALITY OF SERVICE. Namely, with a Quality of Service compliant with the set of acceptable QoS values carried in the SDPng QoS extensions. If the "qos" attribute is set to optional, the SDPng QoS extensions allow participants to indicate with which Quality of Service resources should be reserved, but only if possible, that is without blocking the session set up process. If for mandatory media an end-user does not want best effort quality, the end-user should not indicate best effort as an acceptable QoS level. For optional media, best effort quality is implicitly assumed to be acceptable. 5.5. Scenario examples 5.5.1. Example 1: Simple UAC-UAS scenario Suppose again the simple case (Figure 2) of direct UAC to UAS communication according to the QoS Offer-Answer model. Suppose the UAC specifies a "Requested QoS" containing acceptable QoS levels A, B and C for audio and D and E for video (highest preference for A respectively D). Upon evaluation of the preference list of QoS values in the "Requested QoS", the UAS restricts the "Requested QoS" to only those QoS values that he is willing to use for this particular session. Suppose that the "Negotiated QoS" retains QoS levels A and B for audio and QoS level E for video. This means that the UAS is not willing to support the lowest QoS level C for audio nor the highest QoS level D for video. Suppose the UAC had specified in the SDPng offer that reservation of resources for the audio component (with acceptable QoS levels A, B and C) was optional in the receiving direction whereas reservation of resources for the video component (with acceptable QoS levels D and E) was mandatory also in the receiving direction. This effectively means that the UAC only wishes to continue with the session if the UAS agrees and succeeds to reserve resources towards UAC for the video with a Quality of Service not lower than E and not higher than D. Making resource reservation for the audio component optional means that the UAC would like a Quality of Service level between A and C Bos draft-bos-mmusic-sdpng-qos-00.txt 15 SDPng extensions for QoS negotiation September 2002 but it will accept the media stream in the worst case even with no QoS guarantees (best effort). As the "Negotiated QoS" in this example contains the QoS level E for the video the UAC would accept the session. Suppose UAS rejected all A,B and C for the audio component ("Negotiated QoS" does not contain any QoS values for the audio component), the UAC would still accept the session even with best effort quality of service for the audio. 5.5.2. Example 2: UAC-Proxy Server-UAS scenario Suppose again the case (Figure 3) with intermediate proxy/proxies between UAC and UAS. This example illustrates the use of the three possible formats that can be used to express the SI requirements (QoS Parameters, QoS Class, QoS Flavour). Suppose the UAC uses in the SIP INVITE the "QoS flavour" format hereby indicating to the proxy of the service provider for example that both "Gold" and "Silver" are acceptable for the voice component. "Gold" and "Silver" can be commercial names for QoS packages, the correct interpretation of which are only known to the end-user and its Service Provider (e.g. defined in a subscription). Suppose for this example that the proxy of the service provider decides, after checking several criteria (e.g. local network policies, subscription profile of the end-user, service settings,...) that only "Silver" can be retained. Before forwarding this information to the UAS the service provider will have to perform the correct translation from the non-standard "QoS Flavour" representation form into one of the standard formats "QoS Class" or "QoS Parameters". Since the usage of the QoS Flavour format always assumes a pre- defined and well-understood interpretation of the QoS information sent over the considered interface, the proxy of the service provider unambiguously knows this mapping. "Silver" is mapped to the correct set of corresponding "QoS parameters" which are then sent to the UAS. A typical example where the proxy of the service provider could decide to use the "QoS class" occurs when there is a need to cross another proxy operated by a different provider (e.g. local access network where UAS is roaming) before reaching the UAS. There is no specific motivation to choose the "QoS class" instead of the "QoS parameters" format besides the fact that the former is a standardized abbreviated way to convey the same information. 6. Security considerations The security considerations for ongoing SDPng specification work also apply to the SDPng QoS extensions proposed in this document. If the contents of the SDPng are private then end-to-end encryption of the message body can be used to prevent unauthorized access to the content. Bos draft-bos-mmusic-sdpng-qos-00.txt 16 SDPng extensions for QoS negotiation September 2002 7. Conclusions This document described a framework to negotiate end-to-end the "Quality" of a multimedia session "as the end-user wants to perceive it". This QoS negotiation is achieved at session signaling. All authorized session control elements, user agents as well as proxies, controlling the multimedia session set-up may participate to the QoS negotiation. Secondly this document proposed two new types of SDPng extensions that allow expressing the QoS level per media stream during the QoS negotiation. The first type of SDPng extensions characterize the traffic type of the bearer associated with the media stream, the second type of SDPng extensions characterize 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. To conclude we summarize the main advantages of the proposed approach. - The SDPng QoS negotiation model can be used in combination with several application protocols (SIP, RTSP, Megaco, BICC,...). It works for roaming as well as non-roaming scenarios. - From a customer point of view, the mechanism enables end-users to negotiate/agree upon QoS at session set-up. The end-user QoS preferences can be specified flexibly as a prioritized list of acceptable QoS levels per media stream. Coupling with the manyfolks SDP extensions enables end-users to make successful establishment of a bearer "with a specific QoS" a precondition for session set-up. All this allows end-users to control QoS and thus their expenses more flexibly. - From the provider point of view, via the participation of proxies in the QoS negotiation, he keeps in control (policy and service control) over the QoS allocated to a certain user, also for media associated with a new codec or with no codec at all (e.g. whiteboard). Having the QoS to be set-up at the transport level first "approved" at session level by end-users, service provider and local access provider enables service providers to deliver a "predictable" QoS level to its customers. This means QoS becomes something a service provider can sell. New attractive subscription packages can be designed with a prize based on different QoS levels reflecting the true "Quality" as experienced by the end- user. Allowing non-standard service provider specific QoS info to be carried in SDPng creates new opportunities for differentiation between service providers as they can all start designing their own QoS Flavours (e.g. Gold/Silver/Bronze service). Finally enabling providers to make more intelligent decisions on QoS provisioning allows improvement of network scalability. 8. Acknowledgements This document is a result of an ongoing discussion among many people from Alcatel and other companies (KPN,...). We would hereby like to Bos draft-bos-mmusic-sdpng-qos-00.txt 17 SDPng extensions for QoS negotiation September 2002 thank all the people who provided valuable comments and input that improved the quality of this document. 9. References [1] Rosenberg J., Schulzrinne H., Handley M., Schooler E., "SIP, Session Initiation Protocol", draft-ietf-sip-rfc2543bis-07.txt, Work in Progress. [2] M. Handley, V. Jacobson, C. Perkins: "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-04.txt, Work in progress. [3] W. Marshall et al. "Integration of Resource Management and SIP", draft-ietf-sip-manyfolks-resource-03.txt, Work in progress. [4] W. Marshall et al. "SIP Extensions for Media Authorization", draft-ietf-sip-call-auth-03.txt, Work in progress. [5] Kutscher, Ott, Bormann and Curcio, "Requirements for Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng- req-01.txt, Work in progress. [6] Kutscher, Ott, Bormann, "Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng-03.txt, Work in progress. [7] Rosenberg J., Schulzrinne H., "An offer/answer model with SDP" draft-rosenberg-mmusic-sdp-offer-answer-00.txt, Work in Progress. [8] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [10] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [12] S. Bradner, "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996 10. Author's Addresses Lieve Bos Alcatel Francis wellesplein 1 Phone: +32 3-241-58-91 2018 Antwerpen, Belgium Email: lieve.bos@alcatel.be Suresh Leroy Alcatel Bos draft-bos-mmusic-sdpng-qos-00.txt 18 SDPng extensions for QoS negotiation September 2002 Francis wellesplein 1 Phone: +32 3-240-85-50 2018 Antwerpen, Belgium Email: suresh.leroy@alcatel.be Jozef Vandenameele Alcatel Francis wellesplein 1 Phone: +32 3-240-43-61 2018 Antwerpen, Belgium Email: jozef.vandenameele@alcatel.be Juan-Carlos Rojas Alcatel Le Mail Phone: +33 2-5178-12-82 44708 Orvault, France Email: juan-carlos.rojas@alcatel.fr Laurent Thiebaut Alcatel 10 Rue Latecoere Phone: +33 1-3077-06-45 78140 Velizy, France Email: laurent.thiebaut@alcatel.fr Pieter Veenstra KPN P.O. Box 30150 Phone: +31 70-343-91-21 2500 GD Den Haag, Netherlands Email: p.k.veenstra@kpn.com Richard Brooks Samsung Electronics Research Institute Phone: +44 7776-18-15-55 Communications House Email: richardbrook39@aol.com South Street TW18 4QE Staines, UK Matt Holdrege Sonus Networks Inc. 223 Ximeno Avenue Phone: +1 562-547-19-22 CA 90803 Long Beach, USA Email: matt@sonusnet.com 11. Full copyright statement Copyright (C) The Internet Society (2000). 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. Bos draft-bos-mmusic-sdpng-qos-00.txt 19 SDPng extensions for QoS negotiation September 2002 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. Bos draft-bos-mmusic-sdpng-qos-00.txt 20