draft-ietf-mmusic-img-req-07.txt   draft-ietf-mmusic-img-req-08.txt 
Internet Engineering Task Force MMUSIC WG MMUSIC Working Group Y. Nomura
Internet Draft Y. Nomura Internet-Draft Fujitsu Labs.
Fujitsu Labs. Expires: June 23, 2006 R. Walsh
R. Walsh
J-P. Luoma J-P. Luoma
Nokia Nokia
J. Ott J. Ott
Universitaet Bremen Universitaet Bremen
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-req-07.txt December 19, 2005
June 21, 2004
Expires: December 2004
Requirements for Internet Media Guides Requirements for Internet Media Guides
draft-ietf-mmusic-img-req-08
STATUS OF THIS MEMO Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance have been or will be disclosed, and any of which he or she becomes
with RFC 3668." aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than a "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo specifies requirements for a framework and protocols for This memo specifies requirements for a framework and protocols for
accessing and updating Internet Media Guide (IMG) information for accessing and updating Internet Media Guide (IMG) information for
media-on-demand and multicast applications. These requirements are media-on-demand and multicast applications. These requirements are
designed to guide choice and development of IMG protocols for designed to guide choice and development of IMG protocols for
efficient and scalable delivery. efficient and scalable delivery.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
1.1 Background and Motivation ........................... 3 1.1 Background and Motivation ........................... 3
1.2 Scope of This Document .............................. 4 1.2 Scope of This Document .............................. 4
2 Terminology ......................................... 5 2 Terminology ......................................... 5
2.1 New Terms ........................................... 5
3 Problem Statement ................................... 6 3 Problem Statement ................................... 6
4 Use Cases Requiring IMGs ............................ 7 4 Use Cases Requiring IMGs ............................ 7
4.1 Connectivity-based Use Cases ........................ 7 4.1 Connectivity-based Use Cases ........................ 7
4.1.1 IP Datacast to a Wireless Receiver .................. 7 4.1.1 IP Datacast to a Wireless Receiver .................. 7
4.1.2 Regular Fixed Dial-up Internet Connection ........... 8 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8
4.1.3 Broadband Always-on Fixed Internet Connection ....... 8 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8
4.2 Content-orientated Use Cases ........................ 9 4.2 Content-orientated Use Cases ........................ 9
4.2.1 TV and Radio Program Delivery ....................... 9 4.2.1 TV and Radio Program Delivery ....................... 9
4.2.2 Media Coverage of a Live Event ...................... 9 4.2.2 Media Coverage of a Live Event ...................... 10
4.2.3 Distance Learning ................................... 10 4.2.3 Distance Learning ................................... 10
4.2.4 Multiplayer Gaming .................................. 10 4.2.4 Multiplayer Gaming .................................. 10
4.2.5 File Distribution ................................... 10 4.2.5 File Distribution ................................... 10
4.2.6 Coming-release and Pre-released Content ............. 11 4.2.6 Coming-release and Pre-released Content ............. 11
5 Requirements ........................................ 11 5 Requirements ........................................ 11
5.1 General Requirements ................................ 11 5.1 General Requirements ................................ 11
5.1.1 Independence of IMG Operations from IMG Metadata .... 11 5.1.1 Independence of IMG Operations from IMG Metadata .... 11
5.1.2 Multiple IMG Senders ................................ 11 5.1.2 Multiple IMG Senders ................................ 11
5.1.3 Modularity .......................................... 12 5.1.3 Modularity .......................................... 12
5.2 Delivery Properties ................................. 12 5.2 Delivery Properties ................................. 12
skipping to change at page 2, line 50 skipping to change at page 3, line 4
6.1 IMG Authentication and Integrity .................... 17 6.1 IMG Authentication and Integrity .................... 17
6.2 Privacy ............................................. 18 6.2 Privacy ............................................. 18
6.3 Access Control for IMGs ............................. 18 6.3 Access Control for IMGs ............................. 18
6.4 Denial-of-Service attacks ........................... 19 6.4 Denial-of-Service attacks ........................... 19
6.5 Replay Attacks ...................................... 19 6.5 Replay Attacks ...................................... 19
7 IANA Considerations ................................. 20 7 IANA Considerations ................................. 20
8 Normative References ................................ 20 8 Normative References ................................ 20
9 Informative References .............................. 20 9 Informative References .............................. 20
10 Acknowledgements .................................... 21 10 Acknowledgements .................................... 21
11 Authors' Addresses .................................. 21 11 Authors' Addresses .................................. 21
12 Full Copyright Statement ............................ 22
1 Introduction 1 Introduction
1.1 Background and Motivation 1.1 Background and Motivation
For some ten years, multicast-based (multimedia) conferences For some ten years, multicast-based (multimedia) conferences
(including IETF WG sessions) as well as broadcasts of (including IETF WG sessions) as well as broadcasts of
lectures/seminars, concerts, and other events have been used in the lectures/seminars, concerts, and other events have been used in the
Internet, more precisely, on the MBONE. Schedules and descriptions Internet, more precisely, on the MBONE. Schedules and descriptions
for such multimedia sessions as well as the transport addresses, for such multimedia sessions as well as the transport addresses,
skipping to change at page 3, line 25 skipping to change at page 3, line 25
rudimentary (but as of then largely sufficient) means. Dissemination rudimentary (but as of then largely sufficient) means. Dissemination
of the descriptions has been performed using the Session Announcement of the descriptions has been performed using the Session Announcement
Protocol (SAP) [3] and tools such as SD [4] or SDR [5]; descriptions Protocol (SAP) [3] and tools such as SD [4] or SDR [5]; descriptions
have also been put up on web pages, sent by electronic mail, etc. have also been put up on web pages, sent by electronic mail, etc.
Recently, interest has grown to expand -- or better: to generalize -- Recently, interest has grown to expand -- or better: to generalize --
the applicability of these kinds of session descriptions. the applicability of these kinds of session descriptions.
Descriptions are becoming more elaborate in terms of included Descriptions are becoming more elaborate in terms of included
metadata; more generic regarding the types of media sessions; and metadata; more generic regarding the types of media sessions; and
possibly also support other transports than just IP (e.g. legacy TV possibly also support other transports than just IP (e.g. legacy TV
channel addresses). This peers well with the DVB Organization's channel addresses). This peers well with the DVB (Digital Video
increased activities towards IP-based communications over satellite, Broadcasting) [6] Organization's increased activities towards
cable, and terrestrial radio networks, also considering IP as the IP-based communications over satellite, cable, and terrestrial radio
basis for TV broadcasts and further services. The program/content networks, also considering IP as the basis for TV broadcasts and
descriptions are referred to as Internet Media Guides (IMGs) and can further services. The program/content descriptions are referred to as
be viewed as a generalization of Electronic Program Guides (EPGs) and Internet Media Guides (IMGs) and can be viewed as a generalization of
multimedia session descriptions. Electronic Program Guides (EPGs) and multimedia session descriptions.
An Internet Media Guide (IMG) has a structured collection of An Internet Media Guide (IMG) has a structured collection of
multimedia session descriptions expressed using SDP, SDPng [6] or multimedia session descriptions expressed using SDP, SDPng [7] or
some similar session description format. This is used to describe a some similar session description format. This is used to describe a
set of multimedia services (e.g. television program schedules, set of multimedia services (e.g. television program schedules,
content delivery schedules) but may also refer to other networked content delivery schedules) but may also refer to other networked
resources including web pages. IMGs provide the envelope for metadata resources including web pages. IMGs provide the envelope for metadata
formats and session descriptions defined elsewhere with the aim of formats and session descriptions defined elsewhere with the aim of
facilitating structuring, versioning, referencing, distributing, and facilitating structuring, versioning, referencing, distributing, and
maintaining (caching, updating) such information. maintaining (caching, updating) such information.
The IMG metadata may be delivered to a potentially large audience, The IMG metadata may be delivered to a potentially large audience,
who use it to join a subset of the sessions described, and who may who use it to join a subset of the sessions described, and who may
skipping to change at page 4, line 50 skipping to change at page 4, line 50
statement and existing mechanisms in this area. Then several use case statement and existing mechanisms in this area. Then several use case
scenarios for IMGs are explained including descriptions of how IMG scenarios for IMGs are explained including descriptions of how IMG
metadata and IMG delivery mechanisms contribute to these scenarios. metadata and IMG delivery mechanisms contribute to these scenarios.
Following this, this document provides general requirements that are Following this, this document provides general requirements that are
independent of any transport layer mechanism and application, such as independent of any transport layer mechanism and application, such as
delivery properties, reliability and IMG descriptions. delivery properties, reliability and IMG descriptions.
This document reflects investigating work on delivery mechanisms for This document reflects investigating work on delivery mechanisms for
IMGs and generalizing work on session announcement and initiation IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group (SAP, protocols, especially in the field of the MMUSIC working group (SAP,
SIP [7], SDP). SIP [8], SDP).
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2.1 New Terms
Internet Media Guide (IMG): IMG is a generic term to describe Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise. definition of the IMG is intentionally left imprecise.
IMG Element: The smallest atomic element of metadata that can be IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced transmitted separately by IMG operations and referenced
individually from other IMG elements. individually from other IMG elements.
IMG Metadata: A set of metadata consisting of one or more IMG IMG Metadata: A set of metadata consisting of one or more IMG
elements. IMG metadata describes the features of multimedia elements. IMG metadata describes the features of multimedia
skipping to change at page 6, line 9 skipping to change at page 6, line 11
one or more IMG receivers within the scope of an IMG one or more IMG receivers within the scope of an IMG
transport protocol. An IMG transport session involves a transport protocol. An IMG transport session involves a
time bound series of IMG transport protocol interactions time bound series of IMG transport protocol interactions
that provide delivery of IMG metadata from the IMG sender that provide delivery of IMG metadata from the IMG sender
to the IMG receiver(s). to the IMG receiver(s).
3 Problem Statement 3 Problem Statement
As we enumerate the requirements for IMGs, it will become clear that As we enumerate the requirements for IMGs, it will become clear that
they are not fully addressed by the existing protocols. The Framework they are not fully addressed by the existing protocols. The Framework
for the Usage of Internet Media Guides [8] talks about these issues for the Usage of Internet Media Guides [9] talks about these issues
in more detail. in more detail.
The MMUSIC working group has long been investigating content, media The MMUSIC working group has long been investigating content, media
and service information delivery mechanisms and protocols, and has and service information delivery mechanisms and protocols, and has
itself produces Session Announcement Protocol (SAP), Session itself produces Session Announcement Protocol (SAP), Session
Description Protocol (SDP), and the Session Initiation Protocol Description Protocol (SDP), and the Session Initiation Protocol
(SIP). SDP is capable of describing multimedia sessions (i.e. (SIP). SDP is capable of describing multimedia sessions (i.e.
content in a wider sense) by means of limited descriptive information content in a wider sense) by means of limited descriptive information
intended for human perception plus transport, scheduling information, intended for human perception plus transport, scheduling information,
and codecs and addresses for setting up media sessions. SIP and SAP and codecs and addresses for setting up media sessions. SIP and SAP
are protocols to distribute these session descriptions. are protocols to distribute these session descriptions.
However, we perceive a lack of a standard solution for scalable IMG However, we perceive a lack of a standard solution for scalable IMG
delivery mechanism in the number of receivers with consistency of IMG delivery mechanism in the number of receivers with consistency of IMG
metadata between an IMG sender and IMG receiver for both metadata between an IMG sender and IMG receiver for both
bi-directional and unidirectional transport. With increased service bi-directional and unidirectional transport. With increased service
dynamics and complexity, there is an increased requirement for dynamics and complexity, there is an increased requirement for
updates to these content descriptions. updates to these content descriptions.
HTTP [9] is a well known information retrieval protocol using HTTP [10] is a well known information retrieval protocol using
bi-directional transport and widely used to deliver web-based bi-directional transport and widely used to deliver web-based
content descriptions to many hosts. However, it has well recognized content descriptions to many hosts. However, it has well recognized
limitations of scalability in the number of HTTP clients since it limitations of scalability in the number of HTTP clients since it
relies on the polling mechanism to keep information consistent relies on the polling mechanism to keep information consistent
between the server and client. between the server and client.
SAP [3] is an announcement protocol that distributes session SAP [3] is an announcement protocol that distributes session
descriptions via multicast. It does not support prioritization or descriptions via multicast. It does not support prioritization or
fine-grained metadata selection and update notifications, as it fine-grained metadata selection and update notifications, as it
places restrictions on metadata payload size and always sends the places restrictions on metadata payload size and always sends the
whole metadata. It requires a wide-area multicast infrastructure for whole metadata. It requires a wide-area multicast infrastructure for
it to be deployable beyond a local area network. it to be deployable beyond a local area network.
SIP [7] and SIP-specific event notification [10] can be used to SIP [8] and SIP-specific event notification [11] can be used to
notify subscribers of the update of IMG metadata for bi-directional notify subscribers of the update of IMG metadata for bi-directional
transport. However, it is necessary for SIP Event to define an event transport. However, it is necessary for SIP Event to define an event
package as a standard protocol for each specific application package as a standard protocol for each specific application
including IMGs. including IMGs.
We also perceive a lack of standard solution for flexible content We also perceive a lack of standard solution for flexible content
descriptions to support a multitude of application-specific metadata descriptions to support a multitude of application-specific metadata
and associated data models with differing amount of detail and and associated data models with differing amount of detail and
different target audiences. different target audiences.
SDP [2] has a text-encoded syntax to specify multimedia sessions for SDP [2] has a text-encoded syntax to specify multimedia sessions for
announcements and invitations. It is primarily intended to describe announcements and invitations. It is primarily intended to describe
client capability requirements and enable client application client capability requirements and enable client application
selection. Although SDP is extensible, it has limitations such as selection. Although SDP is extensible, it has limitations such as
structured extensibility and capability to reference properties of a structured extensibility and capability to reference properties of a
multimedia session from the description of another session. multimedia session from the description of another session.
These are mostly overcome by the XML-based SDPng, which is intended These are mostly overcome by the XML-based SDPng [7], which is
for both two-way negotiation and also unidirectional delivery. Since intended for both two-way negotiation and also unidirectional
SDPng addresses multiparty multimedia conferences, it is necessary to delivery. Since SDPng addresses multiparty multimedia conferences, it
extend the XML schema in order to describe general multimedia is necessary to extend the XML schema in order to describe general
content. multimedia content.
4 Use Cases Requiring IMGs 4 Use Cases Requiring IMGs
4.1 Connectivity-based Use Cases 4.1 Connectivity-based Use Cases
4.1.1 IP Datacast to a Wireless Receiver 4.1.1 IP Datacast to a Wireless Receiver
IP Datacast is the delivery of IP-based services over broadcast IP Datacast is the delivery of IP-based services over broadcast
radio. Internet content delivery is therefore unidirectional in this radio. Internet content delivery is therefore unidirectional in this
case. However, there can be significant benefits from being able to case. However, there can be significant benefits from being able to
provide rich media one-to-many services to such receivers. provide rich media one-to-many services to such receivers.
There are two main classes of receiver in this use case: fixed There are two main classes of receiver in this use case: fixed
mains-powered; and mobile battery-powered. Both of these are affected mains-powered; and mobile battery-powered. Both of these are affected
by radio phenomena and so robust, or error-resilient, delivery is by radio phenomena and so robust, or error-resilient, delivery is
important. Carouselled metadata transfer provides a base level of important. Carouselled metadata transfer (cyclically repeated with
robustness for an IP datacast based announcement system, although the fixed bandwidth) provides a base level of robustness for an IP
design of carouselled transfer should enable battery-powered datacast based announcement system, although the design of
receivers to go through periods of sleep to extend their operational carouselled transfer should enable battery-powered receivers to go
time between charges. Insertion of Forward Error Correction (FEC) through periods of sleep to extend their operational time between
data into metadata announcements improves error resilience, and charges. Insertion of Forward Error Correction (FEC) data into
reordering (interleaving) data blocks further increases tolerance to metadata announcements improves error resilience, and reordering
burst errors. (interleaving) data blocks further increases tolerance to burst
errors.
To enable receivers to more accurately specify the metadata they To enable receivers to more accurately specify the metadata they
are interested in, the unidirectional delivery may be distributed are interested in, the unidirectional delivery may be distributed
between several logical channels. This is so that a receiver needs between several logical channels. This is so that a receiver needs
only access the channels of interest and thus can reduce the amount only access the channels of interest and thus can reduce the amount
of time, storage and CPU resources needed for processing the IP of time, storage and CPU resources needed for processing the IP
data. Also, hierarchical channels enable receivers to subscribe to data. Also, hierarchical channels enable receivers to subscribe to
a, possibly well known, root multicast channel/group and a, possibly well known, root multicast channel/group and
progressively access only those additional channels based on progressively access only those additional channels based on
metadata in parent channels. metadata in parent channels.
In some cases the receiver may be multi-access, such that it is In some cases the receiver may have multiple access interfaces adding
capable of bi-directional communications. This enables a multitude of bi-directional communications capability. This enables a multitude of
options, but most importantly it enables NACK based reliability and options, but most importantly it enables NACK based reliability and
the individual retrieval of missed or not-multicasted sets of the individual retrieval of missed or not-multicasted sets of
metadata. metadata.
Thus, essential IMG features in this case include: robust Thus, essential IMG features in this case include: robust
unidirectional delivery (with optional levels of reliability unidirectional delivery (with optional levels of reliability
including "plug-in FEC") which implies easily identifiable including "plug-in FEC" supported by a transport layer protocol)
segmentation of delivery data to enable FEC, carousel, interleaving which implies easily identifiable segmentation of delivery data to
and other schemes possible; effective identification of metadata sets enable FEC, carousel, interleaving and other schemes possible;
(probably uniquely) to enable more efficient use of multicast and effective identification of metadata sets (probably uniquely) to
unicast retrieval over multiple access systems regardless of the enable more efficient use of multicast and unicast retrieval over
parts of metadata and application specific extensions in use; multiple access systems regardless of the parts of metadata and
prioritization of metadata, which can (for instance) be achieved by application specific extensions in use; prioritization of metadata,
spreading it between channels and allocating/distributing bandwidth which can (for instance) be achieved by spreading it between channels
accordingly. and allocating/distributing bandwidth accordingly.
Furthermore, some cases require IMG metadata authentication and some Furthermore, some cases require IMG metadata authentication and some
group security/encryption and supporting security message exchanges group security/encryption and supporting security message exchanges
(out of band from the IMG multicast sessions). (out of band from the IMG multicast sessions).
4.1.2 Regular Fixed Dial-up Internet Connection 4.1.2 Regular Fixed Dial-up Internet Connection
Dial-up connections tend to be reasonably slow (<56kbps in any case) Dial-up connections tend to be reasonably slow (<56kbps in any case)
and thus large data transfers are less feasible, especially during an and thus large data transfers are less feasible, especially during an
active application session (such as a file transfer described by IMG active application session (such as a file transfer described by IMG
skipping to change at page 8, line 50 skipping to change at page 9, line 7
Typically bandwidth is less of an issue to a broadband user and Typically bandwidth is less of an issue to a broadband user and
unicast transport, such as using query-response methods, may be unicast transport, such as using query-response methods, may be
typical for a PC user. If a system were only used in this context, typical for a PC user. If a system were only used in this context,
with content providers, ISPs and users having no other requirements, with content providers, ISPs and users having no other requirements,
then web- based browsing may be equally suitable. However, broadband then web- based browsing may be equally suitable. However, broadband
users sharing a local area network, especially wireless, may benefit users sharing a local area network, especially wireless, may benefit
more from local storage features than on-line browsing, especially if more from local storage features than on-line browsing, especially if
they have intermittent Internet access. they have intermittent Internet access.
Broadband enables rich media services, which are increasingly Some services on broadband, such as live media broadcasting, benefit
bandwidth hungry. Thus backbone operators may prefer multicast from multicast transport for streaming media because of scalability.
communications to reduce overall congestion, if they have the In the cases where multicast transport is already available, it is
equipment and configuration to support this. Thus, broadband users convenient for a sender and receiver to retrieve IMG metadata over
may be forced to retrieve IMG metadata over multicast if the multicast transport. Thus, broadband users may be forced to retrieve
respective operators require this to keep system-wide bandwidth usage IMG metadata over multicast if backbone operators require this to
feasible. keep system-wide bandwidth usage feasible.
4.2 Content-orientated Use Cases 4.2 Content-orientated Use Cases
IMGs will be able to support a very wide range of use cases for IMGs will be able to support a very wide range of use cases for
enabling content/media delivery. The following few sections just enabling content/media delivery. The following few sections just
touch the surface of what is possible and are intended to provide an 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 understanding of the scope and type of IMG usage. Many more examples
may be relevant, for instance those detailed in [11]. There are may be relevant, for instance those detailed in [12]. There are
several unique features of IMGs that set them apart from related several unique features of IMGs that set them apart from related
application areas such as SLP based service location discovery, LDAP application areas such as SLP based service location discovery, LDAP
based indexing services and search engines such as Google. Features based indexing services and search engines such as Google. Features
unique to IMGs include: unique to IMGs include:
o IMG metadata is generally time-related o IMG metadata is generally time-related
o There are timeliness requirements in the delivery of IMG o There are timeliness requirements in the delivery of IMG
metadata metadata
skipping to change at page 13, line 48 skipping to change at page 14, line 5
REQ CUS-1: The system MUST allow delivery of customized IMG metadata. REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
The IMG receiver may require a subset of all the IMG metadata The IMG receiver may require a subset of all the IMG metadata
available according to their preferences (type of content, media available according to their preferences (type of content, media
description, appropriate age group, etc.) and configuration. description, appropriate age group, etc.) and configuration.
The IMG receiver might send its preferences in the IMG operations The IMG receiver might send its preferences in the IMG operations
which can specify user specific IMG metadata to be delivered. These which can specify user specific IMG metadata to be delivered. These
preferences could consist of filtering rules. When receiving these preferences could consist of filtering rules. When receiving these
messages, the IMG sender might respond appropriate messages carrying messages, the IMG sender might respond with appropriate messages
a subset of IMG metadata which matches the IMG receiver's carrying a subset of IMG metadata which matches the IMG receiver's
preferences. preferences.
This mechanism can reduce the amount of IMG metadata delivered from This mechanism can reduce the amount of IMG metadata delivered from
the IMG sender to IMG receiver, and consequently it can save the the IMG sender to IMG receiver, and consequently it can save the
resource consumption on the IMG entities and networks. It is resource consumption on the IMG entities and networks. It is
typically useful in unicast cases and also beneficial in multicast typically useful in unicast cases and also beneficial in multicast
cases where an IMG sender distributes the same IMG metadata to cases where an IMG sender distributes the same IMG metadata to
interested IMG receivers at the same time. interested IMG receivers at the same time.
For multicast and unicast cases where the IMG sender does not provide For multicast and unicast cases where the IMG sender does not provide
skipping to change at page 15, line 10 skipping to change at page 15, line 16
particular IMG receiver has an up-to-date copy of the IMG metadata. particular IMG receiver has an up-to-date copy of the IMG metadata.
In the synchronized model, updating a cached copy of the IMG metadata In the synchronized model, updating a cached copy of the IMG metadata
is necessary to control consistency when the IMG sender or receiver is necessary to control consistency when the IMG sender or receiver
could not communicate for a while. In this case, the IMG sender or could not communicate for a while. In this case, the IMG sender or
receiver may need to confirm its consistency by IMG operations. receiver may need to confirm its consistency by IMG operations.
REQ REL-2: Since IMG metadata can change at any time, IMG receivers REQ REL-2: Since IMG metadata can change at any time, IMG receivers
SHOULD be notified of such changes. SHOULD be notified of such changes.
Fulfilling this requirements needs to be compatible with the
scalability requirements for the number of IMG receivers and the
consistency of metadata.
Depending on the size of the guide, the interested party may want to Depending on the size of the guide, the interested party may want to
defer retrieving the actual information. The change notification defer retrieving the actual information. The change notification
should be addressed to a logical user (or user group), rather than a should be addressed to a logical user (or user group), rather than a
host, since users may change devices. host, since users may change devices.
Note that depending on the deployment environment and application Note that depending on the deployment environment and application
specifics, the level of acceptable inconsistency varies. Thus, this specifics, the level of acceptable inconsistency varies. Thus, this
document does not define inconsistency as specific time and state document does not define inconsistency as specific time and state
differences between IMG metadata stored in an IMG sender and IMG differences between IMG metadata stored in an IMG sender and IMG
metadata stored in an IMG receiver. metadata stored in an IMG receiver.
skipping to change at page 19, line 13 skipping to change at page 19, line 21
REQ ACC-3: It MUST be possible to require different authorization for REQ ACC-3: It MUST be possible to require different authorization for
different parts of the same IMG metadata. different parts of the same IMG metadata.
REQ ACC-4: It MUST be possible to access selected IMG metadata REQ ACC-4: It MUST be possible to access selected IMG metadata
anonymously. anonymously.
REQ ACC-5: It MUST be possible for an IMG receiver to choose not to REQ ACC-5: It MUST be possible for an IMG receiver to choose not to
receive (parts of) IMG metadata in order to avoid being identified by receive (parts of) IMG metadata in order to avoid being identified by
the IMG sender. the IMG sender.
REQ ACC-6: It SHOULD be possible for IMG transceiver to impose REQ ACC-6: It SHOULD be possible for an IMG transceiver to select
different authorization requirements. suitable authorization methods which are compatible between both
IMG senders and IMG receivers it interacts with.
REQ ACC-7: It MAY be possible for IMG senders to require certain REQ ACC-7: It MAY be possible for IMG senders to require certain
authorization that cannot be overridden by intermediaries. authorization that cannot be modified by intermediaries.
6.4 Denial-of-Service attacks 6.4 Denial-of-Service attacks
Retrieving or distributing IMG metadata may require state in the IMG Retrieving or distributing IMG metadata may require state in the IMG
senders, transceivers, and/or receivers for the respective IMG senders, transceivers, and/or receivers for the respective IMG
transport sessions. Attackers may create large numbers of sessions transport sessions. Attackers may create large numbers of sessions
with any of the above IMG entities to disrupt regular operation. with any of the above IMG entities to disrupt regular operation.
REQ DOS-1: IMG operations SHOULD be authenticated. REQ DOS-1: IMG operations SHOULD be authenticated.
REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up
session state in IMG entities to exhaust their resources. session state in IMG entities to exhaust their resources.
REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust
resources of IMG entities by flooding them with IMG metadata. resources of IMG entities by flooding them with IMG metadata.
As an example, two potential solutions which may be considered are As an example, two potential solutions which may be considered are
running an IMG entity in stateless mode or identification and running an IMG entity in stateless mode or identification and
discarding of malicious packets by an IMG entity. discarding of malicious packets by an IMG entity.
6.5 Replay Attacks 6.5 Replay Attacks
skipping to change at page 20, line 16 skipping to change at page 20, line 25
attacks and delivery of inconsistent data requires that an IMG attacks and delivery of inconsistent data requires that an IMG
receiver veryfies that the IMG metadata is valid and reliable by receiver veryfies that the IMG metadata is valid and reliable by
using some security mechanism(s) (e.g. authorization, authentication using some security mechanism(s) (e.g. authorization, authentication
or integrity). or integrity).
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
the IMG operations. the IMG operations.
The level of threat from replay attacks varies very much depending on The level of threat from replay attacks varies very much depending on
system scale and how well defined or open it is. Thus mitigating system scale and how well defined or open it is. Thus mitigating
relay attacks may lead to different solutions for different systems, replay attacks may lead to different solutions for different systems,
independent of the basic delivery method and metadata definitions. A independent of the basic delivery method and metadata definitions. A
system with multiple senders presents a more challenging scenario for system with multiple senders presents a more challenging scenario for
handling replay attacks. As an example, bundling metadata with a handling replay attacks. As an example, bundling metadata with a
security mechanism is one potential solution. security mechanism is one potential solution.
7 IANA Considerations 7 IANA Considerations
There are no IANA considerations within this document. This document does not request any IANA action.
8 Normative References 8 Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," RFC 2119, Internet Engineering Task Force, March 1997.
9 Informative References 9 Informative References
[2] M. Handley and V. Jacobson, "SDP: session description protocol," [2] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, April 1998.
[3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement [3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. protocol," RFC 2974, Internet Engineering Task Force, October 2000.
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ [4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[5] Session Directory Tool, [5] Session Directory Tool,
http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/ http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/
[6] Digital Video Broadcasting Project,
http://www.dvb.org/
[6] D. Kutscher, J. Ott, and C. Bormann, "Session description and [7] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Internet Engineering Task Force, Oct. 2003. Work in progress. Internet Engineering Task Force, October 2003. Work in progress.
[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[8] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, [9] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne,
"A framework for the usage of Internet media guides," Internet Draft "A framework for the usage of Internet media guides," Internet Draft
draft-ietf-mmusic-img-framework-07, Internet Engineering Task Force, draft-ietf-mmusic-img-framework-09, Internet Engineering Task Force,
June 2004. Work in progress. December 2005. Work in progress.
[9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. [10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P.
Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999. RFC 2616, Internet Engineering Task Force, June 1999.
[10] A. B. Roach, "Session initiation protocol (sip)-specific event [11] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002. notification," RFC 3265, Internet Engineering Task Force, June 2002.
[11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges [12] B. Quinn and K. Almeroth, "IP multicast applications: Challenges
and solutions," RFC 3170, Internet Engineering Task Force, Sept. and solutions," RFC 3170, Internet Engineering Task Force, September
2001. 2001.
10 Acknowledgements 10 Acknowledgements
The authors would like to thank Colin Perkins, Jean-Pierre Evain, The authors would like to thank Hitoshi Asaeda, Gonzalo Camarillo,
Gonzalo Camarillo, Magnus Westerlund, Hitoshi Asaeda, Petri Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins,
Koskelainen, Toni Paila and Dirk Kutscher for their excellent Toni Paila and Magnus Westerlund for their excellent comments and
comments and ideas on this work. ideas on this work.
11 Authors' Addresses 11 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan Japan
Email: nom@flab.fujitsu.co.jp Email: nom@flab.fujitsu.co.jp
Rod Walsh Rod Walsh
skipping to change at page 22, line 14 skipping to change at page 22, line 26
Email: jo@tzi.uni-bremen.de Email: jo@tzi.uni-bremen.de
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
12 Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1059 skipping to change at page 23, line 4
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 45 change blocks. 
99 lines changed or deleted 97 lines changed or added

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