idnits 2.17.1 draft-bos-mmusic-sdpqos-framework-00.txt: -(71): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(77): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(348): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(444): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(671): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(674): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(758): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(762): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(776): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(800): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(803): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(806): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(840): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(843): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(845): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' introduction of new codec types is simplified.' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 677 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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]). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '11' on line 988 looks like a reference -- Missing reference section? '10' on line 985 looks like a reference -- Missing reference section? '1' on line 955 looks like a reference -- Missing reference section? '2' on line 959 looks like a reference -- Missing reference section? '3' on line 962 looks like a reference -- Missing reference section? '4' on line 965 looks like a reference -- Missing reference section? '5' on line 968 looks like a reference -- Missing reference section? '7' on line 975 looks like a reference -- Missing reference section? '8' on line 978 looks like a reference -- Missing reference section? '9' on line 982 looks like a reference -- Missing reference section? '6' on line 972 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC working group L. Bos 3 Internet Draft S. Leroy 4 draft-bos-mmusic-sdpqos-framework-00.txt J.-C. Rojas 5 L. Thiebaut 6 J. Vandenameele 7 Alcatel 8 P. Veenstra 9 KPN 10 Expires: May, 2002 November , 2001 12 A Framework for End-to-End User Perceived 13 Quality of Service Negotiation 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance 18 with all provisions of Section 10 of RFC2026 [11]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes a framework to negotiate end-to-end the 38 "Quality" of a multimedia session "as the end-user wants to perceive 39 it". This UPQoS (User Perceived QoS) negotiation is achieved at 40 session signaling level using two types of new SDP extensions, which 41 this document proposes to specify. All session control elements - 42 user agents as well as proxies - involved in the multimedia session 43 setup may participate to the UPQoS negotiation. 45 Secondly this document proposes to specify SDP extensions which 46 allow to express the UPQoS level per medium stream during the UPQoS 47 negotiation. The first type of SDP extensions characterizes the 48 traffic type of the bearer associated with the medium stream. The 49 second type of SDP extensions characterizes the 50 tolerance/sensitivity level of the service requested by the end-user 51 with respect to the QoS information carried in the first type of SDP 52 extensions. 54 Table of Contents 56 Status of this Memo................................................1 57 Abstract...........................................................1 58 1. Conventions used in this document...............................2 59 2. Terminology.....................................................2 60 3. Introduction....................................................5 61 4. End-to-end UPQoS negotiation: goals and requirements............7 62 5. QoS information to be transferred in SDP for UPQoS negotiation..8 63 6. End-to-end user perceived QoS negotiation scenarios............10 64 6.1. Principles of the end-to-end User Perceived QoS negotiation 65 procedure........................................................10 66 6.2. Basic versus enhanced QoS offer-answer model................11 67 6.2.1. Current SDP offer-answer model............................11 68 6.2.2. Offer-answer model for UPQoS negotiation..................12 69 6.3. Example scenarios...........................................13 70 6.3.1. Simple UAC-UAS scenario...................................13 71 6.3.2. UAC � proxy server � UAS scenario.........................15 72 6.3.3. SI formats example........................................18 73 7. Security considerations........................................18 74 8. Conclusions....................................................19 75 9. Acknowledgements...............................................19 76 10. References....................................................19 77 11. Authors� Addresses............................................20 78 12. Full copyright statement......................................21 80 1. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 84 this document are to be interpreted as described in RFC-2119 [10]. 86 2. Terminology 88 The following is a list of terms used with a specific meaning in 89 this document. 91 - User Perceived QoS (UPQoS): "Quality" of a multimedia session "as 92 the end-user wants to perceive it". The UPQoS unambiguously defines 93 per medium stream the level of QoS requested by the end-user at the 94 beginning of the UPQoS negotiation. The UPQoS negotiation is 95 achieved at session signalling level using two new types of SDP 96 extensions (TI and SI extensions). 98 - Traffic Information (TI): first type of SDP extensions which this 99 document proposes to specify, characterising the traffic type of the 100 bearer associated with the medium stream. Typically TI is related to 101 bandwidth and packet size. 103 - Sensitivity Information (SI): second type of SDP extensions which 104 this document proposes to specify, characterising the 105 tolerance/sensitivity level of the service requested by the end-user 106 with respect to the QoS information carried in TI. Typically SI is 107 related to maximum packet loss ratio, maximum end-to-end delay and 108 maximum end-to-end delay variation. There are three possible ways to 109 entirely describe a given SI level for a given medium stream in a 110 given session: QoS flavour (QF) format, Standard QoS Class (SQC) and 111 Standard QoS parameters (SQP). 113 - Standard QoS Parameters (SQP) format: sets of well-known 114 parameters allowing to precisely describe the SI requested for a 115 given medium stream. 117 - Standard QoS Class (SQC) format: an abbreviated way of sending 118 standardised sets of QoS parameters (SQP) with well-defined values. 120 - QoS Flavour (QF) format: a standardized way of sending 121 service/provider specific non-standard SI data. 123 - Local access provider: entity locally providing the end-user 124 access to the network 126 - Service provider: entity offering services to end-users 128 - Subscription: commercial agreement specifying the characteristics 129 of service delivery between the service provider and the customer, 130 possibly including QoS information. 132 - Service settings: service specific information that can be set to 133 different values 135 - Interface: reference point between two session signaling elements 137 - Roaming: possibility to get access to the network via different 138 local access providers 140 - Session level: session signaling level in the protocol stack, 141 controlling access to multimedia services 143 - Transport level: resource management level in the protocol stack, 144 controlling access to network resources 145 - Offerer: party initiating the SDP negotiation with an SDP offer 146 towards the answerer 148 - Answerer: party responding to the initial SDP offer with an SDP 149 answer 151 - Requested QoS: Initial ordered list of UPQoS (TI and SI) values 152 proposed by the offerer in the SDP offer 154 - Modified QoS: Intermediate ordered list of acceptable UPQoS levels 155 (TI and SI) possibly restricted by intermediate proxies in the SDP 156 negotiation according to a number of criteria (e.g. end-user 157 subscription, service settings, network congestion situation, any 158 other local policies) 160 - Extended QoS: Ordered list of UPQoS values, possibly extended by 161 the answerer with extra values, used in case of the enhanced offer- 162 answer model. 164 - Negotiated QoS: Final ordered list of UPQoS values (TI and SI) 165 resulting from the SDP negotiation between all involved session 166 control elements end-to-end. 168 The following list of definitions coming from [1] is also used in 169 this document. 171 - User agent client (UAC): A user agent client is a logical entity 172 that initiates a SIP transaction with a request. This role lasts 173 only for the duration of that transaction. In other words, if a 174 piece of software initiates a request, it acts as a UAC for the 175 duration of that request. If it receives a request later on, it 176 takes on the role of a User Agent Server for the processing of that 177 transaction. 179 - User agent server (UAS): A user agent server is a logical entity 180 that responds to a SIP request, generally acting on behalf of some 181 user. The response accepts, rejects or redirects the request. This 182 role lasts only for the duration of that transaction. In other 183 words, if a piece of software responds to a request, it acts as a 184 UAS for the duration of that request. If it generates a request 185 later on, it takes on the role of a User Agent Client for the 186 processing of that transaction. 188 - User agent (UA): A logical entity that acts as both a user agent 189 client and user agent server for the duration of a call. 191 - Session: A multimedia session is a set of multimedia senders and 192 receivers and the data streams flowing from senders to receivers. A 193 multimedia conference is an example of a multimedia session. A 194 callee can be invited several times, by different calls, to the same 195 session. 197 - Call: A call consists of all participants in a session invited by 198 a common source. A SIP call is created when a user agent sends an 199 INVITE request. This INVITE request may generate multiple 200 acceptances, each of which is part of the same call (but different 201 call legs). Furthermore, if a user is invited to the same multicast 202 session by several people, each of these invitations will be a 203 unique call. In a multiparty conference unit (MCU) based call-in 204 conference, each participant uses a separate call to invite himself 205 to the MCU. 207 - (SIP) transaction: A SIP transaction occurs between a client and a 208 server and comprises all messages from the first request sent from 209 the client to the server up to a final (non-1xx) response sent from 210 the server to the client. A transaction is identified by the CSeq 211 sequence number within a single call leg. The ACK request has the 212 same CSeq number as the corresponding INVITE request, but comprises 213 a transaction of its own. 215 3. Introduction 217 The Session Initiation Protocol, SIP [1] is an application-layer 218 control protocol for creating, modifying and terminating sessions 219 such as Internet multimedia conferences, Internet telephone calls 220 and multimedia distribution. The SIP messages used to create 221 sessions carry session descriptions, which allow participants to 222 agree on a set of compatible media types. The session description, 223 commonly formatted in SDP [2], is intended to be a well-defined 224 format for conveying sufficient information to discover and 225 participate in a multimedia session. 227 Although SIP [1] and SDP [2] offer an attractive set of mechanisms 228 for multimedia session control and description, several IETF drafts 229 have already shown the need for extensions to these protocols, 230 especially for the provisioning of end-to-end Quality of Service for 231 high-quality IP telephony and multimedia services. [3] describes SDP 232 extensions which express preconditions for individual media streams 233 that require network QoS and security associations to be established 234 before continuing with the session setup. [4] describes SIP 235 extensions for media authorization which enable the correlation 236 between the resources authorized by the call/session signaling 237 architecture and the actual network resources requested by the UA at 238 bearer setup. [5] demonstrates that there is a requirement from the 239 IETF Multiparty Multimedia Session Control (MMUSIC) working group to 240 specify additional QoS parameters for SDPng. 242 In essence these recent proposals have recognised the need to 243 enhance the co-ordination between the session signalling layer, 244 which controls access to multimedia specific services, and the 245 resource management layer, which controls access to network 246 resources. However there is currently no mechanism defined to 247 specify at session control level the QoS requirements that reflect 248 the true end-user expectations. 250 Since the purpose of the SDP [2] protocol is to carry the actual 251 session and media stream description, extensions to SDP seem the 252 natural way to carry this information. 254 The final goal of a true end-to-end QoS provisioning architecture is 255 to deliver the end-user a QoS for each medium stream that 256 corresponds exactly to the level of "quality" he wishes to 257 perceive/experience, called User Perceived QoS (UPQoS) hereafter. An 258 end-user should have the possibility to request a different 259 "quality" for a medium stream based on for instance the destination, 260 expected duration of the session, pricing,... The best quality could 261 be preferred for an important session, while the lowest could be 262 chosen when the end-user knows by advance that the session will be 263 quite long, or not very important, etc. The differentiation could 264 also be requested by the service provider in order to take into 265 account the specificity of the service, the time of day/week, the 266 destination, etc. The flexibility to offer QoS based on different 267 levels of perceived end-user quality creates more opportunities for 268 differentiation between operators. 270 Firstly, this document proposes a framework for end-to-end User 271 Perceived QoS (UPQoS) negotiation involving all session control 272 elements between the UAC and UAS. Secondly this document proposes to 273 specify two types of SDP extensions needed to express the UPQoS per 274 medium stream during the UPQoS negotiation. The first type of SDP 275 extensions characterise the traffic type of the bearer associated 276 with the medium stream, the second type of SDP extensions 277 characterise the tolerance/sensitivity level of the service 278 requested by the end-user with respect to the QoS information 279 carried in the first type of SDP extensions. 281 The document also shows the advantages of this approach: 282 - Allows end-users to express to the network per medium stream the 283 "Quality" as they want to perceive it. 284 - Increases end-user flexibility to control his expenses and QoS. 285 - Allows the service provider to develop new charging mechanisms for 286 QoS enabled sessions based on the "Quality" as experienced by the 287 end-user. 288 - Allows local access network in case of network congestion to 289 downgrade the QoS of users (e.g. release calls or re-route calls) 290 respecting the service settings/subscription profile agreed between 291 end-user and service provider. 292 - Enables providers to make more intelligent decisions on QoS 293 provisioning that can help them to improve the network scalability. 294 - Facilitates the introduction of new codec types. 295 - Etc. 297 This document does not describe a way to carry bearer setup messages 298 into SIP/SDP. Since in an IP network session signalling messages 299 (e.g. SIP/SDP) usually follow another route than the bearer setup 300 messages, such a proposal indeed would make no sense. Instead, this 301 document provides a way for the end-user to express to the network 302 the "Quality" he expects, and a way for the network to check at 303 session control level whether an acceptable level of QoS for each 304 medium stream of the requested multimedia session can be set up in 305 accordance with e.g. the user's subscription profile, service 306 settings, policies in the local access,.... 308 Currently SDP does not carry sufficient information allowing SIP- 309 proxies to unambiguously authorise, in line with [4], the complete 310 set of QoS parameters needed for bearer set-up with a "Quality" 311 satisfying the user's expectations. The SDP extensions that this 312 document proposes to specify are a way to make sure that existing 313 bearer setup mechanisms (e.g. RSVP, Diffserv, MPLS) are getting the 314 correct and complete input, that enables them to reserve the 315 resources with a Quality of Service that matches exactly the end- 316 user expectations. 318 [5] demonstrates that there is a requirement from the IETF 319 Multiparty Multimedia Session Control (MMUSIC) working group to 320 specify additional QoS parameters for SDPng. This document proposes 321 to specify QoS extensions to SDP, as this is the current standard. 322 Similar extensions to SDPng are however not precluded. 324 This document is organised as follows. Section 4 lists the 325 requirements and goals of the mechanisms used for User Perceived QoS 326 (UPQoS) negotiation. Section 5 introduces the meaning of the two 327 types of SDP extensions that this document proposes to specify. 328 Section 6 explains a number of end-to-end UPQoS negotiation 329 scenarios. 331 4. End-to-end UPQoS negotiation: goals and requirements 333 This section describes the goals and requirements of the proposed 334 solution to provide end-to-end User Perceived Quality of Service 335 (UPQoS) negotiation. 337 - Independence of session signalling protocol. 338 This document proposes to specify extensions to the session 339 description protocol SDP, not to any session signalling protocol 340 (e.g. SIP, BICC,...). 342 - UPQoS negotiation (session level) complementary to existing bearer 343 setup mechanisms (transport level). 344 This document does not propose a way to carry bearer setup messages 345 in SIP/SDP. Instead the UPQoS negotiation complements existing 346 bearer setup mechanisms (e.g. RSVP [7], Diffserv [8], MPLS [9]) by 347 providing them correct and complete information for setting up a 348 bearer matching exactly end-user�s expectations. This document does 349 not describe new mechanisms to enforce synchronisation between the 350 QoS negotiated at session level and the QoS actually requested at 351 bearer setup. That requirement is already covered by [4]. This 352 document is complementary in this respect to [4]. 354 - Need for an "end-to-end" UPQoS negotiation at session/service 355 level. 356 To guarantee the end-to-end character of the negotiated UPQoS, 357 session control elements of all involved parties in the session 358 signalling path (local access network, service provider, end-user) 359 shall be able to participate in the negotiation process. 361 - UPQoS negotiation per medium stream. 362 In order to ensure a maximum of flexibility, the end-to-end UPQoS 363 negotiation framework shall allow UPQoS negotiation for each medium 364 stream of a given multimedia session. It shall be possible for the 365 end-user to specify per medium stream a range of acceptable UPQoS 366 levels in decreasing order of preference. 368 - Successful establishment of media streams. 369 An end-user shall be able to specify for each medium stream whether 370 successful establishment of a bearer "with a specific QoS" is 371 required. That requirement is already covered by [3]. This document 372 is complementary in this respect to [3]. 374 - Validity for roaming and non-roaming situations. 375 End-to-end UPQoS negotiation shall be possible both for roaming and 376 non-roaming scenarios. 378 - Standard Mechanism to carry standard and non-standard information. 379 For interoperability reasons, a minimum set of QoS information to be 380 carried in the SDP extensions must be standardised. On the other 381 hand in some cases two involved session signalling elements may need 382 to transfer QoS information that is service/provider specific and 383 can therefore not be standardised. Therefore the SDP extensions 384 shall provide a standardised way to send standardised and specific 385 non-standard QoS information. Session control elements shall be 386 allowed to represent the QoS information for a given session in a 387 flexible way depending on the nature of the interface the QoS 388 information is crossing. 390 - Relationship with codec information in SDP 391 End-to-end UPQoS negotiation also works in situations where some 392 medium streams are not associated with codecs (e.g. white board) as 393 well as situations where the intermediate session control entities 394 do not have any a priori knowledge of the codec being used (e.g. use 395 of new codecs). 397 5. QoS information to be transferred in SDP for UPQoS negotiation 398 The User Perceived QoS (UPQoS) is defined as the "Quality" of a 399 multimedia session "as the end-user wants to perceive it". This 400 UPQoS level is requested by the end-user at session setup and 401 negotiated end-to-end at session signalling level. This document 402 proposes to specify two types of SDP extensions to express the UPQoS 403 per medium stream during the UPQoS negotiation. 405 The first type of QoS SDP extensions, hereafter called Traffic 406 Information (TI), characterise the traffic type of the bearer 407 associated with the medium stream. Typically TI is related to 408 bandwidth and packet size. There are situations where some medium 409 streams are not associated with codecs (e.g. white board) or 410 situations where the intermediate session control entities do not 411 have any a priori knowledge of the codec being used (e.g. use of new 412 codecs). Carrying TI per media stream via SDP still provides 413 intermediate session control entities (proxies) knowledge/control on 414 the bearer requirement of the session being established. It relieves 415 the requirement for all involved session control elements to know 416 the mapping from a codec to the bearer level requirement (TI) of 417 this codec. This facilitates the introduction of new codec types. 419 The second type of QoS SDP extensions, hereafter called Sensitivity 420 Information (SI), characterise the tolerance/sensitivity of the 421 service with respect to the QoS information carried in TI. Typically 422 SI is characterised by maximum packet loss ratio, maximum end-to-end 423 delay and maximum end-to-end delay variation. For a certain bearer 424 defined by the TI the SI unambiguously determines the quality "as 425 the end-user wants to perceive it". 427 There are three possible representation formats which can be used to 428 unambiguously describe a given SI level for a given medium stream in 429 a given session: QoS flavour (QF) format, Standard QoS Class (SQC) 430 and Standard QoS parameters (SQP). 432 - The Standard QoS Parameters (SQP) format 433 The Standard QoS Parameters (SQP) are a set of well-known 434 parameters allowing to precisely describe for a given medium 435 stream the tolerance/sensitivity (SI) requirement. The Standard 436 QoS Parameters are maximum packet loss ratio, maximum end-to- 437 end delay and maximum end-to-end delay variation. 439 - The Standard QoS Class (SQC) format 440 A standardised QoS class (SQC) is an abbreviated way of sending 441 standardised sets of QoS parameters (SQP) with well-defined 442 values. A SQC can be directly and unambiguously translated to a 443 pre-defined set of SQP. An example for audio could be a SQC for 444 "PSTN type voice quality�. SQC values must be defined by an 445 internationally recognised standards body. 447 - The QoS Flavour (QF) format 448 The QoS flavour (QF) is a standardised way of sending specific 449 non-standard information describing the tolerance/sensivity 450 (SI) requirement. The QF format is used in cases where two 451 involved session control elements would like to exchange non- 452 standard (e.g. service/provider specific) QoS information. The 453 usage of the QF type is always assuming a pre-defined and well- 454 understood interpretation of the QoS information sent over the 455 considered interface. Therefore, the list of possible values to 456 be exchanged on a given interface has to be previously defined 457 by a common agreement between the involved parties. The QF can 458 take values representing information like "Gold", "Silver", 459 "Bronze",etc. 461 In order to ensure a maximum of flexibility, the end-to-end UPQoS 462 negotiation framework allows UPQoS negotiation for each medium 463 stream of a given multimedia session. Therefore the SDP extensions 464 allow to carry the Traffic Information and Sensitivity Information 465 (expressed in SQP, SQC or QF format as explained above) per medium 466 stream of a given multimedia session. 468 The possibility exists for the end-user (or some default settings or 469 application running on the end-user terminal) to specify per medium 470 stream an ordered set of acceptable levels of User Perceived QoS. 471 Per TI a list of SI levels is possible. A decreasing order of 472 preference is used to represent the set of acceptable UPQOS (TI with 473 corresponding SI) values in SDP. This allows for prioritisation 474 during negotiation. 476 A session control element can use different forms to represent the 477 same SI information depending on which other session control element 478 it is interfacing with. For example, a Service Provider can use the 479 QoS Flavour form on the interface with the end-user and use a 480 standardised form (Standard QoS parameters or Standard QoS Class) on 481 the interface with a network operator. The service provider is 482 assumed to perform the correct translation between the different 483 representation forms. 485 6. End-to-end user perceived QoS negotiation scenarios 487 The purpose of this section is to explain the end-to-end User 488 Perceived QoS (UPQoS) negotiation procedure and to provide some 489 example scenarios describing the SDP negotiation of UPQoS values. 490 The general principles behind the end-to-end UPQoS negotiation 491 procedure are explained in section 6.1. Section 6.2 shows that the 492 SDP negotiation of UPQoS values can be modelled by a basic or 493 enhanced QoS offer-answer model. Section 6.3 finally illustrates the 494 UPQoS negotiation procedure with example scenarios covering both 495 roaming and non-roaming cases. 497 6.1. Principles of the end-to-end User Perceived QoS negotiation 498 procedure 499 Introducing the flexibility to choose a different UPQoS per session 500 for the same type of communication requires the User Perceived QoS 501 (UPQoS), expressed as an ordered set of TI and SI values, to be 502 negotiated end-to-end at the session signalling level during the 503 session establishment. 505 To guarantee the end-to-end character of the negotiated TI and SI 506 values, session control elements of all involved parties in the 507 session signalling path (local access network, service provider, 508 end-user) shall be able to participate in the negotiation process. 510 There is only one UPQoS negotiation procedure per SIP transaction 511 for both sending and receiving directions, but UPQoS requirements 512 (expressed as an ordered set of TI and SI values) can be different 513 in the sending and receiving direction. 515 It is important to note that the negotiation flows shown in the 516 following sections are using the SIP protocol as an example only. 517 The entire framework for end-to-end "User Perceived QoS" negotiation 518 and the associated SDP extensions which this document proposes to 519 specify, are independent of the session signalling protocol being 520 used. The same procedures can therefore also be used in the context 521 of e.g. BICC, MEGACO/H.248,... 523 6.2. Basic versus enhanced QoS offer-answer model 525 This draft uses a number of terms as defined in [1] which refer to 526 the roles played by participants in SIP communications. This 527 document also refers to [3] for the definition of certain SIP 528 extensions (e.g. SIP 183-session-progress). Using this terminology, 529 a simple SIP transaction can be modelled as a communication between 530 a UAC and a UAS. A UAC is a logical entity initiating the SIP 531 transaction with a request (e.g. SIP INVITE) and a UAS is a logical 532 entity that responds to a SIP request (e.g. SIP 200-OK or SIP 183- 533 session-progress), generally acting on behalf of some user. 535 6.2.1. Current SDP offer-answer model 537 As described in [6], the usage of SDP within SIP follows an "offer- 538 answer" model. SDP negotiation within SIP can be modelled as 539 follows: One side (offerer) offers an SDP that provides its own view 540 of the session, and the other side (answerer) answers the SDP with a 541 matching one. The offer can be differentiated in sending and 542 receiving directions by marking media streams as send-only or 543 receive-only. If no marking is present the default is both send and 544 receive. According to [6] the "offer-answer model" may occur in two 545 ways, which are referred to as the "basic" and "enhanced" model for 546 the rest of this document: 548 - Basic offer-answer model 549 The offerer offers an SDP. The answerer is only allowed to 550 reject or to restrict the offer. In the latter case, the answer 551 contains an SDP that is a sub-set of the original SDP proposed 552 by the offerer (the number of "m=" lines remains the same). 554 - Enhanced offer-answer model 555 The offerer offers an SDP. The answerer MAY extend the offer 556 with additional elements or capabilities not listed in the 557 original SDP offer. In this case the answer contains an SDP 558 that is a super-set of the original SDP proposed by the offerer 559 (even when the number of "m=" lines remains the same). 561 A common example of the Basic offer-answer model is where a UAC 562 offers an SDP, containing a list of codecs the UAC is willing to 563 use, in a SIP INVITE. The UAS answers with a SIP 200-OK (this could 564 equally be a SIP 183-session-progress) containing a sub-set of the 565 SDP offered by the UAC, containing only those codecs that the UAS is 566 willing to use for this particular SIP transaction. 568 A common example of the enhanced offer-answer model is where the UAS 569 answers with a SIP 200-OK (this could equally be a SIP-183-session- 570 progress) containing additional codecs, not listed in the 571 corresponding stream in the offer, that the UAS is willing to use 572 for this particular SIP transaction. 574 In both cases, the final result of the offer-answer model is a list 575 of codecs for a given medium stream; any of those codecs can be 576 freely used during the session without sending a SIP message. 578 6.2.2. Offer-answer model for UPQoS negotiation 580 This document proposes to reuse the basic and enhanced offer-answer 581 model of [6] for negotiating lists of UPQoS values. The offerer 582 determines per medium stream a set of acceptable UPQoS levels, 583 expressed in SDP as an ordered set of TI and SI values. The list of 584 acceptable UPQoS values, called "Requested QoS", is carried in the 585 SDP offer in one of three formats, as described in section 5, and in 586 decreasing order of importance, to allow prioritisation during 587 negotiation. 589 +---------+ Requested QoS +----------+ 590 | |--------------------->| | 591 | offerer | Negotiated QoS | Answerer | 592 | |<---------------------| | 593 +---------+ +----------+ 595 Basic offer-answer model 597 +---------+ Requested QoS +----------+ 598 | |--------------------->| | 599 | | Extended QoS | | 600 | offerer |<---------------------| Answerer | 601 | | Negotiated QoS | | 602 | |--------------------->| | 603 +---------+ +----------+ 605 Enhanced offer-answer model 607 Figure 1: Basic versus Enhanced QoS offer-answer model 609 In the basic offer-answer model (see top of Error! Reference source 610 not found.) the answerer is only allowed to reject or to restrict 611 the "Requested QoS". The SDP answer contains a "Negotiated QoS", 612 that is, a sub-set of the original "Requested QoS". 614 In the enhanced offer-answer model (see bottom of Error! Reference 615 source not found.) the answerer MAY extend the "Requested QoS" with 616 additional QoS levels not listed in the original "Requested QoS". In 617 this case, the SDP answer contains an "Extended QoS", that is, a 618 super-set of the original "Requested QoS" proposed by the offerer. 619 To conclude the enhanced offer-answer model, the offerer selects a 620 subset "Negotiated QoS" of the "Extended QoS" and sends this 621 "Negotiated QoS" back to the answerer. 623 In both cases, the final result of the offer-answer model is the 624 "Negotiated QoS", which is a decreasing ordered list of UPQoS (TI 625 and SI) values per medium stream retained for the session. Any of 626 those negotiated TI/SI combinations can be freely used during the 627 session without sending a SIP message. 629 6.3. Example scenarios 631 This section shows how the basic offer-answer model can be used for 632 SDP negotiation of UPQoS values in different scenarios. 634 6.3.1. Simple UAC-UAS scenario 636 A simple example (Error! Reference source not found.) is a UAC 637 trying to set up a SIP transaction with a UAS. The QoS offer-answer 638 model allows the UAC to specify per medium stream a "Requested QoS". 639 The "Requested QoS" consists of a decreasing set of UPQoS levels, 640 expressed an ordered list of TI and SI values, acceptable to the 641 UAC. Suppose for this example that the "Requested QoS" specifies 642 acceptable UPQoS levels A,B and C for audio and acceptable UPQoS 643 levels D and E for video. 645 The "Requested QoS" is carried in the SDP description included in 646 the SIP INVITE, using for SI one of the three formats described in 647 section 5. Upon evaluation of the preference list of UPQoS values in 648 the "Requested QoS", the UAS can restrict the "Requested QoS". The 649 UAS SHOULD use the UPQoS value with the highest preference that is 650 acceptable to it. 652 Consequently the SIP 200-OK sent back to the UAC contains an SDP 653 carrying the "Negotiated QoS", that is, a sub-set of the original 654 "Requested QoS" containing only those UPQoS values that the UAS is 655 willing to use for this particular SIP transaction. Suppose for this 656 example that the "Negotiated QoS" specifies UPQoS levels A and B for 657 audio and UPQoS level E for video. This means that the UAS is not 658 willing for this particular session, to support the lowest QoS level 659 C for audio nor the highest QoS level D for video. 661 The "Negotiated QoS" is equal to the "Requested QoS" in case the UAS 662 accepts to support all the UPQoS values originally proposed by the 663 UAC. The UAS MUST list the "Negotiated QoS" levels in the same 664 relative order they were present in the "Requested QoS" to guarantee 665 that the same QoS level is used by both User Agents. 667 In Error! Reference source not found. the SIP ACK sent back from UAC 668 to UAS is shown for completeness even though it MUST not contain any 669 SDP in this example (as currently described in [1]). 671 +-----+ SIP INVITE, SDP �Requested QoS� +- ---+ 672 | |------------------------------------------>| | 673 | | SIP 200-OK or SIP 18-session-progress | | 674 | UAC | SDP �Negotiated QoS� | UAS | 675 | |<------------------------------------------| | 676 | | ACK or PRACK | | 677 | |------------------------------------------>| | 678 +-----+ +-----+ 680 Figure 2: Simple UAC � UAS scenario 682 An end-user should be able to specify for each medium stream whether 683 the successful establishment of a bearer "with a specific QoS" is 684 required. This is enabled by co-ordinating the simultaneous usage of 685 the mandatory or optional "qos" SDP extensions of [3] with the SDP 686 extensions for UPQoS identified in this document. 688 According to [3] in case resource reservation is required as a 689 precondition before proceeding with the session, it is necessary to 690 replace the SIP 200-OK in Error! Reference source not found. by a 691 SIP 183-session-progress and the SIP ACK by a SIP PRACK. The "qos" 692 attribute indicates whether end-to-end resource reservation is 693 optional or mandatory, and in which direction (send, recv, or 694 sendrecv). 696 When the "qos" attribute indicates mandatory, this means that the 697 participant who has received the SDP does not proceed session setup 698 until resource reservation has been completed in the specified 699 direction. This document builds further upon the concept of [3] in 700 the following way. If the "qos" attribute is set to mandatory, the 701 UPQoS SDP extensions allow participants to indicate that resources 702 need to be reserved end-to-end, not only in which direction, but 703 also with which Quality of Service. Namely, with a Quality of 704 Service compliant with the set of acceptable UPQoS values carried in 705 the SDP extensions proposed in this document. 707 If the "qos" attribute is set to optional, the UPQoS (TI and SI) SDP 708 extensions allow participants to indicate with which Quality of 709 Service resources should be reserved, but only if possible, that is 710 without blocking the session set up process. 712 If for mandatory media an end-user does not want best effort 713 quality, the end-user should not indicate best effort as an 714 acceptable QoS level. For optional media, best effort quality is 715 implicitly assumed to be acceptable. 717 Coming back to the example with the lists of UPQoS values for 718 "Requested QoS" and "Negotiated QoS" mentioned earlier, suppose the 719 UAC had specified that reservation of resources for the audio 720 component (with acceptable UPQoS levels A,B and C) was optional in 721 the receiving direction whereas reservation of resources for the 722 video component (with acceptable UPQoS levels D and E) was mandatory 723 also in the receiving direction. This effectively means that the UAC 724 only wishes to continue with the session if the UAS agrees and 725 succeeds to reserve resources towards UAC for the video with a 726 Quality of Service not lower than E and not higher than D. 728 Making resource reservation for the audio component optional means 729 that the UAC would like a Quality of Service level between A and C 730 but it will accept the medium stream in the worst case even with no 731 QoS guarantees (best effort). 733 As the "Negotiated QoS" in this example did contain the UPQoS level 734 E for the video the UAC would accept the session. Suppose UAS 735 rejected all A,B and C for the audio component ("Negotiated QoS" 736 does not contain any UPQoS values for the audio component), the UAC 737 would still accept the session even with best effort quality of 738 service for the audio. 740 6.3.2. UAC � proxy server � UAS scenario 742 According to [1], SIP requests can be sent directly from a UAC to a 743 UAS (QoS offer-answer model for this case was explained in previous 744 section), or they can traverse one or more proxy servers along the 745 way. 747 It is also clearly stated in [1] that proxies MAY modify any part of 748 the SIP message that are not integrity-protected, except those 749 needed to identify call legs. Furthermore proxies generally do not 750 modify the session description, but MAY do so. Also from [1] we 751 learn that a proxy can indicate that it wants to remain in the 752 request path via a Record-Route header field, although typically 753 only the first request within a call traverses all proxies while 754 subsequent requests are exchanged directly between user agents. 756 +-----+ +--------+ +-----+ 757 | | SIP INVITE | | SIP INVITE | | 758 | | SDP �Requested QoS� | | SDP �Modified QoS� | | 759 | |--------------------->| |--------------------->| | 760 | UAC | SIP 200-OK or | proxy | SIP 200-OK or | UAS | 761 | | SIP 183 | SIP | SIP 183 | | 762 | | SDP �Negotiated QoS� | server | SDP �Negotiated QoS� | | 763 | |<---------------------| |<---------------------| | 764 | | ACK or PRACK | | ACK or PRACK | | 765 | |--------------------->| |--------------------->| | 766 +-----+ +--------+ +-----+ 768 Figure 3: UAC � proxy server � UAS scenario 770 From the statements above, quoted from [1], we can derive the 771 following implications on the QoS offer-answer model. Firstly the 772 simple UAC-UAS model does not suffice, as one or more proxy servers 773 can be in between UAC and UAS (Error! Reference source not found.). 774 Also it is possible that different proxies are operated by different 775 providers; e.g. a first proxy in the local access network, a second 776 proxy operated by the user�s Internet service provider. Furthermore, 777 proxies may decide to forward the SIP request or modify the SDP 778 based on local policies and information contained in the SIP 779 request. 781 Considering the example in Error! Reference source not found., the 782 impact of intermediate proxy servers on the QoS offer-answer model 783 can be modelled in the following way. Proxies MAY modify the 784 "Requested QoS" received from the UAC to a "Modified QoS" based on 785 different criteria. Such criteria could include information 786 regarding subscription profile of the user, specific service 787 settings, time of day/week or any other local network policies. Of 788 course the UAS may also perform a final restriction on the set of 789 UPQoS values resulting in the "Negotiated QoS". 791 Thus, the "Negotiated QoS" will be equal to the "Requested QoS" only 792 if the "Requested QoS" was compliant with the subscriber profile 793 with service settings, not conflicting with local network policies 794 and acceptable to the UAS. 796 Assuming a basic offer-answer model in the example of Error! 797 Reference source not found., proxies are only allowed to make 798 modifications in the sense of restrictions. The only exception is 799 when the UAC does not include a "Requested QoS" in the SIP INVITE 800 message. In this case a SIP proxy in the end-user�s service provider 801 domain MAY propose a "Modified QoS" itself. If the UAC does not 802 specify a "Requested QoS" in the session set up, the "Modified QoS" 803 MAY be deduced by the user�s service provider either implicitly from 804 access information about the UAC (terminal capabilities, 805 applications in terminal, access type,etc.), or from subscription or 806 service information (the user�s service provider can propose 807 subscription packages with different levels of QoS for the different 808 medium streams involved in a communication service). 810 Note that on the response path this "Negotiated QoS" is distributed 811 (in a SIP 200-0K or SIP 183-session-progress) to all involved 812 session control elements all the way from UAS to UAC side. At this 813 point, proxies in the local access networks MAY use this "Negotiated 814 QoS" information to inform the transport layer about the 815 QoS/resources that have been authorized by the session layer for 816 each medium stream of the multimedia session. This topic is however 817 not the subject of this document. [4] Already describes SIP 818 extensions for media authorization which enable this correlation 819 between the resources authorized by the call/session signalling 820 architecture and the actual network resources requested by the UA at 821 bearer setup. 823 It is important to understand also that this document does not 824 describe a way to carry bearer setup messages into SIP/SDP. The SDP 825 extensions that this document proposes to specify, are a way to make 826 sure that existing bearer setup mechanisms (e.g. RSVP, Diffserv, 827 MPLS) are getting the correct and complete input, enabling them to 828 reserve the resources with a Quality of Service that matches exactly 829 the end-user expectations. 831 After all parties (end-user, local access network, service provider) 832 involved in the session signalling have agreed upon the UPQoS 833 values, appropriate resources have to be reserved in the network to 834 deliver this QoS. Therefore UAC and UAS need to be able to translate 835 the final TI and SI values negotiated at session/service level into 836 the correct transport level QoS parameters, in order to trigger the 837 corresponding bearer setup mechanisms (e.g. RSVP, Diffserv). 839 Involvement of proxies from the local access network and the end- 840 user�s service provider domain in the QoS offer-answer model brings 841 strong advantages for delivering end-to-end QoS guarantees, 842 especially in situations of local network overload. The 843 participation of a proxy from the end-user�s service provider domain 844 in the QoS offer-answer model ensures that the "Negotiated QoS" is 845 compliant with the QoS limits specified in the user�s subscription 846 profile and service settings. Communicating this "Negotiated QoS" on 847 the response path to a proxy in the local access network (where the 848 user is actually located), is effectively creates awareness in the 849 local access network about user specific subscription/service 850 information; namely the QoS limits for each medium stream of the 851 session that are allowed by the service provider of that particular 852 end-user. 854 Suppose that after SDP negotiation, when the actual session is 855 ongoing and media streams are being transferred between UAC and UAS, 856 suddenly a situation of network congestion occurs in that segment of 857 the local access network where the end-user is located. Then this 858 document enables the local access network to take more intelligent 859 decisions than just downgrading the QoS of the end-user arbitrarily. 860 Indeed, by respecting the QoS limits specified in the "Negotiated 861 QoS" information when downgrading the QoS for this particular end- 862 user, the local access network is in fact ensuring that the end-user 863 will still experience the QoS delivered to him as compliant with the 864 Quality promised to him in the subscription. As such, the QoS offer- 865 answer model enables service providers to sell attractive 866 subscription packages with guarantees on true "end-to-end" Quality 867 of Service, even in roaming conditions and even under circumstances 868 of local network overload. 870 6.3.3. SI formats example 872 To illustrate the use of the three possible formats which can be 873 used to express the SI requirements in SQP, SQC or QF format, as 874 explained in section 5, a practical example based on Error! 875 Reference source not found. is given in this section. 876 Suppose the UAC uses in the SIP INVITE the "QoS flavour" format 877 hereby indicating to the proxy of the service provider for example 878 that both "Gold" and "Silver" are acceptable UPQoS/SI values for the 879 voice component. "Gold" and "Silver" can be commercial names for QoS 880 packages, the correct interpretation of which are only known to the 881 end-user and its Internet Service Provider (e.g. defined in a 882 subscription). 884 Suppose for this example that the proxy of the service provider 885 decides, after checking several criteria (e.g. local network 886 policies, subscription profile of the end-user, service 887 settings,...) that only "Silver" can be retained. Before forwarding 888 this information to the UAS the service provider will have to 889 perform the correct translation from the non-standardized "QoS 890 flavour" representation form into one of the standardized formats 891 "Standard QoS class" or "Standard QoS parameters". 893 Since the usage of the QoS Flavour format always assumes a pre- 894 defined and well-understood interpretation of the QoS information 895 sent over the considered interface, the proxy unambiguously knows 896 this mapping. "Silver" is mapped to the correct set of corresponding 897 "Standard QoS parameters" which are then sent to the UAS. 899 A typical example where the first proxy could decide to use the 900 "Standard QoS class" occurs when there is a need to cross another 901 proxy operated by a different provider before reaching the UAS. 902 There is no specific motivation to choose the "Standard QoS class" 903 instead of the "Standard QoS parameters" format besides the fact 904 that the former is an abbreviated way to convey similar type of 905 standardized information. 907 7. Security considerations 908 There is no foreseen specific security issue associated with the 909 framework proposed by this document. The UPQoS negotiation framework 910 is not intended to solve any security issue. 912 8. Conclusions 914 This document described a framework to negotiate end-to-end the 915 "Quality" of a multimedia session "as the end-user wants to perceive 916 it". This UPQoS (User Perceived QoS) negotiation is achieved at 917 session signalling level using two types of new SDP extensions, 918 which this document proposes to specify. All session control 919 elements - user agents as well as proxies - involved in the 920 multimedia session setup may participate to the UPQoS negotiation. 921 Secondly this document proposed to specify SDP extensions that allow 922 to express the UPQoS level per medium stream during the UPQoS 923 negotiation. The first type of SDP extensions characterise the 924 traffic type of the bearer associated with the medium stream, the 925 second type of SDP extensions characterise the tolerance/sensitivity 926 level of the service requested by the end-user with respect to the 927 QoS information carried in the first type of SDP extensions. 929 To conclude we summarise the main advantages of the end-to-end User 930 Perceived QoS negotiation framework as proposed by this document. 931 First of all it allows end-users to express to the network per 932 medium stream the "Quality" as they want to perceive it. End-users 933 can control their expenses and QoS more flexibly. Service providers 934 can develop new charging mechanisms for QoS enabled sessions based 935 on the true "Quality" of the session as experienced by the end-user. 936 Service providers can sell more attractive subscription packages 937 with guarantees on true "end-to-end" Quality of Service limits, even 938 in roaming conditions and even under circumstances of local network 939 overload. Enabling providers to make more intelligent decisions on 940 QoS provisioning allows improvement of network scalability. The 941 introduction of new codec types is simplified. 943 9. Acknowledgements 945 This document is a result of an ongoing discussion among many people 946 from Alcatel and other companies (KPN,...). We would hereby like to 947 thank all the people who provided valuable comments and input that 948 improved the quality of this document. 950 Funding for the RFC Editor function is currently provided by the 951 Internet Society. 953 10. References 955 [1] Rosenberg J., Schulzrinne H., Handley M., Schooler E., "SIP, 956 Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt, Work 957 in Progress. 959 [2] M. Handley, V. Jacobson, C. Perkins: "SDP: Session Description 960 Protocol", draft-ietf-mmusic-sdp-new-03.txt, Work in progress. 962 [3] W. Marshall et al. "Integration of Resource Management and 963 SIP", draft-ietf-sip-manyfolks-resource-02.txt, Work in progress. 965 [4] W. Marshall et al. "SIP Extensions for Media Authorization", 966 draft-ietf-sip-call-auth-02.txt, Work in progress. 968 [5] Kutscher, Ott, Bormann and Curcio, "Requirements for Session 969 Description and Capability Negotiation", draft-ietf-mmusic-sdpng- 970 req-01.txt, Work in progress. 972 [6] Rosenberg J., Schulzrinne H., "An offer/answer model with SDP" 973 draft-rosenberg-mmusic-sdp-offer-answer-00.txt, Work in Progress. 975 [7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 976 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 977 Specification", RFC 2205, September 1997. 978 [8] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, 979 "An Architecture for Differentiated Service", RFC 2475, December 980 1998. 982 [9] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 983 Switching Architecture", RFC 3031, January 2001. 985 [10] S. Bradner, "Key words for use in RFCs to Indicate Requirement 986 Levels", BCP 14, RFC 2119, March 1997 988 [11] S. Bradner, "The Internet Standards Process - Revision 3", BCP 989 9, RFC 2026, October 1996 991 11. Authors� Addresses 993 Lieve Bos 994 Alcatel 995 Francis Wellesplein 1 996 2018 Antwerpen 997 Belgium 998 Phone: +32 3 241 58 91 999 EMail: Lieve.Bos@Alcatel.be 1001 Suresh Leroy 1002 Alcatel 1003 Francis Wellesplein 1 1004 2018 Antwerpen 1005 Belgium 1006 Phone: +32 3 240 85 50 1007 EMail: Suresh.Leroy@Alcatel.be 1008 Jozef Vandenameele 1009 Alcatel 1010 Francis Wellesplein 1 1011 2018 Antwerpen 1012 Belgium 1013 Phone: +32 3 240 4361 1014 EMail: Jozef.Vandenameele@Alcatel.be 1016 Juan-Carlos Rojas 1017 Alcatel CIT 1018 Le Mail 1019 44708 Orvault Cedex 1020 France 1021 Phone: +33 2 5178 1282 1022 E-mail: Juan-Carlos.Rojas@Alcatel.fr 1024 Laurent Thiebaut 1025 Alcatel CIT 1026 10 Rue Latecoere 1027 78140 Velizy 1028 France 1029 Phone: +33 1 3077 0645 1030 E-mail: Laurent.Thiebaut@Alcatel.fr 1032 Pieter Veenstra 1033 KPN 1034 P.O. Box 30150 1035 2500 GD Den Haag, Netherlands 1036 Phone: +31 70 3439121 1037 Email: p.k.veenstra@kpn.com 1039 12. Full copyright statement 1041 Copyright (C) The Internet Society (2000). All Rights Reserved. 1043 This document and translations of it may be copied and furnished to 1044 others, and derivative works that comment on or otherwise explain it 1045 or assist in its implementation may be prepared, copied, published 1046 and distributed, in whole or in part, without restriction of any 1047 kind, provided that the above copyright notice and this paragraph 1048 are included on all such copies and derivative works. However, this 1049 document itself may not be modified in any way, such as by removing 1050 the copyright notice or references to the Internet Society or other 1051 Internet organizations, except as needed for the purpose of 1052 developing Internet standards in which case the procedures for 1053 copyrights defined in the Internet Standards process must be 1054 followed, or as required to translate it into languages other than 1055 English. 1057 The limited permissions granted above are perpetual and will not be 1058 revoked by the Internet Society or its successors or assigns. 1060 This document and the information contained herein is provided on an 1061 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1062 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1063 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1064 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1065 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1067 Expires May, 2002