SMPTE ST 364-2008 Television Declarative Data Essence Unidirectional Hypertext Transport Protocol.pdf

1、 Copyright 2008 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved July 3, 2008 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction . 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3

2、4 Data Transfer Features Enabled by the UHTTP Protocol . 3 4.1 Robust Delivery: Gathering Data over Multiple Transmissions 3 4.2 Metainformation in the Form of HTTP-Style Headers 4 4.3 UHTTP Protocol Versions 4 5 UHTTP Header Format 4 5.1 Basic UHTTP Header Format 4 5.2 UHTTP Extension Header Format

3、. 7 5.2.1 HTTPHeaderMap extension header . 7 6 Forward Error Correction Mechanism 9 7 HTTP-Style Headers used in UHTTP 10 7.1 Supported HTTP-Style Headers 10 8 Packaging More than One Resource. 11 9 Secutiry Considerations . 12 Annex A UUID (Universally Unique Identifier) (Informative) 13 Annex B Bi

4、bliography (Informative) . 14 Revision Notes 15 Page 1 of 15 pages SMPTE 364-2008Revision of SMPTE 364M-2001 SMPTE STANDARD for Television Declarative Data Essence Unidirectional Hypertext Transport ProtocolSMPTE 364-2008 Page 2 of 15 pages Foreword SMPTE (the Society of Motion Picture and Televisio

5、n Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices and Engineering Guidelin

6、es, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with t

7、he rules given in Part XIII of its Administrative Practices. SMPTE Standard 364M was prepared by Technology Committee D27. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Standard. However, attention

8、 is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction The unidirectional hypertext transfer protocol, or UHTTP, is a simple, robust data transfer pro

9、tocol that is designed to deliver efficiently resource data in a one-way broadcast-only environment. This transfer protocol is appropriate for delivery of HTML and other content resources using IP multicast over television vertical blanking interval (IP/VBI), in IP multicast carried in MPEG-2, or in

10、 other unidirectional transport systems. The UHTTP protocol is used to deliver television-related content resources (such as web pages, images, and scripts) which are broadcast along with a television signal. Resources sent using the UHTTP protocol are divided into a set of data segments encapsulate

11、d in UDP packets. Typically, these packets are delivered via multicast IP, but this is not required. When delivered via IP multicast, the address and port used must be exclusively for UHTTP. That is, other UDP-based protocol data would be indistinguishable from UHTTP data, and if combined, may resul

12、t in unpredictable receiver behavior. Each packet contains enough header information to begin capturing the data at any time during the broadcast, even midway through the transfer. This header contains a unique identifier (in the form of a UUID Annex A ) that uniquely identifies the transfer, and ad

13、ditional information that enables the receiver to place the data following the header in the appropriate location within the transfer. Additional header information indicates to the receiver how long to continue listening for additional data. UHTTP includes the ability to gather segments over multip

14、le retransmissions to correct for missing packets. It is also possible to group resources together for all-or-none delivery within a UHTTP transfer. The protocol also includes a simple forward error correcting mechanism which provides for the ability to restore missing data in the event of limited p

15、acket loss. SMPTE 364-2008 Page 3 of 15 pages 1 Scope This standard describes the unidirectional hypertext transfer protocol, or UHTTP. UHTTP is a one-way data transfer protocol that is designed to deliver resource data in a one-way broadcast-only environment. This transfer protocol is appropriate f

16、or delivery of HTML and other content resources using IP multicast over television vertical blanking interval (IP/VBI) and other unidirectional transport systems. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conformance la

17、nguage keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this do

18、cument is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and from which no deviat

19、ion is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a ce

20、rtain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in

21、the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“

22、should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. 3 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of

23、publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. IETF RFC 2616, Hypertext Transfer Protocol HTTP/

24、1.1 IETF RFC 2387, The MIME Multipart/Related Content-Type ISO/IEC 11578:1996, Information Technology Open Systems Interconnection Remote Procedure Call (RPC), Annex A, Universal Unique Identifier 4 Data Transfer Features Enabled by the UHTTP Protocol 4.1 Robust Ddelivery: Gathering Data over Multip

25、leTtransmissions Data can be resent via UHTTP using the same globally unique TransferlD. The data are delivered as individual segments, each of which is encapsulated within a UDP message, potentially delivered via IP multicast. Information in the header allows a receiving application to receive segm

26、ents out of order or multiple SMPTE 364-2008 Page 4 of 15 pages times. If the transfer data are sent repeatedly, the receiving service can fill in missing ranges using these retransmissions. This provides robust (though not necessarily reliable) data delivery. Additionally, forward error correction

27、(FEC), using an exclusive-or-based algorithm provides for recovery of some missing segments in the face of segment loss without retransmission. 4.2 Metainformation in the Form of HTTP-Style Headers The protocol provides for the inclusion of HTTP-style headers preceding the resource data. These heade

28、rs may include information describing the content type of the resource and content location in the form of a URL (universal resource locator). It may also be used to describe groups of resources as a multipart construction. Other metainformation, including date stamping and expiration dates, may be

29、used to provide additional information about the resource content. 4.3 UHTTP Protocol Versions Two versions of the UHTTP protocol are defined in this standard. Version 0, the original version, limits the size of the delivered resources to approximately 4 gigabytes each. Version 1 supports delivery o

30、f resources as large as approximately 256 terabytes. The only differences between the two versions are the value in the “version“ field of the UHTTP header, the sizes of the “retransmit expiration,“ “resource size“ and “segment start byte offset“ fields of the UHTTP header, and the sizes of the “HTT

31、P header start“ and “HTTP body size“ fields in the HTTPHeaderMap.“ 5 UHTTP Header Format 5.1 Basic UHTTP Header Format This clause describes the format of the message packets that carry UHTTP data. It describes the information needed to create the messages using the protocol on the broadcast side an

32、d to turn those messages back into resources on the receiving side. The UHTTP header is at the start of every UHTTP IP/UDP datagram. All values are network byte order. For version 0 of the protocol, the UHTTP header has the format given in Figure 1. For version 1 of the protocol, the UHTTP header ha

33、s the format given in Figure 2. The fields are described in Table 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version |X|H|C| PcktsInXORBlk | retransmit expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

34、-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- transfer ID -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | resource size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | segment start byte offset | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

35、=+=+=+=+=+=+=+=+=+=+=| | payload or extension header | : : Figure 1 UHTTP header for version 0 of the protocol SMPTE 364-2008 Page 5 of 15 pages 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version |X|H|C| PcktsInXORBlk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- retransmit

36、 expiration -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- -+ | | +- -+ | | +- transfer ID -+ | | +- -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | resource size | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | segment start byte offset | +- -+ | | +=+=+

37、=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + payload or extension header + : : Figure 2 UHTTP header for version 1 of the protocol SMPTE 364-2008 Page 6 of 15 pages Table 1 UHTTP fields Name Size Description Version 5 bits Describes the version of the protocol. ExtensionHeader (X) 1 bit When set, this bit indicat

38、es that one or more extension header fields are present and immediately follow the main UHTTP header. HTTPHeadersPrecede (H) 1 bit A bit flag that, when set to 1, indicates that HTTP-style headers precede the resource data. These HTTP-style headers are con-sidered part of the data when calculating t

39、he ResourceSize and SegStartByte fields, as well as for forward error correction. This bit must be set in all packets associated with a UHTTP transfer when HTTP-style headers precede the data. When set to zero, no HTTP-style headers precede the resource data. CRCFollows (C) 1 bit When the CRCFollows

40、 bit is set to 1, a 32-bit CRC is calculated and can be used to detect possible corruption in the data delivered via UHTTP. Using the MPEG-2 CRC algorithm, the CRC is calculated on the complete data, including HTTP-style headers, if any. It is then appended to the end of the data in the last logical

41、 packet. This CRC field is considered part of the data for the purposes of calcu-lating the resource length and calculating the forward error correction. The bit must be set in all packets associated with a UHTTP transfer when a CRC is used. PacketsInXORBlock (PcktsInXORBlk) 1 byte Describes the num

42、ber of packets in a forward error correction block, including the forward error correction packet. Set to zero when no forward error correction is used. See Section 6 for details on the forward error correction mechanism. RetransmitExpiration 2 bytes for version 0; 4 bytes for version 1 Describes th

43、e time in seconds over which the resource may be retransmitted. This indicates how long the receiving software should wait to try to recover missing packets that follow in re-transmissions of the same resource. This allows a resource to be carouseled, or sent repeatedly to increase the chances of de

44、livery without missing segments. Set to zero if the resource will not be retransmitted. Set to maximum if the software should continue listening. The RetransmissionExpiration field should be updated to remain accurate during retransmissions, including the current trans-mission. TransferID 16 bytes G

45、lobally unique identifier (GUID Annex A) for the UHTTP transfer. This ID allows receiving software to identify which segments corres-pond to a given transfer, and determine when retransmission occurs. ResourceSize 4 bytes for version 0; 6 bytes for version 1 Size of the complete resource data itself

46、 (excluding segment headers, XOR segments, and padding for exclusive-or correction). This length does include the length of the HTTP-style headers, if any, as well as the 4-byte CRC, if the CRCFollows bit is set to 1. SegmentStartByteOffset (SegStartByte) 4 bytes for version 0; 6 bytes for version 1

47、 Start offset for the first byte in the transfer for this data segment. When XOR data are used to replace missing packets, SegStartByte includes the XOR data as well as the resource data, and optional HTTP-style headers and CRC. This allows for determining where all packets fit regardless of delivery order. The exclusive-or correction packet looks like any other UHTTP packet. Its data payload is simply the exclu