[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
draft-ietf-mmusic-img-framework
Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura
Fujitsu Labs.
R. Walsh
J. Luoma
Nokia
H. Asaeda
INRIA
H. Schulzrinne
Columbia University
draft-nomura-mmusic-img-framework-02.txt
October 27, 2003
Expires: April 2004
A Framework for the Usage of 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 document defines a framework for the delivery of Internet Media
Guides (IMGs). An IMG is a structured collection of multimedia
session descriptions expressed using SDP, SDPng or some similar
session description format. This document describes several use case
scenarios requirering the IMG framework, a generalized model for IMG
delivery mechanisms, and the use of existing protocol to create an
IMG delivery infrastructure.
Y. Nomura et. al. [Page 1]
Internet Draft IMG Framework October 27, 2003
Table of Contents
1 Introduction ........................................ 3
1.1 Background and Motivation ........................... 3
1.2 Scope of this Document .............................. 3
2 Terminology ......................................... 4
3 Use Cases Requiring IMG Framework ................... 4
3.1 Connectivity-based Use Cases ........................ 4
3.1.1 IP Datacast to a Wireless Receiver .................. 4
3.1.2 Regular Fixed Dial-up Internet Connection ........... 6
3.1.3 Broadband Always-on Fixed Internet Connection ....... 6
3.2 Content-orientated Use Cases ........................ 6
3.2.1 File Distribution ................................... 7
3.2.2 TV and Radio Program Delivery ....................... 7
3.2.3 Media Coverage of a Live Event ...................... 7
3.2.4 Distance Learning ................................... 8
3.2.5 Multiplayer Gaming .................................. 8
4 IMG Common Framework Model .......................... 8
4.1 IMG Data-Type ....................................... 9
4.1.1 Complete Description ................................ 9
4.1.2 Delta Description ................................... 9
4.1.3 Pointer ............................................. 9
4.2 Operation Set for IMG Delivery ...................... 10
4.2.1 IMG ANNOUNCE ........................................ 10
4.2.2 IMG QUERY ........................................... 10
4.2.3 IMG RESOLVE ......................................... 10
4.2.4 IMG SUBSCRIBE ....................................... 11
4.2.5 IMG NOTIFY .......................................... 11
4.3 IMG Entities ........................................ 11
4.4 Overview of Protocol Operations ..................... 12
5 Deployment Scenarios for IMG Entities ............... 13
5.1 One-to-many Unidirectional Multicast ................ 14
5.2 One-to-one Bi-directional Unicast ................... 15
5.3 Combined Operations with Common Metadata ............ 15
6 Applicability of Existing Protocols to the
Proposed Framework Model ............................ 16
6.1 Summary of Limitations of Existing Protocols ........ 16
6.2 Existing Protocol Fit to the IMG Framework Model
6.3 Outstanding IMG Mechanism Needs ..................... 18
6.3.1 A Multicast Transport Protocol ...................... 19
6.3.2 Usage of Unicast Transport Protocols ................ 19
6.3.3 The Metadata Envelope ............................... 20
6.3.4 Baseline (Meta)Data Model Specification ............. 21
7 Security Considerations ............................. 22
8 Normative References ................................ 23
9 Infomative References ............................... 25
10 Acknowledgements .................................... 25
11 Authors' Addresses .................................. 25
12 Bibliography ........................................ 26
Y. Nomura et. al. [Page 2]
Internet Draft IMG Framework October 27, 2003
1 Introduction
1.1 Background and Motivation
An Internet Media Guide (IMG) is a structured collection of
multimedia session descriptions expressed using SDP, SDPng or some
similar session description format. It is used to describe a set of
multimedia sessions (e.g. television program schedules, content
delivery schedules etc.) but may also refer to other networked
resources including web pages. An IMG provides an envelope for
metadata formats and session descriptions defined elsewhere with the
aim of facilitating structuring, versioning, referencing,
distributing, and maintaining (caching, updating) such information.
Firstly, this document explains several use case scenarios
requirering the IMG framework. IMGs are inherently required to be
independent of any particular access network, and link in general.
Therefore, they are suitable in many Internet access scenarios
including fixed and mobile devices, wired and satellite and
terrestrial radio, always-on Internet and intermittent connectivity,
and so on. Furthermore, IMGs provides essential functions that
facilitate better distribution of content. Section 3 describes how
IMGs and IMG delivery mechanisms contribute for the scenarios.
Then, this document defines a generalized model for IMG delivery
mechanisms and their deployment in network entities regarding the use
case scenarios. The IMG must be delivered to a potentially large
audience, who use it to join a subset of the sessions described, and
who may need to be notified of changes to the IMG. Hence, a framework
for distributing IMGs in various different ways is needed to
accommodate the needs of different audiences: For traditional
broadcast-style scenarios, multicast-based (push) distribution of
IMGs needs to be supported. Where no multicast is available,
unicast-based push is required, too.
Finally, this document outlines the use of existing protocol to
create an IMG delivery infrastructure. It aims to organize existing
protocol into common model and show their capabilities and
limitations from the view point of IMG delivery functions. One of the
multicast- enabling IMG requirements is scaling well to a large
number of hosts and IMG senders in a network. Another issue is the
need for flexibility and diversity in delivery methods, whereas
existing protocols tend to be bound to a specific application.
1.2 Scope of this Document
This document defines the a common framework model for the delivery
of Internet Media Guides (IMG). The framework describes existing
Y. Nomura et. al. [Page 3]
Internet Draft IMG Framework October 27, 2003
mechanisms and the level to which they support and enable the
framework. The requirements for IMG delivery mechanisms and
descriptions can be found in [1].
A brief run through the usage and use cases of media guide is
provided to illustrate the relevance of IMGs before the framework
model is presented. The framework model defines the data types,
operations and entities which are needed. These are then shown in a
number of simplified deployment scenarios.
Existing protocols are organized and referenced against the framework
model to show the degree to which they fulfil IMG framework and
requirements. This also makes it straightforward to identify gaps so
that new protocols needs are made apparent.
2 Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and "OPTIONAL" in this document are to
be interpreted as described in RFC 2119 [2].
Internet Media 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 Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify original IMGs or merge several IMGs
from a different IMG sender.
IMG Operations: An atomic process for the IMG protocol to
deliver IMG or control the IMG sender or IMG receiver.
3 Use Cases Requiring IMG Framework
3.1 Connectivity-based Use Cases
3.1.1 IP Datacast to a Wireless Receiver
Y. Nomura et. al. [Page 4]
Internet Draft IMG Framework October 27, 2003
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. Such that a receiver need only access the
channels of interest and thus reduce the amount of time and
processing of IP data (and storage). 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 f 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).
Y. Nomura et. al. [Page 5]
Internet Draft IMG Framework October 27, 2003
3.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 an
IMG). 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 IMGs 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).
3.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 IMGs over multicast if the respective
operators require this to keep system-wide bandwidth usage feasible.
3.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 of the scope and type of IMG usage. Many
more examples may be relevant, for instance those detailed in[3].
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 information is generally time-related
o The are timeliness requirements in the delivery of IMG
Y. Nomura et. al. [Page 6]
Internet Draft IMG Framework October 27, 2003
information
o IMG information may be updated as time elapses or when an
event arises
3.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. An IMG 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 to schedule the delivery effectively. Since IMG
can describe time-related data for each client, the content provider
can schedule delivery time for each client. This can save network
bandwidth and capacity of delivery servers. In addition, IMG can be
used to synchronize a set of files between a source host and
destination host, when those files change as time elapses.
3.2.2 TV and Radio Program Delivery
A source of audio/video streaming content can use the IMG 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 information
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 information can be used to notify
receivers of such changes, enabling users to be prompted or recording
times to be adjusted.
3.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
Y. Nomura et. al. [Page 7]
Internet Draft IMG Framework October 27, 2003
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 could 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 information should enable terminals to discover the availability
of different media used to cover a live event.
3.2.4 Distance Learning
An IMG 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.
3.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.
4 IMG Common Framework Model
Two common elements are found in all of existing IMG candidate cases:
the need to describe the services; the need to deliver the
descriptions. In some cases, the descriptions are multicast enablers
(such as the session parameters of SDP) and are thus intrinsically
part of the delivery aspects, and in other cases descriptors are
application-specific (both machine and human readable). Thus, the
technologies can be roughly divided into three areas:
o Application-specific Metadata -- data describing the services'
content and media which are both specific to certain
applications and generally human readable.
o Delivery Descriptors -- the descriptions (metadata) that are
essential to enable (e.g. multicast) delivery. These include
framing (headers) for application-specific metadata, the
metadata element identification and structure, fundamental
session descriptors.
o Delivery Protocol -- the methods and protocols to exchange
descriptions between the senders and the receivers. An IMG
Y. Nomura et. al. [Page 8]
Internet Draft IMG Framework October 27, 2003
delivery protocol consists of two functions: carrying IMG
metadata from an IMG sender to an IMG receiver and controlling
an IMG protocol. These functions are not always exclusive,
therefore some messages may combine control messages and
metadata carriage functions metadata to reduce the amount of
the messaging.
4.1 IMG Data-Type
A data model is needed to precisely define the terminology and
relationships between sets, supersets and subsets of metadata. A
precise data model is essential for the implementation of IMGs
although it is not within the scope of this framework and requires a
separate specification. However there are three IMG data-types in
general:
4.1.1 Complete Description
A Complete Description provides a complete syntax and semantics to
describe a set of metadata, which does not need any additional
information from other IMG entity.
Note, this is not to be confused with a complete IMG, which, although
vaguely defined here, represents the complete database of a sender
(or related group of senders -- potentially the complete Internet IMG
knowledge). A sender will generally deliver only subsets of metadata
from its complete database of metadata in a particular data exchange.
4.1.2 Delta Description
A Delta Description provides only part of a Complete Description,
defining the difference from a previous version of the Compete
Description in question. This descriptor may be used to reduce
network resource usage (it may be more bandwidth and congestion
friendly), for instance, data consistency is essential and, small and
frequent changes occur to the Complete Description. Thus, this
descriptor itself cannot represent complete metadata set until it is
combined with existing, or future, description knowledge.
4.1.3 Pointer
A pointer provided a simple identifier or locator, such as a URL,
that the receiver is able to reference specific metadata with. This
may be used to separately obtain metadata (complete or delta
descriptions) or perform another IMG management function such as data
expire (and erasure). The pointer does not include metadata par se
(although it may also appear as a data field in complete or delta
descriptors).
Y. Nomura et. al. [Page 9]
Internet Draft IMG Framework October 27, 2003
4.2 Operation Set for IMG Delivery
A finite set of operations both meets the IMG requirements [1] and
fits the roles of existing protocols. These are crystallized in the
next few sections.
4.2.1 IMG ANNOUNCE
When an IMG receiver participates in unidirectional communications
(e.g. over satellite, terrestrial radio and wired multicast networks)
an IMG receiver may not need to send any message to an IMG sender
prior to IMGs delivery. In this case, a IMG sender can initiate
unsolicited distribution for IMGs and an IMG sender is the only
entity which can maintain the distribution (this includes scenarios
with multiple and co-operative senders). This operation is useful
when there are considerably large number IMG receivers or IMG
receiver(s) do not have a guaranteed uplink connection to the IMG
sender(s). The sender may also include authentication data in the
announce operation so that receivers may check the authenticity of
the metadata. This operation is able to carry any of the IMG data-
types.
Note, there is no restriction to prevent IMG ANNOUNCE from being used
in an asynchronous solicited manner, where a separate operation
(possibly out of band) is able to subscribe/register receivers to the
IMG ANNOUNCE operation.
4.2.2 IMG QUERY
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
send an IMG QUERY message and initiate a receiver-driven IMG delivery
session. The IMG receiver expects a synchronous response to the
subsequent request from the IMG sender. This operation can be used
where a bi-directional transport network is available between the IMG
sender and receiver. Some IMG receivers may want to obtain IMG
metadata when a resource is available or just to avoid caching
unsolicited IMG metadata. The IMG receiver must indicate the extent
and data type of metadata wanted in some message in the operation
(Extent indicates the number and grouping of metadata descriptions).
In some cases requesting a sender's whole IMG may be feasible, in
others it may not.
4.2.3 IMG RESOLVE
An IMG sender synchronously responds and sends IMG metadata to an IMG
QUERY which has been sent by an IMG receiver. This operation can be
used where a bi-directional transport network is available between
the IMG sender and receiver. If the IMG QUERY specifies a subset of
Y. Nomura et. al. [Page 10]
Internet Draft IMG Framework October 27, 2003
IMG metadata (extent and data type) that the IMG sender has the
subset, the IMG sender can resolve this, otherwise it should indicate
that it is not able to resolve the query. The IMG sender may
authenticate the IMG receiver to investigate the IMG QUERY operation
in order to determine whether the IMG receiver is authorized to be
sent that metadata. The sender may also include authentication data
in the resolve operation so that receivers may check the authenticity
of the metadata. This operation may carry any of the IMG data-types.
4.2.4 IMG SUBSCRIBE
If an IMG receiver wants to be notified when metadata which the IMG
receiver holds is stale, the IMG receiver can start the IMG SUBSCRIBE
operation prior in order to solicit notify messagess. Since the IMG
receiver doesn't know when metadata will be updated and the notify
message will arrive, this operations does not synchronize with the
notify message. The IMG receiver may wait for the notify message for
a long time. The IMG sender may authenticate the IMG receiver to
investigate whether an IMG SUBSCRIBE operation is from an authorized
receiver.
4.2.5 IMG NOTIFY
An IMG receiver needs the response to an earlier IMG SUBSCRIBE and
the IMG NOTIFY indicates that an updated IMG is available or part of
the existing IMG is stale. An IMG NOTIFY may be delivered more than
once during the time an IMG SUBSCRIBE is active. This operation may
carry any of the IMG data-types. The sender may also include
authentication data in the notify operation so that receivers may
check the authenticity of the messages.
4.3 IMG Entities
There are several fundamental IMG entities that indicate the
capability to perform certain roles. An Internet host involved in IMG
operations may adopt one or more of these roles:
IMG Announcer : send IMG ANNOUNCE
IMG Listener : receive IMG ANNOUNCE
IMG Querier : send IMG QUERY to receive IMG RESOLVE
IMG Resolver : receive IMG QUERY then send IMG RESOLVE
IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY
IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY
Y. Nomura et. al. [Page 11]
Internet Draft IMG Framework October 27, 2003
Finally, the figure 1 shows a relationship between IMG entities and
the IMG sender and receiver.
+--------------------------------------------------------+
| IMG Sender |
+------------------+------------------+------------------+
| IMG Announcer | IMG Notifier | IMG Resolver |
+------------------+------------------+------------------+
| ^ ^
message | | |
direction v v v
+------------------+------------------+------------------+
| IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+
| IMG Receiver |
+------------------+------------------+------------------+
Figure 1: Relationship with IMG Entities
4.4 Overview of Protocol Operations
The figure 2 gives an overview of the relationship between transport
cases, IMG Operations and IMG Data-types (note, it is not a protocol
stack).
+--------------------------------------------------+
IMG | |
Data-type | Complete Desc., Delta Desc., Pointer |
| |
+-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+
IMG | | |
Transport | P-to-M | P-to-P |
| | |
+--------------+-----------------------------------+
Y. Nomura et. al. [Page 12]
Internet Draft IMG Framework October 27, 2003
Figure 2: IMG Operations and IMG Data-type
5 Deployment Scenarios for IMG Entities
This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple
dataflow from sender to receiver as shown in figure 3
+-------------+ +---------------+
| IMG Sender | | IMG Receiver |
| |--------------->| |
+-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship
Some IMG may be distributed to a large number of receivers. If, for
example, a particular IMG is public information and the sender
provides the same information for all receivers. This kind of IMG may
be distributed from one sender to multiple receivers (figure 4)
and/or or may be relayed across a set of IMG transceivers that
receive the IMG, 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
IMGs. Satellite and peer-to-peer networks may also carry IMGs.
IMG sender and receiver are logical functions and it is possible for
some or all hosts in a system to perform both roles, as, for
instance, in many-to-many communications or where a transceiver or
proxy is used to combine or aggregate IMG data for some receivers. An
IMG receiver may be allowed to receive IMG metadata from any number
of senders.
The IMG is used to find, obtain, manage and play content. The IMG
metadata distribution may be modified as they are distributed. For
example, a server may use an IMG to retrieve media content via
unicast and then make it available at scheduled times via multicast,
thus requiring a change of the corresponding metadata. IMG
transceivers may add or delete information or aggregate IMGs from
different senders. For example, a rating service may add its own
content ratings or recommendations to existing meta-data.
Y. Nomura et. al. [Page 13]
Internet Draft IMG Framework October 27, 2003
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 4: A Relay Network with an IMG Transceiver
5.1 One-to-many Unidirectional Multicast
This case implies many receivers and one or more senders implementing
IMG ANNOUNCER and IMG LISTENER operations as shown in figure 5.
Unidirectional +----------+
---------------> | IMG |
downlink | Listener |
------------->| 1 |
/ +----------+
+-----------+ / .
| IMG |-------- .
| Announcer | \ .
+-----------+ \ +----------+
------------->| IMG |
| Listener |
| # |
+----------+
Figure 5: IMG Unidirectional Multicast Distribution Example
Y. Nomura et. al. [Page 14]
Internet Draft IMG Framework October 27, 2003
5.2 One-to-one Bi-directional Unicast
Both query/resolve (figure 6) and subscribe/notify (figure 7) message
exchange operations are feasible.
+----------+ +----------+
| IMG |<------(1)------| IMG |
| Resolver |-------(2)----->| Querier |
+----------+ +----------+
Figure 6: Query/Resolve Deployment Example
+----------+ +------------+
| |<-------(1)--------| |
| IMG |--------(2)------->| IMG |
| Notifier | (time passes) | Subscriber |
| |--------(3)------->| |
+----------+ +------------+
Figure 7: Subscribe/Notify Deployment Example
5.3 Combined Operations with Common Metadata
As shown in figure 8, a common data model for multiple protocol
operations allows a diverse range of senders and receivers to provide
consistent and interoperable IMGs.
Y. Nomura et. al. [Page 15]
Internet Draft IMG Framework October 27, 2003
IMG Metadata IMG Senders IMG Receivers
+--------------+
+-----------+ ---->| IMG Listener |
| IMG | / +--------------+
/| Announcer |-----
+-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener |
| Description | |-+ / | - - - - - - -|
| metadata 1 | | | / +-----------+ /--->| IMG Querier |
+-------------+ | | -----| IMG |<----/ +--------------+
+-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+
\ \--->| IMG Querier |
\ +-----------+ | - - - - - - -|
\+ IMG +<--------->| IMG |
+ Notifier + + Subscriber +
+-----------+ +--------------+
Figure 8: Combined System with Common Metadata
6 Applicability of Existing Protocols to the Proposed Framework Model
6.1 Summary of Limitations of Existing Protocols
SDP[5] has a text-encoded syntax to specify multimedia sessions for
announcements and invitations. Although SDP is extensible, it has
limitations such as structured extensibility and capability to carry
another multimedia session descriptors.
These are mostly overcome by the XML-based SDPng[6] , which is
intended for both two-way negotiation and also unidirectional
delivery. Since SDPng addresses multiparty multimedia conferences, it
is necessary to extend the XML schema in order to describe general
multimedia content.
MPEG-7[7] is a collection of XML-based description tools for general
multimedia content including structured multimedia sessions. TV-
Anytime Forum[8] provides descriptions based on MPEG-7 for TV
specific program guides. These are likely to be limited to describe
pictures, music and movies, thus it may be necessary to extend these
descriptions in order to define a variety of documents, game
programs, binary files, live event and so on.
Y. Nomura et. al. [Page 16]
Internet Draft IMG Framework October 27, 2003
HTTP[9] is a well known information retrieval protocol using bi-
directional transport and widely used to deliver web-based content
descriptions to many hosts. However, it has well recognized
limitations of scalability in the number of HTTP clients since it
relies on the polling mechanism to keep information consistent
between the server and client.
SAP[10] distributes session descriptions via multicast. It does not
support fine-grained meta data selection and update notifications, as
it always sends the whole meta data. Given the lack of a wide-area
multicast infrastructure, it is likely only deployable within a local
area network.
SIP[11] and SIP-specific event notification[12] can be used to notify
subscribers of the update of IMG for bi-directional transport. It is
necessary for SIP Event to define an event package for each specific
application such as [13].
6.2 Existing Protocol Fit to the IMG Framework Model
SDP: The SDP format could be used to describe session-level
parameters (e.g. scheduling, addressing and the use of media codecs)
to be included in Complete Descriptors. Although there are extension
points in SDP allowing the format to be extended, there are
limitations in the flexibility of this extension mechanism. However,
SDP syntax can not provide with Partial Descriptors and Pointers
without significant unused overhead. Because it is expected that the
information conveyed by SDP is just a small subset of IMG
information, the use of SDP for other than session-level IMG
parameters may not be reasonable.
SDPng: Similar to SDP, this format could also be used for
representing session-level parameters of IMG metadata. Compared to
SDP, the XML-based format of SDPng is much more flexible with regards
to extensions and combining with other description formats.
MPEG-7: Descriptions based on the MPEG-7 standard could provide
application-specific metadata describing the properties of multimedia
content beyond parameters carried in SDP or SDPng descriptions.
MPEG-7 provides a machine-readable format of representing content
categories and attributes, helping end-users or receiving software in
choosing content for reception: this is well in line with the IMG
usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on
XML, it is well suited for for combining with other XML-based formats
such as SDPng.
HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG
delivery protocol. Being a request-reply oriented protocol, HTTP is
Y. Nomura et. al. [Page 17]
Internet Draft IMG Framework October 27, 2003
well suited for implementing synchronous operations such as QUERY,
RESOLVE and even SUBSCRIBE. However, HTTP does not provide
asynchronous operations such as ANNOUNCE and NOTIFY and to implement
asynchronous operations using HTTP, IMG receivers should poll the IMG
sender periodically. So alone, HTTP is not sufficient to fulfil IMG
needs in a unicast deployment.
SAP: The announcement mechanism provided by SAP provides
unidirectional delivery of session discovery information. Although
SDP is the default payload format of SAP, the use of a MIME type
identifier for the payload allows arbitrary payload formats to be
used in SAP messages. Thus, SAP could be used to implement the
(multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations.
However, the limitations of SAP as a generic IMG transport mechanism
include:
- Lack of reliability (through forward error correction / retransmissions)
- Lack of payload segmentation
- Limited payload size
- Only one description allowed per SAP message
- Lack of congestion control
- Lack of Internet standard authentication / encryption mechanisms
- It is an Experimental RFC with no support for progressing further
In principle, the current SAP protocol could be extended to get
around its limitations (e.g. the use of a multipart MIME type in the
SAP payload has been proposed, enabling multiple descriptions to be
carried in a single SAP message). However, the amount of changes
needed in SAP to address all of the above limitations would
effectively result in a new protocol. Due to these limitations, the
use of SAP as an IMG transport mechanism is not recommended.
SIP: The SIP-specific event mechanism described in RFC 3265 [11]
provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
via a bidirectional unicast connection. However, there are
scalability problems with this approach, as RFC 3265 currently does
not consider multicast.
6.3 Outstanding IMG Mechanism Needs
Several outstanding needs result from the IMG requirements, framework
model and existing relevant mechanisms as already shown in this
document. Four specific groupings of work are readily apparent which
are: (a) specification of an adequate multicast and unidirectional
capable announcement protocol; (b) specification of the use of
existing unicast protocols to enable unicast subscribe and
announcement/notification functionality; (c) specification of the
metadata envelope which is common to, and independent of, the
application metadata syntax(es) used; agreement on basic metadata
models to enable interoperability testing of the above. The following
Y. Nomura et. al. [Page 18]
Internet Draft IMG Framework October 27, 2003
sections describe each of these.
6.3.1 A Multicast Transport Protocol
SAP is currently the only open standard protocol suited to the
unidirectional/multicast delivery of IMG data. As discussed, it fails
to meet the IMG requirements in many ways and, since it is not
designed to be extensible, we recognize that a new multicast
transport protocol for announcements needs to be specified to meet
IMG needs. This protocol will be essential to IMG delivery for
unidirectional and multicast deployments so we recommend that this be
taken on as an official IETF work item.
The Asynchronous Layered Coding (ALC)[14] protocol from the IETF
Reliable Multicast Transport (RMT) working group is very interesting
as it fulfils many of the requirements, is extensible and has the
ability to `plug-in' both FEC (Forward Error Correction -- for
reliability) and CC (Congestion Control) functional blocks -- it is
specifically designed for unidirectional multicast object transport.
ALC is not fully specified, although RMT has a work-in-progress fully
specified protocol using ALC called FLUTE (File Delivery over
Unidirectional Transport)[15]. FLUTE seems to be the only fully
specified transport and open specification on which a new IMG
announcement protocol could be designed. Thus we recommend that ALC
and FLUTE be the starting points for this protocol's design.
Developing a new protocol from scratch, or attempting to improve SAP,
is also feasible, although it would involve repeating many of the
design processes and decisions already made by the IETF for ALC.
Thus, we recommend only to attempt this if ALC-based protocols are
later found to be insufficient.
In particular, any announcement protocol must feature sufficient
scalability, flexibility and reliability to meet IMG needs. Also, the
ANNOUNCE operation must be supported and also NOTIFY capability could
be investigated for both hybrid unicast-multicast and unidirectional
unicast systems.
6.3.2 Usage of Unicast Transport Protocols
A thorough description of the use of existing unicast protocols is
essential for the use of IMGs in a unicast and point-to-point
environment. Such a specification does not currently exist, although
several usable unicast transport protocols and specifications can be
harnessed for this (SIP, SIP events, HTTP, etc). In particular, both
SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled.
We anticipate that the FETCH operation will be a trivial usage of
HTTP, although other transport options may be beneficial to consider
Y. Nomura et. al. [Page 19]
Internet Draft IMG Framework October 27, 2003
too. Thus, it is important that this specification is taken on as an
official work item in the IETF. It is also important that individual
interest in specialist areas (such as peer-to-peer) is welcome too
should a part of the community benefit from this.
6.3.3 The Metadata Envelope
To be able to handle multiple metadata syntaxes, a common minimal set
of information is needed to handle discrete blocks of metadata. The
IMG framework model data types defined in this document. This minimal
set of information field will be named a `metadata envelope' and
must:
1. Uniquely identify the block of metadata, regardless of
metadata syntax used. The uniqueness may only be needed
within the domains the metadata is used but this must
enable globally unique identification to support Internet
usage. Scope/domain specific identifications should not
`leak' outside of the scope, and always using globally
unique identification (e.g. based on URIs) should avoid
this error.
2. Version the block so that changes can be easily handled and
stale data identified.
3. Give the temporal validity of the block. It must expire the
block (expiry time), and may optionally provide a time
(presumably in the future) from when the block becomes
valid. Temporal validity may be changeable for a block, and
even a specific version of a block.
4. Be independent of the metadata syntax(es) used for the
metadata block, in the sense that no useful syntax should
be excluded.
For blocks with multiple descriptors, it is assumed that any
descriptors inherit the parameters of the (super)blocks. Thus the
above information will implicitly describe the individual
descriptors.
Four options for metadata envelope transport are feasible:
1. Embedding in a transport protocol header. This can be done
with either header extensions of existing protocols, or
newly defined header fields of a new (or new version of a)
transport protocol. However, multiple methods for the
variety of transport protocols may hinder interoperability.
Y. Nomura et. al. [Page 20]
Internet Draft IMG Framework October 27, 2003
2. A separate envelope object (a form of metadata itself)
delivered in-band with the metadata. This would complicate
delivery as the envelope and `service' metadata objects
would have to be bound, e.g. by pairing some kind of
transport object numbers (analogous to port number pairs
sometimes used for RTP and RTSP).
3. A metadata wrapper which points to and/or embeds the
service metadata into its `super-syntax'. For example, XML
enables referencing (pointing to) other resources as well
as embedding generic text objects.
4. Embedding in the metadata itself. However, this requires
new field in many metadata syntaxes and would not be
feasible if a useful syntax were not capable of
extensibility in this way. It also introduces a larger
`implementation interpretation' variety which would hinder
interoperability. Thus this option is not recommended.
6.3.4 Baseline (Meta)Data Model Specification
It is likely that more than one of these options will fulfill the
needs of IMGs so the selection, and possibly optimization, is left
for subsequent specification and feedback from implementation
experience. Such a specification is essential for IMG delivery and so
should be an official IETF work item.
Relevant work-in-progress ensures that support of one, or very few,
metadata syntaxes is not sufficient. Whereas the transport protocol
should not restrict the metadata format, the metadata envelope may
influence the choice metadata. However, metadata in binary format
should not be prevented, in addition to the more abundant text and
XML syntaxes currently available.
In most cases the actual content of metadata will be application, or
service domain, specific. For instance, digital cinema distribution
and television channels will have many different requirements. The
task of specifying the bulk of the worldfs metadata is well beyond
the scope of this document: a framework for the delivery of IMGs. We
do anticipate that existing and future metadata specifications,
including those of several working groups and standardization bodies,
shall be able to use the services of the IMG framework. However, it
is not essential to the current IMG work to specify standards with
application-specific metadata.
It is essential that the three IMG data-types are enabled, but it may
not be necessary to achieve this for every metadata syntax available,
nor may it be important to the IETF to cover every possibility for
Y. Nomura et. al. [Page 21]
Internet Draft IMG Framework October 27, 2003
this. Generally, Complete Descriptions will be correct for existing
syntaxes (e.g. for XML may be validated according to existing
schema). Pointer data-types may be served by a new syntax (extremely
minimal), although it is feasible that the proposed metadata envelope
specification will contain enough information to implement the
Pointer data type. Partial Descriptions may need new or modified
syntaxes and semantics (e.g. XML schema) as mandatory fields for a
Complete Description may be redundant for a Partial Description.
During and following the specification of the metadata envelope,
enabling the delivery of Partial Descriptions should be considered.
To gain implementation experience, it is essential to agree the basic
of some metadata in interoperability tests and subsequently in
widespread deployments. So we anticipate that a minimal IMG data
model would be useful to the Internet community, although it should
not be informational rather than mandatory. This may not need to be
an official IETF work item.
7 Security Considerations
The IMG framework is developed from the IMG Requirements document [1]
and so the selection of specific protocols and mechanism for use with
the IMG framework must also take into account the security
considerations of the IMG Requirements document. This framework
document does not mandate the use of specific protocols. However, an
IMG system would inherit the security considerations of specific
protocols used, although this is out side the scope of this document.
Protocol instantiations which are used to provide IMG operations will
have very different security considerations depending on their scope
and purpose. However, there are several general issues which are
valuable to consider and, in some cases, provide technical solutions
to deal with. These are described below.
Individual and Group Privacy: 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. Capturing and protecting this IMG information requires the
same actions and measures as for other point-to-point and multicast
Internet communications. Naturally, the risk depends on the amount of
individual or group personalization the snooped sessions contain.
Further consideration is valuable at both transport and metadata
levels.
IMG Authenticity: In some cases, the receiver needs to be assured of
the origin of an IMG or its modification history. This can prevent
denial of service or hijacking attempts which give an IMG receiver
incorrect information in or about the metadata, thus preventing
Y. Nomura et. al. [Page 22]
Internet Draft IMG Framework October 27, 2003
successful access of the media or directing the IMG receiver to the
incorrect media ? possibly with tasteless material. Action upon
detection of unauthorized data insertion is out of scope of this
document.
Receiver Authorization: Some or all of any IMG sender's metadata may
be private or valuable enough to allow access to only certain
receivers and thus make it worth authenticating users. Encrypting the
data is also a reasonable step, especially where group communications
methods results in unavoidable snooping opportunities for
unauthorized nodes. Encryption and the required security parameters
exchange are outside the scope of this document.
Unidirectional Specifics: A difficulty that is faced by
unidirectional delivery operations is that many protocols providing
application-level security are based on bi-directional
communications. The application of these security protocols in case
of strictly unidirectional links is not considered in the present
document.
Malicious Code: Currently, IMGs are not envisaged to deliver
executable code at any stage. However, as some IMG delivery protocols
may be capable of delivering arbitrary files, it is RECOMMENDED that
the FLUTE delivery service does not have write access to the system
or any other critical areas.
Protocol Specific Attacks: It is recommended that developers of any
IMG protocol take account of the above risks in addition to any
protocol design and deployment environment risks that may be
reasonably identified. Currently this framework document does not
recommend or mandate the use of any specific protocols, however the
deployment of IMG using specific protocol instantiations will
naturally be subject to the security considerations of those
protocols.
Security Improvement Opportunity: The security properties of one
channel and protocol can be improved through the use of another
channel and protocol. For example, a secure unicast channel can be
used to deliver the keys and initialization vectors for an encryption
algorithm used on a multicast channel. The exploitation of this
opportunity is specific to the protocols used and is outside the
scope of this document.
8 Normative References
[1] Y. Nomura et al., "Protocol requirements for Internet media
Y. Nomura et. al. [Page 23]
Internet Draft IMG Framework October 27, 2003
guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet
Engineering Task Force, Sept. 2003. 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] B. Quinn and K. Almeroth, "IP multicast applications: Challenges
and solutions," RFC 3170, Internet Engineering Task Force, Sept.
2001.
[4] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for
content internetworking (CDI)," RFC 3466, Internet Engineering Task
Force, Feb. 2003.
[5] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[6] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," internet draft, Internet Engineering Task
Force, Mar. 2003. Work in progress.
[7] ISO (International Organization for Standardization), "Overview
of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509,
International Organization for Standardization, Geneva, Switzerland,
Dec. 2001.
[8] TVA. Forum, "Metadata specification S-3," TV-Anytime Forum
Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002.
[9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-
Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
Engineering Task Force, Jan. 1997.
[10] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
[11] 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.
[12] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.
[14] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft,
"Asynchronous layered coding (ALC) protocol instantiation," RFC 3450,
Internet Engineering Task Force, Dec. 2002.
Y. Nomura et. al. [Page 24]
Internet Draft IMG Framework October 27, 2003
9 Infomative References
[13] J. Rosenberg, "A presence event package for the session
initiation protocol (SIP)," internet draft, Internet Engineering Task
Force, Jan. 2003. Work in progress.
[15] T. Paila et al., "FLUTE - file delivery over unidirectional
transport," Internet Draft draft-ietf-rmt-flute-02, Internet
Engineering Task Force, Sept. 2003. Work in progress.
10 Acknowledgements
The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila
and Petri Koskelainen on for their ideas and input to this document.
11 Authors' 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
Juha-Pekka Luoma
Nokia Corporation
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
Email: juha-pekka.luoma@nokia.com
Hitoshi Asaeda
INRIA
Project PLANETE
2004, Route des Lucioles, BP93,
06902 Sophia Antipolis,
France
Email: Hitoshi.Asaeda@sophia.inria.fr
Y. Nomura et. al. [Page 25]
Internet Draft IMG Framework October 27, 2003
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: schulzrinne@cs.columbia.edu
Y. Nomura et. al. [Page 26]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/