Internet Engineering Task Force Internet Draft Nomura/Schulzrinne Fujitsu/Columbia U. draft-nomura-mmusic-img-framework-00.txt February 24, 2003 Expires: August 2003 A Framework 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 provides a framework for Internet media guides (IMGs). An IMG is a set of meta-data describing the features of multimedia content in order to subscribe to, manage and exchange multimedia content. We present an architecture, a protocol model and IMG data model for several scenarios. 1 Introduction This document presents a framework for Internet Media Guides (IMGs) to facilitate the standardization of protocols and formats. IMGs allow users to initiate streaming media sessions, schedule delivery of downloadable or multicast content [1] or listen to live Nomura/Schulzrinne [Page 1] Internet Draft IMG Framework February 24, 2003 multicast sessions. An IMG consists of meta-data describing the features of multimedia content. IMGs are designed to be independent of the particular access network and end system. Media guides are generated, modified and processed by various network entities. This document describes several such architectures. This document does not propose or recommend protocols or meta-data formats. 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 [2]. Internet Media Guides (IMGs): An IMG is a set of meta-data describing 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 source: An IMG source 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 transceiver: An IMG transceiver combines an IMG receiver and source. 3 IMG Network Model 3.1 Use Case Models of the IMG Typical use case models of the IMG are following four models divided into using ways (automatically, manually) and obtaining time of content (real time and time shift). Table 1 shows these models and typical examples. | Manually | Automatically -----------+-------------+----------------------------------- Real Time | (1) TV | (3) Live conference broadcasting Time Shift | (2) VCR | (4) Preference-based recording (1) Television model: A human user manually uses the IMG, specifies Nomura/Schulzrinne [Page 2] Internet Draft IMG Framework February 24, 2003 the content and watches it in real time. If the airtime is changed suddenly and the sender of the IMG notifies the user, the user can follow the preferred content manually. (2) VCR model: A human user manually uses the IMG, specifies content to be stored. The user watches it by time-shift. If the airtime is changed suddenly and the sender of the IMG notifies the user, the user can manually specify the preferred content again. (3) Live conference broadcasting model: A device uses the media guide automatically, specifies content and shows it to users when it is available. If the availability is changed suddenly and the sender of the IMG notifies the device of the change, the device can follow this change automatically. (4) Preference-based recording model: A device uses the IMG to store content automatically according to a user's direction such as a preference and configuration. If the availability is changed suddenly and the sender of the IMG notifies the device, the device can follow this change automatically. 3.2 Devices Using the IMG We assume that any Internet host can be a source of content and meta data. Some of the content sources and receivers may only be connected to the Internet intermittently. Also, a single human user may use many different devices to access meta data, including bandwidth- constrained mobile devices. We envision that IMGs can be sent and received by cellular phones, PDAs (Personal Digital Assistant), personal computers, streaming video servers, set-top boxes, video cameras, PVRs (Personal Video Recorder), among others. 3.3 Architectures This section distinguishes different types of IMG interactions. An IMG may be exchanged on a one-to-one basis between a particular source and receiver. The information may be private or may be generated on-demand for one receiver. Figure 1 depicts such an exchange. Some IMG metadata may be distributed to a large number of receivers if a particular part is intended to provide the same information to these receivers. This kind of IMG may be distributed from one source to multiple receivers (Fig. 2) or may be relayed across a set of IMG transceivers that receive the IMG, possibly filter or modify its content, and then forward it. Nomura/Schulzrinne [Page 3] Internet Draft IMG Framework February 24, 2003 The relayed network architecture is similar to content distribution network architecture [3] (CDNs). Existing CDNs may carry IMGs. Satellite and peer-to-peer networks may also carry MGs. An IMG receiver can receive IMGs from any number of sources. +-------------+ +---------------+ | IMG source | | IMG receiver | | |--------------->| | +-------------+ +---------------+ Figure 1: An example of peer-to-peer IMG network +---------------+ +-------------+ +---------------+ | | | -------------> +---------------+ | | | IMG source | -------------> | IMG receivers | |--+ | | -------------> | |--+ +-------------+ +---------------+ Figure 2: An IMG distribution network +-------------+ +-------------+ | +-------------+ +--------------+ +-------------+ | | -->| IMG | | | | IMG sources | |--+ -->| transceiver |-->| IMG receiver | | |--+ -->| | | | +-------------+ +-------------+ +--------------+ Figure 3: A relay network with an IMG transceiver 4 IMG Protocol Model Nomura/Schulzrinne [Page 4] Internet Draft IMG Framework February 24, 2003 4.1 Unicast Model A client needs to be able to access the IMG when convenient. A user may delay retrieving the IMG until sufficient network bandwidth or storage capacity is available. In the unicast model, the client retrieves the IMG when needed. Here, any existing request-response protocols is likely to be sufficient if the IMG has a well-known name, expressible as a URI or URN. If the IMG contains a large amount of data, a user may want to request a subset of the original IMG, selecting only specific items of interest. 4.2 Multicast Model Instead of requesting the IMG periodically, a user may want to simply receive updated versions when they become available [4]. Here, multicast distribution [5] is an efficient mechanism as long as the IMG data volume is small. Such systems can either multicast complete the IMG periodically, or multicast only updates, leaving it to the receiver to retrieve the initial IMG via unicast. The multicast model is particularly appropriate for networks with natural multicast functionality, such as CATV and satellite systems. However, multicast may cause long acquisition delays. For devices that are power-constrained or connected via on-demand networks (dial-up), IMG transmissions may need to be scheduled at well-known time instants. 4.3 Synchronized vs. Unsynchronized IMGs tend to change as time elapses, as new content is added, old content becomes unavailable and the parameters of existing content are changed. The IMG source can either simply make updates available (unsynchronized) or IMG source 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. 5 IMG Data Model Nomura/Schulzrinne [Page 5] Internet Draft IMG Framework February 24, 2003 IMGs can describe multimedia content such as a pictures, music and movies. Some of the data elements, such as content owner, time of creation and author, are likely to be common across all content, while others may depend on the content type and even the genre. There are likely to be several data models with differing amount of detail and different target audiences. For example, an IMG for composing a custom news magazine by network affiliates may be far more detailed than the IMG meant for the typical TV viewer. The IMG is used to find, obtain, manage and play content. The IMG may be modified as they are distributed. For example, a media server may use an IMG to retrieve media content via unicast and then make it available at scheduled times via multicast, thus requiring a change of the corresponding meta-data. IMG transceivers may add or delete information or aggregate IMGs from different sources. For example, a rating service may add its own content ratings or recommendations to existing meta-data. The same IMG may be provided by several different servers. 6 Security Considerations 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. In some cases, the receiver needs to be assured of the origin of an IMG or its modification history. Access to IMG information may require authorization. 7 Bibliography [1] B. Quinn and K. Almeroth, "IP multicast applications: Challenges and solutions," RFC 3170, Internet Engineering Task Force, Sept. 2001. [2] S. Bradner, "Key words for use in rfcs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [3] M. Green et al., "Content internetworking architectural overview," internet draft, Internet Engineering Task Force, July 2002. Work in progress. [4] J. Luoma, "MUPPET: Internet media guide unidirectional," internet draft, Internet Engineering Task Force, Dec. 2002. Work in progress. Nomura/Schulzrinne [Page 6] Internet Draft IMG Framework February 24, 2003 [5] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 8 Acknowledgements The authors would like to thank Juka-Pekka Luoma (Nokia), Rod Walsh (Nokia) and Toni Paila (Nokia) for thier comments on the draft. 9 Author's Addresses Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan Email: nom@flab.fujitsu.co.jp Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Nomura/Schulzrinne [Page 7]