draft-ietf-mmusic-img-req-01.txt   draft-ietf-mmusic-img-req-02.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura Internet Draft Y. Nomura
Fujitsu Labs. Fujitsu Labs.
R. Walsh R. Walsh
J-P. Luoma J-P. Luoma
Nokia Nokia
J. Ott J. Ott
Universitaet Bremen Universitaet Bremen
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-req-01.txt draft-ietf-mmusic-img-req-02.txt
December 2, 2003 December 22, 2003
Expires: March 2004 Expires: June 2004
Protocol Requirements for Internet Media Guides Protocol Requirements for Internet Media Guides
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 6 skipping to change at page 2, line 6
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This memo specifies requirements for a protocol for accessing and This memo specifies requirements for a protocol for accessing and
updating Internet Media Guide (IMG) information for media-on-demand updating Internet Media Guide (IMG) information for media-on-demand
and multicast applications. These requirements are designed to guide and multicast applications. These requirements are designed to guide
development of an IMG protocol for efficient and scalable delivery. development of an IMG protocol for efficient and scalable delivery.
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 2
1.1 Background and Motivation ........................... 2 1.1 Background and Motivation ........................... 3
1.2 Scope of this Document .............................. 4 1.2 Scope of This Document .............................. 4
2 Terminology ......................................... 4 2 Terminology ......................................... 4
3 Problem Statement ................................... 5 3 Problem Statement ................................... 5
4 Requirements ........................................ 6 4 Use Cases Requiring IMGs ............................ 6
4.1 General Requirements ................................ 6 4.1 Connectivity-based Use Cases ........................ 6
4.1.1 Independence of IMG Operations from IMG Metadata .... 6 4.1.1 IP Datacast to a Wireless Receiver .................. 7
4.1.2 Multiple IMG Senders ................................ 6 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8
4.1.3 Modularity .......................................... 6 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8
4.2 Delivery Properties ................................. 7 4.2 Content-orientated Use Cases ........................ 8
4.2.1 Scalability ......................................... 7 4.2.1 File Distribution ................................... 9
4.2.2 Support for Intermittent Connectivity ............... 7 4.2.2 TV and Radio Program Delivery ....................... 9
4.2.3 Congestion Control .................................. 8 4.2.3 Media Coverage of a Live Event ...................... 10
4.2.4 Sender and Receiver Driven Delivery ................. 8 4.2.4 Distance Learning ................................... 10
4.3 Customized IMGs ..................................... 8 4.2.5 Multiplayer Gaming .................................. 10
4.4 Reliability ......................................... 9 5 Requirements ........................................ 10
4.4.1 Managing consistency ................................ 9 5.1 General Requirements ................................ 10
4.4.2 Reliable Message Exchange ........................... 10 5.1.1 Independence of IMG Operations from IMG Metadata
4.5 IMG Descriptions .................................... 10 5.1.2 Multiple IMG Senders ................................ 11
5 Security Considerations ............................. 11 5.1.3 Modularity .......................................... 11
5.1 IMG Authentication and Integrity .................... 12 5.2 Delivery Properties ................................. 11
5.2 Privacy ............................................. 13 5.2.1 Scalability ......................................... 11
5.3 Access Control for IMGs ............................. 13 5.2.2 Support for Intermittent Connectivity ............... 12
5.4 Denial-of-Service attacks ........................... 14 5.2.3 Congestion Control .................................. 12
5.5 Replay Attacks ...................................... 14 5.2.4 Sender and Receiver Driven Delivery ................. 12
6 Acknowledgements .................................... 14 5.3 Customized IMGs ..................................... 13
7 Normative References ................................ 14 5.4 Reliability ......................................... 13
8 Informative References .............................. 15 5.4.1 Managing consistency ................................ 14
9 Authors' Addresses .................................. 15 5.4.2 Reliable Message Exchange ........................... 14
5.5 IMG Descriptions .................................... 15
6 Security Considerations ............................. 16
6.1 IMG Authentication and Integrity .................... 16
6.2 Privacy ............................................. 17
6.3 Access Control for IMGs ............................. 17
6.4 Denial-of-Service attacks ........................... 18
6.5 Replay Attacks ...................................... 18
7 Acknowledgements .................................... 19
8 Normative References ................................ 19
9 Informative References .............................. 19
1 Introduction 1 Introduction
1.1 Background and Motivation 1.1 Background and Motivation
For some ten years, multicast-based (multimedia) conferences For some ten years, multicast-based (multimedia) conferences
(including IETF WG sessions) as well as broadcasts of (including IETF WG sessions) as well as broadcasts of
lectures/seminars, concerts, and other events have been used in the lectures/seminars, concerts, and other events have been used in the
Internet, more precisely, on the MBONE. Schedules and descriptions Internet, more precisely, on the MBONE. Schedules and descriptions
for such multimedia sessions as well as the transport addresses, for such multimedia sessions as well as the transport addresses,
codecs, and their parameters have been described using SDP [1] as a codecs, and their parameters have been described using SDP [1] as a
rudimentary (but as of then largely sufficient) means. Dissemination rudimentary (but as of then largely sufficient) means. Dissemination
of the descriptions has been performed using the Session Announcement of the descriptions has been performed using the Session Announcement
Protocol (SAP) [2] and tools such as SD [3] or SDR [4]; descriptions Protocol (SAP) [2] and tools such as SD [3] or SDR [4]; descriptions
have also been put up on web pages, sent by electronic mail, etc. have also been put up on web pages, sent by electronic mail, etc.
skipping to change at page 4, line 15 skipping to change at page 4, line 26
networks. networks.
Finally, with many potential senders and sinks, different types of Finally, with many potential senders and sinks, different types of
networks, and presumably numerous service providers, IMG metadata may networks, and presumably numerous service providers, IMG metadata may
need to be combined, split, filtered, augmented, modified, etc. on need to be combined, split, filtered, augmented, modified, etc. on
their way from the sender(s) to the receiver(s) to provide the their way from the sender(s) to the receiver(s) to provide the
ultimate user with a suitable selection of multimedia programs ultimate user with a suitable selection of multimedia programs
according to her preferences, subscriptions, location, context (e.g. according to her preferences, subscriptions, location, context (e.g.
devices, access networks), etc. devices, access networks), etc.
1.2 Scope of this Document 1.2 Scope of This Document
This document defines requirements that Internet Media Guide (IMG) This document defines requirements that Internet Media Guide (IMG)
mechanisms must satisfy in order to deliver IMG to a potentially mechanisms must satisfy in order to deliver IMG to a potentially
large audience. Since the IMG can describe many kinds of multimedia large audience. Since the IMG can describe many kinds of multimedia
content, IMG methods are generally applicable to several scenarios. content, IMG methods are generally applicable to several scenarios.
In considering wide applicability, this document provides the problem In considering wide applicability, this document provides the problem
statement and existing mechanisms in this area. Then gives general statement and existing mechanisms in this area. Then several use case
requirements that are independent of any transport layer mechanism scenarios for IMGs are explained including descriptions of how IMG
and application, such as delivery properties, reliability and IMG metadata and IMG delivery mechanisms contribute to these scenarios.
descriptions. Following this, this document provides general requirements that are
independent of any transport layer mechanism and application, such as
delivery properties, reliability and IMG descriptions.
This document reflects investigating work on delivery mechanisms for This document reflects investigating work on delivery mechanisms for
IMGs and generalizing work on session announcement and initiation IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group (SAP, protocols, especially in the field of the MMUSIC working group (SAP,
SIP [5], SDP). SIP [5], SDP).
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6]. document are to be interpreted as described in RFC 2119 [6].
Internet Media Guide (IMG): IMG is a generic term to describe Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise. definition of the IMG is intentionally left imprecise.
IMG Metadata: This is a set of metadata describing the features IMG Element: The smallest atomic element of metadata that can be
of multimedia content used to enable selection of and transmitted separately by IMG operations and referenced
access to media sessions containing content. For example, individually from other IMG elements.
metadata may consist of the URI, title, airtime, bandwidth
needed, file size, text summary, genre, and access IMG Metadata: A set of metadata consisting of one or more IMG
restrictions. elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media
sessions containing content. For example, metadata may
consist of the URI, title, airtime, bandwidth needed, file
size, text summary, genre and access restrictions.
IMG Delivery: The process of exchanging IMG metadata both in IMG Delivery: The process of exchanging IMG metadata both in
terms of large scale and atomic data transfers. terms of large scale and atomic data transfers.
IMG Sender: An IMG sender is a logical entity that sends IMGs to IMG Sender: An IMG sender is a logical entity that sends IMG
one or more IMG receivers. metadata to one or more IMG receivers.
IMG Receiver: An IMG receiver is a logical entity that receives IMG Receiver: An IMG receiver is a logical entity that receives
IMGs from an IMG sender. IMG metadata from an IMG sender.
IMG Transceiver: An IMG transceiver combines an IMG receiver and IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify original IMGs or merge several IMGs sender. It may modify received IMG metadata or merge IMG
from a different IMG sender. metadata received from a several different IMG senders.
IMG Operation: An atomic process for the IMG transport protocol IMG Operation: An atomic operation of an IMG transport protocol,
to deliver IMG metadata or control IMG sender(s) or IMG used between IMG sender(s) and IMG receiver(s) for the
receiver(s). delivery of IMG metadata and for the control of IMG
sender(s)/receiver(s).
IMG Transport Protocol: A protocol that transports IMG metadata IMG Transport Protocol: A protocol that transports IMG metadata
from IMG sender to IMG receiver(s) from an IMG sender to IMG receiver(s).
IMG Transport Session: An association between an IMG sender and
one or more IMG receivers within the scope of an IMG
transport protocol. An IMG transport session involves a
series of IMG transport protocol interactions that provide
delivery of IMG metadata from the IMG sender to the IMG
receiver(s).
3 Problem Statement 3 Problem Statement
The MMUSIC working group has long been investigating content, media The MMUSIC working group has long been investigating content, media
and service information delivery mechanisms and protocols, and has and service information delivery mechanisms and protocols, and has
itself produces Session Announcement Protocol (SAP), Session itself produces Session Announcement Protocol (SAP), Session
Description Protocol (SDP), and the Session Initiation Protocol Description Protocol (SDP), and the Session Initiation Protocol
(SIP). SDP is capable of describing multimedia sessions (i.e. (SIP). SDP is capable of describing multimedia sessions (i.e.
content in a wider sense) by means of limited descriptive information content in a wider sense) by means of limited descriptive information
intended for human perception plus transport, scheduling information, intended for human perception plus transport, scheduling information,
skipping to change at page 6, line 20 skipping to change at page 6, line 46
numbers of sender-receiver connections, especially as both of these numbers of sender-receiver connections, especially as both of these
share a resource (the radio bandwidth or the server resources) and share a resource (the radio bandwidth or the server resources) and
thus limit the number of receivers that can be served, without thus limit the number of receivers that can be served, without
additional infrastructure investment. additional infrastructure investment.
We also perceive a lack of standard solution for flexible content We also perceive a lack of standard solution for flexible content
descriptions to support a multitude of application-specific data descriptions to support a multitude of application-specific data
models with differing amount of detail and different target models with differing amount of detail and different target
audiences. audiences.
4 Requirements 4 Use Cases Requiring IMGs
4.1 General Requirements 4.1 Connectivity-based Use Cases
4.1.1 Independence of IMG Operations from IMG Metadata 4.1.1 IP Datacast to a Wireless Receiver
IP Datacast is the delivery of IP-based services over broadcast
radio. Internet content delivery is therefore unidirectional in this
case. However, there can be significant benefits from being able to
provide rich media one-to-many services to such receivers.
There are two main classes of receiver in this use case: fixed
mains-powered; and mobile battery-powered. Both of these are affected
by radio phenomena and so robust, or error-resilient, delivery is
important. Carouselled metadata transfer provides a base level of
robustness for an IP datacast based announcement system, although the
design of carouselled transfer should enable battery-powered
receivers to go through periods of sleep to extend their operational
time between charges. Insertion of Forward Error Correction (FEC)
data into metadata announcements improves error resilience, and
reordering (interleaving) data blocks further increases tolerance to
burst errors.
To enable receivers to more accurately specify the metadata they are
interested in, the unidirectional delivery is distributed between
several logical channels. This is so that a receiver need only access
the channels of interest and thus can reduce the amount of time,
storage and CPU resources needed for processing the IP data. Also,
hierarchical channels enable receivers to subscribe to a root,
possibly well known, multicast channel/group and progressively access
only those additional channels based on metadata in parent channels.
In some cases the receiver may be multi-access, such that it is
capable of bi-directional communications. This enables a multitude of
options, but most importantly it enables NACK based reliability and
the individual retrieval of missed or not-multicasted sets of
metadata.
Thus, essential IMG features in this case include: robust
unidirectional delivery (with optional levels of reliability
including "plug-in FEC") which implies easily identifiable
segmentation of delivery data to enable FEC, carousel, interleaving
and other schemes possible; effective identification of metadata sets
(probably uniquely) to enable more efficient use of multicast and
unicast retrieval over multiple access systems regardless of the
parts of metadata and application specific extensions in use;
prioritization of metadata, which can (for instance) be achieved by
spreading it between channels and allocating/distributing bandwidth
accordingly.
Furthermore, some cases require IMG metadata authentication and some
group security/encryption and supporting security message exchanges
(out of band from the IMG multicast sessions).
4.1.2 Regular Fixed Dial-up Internet Connection
Dial-up connections tend to be reasonably slow (<56kbps in any case)
and thus large data transfers are less feasible, especially during an
active application session (such as a file transfer described by IMG
metadata). They can also be intermittent, especially if a user is
paying for the connected time, or connected through a less reliable
exchange. Thus this favors locally stored IMG metadata over web-based
browsing, especially where parts of the metadata change infrequently.
There may be no service provider preference over unicast and
multicast transport for small and medium numbers of users as the
last-mile dial-up connection limits per-user congestion, and a user
may prefer the more reliable option (unicast unless reliable
multicast is provided).
4.1.3 Broadband Always-on Fixed Internet Connection
Typically bandwidth is less of an issue to a broadband user and
unicast transport, such as using IMG QUERY, may be typical for a PC
user. If a system were only used in this context, with content
providers, ISPs and users having no other requirements, then web-
based browsing may be equally suitable. However, broadband users
sharing a local area network, especially wireless, may benefit more
from local storage features than on-line browsing, especially if they
have intermittent Internet access.
Broadband enables rich media services, which are increasingly
bandwidth hungry. Thus backbone operators may prefer multicast
communications to reduce overall congestion, if they have the
equipment and configuration to support this. Thus, broadband users
may be forced to retrieve IMG metadata over multicast if the
respective operators require this to keep system-wide bandwidth usage
feasible.
4.2 Content-orientated Use Cases
IMGs will be able to support a very wide range of use cases for
content/media delivery. The following few sections just touch the
surface of what is possible and are intended to provide an
understanding of the scope and type of IMG usage. Many more examples
may be relevant, for instance those detailed in [7]. There are
several unique features of IMGs that set them apart from related
application areas such as SLP based service location discovery, LDAP
based indexing services and search engines such as Google. Features
unique to IMGs include:
o IMG metadata is generally time-related
o There are timeliness requirements in the delivery of IMG
metadata
o IMG metadata may be updated as time elapses or when an event
arises
4.2.1 File Distribution
IMGs support the communication of file delivery session properties,
enabling the scheduled delivery or synchronization of files between a
number of hosts. The received IMG metadata could be subsequently used
by any application (also outside the scope of IMGs), for example to
download a file with a software update. IMG metadata can provide a
description to each file in a file delivery session, assisting users
or receiving software in selecting individual files for reception.
For example, when a content provider wants to distribute a large
amount of data in file format to thousands clients, the content
provider can use IMG metadata to schedule the delivery effectively.
Since IMG metadata can describe time-related data for each receiver,
the content provider can schedule delivery time for each receiver.
This can save network bandwidth and delivery capacity of senders. In
addition, IMG metadata can be used to synchronize a set of files
between a sender host and receiver host, when those files change as
time elapses.
4.2.2 TV and Radio Program Delivery
A sender of audio/video streaming content can use the IMG metadata to
describe the scheduling and other properties of audio/video sessions
and events within those sessions, such as individual TV and radio
programs and segments within those programs. IMG metadata describing
audio/video streaming content could be represented in a format
similar to that of a TV guide in newspapers, or an Electronic Program
Guide available on digital TV receivers.
Similarly to file reception, TV and radio programs can be selected
for reception either manually by the end-user or automatically based
on the content descriptions and the preferences of the user. The
received TV and radio content can be either presented in real time or
recorded for consuming later. There may be changes in the scheduling
of a TV or a radio program, possibly affecting the transmission times
of subsequent programs. IMG metadata can be used to notify receivers
of such changes, enabling users to be prompted or recording times to
be adjusted.
4.2.3 Media Coverage of a Live Event
The media coverage of a live event such as a rock concert or a sports
event is a special case of regular TV/radio programming. There may be
unexpected changes in the scheduling of live event, or the event may
be unscheduled to start with (such as breaking news). In addition to
audio/video streams, textual information relevant to the event (e.g.
statistics of the players during a football match) may be sent to
user terminals. Different transport modes or even different access
technologies can be used for the different media: for example, a
unidirectional datacast transport could be used for the audio/video
streams and an interactive cellular connection for the textual data.
IMG metadata should enable terminals to discover the availability of
different media used to cover a live event.
4.2.4 Distance Learning
IMG metadata could describe compound sessions or services enabling
several alternative interaction modes between the participants. For
example, the combination of one-to-many media streaming, unicast
messaging and download of presentation material could be useful for
distance learning.
4.2.5 Multiplayer Gaming
Multiplayer games are an example of real-time multiparty
communication sessions that could be advertised using IMGs. A gaming
session could be advertised either by a dedicated server, or by the
terminals of individual users. A user could use IMGs to learn of
active multiplayer gaming sessions, or advertise the users interest
in establishing such a session.
5 Requirements
5.1 General Requirements
5.1.1 Independence of IMG Operations from IMG Metadata
REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG
message body MUST be allowed. message body MUST be allowed.
REQ GEN-2: Delivery mechanisms SHOULD support many different REQ GEN-2: Delivery mechanisms SHOULD support many different
applications specific metadata formats to keep the system applications specific metadata formats to keep the system
interoperable with existing applications. interoperable with existing applications.
This provides flexibility in selecting/designing delivery protocol This provides flexibility in selecting/designing IMG transport
suited to various scenarios. protocol suited to various scenarios.
4.1.2 Multiple IMG Senders
5.1.2 Multiple IMG Senders
REQ GEN-3: IMG receivers MUST be allowed to communicate with any REQ GEN-3: IMG receivers MUST be allowed to communicate with any
number of IMG senders simultaneously. number of IMG senders simultaneously.
This might lead to receiving redundant IMG metadata describing the This might lead to receiving redundant IMG metadata describing the
same items, however it enables receiver access to more IMG metadata same items, however it enables the IMG receiver access to more IMG
than may be available from a single IMG sender. This also provides metadata than may be available from a single IMG sender. This also
flexibility for the delivery protocols and does not preclude a provides flexibility for the IMG transport protocols and does not
mechanism to solve inconsistency among IMG metadata due to multiple preclude a mechanism to solve inconsistency among IMG metadata due to
IMG senders. This document assumes a typical IMG environment will multiple IMG senders. This document assumes a typical IMG environment
involve many more receivers than senders and that senders are will involve many more IMG receivers than IMG senders and that IMG
continually connected for the duration of interest (rather than senders are continually connected for the duration of interest
intermittently connected). (rather than intermittently connected).
5.1.3 Modularity
4.1.3 Modularity
REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of
several IMG Operations. several IMG Operations.
This is for the purpose of extending functionality (e.g. several or This is for the purpose of extending functionality (e.g. several or
one protocol(s) to provide all the needed operations). Applications one protocol(s) to provide all the needed operations). Applications
can select an appropriate operation set to fulfill their purpose. can select an appropriate operation set to fulfill their purpose.
4.2 Delivery Properties 5.2 Delivery Properties
This section describes general performance requirements based on the This section describes general performance requirements based on the
assumption that the range of IMG usage shall be important. However, assumption that the range of IMG usage shall be important. However,
it may be noted that requirements of delivery properties may vary it may be noted that requirements of delivery properties may vary
based on the usage scenario, and thus some limited use based on the usage scenario, and thus some limited use
implementations place less importance on some requirements. implementations place less importance on some requirements.
For example, it is clear that a multicast transport may provide more For example, it is clear that a multicast transport may provide more
scalable delivery than a unicast transport, however scalability scalable delivery than a unicast transport, however scalability
requirements do not preclude the unicast transport mechanisms. In requirements do not preclude the unicast transport mechanisms. In
this sense, scalability is always important for the protocols this sense, scalability is always important for the protocols
irrespective of transport mechanisms. irrespective of transport mechanisms.
4.2.1 Scalability 5.2.1 Scalability
REQ DEL-1: The system MUST be scalable in that it does not fail to REQ DEL-1: The system MUST be scalable in that it does not fail to
deliver up-to-date information under huge numbers of transactions and deliver up-to-date information under huge numbers of transactions and
massive quantities of IMG metadata. massive quantities of IMG metadata.
REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from
sending verbose IMG metadata that have been stored or deleted in IMG sending verbose IMG metadata that have been stored or deleted in IMG
receivers. Note, 'verbose' data is unneeded or unused detail or receivers. Note, 'verbose' data is unneeded or unused detail or
repetitions. repetitions.
REQ DEL-3: The protocol MUST be scalable to very large audience sizes REQ DEL-3: The protocol MUST be scalable to very large audience sizes
requiring IMG delivery. requiring IMG delivery.
4.2.2 Support for Intermittent Connectivity 5.2.2 Support for Intermittent Connectivity
REQ DEL-4: The system MUST enable IMG receivers with intermittent REQ DEL-4: The system MUST enable IMG receivers with intermittent
access to network resources (connectivity) to receive and adequately access to network resources (connectivity) to receive and adequately
maintain sufficient IMG metadata. maintain sufficient IMG metadata.
This allows intermittent access to save power where there is no need This allows intermittent access to save power where there is no need
to keep communications links powered-up while they are sitting idle. to keep communications links powered-up while they are sitting idle.
For instance, in this situation periodic bursts of notifies, or a For instance, in this situation periodic bursts of notifies, or a
fast cycling update carousel, allows hosts to wake up for short fast cycling update carousel, allows hosts to wake up for short
periods of time and still be kept up-to-date. This can be beneficial periods of time and still be kept up-to-date. This can be beneficial
for receivers with sporadic connects to the fixed Internet, but is for IMG receivers with sporadic connects to the fixed Internet, but
critical in the battery-powered wireless Internet. is critical in the battery-powered wireless Internet.
4.2.3 Congestion Control 5.2.3 Congestion Control
REQ DEL-5: Internet-friendly congestion control MUST be provided for REQ DEL-5: Internet-friendly congestion control MUST be provided for
use on the public Internet. use on the public Internet.
For instance, notifications of updates (containing only minimal For instance, notifications of updates (containing only minimal
change related data) can reduce congestion, especially for very large change related data) can reduce congestion, especially for very large
groups, while allowing individual "congestion free" parts of the groups, while allowing individual "congestion free" parts of the
Internet to do things "their way". Where some hosts are on Internet to do things "their way". Where some hosts are on
unidirectional links, and other have bi-directional links (or both), unidirectional links, and other have bi-directional links (or both),
this is sensible "diversity". this is sensible "diversity".
REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when
an IMG metadata item has lifetime information and its lifetime is an IMG metadata item has lifetime information and its lifetime is
over. over.
This mechanism can reduce notifications of updates from the IMG This mechanism can reduce notifications of updates from the IMG
sender to receiver to invalidate the item. It may be beneficial for sender to the IMG receiver to invalidate the item. It may be
congestion control. beneficial for congestion control.
4.2.4 Sender and Receiver Driven Delivery 5.2.4 Sender and Receiver Driven Delivery
REQ DEL-7: The system MUST be flexible in choosing sender-driven, REQ DEL-7: The system MUST be flexible in choosing sender-driven,
receiver-driven or both delivery schemes. receiver-driven or both delivery schemes.
Sender-driven delivery achieves high scalability without interaction Sender-driven delivery achieves high scalability without interaction
between the IMG sender and receiver. This avoids keeping track of a between the IMG sender and receiver. This avoids keeping track of a
delivery state of every receiver. delivery state of every IMG receiver.
In contrast, the receiver-driven delivery provides on-demand delivery In contrast, the receiver-driven delivery provides on-demand delivery
for IMG receivers. Since a sender's complete IMG metadata may be a for IMG receivers. Since an IMG sender's complete IMG metadata may be
very large amount of data, the IMG receiver needs to be able to a very large amount of data, the IMG receiver needs to be able to
access the guide when convenient (e.g., when sufficient network access the guide when convenient (e.g., when sufficient network
bandwidth is available to the receiver). bandwidth is available to the IMG receiver).
4.3 Customized IMGs 5.3 Customized IMGs
REQ CUS-1: The system MUST allow delivery of customized IMG metadata. REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
The IMG receiver may require a subset of all the IMG metadata The IMG receiver may require a subset of all the IMG metadata
available according to their preferences (type of content, media available according to their preferences (type of content, media
description, appropriate age group, etc.) and configuration. description, appropriate age group, etc.) and configuration.
The IMG receiver might send its preferences in the IMG operations The IMG receiver might send its preferences in the IMG operations
which can specify user specific IMG metadata to be delivered. These which can specify user specific IMG metadata to be delivered. These
preferences could consist of filtering rules. When receiving these preferences could consist of filtering rules. When receiving these
messages, the IMG sender might respond appropriate messages carrying messages, the IMG sender might respond appropriate messages carrying
a subset of IMG metadata which matches the receiver's preferences. a subset of IMG metadata which matches the IMG receiver's
preferences.
This mechanism can reduce the amount of IMG metadata delivered from This mechanism can reduce the amount of IMG metadata delivered from
the sender to receiver, and consequently it can save the resource the IMG sender to IMG receiver, and consequently it can save the
consumption on the IMG entities and networks. It is typically useful resource consumption on the IMG entities and networks. It is
in unicast case and also beneficial in multicast case where IMG typically useful in unicast case and also beneficial in multicast
sender distributes the same IMG metadata to interested IMG receivers case where IMG sender distributes the same IMG metadata to interested
at the same time. IMG receivers at the same time.
For multicast and unicast cases where the IMG sender does not provide For multicast and unicast cases where the IMG sender does not provide
customized IMG metadata, the IMG receiver could receive all IMG customized IMG metadata, the IMG receiver could receive all IMG
metadata transmitted (on its joined channels). However, it may select metadata transmitted (on its joined channels). However, it may select
and filter the IMG metadata to get customized IMG metadata by its and filter the IMG metadata to get customized IMG metadata by its
preferences, and thus drop unwanted metadata immediately upon preferences, and thus drop unwanted metadata immediately upon
reception. reception.
Customized metadata might be achieved by changing the IMG descriptors Customized metadata might be achieved by changing the IMG
sent and receivers and/or changing the delivery properties (channels descriptions sent and IMG receivers and/or changing the delivery
used). properties (channels used).
Note, customization and scalability are only somewhat exclusive. Note, customization and scalability are only somewhat exclusive.
Systems providing receiver to sender request-based customization, Systems providing an IMG receiver to an IMG sender request-based
will be generally less scalable to massive receiver populations than customization, will be generally less scalable to massive IMG
those without this return signaling technique. Thus, customization, receiver populations than those without this return signaling
as with any feature which effects scalability, should be carefully technique. Thus, customization, as with any feature which affects
designed for the intended application, and it may not be possible scalability, should be carefully designed for the intended
that a one-size-fits-all solution for customization would meet the application, and it may not be possible that a one-size-fits-all
scalability requirements for all applications and deployment cases. solution for customization would meet the scalability requirements
for all applications and deployment cases.
4.4 Reliability 5.4 Reliability
4.4.1 Managing consistency 5.4.1 Managing consistency
IMG metadata tends to change as time elapses, as new content is IMG metadata tends to change as time elapses, as new content is
added, the old IMG metadata stored in the IMG receiver becomes added, the old IMG metadata stored in the IMG receiver becomes
unavailable and the parameters of the existing IMG metadata are unavailable and the parameters of the existing IMG metadata are
changed. changed.
REQ REL-1: The system MUST manage IMG metadata consistency. REQ REL-1: The system MUST manage IMG metadata consistency.
The IMG sender can either simply make updates available The IMG sender can either simply make updates available
(unsynchronized) or IMG sender and receiver can interact to keep (unsynchronized) or IMG sender and receiver can interact to keep
their copies of the IMG metadata synchronized. their copies of the IMG metadata synchronized.
In the unsynchronized model, the sender does not know whether a In the unsynchronized model, the IMG sender does not know whether a
particular receiver has an up-to-date copy of the IMG metadata. particular IMG receiver has an up-to-date copy of the IMG metadata.
In the synchronized model, updating cached copy of the IMG metadata In the synchronized model, updating cached copy of the IMG metadata
is necessary to control consistency when the IMG sender or receiver is necessary to control consistency when the IMG sender or receiver
could not communicate for a while. In this case, the IMG sender or could not communicate for a while. In this case, the IMG sender or
receiver may need to confirm its consistency by IMG operations. receiver may need to confirm its consistency by IMG operations.
REQ REL-2: Since IMG metadata can change at any time, IMG receivers REQ REL-2: Since IMG metadata can change at any time, IMG receivers
SHOULD be notified of such changes. SHOULD be notified of such changes.
Depending on the size of the guide, the interested party may want to Depending on the size of the guide, the interested party may want to
skipping to change at page 10, line 30 skipping to change at page 14, line 50
In general, the consistency of metadata for a content and media is In general, the consistency of metadata for a content and media is
more important immediately prior to and during the media's more important immediately prior to and during the media's
session(s). Hosts which forward (or otherwise resend) metadata may be session(s). Hosts which forward (or otherwise resend) metadata may be
less tolerant to inconsistencies as delivering out of date data is less tolerant to inconsistencies as delivering out of date data is
both misleading and bandwidth inefficient. both misleading and bandwidth inefficient.
By contrast, intermittent connectivity make immediate distribution of By contrast, intermittent connectivity make immediate distribution of
changes infeasible and so managing data consistency should be focused changes infeasible and so managing data consistency should be focused
on the timely delivery of data. on the timely delivery of data.
4.4.2 Reliable Message Exchange 5.4.2 Reliable Message Exchange
REQ REL-3: An IMG transport protocol MUST support reliable message REQ REL-3: An IMG transport protocol MUST support reliable message
exchange. exchange.
The extent to which this could result in 100% error free delivery to The extent to which this could result in 100% error free delivery to
100% of receivers is a statistical characteristic of the protocols 100% of IMG receivers is a statistical characteristic of the
used. Usage of reliable IMG delivery mechanisms is expected to depend protocols used. Usage of reliable IMG delivery mechanisms is expected
on the extent to which underlying networks provide reliability and, to depend on the extent to which underlying networks provide
conversely, introduce errors. Note, some deployments of IMG transport reliability and, conversely, introduce errors. Note, some deployments
protocols may not aim to provide perfect reception to all receivers of IMG transport protocols may not aim to provide perfect reception
in all possible cases. to all IMG receivers in all possible cases.
4.5 IMG Descriptions 5.5 IMG Descriptions
REQ DES-1: IMG metadata MUST be interoperable over any IMG delivery REQ DES-1: IMG metadata MUST be interoperable over any IMG transport
protocol, such that an application receiving the same metadata over protocol, such that an application receiving the same metadata over
any one (or more) of several network connections and/or delivery any one (or more) of several network connections and/or IMG transport
protocols will interpret the metadata in exactly the same way. (This protocols will interpret the metadata in exactly the same way. (This
also relates to the 'Independence of IMG Operations from IMG also relates to the 'Independence of IMG Operations from IMG
Metadata' requirement). Metadata' requirement).
REQ DES-2: IMG delivery MUST enable the carriage of any format of REQ DES-2: IMG delivery MUST enable the carriage of any format of
application-specific metadata. application-specific metadata.
Thus, the system will support the description of many kinds of Thus, the system will support the description of many kinds of
multimedia content, without the need for a single homogenous metadata multimedia content, without the need for a single homogenous metadata
syntax for all uses (which would be infeasible anyway). This is syntax for all uses (which would be infeasible anyway). This is
skipping to change at page 11, line 25 skipping to change at page 15, line 43
select one or more specific application-specific metadata formats select one or more specific application-specific metadata formats
(standard, syntax, etc.), the IMG system MUST be independent of this (standard, syntax, etc.), the IMG system MUST be independent of this
(it may be aware, but it will operate in the same way for all). (it may be aware, but it will operate in the same way for all).
Thus, a transfer envelope format, that is uniform across all Thus, a transfer envelope format, that is uniform across all
different application-specific IMG metadata formats, is needed. The different application-specific IMG metadata formats, is needed. The
payload of this transfer envelope would be some application-specific payload of this transfer envelope would be some application-specific
metadata. metadata.
REQ DES-4: IMG metadata MUST be structured such that it is possible REQ DES-4: IMG metadata MUST be structured such that it is possible
to deliver only part of a sender's (and the global) complete IMG to deliver only part of an IMG sender's (and the global) complete IMG
metadata knowledge. metadata knowledge.
REQ DES-5: A transfer envelope MUST be defined to include essential REQ DES-5: A transfer envelope MUST be defined to include essential
parameters. parameters.
Examples of essential parameters are those that allow the metadata in Examples of essential parameters are those that allow the metadata in
question to be uniquely identified and updated by new versions of the question to be uniquely identified and updated by new versions of the
same metadata. same metadata.
REQ DES-6: It SHALL be possible to deduce the metadata format from REQ DES-6: It SHALL be possible to deduce the metadata format from
skipping to change at page 11, line 49 skipping to change at page 16, line 19
metadata transfer. metadata transfer.
Thus, it will even be possible to describe relationships between Thus, it will even be possible to describe relationships between
syntactically dissimilar application-specific formats within the same syntactically dissimilar application-specific formats within the same
body of IMG metadata knowledge. body of IMG metadata knowledge.
REQ DES-8: IMG metadata SHOULD support to describe differences REQ DES-8: IMG metadata SHOULD support to describe differences
between update version and old version of IMG metadata when IMG between update version and old version of IMG metadata when IMG
delivery mechanism carries updated IMG metadata and those differences delivery mechanism carries updated IMG metadata and those differences
are considerably little. (This also relates the delivery property are considerably little. (This also relates the delivery property
requirements for congestion control in Section 4.2.3). requirements for congestion control in Section 5.2.3).
6 Security Considerations
5 Security Considerations
Internet Media Guides are used to convey information about multimedia Internet Media Guides are used to convey information about multimedia
resources from one or more senders across one or intermediaries to resources from one or more IMG senders across one or intermediaries
one or more receivers. IMG metadata may be pushed to the receivers or to one or more IMG receivers. IMG metadata may be pushed to the IMG
interactively retrieved by them. IMGs provide metadata as well as receivers or interactively retrieved by them. IMGs provide metadata
scheduling and rendezvous information about multimedia resources, as well as scheduling and rendezvous information about multimedia
etc. and requests for IMG metadata may contain information about the resources, etc. and requests for IMG metadata may contain information
requesting users. about the requesting users.
The information contained in IMG metadata as well as the operations The information contained in IMG metadata as well as the operations
related to IMGs should be secured to avoid forging information, related to IMGs should be secured to avoid forging information,
misdirecting users, spoofing senders, etc. and to protect user misdirecting users, spoofing IMG senders, etc. and to protect user
privacy. privacy.
The remainder of section addresses the security requirements for The remainder of section addresses the security requirements for
IMGs. IMGs.
5.1 IMG Authentication and Integrity 6.1 IMG Authentication and Integrity
IMG metadata and its parts need to be protected against unauthorized IMG metadata and its parts need to be protected against unauthorized
altering/adding/deletion on the way. Their originator needs to be altering/adding/deletion on the way. Their originator needs to be
authenticated. authenticated.
REQ AUT-1: It MUST be possible to authenticate the originator of a REQ AUT-1: It MUST be possible to authenticate the originator of a
set of IMG metadata. set of IMG metadata.
REQ AUT-2: It MUST be possible to authenticate the originator of a REQ AUT-2: It MUST be possible to authenticate the originator of a
subpart of IMG metadata (e.g. a delta or a subset of the subpart of IMG metadata (e.g. a delta or a subset of the
skipping to change at page 13, line 7 skipping to change at page 17, line 25
piece had been separated from other pieces of IMG metadata and piece had been separated from other pieces of IMG metadata and
combined with other pieces to form new IMG metadata. combined with other pieces to form new IMG metadata.
REQ AUT-7: It MUST be possible to authenticate the originator of an REQ AUT-7: It MUST be possible to authenticate the originator of an
IMG operation. IMG operation.
REQ AUT-8: It MUST be possible to validate the integrity of any REQ AUT-8: It MUST be possible to validate the integrity of any
contents of an IMG operation (e.g. the subscription or inquiry contents of an IMG operation (e.g. the subscription or inquiry
information). information).
5.2 Privacy 6.2 Privacy
Customized IMG metadata and IMG metadata delivered by notification to Customized IMG metadata and IMG metadata delivered by notification to
individual users may reveal information about the habits and individual users may reveal information about the habits and
preferences of a user and may thus deserve confidentiality preferences of a user and may thus deserve confidentiality
protection, even though the information itself is public. protection, even though the information itself is public.
REQ PRI-1: It MUST be possible to keep user requests to subscribe to REQ PRI-1: It MUST be possible to keep user requests to subscribe to
or retrieve certain (parts of) IMG metadata confidential. or retrieve certain (parts of) IMG metadata confidential.
REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG
metadata, or pointers to IMG metadata delivered to individual users metadata, or pointers to IMG metadata delivered to individual users
or groups of users confidential. or groups of users confidential.
REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- REQ PRI-3: It SHOULD be possible to ensure this confidentiality end-
to-end, that is, to prevent intermediaries (such as IMG transceivers) to-end, that is, to prevent intermediaries (such as IMG transceivers)
from accessing the contained information. from accessing the contained information.
5.3 Access Control for IMGs 6.3 Access Control for IMGs
Some IMG metadata may be freely available, while access to other may Some IMG metadata may be freely available, while access to other may
be restricted to closed user groups (e.g. paying subscribers). Also, be restricted to closed user groups (e.g. paying subscribers). Also,
different parts of IMG metadata may be protected at different levels: different parts of IMG metadata may be protected at different levels:
e.g. metadata describing a media session may be freely accessible e.g. metadata describing a media session may be freely accessible
while rendezvous information to actually access the media session may while rendezvous information to actually access the media session may
require authorization. require authorization.
REQ ACC-1: It MUST be possible to authorize user access to IMG REQ ACC-1: It MUST be possible to authorize user access to IMG
metadata. metadata.
skipping to change at page 13, line 48 skipping to change at page 18, line 19
of IMG metadata (delta information, subparts, pointers). of IMG metadata (delta information, subparts, pointers).
REQ ACC-3: It MUST be possible to require different authorization for REQ ACC-3: It MUST be possible to require different authorization for
different parts of the same IMG metadata. different parts of the same IMG metadata.
REQ ACC-4: It MUST be possible to access selected IMG metadata REQ ACC-4: It MUST be possible to access selected IMG metadata
anonymously. anonymously.
REQ ACC-5: It MUST be possible for an IMG receiver to choose not to REQ ACC-5: It MUST be possible for an IMG receiver to choose not to
receive (parts of) IMG metadata in order to avoid being identified by receive (parts of) IMG metadata in order to avoid being identified by
the sender. the IMG sender.
REQ ACC-6: It SHOULD be possible for IMG transceiver to impose REQ ACC-6: It SHOULD be possible for IMG transceiver to impose
different authorization requirements. different authorization requirements.
REQ ACC-7: It MAY be possible for IMG senders to require certain REQ ACC-7: It MAY be possible for IMG senders to require certain
authorization that cannot be overridden by intermediaries. authorization that cannot be overridden by intermediaries.
5.4 Denial-of-Service attacks 6.4 Denial-of-Service attacks
Retrieving or distributing IMG metadata may require state in the Retrieving or distributing IMG metadata may require state in the IMG
senders, transceivers, and/or receivers for the respective IMG senders, transceivers, and/or receivers for the respective IMG
delivery sessions. Attackers may create large numbers of sessions transport sessions. Attackers may create large numbers of sessions
with any of the above IMG entities to disrupt regular operation. with any of the above IMG entities to disrupt regular operation.
REQ DOS-1: IMG operations SHOULD be authenticated. REQ DOS-1: IMG operations SHOULD be authenticated.
REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up
session state in IMG entities to exhaust their resources. session state in IMG entities to exhaust their resources.
REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust
resources of IMG entities by flooding them with IMG metadata. resources of IMG entities by flooding them with IMG metadata.
5.5 Replay Attacks 6.5 Replay Attacks
IMG metadata disseminated by the sender or a transceiver may be IMG metadata disseminated by an IMG sender or an IMG transceiver may
updated, deleted, or lose validity over time for some other reasons. be updated, deleted, or lose validity over time for some other
Replaying outdated IMG metadata needs to be prevented. reasons. Replaying outdated IMG metadata needs to be prevented.
Furthermore, replay attacks may also apply to IMG operations (rather Furthermore, replay attacks may also apply to IMG operations (rather
than just their payload). Replaying operations needs also be than just their payload). Replaying operations needs also be
prevented. prevented.
REQ REP-1: IMG metadata MUST be protected against partial or full REQ REP-1: IMG metadata MUST be protected against partial or full
replacement of newer ("current") versions by older ones. replacement of newer ("current") versions by older ones.
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
the IMG operations. the IMG operations.
6 Acknowledgements 7 Acknowledgements
The authors would like to thank Hitoshi Asaeda, Petri Koskelainen, The authors would like to thank Hitoshi Asaeda, Petri Koskelainen,
Toni Paila and Dirk Kutscher for their comments and ideas on this Toni Paila and Dirk Kutscher for their comments and ideas on this
work. work.
7 Normative References 8 Normative References
[1] M. Handley and V. Jacobson, ``SDP: session description protocol,'' [1] M. Handley and V. Jacobson, ``SDP: session description protocol,''
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, Apr. 1998.
[2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement [2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement
protocol,'' RFC 2974, Internet Engineering Task Force, Oct. 2000. protocol,'' RFC 2974, Internet Engineering Task Force, Oct. 2000.
[5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP: session Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP: session
initiation protocol,'' RFC 3261, Internet Engineering Task Force, June initiation protocol,'' RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[6] S. Bradner, ``Key words for use in RFCs to indicate requirement [6] S. Bradner, ``Key words for use in RFCs to indicate requirement
levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997.
8 Informative References 9 Informative References
[3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ [3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[4] Session Directory Tool, http://www- [4] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/ mice.cs.ucl.ac.uk/multimedia/software/sdr/
9 Authors' Addresses 10 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan Japan
Email: nom@flab.fujitsu.co.jp Email: nom@flab.fujitsu.co.jp
Rod Walsh Rod Walsh
Nokia Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/