MMUSIC working group L. Bos Internet Draft S. Leroy draft-bos-mmusic-sdpqos-framework-00.txt J.-C. Rojas L. Thiebaut J. Vandenameele Alcatel P. Veenstra KPN Expires: May, 2002 November , 2001 A Framework for End-to-End User Perceived 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 [11]. 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 to negotiate end-to-end the "Quality" of a multimedia session "as the end-user wants to perceive it". This UPQoS (User Perceived QoS) negotiation is achieved at session signaling level using two types of new SDP extensions, which this document proposes to specify. All session control elements - user agents as well as proxies - involved in the multimedia session setup may participate to the UPQoS negotiation. Secondly this document proposes to specify SDP extensions which allow to express the UPQoS level per medium stream during the UPQoS negotiation. The first type of SDP extensions characterizes the traffic type of the bearer associated with the medium stream. The second type of SDP extensions characterizes the tolerance/sensitivity level of the service requested by the end-user L. Bos Page [1] Internet Draft Framework UPQoS negotiation November, 2001 with respect to the QoS information carried in the first type of SDP extensions. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Conventions used in this document...............................2 2. Terminology.....................................................2 3. Introduction....................................................5 4. End-to-end UPQoS negotiation: goals and requirements............7 5. QoS information to be transferred in SDP for UPQoS negotiation..8 6. End-to-end user perceived QoS negotiation scenarios............10 6.1. Principles of the end-to-end User Perceived QoS negotiation procedure........................................................10 6.2. Basic versus enhanced QoS offer-answer model................11 6.2.1. Current SDP offer-answer model............................11 6.2.2. Offer-answer model for UPQoS negotiation..................12 6.3. Example scenarios...........................................13 6.3.1. Simple UAC-UAS scenario...................................13 6.3.2. UAC û proxy server û UAS scenario.........................15 6.3.3. SI formats example........................................18 7. Security considerations........................................18 8. Conclusions....................................................19 9. Acknowledgements...............................................19 10. References....................................................19 11. AuthorsÆ Addresses............................................20 12. Full copyright statement......................................21 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 [10]. 2. Terminology The following is a list of terms used with a specific meaning in this document. - User Perceived QoS (UPQoS): "Quality" of a multimedia session "as the end-user wants to perceive it". The UPQoS unambiguously defines per medium stream the level of QoS requested by the end-user at the beginning of the UPQoS negotiation. The UPQoS negotiation is L. Bos Page [2] Internet Draft Framework UPQoS negotiation November, 2001 achieved at session signalling level using two new types of SDP extensions (TI and SI extensions). - Traffic Information (TI): first type of SDP extensions which this document proposes to specify, characterising the traffic type of the bearer associated with the medium stream. Typically TI is related to bandwidth and packet size. - Sensitivity Information (SI): second type of SDP extensions which this document proposes to specify, characterising the tolerance/sensitivity level of the service requested by the end-user with respect to the QoS information carried in TI. Typically SI is related to maximum packet loss ratio, maximum end-to-end delay and maximum end-to-end delay variation. There are three possible ways to entirely describe a given SI level for a given medium stream in a given session: QoS flavour (QF) format, Standard QoS Class (SQC) and Standard QoS parameters (SQP). - Standard QoS Parameters (SQP) format: sets of well-known parameters allowing to precisely describe the SI requested for a given medium stream. - Standard QoS Class (SQC) format: an abbreviated way of sending standardised sets of QoS parameters (SQP) with well-defined values. - QoS Flavour (QF) format: a standardized way of sending service/provider specific non-standard SI data. - 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 - Interface: reference point between two session signaling elements - Roaming: possibility to get access to the network via different local access providers - Session level: session signaling level in the protocol stack, controlling access to multimedia services - Transport level: resource management level in the protocol stack, controlling access to network resources L. Bos Page [3] Internet Draft Framework UPQoS negotiation November, 2001 - Offerer: party initiating the SDP negotiation with an SDP offer towards the answerer - Answerer: party responding to the initial SDP offer with an SDP answer - Requested QoS: Initial ordered list of UPQoS (TI and SI) values proposed by the offerer in the SDP offer - Modified QoS: Intermediate ordered list of acceptable UPQoS levels (TI and SI) possibly restricted by intermediate proxies in the SDP negotiation according to a number of criteria (e.g. end-user subscription, service settings, network congestion situation, any other local policies) - Extended QoS: Ordered list of UPQoS values, possibly extended by the answerer with extra values, used in case of the enhanced offer- answer model. - Negotiated QoS: Final ordered list of UPQoS values (TI and SI) resulting from the SDP negotiation between all involved session control elements end-to-end. The following list of definitions coming from [1] is also used in this document. - User agent client (UAC): A user agent client is a logical entity that initiates a SIP transaction with a request. This role lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that request. If it receives a request later on, it takes on the role of a User Agent Server for the processing of that transaction. - User agent server (UAS): A user agent server is a logical entity that responds to a SIP request, generally acting on behalf of some user. The response accepts, rejects or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that request. If it generates a request later on, it takes on the role of a User Agent Client for the processing of that transaction. - User agent (UA): A logical entity that acts as both a user agent client and user agent server for the duration of a call. - Session: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. A callee can be invited several times, by different calls, to the same session. L. Bos Page [4] Internet Draft Framework UPQoS negotiation November, 2001 - Call: A call consists of all participants in a session invited by a common source. A SIP call is created when a user agent sends an INVITE request. This INVITE request may generate multiple acceptances, each of which is part of the same call (but different call legs). Furthermore, if a user is invited to the same multicast session by several people, each of these invitations will be a unique call. In a multiparty conference unit (MCU) based call-in conference, each participant uses a separate call to invite himself to the MCU. - (SIP) transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. A transaction is identified by the CSeq sequence number within a single call leg. The ACK request has the same CSeq number as the corresponding INVITE request, but comprises a transaction of its own. 3. Introduction The Session Initiation Protocol, SIP [1] 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 session descriptions, which allow participants to agree on a set of compatible media types. The session description, commonly formatted in SDP [2], is intended to be a well-defined format for conveying sufficient information to discover and participate in a multimedia session. 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 the provisioning of end-to-end Quality of Service for high-quality IP telephony and multimedia services. [3] describes SDP extensions which express preconditions for individual media streams that require network QoS and security associations to be established before continuing with the session setup. [4] describes SIP extensions for media authorization which enable the correlation between the resources authorized by the call/session signaling architecture and the actual network resources requested by the UA at bearer setup. [5] demonstrates that there is a requirement from the IETF Multiparty Multimedia Session Control (MMUSIC) working group to specify additional QoS parameters for SDPng. In essence these recent proposals have recognised the need to enhance the co-ordination between the session signalling layer, which controls access to multimedia specific services, and the resource management layer, which controls access to network resources. However there is currently no mechanism defined to L. Bos Page [5] Internet Draft Framework UPQoS negotiation November, 2001 specify at session control level the QoS requirements that reflect the true end-user expectations. Since the purpose of the SDP [2] protocol is to carry the actual session and media stream description, extensions to SDP seem the natural way to carry this information. The final goal of a true end-to-end QoS provisioning architecture is to deliver the end-user a QoS for each medium stream that corresponds exactly to the level of "quality" he wishes to perceive/experience, called User Perceived QoS (UPQoS) hereafter. An end-user should have the possibility to request a different "quality" for a medium stream based on for instance the destination, expected duration of the session, pricing,... The best quality could be preferred for an important session, while the lowest could be chosen when the end-user knows by advance that the session will be quite long, or not very important, etc. The differentiation could also be requested by the service provider in order to take into account the specificity of the service, the time of day/week, the destination, etc. The flexibility to offer QoS based on different levels of perceived end-user quality creates more opportunities for differentiation between operators. Firstly, this document proposes a framework for end-to-end User Perceived QoS (UPQoS) negotiation involving all session control elements between the UAC and UAS. Secondly this document proposes to specify two types of SDP extensions needed to express the UPQoS per medium stream during the UPQoS negotiation. The first type of SDP extensions characterise the traffic type of the bearer associated with the medium stream, the second type of SDP extensions characterise the tolerance/sensitivity level of the service requested by the end-user with respect to the QoS information carried in the first type of SDP extensions. The document also shows the advantages of this approach: - Allows end-users to express to the network per medium stream the "Quality" as they want to perceive it. - Increases end-user flexibility to control his expenses and QoS. - Allows the service provider to develop new charging mechanisms for QoS enabled sessions based on the "Quality" as experienced by the end-user. - Allows local access network in case of network congestion to downgrade the QoS of users (e.g. release calls or re-route calls) respecting the service settings/subscription profile agreed between end-user and service provider. - Enables providers to make more intelligent decisions on QoS provisioning that can help them to improve the network scalability. - Facilitates the introduction of new codec types. - Etc. This document does not describe a way to carry bearer setup messages into SIP/SDP. Since in an IP network session signalling messages L. Bos Page [6] Internet Draft Framework UPQoS negotiation November, 2001 (e.g. SIP/SDP) usually follow another route than the bearer setup messages, such a proposal indeed would make no sense. Instead, this document provides a way for the end-user to express to the network the "Quality" he expects, and a way for the network to check at session control level whether an acceptable level of QoS for each medium stream of the requested multimedia session can be set up in accordance with e.g. the user's subscription profile, service settings, policies in the local access,.... Currently SDP does not carry sufficient information allowing SIP- proxies to unambiguously authorise, in line with [4], the complete set of QoS parameters needed for bearer set-up with a "Quality" satisfying the user's expectations. The SDP extensions that this document proposes to specify are a way to make sure that existing bearer setup mechanisms (e.g. RSVP, Diffserv, MPLS) are getting the correct and complete input, that enables them to reserve the resources with a Quality of Service that matches exactly the end- user expectations. [5] demonstrates that there is a requirement from the IETF Multiparty Multimedia Session Control (MMUSIC) working group to specify additional QoS parameters for SDPng. This document proposes to specify QoS extensions to SDP, as this is the current standard. Similar extensions to SDPng are however not precluded. This document is organised as follows. Section 4 lists the requirements and goals of the mechanisms used for User Perceived QoS (UPQoS) negotiation. Section 5 introduces the meaning of the two types of SDP extensions that this document proposes to specify. Section 6 explains a number of end-to-end UPQoS negotiation scenarios. 4. End-to-end UPQoS negotiation: goals and requirements This section describes the goals and requirements of the proposed solution to provide end-to-end User Perceived Quality of Service (UPQoS) negotiation. - Independence of session signalling protocol. This document proposes to specify extensions to the session description protocol SDP, not to any session signalling protocol (e.g. SIP, BICC,...). - UPQoS negotiation (session level) complementary to existing bearer setup mechanisms (transport level). This document does not propose a way to carry bearer setup messages in SIP/SDP. Instead the UPQoS negotiation complements existing bearer setup mechanisms (e.g. RSVP [7], Diffserv [8], MPLS [9]) by providing them correct and complete information for setting up a bearer matching exactly end-userÆs expectations. This document does not describe new mechanisms to enforce synchronisation between the L. Bos Page [7] Internet Draft Framework UPQoS negotiation November, 2001 QoS negotiated at session level and the QoS actually requested at bearer setup. That requirement is already covered by [4]. This document is complementary in this respect to [4]. - Need for an "end-to-end" UPQoS negotiation at session/service level. To guarantee the end-to-end character of the negotiated UPQoS, session control elements of all involved parties in the session signalling path (local access network, service provider, end-user) shall be able to participate in the negotiation process. - UPQoS negotiation per medium stream. In order to ensure a maximum of flexibility, the end-to-end UPQoS negotiation framework shall allow UPQoS negotiation for each medium stream of a given multimedia session. It shall be possible for the end-user to specify per medium stream a range of acceptable UPQoS levels in decreasing order of preference. - Successful establishment of media streams. An end-user shall be able to specify for each medium stream whether successful establishment of a bearer "with a specific QoS" is required. That requirement is already covered by [3]. This document is complementary in this respect to [3]. - Validity for roaming and non-roaming situations. End-to-end UPQoS negotiation shall be possible both for roaming and non-roaming scenarios. - Standard Mechanism to carry standard and non-standard information. For interoperability reasons, a minimum set of QoS information to be carried in the SDP extensions must be standardised. On the other hand in some cases two involved session signalling elements may need to transfer QoS information that is service/provider specific and can therefore not be standardised. Therefore the SDP extensions shall provide a standardised way to send standardised and specific non-standard QoS information. Session control elements shall be allowed to represent the QoS information for a given session in a flexible way depending on the nature of the interface the QoS information is crossing. - Relationship with codec information in SDP End-to-end UPQoS negotiation also works in situations where some medium streams are not associated with codecs (e.g. white board) as well as situations where the intermediate session control entities do not have any a priori knowledge of the codec being used (e.g. use of new codecs). 5. QoS information to be transferred in SDP for UPQoS negotiation L. Bos Page [8] Internet Draft Framework UPQoS negotiation November, 2001 The User Perceived QoS (UPQoS) is defined as the "Quality" of a multimedia session "as the end-user wants to perceive it". This UPQoS level is requested by the end-user at session setup and negotiated end-to-end at session signalling level. This document proposes to specify two types of SDP extensions to express the UPQoS per medium stream during the UPQoS negotiation. The first type of QoS SDP extensions, hereafter called Traffic Information (TI), characterise the traffic type of the bearer associated with the medium stream. Typically TI is related to bandwidth and packet size. There are situations where some medium streams are not associated with codecs (e.g. white board) or situations where the intermediate session control entities do not have any a priori knowledge of the codec being used (e.g. use of new codecs). Carrying TI per media stream via SDP still provides intermediate session control entities (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 bearer level requirement (TI) of this codec. This facilitates the introduction of new codec types. The second type of QoS SDP extensions, hereafter called Sensitivity Information (SI), characterise the tolerance/sensitivity of the service with respect to the QoS information carried in TI. Typically SI is characterised by maximum packet loss ratio, maximum end-to-end delay and maximum end-to-end delay variation. For a certain bearer defined by the TI the SI unambiguously determines the quality "as the end-user wants to perceive it". There are three possible representation formats which can be used to unambiguously describe a given SI level for a given medium stream in a given session: QoS flavour (QF) format, Standard QoS Class (SQC) and Standard QoS parameters (SQP). - The Standard QoS Parameters (SQP) format The Standard QoS Parameters (SQP) are a set of well-known parameters allowing to precisely describe for a given medium stream the tolerance/sensitivity (SI) requirement. The Standard QoS Parameters are maximum packet loss ratio, maximum end-to- end delay and maximum end-to-end delay variation. - The Standard QoS Class (SQC) format A standardised QoS class (SQC) is an abbreviated way of sending standardised sets of QoS parameters (SQP) with well-defined values. A SQC can be directly and unambiguously translated to a pre-defined set of SQP. An example for audio could be a SQC for "PSTN type voice qualityö. SQC values must be defined by an internationally recognised standards body. - The QoS Flavour (QF) format The QoS flavour (QF) is a standardised way of sending specific non-standard information describing the tolerance/sensivity L. Bos Page [9] Internet Draft Framework UPQoS negotiation November, 2001 (SI) requirement. The QF format is used in cases where two involved session control elements would like to exchange non- standard (e.g. service/provider specific) QoS information. The usage of the QF type is always assuming a pre-defined and well- understood interpretation of the QoS information sent over the considered interface. Therefore, the list of possible values to be exchanged on a given interface has to be previously defined by a common agreement between the involved parties. The QF can take values representing information like "Gold", "Silver", "Bronze",etc. In order to ensure a maximum of flexibility, the end-to-end UPQoS negotiation framework allows UPQoS negotiation for each medium stream of a given multimedia session. Therefore the SDP extensions allow to carry the Traffic Information and Sensitivity Information (expressed in SQP, SQC or QF format as explained above) per medium stream of a given multimedia session. The possibility exists for the end-user (or some default settings or application running on the end-user terminal) to specify per medium stream an ordered set of acceptable levels of User Perceived QoS. Per TI a list of SI levels is possible. A decreasing order of preference is used to represent the set of acceptable UPQOS (TI with corresponding SI) values in SDP. This allows for prioritisation during negotiation. A session control element can use different forms 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 standardised form (Standard QoS parameters or Standard QoS Class) on the interface with a network operator. The service provider is assumed to perform the correct translation between the different representation forms. 6. End-to-end user perceived QoS negotiation scenarios The purpose of this section is to explain the end-to-end User Perceived QoS (UPQoS) negotiation procedure and to provide some example scenarios describing the SDP negotiation of UPQoS values. The general principles behind the end-to-end UPQoS negotiation procedure are explained in section 6.1. Section 6.2 shows that the SDP negotiation of UPQoS values can be modelled by a basic or enhanced QoS offer-answer model. Section 6.3 finally illustrates the UPQoS negotiation procedure with example scenarios covering both roaming and non-roaming cases. 6.1. Principles of the end-to-end User Perceived QoS negotiation procedure L. Bos Page [10] Internet Draft Framework UPQoS negotiation November, 2001 Introducing the flexibility to choose a different UPQoS per session for the same type of communication requires the User Perceived QoS (UPQoS), expressed as an ordered set of TI and SI values, to be negotiated end-to-end at the session signalling level during the session establishment. To guarantee the end-to-end character of the negotiated TI and SI values, session control elements of all involved parties in the session signalling path (local access network, service provider, end-user) shall be able to participate in the negotiation process. There is only one UPQoS negotiation procedure per SIP transaction for both sending and receiving directions, but UPQoS requirements (expressed as an ordered set of TI and SI values) can be different in the sending and receiving direction. It is important to note that the negotiation flows shown in the following sections are using the SIP protocol as an example only. The entire framework for end-to-end "User Perceived QoS" negotiation and the associated SDP extensions which this document proposes to specify, are independent of the session signalling protocol being used. The same procedures can therefore also be used in the context of e.g. BICC, MEGACO/H.248,... 6.2. Basic versus enhanced QoS offer-answer model This draft uses a number of terms as defined in [1] which refer to 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 modelled 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. 6.2.1. Current SDP offer-answer model As described in [6], the usage of SDP within SIP follows an "offer- answer" model. SDP negotiation within SIP can be modelled as follows: 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 [6] the "offer-answer model" may occur in two ways, which are referred to as the "basic" and "enhanced" model for the rest of this document: - Basic offer-answer model The offerer offers an SDP. The answerer is only allowed to reject or to restrict the offer. In the latter case, the answer L. Bos Page [11] Internet Draft Framework UPQoS negotiation November, 2001 contains an SDP that is a sub-set of the original SDP proposed by the offerer (the number of "m=" lines remains the same). - Enhanced offer-answer model The offerer offers an SDP. The answerer MAY extend the offer with additional elements or capabilities not listed in the original SDP offer. In this case the answer contains an SDP that is a super-set of the original SDP proposed by the offerer (even when the number of "m=" lines remains the same). A common example of the Basic offer-answer model is where a UAC offers an SDP, containing a list of codecs the UAC is willing to use, in a SIP INVITE. The UAS answers with a SIP 200-OK (this could equally be a SIP 183-session-progress) containing a sub-set of the SDP offered by the UAC, containing only those codecs that the UAS is willing to use for this particular SIP transaction. A common example of the enhanced offer-answer model is where the UAS answers with a SIP 200-OK (this could equally be a SIP-183-session- progress) containing additional codecs, not listed in the corresponding stream in the offer, that the UAS is willing to use for this particular SIP transaction. In both cases, the final result of the offer-answer model is a list of codecs for a given medium stream; any of those codecs can be freely used during the session without sending a SIP message. 6.2.2. Offer-answer model for UPQoS negotiation This document proposes to reuse the basic and enhanced offer-answer model of [6] for negotiating lists of UPQoS values. The offerer determines per medium stream a set of acceptable UPQoS levels, expressed in SDP as an ordered set of TI and SI values. The list of acceptable UPQoS values, called "Requested QoS", is carried in the SDP offer in one of three formats, as described in section 5, and in decreasing order of importance, to allow prioritisation during negotiation. +---------+ Requested QoS +----------+ | |--------------------->| | | offerer | Negotiated QoS | Answerer | | |<---------------------| | +---------+ +----------+ Basic offer-answer model +---------+ Requested QoS +----------+ | |--------------------->| | | | Extended QoS | | | offerer |<---------------------| Answerer | L. Bos Page [12] Internet Draft Framework UPQoS negotiation November, 2001 | | Negotiated QoS | | | |--------------------->| | +---------+ +----------+ Enhanced offer-answer model Figure 1: Basic versus Enhanced QoS offer-answer model In the basic offer-answer model (see top of Error! Reference source not found.) the answerer is only allowed to reject or to restrict the "Requested QoS". The SDP answer contains a "Negotiated QoS", that is, a sub-set of the original "Requested QoS". In the enhanced offer-answer model (see bottom of Error! Reference source not found.) the answerer MAY extend the "Requested QoS" with additional QoS levels not listed in the original "Requested QoS". In this case, the SDP answer contains an "Extended QoS", that is, a super-set of the original "Requested QoS" proposed by the offerer. To conclude the enhanced offer-answer model, 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 offer-answer model is the "Negotiated QoS", which is a decreasing ordered list of UPQoS (TI and SI) values per medium stream retained for the session. Any of those negotiated TI/SI combinations can be freely used during the session without sending a SIP message. 6.3. Example scenarios This section shows how the basic offer-answer model can be used for SDP negotiation of UPQoS values in different scenarios. 6.3.1. Simple UAC-UAS scenario A simple example (Error! Reference source not found.) is a UAC trying to set up a SIP transaction with a UAS. The QoS offer-answer model allows the UAC to specify per medium stream a "Requested QoS". The "Requested QoS" consists of a decreasing set of UPQoS levels, expressed an ordered list of TI and SI values, acceptable to the UAC. Suppose for this example that the "Requested QoS" specifies acceptable UPQoS levels A,B and C for audio and acceptable UPQoS levels D and E for video. The "Requested QoS" is carried in the SDP description included in the SIP INVITE, using for SI one of the three formats described in section 5. Upon evaluation of the preference list of UPQoS values in the "Requested QoS", the UAS can restrict the "Requested QoS". The UAS SHOULD use the UPQoS value with the highest preference that is acceptable to it. L. Bos Page [13] Internet Draft Framework UPQoS negotiation November, 2001 Consequently the SIP 200-OK sent back to the UAC contains an SDP carrying the "Negotiated QoS", that is, a sub-set of the original "Requested QoS" containing only those UPQoS values that the UAS is willing to use for this particular SIP transaction. Suppose for this example that the "Negotiated QoS" specifies UPQoS levels A and B for audio and UPQoS level E for video. This means that the UAS is not willing for this particular session, to support the lowest QoS level C for audio nor the highest QoS level D for video. The "Negotiated QoS" is equal to the "Requested QoS" in case the UAS accepts to support all the UPQoS 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 Error! Reference source not found. the SIP ACK sent back from UAC to UAS is shown for completeness even though it MUST not contain any SDP in this example (as currently described in [1]). +-----+ SIP INVITE, SDP æRequested QoSÆ +- ---+ | |------------------------------------------>| | | | SIP 200-OK or SIP 18-session-progress | | | UAC | SDP æNegotiated QoSÆ | UAS | | |<------------------------------------------| | | | ACK or PRACK | | | |------------------------------------------>| | +-----+ +-----+ Figure 2: Simple UAC û UAS scenario An end-user should be able to specify for each medium 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 "qos" SDP extensions of [3] with the SDP extensions for UPQoS identified in this document. According to [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 Error! Reference source not found. by a SIP 183-session-progress and the SIP ACK by a SIP PRACK. The "qos" attribute indicates whether end-to-end resource reservation is optional or mandatory, and in which direction (send, recv, or sendrecv). When the "qos" attribute indicates mandatory, this means that the participant who has received the SDP does not proceed session setup until resource reservation has been completed in the specified direction. This document builds further upon the concept of [3] in the following way. If the "qos" attribute is set to mandatory, the UPQoS SDP 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 L. Bos Page [14] Internet Draft Framework UPQoS negotiation November, 2001 Service compliant with the set of acceptable UPQoS values carried in the SDP extensions proposed in this document. If the "qos" attribute is set to optional, the UPQoS (TI and SI) SDP 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. Coming back to the example with the lists of UPQoS values for "Requested QoS" and "Negotiated QoS" mentioned earlier, suppose the UAC had specified that reservation of resources for the audio component (with acceptable UPQoS levels A,B and C) was optional in the receiving direction whereas reservation of resources for the video component (with acceptable UPQoS 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 but it will accept the medium stream in the worst case even with no QoS guarantees (best effort). As the "Negotiated QoS" in this example did contain the UPQoS 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 UPQoS values for the audio component), the UAC would still accept the session even with best effort quality of service for the audio. 6.3.2. UAC û proxy server û UAS scenario According to [1], SIP requests can be sent directly from a UAC to a UAS (QoS offer-answer model for this case was explained in previous section), or they can traverse one or more proxy servers along the way. It is also clearly stated in [1] that proxies MAY modify any part of the SIP message that are not integrity-protected, except those needed to identify call legs. Furthermore proxies generally do not modify the session description, but MAY do so. 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, although typically only the first request within a call traverses all proxies while subsequent requests are exchanged directly between user agents. L. Bos Page [15] Internet Draft Framework UPQoS negotiation November, 2001 +-----+ +--------+ +-----+ | | SIP INVITE | | SIP INVITE | | | | SDP æRequested QoSÆ | | SDP æModified QoSÆ | | | |--------------------->| |--------------------->| | | UAC | SIP 200-OK or | proxy | SIP 200-OK or | UAS | | | SIP 183 | SIP | SIP 183 | | | | SDP ÆNegotiated QoSÆ | server | SDP æNegotiated QoSÆ | | | |<---------------------| |<---------------------| | | | ACK or PRACK | | ACK or PRACK | | | |--------------------->| |--------------------->| | +-----+ +--------+ +-----+ Figure 3: UAC û proxy server û UAS scenario From the statements above, quoted from [1], we can derive the following implications on the QoS offer-answer model. Firstly the simple UAC-UAS model does not suffice, as one or more proxy servers can be in between UAC and UAS (Error! Reference source not found.). Also it is possible that different proxies are operated by different providers; e.g. a first proxy in the local access network, a second proxy operated by the userÆs Internet service provider. Furthermore, proxies may decide to forward the SIP request or modify the SDP based on local policies and information contained in the SIP request. Considering the example in Error! Reference source not found., the impact of intermediate proxy servers on the QoS offer-answer model can be modelled in the following way. 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 UPQoS values resulting in the "Negotiated QoS". Thus, the "Negotiated QoS" will be equal to the "Requested QoS" only if the "Requested QoS" was compliant with the subscriber profile with service settings, not conflicting with local network policies and acceptable to the UAS. Assuming a basic offer-answer model in the example of Error! Reference source not found., 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, applications in terminal, access type,etc.), or from subscription or service information (the userÆs service provider can propose L. Bos Page [16] Internet Draft Framework UPQoS negotiation November, 2001 subscription packages with different levels of QoS for the different medium streams involved in a communication service). Note that on the response path this "Negotiated QoS" is distributed (in a SIP 200-0K or SIP 183-session-progress) to all involved session control elements all the way from UAS to 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 medium 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 signalling architecture and the actual network resources requested by the UA at bearer setup. It is important to understand also that this document does not describe a way to carry bearer setup messages into SIP/SDP. The SDP extensions that this document proposes to specify, are a way to make sure that existing bearer setup mechanisms (e.g. RSVP, Diffserv, MPLS) are getting the correct and complete input, enabling them to reserve the resources with a Quality of Service that matches exactly the end-user expectations. After all parties (end-user, local access network, service provider) involved in the session signalling have agreed upon the UPQoS values, appropriate resources have to be reserved 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 bearer setup mechanisms (e.g. RSVP, Diffserv). Involvement of proxies from the local access network and the end- userÆs service provider domain in the QoS offer-answer model brings strong advantages for delivering end-to-end QoS guarantees, especially in situations of local network overload. The participation of a proxy from the end-userÆs service provider domain in the QoS offer-answer model ensures that the "Negotiated QoS" is compliant with the QoS limits specified in the userÆs subscription profile and service settings. Communicating this "Negotiated QoS" on the response path to a proxy in the local access network (where the user is actually located), is effectively creates awareness in the local access network about user specific subscription/service information; namely the QoS limits for each medium stream of the session that are allowed by the service provider of that particular end-user. Suppose that after SDP negotiation, when the actual session is ongoing and media streams are being transferred between UAC and UAS, suddenly a situation of network congestion occurs in that segment of the local access network where the end-user is located. Then this document enables the local access network to take more intelligent L. Bos Page [17] Internet Draft Framework UPQoS negotiation November, 2001 decisions than just downgrading the QoS of the end-user arbitrarily. Indeed, by respecting the QoS limits specified in the "Negotiated QoS" information when downgrading the QoS for this particular end- user, the local access network is in fact ensuring that the end-user will still experience the QoS delivered to him as compliant with the Quality promised to him in the subscription. As such, the QoS offer- answer model enables service providers to sell attractive subscription packages with guarantees on true "end-to-end" Quality of Service, even in roaming conditions and even under circumstances of local network overload. 6.3.3. SI formats example To illustrate the use of the three possible formats which can be used to express the SI requirements in SQP, SQC or QF format, as explained in section 5, a practical example based on Error! Reference source not found. is given in this section. 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 UPQoS/SI values 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 Internet 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-standardized "QoS flavour" representation form into one of the standardized formats "Standard QoS class" or "Standard 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 unambiguously knows this mapping. "Silver" is mapped to the correct set of corresponding "Standard QoS parameters" which are then sent to the UAS. A typical example where the first proxy could decide to use the "Standard QoS class" occurs when there is a need to cross another proxy operated by a different provider before reaching the UAS. There is no specific motivation to choose the "Standard QoS class" instead of the "Standard QoS parameters" format besides the fact that the former is an abbreviated way to convey similar type of standardized information. 7. Security considerations L. Bos Page [18] Internet Draft Framework UPQoS negotiation November, 2001 There is no foreseen specific security issue associated with the framework proposed by this document. The UPQoS negotiation framework is not intended to solve any security issue. 8. 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 UPQoS (User Perceived QoS) negotiation is achieved at session signalling level using two types of new SDP extensions, which this document proposes to specify. All session control elements - user agents as well as proxies - involved in the multimedia session setup may participate to the UPQoS negotiation. Secondly this document proposed to specify SDP extensions that allow to express the UPQoS level per medium stream during the UPQoS negotiation. The first type of SDP extensions characterise the traffic type of the bearer associated with the medium stream, the second type of SDP extensions characterise the tolerance/sensitivity level of the service requested by the end-user with respect to the QoS information carried in the first type of SDP extensions. To conclude we summarise the main advantages of the end-to-end User Perceived QoS negotiation framework as proposed by this document. First of all it allows end-users to express to the network per medium stream the "Quality" as they want to perceive it. End-users can control their expenses and QoS more flexibly. Service providers can develop new charging mechanisms for QoS enabled sessions based on the true "Quality" of the session as experienced by the end-user. Service providers can sell more attractive subscription packages with guarantees on true "end-to-end" Quality of Service limits, even in roaming conditions and even under circumstances of local network overload. Enabling providers to make more intelligent decisions on QoS provisioning allows improvement of network scalability. The introduction of new codec types is simplified. 9. Acknowledgements This document is a result of an ongoing discussion among many people from Alcatel and other companies (KPN,...). 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. 10. References [1] Rosenberg J., Schulzrinne H., Handley M., Schooler E., "SIP, Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt, Work in Progress. L. Bos Page [19] Internet Draft Framework UPQoS negotiation November, 2001 [2] M. Handley, V. Jacobson, C. Perkins: "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-03.txt, Work in progress. [3] W. Marshall et al. "Integration of Resource Management and SIP", draft-ietf-sip-manyfolks-resource-02.txt, Work in progress. [4] W. Marshall et al. "SIP Extensions for Media Authorization", draft-ietf-sip-call-auth-02.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] Rosenberg J., Schulzrinne H., "An offer/answer model with SDP" draft-rosenberg-mmusic-sdp-offer-answer-00.txt, Work in Progress. [7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [8] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [9] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [10] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [11] S. Bradner, "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996 11. AuthorsÆ Addresses Lieve Bos Alcatel Francis Wellesplein 1 2018 Antwerpen Belgium Phone: +32 3 241 58 91 EMail: Lieve.Bos@Alcatel.be Suresh Leroy Alcatel Francis Wellesplein 1 2018 Antwerpen Belgium Phone: +32 3 240 85 50 EMail: Suresh.Leroy@Alcatel.be L. Bos Page [20] Internet Draft Framework UPQoS negotiation November, 2001 Jozef Vandenameele Alcatel Francis Wellesplein 1 2018 Antwerpen Belgium Phone: +32 3 240 4361 EMail: Jozef.Vandenameele@Alcatel.be Juan-Carlos Rojas Alcatel CIT Le Mail 44708 Orvault Cedex France Phone: +33 2 5178 1282 E-mail: Juan-Carlos.Rojas@Alcatel.fr Laurent Thiebaut Alcatel CIT 10 Rue Latecoere 78140 Velizy France Phone: +33 1 3077 0645 E-mail: Laurent.Thiebaut@Alcatel.fr Pieter Veenstra KPN P.O. Box 30150 2500 GD Den Haag, Netherlands Phone: +31 70 3439121 Email: p.k.veenstra@kpn.com 12. 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. L. Bos Page [21] Internet Draft Framework UPQoS negotiation November, 2001 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. Expires May, 2002 L. Bos Page [22]