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]