idnits 2.17.1 draft-guenkova-mmusic-e2enp-sdpng-00.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 624 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 700 has weird spacing: '...lzrinne et al...' -- 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.) -- The document date (March 25, 2002) is 8069 days in the past. Is this intentional? 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? '1' on line 675 looks like a reference -- Missing reference section? '2' on line 681 looks like a reference -- Missing reference section? '3' on line 685 looks like a reference -- Missing reference section? '4' on line 688 looks like a reference -- Missing reference section? '5' on line 692 looks like a reference -- Missing reference section? '6' on line 696 looks like a reference -- Missing reference section? '7' on line 700 looks like a reference -- Missing reference section? '8' on line 704 looks like a reference -- Missing reference section? '9' on line 708 looks like a reference -- Missing reference section? '10' on line 711 looks like a reference -- Missing reference section? '11' on line 714 looks like a reference -- Missing reference section? '12' on line 718 looks like a reference -- Missing reference section? '13' on line 722 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group T. Guenkova-Luy, 2 Internet-Draft A. Kassler 3 Document:draft-guenkova-mmusic-e2enp-sdpng-00.txt University of Ulm 4 Expires: September 25, 2002 5 J. Eisl 6 Siemens AG 8 D. Mandato 9 Sony International 10 (Europe) GmbH 12 March 25, 2002 14 Efficient End-to-End QoS Signaling - concepts and features 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all 19 provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document analyzes issues for providing both sedentary and 41 mobile users of multiparty, multimedia communication services with 42 efficient mechanisms for coping with unstable network conditions 43 and limited resource availability, conforming to the users' QoS 44 requirements and expectations. To this extent, the concept of an 45 efficient end-to-end QoS signaling mechanism is needed, dealing 46 not only with capabilities/QoS negotiation, but also with 47 efficient re-negotiations and coordinated resource management. 48 Requirements of a protocol (thereinafter, the "End-to-End 49 Negotiation Protocol" - E2ENP) [1], as well as a possible 51 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 53 implementation thereof, based on extensions of SDPng [2] and on 54 the use of SIP [3], are then discussed. Finally, differences 55 and/or synergies with existing solutions and proposals (especially 56 with [4] and [5]), as well as security considerations, are 57 provided. 59 Table of Contents 61 1. Introduction 2 62 1.1 Motivations 2 63 1.2 Problem Statement 2 64 1.3 Scope of this document 3 65 2. Definition of Terms 4 66 3. The concept 5 67 3.1 Coping with unstable environment conditions 6 68 3.2 Hierarchical QoS Specification 7 69 3.3 Inter-stream QoS constraints 7 70 3.4 Planning counteractions ahead 8 71 3.5 Independence from network aspects 8 72 3.6 Mapping of the quality settings on codec definition 9 73 3.7 Third-Party-Assisted Negotiation 9 74 4. The features 10 75 5. Security Considerations 11 76 6. Related Work 11 77 7. Conclusions 13 78 8. References 13 79 9. Author's addresses for comments and discussions 15 80 10. Acknowledgements 15 82 1. Introduction 84 1.1 Motivations 86 The Internet has proven to be a successful architecture for 87 delivering a broad set of electronic services (including - among 88 many others - telephony, electronic messaging, and audio/video 89 (A/V) services), not only to sedentary but also to nomadic users. 90 Micro/macro IP mobility and wireless IP technologies in fact pave 91 the way to the full integration of the Internet with the second 92 and third generation of mobile phone systems. In order to achieve 93 this goal, next generation IP networks and applications will have 94 to address the increasingly important challenges of wireless 95 access, mobility management, the provision of Quality of Service 96 (QoS), and multimedia services. 98 1.2 Problem Statement 100 A paramount problem that mobile users will face within this 101 context is how to cope with limited amounts of resources at the 103 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 105 end-systems and within the network, under unstable environmental 106 conditions. It is expected that mobile users will no longer be 107 able to rely on their QoS contracts being supported over the whole 108 duration of a session by the network infrastructure, due to 109 various reasons like: wireless link quality degradations, 110 handovers, limited amount of resources. By assuming proper 111 resource overprovision in the backbone, one can expect that these 112 problems will most likely be concentrated in the access network, 113 especially in the radio part thereof, and even on the end-systems. 114 Since users typically have business relationships with specific 115 network providers (e.g. a subscription with an ISP or a prepaid 116 phone card), two possible types of handover may occur: 117 - horizontal handovers: occur within a given administrative 118 domain of a network provider, and within the same type of access 119 network; 120 - vertical handovers: occur across two different types of access 121 networks and/or across the administrative boundary between two 122 network providers. 123 When dealing with handovers, users must be prepared to face 124 changes in network resource availability, depending not only on 125 the type of access network, but also on the type of business 126 relationships the users may have with the various network 127 providers. In some extreme cases, the users might try to access 128 the network owned by a network provider, with which the user has 129 no business relationship at all, or which offers limited amount of 130 resources. Pricing aspects also play a key role. 131 Within this context, multiparty multimedia applications will need 132 an effective and efficient way of handling QoS fluctuations at the 133 network layer. 134 In particular, the sheer negotiation of capabilities (like codecs) 135 is hereby regarded as necessary but not sufficient for meeting the 136 users' QoS expectations. Intelligent, adaptive applications can in 137 fact provide predictive QoS on an end-to-end basis only if end- 138 peers are able to negotiate also QoS aspects directly affecting 139 the application performance, according to the users' QoS 140 expectations. This combined information enables applications 141 effectively choosing the best adaptation strategy in reaction to a 142 given QoS fluctuation [1]. 144 1.3 Scope of this document 146 Coping with the aforementioned issues, this document presents a 147 concept for negotiation of capabilities and QoS at the application 148 level, triggered by QoS requirements of the end-user (the E2ENP 149 concept), which can be realized by either deriving a new specific 150 protocol, or enhancing existing ones. As an example of the latter 151 option, a possible E2ENP implementation based on extensions of 152 SDPng [2] and on the use of SIP [3] is also discussed. 154 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 156 2. Definition of Terms 158 Adaptation Path (AP) 159 An ordered set of QoS contracts that end-systems use for employing 160 adaptation strategies in a preplanned way. The nominal QoS 161 contract indicates the one the end-system should preferably try to 162 enforce. Should this not (or no longer) be possible, the AP offers 163 alternative QoS contracts (and, optionally, specific rules for 164 choosing them) for degrading the QoS level in a controlled way. 166 Application Level QoS 167 An end-system internal representation of QoS specification (e.g. 168 XML description), derived from User Level QoS specification. 170 Capability 171 The ability to perform certain tasks and/or to handle certain 172 information types. A single capability is associated with a 173 certain amount of hardware and/or software resources (each 174 handling a given information type) and can be configured to 175 produce different QoS levels. On the other hand a given QoS level 176 can be associated with different capability sets (e.g. different 177 codecs can offer the same QoS level). 179 Intermediate Components (IM) 180 Any network element situated on the signaling and/or the data path 181 between two end-systems and which can understand the protocol the 182 end-systems use (at least on the network level). Examples are: 183 routers, proxies, independent services, etc. 185 Mediator 186 The role an end-peer can take for redirecting incoming calls to 187 another end-peer(s) according to some settings in the user 188 profile. A part of this role is to provide QoS satisfaction for 189 the user(s) in a way the Mediator itself (considering the end- 190 peer's multimedia capabilities) cannot handle. 192 Peer 193 A service or an end-device (associated with an end-user). This 194 term has equivalent meaning with the terms end-peer and party, 195 which are interchangeably used throughout this document. 197 QoS change 198 The change of the QoS contract initiated by the service user or by 199 an application within the context of a predefined AP. 201 QoS contract 202 An agreement between a service user and a service provider , 203 specifying QoS requirements and constraints, as well as the 204 policies required to keep track of a single QoS level during the 205 given service execution. 207 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 209 QoS level 210 A discrete region of the multidimensional QoS space characterizing 211 a service. Users perceive distinct QoS levels as the result of 212 applying certain QoS contracts to the given services. 214 QoS parameter 215 A functional representation of a single characteristic of a given 216 QoS aware service (e.g. network bitrate, network overall end-to- 217 end delay, but also parameters like video frame rate, video frame 218 size, audio sampling rate, number of audio channels, etc.), which 219 identifies a measurable QoS related quantity. 221 QoS profile 222 A collection of data specifying the end-peer preferences in terms 223 of QoS, concerning the usage of a given service. The QoS profile 224 is the end-system internal representation of the user's QoS 225 preferences within a QoS aware system. The QoS profile can contain 226 one or several Application Level QoS specifications. 228 QoS violation 229 The violation of one or several QoS contracts within an AP, caused 230 by the network and/or Service Provider and/or local system. 232 User Level QoS specification 233 The QoS as users expect to perceive, eventually expressed in non- 234 crisp terms by non-expert users. This QoS specification is an 235 application-specific issue, depending on user interface aspects. 237 3. The concept 239 This section defines requirements for an efficient end-to-end QoS 240 signaling mechanism for dealing with multiparty, multimedia 241 services. This concept also embraces the case of multi-streams 242 applications like online-games combined with A/V sessions. 243 The "handling of QoS" shall be achieved through the negotiation of 244 hardware/software configuration information and the negotiation 245 and enforcement of QoS contracts, which are derived from the user 246 preferences : 247 - a QoS contract shall capture user's QoS expectations, as well 248 as network provider policies for enabling a comprehensive QoS 249 adaptation process (this means for instance to control that the 250 QoS levels fit into the predefined policies, or to control the 251 amount of resources by up-/downgrading QoS upon detection of QoS 252 changes / QoS violations); 253 - a QoS contract shall also capture configuration information 254 concerning network resources, as well as the resources and 255 capabilities of the involved QoS aware end-systems (for instance, 256 some codecs like variable bitrate video-codecs can be differently 257 preset to produce different QoS directly perceivable by the user: 258 the sheer definition of codecs is thus not sufficient for 260 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 262 determining the amount of local and network resources to reserve 263 when QoS should be supported). 265 Before starting a negotiation, each end-peer shall derive the 266 negotiable QoS contracts from existing information concerning both 267 users' QoS expectations and type/amount of available resources, by 268 possibly applying the following refinement/validation process: 269 1. users specify the User Level QoS; 270 2. applications derive Application Level QoS by mapping User Level 271 QoS into QoS contracts detailing specific aspects (e.g. video 272 frame rate, video frame size, image quality, etc); 273 3. the mapping of Application Level QoS on the end-system 274 capabilities (i.e. the end-system hardware and software 275 configuration - e.g. supported codecs), originates QoS contract 276 Sketches, which represent the Application Level QoS that the end- 277 system can theoretically support; 278 4. the validation of QoS contract Sketches against network 279 provider policies for supporting QoS, originates Validated 280 Application Level QoS contracts. These valid contracts constitute 281 a common vocabulary, which the local and the remote end-systems 282 can use for negotiating the establishment of QoS aware 283 communications, and for efficiently dealing with QoS re- 284 negotiations thereof. Those Application Level QoS which have 285 failed the validation, could still be used in special cases like 286 vertical handovers, dynamic end-system changes (e.g. due to end- 287 system up-/downgrading), etc. 289 For the sake of simplicity, this document refers thereinafter to 290 "Validated Application Level QoS contracts" as "Application Level 291 QoS". These are the negotiable QoS contracts end-peers are 292 expected to deal with during QoS negotiations and QoS re- 293 negotiations. 294 In order to allow end-peers reserving network resource in a 295 coordinated manner, during the negotiation process the sender side 296 can derive network-level QoS contracts (e.g. the TI(Traffic 297 Information) and SI(Sensitivity Information) information presented 298 in [4]) from the negotiable Application Level QoS. 300 3.1 Coping with unstable environment conditions 302 In order to allow users achieving QoS with limited amounts of 303 resources at the end-system and in the network, under unstable 304 environment conditions, the application developers and the users 305 shall be prepared to increase renegotiation speed, for instance by 306 proactively planning proper actions at negotiation time. 307 As aforementioned, QoS Contract information is complementary to 308 capability information. As such, the E2ENP may advantageously 309 negotiate QoS Contracts and capabilities independently. For 310 instance some codecs might be dynamically downloadable: having 311 negotiated QoS contracts independently of such codes, allows end- 313 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 315 peers saving time (critical aspect of re-negotiations), by simply 316 referencing the pre-negotiated QoS contracts and binding the newly 317 available codecs with those contracts. 319 3.2 Hierarchical QoS Specification 321 Grouping streams is mainly useful for allowing QoS aware 322 applications to handle groups as a whole when balancing quality to 323 resource availability under certain environmental conditions. 324 For instance, in online gaming applications it can make sense to 325 augment the gaming experience by allowing each player to keep in 326 audio/visual contact with the other players. To this extent, it is 327 possible to distinguish (and therefore treat differently) various 328 groups of streams, each grouping all the streams between the given 329 player and another player. The description of these groups of 330 streams is subject to negotiation. 331 Furthermore, the developers and the users of multiparty multimedia 332 applications dealing with multiple streams may advantageously 333 arrange streams by recursively applying the grouping process, 334 based on high-level criteria aiming to improve resources 335 orchestration among multiple streams. For instance, a player can 336 arrange the A/V streams by identifying multiple concurrent 337 instances of audio- or videoconferences, one with the own team 338 members and one with each other team. This optional form of 339 streams grouping is managed locally by the end-peers (and thus is 340 not subject to negotiation). 341 The resulting hierarchical structure is topologically equivalent 342 to a tree, where each leaf represents a stream, and each internal 343 node represents a group of streams (or, recursively, of groups). 345 3.3 Inter-stream QoS constraints 347 Multi-media applications may deal with multiple streams of 348 different types (i.e. audio, video, and data). To this extent, 349 users of such applications may wish to specify their QoS 350 preferences for each single stream, but also any parameter that 351 might determine inter-stream behavior. Typically, videoconference 352 applications deal with voice and video streams, which must be 353 synchronized (time synchronization). If the media codec and stream 354 format itself does not provide means for synchronizing, it is a 355 requirement that inter-stream correlation information is available 356 and negotiated. This correlation can be generalized by introducing 357 the specification of QoS constraints applicable to a given bundle 358 of streams (QoS correlation). The decision of what level of 359 correlation should be enforced at the QoS level among a set of 360 streams, depends on the scenario and the requirements of the 361 application. The introduction of the time synchronization and QoS 362 correlation aspects augment the overall possibilities to specify 363 and manage QoS within a QoS aware system. 365 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 367 3.4 Planning counteractions ahead 369 A possible way to cope with otherwise unpredictable events 370 resulting from QoS changes / QoS violations, is to enable the 371 mobile users' applications to efficiently and timely react to 372 those events, by planning proper counteractions ahead, in a 373 coordinated manner with the remote end-peers. 374 In this manner, whenever QoS changes / QoS violations occur, 375 agreements on how to most effectively adapt to the mutated 376 conditions can be timely reached among the peers. 377 These counteractions include: 378 - negotiating multiple alternative QoS levels for a stream; 379 - negotiating multiple alternative QoS levels for a group of 380 streams, to capture time synchronization, QoS correlation, and 381 other inter-stream QoS constraints; 382 - coordinating local-, remote-, and network-resource management. 384 3.5 Independence from network aspects 386 The end-peers are in general connected over one or a multiplicity 387 of interconnected networks, including also Intermediate Components 388 (IM). In terms of SIP the SIP-proxies are considered as IM. 389 Taking in account the functionality of the SIP-proxies [3], [6] 390 and their ability to interfere with the communication between two 391 end-peers, it is desirable that the E2ENP operates based on an 392 abstraction of the underlying network, in order to provide real 393 end-to-end negotiation and conformance of the so delivered QoS 394 information. 395 Since the IMs offer services that not only may influence the 396 information that end-peers eventually negotiate via E2ENP, but 397 also may enforce the results of the E2ENP process, IMs should be 398 informed about the decision made by the end-peers. 399 IMs may be informed by providing them with some standard-profile 400 information before the start of E2ENP, and/or by publishing the 401 agreed QoS contracts, e.g. via a directory service. 402 In order to best satisfy the user QoS expectations and the network 403 provider QoS policies, the following is suggested: 404 - the E2ENP should be able to be used in combination with (but 405 independently from) IM, which may result effective in preparing 406 and/or guaranteeing the QoS contracts agreed by the end-peers; 407 - the exchange of information (e.g. profiles, security, 408 authentication, provider policies, etc.) not directly affecting 409 the E2ENP-process, rather influencing the information that is 410 going to be negotiated, should be carried out before the E2ENP 411 starts. 412 In general the flows carrying E2ENP messaging (the signaling-path) 413 and the flows carrying the actual streams (the data-path) could be 414 routed differently, depending not only on network-related issues, 415 but also on application/service specific reasons. Thus the E2ENP 416 signaling-paths and the corresponding data-paths between any two 418 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 420 given end-peers should be in general considered different. 421 Every time a signaling-path and/or data-path is built, there may 422 be some IMs (proxies, directory services, etc.) located along the 423 path, whose usage is application-specific, and which might 424 "understand" some of the protocols used by the end-peers. Some of 425 these entities might thus be able to "interfere" with the E2ENP, 426 thus disrupting the very "End-to-End" nature of the E2ENP. In 427 order to avoid this threat, it is suggested that: 428 - with respect to the E2ENP, Intermediate Components should 429 operate based only on information provided - directly or 430 indirectly - by the peers, in order to carry out application 431 specific tasks; 432 - exception cases when the involvement of the IMs is inevitable, 433 should also be considered. Thus the IMs should be allowed to 434 interfere with the E2ENP only by explicitly notifying the end- 435 peers about the occurred problems, and only when end-peers 436 misbehave, e.g. by disregarding system policies and/or in case of 437 system failure conditions. 439 3.6 Mapping of the quality settings on codec definition 441 When user-defined audio quality settings are associated with 442 codecs according to the standard static payload-type definitions 443 of the codecs [7], each QoS level can be mapped to one audio 444 payload type expressing such QoS level. On the other hand a single 445 variable bitrate video-codec can produce multiple QoS levels with 446 respect to the quality of the single video frame and - in some 447 cases - the quality of the color of a single frame. A user-defined 448 QoS level can be applied to a video by defining a compression 449 percentage for the performance of the video codec. However, some 450 video codecs have different number of compression levels. When an 451 application based on the users requirements selects a constant 452 video quality and accepts a variable bitrate coder, the 453 application would derive from the QoS level "visually perceivable 454 quality = X", an unique number expressing the compression level 455 for the video codec. Thus, in order to better apply QoS settings 456 to a codec, it is suggested that: 457 - applications should share a numbering range for the user 458 perceivable quality specification (overall visual quality and 459 color quality, if the user wants to specify a certain color 460 quality), in order to be able to uniquely map video quality to a 461 given codec; 462 - the numbering range for the user perceivable quality 463 specification should have enough resolution to uniquely map to the 464 compression levels of a given codec. 466 3.7 Third-Party-Assisted Negotiation 468 End-peers may leverage services like directory, allocation, 469 presence, etc. for redirecting connections over alternative end- 471 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 473 systems, which can more appropriately meet users' QoS expectations 474 because of more appropriate capabilities. 475 In these cases, end-peers should be able to negotiate on behalf of 476 other end-peers, according to specific user profile information. 477 This type of negotiation is called third-party-assisted 478 negotiation. By third-party-assisted negotiation a pure Mediator 479 should only facilitate the delegation of a connection without 480 actively taking part in it. 482 4. The features 484 A possible E2ENP implementation can be realized by combining 485 special extensions of SDPng [2] with a particular use of SIP. 486 The following list indicates the proposed SDPng extensions. 487 - An important part of the implementation is the use of 488 modularity for the elements by applying SDPng and extensions of 489 it. This would enable to use SDPng with and without the new 490 extensions. 491 - The modularity of the SDPng extensions should enable the end- 492 to-end negotiating parties to quickly reach agreements on common 493 codecs, payload types and codec parametrizations thus possibly 494 optimizing the decisions on commonly supported QoS contracts. 495 - For describing the QoS contracts it is necessary to have SDPng 496 elements for mapping the Application Level QoS descriptions onto 497 the codecs and the payload types. A single QoS contract would be 498 in these terms the QoS settings of a single media stream. 499 - It is suggested to enrich at the sender side the negotiated 500 Application Level QoS contracts with the TI and SI information 501 presented in [4], for allowing the end-peers to perform resource 502 reservation in a coordinate manner. 503 - It is necessary to distinguish between the different streams 504 (audio, video) and data types (data, control) in the definition of 505 the QoS contracts for a communication session. 506 - Considering the video codecs, the parametrization indicated in 507 [7] is not sufficient to fully characterize the given codec from a 508 QoS perspective. That is why it is necessary to introduce codec 509 parametrization attributes like frame-rate, frame-size, color- 510 quality-range, overall-quality-range, etc. which should be 511 uniquely interpreted by the end-systems. 512 - It is necessary to introduce descriptions and parametrizations 513 for non-streaming data. 514 - It is necessary to provide means for managing user, system, and 515 provider policy information at least by defining which of the 516 proposed QoS contracts the QoS aware system may support during a 517 negotiation. 518 - For defining APs new SDPng elements are needed for formally 519 configuring the adaptation process correspondingly, in accordance 520 with the envisioned QoS changes and/or violations. 521 - For defining stream grouping it is necessary to introduce new 523 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 525 SDPng elements with respect to (eventually hierarchical) group 526 definition, and QoS correlation / time synchronization aspects. 528 The following SIP features for implementing the E2ENP processes 529 are identified: 530 - Signaling for carrying out the negotiation and re-negotiation 531 - Means for coordinating resource management among multiple 532 parties (common example given in [8]) 533 - Transporting and recognizing the E2ENP content expressed as 534 SDPng content 536 5. Security Considerations 538 This chapter discusses some aspects considering security with 539 respect to SDPng and SIP performance. 540 If the contents of the SIP message body (SDPng) are private and 541 should be treated according to security policies they might be 542 encrypted. 543 The use of Digital Certificates with and within SDPng message 544 bodies can serve the unique identification of the sent information 545 for both end-peers and IM. This would enable the end-peers and IM 546 verify and best satisfy the user, system and provider policies. 547 Additional techniques for confidentiality and integrity support, 548 with respect to the negotiated information, should also be 549 considered. 550 On the issue of firewalls, further thorough investigations 551 concerning IMs are required. 553 6. Related Work 555 This section discusses existing solutions and/or proposals in the 556 field of QoS aware end-to-end negotiations, and highlights the 557 shortcomings of the respective existing signaling mechanisms (in- 558 band, SIP) and description methods (SDPng) for QoS. 560 The authors of [7] and [9] describe possibilities of quick re- 561 negotiations via in-band signaling. However this kind of signaling 562 concerns only change of codecs and the redundant support of 563 differently coded media without considering the respective effects 564 when QoS should be supported. 566 The authors of [8] and [10] present a multi-phase call-setup 567 mechanism that makes network QoS and security establishment a 568 precondition to sessions initiated by the SIP and described by the 569 SDP. Thus the resource management is done only for the network 570 resources. However [8], [10] do not consider pre-negotiation of 571 QoS and the integration of local and peer resource management. 573 The authors of [11] describe a complete model for one-to-one 574 capabilities negotiation with SDP. However this model has problems 576 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 578 by the definition of mutually referred information and information 579 on grouping streams because of the flat structure of the SDP. 580 Additionally this model concerns only capability negotiation but 581 no QoS support and QoS adaptation. 583 Ongoing work in [12] identifies the requirements of a framework 584 dealing with session description and endpoint capability 585 negotiation in multiparty multimedia conferencing scenarios. 586 Depending on user preferences, system capabilities, or other 587 constraints, different configurations can be chosen for the 588 conference. The need of a negotiation process among the end-peers 589 for determining a common set of potential system configurations 590 and for selection of one or many common configurations to be used 591 is identified, but not described. The authors of [12] also 592 identify the need for network resource reservation coupled with 593 session setup. 594 The proposal in [12] deals only with capability negotiations and 595 does neither consider a negotiation protocol for determining a 596 common set of QoS configuration nor integrate local, peer and 597 network resource reservation. 599 The most recent versions of SDPng proposal [2], [13] provide 600 detailed XML Schema specification and a prototype of the Audio 601 Codec and RTP Profiles. Additionally [13] describes a capability 602 negotiation process for establishing of a common capability 603 vocabulary between end-peers. However the proposals in [2], [13] 604 still do not consider the QoS specific issues. 606 In [5] an End-to-End User Perceived Quality of Service Negotiation 607 is described, with the assumption that some IMs and services may 608 strongly be involved in the end-decision about the negotiated QoS 609 information of the end-peers. The decision about QoS 610 configurations in [5] may be taken over some standard "contract 611 types". Although [5] mentions that signaling and data packets may 612 flow along different paths throughout the network, the authors of 613 [5] suggest that some IMs along the negotiation path may influence 614 the negotiation, though in general having nothing to do with the 615 data. According to such a protocol model the network is not 616 transparent. 617 The negotiation process presented in [5] does not allow 618 incremental negotiations, and furthermore [5] leverages static APs 619 with fixed transitions among capability configurations/network- 620 level QoS contracts only. 621 The model of [5] suggests negotiations of QoS only at stream level 622 without considering some stream dependencies like groups and 623 stream hierarchies. 625 The most recent work on the problem of User Perceived QoS [4] 626 introduces SDPng schema for defining traffic throughput and 627 sensitivity information. This information considers only the 629 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 631 network reservation process without taking in account the 632 necessity for local (peer) QoS specific configurations and 633 reservations. The model in [4] is not taking in account the 634 Application Level QoS definitions, with respect to codec 635 configuration and a flexible adaptation process. However the E2ENP 636 can incorporate this proposal, by allowing senders to derive TI/SI 637 from Application Level QoS contracts, and to forward this 638 information as part of a proposal/counter-proposal to the 639 receiver(s). The model of [4] is static in terms of adaptation, 640 insofar as it reuses the fixed prioritization of alternative 641 options derived from SDP, thus losing the powerful flexibility 642 featured by XML. The description of the payload types in [4] is 643 not in accordance with the payload types as described in [7], 644 since the codec parametrization of the audio codecs is already 645 pre-defined for the static payload types. One interesting aspect 646 in [4] is the introduction of QoS Class format as a form of 647 predefined interoperable application level QoS definition. However 648 such a definition would also need high level QoS specification 649 considering the usage of different possible QoS configurations of 650 a single codec/payload type. 652 7. Conclusions 654 This document has introduced the concept and requirements of the 655 End-to-End QoS Negotiation Protocol (E2ENP). The E2ENP is a 656 signaling mechanism for effectively and efficiently performing 657 end-to-end QoS negotiations/re-negotiations and resource 658 management coordination, when dealing with multiparty multimedia 659 services under unstable network conditions. Special features are 660 the negotiation of common vocabulary and adaptation paths, that 661 describe alternative QoS contracts to be applied, when QoS 662 violations occur. 663 Furthermore, the E2ENP allows developers and/or users to capture 664 and enforce time synchronization and QoS correlation (and even 665 more complex) constraints among multiple streams, thus allowing 666 adaptation at different levels. This is envisioned to be a key 667 benefit in terms of QoS for current and future applications. 668 By modularly extending SDPng, and by properly defining SIP usages, 669 the authors expect that the induction of the E2ENP concept will 670 smoothly blend with legacy solutions, along the path towards the 671 next generation of QoS aware multiparty, multimedia services. 673 8. References 675 [1] IST-1999-10050 BRAIN Deliverable 1.2, Concepts for Service 676 adaptation, scalability and QoS handling on mobility enabled 677 networks, 31.03.2001 (http://www.ist-brain.org/) 679 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 681 [2] D. Kutscher et al.: Session Description and Capability 682 Negotiation, IETF Internet-Draft, Work-in-progress, . 685 [3] IETF RFC 2543, SIP: Session Initiation Protocol, M. Handley et 686 al, ACIRI, March 1999. 688 [4] L. Bos, et al: SDPng extensions for Quality of service 689 negotiation, IETF Internet-Draft, Work-in-progress,. 692 [5] L. Bos, et al: A Framework for End-to-End User Perceived 693 Quality of Service Negotiation, IETF Internet-Draft, Work-in- 694 progress,. 696 [6] Rosenberg et al.: SIP: Session Initiation Protocol, IETF SIP 697 working group, Work-in-progress, . 700 [7] H. Schulzrinne et al.: RTP Profile for Audio and Video 701 Conferences with Minimal Control, Columbia U., Work-in-progress, 702 . 704 [8] W. Marshall et al.: Integration of Resource Management and SIP 705 - SIP Extensions for Resource Management, IETF SIP working group, 706 Work-in-progress, . 708 [9] IETF RFC 2198, RTP Payload for Redundant Audio Data, C. 709 Perkins et al., Network Working Group, September 1997. 711 [10] W.Marshall et al., SIP Extensions for Resource Management, 712 IETF draft , November 2000. 714 [11] J.Rosenberg, H.Schulzrinne.: An Offer/Answer Model with SDP, 715 IETF Internet-Draft, Work-in-progress, . 718 [12] D. Kutscher et al.: Requirements for Session Description and 719 Capability Negotiation, IETF Internet-Draft, Work-in-progress, 720 . 722 [13] D. Kutscher et al.: Session Description and Capability 723 Negotiation, IETF Internet-Draft, Work-in-progress, . 726 Efficient End-to-End QoS Signaling - concepts and features Mar 2002 728 9. Author's addresses for comments and discussions 730 Teodora Guenkova-Luy 731 Dept. Distributed Systems, University of Ulm, 732 Oberer Eselsberg, 89069 Ulm, Germany 733 Tel: +49 (0)731 502-4148 734 Fax: +49 (0)731 502-4142 735 e-Mail: guenkova@vs.informatik.uni-ulm.de 737 Andreas Kassler 738 Dept. Distributed Systems, University of Ulm, 739 Oberer Eselsberg, 89069 Ulm, Germany 740 Tel: +49 (0)731 502-4146 741 Fax: +49 (0)731 502-4142 742 e-Mail: kassler@informatik.uni-ulm.de 744 Jochen Eisl 746 Siemens Mobile Networks 747 Research & Concepts Dep. 748 Tel: +49 (0)89 722 62710 749 Fax: +49 (0)89 722 21882 750 e-Mail: jochen.eisl@icn.siemens.de 752 Davide Mandato 753 Broadband Wireless Technology Research (BWTR) 754 Sony International (Europe) GmbH 755 Advanced Technology Center Stuttgart 756 Heinrich-Hertz-Str. 1 757 70327 Stuttgart, Germany 758 Tel: +49 (0)711 5858-797 759 Fax: +49 (0)711 5858-468 760 e-mail: mandato@sony.de 762 10. Acknowledgements 764 This work has been performed in the framework of the IST project 765 IST-2000-28584 MIND, which is partly funded by the European Union. 766 The authors would like to acknowledge the contributions of their 767 colleagues, especially Markku Kojo. 768 The authors would also like to thank their colleagues from TZI, 769 University of Bremen, from Sony International (Europe), Stuttgart 770 and University of Ulm for their support.