Internet Engineering Task Force MMUSIC WG Internet Draft Y. Nomura Fujitsu Labs. R. Walsh Nokia H. Schulzrinne Columbia University draft-nomura-mmusic-img-requirements-01.txt June 30, 2003 Expires: December 2003 Protocol Requirements for Internet Media Guides STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This memo specifies requirements for a protocol for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide development of an IMG protocol for efficient and scalable delivery. Table of Contents 1 Introduction ........................................ 2 2 Terminology ......................................... 3 Y. Nomura et. al. [Page 1] Internet Draft IMG Requirements June 30, 2003 3 Overview ............................................ 3 4 Requirements ........................................ 3 4.1 Separating IMG operations from IMGs ................. 4 4.2 Multiple IMG Senders ................................ 4 4.3 Modularity .......................................... 4 4.4 Performance ......................................... 4 4.4.1 Scalability ......................................... 4 4.4.2 Low Resource Consumption ............................ 5 4.4.3 Preventing Congestion ............................... 5 4.4.4 Preventing stale state .............................. 5 4.4.5 Change Notification ................................. 5 4.5 Flexibility ......................................... 6 4.5.1 Customized IMGs ..................................... 6 4.5.2 Many kinds of multimedia content .................... 6 4.5.3 Sender- and Receiver-Driven ......................... 6 4.6 Reliability ......................................... 6 4.6.1 Managing consistency ................................ 6 4.6.2 Reliable Message Exchange ........................... 7 4.7 IMG Description ..................................... 7 5 Security Considerations ............................. 7 5.1 IMG Authentication .................................. 7 5.2 Access Control for IMG .............................. 8 5.3 Denial-of-Service attacks ........................... 8 5.4 Replay Attacks ...................................... 8 6 Acknowledgements .................................... 8 7 Bibliography ........................................ 8 8 Author's Addresses .................................. 9 1 Introduction This document defines requirements that an Internet Media Guide (IMG) [1] protocol must satisfy in order to deliver IMG to a potentially large audience. Since the IMG can describe many kinds of multimedia content, the protocol are generally applicable to several scenarios. In considering wide applicability, this document provides general requiements which are independent of any transport layer mechanism, existing protocol and application. IMG framework document presents general IMG operations and descriptors, therefore this document describes its performance, flexibility and reliability. Additionally, there might be several implementations to meet the requirements within the IMG framework. This document reflects investigating work on delivery mechanisms for IMGs and generalizing work on session announcement and initiation protocols, especially in the field of the MMUSIC working group Y. Nomura et. al. [Page 2] Internet Draft IMG Requirements June 30, 2003 (SAP[2], SIP[3], SDP[4]). 2 Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. Internet Media Guide (IMG): An IMG is a set of meta-data describing the features of multimedia content. For example, meta-data may consist of the URI, title, air time, bandwidth needed, file size, text summary, genre, and access restrictions. IMG Delivery: The process of exchanging IMG metadata both in terms of large scale and atomic data transfers. IMG Sender: An IMG sender is a logical entity that sends IMGs to one or more IMG receivers. IMG Receiver: An IMG receiver is a logical entity that receives IMGs from an IMG source. IMG Operations: An atomic process for the IMG protocol to deliver IMG or control the IMG sender or IMG receiver. 3 Overview First of all, the section summarizes the features of the IMG and IMG protocol. o IMG data may be updated as time elapses because content described in the guide may be changed. For example, the airtime of an event such as a concert or sports event may change, possibly affecting the air time of subsequent medias. o We assume that any Internet host can be a source of content and thus IMG. Some of the content sources and sinks may only be connected to the Internet sporadically. Also, a single human user may use many different devices to access meta data, including bandwidth-constrained mobile devices. Thus, we envision that IMGs can be sent and received by, among others, by cellular phones, PDA (Personal Digital Assistant), personal computer, streaming video server, set-top box, video camera, and PVR (Personal Video Recorder). 4 Requirements Y. Nomura et. al. [Page 3] Internet Draft IMG Requirements June 30, 2003 Throughout the rest of this section, "the protocol" refers to the IMG protocol. 4.1 Separating IMG operations from IMGs The protocol MUST allow to carry different kinds of IMG metadata format in the IMG message body. The protocol SHOULD be designed to take advantage an existing metadata format. While it doesn't rely on the specific format, this provides flexibility for the protocol, which is applied to various scenarios. 4.2 Multiple IMG Senders The protocol MUST allow a IMG receiver to communicate with any number of IMG sender simultaneously. This might lead to receiving duplicated IMGs and consuming unneeded resources, however this creates potential opportunities covering more IMGs than a single IMG sender. This also provides flexibility for the protocol. The protocol doesn't preclude a mechanism to solve inconsistency among IMGs due to multiple IMG senders. 4.3 Modularity The protocol MUST allow to combine several IMG operations for the purpose of extending functionality. The protocol MUST be designed to make the protocol implementation simple, however it might be applied various scenarios. 4.4 Performance Although the performance requirements may depend on the scenarios, the section describes general performance requirements based on the assumption that the protocol is always required to achieve the wide applicability for several scenarios. Example: It is clear that a multicast transport provides more scalable delivery than an unicast transport, however the section doesn't preclude the specific transport mechanism. In this sense, scalability is always important for the protocols irrespective of transport mechanisms. 4.4.1 Scalability The protocol MUST be scalable in the number of transactions and the amount of IMGs to deliver up-to-date IMGs from the IMG sender to receiver. Y. Nomura et. al. [Page 4] Internet Draft IMG Requirements June 30, 2003 The protocol SHOULD provide the mechanism that the IMG sender doesn't send verbose IMGs which have been stored or deleted in the IMG receiver. The protocol MUST be scalable in the number of audience, who require IMG delivery. 4.4.2 Low Resource Consumption The protocol MUST allow an efficient intermittent access to save power. There is no need to keep communications links powered up while they are sitting idle. Thus, either periodic bursts of notifies, or a fast cycling update carousel allows hosts to wake up for short periods of time and still be kept up to date. This may be beneficial in the fixed-Internet, but is critical in the battery powered wireless Internet. 4.4.3 Preventing Congestion Internet friendly congestion (it is possible that the minimal required metadata transfer is less than the total metadata (versions) during the life of a certain "media") - so notifies can reduce congestion, especially for very large groups, while allowing individual "congestion free" parts of the Internet to do things "their way". Where some hosts are on unidirectional links, and other have bi-directional links (or both), this is sensible " diversity". 4.4.4 Preventing stale state The IMG entities MUST support to prevent stale state in an IMG. When an IMG item has lifetime information, the IMG entity SHOULD invalidate the IMG item when its lifetime is over. This mechanism can eliminate a invalidation message from the IMG sender to receiver. 4.4.5 Change Notification Since IMGs can change at any time, receivers of IMGs SHOULD be notified of such changes, without necessarily re-sending the whole IMG. Depending on the size of the guide, the interested party may want to defer retrieving the actual information. The change notification should be addressed to a logical user, not a host, since users may change devices. As an example, consider a storage device requires the up-to-date video file from an IP-reachable video camera but the camera is connected only sporadically. When the camera is connected on the network and has a new video object, the storage device must be notified of its availability immediately. Y. Nomura et. al. [Page 5] Internet Draft IMG Requirements June 30, 2003 4.5 Flexibility 4.5.1 Customized IMGs The protocol SHOULD allow to deliver customized IMGs. The IMG receiver may require a subset of the IMG according to their preference (type of content, media format, appropriate age group, etc.) and configuration. The IMG receiver may send its preferences in the IMG operations which can specify interested IMGs to be delivered. The preferences might consist of filtering rules. When receiving these messages, the IMG sender may respond appropriate messages carrying a subset of IMGs which matches the receiver's preferences. This mechanism can reduce the amount of IMGs delivered from the sender to receiver, and consequently it can save the resource consumption on the IMG Entities and IMG networks. 4.5.2 Many kinds of multimedia content The protocol MUST deliver a variety of media formats, which describe multimedia items available either for download, streaming or multicast distribution. It is essential for the protocol to support many kinds of multimedia content and to achieve wide applicability. 4.5.3 Sender- and Receiver-Driven The protocol MUST be flexible in choosing sender-driven, receiver- driven or both delivery. Server-driven delivery achieves highly scalability without interaction between the IMG sender and receiver. This avoids keeping track of a delivery state at every receivers. In contrast, the receiver-driven delivery provides on-demand delivery for IMG receivers. Since an IMG may contain a large amount of data, the IMG receiver needs to be able to access the guide when convenient (e.g., when sufficient network bandwidth is available to the user). Combining sender-driven and receiver-driven might be a flexible approach to solve the problems in both delivery mechanisms. 4.6 Reliability 4.6.1 Managing consistency IMGs tend to change as time elapses, as new content is added, the old IMG stored in the IMG receiver becomes unavailable and the parameters of the existing IMG are changed. Y. Nomura et. al. [Page 6] Internet Draft IMG Requirements June 30, 2003 The IMG sender can either simply make updates available (unsynchronized) or IMG sender and receiver can interact to keep their copies of the IMG synchronized. In the unsynchronized model, the source does not know whether a particular receiver has an up-to-date copy of the IMG. In the synchronized model, updating cached copy of the IMG is necessary to control consistency when the IMG sender or receiver couldn't communicate for a while. In this case, the IMG sender or receiver may need to confirm its consistency by IMG operations. Thus, the protocol MUST allow to manage IMG consistency between the IMG sender and receiver. 4.6.2 Reliable Message Exchange If a bi-directional transport connects the IMG receiver with sender, this protocol SHOULD support a reliable message exchange. In the unidirectional transport case, it is RECOMMENDED to implement this. 4.7 IMG Description To avoid interoperability problems, an IMG description should be standardized. The IMG format MUST support pointer type description to refer other another IMG. An IMG may refer multiple content, and content may consist of sub- content. Each sub-content is described by a set of parameters. Thus, an IMG is structured data. An IMG may refer (via URI) to other IMGs. Such references improve flexibility and scalability and simplifies decentralized management of IMGs. The IMG format MUST support delta type description to avoid redundant delivery of IMGs. 5 Security Considerations 5.1 IMG Authentication Customized IMGs may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even though the information itself is public. To prevent it, the protocol SHOULD provide for message authentication and Y. Nomura et. al. [Page 7] Internet Draft IMG Requirements June 30, 2003 confidentiality. 5.2 Access Control for IMG The protocol SHOULD provide receiver authorization mechanism to selectively reject accessing the IMG. Some or all of any IMG sender's metadata may be private or valuable, the mechanism can avoid undesired accesses from anonymous receivers. 5.3 Denial-of-Service attacks The protocol needs to keep the request state to establish IMG delivery sessions, and this request can be used by attackers to consume resources on the IMG sender. To reduce the impact of the attack, the protocol MUST provide authentication mechanism. 5.4 Replay Attacks The protocol MUST provide mechanisms to mitigate replay attacks on the IMG operations. 6 Acknowledgements The authors would like to thank Hitoshi Asaeda (INRIA), Juka-Pekka Luoma (Nokia) , Petri Koskelainen (Nokia) and Toni Paila (Nokia) for thier comments on the draft. 7 Bibliography [1] Y. Nomura and H. Schulzrinne, "A framework for Internet media guides," internet draft, Internet Engineering Task Force, Feb. 2003. Work in progress. [2] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002. [4] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. [5] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. Y. Nomura et. al. [Page 8] Internet Draft IMG Requirements June 30, 2003 8 Author's Addresses Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan Email: nom@flab.fujitsu.co.jp Rod Walsh Nokia Corporation Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland Email: rod,walsh@nokia.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Full Copyright Statement Copyright (c) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Y. Nomura et. al. [Page 9] Internet Draft IMG Requirements June 30, 2003 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Y. Nomura et. al. [Page 10]