Internet Engineering Task Force

INTERNET-DRAFT  Nomura/Schulzrinne
draft-nomura-mmusic-pguide-framework-00.ps  Fujitsu/Columbia U.

October 24, 2002 Expires: April 2003

A Framework for Internet Program Guide

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.

Copyright Notice

Copyright (c) The Internet Society (2002). All Rights Reserved.

Abstract This memo specifies a framework for Internet Program Guide. A program guide is a set of meta-data describing the features of multimedia content to subscribe, manage and exchange content. To discuss the protocol and program guide format, we present a network architectures, protocol model and program guide data model using some scenarios.

1 Introduction

This document presents a framework for Internet Program Guide [1] to support the standardization of protocols and formats, which is facilitate the multimedia content management and exchange.

Program guides allow users to initiate streaming media sessions, schedule delivery of downloadable or multicast content or listen to live multicast sessions. Program guide is a set of meta-data describing the features of multimedia content that is used on many network platforms and network devices.

The program guides are applicable to various applications and network environments. Thus, it is necessary to overview network architectures, protocol models, and data models from various aspects such as scenarios, goals and implementations to classify technical issues and engineering tradeoffs. This document does not make choices, and does not select any particular approach to support Internet Program Guide.

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].

User Agent Server (UAS) : A User Agent Server is a logical entity that sends program guides to A User Agent Client.

User Agent Client (UAC) : A User Agent Client is a logical entity that receives program guide from a UAS.

INTERNET-DRAFT  draft-nomura-mmusic-pguide-framework-00.ps  October 24, 2002

User Agent (UA): A User Agent is a logical entity including both a UAS and UAC.

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 thus meta data. 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 program guides 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).

3.2 Network Architectures

This section distinguishes different types of program guide networks in order to classify the architecture.

A program guide may be closed information between a particular UAS and USC, since the PG describes private information, which is not intended to disclose to other parties. Figure 1 depicts an example of the network consists of just the UAS and UAC.

On the other hand, some PG is distributed to a lot of UACs [?], because the PG doesn’t have any restrictions. This kind of PG may be distributed from a UAS to UACs, or relayed by the UAS to USC sessions.

Figure 2 and 3 shows an example of the PG distribution network. In Figure 3, there are two hosts behave as a UAs.

The relayed network architecture similar to content distribution network architecture [3]. In some case, the PGs are carried over the content network (e.g. content distribution network, satellite network, or Peerto-Peer network).

A UAC can receive not a only single PG from a single UAS but also multiple PGs from multiple UASs.

          +-------------+                  +---------------+
          | PG Server   |                  | PG Client      |
          |          UAS |--------------->| UAC             |
          +-------------+                  +---------------+
       Figure 1. An example of peer-to-peer PG network

                                                     +---------------+
                                                 +---------------+  |
          +-------------+                  +---------------+  |  |
          | PG Server   |                  | PG Clients     |  |--+

          |          UAS |--------------->| UACs           |--+
          +-------------+                  +---------------+
       Figure 2. An example of distribution network

       +------------+   +-----------+   +-----------+   +------------+
       |  PG Server |   | PG Host A |   | PG Host B |   |  PG Client |
       |              |-->|             |-->|             |-->|              |
       |              |   |             |   |             |   |              |
       +------------+   +-----------+   +-----------+   +------------+
               PG UAS --> PG UAC
                                 PG UAS --> PG UAC
                                                   PG UAS --> PG UAC
       Figure 3. An example of relayed network

4 Program Guide Protocol Model

4.1 Unicast Model

A client needs to be able to access the PG when convenient. For example, when sufficient network bandwidth or storage capacity is available to the user, the user can retrieve the PG.

When the user doesn’t want to keep track of the up-to-date PG but wants to take it just several times when necessary, the unicast model is appropriate.

If a cost-effective implementation is required or the resource for the implementation is limited in a UAC, the UAC can use existing request-response type protocols for a PG retrieval.

If the PG contains a large amount of data, a user may request the subset of the original PG by a customized request mechanism over the unicast model.

4.2 Multicast Model

A user may want to receive PGs without requesting every time. As an example, if the PG source is fixed and the PG changes periodically, a UAC prefers to obtain the PG by multicast session [4] in order to reduce the overhead of a request functionality.

It is clear that the multicast model provides scalable distributing mechanism of PG. Since this model can reduce the number of retrieval requests to the UAS, the UAS can benefit from this model.

The multicast model may be introduced into existing broadcast or multicast networks such as satellite systems. Using existing broadcast infrastructures, the introduction cost can be decreased.

4.3 Un-managed Status vs. Managed Status

In most cases, it is required that PG can be transferred continuously to a UAC, because the PG will be changed by the time elapsed. Regarding the status management between a UAS and UAC, there are two options to deal with the PG status; un-managed and managed.

The un-managed model doesn’t care the status in the other side of the protocol. In the model, the UAS and UAC may manage its own status, but they don’t maintain the status of the other side. For instance, the UAC does not update the existing PG but keeps it until the UAC receives new PG from the UAS because it doesn’t care the UAS status. Also, the UAS doesn’t recognize the UAC status even if the UAC didn’t receive and update the PG.

This model makes managing functions in the UAC and UAS simple. However, the model does not provide the up-to-date PG whenever the UAC requires it.

In the managed model, a UA can watch or confirm the status on the other side, and can also request to update or synchronize the status when necessary. The model provides a reliable and accurate update mechanism, which can be used to synchronize PG information between the UAC and UAS.

5 Program Guide Data Model

A program guide consists of multiple programs [5], and a program may consist of sub–programs named ”segment”. Thus, a program guide has a hierarchical structure.

PG is required to describe multimedia content such as a picture, music and movie. To describe such various content, the PG data model uses comprehensive description tools, which is also extensible for future new content. However, if content does not contain much meta-data, PG may be described by simple tools, which is a subset of the full set of description tools.

PG is used to find, obtain, manage and play content, and may be modified by an user if necessary. For example, since location and available time may vary from the distribution network environment, a UA may modify such dynamic meta-data to fit the network.

A program guide may contain a hyperlink to refer other PGs. The hyperlink provides flexibility and scalability to describe PGs, and it keeps managing the original PGs separated from other PGs.

A PG is provided by a single source or multiple sources. Some sources want to manage distributing content and the PG from a root server. In this case, some UAC can only access PGs from the root or its child servers. Otherwise, the UAC can access the same PGs from different UASs.

PG is independent of particular devices, network platforms and protocols.

References

[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] M. Green et al., “Content internetworking architectural overview,” Internet Draft, Internet Engineering Task Force, July 2002. Work in progress.

[4] M. Handley, C. Perkins, and E. Whelan, “Session announcement protocol,” RFC 2974, Internet Engineering Task Force, Oct. 2000.

[5] TV-Anytime Forum, “Metadata specification S-3,” TV-Anytime Forum Specification SP003v1.2 Part A, TV096R5, TV-Anytime Forum, June 2002.

6 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

Full Copyright Statement

Copyright (c) The Internet Society (2002). 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 IN-TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-RANTIES, EXPRESS OR IMPLIED, INCLUDING 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.