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]