MMUSIC J-P. Luoma Internet-Draft Nokia Expires: June 14, 2004 J. Peltotalo S. Peltotalo Tampere University of Technology December 15, 2003 MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport draft-luoma-mmusic-img-muppet-04 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 June 14, 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 File Delivery over Unidirectional Transport (FLUTE), a protocol for unidirectional file delivery. MUPPET is intended to be used with the Internet Media Guide framework, and in addition may be useful with other applications. Luoma, et al. Expires June 14, 2004 [Page 1] Internet-Draft MUPPET December 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 4. The MUPPET Protocol . . . . . . . . . . . . . . . . . . . 9 4.1 Use of MUPPET Sessions . . . . . . . . . . . . . . . . . . 9 4.2 Use of MUPPET Channels . . . . . . . . . . . . . . . . . . 9 4.3 Protocol Framing . . . . . . . . . . . . . . . . . . . . . 10 4.4 Forward Error Correction . . . . . . . . . . . . . . . . . 11 4.5 Payload Segmentation . . . . . . . . . . . . . . . . . . . 12 4.6 Use of Congestion Control . . . . . . . . . . . . . . . . 12 4.7 Caching Support in MUPPET Transceivers . . . . . . . . . . 12 4.8 Authentication . . . . . . . . . . . . . . . . . . . . . . 12 4.9 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 13 4.10 Bootstrapping MUPPET Session (informative) . . . . . . . . 13 4.10.1 Pilot Announcements . . . . . . . . . . . . . . . . . . . 13 4.10.2 Look-up Mechanisms . . . . . . . . . . . . . . . . . . . . 13 4.10.3 Pre-configuration . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . 15 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . 18 Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 19 A. Pilot Packet Format (informative) . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . 25 Luoma, et al. Expires June 14, 2004 [Page 2] Internet-Draft MUPPET December 2003 1. Introduction This document defines MUPPET, a unidirectional point-to-multipoint transport protocol for the delivery of Internet Media Guide (IMG) metadata. The scope and background of the work on Internet Media Guides have been described in the IMG requirements [2] and IMG framework [3] specifications. MUPPET 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. 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, et al. Expires June 14, 2004 [Page 3] Internet-Draft MUPPET December 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 [1]. Luoma, et al. Expires June 14, 2004 [Page 4] Internet-Draft MUPPET December 2003 3. Terminology Complete IMG Description Provides a complete syntax and semantics to describe a set of metadata, which does not need any additional information from other IMG Descriptions. It may contain either a full IMG or a subset thereof. Complete Transfer Transfer of the whole set of metadata comprising an IMG block. Congestion Control 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 Description Provides an update to a Complete IMG Description, defining the difference from the Complete IMG Description in question. This description may be used to reduce network resource usage for instance when small and frequent changes occur to Complete IMG Description. Thus, this description itself cannot represent complete metadata set until it is combined with the corresponding Complete IMG Description. Delta Transfer Transfer of Delta IMG Description(s) to update an IMG block. 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. Full IMG Represents a subset/whole of the sender's IMG database delivered within the scope of one IMG transport session. A sender will generally deliver only a subset of metadata from its whole database of IMG metadata as a full IMG, but a full Luoma, et al. Expires June 14, 2004 [Page 5] Internet-Draft MUPPET December 2003 IMG could also represent the whole IMG database of a particular sender. Different subsets of the sender's IMG database may be provided within different transport sessions; similarly, the same subset may be provided in more than one transport session. Internet Media Guide (IMG) An IMG is a generic term to describe the formation, delivery and use of IMG metadata. The definition of the IMG is intentionally left imprecise. IMG ANNOUNCE IMG ANNOUNCE is an IMG operation for the unsolicited delivery of IMG metadata from an IMG sender to IMG receiver(s) [3]. References to parts of IMG metadata may also be included, instead of the actual metadata. IMG Block IMG block consists of one or more IMG Descriptions. IMG Description A collection of IMG metadata. There are the following subtypes of IMG Descriptions: Complete IMG Description, Delta IMG Description and IMG Pointer. IMG Element The smallest atomic element of IMG metadata that can be transmitted separately and referenced individually from other IMG elements. IMG Metadata A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of the URI, title, airtime, bandwidth needed, file size, text summary, genre, and access restrictions. IMG Pointer A reference, such as URI, that the receiver is able to address specific metadata with. An IMG pointer may be used to separately obtain IMG elements, or perform another IMG Luoma, et al. Expires June 14, 2004 [Page 6] Internet-Draft MUPPET December 2003 management function such as data expiry and erasure. IMG Transfer A complete transfer, delta transfer or notification transfer pertaining to an IMG block. IMG Transport Protocol A protocol that transports IMG metadata from an IMG sender to IMG receiver(s) [3]. IMG Update Notification Provides one or more IMG Pointers. MUPPET Channel Provides a delivery service for IMG Descriptions. A MUPPET channel is one of the following: 1. Complete Channel that delivers Complete IMG Descriptions. 2. Delta Channel that delivers Delta IMG Descriptions. 3. Pointer Channel that delivers IMG Pointers. MUPPET Receiver A MUPPET Receiver is an IMG receiver [3] that receives IMG metadata from an IMG sender using the MUPPET protocol. MUPPET Sender A MUPPET sender is an IMG sender [3] that delivers IMG metadata to one or more IMG rececivers using the MUPPET protocol. receivers. A MUPPET sender shall provide bandwidth control or congestion control schemes on the output. MUPPET Session A MUPPET session is an IMG transport session [3] that uses the MUPPET protocol for the delivery of IMG metadata. Each MUPPET session consists of one or more MUPPET channels. MUPPET Transceiver A MUPPET transceiver is an IMG transceiver [3] that combines a Luoma, et al. Expires June 14, 2004 [Page 7] Internet-Draft MUPPET December 2003 MUPPET receiver and a MUPPET sender. Before transmission, it may modify the received IMG metadata or combine IMG metadata received from multiple MUPPET senders. Notification Transfer The transfer of an IMG update notification. Luoma, et al. Expires June 14, 2004 [Page 8] Internet-Draft MUPPET December 2003 4. The MUPPET Protocol The IMG Point-to-Multipoint Unidirectional Transport (MUPPET) protocol defined in this document provides a transport service corresponding to the IMG ANNOUNCE operation described in the Internet Media Guide framework [3] specification. MUPPET 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, which is based on the Layered Coding Transport (LCT) [6] protocol building block, provides a unidirectional transport service to arbitrary binary objects. FLUTE extends the ALC protocol to provide the additional functionality needed 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. 4.1 Use of MUPPET Sessions The MUPPET protocol provides a MUPPET 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. 4.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.One or more of the following MUPPET channels MAY be included in a MUPPET session. o Complete Channel - repeatedly delivers Complete IMG Descriptions. 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 Descriptions consisting of parts of the sender's IMG metadata that have changed since the latest Complete IMG Description was sent. o Pointer Channel - repeatedly delivers IMG Pointers to parts of the sender's IMG that have changed since the latest Complete IMG Description was sent. Each MUPPET channel is implemented as a file delivery session defined Luoma, et al. Expires June 14, 2004 [Page 9] Internet-Draft MUPPET December 2003 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 an ALC session by the combination of source IP address and destination IP address. The MUPPET sender decides on the number of ALC channels allocated for each ALC session and the bit rate used on each ALC channel. MUPPET receivers with interactive network connection are able to join and leave transport channels, and hence control the received bit rate. MUPPET 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 MUPPET transceiver 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 4.10. A MUPPET 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 MUPPET transceiver 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. 4.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 1. Luoma, et al. Expires June 14, 2004 [Page 10] Internet-Draft MUPPET December 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 1: 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], with extensions defined in FLUTE [4]. 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. 4.4 Forward Error Correction MUPPET implementations are REQUIRED to support a Forward Error Correction (FEC) scheme that is an instantiation of the reliable Luoma, et al. Expires June 14, 2004 [Page 11] Internet-Draft MUPPET December 2003 multicast 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. 4.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 Maximum Transmission Unit (MTU). 4.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 [7], a bandwidth control mechanism that operates without receiver feedback MUST NOT be used on network links that are routed to the public Internet. 4.7 Caching Support in MUPPET Transceivers It may be necessary for a MUPPET transceiver to look into the payload of MUPPET messages to enable better support of caching policies and congestion control. However, this may be restricted by the use of encryption (Section 4.9). 4.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 MUPPET transceivers that need to modify the payload of MUPPET messages MAY have sufficient trust to calculate and insert valid authentication information to the modified Luoma, et al. Expires June 14, 2004 [Page 12] Internet-Draft MUPPET December 2003 MUPPET message. 4.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 MUPPET receivers. The details of encryption are outside the scope of this specification. OPTIONALLY, network elements such as MUPPET transceivers that need to modify the payloads of MUPPET messages MAY have sufficient trust to decrypt and re-encrypt MUPPET messages 4.10 Bootstrapping MUPPET Session (informative) It is necessary to find the parameters of MUPPET channels before a receiver can join to the MUPPET 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. 4.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]. MUPPET specific pilot packet format is presented in Appendix A. 4.10.2 Look-up Mechanisms This method is only possible for unicast capable network connections. The parameters of MUPPET 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. Luoma, et al. Expires June 14, 2004 [Page 13] Internet-Draft MUPPET December 2003 Bootstrapping MUPPET sessions may also be provided by unicast IMG transport protocols compliant with the IMG Framework [3], or by mechanisms such as [15]. 4.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 MUPPET 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 MUPPET channels for example by using configuration scripts or manually using instructions received from the service provider. Luoma, et al. Expires June 14, 2004 [Page 14] Internet-Draft MUPPET December 2003 5. Security Considerations The main security concern with this protocol is how to protect receivers from forged MUPPET messages. Such messages could be generated to prevent end-users from obtaining IMGs or to insert false information into IMGs. Authentication techniques can be used on MUPPET protocol messages to protect against message tampering. Another security concern is that MUPPET senders may not wish all of the IMG metadata transmitted with MUPPET to be accessible to all MUPPET receivers. This can be accomplished by encrypting some IMG elements (partial encryption) or all of the IMG metadata (full encryption) sent as a an IMG transfer. Authentication and encryption can be provided on any of the following layers: IMG metadata, MUPPET or lower protocol layers (such as IPsec [16] or TLS [17]). The details of providing encryption and authentication are not within the scope of this specification, but can be provided on other protocol layers (for example using IPsec or TLS) or implemented as extensions to MUPPET. Luoma, et al. Expires June 14, 2004 [Page 15] Internet-Draft MUPPET December 2003 6. 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 Luoma, et al. Expires June 14, 2004 [Page 16] Internet-Draft MUPPET December 2003 7. Acknowledgements The author would like to thank Yuji Nomura, Henning Schulzrinne and Rami Lehtonen for their feedback on this document. Luoma, et al. Expires June 14, 2004 [Page 17] Internet-Draft MUPPET December 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., Luoma, J., Ott, J. and H. Schulzrinne, "Protocol Requirements for Internet Media Guides", draft-ietf-mmusic-img-req-01 (work in progress), December 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-01 (work in progress), December 2003. [4] Paila, T., Luby, M., Lehtonen, R. and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-07 (work in progress), December 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-P., Peltotalo, J. and S. Peltotalo, "A Metadata Framework for Internet Media Guides: Metadata Envelope", draft-luoma-mmusic-img-metadata-envelope-00 (work in progress), December 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 progress), May 2003. Luoma, et al. Expires June 14, 2004 [Page 18] Internet-Draft MUPPET December 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. [16] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [17] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wrigth, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. Authors' Addresses Juha-Pekka Luoma Nokia Research Center P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: juha-pekka.luoma@nokia.com Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: jani.peltotalo@tut.fi Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: sami.peltotalo@tut.fi Luoma, et al. Expires June 14, 2004 [Page 19] Internet-Draft MUPPET December 2003 Appendix A. Pilot Packet Format (informative) MUPPET specific pilot packets have the format described in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |A| C |S|E|F|U| AUTH_LEN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Source IP Address (32 or 128 bits) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . MUPPET Channel Descriptions . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Estimated Start Time (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Estimated End Time (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . FEC Object Transmission Information . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . URI of the IMG Transfer Envelope . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Authentication Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Pilot Packet Format Version Number (V): 4 bits This field indicates the version number of pilot packet format. The version number MUST be set to 0. Address Type flag (A): 1 bit This field indicates the length of the IP Address fields. A=0 indicates that IP Address fields contains a 32-bit IPv4 address. Luoma, et al. Expires June 14, 2004 [Page 20] Internet-Draft MUPPET December 2003 A=1 indicates that IP Address fields contains a 128-bit IPv6 address. MUPPET Channel Descriptions flag (C): 2 bits This field indicates the number of descriptions in a MUPPET Channel Descriptions field. C=0 indicates that one description is present. C=1 indicates that two descriptions are present. C=2 indicates that three descriptions are present. Estimated Start Time flag (S): 1 bit This field indicates the presence of an Estimated Start Time (EST) field. S=0 indicates that the EST field is not present. S=1 indicates that the EST field is present. Estimated End Time flag (E): 1 bit This field indicates the presence of an Estimated End Time (EET) field. E=0 indicates that the EET field is not present. E=1 indicates that the EET field is present. FEC Object Transmission Information flag (F): 1 bit This field indicates the presence of a FEC Object Transmission Information (FEC_OTI) field. F=0 indicates that the FEC_OTI field is not present. F=1 indicates that the FEC_OTI field is present. URI of the IMG Transfer Envelope flag (U): 1 bit This field indicates the presence of an URI of the IMG Transfer Envelope [8] field. U=0 indicates that the URI of the IMG Transfer Envelope field is not present. U=1 indicates that the URI of the IMG Transfer Envelope field is present. Authentication Data Length (AUTH_LEN): 8 bit Luoma, et al. Expires June 14, 2004 [Page 21] Internet-Draft MUPPET December 2003 This field indicates the length of an Authentication Data field in 32-bit words. The value of this field MUST be zero when authentication header is not present. Reserved (R): 13 bits This field is reserved for future use. It MUST be zeroed by sender and ignored by receiver. Source IP Address: 32 or 128 bits This field contains the IP address of the source. The length of this field MUST be 32 bits (IPv4 address) if A=0 and 128 bits (IPv6 address) if A=1. MUPPET Channel Descriptions: X bits This field contains descriptions for MUPPET channels. This field MUST contain that amount of descriptions defined by MUPPET Channel Descriptions flag. The format of MUPPET Channel Description is described in Figure 3. Estimated Start Time: 0 or 32 bits This field represents an estimated start time of the session in Network Time Protocol (NTP) format. This field MUST NOT be present if S=0 and MUST be present if S=1. Estimated End Time: 0 or 32 bits This field represents an estimated end time of the session in NTP format. This field MUST NOT be present if E=0 and MUST be present if E=1. FEC Object Transmission Information: X bits This field contains a FEC Object Transmission Information. The format of this field is TBD. This field MUST NOT be present if F=0 and MUST be present if Luoma, et al. Expires June 14, 2004 [Page 22] Internet-Draft MUPPET December 2003 F=1. URI of the IMG transfer envelope: X bits This field contains an URI of the IMG transfer envelope containing the IMG root. The format of this field is TBD. This field MUST NOT be present if U=0 and MUST be present if U=1. Authentication Data: X bits This field contains an authentication data. The format of this field is TBD. This field MUST NOT be present if AUTH_LEN=0. MUPPET Channel Descriptions have the format described in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M | T | N | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination UDP Port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . Transport Session Identifier (16, 32 or 48 bits) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Destination IP Address (32 or 128 bits) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of MUPPET Channel Description MUPPET Channel Identifier (M): 2 bits This field indicates the MUPPET Channel type. M=0 indicates that this description is for Complete Channel. M=1 indicates that this description is for Delta Channel. M=2 indicates that this description is for Pointer Channel. Transport Session Identifier flag (T): 2 bits This field indicates the length of the Transport Session Identifier (TSI) field. Luoma, et al. Expires June 14, 2004 [Page 23] Internet-Draft MUPPET December 2003 T=0 indicates that 16 bits TSI field is to be used. T=1 indicates that 32 bits TSI field is to be used. T=2 indicates that 48 bits TSI field is to be used. Number of ALC/LCT channels (N): 4 bits Indicates the number of ALC/LCT channels (N + 1) in this MUPPET channel. Reserved: 24 bits This field is reserved for future use. It MUST be zeroed by sender and ignored by receiver. Destination UDP Port: 16 bits This field contains the Destination UDP port number for base ALC/LCT channel. Port numbers for consecutive ALC/LCT channels are derived from base port number by adding one to previous channel's port number. Transport Session Identifier: 16, 32 or 48 bits This field contains the Transport Session Identifier. If 32 bits TSI field is used then the first 16 bits of the field MUST be zeroed by sender and ignored by receiver. Destination IP Address: 32 or 128 bits This field contains the Destination multicast IP address for base ALC/LCT channel. Destination multicast IP address for consecutive ALC/LCT channels are derived from base address by adding one to previous channel's IP address. The length of this field MUST be 32 bits (IPv4 address) if A (in Figure 2) is 0 and 128 bits (IPv6 address) if A (in Figure 2) is 1. Luoma, et al. Expires June 14, 2004 [Page 24] Internet-Draft MUPPET December 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, et al. Expires June 14, 2004 [Page 25] Internet-Draft MUPPET December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Luoma, et al. Expires June 14, 2004 [Page 26]