[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
                  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]