[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                                 Y. Nomura
                                                           Fujitsu Labs.
                                                                R. Walsh
                                                               H. Asaeda
                                                          H. Schulzrinne
                                                     Columbia University
June 30, 2003
Expires: December 2003

           A Framework for the Usage of Internet Media Guides


   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-

   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

   To view the list Internet-Draft Shadow Directories, see


   This document defines a framework for the delivery of Internet Media
   Guides (IMGs). A media guide is a set of information (metadata)
   describing the features of multimedia content in order to subscribe
   to, manage and exchange multimedia content.

   Several protocols and methods exist that are able to deliver metadata
   over the Internet, giving information on Internet services, media and
   content. This existing knowledge is used to provide a general
   framework for Internet Media Guides and outlines existing scalability

Y. Nomura et. al.                                             [Page 1]

Internet Draft               IMG Framework                 June 30, 2003

   and flexibility issues, along with the desirable features that can
   solve these problems.

Table of Contents

   1          Introduction ........................................    3
   2          Terminology .........................................    3
   3          Problem Statement ...................................    4
   3.1        Prior Methods for Server-Client Scenario ............    4
   3.1.1      Web-based Media Guide Browsing ......................    5
   3.1.2      Multicasting a Media Guide ..........................    5
   3.1.3      Possible Solutions ..................................    8
   3.2        Prior Methods for Server-Server Scenarios ...........    8
   3.2.1      Content Distribution Internetworking (CDI) ..........    8
   3.2.2      Web Intermediary (WEBI) .............................    9
   3.3        IETF Protocols ......................................    9
   3.3.1      HTTP ................................................    9
   3.3.2      FTP .................................................   10
   3.3.3      SAP .................................................   10
   3.3.4      SIP for Event Notification ..........................   11
   4          IMG Common Framework Model ..........................   12
   4.1        IMG Data-Type .......................................   12
   4.1.1      Complete Description ................................   12
   4.1.2      Delta Description ...................................   13
   4.1.3      Pointer .............................................   13
   4.2        Operation Set for IMG Delivery ......................   13
   4.2.1      IMG ANNOUNCE ........................................   13
   4.2.2      IMG QUERY ...........................................   14
   4.2.3      IMG RESOLVE .........................................   14
   4.2.4      IMG SUBSCRIBE .......................................   14
   4.2.5      IMG NOTIFY ..........................................   14
   4.3        IMG Entities ........................................   15
   4.4        Overview of Protocol Operations .....................   16
   5          Deployment Scenarios for IMG Entities ...............   16
   5.1        One-to-many Unidirectional Multicast ................   17
   5.2        One-to-one Bi-directional Unicast ...................   18
   5.3        Combined Operations with Common Metadata ............   19
   6          Use case Requiring IMG Framework ....................   20
   6.1        IP Datacast to a Wireless Receiver ..................   20
   6.2        Regular fixed dial-up Internet Connection ...........   21
   6.3        Broadband Always-on Fixed Internet Connection .......   21
   7          Security Considerations .............................   21
   8          Bibliography ........................................   22
   9          Acknowledgements ....................................   24
   10         Author's Addresses ..................................   24

Y. Nomura et. al.                                             [Page 2]

Internet Draft               IMG Framework                 June 30, 2003

1 Introduction

   An Internet Media Guide (IMG) is a collection of multimedia session
   descriptions expressed using SDP, SDPng or some similar session
   description format. It is used to describe a collection of multimedia
   sessions (e.g. television programmed schedules). IMGs 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.

   This document is the result of investigating work on delivery
   mechanisms for IMGs and generalizing work on session announcement and
   initiation protocols, especially in the field of the IETF-MMUSIC
   working group (SAP[1], SIP[2], SDP[3]).

   Firstly, 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 problems
   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. These issues
   and related problems with existing protocols are clarified in this

   Then, this document defines a generalized model for IMG delivery
   mechanisms and their deployment in network entities with reference to
   existing protocols. 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.

2 Terminology

   SHOULD NOT, RECOMMENDED, MAY, and "OPTIONAL" in this document are to
   be interpreted as described in RFC 2119 [4].

        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.

Y. Nomura et. al.                                             [Page 3]

Internet Draft               IMG Framework                 June 30, 2003

        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 sender.

        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.

3 Problem Statement

   The MMUSIC working group has long been investigating content, media
   and service information delivery mechanisms and protocols, and has
   itself produces Session Announcement Protocol (SAP), Session
   Description Protocol (SDP) and Session' Initiation Protocol (SIP)
   which, among other things, are protocols to distribute metadata about
   multicast session information. Also in the IETF, HTTP is a well-known
   information retrieval protocol using bi-directional transport and
   widely used to deliver metadata to many hosts.

   However, when the number of services, content and the receivers
   becomes huge, we need a more scalable protocol for the metadata
   delivery. In addition, comparing with other type of data, metadata
   tends to change quite often, therefore an effective mechanism to
   update the metadata is also required.

   Although these protocols are widely used in the Internet they
   mismatch our demands for scalable and flexible information
   distribution in terms of the large amounts of metadata and a huge
   number of receivers.

3.1 Prior Methods for Server-Client Scenario

   There are three elementary scenarios for media delivery for server-
   client models: Web-based Media Guide; Multicasting a Media Guide;
   Fetching a Media Guide by Unicast. Each of these is described below.
   The list is not intended to be exhaustive, but instead it is to give
   a good foundation in the important types of media delivery mechanisms
   in current usage.

   For all these scenarios, it is assumed that there are a number of
   suitable (e.g. multicast and broadcast) services available and
   interested user groups having terminals capable of receiving the

   The IETF has previously standardized a number of protocols that are
   relevant to the above scenarios. These are also briefly considered

Y. Nomura et. al.                                             [Page 4]

Internet Draft               IMG Framework                 June 30, 2003


3.1.1 Web-based Media Guide Browsing

   A common Internet-world approach to discovering multicast - and
   unicast - streaming media is to access web pages. These web pages
   describe and categorize services in sufficient detail for the user,
   and provide links to machine-readable files that provide enough
   session and media parameters for client applications to access the
   streaming service over a suitable IP network.

   This scenario tends to be a human-oriented mechanism because the web
   already provides appropriate infrastructure for human-oriented
   information delivery and it is easy to deploy this technique.
   However, this technique strongly depends on a web-based system,
   namely client-driven delivery and a human readable data model for
   browsing and selection.

   Whenever a web client requires updated web pages, the client has to
   reload the web page using the same URL. For mass media, the large
   number of users polling a server causes scalability and congestion
   concerns and so the technique is feasible only if the period between
   reloadings is long and the amount of a media guide metadata or the
   number of users is small. A well-behaved implementation significantly
   limits the timeliness of receiver-side updates for mass audiences.

   In any Internet access situation where there is a premium for
   always-on connectivity, the need to keeping many point-to-point
   sessions active merely for the purposes of browsing current and
   future services may cause severe scalability concerns for the
   distribution of resources. This is especially true of wireless
   systems with finite, and potentially expensive, radio resources.

   Additionally, this does not easily enable off-line reading of media
   metadata. So finding the service descriptions for content that is
   already delivered and locally stored becomes problematic. As does
   browsing descriptions of available services at a future destination
   and time, especially for multi-homing and mobile users. For these
   kinds of use cases, an off-line storage of service descriptions is
   necessary, and effective separation, filtering and maintenance of
   this descriptive metadata is needed to keep the local storage at a
   reasonable finite size.

3.1.2 Multicasting a Media Guide

   A common broadcast-world (TV and radio) approach to discovering one-
   to-many services is to push descriptions of streaming services to the
   user terminals. Often this is done by means of data carousels that

Y. Nomura et. al.                                             [Page 5]

Internet Draft               IMG Framework                 June 30, 2003

   repeat the same set of service information at known or predictable
   intervals. The repetition provides some robustness (i.e. tolerates
   some errors in transmission) and enables receivers that are
   switched-on later than the first service information transmission to
   collect the full media guide - or at least the parts they are
   interested in. In addition to carouselling the information, it is
   also a common idea to notify of updates and delivery of changed
   service information on-demand based on the changed event.

   The primary advantage of this scheme is its massive scalability. No
   uplink signaling is necessary and the user group size (for the media
   guide) is unlimited. The downlink is more efficient than web-based
   access on the broadcast radio as all receivers, which do not stay in
   a power-saving mode, are able to receive the data simultaneously
   using just one shared logical and physical link channel. However, to
   prevent the downlink bandwidth usage from exploding, the service
   information that is broadcast is fine-tuned according to the system
   (for instance, this may be different for broadband and narrowband
   users). Only the essential information is mandatory. Concise
   information may be transmitted frequently and verbose information
   infrequently. Therefore, the effect is a reasonable balance between
   user and control data on the downlink radio channel.

   Receivers may remain actively receiving for as long as desirable to
   collect the service information, although it is common practice to
   switch the communications interface to an idle, or sleep, mode once
   the initial media guide is cached and only periodically reconnect to
   a session for updates. Thus power-saving techniques are feasible, and
   more effective, when the time of interesting service information
   transmission is known in advance.

   In the case of extremely small user groups, the repetition of service
   information transmission in the downlink may cause more traffic than
   separate individual connections to the sender. In this case, the
   carousel method is not optimal and an on-demand multicast push or
   unicast fetch may be more efficient.

   There are a few disadvantages to these multicast schemes too. There
   may be a significant delay before the interesting information is
   transmitted. The information may be brief as verbose descriptions
   would be unnecessary in most cases. The information is targeted at a
   group and may not be well tuned to the wishes of an atypical user.

   The IETF has developed two protocols for these kinds of applications.
   SAP (version 2) and SDP are typically used to announce session
   descriptions by multicast. SAP is the transport protocol over UDP/IP
   and SDP is the description syntax for basic media and session
   information. Both of these are independent such that, for example,

Y. Nomura et. al.                                             [Page 6]

Internet Draft               IMG Framework                 June 30, 2003

   SAP would be used to transport some other description syntax and SDP
   could be delivered over some other transport protocol. The deployment
   of SDP is increasing as it is also used with SIP. However, the
   deployment of SAP is limited and it remains at the experimental
   standard status.

   SDP has a text-encoded syntax that is extensible but has well
   recognized limitations. These are mostly overcome by the XML-based
   SDPng[5] , which is intended for both two-way negotiation and also
   unidirectional delivery.

   SAP has a bit-encoded header and includes details of bandwidth
   control by transmission frequency. SAP also has several know
   limitations and, especially, robustness or reliability, payload size
   and packing, bandwidth control, prioritization of
   metadata/descriptions and authentication are either lacking or
   performed in an unusual or unusable way for many applications.

   Both SDP and SAP are products of the MMUSIC working group of the
   IETF. There are no other current IETF standards that solve these
   kinds of problems.

   Tailoring multicast (and unicast) push-type delivery requires server
   configuration facilitated by some kind of control messaging between
   client and server. In the case of multicast, the crudest method is to
   preconfigure multicast channels (or groups) with well-known subsets
   of data at the sender and simply allow receivers to joining to the
   relevant multicast groups (using MLD [6] or IGMP[7] for IP versions 6
   and 4 respectively). The most significant limitation of this is
   making the content well known. For instance, knowing in advance
   exactly which metadata/descriptors will be updated in the future is
   infeasible in most cases. This can be refined by making the type of
   content well known so, for instance, a certain multicast channel
   might contain metadata updates only relating to sports channel
   services in the next hour.

   The unicast equivalent of this is to maintain a unicast
   connection/session between sender and receiver for the whole time a
   receiver is interested in a service. This may be feasible in many
   fixed-line systems for servers with only a few receivers, but both of
   these become less attractive for both wireless links and large
   numbers sender-receiver connections, especially as both of these
   share a resource (the radio bandwidth or the server resources) and
   thus limit the number of receivers which can be served, without
   additional infrastructure investment.

   More finely grained control would be to provide push content
   categorized for multicast and individual, or categorized, for

Y. Nomura et. al.                                             [Page 7]

Internet Draft               IMG Framework                 June 30, 2003

   unicast, and use a control methods separated from the data delivery.
   This can be facilitated by SIP or remote procedure call techniques
   using SOAP[8] , CORBA[9] or ONC-RPC[10], among others.

3.1.3 Possible Solutions

   Fetching media descriptions by unicast from the network is a
   compromise, which enables personalized media guides that are
   available off-line. Used alone, it is subject to similar scalability
   issues as web-based media guides. However, it is well suited to being
   used in combination with update notification by unicast or multicast
   push so that the correct balance of scalability and personalization
   of service guides can be made for the application and network
   environment in question. This technique is feasible with current
   protocols although not widely implemented, unlike web-base media

   This also requires the use of consistently defined and identified
   atomic metadata, which can be selected, delivered and maintained
   regardless of the exact transport(s) used to get it to the receiver.
   It would also benefit from a consistent metadata structure and syntax
   to aid storage and rendering on the receiver.

   Scalability may be increased further by the selective use of update
   and notifications. An update would provide only the changed metadata
   and a notification would notify a receiver that there has been a
   change in metadata and would allow the receiver to decide on whether
   it needs to receive or fetch that. Notifications are a common
   technique in multiparty conferencing where users first subscribe to
   the service and then are notified that they may participate. The use
   of asynchronous notification allows users to subscribe in advance to
   the service and be notified of the event as it occurs.

   Fetching an object over IP is a well-standardized and deployed
   activity. Primarily either HTTP[11] or FTP[12] is used over TCP/IP.
   Metadata syntax describing media is mostly concentrated on
   enhancements to SDP and SDPng (although other schemes such as XML-
   based MPEG7[13] and TVAnytime [14] are deployable - also for
   multicast metadata).

3.2 Prior Methods for Server-Server Scenarios

3.2.1 Content Distribution Internetworking (CDI)

   The IETF CDI-WG has been investigating an architecture of network
   elements, arranged for efficient delivery of digital content. CDI[15]
   is a concept including request routing, the distribution and the
   accounting techniques. Among those entities, the distribution

Y. Nomura et. al.                                             [Page 8]

Internet Draft               IMG Framework                 June 30, 2003

   techniques are related to IMG framework.

   The unpublished distribution requirement document in CDI-WG tried to
   specify interconnecting, or peering, the distribution systems of
   Content Networks (CN). Distribution internetworking requires
   advertising the capabilities of a CN offering distribution services,
   moving content from one CN to another, and signaling requirements for
   consistent storage and delivery of content.

   According to CDI-WG definitions, content signaling is a mechanism
   between CNs to propagate content metadata. The metadata includes
   information such as the immediate invalidation of content or a change
   in the sender or distribution method of content[16] .

   This work considered parts of an IMG-like framework, although it
   focused only in the server-to-server internetworking scope. However,
   CDI-WG did not publish the requirement draft nor any protocols to
   solve the problems.

3.2.2 Web Intermediary (WEBI)

   The WEBI-WG in the IETF tried to define a new protocol named Resource
   Update Protocol (RUP)[17] to achieve cache coherence in web
   intermediary systems such as caching proxies and surrogates.
   Therefore, the target system in WEBI-WG is a content cache network
   consisting of caching entities. The target problem was to maintain
   consistency in an environment where periodic revalidation is
   unacceptable in terms of performance and/or cache consistency.

   In addition, the scope of RUP included an updating mechanism for
   metadata, which described content cache set.

   However, WEBI-WG was closed without standardizing any protocol
   document to solve the problems. The WEBI-WG problem definition is
   also partly valid for an IMG framework and so may be reused,
   especially in server-to-server scenarios.

3.3 IETF Protocols

3.3.1 HTTP

   For the metadata distribution model, a HTTP client requests an object
   (file containing metadata) by sending "GET Request", then the
   metadata sender replies "GET Response" including the metadata in its

   When the client wants to keep metadata up-to-date, the client must
   reissue "GET Request" to the sender and obtain "GET Response" in

Y. Nomura et. al.                                             [Page 9]

Internet Draft               IMG Framework                 June 30, 2003

   order to avoid metadata becoming stale.

   The mechanism has two major problems in terms of scalability and

        1.   Since the client can not know when metadata changes, the
             client must poll "GET Requests" to the metadata sender
             periodically. This can overload the metadata sender with
             unnecessary request messages, especially when the number of
             clients high. Therefore, this approach has a scalability

        2.   To decrease the load on the metadata sender, the client
             must wait to send the request message for considerably long
             period. It makes metadata inconsistent between the sender
             and client when metadata changes during the client wait.

3.3.2 FTP

   FTP is a client-server type protocol that is widely used. The
   protocol aims to provide a control mechanism necessary for a file
   transfer.  This protocol simply consists of control messages, all of
   which are initiated by the client. Thus, regarding the IMG delivery,
   the protocol has the same drawbacks as HTTP. Additionally, since this
   protocol depends on the file managing structure and file unit, there
   is no means to a delta description and pointer operation, which we
   discuss later.

3.3.3 SAP

   The session information can be described using the Session
   Description Protocol (SDP). SDP describes valuable metadata
   information including session name, session time, sender and
   multicast addresses, format of the media, etc., and the information
   becomes the key to join the session.

   SDP is text-based and extensible using a number of different options,
   which can cause interoperability concerns for parser implementations
   in ensuring all variations are supported. This is symptomatic of no
   clear separation between application-specific descriptors and common
   delivery-enabling descriptors. Furthermore, SDP does not give the
   naturally hierarchical syntax nor many of the advanced features that
   XML-based descriptors have to offer.

   SDP is widely deployed although there is a consensus in the IETF
   MMUSIC-WG (the home of SDP), that it should become obsoleted by a
   transition to the XML-based SDPng, which is a work-in-progress.

Y. Nomura et. al.                                            [Page 10]

Internet Draft               IMG Framework                 June 30, 2003

   SDP does not specify how the information is transported. This is the
   role of the Session Announcement Protocol (SAP). When the multicast
   application starts sending session data, the sender announces its
   media-specific information to prospective participants using SAP.
   Therefore, although SAP is currently one of the necessary components
   of a session announcement system based on the announcement model,
   whenever a session is deleted or modified, SAP messages multicast
   similarly to keep all the session directory instances synchronized.
   Such periodic session announcements cause scalability problems when
   the number of sessions increases. Additionally, since the SAP
   announcements use the standard non reliable best-effort UDP/IP
   semantics, improving SAP robustness in front of packet losses
   requires transmitting the messages several times.

   As another concern, SAP communication assumes that the whole network
   establishes traditional many-to-many multicast communication, called
   Any-Source Multicast (ASM), since it is required by the fact that
   every data sender becomes a source of the SAP announcement group.
   Nowadays Source-Specific Multicast (SSM) [18] realized by IGMPv3[7]
   and MLDv2[19] is recognized as the a feasible multicast communication
   model for a wide use throughout the Internet, as it eliminates many
   complexities associated with the traditional ASM communication model.
   If we can conceive that some Internet Service Providers would support
   or permit only SSM because of its scalability advantages, avoiding a
   multicast session directory that relies on the ASM model is more

3.3.4 SIP for Event Notification

   SIP is a text-based request/response protocol. A SIP request consists
   of a request-line, header field and message body like HTTP. A SIP
   response also consists of a status-line, header field and body.

   A SIP Event[20] has the same features as SIP but a SIP Event needs
   only two messages, SUBSCRIBE and NOTIFY, to notify subscribers of an
   event. Since the protocol intends to do this, it does not require SIP
   messages to establish a session.  The following diagram shows basic
   protocol operations in a SIP Event.

           Subscriber          Notifier
               |-----SUBSCRIBE---->|     Request state subscription
               |<-------200--------|     Acknowledge subscription
               |<------NOTIFY----- |     Return current state information
               |<------NOTIFY----- |     Return current state information

Y. Nomura et. al.                                            [Page 11]

Internet Draft               IMG Framework                 June 30, 2003

   A SIP Event can notify update information, however there is no
   standard protocol using SIP Event in order to carry metadata and
   update information about metadata.

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
          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

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.

Y. Nomura et. al.                                            [Page 12]

Internet Draft               IMG Framework                 June 30, 2003

   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

4.2 Operation Set for IMG Delivery


   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-

   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

Y. Nomura et. al.                                            [Page 13]

Internet Draft               IMG Framework                 June 30, 2003

   IMG ANNOUNCE operation.


   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.


   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
   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.


   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 notifications. Since the IMG
   receiver doesn't know when metadata will be updated and the
   notification will arrive, this operations does not synchronize with
   the notification. The IMG receiver may wait for the notification for
   a long time. The IMG sender may authenticate the IMG receiver to
   investigate whether an IMG SUBSCRIBE operation is from an authorized


   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

Y. Nomura et. al.                                            [Page 14]

Internet Draft               IMG Framework                 June 30, 2003

   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

   Finally, the figure 1 shows a relationship between IMG entities and
   the IMG sender and receiver.

        |                      IMG Sender                        |
        |  IMG Announcer   |   IMG Resolver   |    IMG Notifier  |
                |                    ^                  ^
   message      |                    |                  |
   direction    v                    v                  v
        |   IMG Listener   |   IMG Querier    |  IMG Subscriber  |
        |                      IMG Receiver                      |

               Figure 1: Relationship with IMG Entities

Y. Nomura et. al.                                            [Page 15]

Internet Draft               IMG Framework                 June 30, 2003

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

    IMG        |                                                  |
    Data-type  |       Complete Desc., Delta Desc., Pointer       |
               |                                                  |
    Operations |                   |  IMG NOTIFY    | IMG RESOLVE |
    IMG        |              |                                   |
    Transport  |   P-to-M     |              P-to-P               |
               |              |                                   |

                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

Y. Nomura et. al.                                            [Page 16]

Internet Draft               IMG Framework                 June 30, 2003

   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[15] (CDNs). Existing CDNs may carry
   IMGs. Satellite and peer-to-peer networks may also carry IMGs.

        +----------+                                    +----------+
        | IMG      |                                    | IMG      |
        | Sender   |----                           ---->| Receiver |
        +----------+    \                         /     +----------+
                         \                       /
             .            \   +-----------+     /            .
             .             -->|IMG        |-----             .
             .             -->|Transceiver|     \            .
                          /   +-----------+      \
        +----------+     /                        \     +----------+
        | IMG      |    /                          ---->| IMG      |
        | Sender   |----                                | Receiver |
        +----------+                                    +----------+

            Figure 4: A Relay Network with an IMG Transceiver

   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.

5.1 One-to-many Unidirectional Multicast

Y. Nomura et. al.                                            [Page 17]

Internet Draft               IMG Framework                 June 30, 2003

   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

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

Y. Nomura et. al.                                            [Page 18]

Internet Draft               IMG Framework                 June 30, 2003

             +----------+                   +------------+
             |          |<-------(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.

    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

Y. Nomura et. al.                                            [Page 19]

Internet Draft               IMG Framework                 June 30, 2003

6 Use case Requiring IMG Framework

6.1 IP Datacast to a Wireless Receiver

   IP Datacast is the delivery of IP-based services over broadcast
   radio.  Internet content delivery is therefore unidirectional in this
   case. However, there can be significant benefits from being able to
   provide rich media one-to-many services to such receivers.

   There are two main classes of receiver in this use case: fixed
   mains-powered; and mobile battery-powered. Both of these are affected
   by radio phenomena and so robust, or error-resilient, delivery is
   important. Carouselled metadata transfer provides a base level of
   robustness for an IP datacast based announcement system, although the
   design of carouseled 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

   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

   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

Y. Nomura et. al.                                            [Page 20]

Internet Draft               IMG Framework                 June 30, 2003

   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).

6.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).

6.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.

7 Security Considerations

   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

Y. Nomura et. al.                                            [Page 21]

Internet Draft               IMG Framework                 June 30, 2003

   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

   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
   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

   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

   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

8 Bibliography

Y. Nomura et. al.                                            [Page 22]

Internet Draft               IMG Framework                 June 30, 2003

   [1] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
   protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.

   [2] 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

   [3] M. Handley and V. Jacobson, "SDP: session description protocol,"
   RFC 2327, Internet Engineering Task Force, Apr. 1998.

   [4] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and
   capability negotiation," internet draft, Internet Engineering Task
   Force, Mar. 2003.  Work in progress.

   [6] S. E. Deering, W. Fenner, and B. Haberman, "Multicast listener
   discovery (MLD) for IPv6," RFC 2710, Internet Engineering Task Force,
   Oct. 1999.

   [7] B. Cain, S. E. Deering, I. Kouvelas, B. Fenner, and A.
   Thyagarajan, "Internet group management protocol, version 3," RFC
   3376, Internet Engineering Task Force, Oct. 2002.

   [8] N. Mitra, "Soap version 1.2 part 0: Primer," W3C working draft,
   World Wide Web Consortium (W3C), Dec. 2001.

   [9] Object Management Group, "Common Object Request Broker
   Architecture: Core Specification", Dec. 2002.

   [10] R. Srinivasan, "RPC: remote procedure call protocol
   specification version 2," RFC 1831, Internet Engineering Task Force,
   Aug. 1995.

   [11] 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.

   [12] J. B. Postel and J. F. Reynolds, "File transfer protocol," RFC
   959, Internet Engineering Task Force, Oct. 1985.

   [13] 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.

Y. Nomura et. al.                                            [Page 23]

Internet Draft               IMG Framework                 June 30, 2003

   [14] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum
   Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002.

   [15] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for
   content internetworking (CDI)," RFC 3466, Internet Engineering Task
   Force, Feb.  2003.

   [16] L. Amini et al., "Distribution requirements for content
   internetworking," internet draft, Internet Engineering Task Force,
   Dec.  2002.  Work in progress.

   [17] I. Cooper, D. Li, M. Dahlin, and M. Hamilton, "Requirements for
   a resource update protocol," internet draft, Internet Engineering
   Task Force, Mar.  2002.  Work in progress.

   [18] H. Holbrook and B. Cain, "Source-specific multicast for IP,"
   internet draft, Internet Engineering Task Force, May 2003.  Work in

   [19] R. Vida and L. Costa, "Multicast listener discovery version 2
   (mldv2) for IPv6," internet draft, Internet Engineering Task Force,
   June 2003.  Work in progress.

   [20] A. B. Roach, "Session initiation protocol (sip)-specific event
   notification," RFC 3265, Internet Engineering Task Force, June 2002.

9 Acknowledgements

   The authors would like to thank Joerg Ott, Juha-Pekka Luoma, Toni
   Paila and Petri Koskelainen on for their ideas and input to this

10 Author's Addresses

   Yuji Nomura
   Fujitsu Laboratories Ltd.
   4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
   Email: nom@flab.fujitsu.co.jp

   Rod Walsh
   Nokia Corporation
   Nokia Research Center
   P.O. Box 100, FIN-33721 Tampere
   Email: rod,walsh@nokia.com

   Hitoshi Asaeda

Y. Nomura et. al.                                            [Page 24]

Internet Draft               IMG Framework                 June 30, 2003

   Project PLANETE
   2004, Route des Lucioles, BP93,
   06902 Sophia Antipolis,
   Email: Hitoshi.Asaeda@sophia.inria.fr

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   Email: schulzrinne@cs.columbia.edu

   Full Copyright Statement

   Copyright (c) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Y. Nomura et. al.                                            [Page 25]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/