idnits 2.17.1 draft-ietf-mmusic-img-req-08.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.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1052. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1058. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (December 19, 2005) is 6697 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) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '10') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '11') (Obsoleted by RFC 6665) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group Y. Nomura 3 Internet-Draft Fujitsu Labs. 4 Expires: June 23, 2006 R. Walsh 5 J-P. Luoma 6 Nokia 7 J. Ott 8 Universitaet Bremen 9 H. Schulzrinne 10 Columbia University 11 December 19, 2005 13 Requirements for Internet Media Guides 14 draft-ietf-mmusic-img-req-08 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This memo specifies requirements for a framework and protocols for 47 accessing and updating Internet Media Guide (IMG) information for 48 media-on-demand and multicast applications. These requirements are 49 designed to guide choice and development of IMG protocols for 50 efficient and scalable delivery. 52 Table of Contents 54 1 Introduction ........................................ 3 55 1.1 Background and Motivation ........................... 3 56 1.2 Scope of This Document .............................. 4 57 2 Terminology ......................................... 5 58 2.1 New Terms ........................................... 5 59 3 Problem Statement ................................... 6 60 4 Use Cases Requiring IMGs ............................ 7 61 4.1 Connectivity-based Use Cases ........................ 7 62 4.1.1 IP Datacast to a Wireless Receiver .................. 7 63 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8 64 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8 65 4.2 Content-orientated Use Cases ........................ 9 66 4.2.1 TV and Radio Program Delivery ....................... 9 67 4.2.2 Media Coverage of a Live Event ...................... 10 68 4.2.3 Distance Learning ................................... 10 69 4.2.4 Multiplayer Gaming .................................. 10 70 4.2.5 File Distribution ................................... 10 71 4.2.6 Coming-release and Pre-released Content ............. 11 72 5 Requirements ........................................ 11 73 5.1 General Requirements ................................ 11 74 5.1.1 Independence of IMG Operations from IMG Metadata .... 11 75 5.1.2 Multiple IMG Senders ................................ 11 76 5.1.3 Modularity .......................................... 12 77 5.2 Delivery Properties ................................. 12 78 5.2.1 Scalability ......................................... 12 79 5.2.2 Support for Intermittent Connectivity ............... 12 80 5.2.3 Congestion Control .................................. 13 81 5.2.4 Sender and Receiver Driven Delivery ................. 13 82 5.3 Customized IMGs ..................................... 13 83 5.4 Reliability ......................................... 14 84 5.4.1 Managing Consistency ................................ 14 85 5.4.2 Reliable Message Exchange ........................... 15 86 5.5 IMG Descriptions .................................... 15 87 6 Security Considerations ............................. 17 88 6.1 IMG Authentication and Integrity .................... 17 89 6.2 Privacy ............................................. 18 90 6.3 Access Control for IMGs ............................. 18 91 6.4 Denial-of-Service attacks ........................... 19 92 6.5 Replay Attacks ...................................... 19 93 7 IANA Considerations ................................. 20 94 8 Normative References ................................ 20 95 9 Informative References .............................. 20 96 10 Acknowledgements .................................... 21 97 11 Authors' Addresses .................................. 21 99 1 Introduction 101 1.1 Background and Motivation 103 For some ten years, multicast-based (multimedia) conferences 104 (including IETF WG sessions) as well as broadcasts of 105 lectures/seminars, concerts, and other events have been used in the 106 Internet, more precisely, on the MBONE. Schedules and descriptions 107 for such multimedia sessions as well as the transport addresses, 108 codecs, and their parameters have been described using SDP [2] as a 109 rudimentary (but as of then largely sufficient) means. Dissemination 110 of the descriptions has been performed using the Session Announcement 111 Protocol (SAP) [3] and tools such as SD [4] or SDR [5]; descriptions 112 have also been put up on web pages, sent by electronic mail, etc. 114 Recently, interest has grown to expand -- or better: to generalize -- 115 the applicability of these kinds of session descriptions. 116 Descriptions are becoming more elaborate in terms of included 117 metadata; more generic regarding the types of media sessions; and 118 possibly also support other transports than just IP (e.g. legacy TV 119 channel addresses). This peers well with the DVB (Digital Video 120 Broadcasting) [6] Organization's increased activities towards 121 IP-based communications over satellite, cable, and terrestrial radio 122 networks, also considering IP as the basis for TV broadcasts and 123 further services. The program/content descriptions are referred to as 124 Internet Media Guides (IMGs) and can be viewed as a generalization of 125 Electronic Program Guides (EPGs) and multimedia session descriptions. 127 An Internet Media Guide (IMG) has a structured collection of 128 multimedia session descriptions expressed using SDP, SDPng [7] or 129 some similar session description format. This is used to describe a 130 set of multimedia services (e.g. television program schedules, 131 content delivery schedules) but may also refer to other networked 132 resources including web pages. IMGs provide the envelope for metadata 133 formats and session descriptions defined elsewhere with the aim of 134 facilitating structuring, versioning, referencing, distributing, and 135 maintaining (caching, updating) such information. 137 The IMG metadata may be delivered to a potentially large audience, 138 who use it to join a subset of the sessions described, and who may 139 need to be notified of changes to this information. Hence, a 140 framework for distributing IMG metadata in various different ways is 141 needed to accommodate the needs of different audiences: For 142 traditional broadcast-style scenarios, multicast-based (push) 143 distribution of IMG metadata needs to be supported. Where no 144 multicast is available, unicast-based push is required, too. 145 Furthermore, IMG metadata may need to be retrieved interactively, 146 similar to web pages (e.g. after rebooting a system or when a user is 147 browsing after network connectivity has been re-established). 148 Finally, IMG metadata may be updated as time elapses because content 149 described in the guide may be changed: for example, the airtime of an 150 event such as a concert or sports event may change, possibly 151 affecting the airtime of subsequent media. This may be done by 152 polling the IMG sender as well as by asynchronous change 153 notifications. 155 Furthermore, any Internet host can be a sender of content and thus an 156 IMG sender. Some of the content sources and sinks may only be 157 connected to the Internet sporadically. Also, a single human user may 158 use many different devices to access metadata. Thus, we envision that 159 IMG metadata can be sent and received by, among others, by cellular 160 phones, PDA (Personal Digital Assistant), personal computer, 161 streaming video server, set-top box, video camera, and DVR (Digital 162 Video Recorder) and that they be carried across arbitrary types of 163 link layers, including bandwidth-constrained mobile networks. 164 However, generally we expect IMG Senders to be well-connected hosts. 166 Finally, with many potential senders and receivers, different types 167 of networks, and presumably numerous service providers, IMG metadata 168 may need to be combined, split, filtered, augmented, modified, etc., 169 on their way from the sender(s) to the receiver(s) to provide the 170 ultimate user with a suitable selection of multimedia services 171 according to her preferences, subscriptions, location, context (e.g. 172 devices, access networks), etc. 174 1.2 Scope of This Document 176 This document defines requirements that Internet Media Guide 177 mechanisms must satisfy in order to deliver IMG metadata to a 178 potentially large audience. Since IMGs can describe many kinds of 179 multimedia content, IMG methods are generally applicable to several 180 scenarios. 182 In considering wide applicability, this document provides the problem 183 statement and existing mechanisms in this area. Then several use case 184 scenarios for IMGs are explained including descriptions of how IMG 185 metadata and IMG delivery mechanisms contribute to these scenarios. 186 Following this, this document provides general requirements that are 187 independent of any transport layer mechanism and application, such as 188 delivery properties, reliability and IMG descriptions. 190 This document reflects investigating work on delivery mechanisms for 191 IMGs and generalizing work on session announcement and initiation 192 protocols, especially in the field of the MMUSIC working group (SAP, 193 SIP [8], SDP). 195 2 Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC 2119 [1]. 201 2.1 New Terms 203 Internet Media Guide (IMG): IMG is a generic term to describe 204 the formation, delivery and use of IMG metadata. The 205 definition of the IMG is intentionally left imprecise. 207 IMG Element: The smallest atomic element of metadata that can be 208 transmitted separately by IMG operations and referenced 209 individually from other IMG elements. 211 IMG Metadata: A set of metadata consisting of one or more IMG 212 elements. IMG metadata describes the features of multimedia 213 content used to enable selection of and access to media 214 sessions containing content. For example, metadata may 215 consist of the URI, title, airtime, bandwidth needed, file 216 size, text summary, genre and access restrictions. 218 IMG Delivery: The process of exchanging IMG metadata both in 219 terms of large scale and atomic data transfers. 221 IMG Sender: An IMG sender is a logical entity that sends IMG 222 metadata to one or more IMG receivers. 224 IMG Receiver: An IMG receiver is a logical entity that receives 225 IMG metadata from an IMG sender. 227 IMG Transceiver: An IMG transceiver combines an IMG receiver and 228 sender. It may modify received IMG metadata or merge IMG 229 metadata received from a several different IMG senders. 231 IMG Operation: An atomic operation of an IMG transport protocol, 232 used between IMG sender(s) and IMG receiver(s) for the 233 delivery of IMG metadata and for the control of IMG 234 sender(s)/receiver(s). 236 IMG Transport Protocol: A protocol that transports IMG metadata 237 from an IMG sender to IMG receiver(s). 239 IMG Transport Session: An association between an IMG sender and 240 one or more IMG receivers within the scope of an IMG 241 transport protocol. An IMG transport session involves a 242 time bound series of IMG transport protocol interactions 243 that provide delivery of IMG metadata from the IMG sender 244 to the IMG receiver(s). 246 3 Problem Statement 248 As we enumerate the requirements for IMGs, it will become clear that 249 they are not fully addressed by the existing protocols. The Framework 250 for the Usage of Internet Media Guides [9] talks about these issues 251 in more detail. 253 The MMUSIC working group has long been investigating content, media 254 and service information delivery mechanisms and protocols, and has 255 itself produces Session Announcement Protocol (SAP), Session 256 Description Protocol (SDP), and the Session Initiation Protocol 257 (SIP). SDP is capable of describing multimedia sessions (i.e. 258 content in a wider sense) by means of limited descriptive information 259 intended for human perception plus transport, scheduling information, 260 and codecs and addresses for setting up media sessions. SIP and SAP 261 are protocols to distribute these session descriptions. 263 However, we perceive a lack of a standard solution for scalable IMG 264 delivery mechanism in the number of receivers with consistency of IMG 265 metadata between an IMG sender and IMG receiver for both 266 bi-directional and unidirectional transport. With increased service 267 dynamics and complexity, there is an increased requirement for 268 updates to these content descriptions. 270 HTTP [10] is a well known information retrieval protocol using 271 bi-directional transport and widely used to deliver web-based 272 content descriptions to many hosts. However, it has well recognized 273 limitations of scalability in the number of HTTP clients since it 274 relies on the polling mechanism to keep information consistent 275 between the server and client. 277 SAP [3] is an announcement protocol that distributes session 278 descriptions via multicast. It does not support prioritization or 279 fine-grained metadata selection and update notifications, as it 280 places restrictions on metadata payload size and always sends the 281 whole metadata. It requires a wide-area multicast infrastructure for 282 it to be deployable beyond a local area network. 284 SIP [8] and SIP-specific event notification [11] can be used to 285 notify subscribers of the update of IMG metadata for bi-directional 286 transport. However, it is necessary for SIP Event to define an event 287 package as a standard protocol for each specific application 288 including IMGs. 290 We also perceive a lack of standard solution for flexible content 291 descriptions to support a multitude of application-specific metadata 292 and associated data models with differing amount of detail and 293 different target audiences. 295 SDP [2] has a text-encoded syntax to specify multimedia sessions for 296 announcements and invitations. It is primarily intended to describe 297 client capability requirements and enable client application 298 selection. Although SDP is extensible, it has limitations such as 299 structured extensibility and capability to reference properties of a 300 multimedia session from the description of another session. 302 These are mostly overcome by the XML-based SDPng [7], which is 303 intended for both two-way negotiation and also unidirectional 304 delivery. Since SDPng addresses multiparty multimedia conferences, it 305 is necessary to extend the XML schema in order to describe general 306 multimedia content. 308 4 Use Cases Requiring IMGs 310 4.1 Connectivity-based Use Cases 312 4.1.1 IP Datacast to a Wireless Receiver 314 IP Datacast is the delivery of IP-based services over broadcast 315 radio. Internet content delivery is therefore unidirectional in this 316 case. However, there can be significant benefits from being able to 317 provide rich media one-to-many services to such receivers. 319 There are two main classes of receiver in this use case: fixed 320 mains-powered; and mobile battery-powered. Both of these are affected 321 by radio phenomena and so robust, or error-resilient, delivery is 322 important. Carouselled metadata transfer (cyclically repeated with 323 fixed bandwidth) provides a base level of robustness for an IP 324 datacast based announcement system, although the design of 325 carouselled transfer should enable battery-powered receivers to go 326 through periods of sleep to extend their operational time between 327 charges. Insertion of Forward Error Correction (FEC) data into 328 metadata announcements improves error resilience, and reordering 329 (interleaving) data blocks further increases tolerance to burst 330 errors. 332 To enable receivers to more accurately specify the metadata they 333 are interested in, the unidirectional delivery may be distributed 334 between several logical channels. This is so that a receiver needs 335 only access the channels of interest and thus can reduce the amount 336 of time, storage and CPU resources needed for processing the IP 337 data. Also, hierarchical channels enable receivers to subscribe to 338 a, possibly well known, root multicast channel/group and 339 progressively access only those additional channels based on 340 metadata in parent channels. 342 In some cases the receiver may have multiple access interfaces adding 343 bi-directional communications capability. This enables a multitude of 344 options, but most importantly it enables NACK based reliability and 345 the individual retrieval of missed or not-multicasted sets of 346 metadata. 348 Thus, essential IMG features in this case include: robust 349 unidirectional delivery (with optional levels of reliability 350 including "plug-in FEC" supported by a transport layer protocol) 351 which implies easily identifiable segmentation of delivery data to 352 enable FEC, carousel, interleaving and other schemes possible; 353 effective identification of metadata sets (probably uniquely) to 354 enable more efficient use of multicast and unicast retrieval over 355 multiple access systems regardless of the parts of metadata and 356 application specific extensions in use; prioritization of metadata, 357 which can (for instance) be achieved by spreading it between channels 358 and allocating/distributing bandwidth accordingly. 360 Furthermore, some cases require IMG metadata authentication and some 361 group security/encryption and supporting security message exchanges 362 (out of band from the IMG multicast sessions). 364 4.1.2 Regular Fixed Dial-up Internet Connection 366 Dial-up connections tend to be reasonably slow (<56kbps in any case) 367 and thus large data transfers are less feasible, especially during an 368 active application session (such as a file transfer described by IMG 369 metadata). They can also be intermittent, especially if a user is 370 paying for the connected time, or connected through a less reliable 371 exchange. Thus this favors locally stored IMG metadata over web-based 372 browsing, especially where parts of the metadata change infrequently. 373 There may be no service provider preference over unicast and 374 multicast transport for small and medium numbers of users as the 375 last-mile dial-up connection limits per-user congestion, and a user 376 may prefer the more reliable option (unicast unless reliable 377 multicast is provided). 379 4.1.3 Broadband Always-on Fixed Internet Connection 381 Typically bandwidth is less of an issue to a broadband user and 382 unicast transport, such as using query-response methods, may be 383 typical for a PC user. If a system were only used in this context, 384 with content providers, ISPs and users having no other requirements, 385 then web-based browsing may be equally suitable. However, broadband 386 users sharing a local area network, especially wireless, may benefit 387 more from local storage features than on-line browsing, especially if 388 they have intermittent Internet access. 390 Some services on broadband, such as live media broadcasting, benefit 391 from multicast transport for streaming media because of scalability. 392 In the cases where multicast transport is already available, it is 393 convenient for a sender and receiver to retrieve IMG metadata over 394 multicast transport. Thus, broadband users may be forced to retrieve 395 IMG metadata over multicast if backbone operators require this to 396 keep system-wide bandwidth usage feasible. 398 4.2 Content-orientated Use Cases 400 IMGs will be able to support a very wide range of use cases for 401 enabling content/media delivery. The following few sections just 402 touch the surface of what is possible and are intended to provide an 403 understanding of the scope and type of IMG usage. Many more examples 404 may be relevant, for instance those detailed in [12]. There are 405 several unique features of IMGs that set them apart from related 406 application areas such as SLP based service location discovery, LDAP 407 based indexing services and search engines such as Google. Features 408 unique to IMGs include: 410 o IMG metadata is generally time-related 412 o There are timeliness requirements in the delivery of IMG 413 metadata 415 o IMG metadata may be updated as time elapses or when an event 416 arises 418 4.2.1 TV and Radio Program Delivery 420 A sender of audio/video streaming content can use the IMG metadata to 421 describe the scheduling and other properties of audio/video sessions 422 and events within those sessions, such as individual TV and radio 423 programs and segments within those programs. IMG metadata describing 424 audio/video streaming content could be represented in a format 425 similar to that of a TV guide in newspapers, or an Electronic Program 426 Guide available on digital TV receivers. 428 TV and radio programs can be selected for reception either manually 429 by the end-user or automatically based on the content descriptions 430 and the preferences of the user. The received TV and radio content 431 can be either presented in real time or recorded for later 432 consumption. There may be changes in the scheduling of a TV or a 433 radio program, possibly affecting the transmission times of 434 subsequent programs. IMG metadata can be used to notify receivers of 435 such changes, enabling users to be prompted or recording times to be 436 adjusted. 438 4.2.2 Media Coverage of a Live Event 440 The media coverage of a live event such as a rock concert or a sports 441 event is a special case of regular TV/radio programming. There may be 442 unexpected changes in the scheduling of live event, or the event may 443 be unscheduled to start with (such as breaking news). In addition to 444 audio/video streams, textual information relevant to the event (e.g. 445 statistics of the players during a football match) may be sent to 446 user terminals. Different transport modes or even different access 447 technologies can be used for the different media: for example, a 448 unidirectional datacast transport could be used for the audio/video 449 streams and an interactive cellular connection for the textual data. 450 IMG metadata should enable terminals to discover the availability of 451 different media used to cover a live event. 453 4.2.3 Distance Learning 455 IMG metadata could describe compound sessions or services enabling 456 several alternative interaction modes between the participants. For 457 example, the combination of one-to-many media streaming, unicast 458 messaging and download of presentation material could be useful for 459 distance learning. 461 4.2.4 Multiplayer Gaming 463 Multiplayer games are an example of real time multiparty 464 communication sessions that could be advertised using IMGs. A gaming 465 session could be advertised either by a dedicated server, or by the 466 terminals of individual users. A user could use IMGs to learn of 467 active multiplayer gaming sessions, or advertise the users interest 468 in establishing such a session. 470 4.2.5 File Distribution 472 IMGs support the communication of file delivery session properties, 473 enabling the scheduled delivery or synchronization of files between a 474 number of hosts. The received IMG metadata could be subsequently used 475 by any application (also outside the scope of IMGs), for example to 476 download a file with a software update. IMG metadata can provide a 477 description to each file in a file delivery session, assisting users 478 or receiving software in selecting individual files for reception. 480 For example, when a content provider wants to distribute a large 481 amount of data in file format to thousands clients, the content 482 provider can use IMG metadata to schedule the delivery effectively. 484 Since IMG metadata can describe time-related data for each receiver, 485 the content provider can schedule delivery time for each receiver. 486 This can save network bandwidth and delivery capacity of senders. In 487 addition, IMG metadata can be used to consistency check, and thus 488 synchronize, a set of files between a sender host and receiver host, 489 when those files change as time elapses. 491 4.2.6 Coming-release and Pre-released Content 493 IMG metadata can be used to describe items of content before the 494 details of their final release are known. A user may be interested 495 in coming content (a new movie or software title where some aspects 496 of the content description are known in advance) and so subscribe 497 to an information service which notifies the user of changes to 498 metadata describing that content. Thus, as the coming release, or 499 pre-releases, (such as movie trailers or software demos) become 500 available the IMG metadata changes and the user is notified of this 501 change. For example, the user could see an announcement of a movie 502 that will be released sometime in the next few months, and 503 configure the user's terminal to receive and record any trailers or 504 promotional material as they become available. 506 5 Requirements 508 5.1 General Requirements 510 5.1.1 Independence of IMG Operations from IMG Metadata 512 REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG 513 message body MUST be allowed. 515 REQ GEN-2: Delivery mechanisms SHOULD support many different 516 applications' specific metadata formats to keep the system 517 interoperable with existing applications. 519 This provides flexibility in selecting/designing IMG transport 520 protocol suited to various scenarios. 522 5.1.2 Multiple IMG Senders 524 REQ GEN-3: IMG receivers MUST be allowed to communicate with any 525 number of IMG senders simultaneously. 527 This might lead to receiving redundant IMG metadata describing the 528 same items, however it enables the IMG receiver access to more IMG 529 metadata than may be available from a single IMG sender. This also 530 provides flexibility for the IMG transport protocols and does not 531 preclude a mechanism to solve inconsistency among IMG metadata due to 532 multiple IMG senders. This document assumes a typical IMG environment 533 will involve many more IMG receivers than IMG senders and that IMG 534 senders are continually connected for the duration of interest 535 (rather than intermittently connected). 537 5.1.3 Modularity 539 REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 540 several IMG Operations. 542 This is for the purpose of extending functionality (e.g. several or 543 one protocol(s) to provide all the needed operations). Applications 544 can select an appropriate operation set to fulfill their purpose. 546 5.2 Delivery Properties 548 This section describes general performance requirements based on the 549 assumption that the range of IMG usage shall be important. However, 550 it may be noted that requirements of delivery properties may vary 551 based on the usage scenario, and thus some limited use 552 implementations place less importance on some requirements. 554 For example, it is clear that a multicast transport may provide more 555 scalable delivery than a unicast transport, however scalability 556 requirements do not preclude the unicast transport mechanisms. In 557 this sense, scalability is always important for the protocols 558 irrespective of transport mechanisms. 560 5.2.1 Scalability 562 REQ DEL-1: The IMG system MUST be scalable to large numbers of 563 messages, so as to allow design and use of delivery mechanisms that 564 will not fail in delivering up-to-date information under huge numbers 565 of transactions and massive quantities of IMG metadata. 567 REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 568 sending unnecessary IMG metadata that have been stored or deleted in 569 IMG receivers. 571 REQ DEL-3: The protocol MUST be scalable to very large audience sizes 572 requiring IMG delivery. 574 5.2.2 Support for Intermittent Connectivity 576 REQ DEL-4: The system MUST enable IMG receivers with intermittent 577 access to network resources (connectivity) to receive and adequately 578 maintain sufficient IMG metadata. 580 This allows intermittent access to save power where there is no need 581 to keep communications links powered-up while they are sitting idle. 582 For instance, in this situation periodic bursts of notifies, or a 583 fast cycling update carousel, allows hosts to wake up for short 584 periods of time and still be kept up-to-date. This can be beneficial 585 for IMG receivers with sporadic connections to the fixed Internet, 586 but is critical in the battery-powered wireless Internet. 588 The implication of intermittent connectivity is that immediate 589 distribution of changes becomes infeasible and so managing data 590 consistency should be focused on the timely delivery of data. 592 5.2.3 Congestion Control 594 REQ DEL-5: Internet-friendly congestion control MUST be provided for 595 use on the public Internet. 597 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 598 an IMG metadata item has lifetime information and its lifetime is 599 over. This will lessen the need for notifications of updates from the 600 IMG sender to the IMG receiver to invalidate the item and may enable 601 lesser congestion. 603 5.2.4 Sender and Receiver Driven Delivery 605 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 606 receiver-driven or both delivery schemes. 608 Sender-driven delivery achieves high scalability without interaction 609 between the IMG sender and receiver. This avoids keeping track of a 610 delivery state for every IMG receiver. 612 In contrast, the receiver-driven delivery provides on-demand delivery 613 for IMG receivers. Since an IMG sender's complete IMG metadata may be 614 a very large amount of data, the IMG receiver needs to be able to 615 access the guide when convenient (e.g. when sufficient network 616 bandwidth is available to the IMG receiver). 618 5.3 Customized IMGs 620 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 622 The IMG receiver may require a subset of all the IMG metadata 623 available according to their preferences (type of content, media 624 description, appropriate age group, etc.) and configuration. 626 The IMG receiver might send its preferences in the IMG operations 627 which can specify user specific IMG metadata to be delivered. These 628 preferences could consist of filtering rules. When receiving these 629 messages, the IMG sender might respond with appropriate messages 630 carrying a subset of IMG metadata which matches the IMG receiver's 631 preferences. 633 This mechanism can reduce the amount of IMG metadata delivered from 634 the IMG sender to IMG receiver, and consequently it can save the 635 resource consumption on the IMG entities and networks. It is 636 typically useful in unicast cases and also beneficial in multicast 637 cases where an IMG sender distributes the same IMG metadata to 638 interested IMG receivers at the same time. 640 For multicast and unicast cases where the IMG sender does not provide 641 customized IMG metadata, the IMG receiver could receive all IMG 642 metadata transmitted (on its joined channels). However, it may select 643 and filter the IMG metadata to get customized IMG metadata by its 644 preferences, and thus drop unwanted metadata immediately upon 645 reception. 647 Customized metadata might be achieved by changing the IMG 648 descriptions sent and IMG receivers and/or changing the delivery 649 properties (channels used). 651 Note, customization and scalability are only somewhat exclusive. 652 Systems providing an IMG receiver to an IMG sender request-based 653 customization, will be generally less scalable to massive IMG 654 receiver populations than those without this return signaling 655 technique. Thus, customization, as with any feature which affects 656 scalability, should be carefully designed for the intended 657 application, and it may not be possible that a one-size-fits-all 658 solution for customization would meet the scalability requirements 659 for all applications and deployment cases. 661 5.4 Reliability 663 5.4.1 Managing Consistency 665 IMG metadata tends to change as time elapses, as new content is 666 added, the old IMG metadata stored in the IMG receiver becomes 667 unavailable and the parameters of the existing IMG metadata are 668 changed. 670 REQ REL-1: The system MUST manage IMG metadata consistency. 672 The IMG sender can either simply make updates available 673 (unsynchronized) or IMG sender and receiver can interact to keep 674 their copies of the IMG metadata synchronized. 676 In the unsynchronized model, the IMG sender does not know whether a 677 particular IMG receiver has an up-to-date copy of the IMG metadata. 679 In the synchronized model, updating a cached copy of the IMG metadata 680 is necessary to control consistency when the IMG sender or receiver 681 could not communicate for a while. In this case, the IMG sender or 682 receiver may need to confirm its consistency by IMG operations. 684 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 685 SHOULD be notified of such changes. 687 Fulfilling this requirements needs to be compatible with the 688 scalability requirements for the number of IMG receivers and the 689 consistency of metadata. 691 Depending on the size of the guide, the interested party may want to 692 defer retrieving the actual information. The change notification 693 should be addressed to a logical user (or user group), rather than a 694 host, since users may change devices. 696 Note that depending on the deployment environment and application 697 specifics, the level of acceptable inconsistency varies. Thus, this 698 document does not define inconsistency as specific time and state 699 differences between IMG metadata stored in an IMG sender and IMG 700 metadata stored in an IMG receiver. 702 In general, the consistency of metadata for a content and media is 703 more important immediately prior to and during the media's 704 session(s). Hosts which forward (or otherwise resend) metadata may be 705 less tolerant to inconsistencies as delivering out of date data is 706 both misleading and bandwidth inefficient. 708 5.4.2 Reliable Message Exchange 710 REQ REL-4: An IMG transport protocol MUST support reliable message 711 exchange. 713 The extent to which this could result in 100% error free delivery to 714 100% of IMG receivers is a statistical characteristic of the 715 protocols used. Usage of reliable IMG delivery mechanisms is expected 716 to depend on the extent to which underlying networks provide 717 reliability and, conversely, introduce errors. Note, some deployments 718 of IMG transport protocols may not aim to provide perfect reception 719 to all IMG receivers in all possible cases. 721 5.5 IMG Descriptions 723 REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 724 protocol, such that an application receiving the same metadata over 725 any one (or more) of several network connections and/or IMG transport 726 protocols will interpret the metadata in exactly the same way. (This 727 also relates to the 'Independence of IMG Operations from IMG 728 Metadata' requirements.) 730 REQ DES-2: IMG delivery MUST enable the carriage of any format of 731 application-specific metadata. 733 Thus, the system will support the description of many kinds of 734 multimedia content, without the need for a single homogenous metadata 735 syntax for all uses (which would be infeasible anyway). This is 736 essential for environments using IMG systems to support many kinds of 737 multimedia content and to achieve wide applicability. 739 REQ DES-3: Whereas specific applications relying on IMGs will need to 740 select one or more specific application-specific metadata formats 741 (standard, syntax, etc.), the IMG system MUST be independent of this 742 (it may be aware, but it will operate in the same way for all). 744 Thus, a metadata transfer envelope format, that is uniform across all 745 different application-specific IMG metadata formats, is needed. The 746 envelope would reference (point to) or carry (as payload) some 747 application-specific metadata, and the envelope would support the 748 maintenance of the application-specific metadata, which may also 749 serve the metadata relationships determined by the data model(s) 750 used. The envelope would not need to be aware of the data model(s) in 751 use. 753 REQ DES-4: IMG metadata MUST be structured to enable fragmentation 754 for efficient delivery. 756 This is intended to ensure that and IMG sender with more than a 757 trivial knowledge of metadata is able to deliver only part of its 758 (and the global) complete IMG metadata knowledge. (For instance, a 759 trivial quantity of knowledge could be a single SDP description.) In 760 general, the resolution of this fragmentation will be very much 761 dependent on the optimal delivery of a deployment, although some 762 metadata syntaxes will inherently effect the sensible lower limit for 763 a single element/fragment. 765 REQ DES-5: A metadata transfer envelope MUST be defined to include 766 essential parameters. 768 Examples of essential parameters are those that allow the metadata in 769 question to be uniquely identified and updated by new versions of the 770 same metadata. 772 REQ DES-6: It SHALL be possible to deduce the metadata format via the 773 metadata transfer envelope. 775 REQ DES-7: IMG senders SHALL use a metadata transfer envelope for 776 each IMG metadata transfer. 778 Thus, it will even be possible to describe relationships between 779 syntactically dissimilar application-specific formats within the same 780 body of IMG metadata knowledge. (E.g. a data model could be 781 instantiated using both SDP and SDPng.) 783 REQ DES-8: IMG metadata SHOULD support the description of differences 784 between update version and old version of IMG metadata when IMG 785 delivery mechanism carries updated IMG metadata and those differences 786 are considerably little. (E.g. by providing a 'delta' of the two 787 versions. This also relates the delivery property requirements for 788 congestion control in Section 5.2.3). 790 6 Security Considerations 792 Internet Media Guides are used to convey information about multimedia 793 resources from one or more IMG senders across one or intermediaries 794 to one or more IMG receivers. IMG metadata may be pushed to the IMG 795 receivers or interactively retrieved by them. IMGs provide metadata 796 as well as scheduling and rendezvous information about multimedia 797 resources, etc. and requests for IMG metadata may contain information 798 about the requesting users. 800 The information contained in IMG metadata as well as the operations 801 related to IMGs should be secured to avoid forged information, 802 misdirected users, spoofed IMG senders, etc. and to protect user 803 privacy. 805 The remainder of section addresses the security requirements for 806 IMGs. 808 6.1 IMG Authentication and Integrity 810 IMG metadata and its parts need to be protected against unauthorized 811 altering/adding/deletion on the way. Their originator needs to be 812 authenticated. 814 REQ AUT-1: It MUST be possible to authenticate the originator of a 815 set of IMG metadata. 817 REQ AUT-2: It MUST be possible to authenticate the originator of a 818 subpart of IMG metadata (e.g. a delta or a subset of the 819 information). 821 REQ AUT-3: It MUST be possible to validate the integrity of IMG 822 metadata. 824 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 825 of IMG metadata (e.g. a delta or a subset of the information). 827 REQ AUT-5: It MUST be possible to separate or combine individually 828 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 829 without invalidating the authentication. 831 REQ AUT-6: It MUST be possible to validate the integrity of an 832 individually authenticated piece of IMG metadata even after this 833 piece had been separated from other pieces of IMG metadata and 834 combined with other pieces to form new IMG metadata. 836 REQ AUT-7: It MUST be possible to authenticate the originator of an 837 IMG operation. 839 REQ AUT-8: It MUST be possible to validate the integrity of any 840 contents of an IMG operation (e.g. the subscription or inquiry 841 information). 843 6.2 Privacy 845 Customized IMG metadata and IMG metadata delivered by notification to 846 individual users may reveal information about the habits and 847 preferences of a user and may thus deserve confidentiality 848 protection, even though the information itself is public. 850 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 851 or retrieve certain (parts of) IMG metadata confidential. 853 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 854 metadata, or pointers to IMG metadata delivered to individual users 855 or groups of users confidential. 857 REQ PRI-3: It SHOULD be possible to ensure this confidentiality 858 end-to-end, that is, to prevent intermediaries (such as IMG 859 transceivers) from accessing the contained information. 861 6.3 Access Control for IMGs 863 Some IMG metadata may be freely available, while access to other IMG 864 metadata may be restricted to closed user groups (e.g. paying 865 subscribers). Also, different parts of IMG metadata may be protected 866 at different levels: e.g. metadata describing a media session may be 867 freely accessible while rendezvous information to actually access the 868 media session may require authorization. 870 REQ ACC-1: It MUST be possible to authorize user access to IMG 871 metadata. 873 REQ ACC-2: It MUST be possible to authorize access of users to pieces 874 of IMG metadata (delta information, subparts, pointers). 876 REQ ACC-3: It MUST be possible to require different authorization for 877 different parts of the same IMG metadata. 879 REQ ACC-4: It MUST be possible to access selected IMG metadata 880 anonymously. 882 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 883 receive (parts of) IMG metadata in order to avoid being identified by 884 the IMG sender. 886 REQ ACC-6: It SHOULD be possible for an IMG transceiver to select 887 suitable authorization methods which are compatible between both 888 IMG senders and IMG receivers it interacts with. 890 REQ ACC-7: It MAY be possible for IMG senders to require certain 891 authorization that cannot be modified by intermediaries. 893 6.4 Denial-of-Service attacks 895 Retrieving or distributing IMG metadata may require state in the IMG 896 senders, transceivers, and/or receivers for the respective IMG 897 transport sessions. Attackers may create large numbers of sessions 898 with any of the above IMG entities to disrupt regular operation. 900 REQ DOS-1: IMG operations SHOULD be authenticated. 902 REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up 903 session state in IMG entities to exhaust their resources. 905 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 906 resources of IMG entities by flooding them with IMG metadata. 908 As an example, two potential solutions which may be considered are 909 running an IMG entity in stateless mode or identification and 910 discarding of malicious packets by an IMG entity. 912 6.5 Replay Attacks 914 IMG metadata disseminated by an IMG sender or an IMG transceiver may 915 be updated, deleted, or lose validity over time for some other 916 reasons. Replaying outdated IMG metadata needs to be prevented. 918 Furthermore, replay attacks may also apply to IMG operations (rather 919 than just their payload). Replaying operations also needs to be 920 prevented. 922 REQ REP-1: IMG metadata MUST be protected against partial or full 923 replacement of newer ("current") versions by older ones. 925 In a system with multiple senders it may not be feasible to prevent 926 some senders delivering older versions of metadata than others - as a 927 result of imperfect sender-sender data consistency. Thus, replay 928 attacks and delivery of inconsistent data requires that an IMG 929 receiver veryfies that the IMG metadata is valid and reliable by 930 using some security mechanism(s) (e.g. authorization, authentication 931 or integrity). 933 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 934 the IMG operations. 936 The level of threat from replay attacks varies very much depending on 937 system scale and how well defined or open it is. Thus mitigating 938 replay attacks may lead to different solutions for different systems, 939 independent of the basic delivery method and metadata definitions. A 940 system with multiple senders presents a more challenging scenario for 941 handling replay attacks. As an example, bundling metadata with a 942 security mechanism is one potential solution. 944 7 IANA Considerations 946 This document does not request any IANA action. 948 8 Normative References 950 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 951 levels," RFC 2119, Internet Engineering Task Force, March 1997. 953 9 Informative References 955 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 956 RFC 2327, Internet Engineering Task Force, April 1998. 958 [3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 959 protocol," RFC 2974, Internet Engineering Task Force, October 2000. 961 [4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 963 [5] Session Directory Tool, 964 http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/ 966 [6] Digital Video Broadcasting Project, 967 http://www.dvb.org/ 969 [7] D. Kutscher, J. Ott, and C. Bormann, "Session description and 970 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 971 Internet Engineering Task Force, October 2003. Work in progress. 973 [8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 974 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 975 initiation protocol," RFC 3261, Internet Engineering Task Force, June 976 2002. 978 [9] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, 979 "A framework for the usage of Internet media guides," Internet Draft 980 draft-ietf-mmusic-img-framework-09, Internet Engineering Task Force, 981 December 2005. Work in progress. 983 [10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 984 Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 985 RFC 2616, Internet Engineering Task Force, June 1999. 987 [11] A. B. Roach, "Session initiation protocol (sip)-specific event 988 notification," RFC 3265, Internet Engineering Task Force, June 2002. 990 [12] B. Quinn and K. Almeroth, "IP multicast applications: Challenges 991 and solutions," RFC 3170, Internet Engineering Task Force, September 992 2001. 994 10 Acknowledgements 996 The authors would like to thank Hitoshi Asaeda, Gonzalo Camarillo, 997 Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins, 998 Toni Paila and Magnus Westerlund for their excellent comments and 999 ideas on this work. 1001 11 Authors' Addresses 1003 Yuji Nomura 1004 Fujitsu Laboratories Ltd. 1005 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 1006 Japan 1007 Email: nom@flab.fujitsu.co.jp 1009 Rod Walsh 1010 Nokia Research Center 1011 P.O. Box 100, FIN-33721 Tampere 1012 Finland 1013 Email: rod.walsh@nokia.com 1014 Juha-Pekka Luoma 1015 Nokia Research Center 1016 P.O. Box 100, FIN-33721 Tampere 1017 Finland 1018 Email: juha-pekka.luoma@nokia.com 1020 Joerg Ott 1021 Universitaet Bremen 1022 MZH 5180 1023 Bibliothekstr. 1 1024 D-28359 Bremen 1025 Germany 1026 Email: jo@tzi.uni-bremen.de 1028 Henning Schulzrinne 1029 Dept. of Computer Science 1030 Columbia University 1031 1214 Amsterdam Avenue 1032 New York, NY 10027 1033 USA 1034 Email: schulzrinne@cs.columbia.edu 1036 Intellectual Property Statement 1038 The IETF takes no position regarding the validity or scope of any 1039 Intellectual Property Rights or other rights that might be claimed to 1040 pertain to the implementation or use of the technology described in 1041 this document or the extent to which any license under such rights 1042 might or might not be available; nor does it represent that it has 1043 made any independent effort to identify any such rights. Information 1044 on the procedures with respect to rights in RFC documents can be 1045 found in BCP 78 and BCP 79. 1047 Copies of IPR disclosures made to the IETF Secretariat and any 1048 assurances of licenses to be made available, or the result of an 1049 attempt made to obtain a general license or permission for the use of 1050 such proprietary rights by implementers or users of this 1051 specification can be obtained from the IETF on-line IPR repository at 1052 http://www.ietf.org/ipr. 1054 The IETF invites any interested party to bring to its attention any 1055 copyrights, patents or patent applications, or other proprietary 1056 rights that may cover technology that may be required to implement 1057 this standard. Please address the information to the IETF at ietf- 1058 ipr@ietf.org. 1060 Disclaimer of Validity 1062 This document and the information contained herein are provided on 1063 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1064 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1065 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1066 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1067 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1068 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1069 PARTICULAR PURPOSE. 1071 Copyright Statement 1073 Copyright (C) The Internet Society (2005). This document is subject 1074 to the rights, licenses and restrictions contained in BCP 78, and 1075 except as set forth therein, the authors retain all their rights. 1077 Acknowledgement 1079 Funding for the RFC Editor function is currently provided by the 1080 Internet Society.