Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura
Fujitsu Labs.
R. Walsh
Nokia
H. Schulzrinne
Columbia University
draft-nomura-mmusic-img-requirements-01.txt
June 30, 2003
Expires: December 2003
Protocol Requirements 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 specifies requirements for a protocol for accessing and
updating Internet Media Guide (IMG) information for media-on-demand
and multicast applications. These requirements are designed to guide
development of an IMG protocol for efficient and scalable delivery.
Table of Contents
1 Introduction ........................................ 2
2 Terminology ......................................... 3
Y. Nomura et. al. [Page 1]
Internet Draft IMG Requirements June 30, 2003
3 Overview ............................................ 3
4 Requirements ........................................ 3
4.1 Separating IMG operations from IMGs ................. 4
4.2 Multiple IMG Senders ................................ 4
4.3 Modularity .......................................... 4
4.4 Performance ......................................... 4
4.4.1 Scalability ......................................... 4
4.4.2 Low Resource Consumption ............................ 5
4.4.3 Preventing Congestion ............................... 5
4.4.4 Preventing stale state .............................. 5
4.4.5 Change Notification ................................. 5
4.5 Flexibility ......................................... 6
4.5.1 Customized IMGs ..................................... 6
4.5.2 Many kinds of multimedia content .................... 6
4.5.3 Sender- and Receiver-Driven ......................... 6
4.6 Reliability ......................................... 6
4.6.1 Managing consistency ................................ 6
4.6.2 Reliable Message Exchange ........................... 7
4.7 IMG Description ..................................... 7
5 Security Considerations ............................. 7
5.1 IMG Authentication .................................. 7
5.2 Access Control for IMG .............................. 8
5.3 Denial-of-Service attacks ........................... 8
5.4 Replay Attacks ...................................... 8
6 Acknowledgements .................................... 8
7 Bibliography ........................................ 8
8 Author's Addresses .................................. 9
1 Introduction
This document defines requirements that an Internet Media Guide (IMG)
[1] protocol must satisfy in order to deliver IMG to a potentially
large audience. Since the IMG can describe many kinds of multimedia
content, the protocol are generally applicable to several scenarios.
In considering wide applicability, this document provides general
requiements which are independent of any transport layer mechanism,
existing protocol and application. IMG framework document presents
general IMG operations and descriptors, therefore this document
describes its performance, flexibility and reliability.
Additionally, there might be several implementations to meet the
requirements within the IMG framework.
This document reflects investigating work on delivery mechanisms for
IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group
Y. Nomura et. al. [Page 2]
Internet Draft IMG Requirements June 30, 2003
(SAP[2], SIP[3], SDP[4]).
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 [5].
Internet Media Guide (IMG): An IMG is a set of meta-data
describing the features of 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 Delivery: The process of exchanging IMG metadata both in
terms of large scale and atomic data transfers.
IMG Sender: An IMG sender 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 Operations: An atomic process for the IMG protocol to
deliver IMG or control the IMG sender or IMG receiver.
3 Overview
First of all, the section summarizes the features of the IMG and IMG
protocol.
o IMG data may be updated as time elapses because content
described in the guide may be changed. For example, the
airtime of an event such as a concert or sports event may
change, possibly affecting the air time of subsequent medias.
o We assume that any Internet host can be a source of content
and thus IMG. 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 IMGs 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).
4 Requirements
Y. Nomura et. al. [Page 3]
Internet Draft IMG Requirements June 30, 2003
Throughout the rest of this section, "the protocol" refers to the IMG
protocol.
4.1 Separating IMG operations from IMGs
The protocol MUST allow to carry different kinds of IMG metadata
format in the IMG message body. The protocol SHOULD be designed to
take advantage an existing metadata format. While it doesn't rely on
the specific format, this provides flexibility for the protocol,
which is applied to various scenarios.
4.2 Multiple IMG Senders
The protocol MUST allow a IMG receiver to communicate with any number
of IMG sender simultaneously. This might lead to receiving duplicated
IMGs and consuming unneeded resources, however this creates potential
opportunities covering more IMGs than a single IMG sender. This also
provides flexibility for the protocol. The protocol doesn't preclude
a mechanism to solve inconsistency among IMGs due to multiple IMG
senders.
4.3 Modularity
The protocol MUST allow to combine several IMG operations for the
purpose of extending functionality. The protocol MUST be designed to
make the protocol implementation simple, however it might be applied
various scenarios.
4.4 Performance
Although the performance requirements may depend on the scenarios,
the section describes general performance requirements based on the
assumption that the protocol is always required to achieve the wide
applicability for several scenarios.
Example: It is clear that a multicast transport provides more
scalable delivery than an unicast transport, however the section
doesn't preclude the specific transport mechanism.
In this sense, scalability is always important for the protocols
irrespective of transport mechanisms.
4.4.1 Scalability
The protocol MUST be scalable in the number of transactions and the
amount of IMGs to deliver up-to-date IMGs from the IMG sender to
receiver.
Y. Nomura et. al. [Page 4]
Internet Draft IMG Requirements June 30, 2003
The protocol SHOULD provide the mechanism that the IMG sender doesn't
send verbose IMGs which have been stored or deleted in the IMG
receiver.
The protocol MUST be scalable in the number of audience, who require
IMG delivery.
4.4.2 Low Resource Consumption
The protocol MUST allow an efficient intermittent access to save
power. There is no need to keep communications links powered up
while they are sitting idle. Thus, either periodic bursts of
notifies, or a fast cycling update carousel allows hosts to wake up
for short periods of time and still be kept up to date. This may be
beneficial in the fixed-Internet, but is critical in the battery
powered wireless Internet.
4.4.3 Preventing Congestion
Internet friendly congestion (it is possible that the minimal
required metadata transfer is less than the total metadata (versions)
during the life of a certain "media") - so notifies can reduce
congestion, especially for very large groups, while allowing
individual "congestion free" parts of the Internet to do things
"their way". Where some hosts are on unidirectional links, and other
have bi-directional links (or both), this is sensible " diversity".
4.4.4 Preventing stale state
The IMG entities MUST support to prevent stale state in an IMG. When
an IMG item has lifetime information, the IMG entity SHOULD
invalidate the IMG item when its lifetime is over. This mechanism can
eliminate a invalidation message from the IMG sender to receiver.
4.4.5 Change Notification
Since IMGs can change at any time, receivers of IMGs SHOULD be
notified of such changes, without necessarily re-sending the whole
IMG. Depending on the size of the guide, the interested party may
want to defer retrieving the actual information. The change
notification should be addressed to a logical user, not a host, since
users may change devices.
As an example, consider a storage device requires the up-to-date
video file from an IP-reachable video camera but the camera is
connected only sporadically. When the camera is connected on the
network and has a new video object, the storage device must be
notified of its availability immediately.
Y. Nomura et. al. [Page 5]
Internet Draft IMG Requirements June 30, 2003
4.5 Flexibility
4.5.1 Customized IMGs
The protocol SHOULD allow to deliver customized IMGs. The IMG
receiver may require a subset of the IMG according to their
preference (type of content, media format, appropriate age group,
etc.) and configuration.
The IMG receiver may send its preferences in the IMG operations which
can specify interested IMGs to be delivered. The preferences might
consist of filtering rules. When receiving these messages, the IMG
sender may respond appropriate messages carrying a subset of IMGs
which matches the receiver's preferences.
This mechanism can reduce the amount of IMGs delivered from the
sender to receiver, and consequently it can save the resource
consumption on the IMG Entities and IMG networks.
4.5.2 Many kinds of multimedia content
The protocol MUST deliver a variety of media formats, which describe
multimedia items available either for download, streaming or
multicast distribution. It is essential for the protocol to support
many kinds of multimedia content and to achieve wide applicability.
4.5.3 Sender- and Receiver-Driven
The protocol MUST be flexible in choosing sender-driven, receiver-
driven or both delivery. Server-driven delivery achieves highly
scalability without interaction between the IMG sender and receiver.
This avoids keeping track of a delivery state at every receivers.
In contrast, the receiver-driven delivery provides on-demand delivery
for IMG receivers. Since an IMG may contain a large amount of data,
the IMG receiver needs to be able to access the guide when convenient
(e.g., when sufficient network bandwidth is available to the user).
Combining sender-driven and receiver-driven might be a flexible
approach to solve the problems in both delivery mechanisms.
4.6 Reliability
4.6.1 Managing consistency
IMGs tend to change as time elapses, as new content is added, the old
IMG stored in the IMG receiver becomes unavailable and the parameters
of the existing IMG are changed.
Y. Nomura et. al. [Page 6]
Internet Draft IMG Requirements June 30, 2003
The IMG sender can either simply make updates available
(unsynchronized) or IMG sender 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.
In the synchronized model, updating cached copy of the IMG is
necessary to control consistency when the IMG sender or receiver
couldn't communicate for a while. In this case, the IMG sender or
receiver may need to confirm its consistency by IMG operations.
Thus, the protocol MUST allow to manage IMG consistency between the
IMG sender and receiver.
4.6.2 Reliable Message Exchange
If a bi-directional transport connects the IMG receiver with sender,
this protocol SHOULD support a reliable message exchange.
In the unidirectional transport case, it is RECOMMENDED to implement
this.
4.7 IMG Description
To avoid interoperability problems, an IMG description should be
standardized.
The IMG format MUST support pointer type description to refer other
another IMG.
An IMG may refer multiple content, and content may consist of sub-
content. Each sub-content is described by a set of parameters. Thus,
an IMG is structured data. An IMG may refer (via URI) to other IMGs.
Such references improve flexibility and scalability and simplifies
decentralized management of IMGs.
The IMG format MUST support delta type description to avoid redundant
delivery of IMGs.
5 Security Considerations
5.1 IMG Authentication
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. To prevent
it, the protocol SHOULD provide for message authentication and
Y. Nomura et. al. [Page 7]
Internet Draft IMG Requirements June 30, 2003
confidentiality.
5.2 Access Control for IMG
The protocol SHOULD provide receiver authorization mechanism to
selectively reject accessing the IMG. Some or all of any IMG
sender's metadata may be private or valuable, the mechanism can avoid
undesired accesses from anonymous receivers.
5.3 Denial-of-Service attacks
The protocol needs to keep the request state to establish IMG
delivery sessions, and this request can be used by attackers to
consume resources on the IMG sender.
To reduce the impact of the attack, the protocol MUST provide
authentication mechanism.
5.4 Replay Attacks
The protocol MUST provide mechanisms to mitigate replay attacks on
the IMG operations.
6 Acknowledgements
The authors would like to thank Hitoshi Asaeda (INRIA), Juka-Pekka
Luoma (Nokia) , Petri Koskelainen (Nokia) and Toni Paila (Nokia) for
thier comments on the draft.
7 Bibliography
[1] Y. Nomura and H. Schulzrinne, "A framework for Internet media
guides," internet draft, Internet Engineering Task Force, Feb. 2003.
Work in progress.
[2] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
[3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[5] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Y. Nomura et. al. [Page 8]
Internet Draft IMG Requirements June 30, 2003
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
Rod Walsh
Nokia Corporation
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
Email: rod,walsh@nokia.com
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 (2003). 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 INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Y. Nomura et. al. [Page 9]
Internet Draft IMG Requirements June 30, 2003
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.
Y. Nomura et. al. [Page 10]