[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/