Internet Engineering Task Force Internet Draft Nomura/Schulzrinne Fujitsu/Columbia U. draft-nomura-mmusic-pguide-framework-00.txt October 27, 2002 Expires: April 2003 A Framework for Internet Program 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 program guides (IPG). An IPG 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 program guide data model for several scenarios. 1 Introduction This document presents a framework for Internet Program Guides (IPGs) [1] to facilitate the standardization of protocols and formats. Program guides allow users to initiate streaming media sessions, schedule delivery of downloadable or multicast content or listen to Nomura/Schulzrinne [Page 1] Internet Draft IPG Framework October 27, 2002 live multicast sessions. A program guide consists of meta-data describing the features of multimedia content. Program guides are designed to be independent of the particular access network and end system. Program 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]. IPG source: An IPG source is a logical entity that sends program guides to one or more IPG receivers. IPG receiver: An IPG receiver is a logical entity that receives program guides from an IPG source. IPG transceiver: An IPG transceiver combines an IPG receiver and source. Program Guide (PG): A program guide 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. 3 Program Guide Network Model 3.1 Devices Using the Program Guide 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 program guides 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.2 Architectures This section distinguishes different types of program guide interactions. Nomura/Schulzrinne [Page 2] Internet Draft IPG Framework October 27, 2002 A program guide 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 PG may be distributed to a large number of receivers [3] if a particular PG is public information and the provides the same information for all receivers. This kind of PG may be distributed from one source to multiple receivers (Fig. 2) or may be relayed across a set of IPG transceivers that receive the PG, possibly filter or modify its content, and then forward it. The relayed network architecture is similar to content distribution network architecture [4] (CDNs). Existing CDNs may carry PGs. Satellite and peer-to-peer networks may also carry PGs. A IPG receiver can receive program guides from any number of sources. +-------------+ +---------------+ | IPG source | | IPG receiver | | |--------------->| | +-------------+ +---------------+ Figure 1: An example of peer-to-peer PG network +---------------+ +---------------+ | +-------------+ +---------------+ | | | IPG source | | IPG receivers | |--+ | |--------------->| |--+ +-------------+ +---------------+ Figure 2: A PG distribution network Nomura/Schulzrinne [Page 3] Internet Draft IPG Framework October 27, 2002 +------------+ +-----------+ +-----------+ +--------------+ | IPG source | | IPG | | IPG | | IPG receiver | | |-->| trans- |-->| trans- |-->| | | | | ceiver | | ceiver | | | +------------+ +-----------+ +-----------+ +--------------+ Figure 3: A relay network with IPG transceivers 4 Program Guide Protocol Model 4.1 Unicast A client needs to be able to access the PG when convenient. A user may delay retrieving the PG until sufficient network bandwidth or storage capacity is available. In the unicast model, the client retrieves the PG when needed. Here, any existing request-response protocols is likely to be sufficient if the PG has a well-known name, expressible as a URI or URN. If the PG contains a large amount of data, a user may want to request a subset of the original PG, selecting only specific items of interest. 4.2 Multicast Model Instead of requesting the PG periodically, a user may want to simply receive updated versions when they become available. Here, multicast distribution [5] is an efficient mechanism as long as the PG data volume is small. Such systems can either multicast the complete PG periodically, or multicast only updates, leaving it to the receiver to retrieve the initial PG 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), PG transmissions may need to be scheduled at well-known time instants. 4.3 Synchronized vs. Unsynchronized Nomura/Schulzrinne [Page 4] Internet Draft IPG Framework October 27, 2002 PGs tend to change as time elapses, as new content is added, old content becomes unavailable and the parameters of existing content are changed. The IPG source can either simply make updates available (unsynchronized) or IPG source and receiver can interact to keep their copies of the PG synchronized. In the unsynchronized model, the source does not know whether a particular receiver has an up-to-date copy of the PG. 5 Program Guide Data Model A program guide consists of multiple programs [6], and a program may consist of sub-programs called "segments". Each segment is described by a set of parameters. Thus, a program guide is structured data. PGs 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, a program guide for composing a custom news magazine by network affiliates may be far more detailed than the program guide meant for the typical TV viewer. PG is used to find, obtain, manage and play content. PG may be modified as they are distributed. For example, a media server may use a PG 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. IPG transceivers may add or delete information or aggregate PGs from different sources. For example, a rating service may add its own content ratings or recommendations to existing meta-data. A program guide may reference (via URI) to refer other PGs. Such references improve flexibility and scalability and simplifies decentralized management of PGs. However, it makes update notifications somewhat more challenging. The same PG may be provided by several different servers. 6 Security Considerations Customized PGs may reveal information about the habits and preferences of a user and may thus deserve confidentiality Nomura/Schulzrinne [Page 5] Internet Draft IPG Framework October 27, 2002 protection, even though the information itself is public. In some cases, the receiver needs to be assured of the origin of a PG or its modification history. Access to PG information may require authorization. 7 Bibliography [1] Y. Nomura and H. Schulzrinne, "Protocol requirements for internet program guides," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [3] J. Luoma, R. Walsh, and T. Paila, "IP-CC Requirements specification," DVB-GBS Working Group, SI-DAT 621R3, May 2002. [4] M. Green et al., "Content internetworking architectural overview," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [5] M. Handley, C. Perkins, and E. Whelan, "Session announcement protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. [6] TV-Anytime Forum, "Metadata specification S-3," TV-Anytime Forum Specification SP003v1.2 Part A, TV096R5, TV-Anytime Forum, June 2002. 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 Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Nomura/Schulzrinne [Page 6]