idnits 2.17.1 draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 652. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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 1 longer page, the longest (page 10) being 530 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 426: '...ports SHALL be considered. The countin...' RFC 2119 keyword, line 473: '...original SDPng draft [2], hence they SHOULD be considered as...' RFC 2119 keyword, line 495: '...gnalling the security components SHALL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 10, 2005) is 7016 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) == Unused Reference: '12' is defined on line 548, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-23 == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '8') == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-07 -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-sdpng-trans (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MMUSIC WG T. Guenkova-Luy 3 Internet-Draft A. Schorr 4 Expires: August 10, 2005 F. Hauck 5 University of Ulm 7 I. Wolf 8 B. Feiten 9 T-Systems 10 International 12 M. Gomez 13 F. Galan 14 Agora Systems 16 Telma Mota 17 Portugal Telecom 18 Inovacao 20 Willem Romijn 21 Lucent Technologies 23 February 10, 2005 25 Stream Tracking Description for Resource Management Guarantees in 26 the Network 27 draft-guenkova-mmusic-sdp-ng-streamtrack-00 29 Status of this Memo 31 By submitting this Internet-Draft, the authors certify that any 32 applicable patent or other IPR claims of which the authors are aware 33 have been disclosed, or will be disclosed, and any of which the 34 authors become aware will be disclosed, in accordance with RFC 3668. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Guenkova, et al. Expires August 10, 2005 [Page 1] 53 This Internet-Draft will expire on August 10, 2005. 55 Abstract 57 This document defines an extension to the Session Description 58 Protocol (SDP) and to Session Description Protocol new generation 59 (SDPng - work in progress). The intention of this draft is to provide 60 descriptions in SDP and SDPng that specify the source port of media 61 streams. Such specification within the session description is 62 required in many network quality of service (QoS) management systems 63 in order to be able to track the media streams from their source to 64 their destination. Thus the QoS management system can differentiate 65 the stream tracks end-to-end and guarantee QoS for every single 66 media. 68 Table of Contents 70 1. Introduction..........................................2 71 2. Motivation............................................3 72 3. RTP traffic tracking descriptions in SDP and SDPng....6 73 3.1. SDP enhancement of the "m=" line......................6 74 3.2. SDPng enhancement of the component of the RTP 75 package.....................................................7 76 4. IANA Considerations...................................9 77 5. Security considerations..............................10 78 References.................................................10 79 Authors' Addresses.........................................11 80 Acknowledgements...........................................13 81 Copyright Notice...........................................13 82 Liability notice...........................................13 84 1. Introduction 86 The intention of this draft is to provide descriptions in SDP [1] and 87 SDPng [2] that specify the source port of media streams. Such 88 specification within the session description is required in many 89 network quality of service (QoS) management systems in order to be 90 able to track the media streams from their source to their 91 destination, especially in cases where it is necessary to distinguish 92 between several different network flows which are all sent from the 93 same source IP address to the same destination. Thus the QoS 94 management system can differentiate the stream tracks end-to-end and 95 guarantee QoS for every single media. Additionally, this draft can be 96 considered an extension to RFC 3312 [3]. RFC 3312 also treats 97 resource reservation issues, but it addresses predominantly the 98 problem of resource reservation coordination using the Session 99 Initiation Protocol (SIP) [4]. The problem of indicating and 100 distinguishing the network flows of the multimedia end-to-end in 101 order to guarantee their reservation is not treated in RFC 3312. 103 Guenkova, et al. Expires August 10, 2005 [Page 2] 104 In this draft we consider first the multimedia management 105 architectures that serve as motivation for the proposed SDP and SDPng 106 enhancements. We discuss the structure of the enhancements and give 107 corresponding examples. The draft is concluded with security 108 considerations about the usage of the proposed enhancements. 110 2. Motivation 112 Most of the Next Generation Network specifications have a similar 113 architecture to the one proposed by the 3GPP UMTS IP Multimedia 114 Subsystem (IMS) [5] and include a dedicated platform for delivering 115 of Multimedia Services over the underlying Packet-Switched network. 116 Such multimedia provisioning platforms usually comprise the following 117 elements: 119 o A control plane based on signalling proxy entities, usually SIP- 120 based [4]. 122 o A native service-provisioning platform, implemented over a set of 123 Application Servers based on the native signalling protocol(s) 124 supported by the platform. 126 o A set of media-processing elements, for the provisioning of 127 advanced multimedia services. 129 o A set of interconnection elements, belonging to both the signalling 130 and the media-processing level that enable the access to foreign 131 services, service domains or legacy systems. 133 The multimedia-services control plane can be decomposed into three 134 main logical control functions: 136 o Access proxy function (e.g. P-CSCF in IMS networks): This is the 137 entry point for subscribers to the multimedia-provisioning 138 platform. 140 o Query proxy function (e.g. I-CSCF in IMS networks): This entity 141 allows locating the service control function that handles a 142 particular user. This proxy behaves also as an entry point in the 143 home network for external Foreign Service domains. 145 o Serving proxy function (e.g. S-CSCF in IMS networks): This is the 146 entity that serves the users in the home network. It performs 147 service-level control and authorization. 149 The "access proxy function" is the entity in charge of ensuring QoS 150 for the negotiated multimedia sessions. In order to accomplish this 151 task, it contacts the QoS brokerage entities in the access network to 152 reserve the required resources for the requested multimedia streams. 153 This interaction is usually performed using a policy control protocol 155 Guenkova, et al. Expires August 10, 2005 [Page 3] 156 like COPS [6]. 158 QoS Control elements may be classified according to two main 159 categories: brokerage and enforcement elements. QoS Brokers (Policy 160 Decision Points or PDPs, in COPS terminology) are the elements in 161 charge of performing policy-based admission control and managing QoS 162 resources at a global level. For scalability reasons, this element 163 may be divided into a set of access network brokerage elements (the 164 actual PDPs) and a core QoS broker. QoS enforcement elements (Policy 165 Enforcement Points or PEPs, in COPS terminology) are the network 166 routing nodes, which are in charge of applying the QoS configurations 167 set up by the brokerage elements. Routing elements - the actual PEPs 168 -are usually classified into: 170 o Access Routers (AR) which constitute the entry point to the network 171 for subscribers. 173 o The Core Routers (CR) is in charge of managing QoS reservations for 174 aggregated flows (macroflows). 176 o The Edge Routers (ER) is in charge of interconnecting several 177 DiffServ [7] domains or IntServ [8] to DiffServ mapping. 179 In the presented Multimedia Service Provisioning Platform 180 architecture, the access proxy element (AProxy) will contact its 181 local Access Network's QoS Broker (ANQosBr) in order to reserve the 182 required resources for the steams that are negotiated through 183 multimedia signalling. After a successful negotiation all the QoS- 184 related interactions will be exchanged through the QoS provisioning 185 part of the architecture, with no further interactions between the 186 Service and the QoS provisioning elements. 188 In order to request QoS resources for a particular multimedia stream, 189 the access proxy element must provide the Access Network QoS Broker 190 not only a description of the required network resources (e.g. 191 Service type, stream QoS characterization, etc.), but also some 192 filtering criteria that enable QoS elements to identify the 193 reservation target streams. Streams can usually be identified from 194 the network point of view by a combination of elements from the 5- 195 tuple (source address, source port, destination address, destination 196 port, transport protocol). 198 The sequence of interaction events between the components shown in 199 Fig. 1 is: 201 o The AProxy will interpret the SDP/SDPng content in order to arrange 202 the type of QoS network reservation to be requested from the 203 ANQosBroker. 205 o In order to uniquely identify the reservation for a specific flow, 206 filtering information must be provided to the ANQoSBroker. 208 Guenkova, et al. Expires August 10, 2005 [Page 4] 209 o The ANQoSBroker will configure the AR accordingly. 211 Since there is not an explicit relationship between the SIP session 212 identifier and the media session (e.g. RTP session), the AR must know 213 all the parameters referred in the filtering information in order to 214 uniquely identify and control the admission of the packets of a 215 single flow. 217 +------------+ Coordination +--------------+ 218 | ANQosBr |<-------------->| Other QoS | 219 |(PEP1)(PDP2)| | provisioning | 220 +------------+ | elements | 221 ^ | +--------------+ 222 COPS | | 223 | | 224 \/ | 225 +-------+ | 226 |AProxy | | 227 |(PDP1) | | QoS configuration 228 +-------+ | 229 ^ | 230 | | 231 SIP/SDP | | 232 or | | 233 SIP/SDPng | | 234 | | 235 | \/ 236 +------+ +-------+ Access +----+ Core 237 | Host |<=====>| AR |<===> Network <===>| ER |<===> Network 238 | | Media | (PEP2)| (QoS 1) | | (QoS 2) 239 +------+ +-------+ +----+ 241 Figure 1: Multimedia Service Provisioning Platform 243 Although session description protocols [1][2] describe in detail the 244 multimedia-oriented service characteristics of streams, they only 245 provide a basic description of their associated network parameters, 246 conveying only the IP addresses, transport protocols, and reception 247 ports of the streams composing the session. Several common practice 248 mechanisms (e.g. symmetric RTP uses the local listening port also as 249 the source port for outgoing streams [9]) are applied in order to 250 infer the sender port information from the exchanged session 251 descriptions delivered through the multimedia signalling, since the 252 sender port information is not explicitly given in the session 253 descriptions. This kind of practices should be discouraged, as they 254 are vulnerable and error-prone, with the consequences of network 255 resource wasting and exposure to exploitation by malicious users. 257 Guenkova, et al. Expires August 10, 2005 [Page 5] 258 Therefore, session descriptions conveyed in the multimedia signalling 259 should be enhanced in order to include complete and univocal stream 260 descriptions, so that access proxy elements may provide to the QoS 261 subsystem all the necessary parameters for an effective flow 262 distinction and tracking. 264 Please note that, although intended for the architecture depicted 265 above, this extension may be useful for any network element issuing 266 resource reservation requests based on information conveyed in 267 multimedia session descriptions too, such as: 269 o User terminals (e.g. using RSVP [10]). 271 o Routers implementing any signalling tracking mechanism for 272 automatic QoS resource reservation. 274 3. RTP traffic tracking descriptions in SDP and SDPng 276 Session Description Protocol (SDP) [1] is intended for describing 277 multimedia sessions for the purposes of session announcement, session 278 invitation, and other forms of multimedia session initiation. 280 SDPng [2] is a meta-protocol that can describe other protocols and 281 configuration mechanisms of the applications. Just like its 282 predecessor SDP [1], SDPng is carried as an attachment of other 283 configuration protocols (e.g. SIP [4], RTSP [11]) to exchange for 284 example configuration information about RTP-based [9] multimedia 285 streams. SDPng is a successor protocol of the Session Description 286 Protocol [1] and is designed to be modular and extensible using the 287 eXtensible Markup Language (XML) [12](unlike its predecessor SDP). 288 SDPng is designed to support more complex media features and 289 scenarios than SDP, including quality of service (QoS), security 290 support for media transfer, etc [13]. 292 Sections 3.1 and 3.2 describe the proposed enhancements for SDP and 293 SDPng to include information about media source ports, thus enabling 294 effective flow distinction and tracking as discussed and motivated in 295 Chapter 2. 297 3.1. SDP enhancement of the "m=" line 299 The following defines the model for the SDP enhancement: 301 m= /// 304 An example corresponding to the above model is: 306 Guenkova, et al. Expires August 10, 2005 [Page 6] 307 m=video 49170/2/50080/2 RTP/AVP 31 309 Meaning of the example: 311 o The media type is "video" 313 o The first RTP receiving port in use is 49170 315 o The second RTP receiving port in use is 49172 317 o The first RTCP port that corresponds the first receiving RTP port 318 is 49171 320 o The second RTCP port that corresponds the second receiving RTP port 321 is 49173 323 o The first RTP sending port in use is 50080 325 o The second RTP sending port in use is 50082 327 o The first RTCP sending port that corresponds the first RTP sending 328 port is 50081 330 o The second RTCP sending port that corresponds the second RTP 331 sending port is 550083 333 o The protocol in use is RTP with the AVP profile [14] 335 o The applied payload format is number 31 according to [14] 337 Note that if QoS shall be guaranteed for RTP streams, it shall also 338 be guaranteed for their corresponding RTCP traffic, as the timely 339 reports for the RTP traffic are important for the QoS relevant 340 adaptations of the traffic. 342 3.2. SDPng enhancement of the component of the RTP 343 package 345 Due to the line wrapping of the format required for this document the 346 original indentation as usual for XML layout does not appear 347 correctly, i.e. the bracket pairs "<" and "/>" or "<" and ">", or 348 "" always indicate single unbreakable lines. Additionally, 349 the conventional ordering of the XML hierarchical elements appears as 350 hierarchical tree layout. All the XML examples and schemas in this 351 document are proven on wellformness and validity with XMLSpy Software 352 [15]. 354 The following SDPng definition is the expression that corresponds to 355 the definition in SDP within the previous Section 3.1. In order to 357 Guenkova, et al. Expires August 10, 2005 [Page 7] 358 achieve similar expressiveness as the "m=" line in SDP, we redefine 359 the element of SDPng. The new definition of the IP 360 address and RTP ports in the SDPng RTP package (see [2]) is provided 361 through the application of two new XML complex types. 363 The XML schema snippets corresponding the new "IP addresses" and "RTP 364 ports" complex types are: 366 Port Type: 368 369 370 372 374 376 378 380 382 383 385 IP Address Type: 387 388 389 390 391 392 393 395 The definition of the new corresponding element in the RTP XML schema 396 would be then: 398 400 As a result of this new definition the port definitions are put in 401 the container for the IP Address . The complete 402 definition is still a sub-element of the container [2] as 403 shown in the example below: 405 Guenkova, et al. Expires August 10, 2005 [Page 8] 406 407 ... 408 409 49170 410 49171 411 1 412 50080 413 50081 414 1 415 416 ... 417 419 This SDPng description corresponds to the same parameter 420 configuration as in the SDP example given in Section 3.1. The 421 difference to SDP is that the pairs of RTP and RTCP ports are now 422 combined in a way that it is evident how the single ports belong 423 together (compared to the SDP "a=rtcp:" definition [1]). The elements 424 and indicate that 425 additional pair/-s of correspondingly receiving and sending RTP/RTCP 426 ports SHALL be considered. The counting of the port numbers of every 427 next pair starts in this case with the number of the RTCP port as 428 basis. 430 For example: 432 49170 433 49171 434 1 436 specifies that 1 additional pair of ports shall be taken, i.e. 438 o The first RTP receiving port in use is 49170 440 o The first RTCP port that corresponds the first receiving RTP port 441 is 49171 443 o The second RTP receiving port in use is 49172 (i.e. RTCP port 1 444 plus 1) 446 o The second RTCP port that corresponds the second receiving RTP port 447 is 49173 (i.e. RTCP port 1 plus 2). 449 In case of n-port offsets: 451 49170 452 49171 453 n 455 every n-th pair of RTP/RTCP ports is calculated as RTP_n=RTCP_1+n and 457 Guenkova, et al. Expires August 10, 2005 [Page 9] 458 RTCP_n= RTCP_1+n+1 460 The same definition holds true also for the RTP/RTCP sender ports 461 (i.e. rtp:rtp-sendport>, and ). 464 4. IANA Considerations 466 The IANA should set up a registry for XML namespaces for SDPng and 467 SDPng package definitions. 469 The SDP parameter registry (http://www.iana.org/assignments/sdp- 470 parameters) should be converted to SDPng package definitions. 472 The inputs of this draft are not concurrent to the inputs of the 473 original SDPng draft [2], hence they SHOULD be considered as 474 belonging to the same namespace as long as SDPng is concerned. 476 The exact structure of the SDPng namespace depends also on the fact 477 if SDPng work in progress [2] shall be continued or if this draft 478 shall take over the SDPng development. 480 5. Security considerations 482 The explicit definition of RTP/RTCP receiver and sender ports allows 483 the QoS entities in the network to prove upon the session 484 descriptions that the terminals are in line with their QoS 485 specifications as the complete sender-to-receiver track is monitored. 486 Furthermore, network resource wasting and/or exposure of the network 487 streams to exploitation by malicious users is avoided as the QoS 488 relevant streams are declared explicitly for monitoring in the 489 session descriptions. 491 The problem of the security should also be studies further with 492 respect to Firewall and NAT traversal, as the proposed solution in 493 this document requires interactions between the session signalling 494 and the multimedia streaming. In order to achieve correspondence 495 between these two types of signalling the security components SHALL 496 apply similar to the IMS architecture (see also Chapter 2) in order 497 to guarantee conformant treatment for both the session signalling and 498 the corresponding multimedia streaming. 500 Since SDP and SDPng are a description formats carried by other 501 protocols (SIP [8], RTSP [11], etc.), SDP and SDPng rely on the 502 security provided by their carriers to guarantee faultless end-to-end 503 transfer. 505 References 507 [1] M. Handley, V. Jacobson, "SDP: Session Description 508 Protocol", IETF RFC 2327, April 1998 and M. Handley, V. 509 Jacobson, C. Perkins, "SDP: Session Description Protocol", 510 draft-ietf-mmusic-sdp-new-23.txt, December 2004. 512 [2] D. Kutscher et al., "Session description and capability 513 negotiation", IETF Internet-Draft, Work-in-progress: draft- 514 ietf-mmusic-sdpng-07, October 2003. 516 [3] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 517 Resource Management and Session Initiation Protocol", IETF 518 RFC 3312, October 2002. 520 [4] J. Rosenberg et al., "SIP: Session Initiation Protocol", 521 IETF RFC 3261, June 2002. 523 [5] 3GPP TS 23.228 v 6.8.0, "IP Multimedia Subsystem (IMS); 524 Stage 2 (Release 6)", December 2004. 526 [6] D. Durham et al, "The COPS (Common Open Policy Service) 527 Protocol", IETF RFC 2748, January 2000. 529 [7] S. Blake et al., "An Architecture for Differentiated 530 Service", IETF RFC 2475, December 1998. 532 [8] R. Braden, D. Clark, S. Shenker, "Integrated Services in the 533 Internet Architecture: an Overview", IETF RFC 1633, June 534 1994. 536 [9] H. Schulzrinne et al., "RTP: A Transport Protocol for Real- 537 Time Applications", IETF RFC 3550, July 2003. 539 [10] R. Braden et al, "Resource ReSerVation Protocol (RSVP) -- 540 Version 1 Functional Specification", IETF RFC 2205, 541 September 1997. 543 [11] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 544 Protocol (RTSP)", IETF RFC 2326, April 1998 and H. 545 Schulzrinne et al., "Real Time Streaming Protocol (RTSP)", 546 draft-ietf-mmusic-rfc2326bis-07.txt, July 2004. 548 [12] W3C, "Extensible Markup Language (XML) 1.0 (Second 549 Edition)". 551 [13] J. Ott, C. Perkins, "SDPng Transition", IETF Internet-Draft 552 (draft-ietf-mmusic-sdpng-trans-04), May 2003. 554 [14] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video 555 Conferences with Minimal Control", IETF RFC 3551, July 2003 556 [15] Altova GmbH & Altova Inc., XMLSpy IDE version 4.3, 557 www.altova.com 559 Authors' Addresses 561 Teodora Guenkova-Luy 562 Dept. Distributed Systems, University of Ulm, 563 Oberer Eselsberg, 89069 Ulm, Germany 564 Tel: +49 (0)731 502-4148 565 Fax: +49 (0)731 502-4142 566 e-Mail: guenkova@vs.informatik.uni-ulm.de 568 Andreas Schorr 569 Dept. Distributed Systems, University of Ulm, 570 Oberer Eselsberg, 89069 Ulm, Germany 571 Tel: +49 (0)731 502-4147 572 Fax: +49 (0)731 502-4142 573 e-Mail: schorr@informatik.uni-ulm.de 575 Franz Hauck 576 Dept. Distributed Systems, University of Ulm, 577 Oberer Eselsberg, 89069 Ulm, Germany 578 Tel: +49 (0)731 502-4143 579 Fax: +49 (0)731 502-4142 580 e-Mail: hauck@informatik.uni-ulm.de 582 Ingo Wolf 583 T-Systems International GmbH 584 Goslarer Ufer 35, 10589 Berlin, Germany 585 Tel: +49 (0)30 3497 2526 586 Fax: +49 (0)30 3497 2929 587 E-mail: wolfi@t-systems.com 589 Bernhard Feiten 590 T-Systems International GmbH 591 Goslarer Ufer 35, 10589 Berlin, Germany 592 Tel: +49 (0)30 3497 2528 593 Fax: +49 (0)30 3497 2929 594 e-Mail: Bernhard.Feiten@t-systems.com 596 Miguel Gomez 597 Agora Systems, S.A. 598 Aravaca 12, 1 A. 28040 Madrid, Spain 599 Tel: +34-91-533-58-57 600 Fax: +34-91-534-84-77 601 e-Mail: miguel.gomez@agora-2000.com 602 Fermin Galan 603 Agora Systems, S.A. 604 Aravaca 12, 1 A. 28040 Madrid, Spain 605 Tel: +34-91-533-58-57 606 Fax: +34-91-534-84-77 607 e-Mail: fermin.galan@agora-2000.com 609 Telma Mota 610 Portugal Telecom Inova??o, SA 611 Rua Eng. Jos? Ferreira Pinto Basto 612 3810 AVEIRO, Portugal 613 Tel: +351-234-403-280 614 e-mail: telma@ptinovacao.pt 616 Willem A. Romijn 617 Lucent Technologies Nederland B.V. 618 Larenseweg 50 619 1221 CN Hilversum 620 The Netherlands 621 Tel: +31 35 687 4672 622 e-mail: romijn@lucent.com 624 Acknowledgements 626 The work described in this draft is based on results of IST FP6 627 Integrated Project DAIDALOS. DAIDALOS receives research funding from 628 the European Community's Sixth Framework Programme. Apart from this, 629 the European Commission has no responsibility for the content of this 630 draft. The information in this document is provided as is and no 631 guarantee or warranty is given that the information is fit for any 632 particular purpose. The user thereof uses the information at its sole 633 risk and liability. 635 Additional support has been provided by the DFG within the AKOM 636 framework. 638 Copyright Notice 640 Copyright (C) The Internet Society (2005). This document is subject 641 to the rights, licenses and restrictions contained in BCP 78, and 642 except as set forth therein, the authors retain all their rights. 644 Liability notice 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 649 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 650 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 651 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.