MMUSIC                                                          J. Luoma
Internet-Draft                                                     Nokia
Expires: April 26, 2004                                 October 27, 2003


    MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint
                               Transport
                    draft-luoma-mmusic-img-muppet-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2004.

Copyright Notice

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

Abstract

   This document defines MUPPET, a unidirectional point-to-multipoint
   transport protocol for the delivery of Internet Media Guide metadata.
   The MUPPET protocol is based on Asynchronous Layered Coding (ALC), a
   massively scalable protocol for reliable multicast transport. MUPPET
   is intended to be used with the Internet Media Guide framework, and
   in addition may be useful with other applications.









Luoma                    Expires April 26, 2004                 [Page 1]

Internet-Draft                   MUPPET                     October 2003


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
   2.     Conventions Used in This Document  . . . . . . . . . . . .   4
   3.     Terminology  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.     IMG Metadata Delivery Using MUPPET . . . . . . . . . . . .   7
   4.1    Complete IMG Descriptors . . . . . . . . . . . . . . . . .   7
   4.2    Delta IMG Descriptors  . . . . . . . . . . . . . . . . . .   8
   4.3    IMG Pointers . . . . . . . . . . . . . . . . . . . . . . .   8
   4.4    Environmental Considerations . . . . . . . . . . . . . . .   9
   5.     The MUPPET Protocol  . . . . . . . . . . . . . . . . . . .  10
   5.1    Use of MUPPET Sessions . . . . . . . . . . . . . . . . . .  10
   5.2    Use of MUPPET Channels . . . . . . . . . . . . . . . . . .  10
   5.3    Protocol Framing . . . . . . . . . . . . . . . . . . . . .  11
   5.4    Forward Error Correction . . . . . . . . . . . . . . . . .  12
   5.5    Payload Segmentation . . . . . . . . . . . . . . . . . . .  13
   5.6    Use of Congestion Control  . . . . . . . . . . . . . . . .  13
   5.7    Caching Support in IMG Proxies . . . . . . . . . . . . . .  13
   5.8    Authentication . . . . . . . . . . . . . . . . . . . . . .  13
   5.9    Encryption . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.10   Bootstrapping IMG Session (informative)  . . . . . . . . .  14
   5.10.1 Pilot Announcements  . . . . . . . . . . . . . . . . . . .  14
   5.10.2 Look-up Mechanisms . . . . . . . . . . . . . . . . . . . .  14
   5.10.3 Pre-configuration  . . . . . . . . . . . . . . . . . . . .  15
   6.     Security Considerations  . . . . . . . . . . . . . . . . .  16
   7.     Contributors . . . . . . . . . . . . . . . . . . . . . . .  17
   8.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  18
          Normative References . . . . . . . . . . . . . . . . . . .  19
          Informative References . . . . . . . . . . . . . . . . . .  21
          Author's Address . . . . . . . . . . . . . . . . . . . . .  21
          Intellectual Property and Copyright Statements . . . . . .  22




















Luoma                    Expires April 26, 2004                 [Page 2]

Internet-Draft                   MUPPET                     October 2003


1. Introduction

   This document defines MUPPET, a unidirectional point-to-multipoint
   transport protocol for the delivery of Internet Media Guide (IMG)
   metadata. The protocol defined in this specification is based on File
   Delivery over Unidirectional Transport (FLUTE) [4], a protocol for
   unidirectional file delivery. FLUTE builds on the Asynchronous
   Layered Coding (ALC) [5], a massively scalable transport protocol
   defined in Reliable Multicast Transport (RMT) Working Group of IETF.

   MUPPET is a protocol instantiation compliant with the Internet Media
   Guide Framework [3]. An Internet Media Guide (IMG) is a set of
   metadata describing content such as streaming media and downloadable
   files available to receivers. This document considers unidirectional
   point-to-multipoint (p-t-m) transmission of IMG metadata and defines
   a new transport protocol "MUPPET" for this purpose. The baseline of
   an IMG metadata format suited for delivery with MUPPET is defined in
   [8].

   The in-band delivery of parameters essential to the delivery of IMG
   information is in the scope of the current specification. The syntax
   and semantics of the IMG information carried within the payloads of
   MUPPET packets is outside the scope of this specification.




























Luoma                    Expires April 26, 2004                 [Page 3]

Internet-Draft                   MUPPET                     October 2003


2. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.














































Luoma                    Expires April 26, 2004                 [Page 4]

Internet-Draft                   MUPPET                     October 2003


3. Terminology

      Complete IMG Descriptor

         Provides a complete syntax and semantics to describe a set of
         metadata, which does not need any additional information from
         other IMG Descriptors. It may contain either the full set of
         metadata in the sender's IMG database or only a subset thereof.
         In addition to actual metadata, a Complete IMG Descriptor may
         also include references to IMG Descriptors that can only be
         accessed using some other delivery mechanism than MUPPET.

      Congestion Control

         IMG senders' functionality to control their transmission rate
         in a way that is fair to the network. The lack of a feedback
         channel from receivers on unidirectional access networks limits
         the use of congestion control for downlink data and eliminates
         the need for congestion control on the uplink.

      Delta IMG Descriptor

         Provides only part of a Complete IMG Descriptor, defining the
         difference from a previous version of the Complete IMG
         Descriptor in question. This descriptor may be used to reduce
         network resource usage for instance when small and frequent
         changes occur to Complete IMG Description. Thus, this
         descriptor itself cannot represent complete metadata set until
         it is combined with the corresponding Complete IMG
         Descriptor(s). In addition to actual metadata, a Delta IMG
         Descriptor may also include references to parts of metadata
         that can only be accessed using some other delivery mechanism
         than MUPPET.

      Forward Error Correction (FEC)

         FEC data is redundant information generated from payload data
         and delivered with it for transmission. The use of FEC allows
         receivers to reconstruct payload data segments lost or damaged
         due to transmission errors.

      MUPPET Channel

         Provides a delivery service for IMG Descriptors. A MUPPET
         channel is one of the following:

         1.  Complete Channel that delivers Complete IMG Descriptors.




Luoma                    Expires April 26, 2004                 [Page 5]

Internet-Draft                   MUPPET                     October 2003


         2.  Delta Channel that delivers Delta IMG Descriptors.

         3.  Pointer Channel that delivers IMG Pointers.

      IMG Descriptor

         A collection of IMG metadata - see [8]. There are the following
         subtypes of IMG Descriptors: Complete IMG Descriptor, Delta IMG
         Descriptor and IMG Pointer. MUPPET is a protocol providing a
         multicast transport service to IMG Descriptors.

      IMG Pointer

         Consists of one or more references, such as URLs, that the
         receiver is able to address specific metadata with. An IMG
         pointer may be used to separately obtain Complete or Delta IMG
         Descriptors, or perform another IMG management function such as
         data expiry and erasure.

      IMG Proxy

         IMG proxy is a combined IMG receiver and IMG sender that can
         filter from one or more IMG senders and output to one or more
         MUPPET sessions. Logically a proxy fits in between IMG senders
         and receivers. A proxy may also cache IMG metadata and may
         provide its own bandwidth control or congestion control schemes
         on the output.

      IMG Receiver

         A logical entity that receives IMG metadata from IMG sender(s).

      IMG Sender

         A logical entity that delivers IMG metadata to one or more IMG
         receivers. A (multicast) sender shall provide bandwidth control
         or congestion control schemes on the output.

      MUPPET Session

         A MUPPET session delivers the full or partial metadata of a
         single IMG from the sender to any number of receivers. A MUPPET
         session consists of one or more MUPPET channels.

      IMG Transceiver

         A combination of an IMG receiver and sender, potentially with
         protocol translation functionality.



Luoma                    Expires April 26, 2004                 [Page 6]

Internet-Draft                   MUPPET                     October 2003


4. IMG Metadata Delivery Using MUPPET

   The requirements and framework for Internet Media Guides (IMG) are
   described in [2] and [3], respectively. The following atomic
   operations needed for IMG metadata delivery are identified in [3] and
   briefly listed in the following.

   o  IMG ANNOUNCE: unsolicited delivery of IMG metadata.

   o  IMG QUERY: request to receive a delivery of IMG metadata.

   o  IMG RESOLVE: delivery of IMG metadata in response to an IMG QUERY.

   o  IMG SUBSCRIBE: request to receive notifications of changes in IMG.

   o  IMG NOTIFY: delivery of a change notification in response to an
      IMG SUBSCRIBE.

   The MUPPET protocol provides the IMG ANNOUNCE operation, with
   unidirectional transport for IMG Descriptors. Although the actual
   syntax and semantics of IMG Descriptors is outside the scope of this
   specification, for the purposes of the MUPPET protocol an IMG
   Descriptor is one of the following.

   o  Complete IMG Descriptor: a set of IMG metadata that does not need
      additional information from other IMG entities.

   o  Delta IMG Descriptor: provides a part of a Complete IMG
      Description, defining the difference from a previous version of
      the Complete IMG Description.

   o  IMG Pointer: provides a simple identifier or locator, such as a
      URL, that the receiver is able to reference specific metadata
      with.

   IMG senders MAY transmit all IMG Descriptors in carousel-style,
   periodically repeating the transmission of IMG Descriptors sent
   earlier that are still valid. This provides a level of error
   robustness and allows receivers that are switched on later than the
   initial transmission to receive the entire transmission - or at least
   the parts they are interested in. Determining the time interval
   between retransmissions is application specific and outside the scope
   of this document.

4.1 Complete IMG Descriptors

   A set of an IMG sender's metadata can be delivered to IMG receivers
   using a Complete IMG Descriptor, and the bandwidth efficiency may be



Luoma                    Expires April 26, 2004                 [Page 7]

Internet-Draft                   MUPPET                     October 2003


   further improved by the used Delta IMG Descriptors and/or IMG
   Pointers. A Complete IMG Descriptor may contain either the full or
   partial set of IMG metadata from a particular sender.

4.2 Delta IMG Descriptors

   The use of Delta IMG Descriptions enables receivers to discover
   changes in IMG metadata faster and allows reducing the retransmission
   rate of Complete IMG Descriptions. After obtaining a Complete IMG
   Description, an IMG receiver can remain up to date with changes in
   the corresponding IMG metadata by receiving just Delta IMG
   Descriptions, if available.

4.3 IMG Pointers

   In addition to sending Complete IMG Descriptions, either or both of
   IMG Pointers and Delta IMG Descriptions can be transmitted for the
   same IMG. Because IMG Pointers only carry references to metadata, IMG
   receivers must retrieve the actual metadata they need via other
   means, for example by receiving Complete or Delta IMG Descriptors
   using either MUPPET or some other IMG transport protocol.

   In the case of a fully unidirectional IMG announcement system, IMG
   receivers that have received the latest Complete IMG Descriptor of a
   particular IMG subsequently only need to receive IMG Pointers
   referring to changes in the same set of IMG metadata. Based on the
   received IMG Pointers, each IMG receiver may decide to obtain the
   Delta IMG Description or Complete IMG Description carrying the actual
   changed metadata.

   On an IMG announcement system that provides a return data path from
   each IMG receiver to the IMG sender, the following are examples of
   cases where IMG Pointers should be transmitted by IMG senders.

   o  No unidirectional metadata transfer: IMG metadata descriptors are
      never sent unsolicited to receivers but can be requested using a
      separate unicast IMG transport protocol.

   o  Unidirectional metadata transfer for IMG updates only if
      sufficient demand: IMG updates are only sent if enough clients
      indicate (via out-of-band means) that they wish to receive the
      updates.

   o  Unidirectional metadata transfer with bandwidth reduction:
      Complete IMG Descriptions and Delta IMG Descriptions are sent to
      clients much less frequently than IMG Pointers. IMG Pointers
      inform receivers that part of their IMG data is no longer valid -
      IMG receivers can either wait for an unsolicited delivery of IMG



Luoma                    Expires April 26, 2004                 [Page 8]

Internet-Draft                   MUPPET                     October 2003


      metadata via MUPPET or request an IMG update via a point-to-point
      IMG transport protocol.


4.4 Environmental Considerations

   Figure 1 shows an IMG usage scenario where a single IMG sender is
   delivering IMG metadata to a number of IMG receivers. IP routing
   infrastructure is assumed and not shown.

                        unidirectional
                       --------------->           +----------+
                           downlink               | IMG      |
                                    ------------->| Receiver |
                                   /              +----------+
             +--------+           /                    .
             | IMG    |-----------                     .
             | Sender |           \                    .
             +--------+            \              +----------+
                                    ------------->| IMG      |
                                                  | Receiver |
                                                  +----------+

       Figure 1: Architecture of an IMG Sender and IMG Receivers

   Figure 2 shows an IMG usage scenario involving the optional use of an
   IMG proxy between IMG senders and IMG receivers.

           +----------+          unidirectional          +----------+
           | IMG      |         --------------->         | IMG      |
           | Sender   |----         downlink        ---->| Receiver |
           +----------+    \                       /     +----------+
                            \                     /
                .            \     +-------+     /            .
                .             ---->| IMG   |-----             .
                .             ---->| Proxy |     \            .
                             /     +-------+      \
           +----------+     /                      \     +----------+
           | IMG      |    /                        ---->| IMG      |
           | Sender   |----                              | Receiver |
           +----------+                                  +----------+

 Figure 2: Architecture of IMG Senders, IMG Receivers and an IMG Proxy

   An IMG proxy could be useful in the case that a service provider
   wishes to filter or mix IMG metadata originating from different
   sources, or needs to change the bandwidth allocation for IMG metadata
   between different network domains.



Luoma                    Expires April 26, 2004                 [Page 9]

Internet-Draft                   MUPPET                     October 2003


5. The MUPPET Protocol

   The IMG Point-to-Multipoint Unidirectional Transport (MUPPET)
   protocol defined in this document uses multicast IP delivery to
   provide a transport service to IMG Descriptors. This transport
   service is based on FLUTE [4], a protocol for the unidirectional
   delivery of files over IP based networks. FLUTE in turn builds on the
   reliable multicast transport protocol Asynchronous Layered Coding
   (ALC) [5].

   ALC provides a unidirectional transport service to arbitrary binary
   objects. FLUTE extends the ALC protocol to provide better support for
   file transport. MUPPET uses a set of one or more FLUTE sessions to
   implement a  MUPPET session. Each MUPPET session can provide
   unidirectional transport for a set of IMG information, as well as
   carry updates and notifications of changes within that IMG
   information.

5.1 Use of MUPPET Sessions

   The MUPPET protocol provides an IMG sender with unidirectional
   transport for its IMG metadata in the scope of a MUPPET session,
   consisting of one or more MUPPET channels. Each MUPPET channel is
   implemented as a separate file delivery session provided by the FLUTE
   protocol. At most one of each MUPPET channel type (Complete Channel,
   Update Channel, Notify Channel) can be included in each MUPPET
   session.

5.2 Use of MUPPET Channels

   A MUPPET session consists of one or more MUPPET channels. Each of
   these channels has its own ALC/LCT Transport Session Identifier (TSI)
   value which is carried in every MUPPET packet. MUPPET packets in all
   MUPPET channels are sent from the same source port and IP address,
   but are addressed to a different destination port and/or IP address.
   One or more of the following MUPPET channels MAY be included in a
   MUPPET session.

   o  Complete Channel - repeatedly delivers Complete IMG Descriptors.
      When only a partial IMG is delivered on the Complete Channel,
      clients MAY be provided access to the full IMG via a different
      protocol, e.g. a point-to-point IMG transport protocol.

   o  Delta Channel - repeatedly delivers Delta IMG Descriptors
      consisting of parts of the sender's IMG metadata that have changed
      since the latest Complete IMG Descriptor was sent.

   o  Pointer Channel - repeatedly delivers IMG Pointers to parts of the



Luoma                    Expires April 26, 2004                [Page 10]

Internet-Draft                   MUPPET                     October 2003


      sender's IMG that have changed since the latest Complete IMG
      Descriptor was sent.

   Each MUPPET channel is implemented as a file delivery session defined
   in the FLUTE [4] specification. Hence, a MUPPET session consists of
   one or more file delivery sessions, each corresponding to an ALC/LCT
   session. An ALC session is defined in RFC 3450 [5] to consist of one
   or more ALC channels. The combination of the source IP address and
   the ALC/LCT header field Transport Session Identifier (TSI) uniquely
   identifies an ALC session. An ALC channel in turn is uniquely
   identified within the scope of a MUPPET session by the combination of
   source IP address and destination IP address.

   IMG sender decides on the number of ALC channels allocated for each
   ALC session and the bit rate used on each ALC channel. IMG receivers
   with interactive network connection are able to join and leave
   transport channels, and hence control the received bit rate. IMG
   receivers that only have unidirectional network connectivity have the
   option of filtering only some of the received ALC channels for
   processing. Furthermore, a network element such as IMG proxy can
   reduce the number of ALC channels forwarded to a unidirectional link,
   for example when congestion is detected at the feed of such a link.
   Signaling the addressing parameters needed to join a MUPPET session
   is part of the MUPPET bootstrapping procedure, described in Section
   5.10.

   An IMG receiver with interactive network connectivity is able to join
   and leave ALC channels that constitute a MUPPET channel, as needed.
   Decisions to join and leave ALC channels may be affected by the
   congestion status of the network, as well as the type of MUPPET
   channels the receiver needs to obtain. Furthermore, a network element
   such as IMG proxy can reduce the number of ALC channels forwarded to
   a unidirectional link, for example when congestion is detected at the
   feed of such a link.

5.3 Protocol Framing

   The MUPPET protocol re-uses the packet format of ALC/LCT defined in
   RFC 3450 [5] and RFC 3451 [6], with extensions defined in the FLUTE
   [4] specification. MUPPET uses the ALC/LCT packet format, reproduced
   in Figure 3.










Luoma                    Expires April 26, 2004                [Page 11]

Internet-Draft                   MUPPET                     October 2003


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         UDP header                            |
    |                                                               |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    .                        LCT header portion                     .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                       FEC Payload ID                          .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                     Encoding Symbol(s)                        .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: Overall MUPPET Packet Format

      UDP header: 32 bits

         The standard UDP header.

      LCT header portion: variable length

         The LCT header portion of the MUPPET packet is described in
         [6].

      FEC Payload ID: variable length

         The size and format of this header field is determined by the
         FEC Object Transmission Information defined for ALC in RFC 3450
         [5]. FLUTE [4] defines several alternative mechanisms for
         communicating FEC Object Transmission Information to receivers
         of file delivery sessions. Any of these mechanisms can be used
         with MUPPET.

      Encoding Symbol(s): variable length

         This field is used to carry one or more ALC encoding symbols
         [5] that are the payload of the MUPPET protocol. The size of
         each encoding symbol is communicated to receivers using FEC
         Object Transmission Information.


5.4 Forward Error Correction

   MUPPET implementations are REQUIRED to support a Forward Error
   Correction scheme that is an instantiation of the reliable multicast



Luoma                    Expires April 26, 2004                [Page 12]

Internet-Draft                   MUPPET                     October 2003


   FEC building block defined in [9], in line with the requirements of
   the underlying ALC protocol. However, FEC functionality is not
   expected to be necessary for MUPPET implementations in all
   environments. Therefore, only the Compact No-Code FEC scheme [12]
   MUST be supported by all MUPPET implementations, while other FEC
   schemes compliant with [9] MAY also be supported.

5.5 Payload Segmentation

   IP layer fragmentation of MUPPET packets is unwanted because of the
   loss-multiplier effect that reduces the efficiency of FEC schemes at
   higher protocol layers. Thus, the size of a MUPPET packet with
   protocol headers SHOULD be no larger than the Layer 2 MTU.

5.6 Use of Congestion Control

   The transport protocol defined in this document SHALL provide a
   mechanism for keeping the bandwidth consumption under given limits in
   a way compatible with RFC 2357 [7]. To support scenarios where MUPPET
   is deployed on a unidirectional access network with fully provisioned
   bandwidth allocation, implementations of this protocol SHOULD support
   a bandwidth control mechanism that does not require feedback from the
   receivers to the network. In accordance with RFC 2357, a bandwidth
   control mechanism that operates without receiver feedback MUST NOT be
   used on network links that are routed to the public Internet.

5.7 Caching Support in IMG Proxies

   It may be necessary for an IMG proxy to look into the fields of the
   MUPPET payload [8] to enable better support of caching policies and
   congestion control. However, this may be restricted by the use of
   encryption (Section 5.9).

5.8 Authentication

   The MUPPET protocol SHALL support authenticated delivery of transport
   objects, allowing the integrity of the transported data to be
   verified (message authentication) and the sender to be identified
   (source authentication). The use of message authentication is
   RECOMMENDED, while the use of source authentication is OPTIONAL. The
   details of authentication are outside the scope of this
   specification.

   OPTIONALLY, network elements such as IMG proxies that need to modify
   the payloads of MUPPET messages MAY have sufficient trust to
   calculate and insert valid authentication information to the modified
   MUPPET packet.




Luoma                    Expires April 26, 2004                [Page 13]

Internet-Draft                   MUPPET                     October 2003


5.9 Encryption

   This protocol SHALL support encrypted delivery of transport objects,
   only allowing the transported data to be decrypted by a given subset
   of the IMG receivers. The details of encryption are outside the scope
   of this specification.

   OPTIONALLY, network elements such as IMG proxies that need to modify
   the payloads of MUPPET messages MAY have sufficient trust to decrypt
   and re-encrypt MUPPET messages

5.10 Bootstrapping IMG Session (informative)

   It is necessary to find the parameters of IMG channels before a
   receiver can join to the IMG session. This initial bootstrapping/
   discovery can be performed by a number of well-known methods. Some
   examples are provided below for information although this
   functionality is outside the scope of the MUPPET protocol.

5.10.1 Pilot Announcements

   This method is principally for the unidirectional multicast
   environment. Announcements could be sent using MUPPET specific pilot
   packet format (similar to SAP [10], or piggy-backing/extending/
   mimicking the information on SAP or Router Advertisement [13]
   messages. When using SAP and SDP [11], many extensions to SDP are
   however required.

   These pilot announcements are sent to well-known group/destination
   address. There are still issues with learning this initial address,
   which may be solved through IANA registration or pre-configuration.
   Source address of pilot announcements is also required to know in
   SSM-networks. This problem may be solved again by pre-configuration
   or by using  protocols such as [14].

5.10.2 Look-up Mechanisms

   This method is only possible for unicast capable network connections.
   The parameters of IMG channels could be retrieved by using HTTP or a
   similar interactive protocol. Directory mechanisms similar to the
   Domain Name System (DNS) could be also used. In the above mentioned
   mechanisms a well-known, site-local address could be used for the
   look-up, and it may be set by pre-configuration.

   It is also possible to use mechanisms like [15] and IMG Framework's
   [3] unicast protocols to bootstrap IMG sessions.





Luoma                    Expires April 26, 2004                [Page 14]

Internet-Draft                   MUPPET                     October 2003


5.10.3 Pre-configuration

   This method is particularly useful for administratively closed
   domains, but maybe also relevant to the Internet at large.

   The parameters of IMG channels could be pre-configured by service
   providers and/or users (note the difference compared to
   pre-configuration in earlier cases, where only initial discovery
   addresses were pre-configured). Users can configure IMG channels for
   example by using configuration scripts or manually using instructions
   received from the service provider.








































Luoma                    Expires April 26, 2004                [Page 15]

Internet-Draft                   MUPPET                     October 2003


6. Security Considerations

   The main security concern with this protocol is how to protect IMG
   receiver from forged MUPPET messages. Such messages could be
   generated to prevent end-users from obtaining IMGs or to insert false
   information into IMGs. To enable receivers to detect message
   tampering, authentication information can be added to IMG transfers,
   allowing (at least some of) the IMG receivers to verify if IMG
   metadata originates from a particular IMG sender and if it has been
   tampered with.

   Another security concern is that IMG senders may not wish all of the
   IMG metadata transmitted with MUPPET to be accessible to all IMG
   receivers. This can be accomplished by encrypting some IMG metadata
   fields (partial encryption) or all of the IMG metadata (full
   encryption) transmitted as a single IMG transfer.

   Encryption can be provided on any of the following layers: IMG
   metadata, MUPPET or lower protocol layers (such as IPsec or TLS).
   Encryption is currently not within the scope of MUPPET, but can be
   implemented as an extension to it or provided on other protocol
   layers.





























Luoma                    Expires April 26, 2004                [Page 16]

Internet-Draft                   MUPPET                     October 2003


7. Contributors

   Rod Walsh
   Nokia Research Center
   P.O. Box 100 (Visiokatu 1)
   FIN-33721 Tampere
   Finland
   EMail: rod.walsh@nokia.com

   Toni Paila
   Nokia Ventures Organization
   P.O. Box 209 (Itamerenkatu 11-13)
   FIN-00181 Helsinki
   Finland
   EMail: toni.paila@nokia.com

   Jani Peltotalo
   Tampere University of Technology
   Institute of Communications Engineering
   P.O. Box 553 (Korkeakoulunkatu 1)
   FIN-33101 Tampere
   Finland
   EMail: jani.peltotalo@tut.fi

   Sami Peltotalo
   Tampere University of Technology
   Institute of Communications Engineering
   P.O. Box 553 (Korkeakoulunkatu 1)
   FIN-33101 Tampere
   Finland
   EMail: sami.peltotalo@tut.fi




















Luoma                    Expires April 26, 2004                [Page 17]

Internet-Draft                   MUPPET                     October 2003


8. Acknowledgements

   The author would like to thank Yuji Nomura, Henning Schulzrinne and
   Rami Lehtonen for their feedback on this document.















































Luoma                    Expires April 26, 2004                [Page 18]

Internet-Draft                   MUPPET                     October 2003


Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCD 14, March 1997.

   [2]   Nomura, Y., Walsh, R., Ott, J. and H. Schulzrinne, "Protocol
         Requirements for Internet Media Guides",
         draft-ietf-mmusic-img-requirements-00 (work in progress),
         September 2003.

   [3]   Nomura, Y., Walsh, R., Luoma, J., Asaeda, H. and H.
         Schulzrinne, "A Framework for the Usage of Internet Media
         Guides", draft-ietf-mmusic-img-framework-00 (work in progress),
         October 2003.

   [4]   Paila, T., Luby, M., Lehtonen, R. and V. Roca, "FLUTE - File
         Delivery over Unidirectional Transport",
         draft-ietf-rmt-flute-03 (work in progress), October 2003.

   [5]   Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
         "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC
         3450, December 2002.

   [6]   Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
         J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
         RFC 3451, December 2002.

   [7]   Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
         Criteria for Evaluating Reliable Multicast Transport and
         Application Protocols", RFC 2357, June 1998.

   [8]   Luoma, J., "A Metadata Framework for Internet Media Guides:
         Metadata Envelope and Baseline Data Model",
         draft-luoma-mmusic-img-metadata-02 (work in progress), October
         2003.

   [9]   Luby, M., Vicisano, L., Gemmel, J., Rizzo, L., Handley, M. and
         J. Crowcroft, "Forward Error Correction (FEC) Building Block",
         RFC 3452, December 2002.

   [10]  Handley, M., Perkins, C. and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

   [11]  Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [12]  Vicisano, L. and M. Luby, "Compact Forward Error Correction
         (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in



Luoma                    Expires April 26, 2004                [Page 19]

Internet-Draft                   MUPPET                     October 2003


         progress), May 2003.


















































Luoma                    Expires April 26, 2004                [Page 20]

Internet-Draft                   MUPPET                     October 2003


Informative References

   [13]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
         September 1991.

   [14]  Beck, F., "Source Discovery Protocol in SSM Networks",
         draft-beck-mboned-ssm-source-discovery-protocol-00 (work in
         progress), July 2003.

   [15]  Asaeda, H. and V. Roca, "Consideration of Multicast Channel
         Announcement Architecture", INRIA Research Report RR-4762,
         March 2003.


Author's Address

   Juha-Pekka Luoma
   Nokia
   P.O. Box 100 (Visiokatu 1)
   Tampere  FIN-33721
   Finland

   EMail: juha-pekka.luoma@nokia.com




























Luoma                    Expires April 26, 2004                [Page 21]

Internet-Draft                   MUPPET                     October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


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

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Luoma                    Expires April 26, 2004                [Page 22]

Internet-Draft                   MUPPET                     October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Luoma                    Expires April 26, 2004                [Page 23]