投递文章
投稿指南
Request for Comments: 4473 Fujitsu Labs
Category: Informational R. Walsh
J-P. Luoma
Nokia
J. Ott
Helsinki University of Technology
H. Schulzrinne
Columbia University
May 2006
Requirements for Internet Media Guides (IMGs)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo specifies requirements for a framework and protocols for
accessing and updating Internet Media Guide (IMG) information for
media-on-demand and multicast applications. These requirements are
designed to guide choice and development of IMG protocols for
efficient and scalable delivery.
Table of Contents
1. Introduction ....................................................3
1.1. Background and Motivation ..................................3
1.2. Scope of This Document .....................................4
2. Terminology .....................................................5
2.1. New Terms ..................................................5
3. Problem Statement ...............................................6
4. Use Cases Requiring IMGs ........................................7
4.1. Connectivity-based Use Cases ...............................7
4.1.1. IP Datacast to a Wireless Receiver ..................7
4.1.2. Regular Fixed Dial-up Internet Connection ...........8
4.1.3. Broadband Always-on Fixed Internet Connection .......9
4.2. Content-orientated Use Cases ...............................9
4.2.1. TV and Radio Program Delivery .......................9
4.2.2. Media Coverage of a Live Event .....................10
4.2.3. Distance Learning ..................................10
4.2.4. Multiplayer Gaming .................................10
4.2.5. File Distribution ..................................11
4.2.6. Coming-release and Pre-released Content ............11
5. Requirements ...................................................11
5.1. General Requirements ......................................11
5.1.1. Independence of IMG Operations from IMG Metadata ...11
5.1.2. Multiple IMG Senders ...............................12
5.1.3. Modularity .........................................12
5.2. Delivery Properties .......................................12
5.2.1. Scalability ........................................13
5.2.2. Support for Intermittent Connectivity ..............13
5.2.3. Congestion Control .................................13
5.2.4. Sender- and Receiver-Driven Delivery ...............13
5.3. Customized IMGs ...........................................14
5.4. Reliability ...............................................15
5.4.1. Managing Consistency ...............................15
5.4.2. Reliable Message Exchange ..........................16
5.5. IMG Descriptions ..........................................16
6. Security Considerations ........................................17
6.1. IMG Authentication and Integrity ..........................18
6.2. Privacy ...................................................19
6.3. Access Control for IMGs ...................................19
6.4. Denial-of-Service (DOS) Attacks ...........................20
6.5. Replay Attacks ............................................20
7. Normative References ...........................................21
8. Informative References .........................................21
9. Acknowledgements ...............................................22
1. Introduction
1.1. Background and Motivation
For some ten years, multicast-based (multimedia) conferences
(including IETF working group sessions) as well as broadcasts of
lectures/seminars, concerts, and other events have been used in the
Internet, more precisely, on the MBONE. Schedules and descriptions
for such multimedia sessions as well as the transport addresses,
codecs, and their parameters have been described using the Session
Description Protocol (SDP) [2] as a rudimentary (but as of then
largely sufficient) means. Descriptions have been disseminated using
the Session Announcement Protocol (SAP) [3] and Session Directory
Tools such as SD [4] or SDR [5]; descriptions have also been put up
on web pages, sent by electronic mail, etc.
Recently, interest has grown to expand -- or better: to generalize --
the applicability of these kinds of session descriptions.
Descriptions are becoming more elaborate in terms of included
metadata, more generic regarding the types of media sessions, and
possibly also support other transports than just IP (e.g., legacy TV
channel addresses). This peers well with the DVB (Digital Video
Broadcasting) [6] Organization’s increased activities towards IP-
based communications over satellite, cable, and terrestrial radio
networks, also considering IP as the basis for TV broadcasts and
further services. The program/content descriptions are referred to
as Internet Media Guides (IMGs) and can be viewed as a generalization
of Electronic Program Guides (EPGs) and multimedia session
descriptions.
An Internet Media Guide (IMG) has a structured collection of
multimedia session descriptions expressed using SDP, SDPng [7], or
some similar session description format. This is used to describe a
set of multimedia services (e.g., television program schedules,
content delivery schedules) but may also refer to other networked
resources including web pages. IMGs provide the envelope for
metadata formats and session descriptions defined elsewhere with the
aim of facilitating structuring, versioning, referencing,
distributing, and maintaining (caching, updating) such information.
The IMG metadata may be delivered to a potentially large audience,
who uses it to join a subset of the sessions described, and who may
need to be notified of changes to this information. Hence, a
framework for distributing IMG metadata in various different ways is
needed to accommodate the needs of different audiences: For
traditional broadcast-style scenarios, multicast-based (push)
distribution of IMG metadata needs to be supported. Where no
multicast is available, unicast-based push is required, too.
Furthermore, IMG metadata may need to be retrieved interactively,
similar to web pages (e.g., after rebooting a system or when a user
is browsing after network connectivity has been re-established).
Finally, IMG metadata may be updated as time elapses because content
described in the guide may be changed: for example, the airtime of an
event such as a concert or sports event may change, possibly
affecting the airtime of subsequent media. This may be done by
polling the IMG sender as well as by asynchronous change
notifications.
Furthermore, any Internet host can be a sender of content and thus an
IMG sender. Some of the content sources and sinks may only be
connected to the Internet sporadically. Also, a single human user
may use many different devices to access metadata. Thus, we envision
that IMG metadata can be sent and received by, among others, cellular
phones, Personal Digital Assistants (PDAs), personal computers,
streaming video servers, set-top boxes, video cameras, and Digital
Video Recorders (DVRs), and that the data be carried across arbitrary
types of link layers, including bandwidth-constrained mobile
networks. However, generally we expect IMG senders to be well-
connected hosts.
Finally, with many potential senders and receivers, different types
of networks, and presumably numerous service providers, IMG metadata
may need to be combined, split, filtered, augmented, modified, etc.,
on their way from the sender(s) to the receiver(s) to provide the
ultimate user with a suitable selection of multimedia services
according to her preferences, subscriptions, location, and context
(e.g., devices, access networks).
1.2. Scope of This Document
This document defines requirements that Internet Media Guide
mechanisms must satisfy in order to deliver IMG metadata to a
potentially large audience. Since IMGs can describe many kinds of
multimedia content, IMG methods are generally applicable to several
scenarios.
In considering wide applicability, this document provides the problem
statement and discusses existing mechanisms in this area. Then
several use case scenarios for IMGs are explained including
descriptions of how IMG metadata and IMG delivery mechanisms
contribute to these scenarios. 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
IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group (SAP,
SIP [8], SDP).
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 [1].
2.1. New Terms
Internet Media Guide (IMG): IMG is a generic term used to describe
the formation, delivery, and use of IMG metadata. The
definition of the IMG is intentionally left imprecise.
IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced
individually from other IMG elements.
IMG Metadata: A set of metadata consisting of one or more IMG
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 in terms of both
large-scale and atomic data transfers.
IMG Sender: An IMG sender is a logical entity that sends IMG metadata
to one or more IMG receivers.
IMG Receiver: An IMG receiver is a logical entity that receives IMG
metadata from an IMG sender.
IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify received IMG metadata or merge IMG
metadata received from several different IMG senders.
IMG Operation: An atomic operation of an IMG transport protocol, used
between IMG sender(s) and IMG receiver(s) for the delivery of
IMG metadata and for the control of IMG sender(s)/receiver(s).
IMG Transport Protocol: A protocol that transports IMG metadata 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 time-bound
series of IMG transport protocol interactions that provide
delivery of IMG metadata from the IMG sender to the IMG
receiver(s).
3. Problem Statement
As we enumerate the requirements for IMGs, it will become clear that
they are not fully addressed by the existing protocols. The
"Framework for the Usage of Internet Media Guides" [9] discusses
about these issues in more detail.
The MMUSIC working group has long been investigating content, media
and service information delivery mechanisms, and protocols, and has
itself produced the Session Announcement Protocol (SAP), the Session
Description Protocol (SDP), and the Session Initiation Protocol
(SIP). SDP is capable of describing multimedia sessions (i.e.,
content in a wider sense) by means of limited descriptive information
intended for human perception plus transport, scheduling information,
and codecs and addresses for setting up media sessions. SIP and SAP
are protocols to distribute these session descriptions.
However, we perceive a lack of a standard solution for scalable IMG
delivery mechanism in the number of receivers with consistency of IMG
metadata between an IMG sender and IMG receiver for both bi-
directional and unidirectional transport. With increased service
dynamics and complexity, there is an increased requirement for
updates to these content descriptions.
HTTP [10] is a well-known information retrieval protocol using bi-
directional transport and is 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 [3] is an announcement protocol that distributes session
descriptions via multicast. It does not support prioritization or
fine-grained metadata selection and update notifications, as it
places restrictions on metadata payload size and always sends the
whole metadata. It requires a wide-area multicast infrastructure for
it to be deployable beyond a local area network.
SIP [8] and SIP-specific event notifications [11] can be used to
notify subscribers of the update of IMG metadata for bi-directional
transport. However, it is necessary to define an event package for
IMGs.
We also perceive a lack of standard solution for flexible content
descriptions to support a multitude of application-specific metadata
and associated data models with a different amount of detail and
different target audiences.
SDP [2] has a text-encoded syntax to specify multimedia sessions for
announcements and invitations. It is primarily intended to describe
client capability requirements and enable client application
selection. Although SDP is extensible, it has limitations such as
structured extensibility and capability to reference properties of a
multimedia session from the description of another session.
These can mostly be overcome by the XML-based SDPng [7] -- which is
intended for both two-way negotiation and unidirectional delivery --
or similar content description mechanisms. Since SDPng addresses
multiparty multimedia conferences, it would be necessary to extend
the XML schema in order to describe general multimedia content.
4. Use Cases Requiring IMGs
4.1. Connectivity-based Use Cases
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 (cyclically repeated with a
fixed bandwidth) 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 may be distributed between
several logical channels. This is so that a receiver needs 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
(possibly well-known) root multicast channel/group and progressively
access only those additional channels based on metadata in parent
channels.
In some cases, the receiver may have multiple access interfaces
adding bi-directional communications capability. This enables a
multitude of options, but most important, it enables NACK-based
reliability and the individual retrieval of missed or not-multicast
sets of metadata.
Thus, essential IMG features in this case include the following:
robust unidirectional delivery (with optional levels of reliability
including "plug-in FEC" supported by a transport layer protocol),
which implies easily identifiable segmentation of delivery data to
make 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; and 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 (<56 kbps 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 query-response methods, 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.
Some services on broadband, such as live media broadcasting, benefit
from multicast transport for streaming media because of scalability.
In the cases where multicast transport is already available, it is
convenient for a sender and receiver to retrieve IMG metadata over
multicast transport. Thus, broadband users may be forced to retrieve
IMG metadata over multicast if backbone 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
enabling 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 [12]. There are
several unique features of IMGs that set them apart from related
application areas such as Service Location Protocol (SLP) based
service location discovery, Lightweight Directory Access Protocol
(LDAP) based indexing services, and search engines such as Google.
Features unique to IMGs include the following:
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. 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.
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 later
consumption. 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.2. 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 a 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.3. 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 downloading of presentation material could be useful
for distance learning.
4.2.4. 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 user’s interest
in establishing such a session.
4.2.5. 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 of clients, the content
provider can use IMG metadata to schedule the delivery effectively.