Internet Draft J.-P. Luoma Document: draft-luoma-mmusic-img-muppet-00.txt Nokia Category: Informational December 2002 Expires: June 2003 MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport 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. Abstract This document defines MUPPET, a point-to-multipoint transport protocol for the delivery of Internet Media Guides over unidirectional access networks. The MUPPET protocol is intended to be used with the Internet Media Guide framework, and may also be useful with other applications. Luoma Expires June 2003 [Page 1] Internet Draft MUPPET December 2002 Table of Contents 1. Introduction ...............................................2 2. Conventions used in this document ..........................2 3. Terminology ................................................2 4. Overview ...................................................4 4.1. Usage for Pushing IMG Metadata..............................6 4.2. Usage for Pushing IMG Notifications.........................6 4.3. Combined Usage for Pushing IMG Metadata and Notifications...7 4.4. Environmental Considerations................................7 5. The MUPPET Protocol ........................................8 5.1. Forward Error Correction....................................9 5.2. Payload segmentation........................................9 5.3. Congestion Control..........................................9 5.4. Authentication .............................................9 5.5. Encryption..................................................9 5.6. Protocol Framing............................................9 5.7. ALC Considerations..........................................9 6. Security Considerations ...................................10 7. Acknowledgements ..........................................11 8. Contributors ..............................................11 9. Annex A: Example usage ....................................11 10. Normative References ......................................11 11. Informative References ....................................11 12. Authors' Addresses ........................................12 13. Full Copyright Statement ..................................12 1. Introduction An Internet Media Guide (IMG) is a set of metadata describing available content such as streaming media and downloadable files. This document considers point-to-multipoint (p-t-m) transmission of IMG metadata over unidirectional access networks and defines a new transport protocol "MUPPET" for this purpose. The format of the IMG metadata is outside the scope of this document. 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. 3. Terminology * Congestion Control Functionality of IMG senders allowing them 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 Luoma Expires June 2003 [Page 2] Internet Draft MUPPET December 2002 downlink data and practically eliminates the need for congestion control on the uplink. * Forward Error Correction (FEC) FEC data is redundant information generated from payload data and interleaved with it for transmission. The use of FEC allows receivers to reconstruct payload data segements lost or damaged due to transmission errors. * IMG Fetch The client-controlled delivery of IMG metadata to an IMG receiver, based on a request-response model using acknowledgements if required. * IMG Metadata Composite An IMG metadata composite consists of two or more IMG metadata structures. * IMG Metadata Element A set of IMG metadata that is atomic for the purposes of IMG transport. * IMG Metadata Reference A pointer to an IMG metadata structure. * IMG Metadata Structure An IMG metadata structure is an IMG element, an IMG composite or an IMG metadata reference. * IMG Notify Informs IMG receivers about a change in the IMG metadata. It shall identify the parts of the IMG metadata that have changed without delivering the updated IMG metadata. A unidirectional notify provides only an indication, whereas notification on a bidireciontal link may additionally require a response from the receivers. * IMG Proxy An IMG Proxy can filter from one or more IMG senders and output to one or more delivery channels. 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 Push The sender-controlled delivery of IMG metadata to IMG receivers. This is inherently unidirectional. * IMG Receiver A logical entity that receives media guides from an IMG sender. Luoma Expires June 2003 [Page 3] Internet Draft MUPPET December 2002 * 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. A sender can additionally be a receiver - see IMG transceiver. * IMG Subscribe A request for notifications of IMG metadata updates, from a receiver to a sender or proxy. * IMG Transceiver Combination of an IMG receiver and sender. 4. Overview The documents [2] and [3] describe the requirements and framework for Internet Media Guides (IMG), respectively, and identify several IMG transport services. One or more IMG transport protocol instantiations providing these conceptual IMG transport services need to be specified and the protocol implementations may vary between different network environments. Figure 1 shows the need for different IMG transport services depending on the unidirectional/bidirectional property of the access network and the use of Point-to-Point/Point-to-Multipoint delivery. As only a subset of the use cases provided by may be useful in some implementations, it is considered that a minimum of two IMG transport protocol specifications will be required and thus published: a point-to-multipoint instantiation; and, a point- to-point instantiation. Luoma Expires June 2003 [Page 4] Internet Draft MUPPET December 2002 +---------------+---------------+ |unidirectional |bi-directional | | (simplex) | (duplex) | +---------+---------------+---------------+ | | img_NOTIFY | img_SUBSCRIBE | | p-t-p | img_PUSH | img_NOTIFY | | unicast | | img_FETCH | | | | | +---------+---------------+---------------+ | | img_NOTIFY | img_SUBSCRIBE | | p-t-m | img_PUSH | img_NOTIFY | |multicast| | img_PUSH | | | | img_FETCH | +---------+---------------+---------------+ Figure 1 - IMG Transport Matrix The IMG transport services shown in Figure 1 can be described as follows: * img_SUBSCRIBE is used by IMG receivers to request notifications of IMG metadata updates. An implementation of this IMG transport service corresponds to the "Notification request" protocol component described in [2]. * img_NOTIFY is used by the IMG sender to inform IMG receivers about a change in the IMG metadata. An implementation of this IMG transport service corresponds to the "Update notification" protocol component described in [2]. * img_PUSH provides server-controlled delivery of IMG metadata to IMG receivers. Either the full metadata or an update to the IMG metadata can be provided. The implementation of this IMG transport service can be shared with img_NOTIFY, or a separate implementation may be provided. * img_FETCH provides a receiver-controlled delivery of IMG metadata to the IMG receiver. Either the full metadata or an update to the IMG metadata can be provided. An implementation of this IMG transport service corresponds to the "Program guide request" protocol component described in [2]. Figure 2 below shows the use of different transport protocols to provide IMG transport services. In this figure, the name "MUPPET" refers to IMG p-t-m transport protocol being defined in this document, while "SIP" refers to the use of the Session Initiation Protocol with event notification mechanism. Luoma Expires June 2003 [Page 5] Internet Draft MUPPET December 2002 +--------------------------------------------+ IMG | | Content | METADATA | | (IMG metadata structures) | +------+--------+--------+-----------+-------+ Logical | | | | | | Transport | PUSH | NOTIFY | NOTIFY | SUBSCRIBE | FETCH | Service | | (p-t-m)| (p-t-p)| | | +------+--------+--------+-----------+-------+ Transport | | | | Protocol | MUPPET | SIP | HTTP | | | | | +---------------+--------------------+-------+ Figure 2 - Relations between IMG transport services and transport protocols This document specifies a point-to-multipoint IMG transport protocol instantiation "MUPPET" that provides the IMG Transport Services img_NOTIFY and img_PUSH via unidirectional access networks. 4.1. Usage for Pushing IMG Metadata The IMG p-t-m unidirectional transport protocol provides the IMG_PUSH transport service for the delivery of the full IMG metadata or an IMG metadata update. When used for sending updates, only the updated IMG metadata structures (or possibly just the delta information) are transmitted. To add reliability to transmissions over error-prone links the IMG sender SHOULD send IMG repetitively, by repeating a set of transmissions in carousel style or by sending individual transmissions multiple times. To reduce the processing load of clients monitoring changes only in parts of an IMG service hierarchy, the transfer of IMG metadata MAY be divided between several multicast channels. In this case, a multicast channel could be an ASM group, SSM channel or an ALC channel. The selection of multicast channel for each metadata structure can take place e.g. based on the content category assigned to the element. 4.2. Usage for Pushing IMG Notifications The IMG p-t-m unidirectional transport protocol provides the img_NOTIFY transport service for the delivery of IMG update notifications. Although IMG delivery can be implemented without update notifications, it is RECOMMENDED to use them in the following cases: Luoma Expires June 2003 [Page 6] Internet Draft MUPPET December 2002 * No unidirectional metadata transfer: updated IMG metadata is never pushed to receivers, but can be obtained via a fetch operation. This case is only feasible if the receivers can at least intermittently access a bidirectional network connection. * Unidirectional metadata transfer only if sufficient demand: IMG updates are only pushed to clients if enough clients indicate (via out-of-band means) that they wish to receive the updates. * Unidirectional metadata transfer with bandwidth reduction: IMG updates are pushed to clients much less frequently than IMG update notifications. The notifications inform clients that part of their IMG data is no longer valid - they can either wait for an IMG update push via the unidirectional connection or fetch the IMG update via a bidirectional connection if available. 4.3. Combined Usage for Pushing IMG Metadata and Notifications An IMG sender MAY combine the following in the same IMG push transfer (also known as piggybacking): * A notification of updates in parts of the IMG metadata * The actual metadata of other updated parts of the IMG As an example, only the changed IMG metadata considered most relevant to clients could be pushed to clients while the rest of the metadata would only be available via a fetch operation. 4.4. Environmental Considerations Figure 3 below 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. Luoma Expires June 2003 [Page 7] Internet Draft MUPPET December 2002 +----------+ | IMG | +--------------->| Receiver | | +----------+ +--------+ | . | IMG |----------+ . | Sender | | . +--------+ | +----------+ +--------------->| IMG | | Receiver | +----------+ Figure 3 - Architecture of an IMG sender and IMG receivers Figure 4 below shows an IMG usage scenario involving the optional use of an IMG proxy between IMG senders and IMG receivers. +--------+ +----------+ | IMG |----------+ +---------->| IMG | | Sender | | | | Receiver | +--------+ V | +----------+ . +-------+ . . | IMG | . . | Proxy | . +-------+ +--------+ ^ | +----------+ | IMG | | | | IMG | | Sender |----------+ +---------->| Receiver | +--------+ +----------+ Figure 4 - 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. 5. The MUPPET Protocol The IMG Point-to-Multipoint Unidirectional Transport (MUPPET) protocol defined in this document uses multicast IP delivery to provide the following functionalities via unidirectional access networks: * Delivery of IMG metadata (img_PUSH) - transmission of the full metadata of an IMG or just the updated part of the IMG metadata. * Notification of a change in the IMG metadata (img_NOTIFY) - indication of a change in the IMG metadata. Luoma Expires June 2003 [Page 8] Internet Draft MUPPET December 2002 This protocol SHALL be based on the reliable multicast transport protocol RMT-ALC [4] 5.1. Forward Error Correction The MUPPET protocol is optimized for unidirectional access networks that do not support receiver reports on incorrectly received or missing data segments. Therefore, the transport protocol provides support for error resilience through the insertion of Forward Error Correction (FEC) data and/or repetitive transmission of data segments. The FEC can be implemented for example using the Forward Error Correction building block defined in [6]. The retransmissions can be implemented either as immediate retransmissions of data segments or as carouselling of IMG metadata transmissions. The use of one or more of these error resilience features is RECOMMENDED. 5.2. Payload segmentation IP layer fragmentation of transmission segments is unwanted because of the loss-multiplier effect that reduces the efficiency of FEC schemes at higher protocol layers. Hence, the size of a transmission segment with protocol headers SHOULD be no larger than the MTU at Layer 2. This transport protocol allows the OPTIONAL mapping of transmission segment boundaries to the delimiters of IMG metadata elements, thus providing better support for progressive decoding of IMG metadata during reception by clients. 5.3. 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 [5]. It may be necessary for an IMG proxy to look into the metadata payload (e.g. for the identifier and expiry time of an IMG metadata structure) to enable better support of caching policies and congestion control - see the encryption notes. 5.4. Authentication This protocol SHALL support authenticated transport of IMG metadata, allowing the integrity of the metadata 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. Luoma Expires June 2003 [Page 9] Internet Draft MUPPET December 2002 5.5. Encryption * Encryption of IMG Metadata Push and IMG Notification Push messages MAY be used * The message identifier (and version?) fields of each metadata structure SHOULD be provided in the clear regardless of whether the rest of the message is encrypted * OPTIONALLY every router and host on the IMG route which needs to interact with the message identifier (and version?) fields of each metadata structure MAY have sufficient trust to be able to decrypt these fields if encrypted * Exchange of security parameters related to the encryption of IMG messages (may involve IMG metadata but) is out of scope of this document. 5.6. Protocol Framing 5.7. ALC Considerations * Autonomous ALC congestion control is not required on links with fully provisioned bandwidth allocation and not connected to the public Internet. * ALC Network-controlled congestion control may OPTIONALLY be implemented * ALC Client-controlled or Server-controlled congestion control are not feasible because of unidirectional connectivity * : ALC session and channel parameters are defined out-of-band; OR ALC session and channel parameters related to IMG p-t-m transport shall be defined in IMG metadata 6. Security Considerations * An IMG receiver should not trust an IMG protocol message unless the message is received from a trusted source and passes authenticity checks. However, untrusted messages MAY be accepted Luoma Expires June 2003 [Page 10] Internet Draft MUPPET December 2002 by the receiver * An IMG client should not participate in interactive sessions without the end-user's consent * An IMG client should not start applications other than those configured for receiving content described by IMG metadata 7. Acknowledgements We would like to thank Yuji Nomura and Henning Schulzrinne for providing a basis and offering feedback on this document. 8. 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 9. Annex A: Example usage 10. Normative References [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [2] Y. Nomura, H. Schulzrinne, "Protocol Requirements for Internet Program Guides", Internet Draft draft-nomura-mmusic- pguide-requirements-00.txt, February 2002, a work in progress. [3] Y. Nomura, H. Schulzrinne, "A Framework for Internet Program Guides", Internet Draft draft-nomura-mmusic-pguide-framework- 00.txt, October 2002, a work in progress. [4] M. Luby et al., "Asynchronous Layered Coding protocol instantiation", Internet Draft draft-ietf-rmt-pi-alc-08.txt, April 2002, a work in progress. Luoma Expires June 2003 [Page 11] Internet Draft MUPPET December 2002 [5] A. Mankin et al., "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. 11. Informative References [6] M. Luby et al., "Forward Error Correction protocol building block", Internet Draft draft-ietf-rmt-bb-fec-07.txt, September 2002, a work in progress. 12. Authors' Addresses Juha-Pekka Luoma Nokia Research Center P.O. Box 100 (Visiokatu 1) FIN-33721 Tampere Finland Email: juha-pekka.luoma@nokia.com 13. Full Copyright Statement Luoma Expires June 2003 [Page 12]