Internet DRAFT - draft-bos-mmusic-sdpqos-framework
draft-bos-mmusic-sdpqos-framework
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]
