it.
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 4: A Relay Network with an IMG Transceiver
IMG senders and receivers 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 is
used to combine or aggregate IMG metadata for some IMG receivers. An
IMG receiver may be allowed to receive IMG metadata from any number
of IMG senders.
IMG metadata is used to find, obtain, manage, and play media content.
IMG metadata may be modified during IMG transfer. For example, a
server may use IMGs 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 IMG metadata from different IMG
senders. For example, a rating service may add its own content
ratings or recommendations to existing metadata. An implication of
changing (or aggregating) IMG metadata from one or more IMG senders
is that the original authenticity is lost. Thus, it may be
beneficial to sign fragments so that the intermediary can replace a
fragment without changing the authenticity of the remainder. For
example, smaller fragments may be appropriate for more volatile
parts, and larger ones may be appropriate for stable parts.
4.2. One-to-Many Unidirectional Multicast
The one-to-many unidirectional multicast case implies many IMG
receivers and one or more IMG 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
Note, as defined in the IMG requirement REL-4 [4], an IMG transport
protocol MUST support reliable message exchange. This includes the
one-to-many unidirectional multicast case; however, the mechanism to
provide this is beyond the scope of this document.
4.3. One-to-One Bidirectional Unicast
In the one-to-one bidirectional unicast case, both query/resolve
(Figure 6) and subscribe/notify (Figure 7) message exchange
operations are feasible.
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
Figure 6: Query/Resolve Sequence Example
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 7: Subscribe/Notify Sequence Example
4.4. Combined Operations with Common Metadata
As shown in Figure 8, a common data model for multiple protocol
operations allows a diverse range of IMG senders and receivers to
provide consistent and interoperable sets of IMG metadata.
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
5. Applicability of Existing Protocols to the Proposed Framework Model
5.1. Existing Standards Fitting the IMG Framework Model
SDP: The SDP format [2] could be used to describe session-level
parameters (e.g., scheduling, addressing, and the use of media
codecs) to be included in Complete IMG Descriptions. 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 cannot provide IMG Descriptions and IMG Pointers
without significant overhead. It is expected that the information
conveyed by SDP is just a small subset of IMG metadata; thus, the use
of SDP for other than session parameters may not be reasonable.
SDPng [3]: 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 should be much more flexible and
allow extensions and integration with other description formats.
MPEG-7: Descriptions based on the MPEG-7 standard [5] 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. MPEG-7 is based on XML, so it is
well suited to be combined with other XML-based formats such as
SDPng.
TV-Anytime: The TV-Anytime Forum [6] provides descriptions based on
XML schema for TV-specific program guides. TV-Anytime uses the
MPEG-7 User description profile to a limited extent, only for user
preferences and usage history, and also a TV-Anytime-specific data
model for other schema. These are optimized to describe broadcast
schedules, on-demand program guides and program events.
HTTP: The HTTP protocol [7] can be used as a bidirectional unicast
IMG transport protocol. Being a request-reply-oriented protocol,
HTTP is 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. Thus, by itself, HTTP is not sufficient to
fulfill all of the IMG requirements [4] in a unicast deployment.
Session Announcement Protocol (SAP): The announcement mechanism
provided by SAP [8] 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, SAP lacks scalable and efficient reliability, extensibility
for payload size, and congestion control, and only one description is
allowed per SAP message due to lack of payload segmentation.
In principle, SAP could be extended to get around its limitations.
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 protocol is not
recommended.
SIP: The SIP-specific event mechanism described in RFC 3265 [9]
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.
Real Time Streaming Protocol (RTSP): The RTSP protocol [10] defines a
retrieval-and-update notification mechanism, named DESCRIBE and
ANNOUNCE, for the description of a presentation or media object in
order to initialize a streaming session. These methods are a subset
of the entire streaming control operations in RTSP; thus, these could
not be available for individual mechanisms. However, the DESCRIBE
method in RTSP could be used to instantiate IMG QUERY, IMG RESOLVE,
and IMG SUBSCRIBE, and the RTSP ANNOUNCE could be used to instantiate
an IMG NOTIFY for a streaming session controlled by RTSP.
5.2. IMG Mechanism Needs Which Are Not Met by Existing Standards
Several 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: (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 that is
common to, and independent of, the application metadata syntax(es)
used; and (d) agreement on basic metadata models to enable
interoperability testing of the above. The following sections
describe each of these.
5.2.1. A Multicast Transport Protocol
SAP is currently the only open standard protocol suited to the
unidirectional/multicast delivery of IMG metadata. 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.
The Asynchronous Layered Coding (ALC) [11] protocol from the IETF
Reliable Multicast Transport (RMT) working group is very interesting
as it fulfills 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 the RMT working group had a
fully specified protocol using ALC called FLUTE (File Delivery over
Unidirectional Transport) [12]. 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. In
particular, any announcement protocol must feature sufficient
scalability, flexibility, and reliability to meet IMG needs. Also,
the IMG ANNOUNCE operation must be supported and IMG NOTIFY
capability could be investigated for both hybrid unicast-multicast
and unidirectional unicast systems.
5.2.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 point-to-point
environment. Such a specification has not been published, although
several usable unicast transport protocols and specifications can be
harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.). In
particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation
pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE
operation can be achieved using HTTP, although other transport
protocol options may be beneficial to consider too.
5.2.3. IMG Envelope
An IMG envelope provides the binding between IMG operations and data
types. Such a binding can be realized by defining a common minimal
set of information needed to manage IMG metadata transfers, and by
including this information with any set of IMG metadata delivered to
IMG receivers.
Four options for IMG metadata transfer envelope delivery 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 would hinder interoperability and
transport protocol independence.
2. A separate envelope object, which points to the IMG metadata
’object’, delivered in-band with the metadata transport
protocol session. This might 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
RTCP [14]). This would also enable schemes that deliver
envelope and metadata ’objects’ by different media, also using
more than a single transport protocol.
3. A metadata wrapper that points to and/or embeds the service
metadata into its ’super-syntax’. For example, XML would
enable embedding generic text objects.
4. Embedding in the metadata itself. However, this requires a
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.
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.
When there are superset/subset relations between IMG Descriptions, it
is assumed that the IMG Descriptions of the subset inherit the
parameters of the superset. Thus, an IMG metadata transfer envelope
carrying the IMG Descriptions of a superset may implicitly define
parameters of IMG Descriptions belonging to its subset. The
relations between IMG Descriptions may span from one envelope to
another according to a data model definition.
5.2.4. Metadata Data Model
A structured data model would allow reuse and extension of the set of
metadata and may enable use of multiple syntaxes (SDP, MPEG-7, etc.)
as part of the same body of IMG metadata.
For the successful deployment of IMGs in various environments,
further work may be needed to define metadata and data models for
application-specific requirements. Existing (and future) work on
these would need to be mapped to the IMG data types and use of the
IMG transfer envelope concept as described above.
This document is a framework for the delivery of IMG metadata and
thus further discussion on the definition data models for IMGs is
beyond its scope.
6. Security Considerations
The IMG framework is developed from the IMG requirements document
[4], 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 specification would inherit the security considerations of
specific protocols used.
Protocol instantiations that are used to provide IMG operations will
have very different security considerations depending on their scope
and purpose. However, there are several general issues that are
valuable to consider and, in some cases, provide technical solutions
for. These are described below.
Individual and group privacy: Customized IMG metadata may reveal
information about the habits and preferences of a user and may thus
deserve confidentiality protection, even if the original information
were public. Protecting this metadata against snooping requires the
same actions and measures as for other point-to-point and multicast
Internet communications. Naturally, the risk of snooping depends on
the amount of individual or group personalization the IMG metadata
contains.
IMG authenticity: In some cases, the IMG receiver needs to be assured
of the sender or origin of IMG metadata or its modification history.
This can prevent denial-of-service or hijacking attempts that give an
IMG receiver incorrect information in or about the metadata, thus
preventing successful access of the media or directing the IMG
receiver to the incorrect media possibly with tasteless material.
IMG receiver authorization: Some or all of any IMG sender’s metadata
may be private or valuable enough to allow access to only certain IMG
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.
Unidirectional specifics: A difficulty that is faced by
unidirectional delivery operations is that many protocols providing
application-level security are based on bidirectional 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 transport
protocols may be capable of delivering arbitrary files, it is
RECOMMENDED that the IMG operations do not have write access to the
system or any other critical areas.
7. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8. Informative References
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Kutscher, D., Ott, J., and C. Bormann, "Session description and
capability negotiation", Work in Progress, October 2003.
[4] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne,
"Requirements for Internet Media Guides", Work in Progress,