Internet DRAFT - draft-bos-mmusic-sdpng-qos
draft-bos-mmusic-sdpng-qos
MMUSIC working group L. Bos
Internet Draft S. Leroy
Document: draft-bos-mmusic-sdpng-qos-00.txt J-C Rojas
Expires: September 2002 L. Thiebaut
J. Vandenameele
Alcatel
P.Veenstra
KPN
R. Brook
Samsung
Electronics
M. Holdrege
Sonus Networks
Inc.
SDPng extensions for Quality of service negotiation
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a framework that allows end-
users/applications to inform each other and negotiate about the QoS
characteristics of the media components in a session, prior to its
establishment. The QoS negotiation is modeled after the existing
codec negotiation and as such becomes an integral part of the
existing SDPng Offer/Answer model. The QoS information is exchanged
at session set-up time using two new types of SDPng extensions
between the end-users sites. Apart from the end hosts also some
Bos draft-bos-mmusic-sdpng-qos-00.txt 1
SDPng extensions for QoS negotiation September 2002
authorized intermediate proxies controlling the session set-up MAY
participate to the QoS negotiation.
Secondly this document proposes SDPng extensions which allow the
end-user to request an ordered list of preferred QoS levels per
media stream during the QoS negotiation. The first type of
extensions, called TI (Traffic Information), characterizes the
traffic type of the bearer associated with the media stream. TI is
typically related to bandwidth and packet size. The second type of
extensions, called SI (Sensitivity Information), characterizes the
sensitivity level of the service requested by the end-user with
respect to the QoS information carried in the first type of SDPng
extensions. SI is typically related to delay, jitter and packet
loss.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Conventions used in this document...............................3
2. Introduction....................................................3
3. Terminology.....................................................5
4. QoS information to be carried in SDPng..........................6
4.1. First SDPng extension: TI (Traffic Information)...............6
4.2. Second SDPng extension: SI (Sensitivity Information)..........7
4.3. Encoding of QoS extensions in SDPng...........................8
4.3.1. QoS Parameter format........................................8
4.3.2. The QoS Class format........................................9
4.3.3. The QoS Flavour format......................................9
5. QoS negotiation procedure......................................10
5.1. Principles of the QoS negotiation procedure..................10
5.2. Offer/Answer versus Offer/Counter-Offer/Answer model for QoS
negotiation.......................................................10
5.2.1. Current SDP codec negotiation..............................10
5.2.2. Proposed SDPng QoS negotiation.............................11
5.2.2.1 Simple UAC-UAS scenario...................................12
5.2.2.2. UAC-Proxy Server-UAS scenario............................12
5.3. Relationship with transport level QoS provisioning...........14
5.4. QoS preconditions - Coupling with manyfolks..................14
5.5. Scenario examples............................................15
5.5.1. Example 1: Simple UAC-UAS scenario.........................15
5.5.2. Example 2: UAC-Proxy Server-UAS scenario...................16
6. Security considerations........................................16
7. Conclusions....................................................17
8. Acknowledgements...............................................17
9. References.....................................................18
10. Author's Addresses............................................18
11. Full copyright statement......................................19
Bos draft-bos-mmusic-sdpng-qos-00.txt 2
SDPng extensions for QoS negotiation September 2002
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [11].
2. Introduction
There is a whole range of applications that requires a phase of
session/application level signaling before setting up network-layer
resources/QoS. Examples are Internet telephony calls, multimedia
conferencing (e.g. created via SIP), broadcast scenarios (e.g.
announced via SAP), streaming applications (e.g. controlled via
RTSP), etc. Typically the application level signaling messages used
to create or modify those types of sessions carry session
descriptions, which allow participants to exchange end-system
capabilities and agree on a set of compatible media types. The
session description, commonly formatted in SDP [2] or in the future
in SDPng [6], is a well-defined format for conveying sufficient
information to discover and participate in the session.
Some applications (e.g. Internet phone calls, ad-hoc multiparty
conferencing) require a dynamic exchange of the session description
to allow participants to exchange end-system capabilities and
negotiate/agree on a set of compatible media types. Other
applications (e.g. loosely coupled conferences or broadcast
scenarios) don't require a negotiation phase. For example via SAP a
previously created (and typically fixed) session description can be
disseminated to a potentially large audience. Only the interested
members of the audience that support all the parameters specified by
the session description contained in SAP, will join the announced
session.
The same SDPng QoS extensions can be used both for applications that
require negotiation (e.g. SIP, BICC) or dissemination (e.g. SAP,
RTSP) of the session description. As the dissemination case can be
seen as a simplified one-way negotiation, the rest of this document
will focus on the SDPng QoS negotiation procedure. The SIP protocol
is used as example.
Although SIP [1] and SDP [2] offer an attractive set of mechanisms
for multimedia session control and description, several IETF drafts
have already shown the need for extensions to these protocols,
especially for provisioning end-to-end Quality of Service for high-
quality IP telephony and multimedia services. In essence these
recent proposals have recognized the need to enhance the co-
ordination between the session signaling layer, which controls
access to multimedia specific services, and the resource management
layer, which controls access to network resources.
[4] describes SIP extensions for media authorization for correlating
the resources authorized by the session signaling architecture with
Bos draft-bos-mmusic-sdpng-qos-00.txt 3
SDPng extensions for QoS negotiation September 2002
the actual network resources requested by the UA for the media
components. Manyfolks [3] describes SDP extensions that allow end-
users to check before continuing with the session set-up if
establishing network QoS or security associations was successful for
the individual media streams.
But the manyfolks SDP extensions/preconditions don't allow
expressing which level of network QoS is required. Currently simply
no mechanism exists to specify at session control level per media
stream the QoS requirements that reflect the true end-user
expectations.
Since the purpose of the SDP[2]/SDPng[6] protocol is to carry the
actual session and media stream description, extensions to this
protocol seem the natural way to carry this QoS information. In this
way all applications using the SDPng session description (e.g. SIP,
BICC, SAP, RTSP, MEGACO, ą) can benefit from the same QoS
extensions. The need to add QoS information to SDPng has already
been recognized in the SDPng requirements draft [4] and the SDPng
draft on requirements for session description and capability
negotiation [5].
This document makes a specific proposal for those additional QoS
information fields in SDPng. However for backward compatibility with
the current SDP version and timely market introduction of the
proposed QoS extensions together with the manyfolks extensions, the
authors believe that similar QoS extensions to SDP would be most
useful.
The final goal of the true and-to-end QoS provisioning architecture
is to deliver the end-user for each media stream a QoS that
corresponds exactly to the level of "Quality" he wishes to
experience. Currently however we are still far from this goal.
Network operators or service providers may want their SIP proxies to
be able to "screen" SIP/SDP messages (e.g. to enforce local QoS
policy control or to check the user's QoS subscription profile). But
unfortunately the QoS the user really wants can not be derived
accurately from the codec and the optional b parameter in SDP. Even
if SIP proxies of local access/service provider force themselves in
the SIP signaling path (e.g. Record Route), today they can not fully
control the QoS requirements associated with all session set-ups.
This because some media simply are not associated with a codec (e.g.
white board) or are associated with a codec the proxy doesnĘt know
(e.g. new applications). Since today end-users can not
negotiate/reach a QoS agreement at session set-up, there is no way
to ensure that in both access networks the end-users will initiate a
bearer set-up request with the same QoS. Therefore it is impossible
for service providers to deliver "predictable end-to-end QoS" to
their customers. And thus they can not really charge for QoS today.
All these problems are solved with the proposed solution of QoS
negotiation via SDPng extensions.
Service providers ideally would like to sell QoS packages (e.g.
Gold/Silver quality). Before starting to watch a movie for example,
Bos draft-bos-mmusic-sdpng-qos-00.txt 4
SDPng extensions for QoS negotiation September 2002
an end-user may want to choose between different qualities and
prices. The business model for long distance calls is already
proven. Some telephony networks already offer users the choice
between the traditional phone connection and the IP-based one, where
the latter is cheaper but of worse quality. It is reasonable to
assume that users may also be willing to pay for a differentiation
in quality based on other parameters like destination
(business/private call), expected duration of the session, etc.
Service providers might also want to adapt the QoS based on other
parameters (e.g. time of day/week, busy/non busy hour, destination,
service settings). The proposed solution even creates further room
for differentiation between service providers by allowing them to
define their own QoS levels/packages.
The proposal enables end-users to express to the network and to
negotiate with each other the "Quality" they find acceptable for
each media stream of the requested multimedia session. It also
provides a way for the network to check at session control level
whether the QoS levels acceptable to both end-users are compliant
with e.g. the users' subscription profile, service settings,
policies in the local access,... .
It is important to understand also that this document does not
describe a way to use SIP/SDPng messages for QoS provisioning. The
SDPng QoS negotiation occurs independently of and prior to the QoS
provisioning itself (e.g. RSVP [8], MPLS [10]).
This document is organized as follows. Section 3 provides a
definition list. Section 4 introduces the two new types of SDPng
extensions. Section 5 explains the QoS negotiation procedure and
gives some examples scenarios. Section 6 covers the security
considerations. Section 7 wraps up with the conclusions highlighting
the main advantages of the proposed approach.
3. Terminology
The following is a list of terms used with a specific meaning in
this document.
- Local access provider: entity locally providing the end-user
access to the network
- Service provider: entity offering services to end-users
- Subscription: commercial agreement specifying the characteristics
of service delivery between the service provider and the customer,
possibly including QoS information
- Service settings: service specific information that can be set to
different values by service provider
- Interface: reference point between two session signaling elements
- Roaming: possibility to get access to the network via different
Bos draft-bos-mmusic-sdpng-qos-00.txt 5
SDPng extensions for QoS negotiation September 2002
local access providers
- Session level: session signaling level in the protocol stack,
controlling access to applications/services (e.g. SIP)
- Transport level: resource management level in the protocol stack,
controlling access to network resources (e.g. RSVP)
This document also uses the following terminology as defined in [1]:
User Agent Client (UAC), User Agent Server (UAS), User Agent (UA),
Session, call, Offer/Answer model, Offer/Counter-offer/Answer model.
4. QoS information to be carried in SDPng
The goal is that the QoS information carried in SDPng reflects
exactly the "Quality" level "as the end-user wants to perceive it".
In order to ensure a maximum of flexibility, it SHALL be possible to
negotiate the QoS for each media stream of a given multimedia
session.
Two types of SDPng extensions are needed during the QoS negotiation;
TI (Traffic Information) and SI (Sensitivity Information).
With each codec corresponds one TI level. The end-user (or some
default settings or application running on the end-user terminal)
SHOULD be able to specify per media stream and per codec an ordered
set of acceptable SI QoS levels. Per codec/TI a list of SI levels is
possible. The set of acceptable SI values are listed in decreasing
order of preference in SDPng. This allows for prioritization during
negotiation.
Although there is only one QoS negotiation per SIP transaction for
both send and receive directions, the QoS requirements itself can be
different in the send and receive directions.
4.1. First SDPng extension: TI (Traffic Information)
The first SDPng QoS extensions, called TI (Traffic Information),
define the traffic type of the bearer associated with the media
stream. The parameters characterizing TI are peak bit rate,
sustainable bit rate, maximum packet size and maximum burst size.
TI carries the QoS information that in normal situations can be more
or less derived from the codec. However there are cases where some
media streams are not associated with codecs (e.g. white board) or
cases where the intermediate session control entities do not
recognize the codec being used (e.g. use of new codecs).
Carrying TI explicitly in SDPng still provides intermediate session
control entities (e.g. SIP proxies) knowledge/control on the bearer
requirement of the session being established. It relieves the
requirement for all involved session control elements to know the
mapping from a codec to the transport level requirement (TI) of this
codec. This facilitates the introduction of new codec types.
Bos draft-bos-mmusic-sdpng-qos-00.txt 6
SDPng extensions for QoS negotiation September 2002
TI is always represented in SDPng under the form of parameters with
their respective values:
o peak bit rate
o sustainable bit rate
o maximum packet size
o maximum burst size
4.2. Second SDPng extension: SI (Sensitivity Information)
The second SDPng QoS extensions, called SI (Sensitivity
Information), define the sensitivity of the service with respect to
the QoS information carried in TI. The parameters characterizing SI
are maximum end-to-end delay, maximum end-to-end delay variation and
maximum packet loss ratio. For a certain bearer defined by TI, SI
unambiguously determines the quality "as the end-user wants to
perceive it", SI allows making the differentiation between low,
media, high quality.
Three different formats that can be used to represent SI in SDPng:
- QoS Parameters format:
A standardized set of well-known parameters unambiguously
describing the sensitivity (SI) requirement for a particular codec
corresponding with TI for a given media stream in a session.
The SI QoS parameters are:
o maximum end-to-end delay
o maximum end-to-end delay variation
o maximum packet loss ratio
- QoS Class format:
A standardized abbreviation for the SI QoS parameter format.
Knowing the codec, a QoS class can be directly and unambiguously
translated to a predefined set of SI QoS parameters with well-
defined values. An example QoS class for audio for PCM codec
(G.711) could be "TIPHON PSTN type voice quality". QoS class
values MUST be defined by an internationally recognized standards
body.
- QoS Flavour format:
A standardized way of sending specific non-standard information
describing SI for particular TI/codec. The QoS Flavour format is
used in cases where two involved session control peer elements
would like to exchange non-standard (e.g. service/provider
specific) QoS information. The usage of the QoS Flavour is always
assuming a pre-defined and well-understood interpretation of the
QoS information sent over the considered interface. Therefore, the
list of possible QoS Flavour values that may be exchanged on a
given interface has to be previously defined by a common agreement
between the involved parties. Examples of the QoS Flavour format
are Gold/Silver/Bronze quality, Low/Medium/High quality,...
Bos draft-bos-mmusic-sdpng-qos-00.txt 7
SDPng extensions for QoS negotiation September 2002
A session control element can use different formats to represent the
same SI information depending on which other session control element
it is interfacing with. For example, a service provider can use the
QoS Flavour form on the interface with the end-user and use a
standardized form (QoS parameters or QoS Class) on the interface
with a network operator. The service provider is assumed to perform
the translation between the different representation forms.
4.3. Encoding of QoS extensions in SDPng
The QoS extensions are encoded in SDPng using <option>, as was
already suggested in the last example of section 3.1.2 in [6]. This
section shows, for each of the three different formats explained in
section 4.2, how the SDPng QoS extensions could be incorporated in
that example.
4.3.1. QoS Parameter format
<cfg>
<component name="audio1" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
<option name="TI" pbr="29" sbr="29" mps="72" mbs="72">
<suboption type="SI-parm" name="SI1" me2ed="80"
me2edv="10" mplr="2E-2"/>
<suboption type="SI-parm" name="SI2" me2ed="120"
me2edv="20" mplr="2E-2"/>
</option>
</rtp:udp>
</rtp:session>
</alt>
</component>
</cfg>
This example indicates that for the component "audio1" there is only
one acceptable codec "AVP-audio-0". But with this one codec there
are two acceptable QoS levels, specified in parameter format
respectively as SI1 and SI2. The first set (TI, SI-parm-1) has the
highest preference.
The above TI parameters are defined as follows:
pbr: Peak Bit Rate, expressed in kilobits per second
sbr: Sustainable Bit Rate, expressed in kilobits per second
mps: Maximum Packet Size, expressed in bytes
mbs: Maximum Burst Size, expressed in kilobits
The above SI parameters are defined as follows:
me2ed : Maximum end-to-end delay, expressed in milliseconds
me2edv: Maximum end-to-end delay variation,expressed in milliseconds
mplr : Maximum Packet Loss Ratio
Bos draft-bos-mmusic-sdpng-qos-00.txt 8
SDPng extensions for QoS negotiation September 2002
4.3.2. The QoS Class format
<cfg>
<component name="audio1" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
<option name="TI" pbr="29" sbr="29" mps="72" mbs="72">
<suboption type="SI-class" name="SI1" body="TIPHON"
cl="Narrowband HIGH"/>
</option>
</rtp:udp>
</rtp:session>
</alt>
</component>
</cfg>
This example indicates that for the component "audio1" there is only
one acceptable codec "AVP-audio-0". For this single codec there is
also only one acceptable QoS level, specified in class format, the
"TIPHON PSTN audio" quality. "TIPHON Narrowband HIGH" is an example
of the QoS class defined by TIPHON corresponding with classical PSTN
audio quality.
4.3.3. The QoS Flavour format
<cfg>
<component name="audio1" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
<option name="TI" pbr="29" sbr="29" mps="72" mbs="72">
<suboption type="SI-flav" name="SI1" flav="Gold"/>
<suboption type="SI-flav" name="SI2" flav="Silver"/>
<suboption type="SI-flav" name="SI3" flav="Bronze"/>
</option>
</rtp:udp>
</rtp:session>
</alt>
</component>
</cfg>
This example indicates that for the component "audio1" there is only
one acceptable codec "AVP-audio-0". But with this one codec there
are three acceptable QoS levels, specified in flavour format as
"Gold", "Silver" and "Bronze" quality. Gold has the highest
preference. "Gold Quality", "Silver Quality" and "Bronze Quality"
are examples of QoS Flavours defined by a service provider.
Bos draft-bos-mmusic-sdpng-qos-00.txt 9
SDPng extensions for QoS negotiation September 2002
5. QoS negotiation procedure
The purpose of this section is to explain the QoS negotiation
procedure and to provide some example scenarios. The general
principles behind the QoS negotiation procedure are described in
section 5.1. Section 5.2 explains that the QoS negotiation is
modelled after existing SDPng codec negotiation and shows how it
becomes an integral part of the SDPng Offer/Answer or Offer/Counter-
Offer/Answer model. Section 5.3 provides example QoS negotiation
scenarios.
5.1. Principles of the QoS negotiation procedure
Allowing end-users to choose/agree upon a different QoS for the same
type of communication (e.g. audio call) on a per session basis,
requires QoS (TI and SI) to be negotiable between end-users at the
session signaling level.
All parties executing control on the session signaling (i.e. end-
user, service provider executing service control and local access
network executing policy control) SHALL be able to participate in
the QoS negotiation process. This is to ensure that the QoS
negotiation results in a set of TI and SI values that have been
agreed truly end-to-end at session level so that subsequently at the
transport level QoS provisioning can be started based on end-to-end
QoS agreement.
5.2. Offer/Answer versus Offer/Counter-Offer/Answer model for QoS
negotiation
This draft refers to [1] for the definition of the roles played by
participants in SIP communications. This document also refers to [3]
for the definition of certain SIP extensions (e.g. SIP 183-session-
progress). Using this terminology, a simple SIP transaction can be
modeled as a communication between a UAC and a UAS. A UAC is a
logical entity initiating the SIP transaction with a request (e.g.
SIP INVITE) and a UAS is a logical entity that responds to a SIP
request (e.g. SIP 200-OK or SIP 183-session-progress), generally
acting on behalf of some user.
5.2.1. Current SDP codec negotiation
As described in [7], SDP negotiation within SIP follows an "offer-
answer" model. One side (offerer) offers an SDP that provides its
own view of the session, and the other side (answerer) answers the
SDP with a matching one. The offer can be differentiated in sending
and receiving directions by marking media streams as send-only or
receive-only. If no marking is present the default is both send and
receive. According to [7] SDP negotiation may occur in two ways,
which are referred to as Offer/Answer versus Offer/Counter-
Offer/Answer model:
- Offer/Answer model
The offerer offers an SDP. The answerer is only allowed to reject
Bos draft-bos-mmusic-sdpng-qos-00.txt 10
SDPng extensions for QoS negotiation September 2002
or to restrict the offer. In the latter case, the answer contains
an SDP that is a sub-set of the original SDP proposed by the
offerer (the number of "m=" lines remains the same). In the common
example of codec negotiation, the UAC offers the list of codecs
the UAC is willing to use in the SDP of the SIP INVITE. UAS
answers with an SDP in the SIP 200-OK (or SIP 183-session-
progress) containing only that subset of the original list of
codecs that the UAS is willing to use.
- Offer/Counter-Offer/Answer model
The offerer offers an SDP. The answerer makes a Counter-Offer with
additional elements or capabilities not listed in the original SDP
offer. The Counter-Offer contains an SDP that may be a super-set
of the original SDP proposed by the offerer (even when the number
of "m=" lines remains the same). In the common example of codec
negotiation, the UAS answers with an SDP in the SIP 200-OK (or
SIP-183-session-progress) containing additional codecs, not listed
in the SDP of the SIP INVITE received from the UAC.
In both cases, the final result of the codec negotiation is a list
of codecs for a given media stream; any of those codecs can be
freely used during the session without sending a SIP message.
5.2.2. Proposed SDPng QoS negotiation
The QoS negotiation is modelled after the existing codec negotiation
and as such becomes an integral part of the existing SDPng
Offer/Answer or Offer/Counter-Offer/Answer model. The offerer
determines per media stream a set of acceptable QoS levels,
expressed in SDPng per media component and per codec/TI as an
ordered set SI values. The list of acceptable SI QoS values, called
"Requested QoS", is carried in the SDPng offer in one of three
formats (QoS Parameter, QoS Class or QoS Flavour) and in decreasing
order of preference, to allow prioritization during negotiation.
+---------+ Requested QoS +----------+
| |--------------------->| |
| offerer | Negotiated QoS | Answerer |
| |<---------------------| |
+---------+ +----------+
Offer/Answer model
+---------+ Requested QoS +----------+
| |--------------------->| |
| | Extended QoS | |
| offerer |<---------------------| Answerer |
| | Negotiated QoS | |
| |--------------------->| |
+---------+ +----------+
Offer/Counter-Offer/Answer model
Bos draft-bos-mmusic-sdpng-qos-00.txt 11
SDPng extensions for QoS negotiation September 2002
Figure 1: Basic versus Enhanced QoS offer-answer model
In the Offer/Answer model (see top of Figure 1) the answerer is only
allowed to reject or restrict the "Requested QoS". The UAS SHOULD
use the QoS value with the highest preference that is acceptable to
it. The SDPng answer contains a "Negotiated QoS", that is a sub-set
of the original "Requested QoS".
The "Negotiated QoS" is equal to the "Requested QoS" in case the UAS
accepts to support all the QoS values originally proposed by the
UAC. The UAS MUST list the "Negotiated QoS" levels in the same
relative order they were present in the "Requested QoS" to guarantee
that the same QoS level is used by both User Agents.
In the Offer/Counter-Offer/Answer model (see bottom of Figure 1) the
answerer MAY extend the "Requested QoS" with additional QoS levels
not listed in the original "Requested QoS". In this case, the
Counter-Offer contains an "Extended QoS", that MAY be a super-set of
the original "Requested QoS" proposed by the offerer. The offerer
selects a subset "Negotiated QoS" of the "Extended QoS" and sends
this "Negotiated QoS" back to the answerer.
In both cases, the final result of the QoS negotiation is the
"Negotiated QoS"; a decreasing ordered list of QoS (TI and SI)
values per media stream retained for the session. Any of those
negotiated TI/SI combinations can be freely used during the session
without sending a SIP message.
5.2.2.1 Simple UAC-UAS scenario
A simple example (Figure 2) is direct UAC to UAS communication
according to the QoS Offer-Answer model. The "Requested QoS" is
carried in the SIP INVITE, the "Negotiated QoS" in the SIP 200-OK or
SIP 183-session-progress.
+-----+ SIP INVITE, SDPng "Requested QoS" +-----+
| |-------------------------------------------->| |
| | SIP 200-OK or SIP 183-session-progress | |
| UAC | SDPng "Negotiated QoS" | UAS |
| |<--------------------------------------------| |
| | ACK or PRACK | |
| |-------------------------------------------->| |
+-----+ +-----+
Figure 2: Simple UAC - UAS scenario
5.2.2.2. UAC-Proxy Server-UAS scenario
According to [1], SIP requests can be sent directly from a UAC to a
UAS or they can traverse one or more proxy servers along the way.
Also from [1] we learn that a proxy can indicate that it wants to
remain in the request path via a Record-Route header field. [1] also
Bos draft-bos-mmusic-sdpng-qos-00.txt 12
SDPng extensions for QoS negotiation September 2002
states that proxies MAY modify any part of the SIP message -
including the SDP - that are not integrity-protected, except those
needed to identify call legs.
The above statements, quoted from [1], have the following
implications on the QoS Offer/Answer model. Firstly the simple UAC-
UAS model (Figure 2) does not suffice. One or more proxy servers,
possibly operated by different providers, MAY be in the signaling
path between UAC and UAS (Figure 3). Some proxies (e.g. proxy in
local access network executing policy control and proxy operated by
the userĘs Internet service provider executing service control) MAY
Record-Route themselves, so that they can screen the SDPng QoS
negotiation, and MAY decide to modify the QoS being negotiated.
+-----+ +--------+ +-----+
| | SIP INVITE | | SIP INVITE | |
| | SDPng | | | |
| | "Requested QoS" | | SDPng "Modified QoS" | |
| |------------------->| |----------------------->| |
| UAC | SIP 200-OK or | proxy | SIP 200-OK or | UAS |
| | SIP 183 | SIP | SIP 183 | |
| | SDPng | | | |
| | "Negotiated QoS" | server | SDPng "Negotiated QoS" | |
| |<-------------------| |<-----------------------| |
| | ACK or PRACK | | ACK or PRACK | |
| |------------------->| |----------------------->| |
+-----+ +--------+ +-----+
Figure 3: UAC - Proxy Server - UAS scenario
Figure 3 shows the impact of intermediate proxies on the Offer-
Answer model. Proxies MAY modify the "Requested QoS" received from
the UAC to a "Modified QoS" based on different criteria. Such
criteria could include information regarding subscription profile of
the user, specific service settings, time of day/week or any other
local network policies. Of course the UAS may also perform a final
restriction on the set of QoS values resulting in the "Negotiated
QoS".
Thus, the "Negotiated QoS" will equal the "Requested QoS" only if
the "Requested QoS" was compliant with the subscriber
profile/service settings, not conflicting with local network
policies and acceptable to the UAS.
In the Offer-Answer model proxies are only allowed to make
modifications in the sense of restrictions. The only exception is
when the UAC does not include a "Requested QoS" in the SIP INVITE
message. In this case a SIP proxy in the end-userĘs service provider
domain MAY propose a "Modified QoS" itself. If the UAC does not
specify a "Requested QoS" in the session set up, the "Modified QoS"
MAY be deduced by the userĘs service provider either implicitly from
access information about the UAC (terminal capabilities,
Bos draft-bos-mmusic-sdpng-qos-00.txt 13
SDPng extensions for QoS negotiation September 2002
applications in terminal, access type, etc.), or from subscription
or service information (the userĘs service provider can propose
subscription packages with different levels of QoS for the different
media streams involved in a communication service).
5.3. Relationship with transport level QoS provisioning
On the response path (Figure 3) the "Negotiated QoS" is distributed
(in a SIP 200-0K or SIP 183-session-progress) to all involved
session control elements between UAS and UAC side. At this point,
proxies in the local access networks MAY use this "Negotiated QoS"
information to inform the transport layer about the QoS/resources
that have been authorized by the session layer for each media stream
of the multimedia session. This topic is however not the subject of
this document. [4] Already describes SIP extensions for media
authorization which enable this correlation between the resources
authorized by the call/session signaling architecture and the actual
network resources requested by the UA at resource reservation/QoS
provisioning.
It is important to understand also that this document does not
describe a way to use SIP/SDPng messages for QoS provisioning. The
SDPng QoS negotiation occurs independently of and prior to the QoS
provisioning itself. Since in an IP network session signaling (e.g.
SIP/SDP) usually follows another route than the data path, a
proposal to integrate them indeed would make no sense. During the
SDPng QoS negotiation step end-users simply agree on the QoS they
would prefer but no resource reservation /QoS provisioning is
carried out yet for that particular session. The proposed SDPng QoS
extensions are a way to make sure that existing QoS provisioning
mechanisms (e.g. RSVP, DiffServ, MPLS) receive correct and complete
input, enabling them to reserve the resources with a QoS that
matches exactly the end-user expectations.
After all parties (end-user, local access network, service provider)
involved in the session signaling have agreed upon the QoS,
appropriate QoS has to be provisioned in the network to deliver this
QoS. Therefore UAC and UAS need to be able to translate the final TI
and SI values negotiated at session/service level into the correct
transport level QoS parameters, in order to trigger the
corresponding QoS provisioning mechanisms (e.g. RSVP, DiffServ).
5.4. QoS preconditions - Coupling with manyfolks
Manyfolks [3] defined the "qos" attribute SDP extension, that
indicates whether end-to-end resource reservation is optional or
mandatory, and in which direction (send, recv, or sendrecv). The
assumption is that similar extensions will also exist in SDPng.
An end-user should be able to specify for each media stream whether
the successful establishment of a bearer "with a specific QoS" is
required. This is enabled by co-ordinating the simultaneous usage of
the mandatory or optional SDPng manyfolks extensions with the SDPng
QoS extensions defined in this document.
Bos draft-bos-mmusic-sdpng-qos-00.txt 14
SDPng extensions for QoS negotiation September 2002
According to manyfolks [3] in case resource reservation is required
as a precondition before proceeding with the session, it is
necessary to replace the SIP 200-OK in Figure 2 by a SIP 183-
session-progress and the SIP ACK by a SIP PRACK. When the "qos"
attribute indicates mandatory, this means that the participant who
has received the session description does not proceed session setup
until resource reservation has been completed in the specified
direction.
This document extends manyfolks [3] in the following way. If the
"qos" attribute is set to mandatory, the SDPng QoS extensions allow
participants to indicate that resources need to be reserved end-to-
end, not only in which direction, but also WITH WHICH QUALITY OF
SERVICE. Namely, with a Quality of Service compliant with the set of
acceptable QoS values carried in the SDPng QoS extensions. If the
"qos" attribute is set to optional, the SDPng QoS extensions allow
participants to indicate with which Quality of Service resources
should be reserved, but only if possible, that is without blocking
the session set up process. If for mandatory media an end-user does
not want best effort quality, the end-user should not indicate best
effort as an acceptable QoS level. For optional media, best effort
quality is implicitly assumed to be acceptable.
5.5. Scenario examples
5.5.1. Example 1: Simple UAC-UAS scenario
Suppose again the simple case (Figure 2) of direct UAC to UAS
communication according to the QoS Offer-Answer model. Suppose the
UAC specifies a "Requested QoS" containing acceptable QoS levels A,
B and C for audio and D and E for video (highest preference for A
respectively D).
Upon evaluation of the preference list of QoS values in the
"Requested QoS", the UAS restricts the "Requested QoS" to only those
QoS values that he is willing to use for this particular session.
Suppose that the "Negotiated QoS" retains QoS levels A and B for
audio and QoS level E for video. This means that the UAS is not
willing to support the lowest QoS level C for audio nor the highest
QoS level D for video.
Suppose the UAC had specified in the SDPng offer that reservation of
resources for the audio component (with acceptable QoS levels A, B
and C) was optional in the receiving direction whereas reservation
of resources for the video component (with acceptable QoS levels D
and E) was mandatory also in the receiving direction. This
effectively means that the UAC only wishes to continue with the
session if the UAS agrees and succeeds to reserve resources towards
UAC for the video with a Quality of Service not lower than E and not
higher than D.
Making resource reservation for the audio component optional means
that the UAC would like a Quality of Service level between A and C
Bos draft-bos-mmusic-sdpng-qos-00.txt 15
SDPng extensions for QoS negotiation September 2002
but it will accept the media stream in the worst case even with no
QoS guarantees (best effort).
As the "Negotiated QoS" in this example contains the QoS level E for
the video the UAC would accept the session. Suppose UAS rejected all
A,B and C for the audio component ("Negotiated QoS" does not contain
any QoS values for the audio component), the UAC would still accept
the session even with best effort quality of service for the audio.
5.5.2. Example 2: UAC-Proxy Server-UAS scenario
Suppose again the case (Figure 3) with intermediate proxy/proxies
between UAC and UAS. This example illustrates the use of the three
possible formats that can be used to express the SI requirements
(QoS Parameters, QoS Class, QoS Flavour). Suppose the UAC uses in
the SIP INVITE the "QoS flavour" format hereby indicating to the
proxy of the service provider for example that both "Gold" and
"Silver" are acceptable for the voice component. "Gold" and "Silver"
can be commercial names for QoS packages, the correct interpretation
of which are only known to the end-user and its Service Provider
(e.g. defined in a subscription).
Suppose for this example that the proxy of the service provider
decides, after checking several criteria (e.g. local network
policies, subscription profile of the end-user, service
settings,...) that only "Silver" can be retained. Before forwarding
this information to the UAS the service provider will have to
perform the correct translation from the non-standard "QoS Flavour"
representation form into one of the standard formats "QoS Class" or
"QoS Parameters".
Since the usage of the QoS Flavour format always assumes a pre-
defined and well-understood interpretation of the QoS information
sent over the considered interface, the proxy of the service
provider unambiguously knows this mapping. "Silver" is mapped to the
correct set of corresponding "QoS parameters" which are then sent to
the UAS.
A typical example where the proxy of the service provider could
decide to use the "QoS class" occurs when there is a need to cross
another proxy operated by a different provider (e.g. local access
network where UAS is roaming) before reaching the UAS. There is no
specific motivation to choose the "QoS class" instead of the "QoS
parameters" format besides the fact that the former is a
standardized abbreviated way to convey the same information.
6. Security considerations
The security considerations for ongoing SDPng specification work
also apply to the SDPng QoS extensions proposed in this document. If
the contents of the SDPng are private then end-to-end encryption of
the message body can be used to prevent unauthorized access to the
content.
Bos draft-bos-mmusic-sdpng-qos-00.txt 16
SDPng extensions for QoS negotiation September 2002
7. Conclusions
This document described a framework to negotiate end-to-end the
"Quality" of a multimedia session "as the end-user wants to perceive
it". This QoS negotiation is achieved at session signaling. All
authorized session control elements, user agents as well as proxies,
controlling the multimedia session set-up may participate to the QoS
negotiation. Secondly this document proposed two new types of SDPng
extensions that allow expressing the QoS level per media stream
during the QoS negotiation. The first type of SDPng extensions
characterize the traffic type of the bearer associated with the
media stream, the second type of SDPng extensions characterize the
sensitivity level of the service requested by the end-user with
respect to the QoS information carried in the first type of SDPng
extensions.
To conclude we summarize the main advantages of the proposed
approach.
- The SDPng QoS negotiation model can be used in combination with
several application protocols (SIP, RTSP, Megaco, BICC,...). It
works for roaming as well as non-roaming scenarios.
- From a customer point of view, the mechanism enables end-users to
negotiate/agree upon QoS at session set-up. The end-user QoS
preferences can be specified flexibly as a prioritized list of
acceptable QoS levels per media stream. Coupling with the
manyfolks SDP extensions enables end-users to make successful
establishment of a bearer "with a specific QoS" a precondition for
session set-up. All this allows end-users to control QoS and thus
their expenses more flexibly.
- From the provider point of view, via the participation of proxies
in the QoS negotiation, he keeps in control (policy and service
control) over the QoS allocated to a certain user, also for media
associated with a new codec or with no codec at all (e.g.
whiteboard). Having the QoS to be set-up at the transport level
first "approved" at session level by end-users, service provider
and local access provider enables service providers to deliver a
"predictable" QoS level to its customers. This means QoS becomes
something a service provider can sell. New attractive subscription
packages can be designed with a prize based on different QoS
levels reflecting the true "Quality" as experienced by the end-
user. Allowing non-standard service provider specific QoS info to
be carried in SDPng creates new opportunities for differentiation
between service providers as they can all start designing their
own QoS Flavours (e.g. Gold/Silver/Bronze service). Finally
enabling providers to make more intelligent decisions on QoS
provisioning allows improvement of network scalability.
8. Acknowledgements
This document is a result of an ongoing discussion among many people
from Alcatel and other companies (KPN,...). We would hereby like to
Bos draft-bos-mmusic-sdpng-qos-00.txt 17
SDPng extensions for QoS negotiation September 2002
thank all the people who provided valuable comments and input that
improved the quality of this document.
9. References
[1] Rosenberg J., Schulzrinne H., Handley M., Schooler E., "SIP,
Session Initiation Protocol", draft-ietf-sip-rfc2543bis-07.txt, Work
in Progress.
[2] M. Handley, V. Jacobson, C. Perkins: "SDP: Session Description
Protocol", draft-ietf-mmusic-sdp-new-04.txt, Work in progress.
[3] W. Marshall et al. "Integration of Resource Management and
SIP", draft-ietf-sip-manyfolks-resource-03.txt, Work in progress.
[4] W. Marshall et al. "SIP Extensions for Media Authorization",
draft-ietf-sip-call-auth-03.txt, Work in progress.
[5] Kutscher, Ott, Bormann and Curcio, "Requirements for Session
Description and Capability Negotiation", draft-ietf-mmusic-sdpng-
req-01.txt, Work in progress.
[6] Kutscher, Ott, Bormann, "Session Description and Capability
Negotiation", draft-ietf-mmusic-sdpng-03.txt, Work in progress.
[7] Rosenberg J., Schulzrinne H., "An offer/answer model with SDP"
draft-rosenberg-mmusic-sdp-offer-answer-00.txt, Work in Progress.
[8] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss,
"An Architecture for Differentiated Service", RFC 2475, December
1998.
[10] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[11] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[12] S. Bradner, "The Internet Standards Process - Revision 3", BCP
9, RFC 2026, October 1996
10. Author's Addresses
Lieve Bos
Alcatel
Francis wellesplein 1 Phone: +32 3-241-58-91
2018 Antwerpen, Belgium Email: lieve.bos@alcatel.be
Suresh Leroy
Alcatel
Bos draft-bos-mmusic-sdpng-qos-00.txt 18
SDPng extensions for QoS negotiation September 2002
Francis wellesplein 1 Phone: +32 3-240-85-50
2018 Antwerpen, Belgium Email: suresh.leroy@alcatel.be
Jozef Vandenameele
Alcatel
Francis wellesplein 1 Phone: +32 3-240-43-61
2018 Antwerpen, Belgium Email: jozef.vandenameele@alcatel.be
Juan-Carlos Rojas
Alcatel
Le Mail Phone: +33 2-5178-12-82
44708 Orvault, France Email: juan-carlos.rojas@alcatel.fr
Laurent Thiebaut
Alcatel
10 Rue Latecoere Phone: +33 1-3077-06-45
78140 Velizy, France Email: laurent.thiebaut@alcatel.fr
Pieter Veenstra
KPN
P.O. Box 30150 Phone: +31 70-343-91-21
2500 GD Den Haag, Netherlands Email: p.k.veenstra@kpn.com
Richard Brooks
Samsung Electronics
Research Institute Phone: +44 7776-18-15-55
Communications House Email: richardbrook39@aol.com
South Street
TW18 4QE Staines, UK
Matt Holdrege
Sonus Networks Inc.
223 Ximeno Avenue Phone: +1 562-547-19-22
CA 90803 Long Beach, USA Email: matt@sonusnet.com
11. Full copyright statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Bos draft-bos-mmusic-sdpng-qos-00.txt 19
SDPng extensions for QoS negotiation September 2002
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bos draft-bos-mmusic-sdpng-qos-00.txt 20
