idnits 2.17.1
draft-bouazizi-tsvwg-mmtp-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 3 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 205: '... MUST be set to 0 by the sender and ...'
RFC 2119 keyword, line 848: '... or "reserved" (r) MUST by set to 0 by...'
RFC 2119 keyword, line 1280: '... The MMTP sender SHALL make use of thi...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 478 has weird spacing: '...16 bits indic...'
== Line 481 has weird spacing: '... 4 bits this ...'
== Line 484 has weird spacing: '...: 1 bit this ...'
== Line 488 has weird spacing: '... 2 bits this ...'
-- The document date (March 21, 2016) is 2952 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC3550' is defined on line 1325, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force I. Bouazizi
3 Internet-Draft Samsung Research America
4 Intended status: Informational March 21, 2016
5 Expires: September 22, 2016
7 MPEG Media Transport Protocol (MMTP)
8 draft-bouazizi-tsvwg-mmtp-01
10 Abstract
12 The MPEG Media Transport Protocol (MMTP) is a transport protocol that
13 is designed to support download, progressive download, and streaming
14 applications simultaneously. MMTP provides a generic media streaming
15 mode by optimizing the delivery of generic media data encapsulated
16 according to the ISO-Base Media File Format (ISOBMFF). In the file
17 delivery mode, MMTP supports the delivery of any type of file. MMTP
18 may used in IP unicast or multicast delivery and supports both
19 Forward Error Correction (FEC) and retransmissions for reliable
20 delivery of content.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on September 22, 2016.
39 Copyright Notice
41 Copyright (c) 2016 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2.1. Difference to RTP . . . . . . . . . . . . . . . . . . . . 4
59 3. Packet Header Field . . . . . . . . . . . . . . . . . . . . . 5
60 3.1. MMTP Header Extension . . . . . . . . . . . . . . . . . . 8
61 4. The MMTP payload . . . . . . . . . . . . . . . . . . . . . . 9
62 4.1. The ISOBMFF Mode . . . . . . . . . . . . . . . . . . . . 9
63 4.1.1. MMTP payload header for ISOBMFF mode . . . . . . . . 10
64 4.2. Generic File Delivery Mode . . . . . . . . . . . . . . . 13
65 4.2.1. GFD Information . . . . . . . . . . . . . . . . . . . 14
66 4.2.1.1. GFD Table . . . . . . . . . . . . . . . . . . . . 14
67 4.2.1.2. CodePoints . . . . . . . . . . . . . . . . . . . 15
68 4.2.1.3. Content-Location Template . . . . . . . . . . . . 17
69 4.2.1.4. File metadata . . . . . . . . . . . . . . . . . . 18
70 4.2.1.5. MMTP payload header for GFD mode . . . . . . . . 19
71 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 20
72 5.1. General Operation . . . . . . . . . . . . . . . . . . . . 20
73 5.2. Delivery ISOBMFF objects . . . . . . . . . . . . . . . . 21
74 5.2.1. MMTP sender operation . . . . . . . . . . . . . . . . 21
75 5.2.1.1. Timed Media Data . . . . . . . . . . . . . . . . 21
76 5.2.1.2. Non-Timed Media Data . . . . . . . . . . . . . . 22
77 5.2.2. MMTP receiver operation . . . . . . . . . . . . . . . 23
78 5.3. Delivering Generic Objects . . . . . . . . . . . . . . . 24
79 5.3.1. MMTP sender operation . . . . . . . . . . . . . . . . 24
80 5.3.2. GFD Payload . . . . . . . . . . . . . . . . . . . . . 26
81 5.3.3. GFD Table Delivery . . . . . . . . . . . . . . . . . 26
82 5.3.4. MMTP receiver operation . . . . . . . . . . . . . . . 26
83 6. Session Description information . . . . . . . . . . . . . . . 28
84 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 28
85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
88 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
89 10.2. Informative References . . . . . . . . . . . . . . . . . 29
90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
92 1. Introduction
94 The MMT protocol is an application layer transport protocol that is
95 designed to efficiently and reliably transport multimedia data. MMTP
96 can be used for both timed and non-timed media data. It supports
97 several features, such as media multiplexing and network jitter
98 estimation. These features are designed to deliver content composed
99 of various types of encoded media data more efficiently. MMTP may
100 run on top of existing network protocols such as UDP and IP. In this
101 specification, the carriage of data formatted differently than the
102 MMTP payload format as specified in Section 4 by MMTP is not defined.
103 The MMT protocol is designed to support a wide variety of
104 applications and does not specify congestion control. The congestion
105 control function is left for the application implementation. MMTP
106 supports the multiplexing of different media data such as ISOBMFF
107 files from various Assets over a single MMTP packet flow. It
108 delivers multiple types of data in the order of consumption to the
109 receiving entity to help synchronization between different types of
110 media data without introducing a large delay or requiring large
111 buffer. MMTP defines two packetization modes, Generic File Delivery
112 mode as specified in Section 4.2 and the ISOBMFF mode as specified in
113 Section 4.1. The former defines a mode for packetizing media data
114 based on the size of the payload to be carried and the latter defines
115 a mode for packetizing media data based on the type of data to be
116 carried in the payload. MMTP supports simultaneous transmission of
117 packets using the two different modes in a single delivery session.
118 MMTP also provides means to calculate and remove jitter introduced by
119 the underlying delivery network, so that constant end-to-end delay
120 for data delivery can be achieved. By using the delivery timestamp
121 field in the packet header, jitter can be precisely estimated without
122 requiring any additional signalling information and protocols.
124 2. Rationale
126 MMTP provides a generic media transport protocol that inherently
127 supports virtually any media type and codec. For this purpose, MMTP
128 is designed to support a limited set of payload types agnostic to the
129 media type or coding format, but providing generic information to
130 serve the needs of different multimedia delivery services. The MMTP
131 payload format is defined as a generic payload format for the
132 packetization of media data. It is agnostic to media codecs used for
133 encoded media data, so that any type of media data that are
134 encapsulated in the ISOBMFF format can be packetized into MMTP
135 payloads. The MMTP payload format also supports fragmentation and
136 aggregation of data to be delivered. MMTP supports both streaming
137 and download modes, where the streaming mode is optimized for
138 packetized streaming of ISO-Base Media File formatted files (ISOBMFF
139 mode) and the download mode allows for flexible delivery of generic
140 files (GFD mode). In addition, MMTP delivers streaming support data
141 such as Application Layer Forward Error Correction (AL-FEC) repair
142 data.
144 2.1. Difference to RTP
146 The RTP protocol was initially designed to support multi-party real-
147 timed communication conferencing over the Internet. Key concern at
148 that time was scalability of RTP to a large number of participants
149 and dealing with media synchronization. Consequently, the RTP
150 protocol is a mixture of transport and presentation layer functions.
151 RTP supports a wide range of media types and codecs through the
152 definition of codec-specific payload formats.
154 A set of issues arise when deploying RTP for media delivery, some of
155 which are provided in the following list:
157 Lack of Multiplexing: RTP usually requires two separate ports for
158 every media session. Rich media services have several service
159 components, each of which would require an RTP/RTCP port pair.
160 Although some level of multiplexing is possible in RTP (i.e. RTP
161 and RTCP multiplexing as defined in [RFC5761], it is not clear
162 that all RTP implementations support it and this still does not
163 solve the problem. This is one of the reasons the industry is
164 moving towards HTTP-based streaming where a single port is used.
165 MMTP uses a single port and multiplexes all media streams of a
166 service as well as the related signaling and any non-real time
167 objects into a single MMTP flow that is self-contained and self-
168 describing.
170 Costly Server Maintenance One of the major issues with RTP is the
171 costly operation of dedicated streaming servers that need to be
172 updated to support any new media codecs. The server must be
173 upgraded to support the new payload format for any new media codec
174 that the service provider wishes to use. MMTP solves this issue
175 by supporting a single payload format for media streaming based on
176 the ISOBMFF file format. Any media codec that can be encapsulated
177 into the ISOBMFF file format can be streamed without any
178 modifications by an MMT server.
180 Coupling Delivery and Presentation RTP carries the presentation
181 timestamp of the encapsulated media data, which corresponds to the
182 sampling instant of the first media sample/sub-sample contained in
183 the packet payload. As the delivery timestamp is not provided in
184 RTP, it is often assumed that the presentation timestamp is equal
185 to the delivery timestamp. This coupling may make sense for real-
186 time conferencing use cases but is generally not useful for
187 streaming of on-demand content as the receiver will not be aware
188 of the exact delivery time and will usually use external media for
189 controlling the presentation time (so that the RTP timestamp will
190 only be use for intra-media synchronization). MMTP decouples
191 media delivery and media presentation completely by carrying only
192 the delivery timestamp at the MMTP protocol level. The
193 presentation time is controlled by external Presentation
194 Information that may as well be carried as part of the MMTP flow,
195 whereas the intra-synchronization is provided by the ISOBMFF file
196 format. The delivery timestamp may be used for de-jittering,
197 retransmissions, and other purposes.
199 3. Packet Header Field
201 The MMTP header is of variable size, where the size of the header may
202 be deduced from the header flags. In the MMTP header, all integer
203 fields are carried in "big-endian" or "network order" format, so that
204 the most significant byte is first. Bits marked as "reserved" (r)
205 MUST be set to 0 by the sender and ignored by receivers in this
206 version of the specification. Unless otherwise noted, numeric
207 constants in this specification are in decimal form (base 10). The
208 format of the MMTP header is depicted in Figure 1.
210 0 1 2 3
211 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
212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
213 |V=0|C|FEC|r|X|R|RES| type | packet_id |
214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
215 | timestamp |
216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
217 | packet_sequence_number |
218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
219 | packet_counter |
220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
221 | header_extension ....
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
223 | payload data ....
224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
226 Figure 1: MMTP Header
228 The function and length of each field in the MMTP header is specified
229 as follows:
231 version (V): 2 bits
233 indicates the version number of the MMTP protocol. This field
234 shall be set to "00" to comply with this specification.
236 packet_counter_flag (C): 1 bit
238 "1" in this field indicates that the packet_counter field is
239 present.
241 FEC_type (FEC): 2 bits
243 indicates whether the payload carries FEC source data or repair
244 data. Valid values of this field are listed in Table 1 below.
245 Depending on the FEC scheme, additional payload header may be
246 added, for instance to identify the contained symbol(s).
248 reserved (r): 1 bit
250 reserved for future use.
252 extension_flag (X): 1 bit
254 when set to "1" this flag indicates that the header_extension
255 field is present.
257 RAP_flag (R): 1 bit
259 when set to "1" this flag indicates that the payload contains a
260 Random Access Point (RAP) to the data stream of that data type.
261 The exact semantics of this flag are defined by the data type
262 itself. The RAP_flag shall be set to mark data units of Fragment
263 Type value "0" and "1" and for data units that contain a sync
264 sample or a fragment thereof in the case of timed media and for
265 the primary item of non-timed data.
267 reserved (RES): 2 bits
269 reserved for future use.
271 type: 6 bits
273 this field indicates the type of payload data. Payload type
274 values are defined in Table 2.
276 packet_id: 16 bits
278 this field is an integer value that can be used to identify
279 related media data, for example media that belong to the same
280 media asset. The packet_id is unique throughout the lifetime of
281 the delivery session and for all MMTP flows delivered by the same
282 MMTP sender.
284 packet_sequence_number: 32 bits
286 an integer value that is used to distinguish between packets that
287 have the same packet_id. The value of this field should start
288 from an arbitrary value and shall be incremented by one for each
289 new MMTP packet. It wraps around to "0" after the maximum value
290 is reached.
292 timestamp: 32 bits
294 specifies the time instance of MMTP packet delivery based on UTC.
295 The format is the "short-format" as defined in clause 6 of
296 [RFC5905], NTP version 4. This timestamp specifies the sending
297 time at the first byte of MMTP packet. It is required that an
298 MMTP sender should provide accurate time information that are
299 synchronized with UTC.
301 packet_counter: 32 bits
303 an integer value for counting MMTP packets. It is incremented by
304 1 when an MMTP packet is sent regardless of its packet_id value.
305 This field starts from arbitrary value and wraps around to "0"
306 after its maximum value is reached.
308 header_extension:
310 this field contains user-defined information. The header
311 extension mechanism is provided to allow for proprietary
312 extensions to the payload format to enable applications and media
313 types that require additional information to be carried in the
314 payload format header. The header extension mechanism is designed
315 in a such way that it may be discarded without impacting the
316 correct processing of the MMTP payload. The header extension
317 shall have the format as shown in Figure 2. This specification
318 does not specify any particular header extension.
320 +-------+--------------------------------------------------------+
321 | Value | Description |
322 +-------+--------------------------------------------------------+
323 | 0 | MMTP packet without AL-FEC protection |
324 | 1 | MMTP packet with AL-FEC protection (FEC source packet) |
325 | 2 | MMTP packet for repair symbol(s) (FEC repair packet) |
326 | 3 | Reserved for future use |
327 +-------+--------------------------------------------------------+
329 Table 1: FEC Type
331 +-----------+------------+------------------------------------------+
332 | Value | Data type | Definition of data unit |
333 +-----------+------------+------------------------------------------+
334 | 0x00 | ISOBMFF | The packet carries a media-aware |
335 | | file | fragment of the ISOBMFF file |
336 | 0x01 | Generic | The packet contains a generic object |
337 | | object | such as a complete ISOBMFF file or an |
338 | | | object of another type or a chunk |
339 | | | thereof. |
340 | 0x02 | signalling | one or more signalling messages or a |
341 | | message | fragment of a signalling message. The |
342 | | | syntax and semantics of signalling |
343 | | | messages are out of scope of the current |
344 | | | memo. |
345 | 0x03 | repair | The packet carries a single complete FEC |
346 | | symbol | repair symbol |
347 | 0x04-0x1F | reserved | reserved for ISO use |
348 | 0x20-0x3F | reserved | reserved for private use |
349 +-----------+------------+------------------------------------------+
351 Table 2: Data type and definition of data unit
353 3.1. MMTP Header Extension
355 0 1 2 3
356 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
357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
358 | type | length |
359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
360 | header_extension_value ....
361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
363 Figure 2: MMTP Header Extension
365 The function and length of each field in the MMTP header extension is
366 as follows:
368 type: 16 bits
370 indicates the unique identification of the following header
371 extension.
373 length: 16 bits
375 indicates the length of header_extension_value field in byte.
377 header_extension_value
378 provides the extension information. The format of this field is
379 out of scope of this specification.
381 4. The MMTP payload
383 The MMTP payload is a generic payload format to packetize and carry
384 media data such as ISOBMFF files, generic objects, and other
385 information for consumption of a media service using the MMT
386 protocol. The appropriate MMTP payload format shall be used to
387 packetize ISOBMFF files, and generic objects. An MMTP payload may
388 carry complete ISOBMFF files or fragments of ISOBMFF files,
389 signalling messages, generic objects, repair symbols of AL-FEC
390 schemes, etc. The type of the payload is indicated by the type field
391 in the MMT protocol packet header. For each payload type, a single
392 data unit for delivery as well as a type specific payload header are
393 defined. For example, fragment of an ISOBMFF file (e.g. a data unit)
394 is considered as a single data unit when MMTP payload carries ISOBMFF
395 file fragments. The MMT protocol may aggregate multiple data units
396 with the same data type into a single MMTP payload. It can also
397 fragment a single data unit into multiple MMTP packets. The MMTP
398 payload consists of a payload header and payload data. Some data
399 types may allow for fragmentation and aggregation, in which case a
400 single data unit is split into multiple fragments or a set of data
401 units are delivered in a single MMTP packet. Each data unit may have
402 its own data unit header depending on the type of the payload. For
403 types that do not require a payload type specific header no payload
404 type header is present and the payload data follows the MMTP header
405 immediately. Some fields of the MMTP packet header are interpreted
406 differently depending on the payload type. The semantics of these
407 fields will be defined by the payload type in use.
409 4.1. The ISOBMFF Mode
411 The delivery of ISOBMFF files to MMT receivers using the MMT protocol
412 requires a packetization and depacketization procedure to take place
413 at the MMTP sender and MMTP receiver, respectively. The
414 packetization procedure transforms an ISOBMFF file into a set of MMTP
415 payloads that are then carried in MMTP packets. The MMTP payload
416 format allows for fragmentation of the MMTP payload to enable the
417 delivery of large payloads. It also allows for the aggregation of
418 multiple MMTP payload data units into a single MMTP payload, to cater
419 for smaller data units. At the receiving entity depacketization is
420 performed to recover the original ISOBMFF file data. Several
421 depacketization modes are defined to address the different
422 requirements of the overlaying applications. It the payload type is
423 0x00, the ISOBMFF file is fragmented in a media aware way allowing
424 the transport layer to identify the nature and priority of the
425 fragment that is carried. A fragment of an ISOBMFF file may either
426 be ISOBMFF file metadata, a Movie Fragment metadata, a data unit, or
427 a non-timed media data item.
429 4.1.1. MMTP payload header for ISOBMFF mode
431 The payload type specific header is provided in Figure 3.
433 0 1 2 3
434 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
435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
436 | length | FT |T|f_i|A| frag_counter |
437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
438 | sequence_number |
439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
440 | DU_length | DU_Header ....
441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
442 | DU payload ....
443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
445 Figure 3: Structure of the MMTP payload header for the ISOBMFF mode
447 For payload that carries a data unit, the DU header is specified
448 depending on the value of the T flag indicating wether the carried
449 data is timed or non-timed media. For timed media (i.e. when the
450 value of T is set to "1") the DU header fields are shown in Figure 4.
451 For non-timed media (T is set to "0"), the DU header is defined as
452 shown in Figure 4.
454 0 1 2 3
455 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
456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457 | movie_fragment_sequence_number |
458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459 | sample_number |
460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461 | offset |
462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
463 | priority | dep_counter |
464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
466 Figure 4: The DU header for a timed-media data unit
468 For non-timed media, the DU header fields are shown in Figure 5.
470 0 1 2 3
471 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
472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473 | item_ID |
474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
476 Figure 5: The DU header for a non-timed media data unit
478 length: 16 bits indicates the length of payload excluding this field
479 in byte.
481 Fragment Type (FT): 4 bits this field indicates the fragment type
482 and its valid values are shown in Table 3.
484 Timed Flag (T): 1 bit this flag indicates if the fragment is from an
485 ISOBMFF file that carries timed (value 1) or non-timed media
486 (value 0).
488 Fragmentation Indicator (f_i) : 2 bits this field indicates the
489 fragmentation indicator contains information about fragmentation
490 of data unit in the payload. The four values are listed in
491 Table 4. If the value is set to "00", the aggregation_flag can be
492 presented.
494 +------+--------------+---------------------------------------------+
495 | FT | Description | Content |
496 +------+--------------+---------------------------------------------+
497 | 0 | ISOBMFF | contains the ftyp, mmpu, moov, and meta |
498 | | metadata | boxes as well as any other boxes that |
499 | | | appear in between. |
500 | 1 | Movie | contains the moof box and the mdat box, |
501 | | fragment | excluding all media data inside the mdat |
502 | | metadata | box. |
503 | 2 | a data unit | contains a sample or sub-sample of timed |
504 | | | media data or an item of non-timed media |
505 | | | data. |
506 | 3~15 | Reserved for | reserved |
507 | | private use | |
508 +------+--------------+---------------------------------------------+
510 Table 3: Data type and definition of data unit
512 +----------------+--------------------------------------------------+
513 | fragmentation | Description |
514 | indicator | |
515 +----------------+--------------------------------------------------+
516 | 00 | Payload contains one or more complete data |
517 | | units. |
518 | 01 | Payload contains the first fragment of data unit |
519 | 10 | Payload contains a fragment of data unit that is |
520 | | neither the first nor the last part. |
521 | 11 | Payload contains the last fragment of data unit. |
522 +----------------+--------------------------------------------------+
524 Table 4: Values for fragmentation indicator
526 The following flags are used to indicate the presence of various
527 information carried in the MMTP payload. Multiple bits can be set
528 simultaneously.
530 aggregation_flag (A: 1 bit)
532 when set to "1" indicates that more than 1 data unit is present in
533 the payload, i.e. multiple data units are aggregated.
535 fragment_counter (frag_count: 8 bits)
537 this field specifies the number of payload containing fragments of
538 same data unit succeeding this MMTP payload. This field shall be
539 "0" if aggregation_flag is set to "1".
541 sequence_number (32 bits)
543 the sequence number of the ISOBMFF to which this fragment belongs.
545 DU_length (16 bits)
547 this field indicates the length of the data following this field.
548 When aggregation_flag is set to "0", this field shall not be
549 present. When aggregation_flag is set to "1", this field shall
550 appear as many times as the number of the data units aggregated in
551 the payload and preceding each aggregated data unit.
553 DU_Header
555 The header of the data unit, which depends on the FT field. A
556 header is only defined for the media unit fragment type, with
557 different semantics for timed and non-timed media as identified by
558 the T flag.
560 movie_fragment_sequence_number (32 bits)
562 the sequence number of the movie fragment to which the media data
563 of this data unit belongs. (see [isopart12] sub-clause 8.5.5)
565 sample_number (32 bits)
567 the sample number of the sample to which the media data of the
568 data unit. (see [isopart12] sub-clause 8.8.8)
570 offset (32 bits)
572 offset of the media data of this data unit inside the referenced
573 sample.
575 subsample_priority (priority: 8 bits)
577 provides the priority of the media data carried by this data unit
578 compared to other media data of the same ISOBMFF file. The value
579 of subsample_priority shall be between "0" and "255", with higher
580 values indicating higher priority.
582 dependency_counter (dep_counter: 8 bits)
584 indicates the number of data units that depend on their media
585 processing upon the media data in this data unit.
587 Item_ID (32 bits)
589 the identifier of the item that is carried as part of this data
590 unit.
592 For the FT types "0" and "1", no additional DU header is defined.
594 4.2. Generic File Delivery Mode
596 MMTP also supports the transport of generic files and Assets and uses
597 payload type "0x01" as defined in Table 3. An Asset consists of one
598 or more files that are logically grouped and share some commonality
599 for an application, e.g. Segments of a Dynamic Adaptive Streaming
600 over HTTP (DASH) Representation, a sequence of ISOBMFF files, etc.
601 In the generic file delivery (GFD) mode, an Asset is transported by
602 using MMTP"s GFD payload type. Each file delivered using the GFD
603 mode requires association of transport delivery information. This
604 includes, but is not limited to information such as the transfer
605 length. Each file delivered using the GFD mode may also have
606 associated content specific parameters such as Name, Identification,
607 and Location of file, media type, size of the file, encoding of the
608 file or message digest of the file. In alignment with HTTP/1.1
609 protocol as defined in [RFC2616], each file within one generic Asset
610 may have assigned any meta-information about the entity body, i.e.
611 the delivered file. The details are also defined in Section 4.2.1.
613 4.2.1. GFD Information
615 In the GFD mode, each file gets assigned the following parameters:
617 o the asset to which each object belongs to. Objects that belong to
618 the same asset are considered as logically connected, e.g. all
619 DASH segments of a Representation and also across Representations
620 that extend over multiple DASH Periods and which carry pieces of
621 the same content.
623 o Each object is associated with a unique identifier within the
624 scope of the packet_id.
626 o each object is associated with a CodePoint. A CodePoint
627 associates a specific object and object transport properties.
628 Packets with the same TOI shall have the same CodePoint value.
629 For more details see 0.
631 4.2.1.1. GFD Table
633 The GFD table provides a list of CodePoints as defined in
634 Section 4.2.1.2. Each CodePoint gets dynamically assigned a
635 CodePoint value. Table 5 shows the structure and semantics of the
636 GFD table.
638 +-----------------------+------+------------------------------------+
639 | Element or Attribute | Use | Description |
640 | Name | | |
641 +-----------------------+------+------------------------------------+
642 | GFDTable | | The element carries a GFDTable |
643 | CodePoint | 1..N | defines all CodePoints in the MMTP |
644 | | | session |
645 +-----------------------+------+------------------------------------+
647 Table 5: GFD Table
649 Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with
650 Default Value, CM=Conditionally Mandatory. For elements:
651 minOccurs..maxOccurs (N=unbounded) Elements are bold; attributes are
652 non-bold and preceded with an @
654 4.2.1.2. CodePoints
656 A CodePoint value can be used to obtain following information:
658 o the maximum transfer length of any object delivered with this
659 CodePoint signalling
661 In addition, a CodePoint may include following information
663 o the actual transfer length of the objects
665 o any information that may be present in the entity-header as
666 defined in [RFC2616] section 7.1.
668 o A Content-Location-Template as defined in Section 4.2.1.3 using
669 the TOI and packet_id parameter, if present. The TOI and
670 packet_id may be used to generate the Content-Location for each
671 TOI and packet_id. If such a template is present, the processing
672 in Section 4.2.1.3 shall be used to generate the Content-Location
673 and the value of the URI shall be treated as the Content-Location
674 field in the entity-header.
676 o Specific information on the content, for example how the content
677 is packaged, etc.
679 Within one session, at most 256 CodePoints may be defined. The
680 definition of CodePoints is dynamically setup in the MMTP Session
681 Description. The CodePoint semantics are described in Table 6.
683 +--------------------------+----------+-----------------------------+
684 | Element or Attribute | Use | Description |
685 | Name | | |
686 +--------------------------+----------+-----------------------------+
687 | @value | M | defines the value of the |
688 | | | CodePoint in the MMTP |
689 | | | session as provided in the |
690 | | | CodePoint value of the MMTP |
691 | | | packet header containing |
692 | | | the GFD payload. The value |
693 | | | shall be between 1 and 255. |
694 | | | The value 0 is reserved. |
695 | @fileDeliveryMode | M | specifies the file delivery |
696 | | | mode according to Section |
697 | | | 4.2. |
698 | @maximumTransferLength | M | specifies the maximum |
699 | | | transfer length in bytes of |
700 | | | any object delivered with |
701 | | | this CodePoint in this MMTP |
702 | | | session. |
703 | @constantTransferLength | OD | specifies if all objects |
704 | | default: | delivered by this CodePoint |
705 | | 'false' | have constant transfer |
706 | | | length. If this attribute |
707 | | | is set to TRUE, all objects |
708 | | | shall have transfer length |
709 | | | as specified in the |
710 | | | @maximumTransferLength |
711 | | | attribute. |
712 | @contentLocationTemplate | O | specifies a template to |
713 | | | generate the Content- |
714 | | | Location of the entity |
715 | | | header. |
716 | EntityHeader | 0..1 | specifies a full entity |
717 | | | header in the format as |
718 | | | defined in [RFC2616] |
719 | | | section 7.1. The entity |
720 | | | header applies for all |
721 | | | objects that are delivered |
722 | | | with the value of this |
723 | | | CodePoint. |
724 +--------------------------+----------+-----------------------------+
726 Table 6: CodePoint Semantics
728 Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with
729 Default Value, CM=Conditionally Mandatory. For elements:
731 minOccurs..maxOccurs (N=unbounded) Elements are bold; attributes are
732 non-bold and preceded with an @
734 4.2.1.3. Content-Location Template
736 A CodePoint may include a @contentLocationTemplate attribute. The
737 value of @contentLocationTemplate attribute may contain one or more
738 of the identifiers listed in Table 7. In each URL, the identifiers
739 from Table 7 shall be replaced by the substitution parameter defined
740 in Table 7. Identifier matching is case-sensitive. If the URL
741 contains unescaped $ symbols which do not enclose a valid identifier
742 then the result of URL formation is undefined. The format of the
743 identifier is also specified in Table 7. Each identifier may be
744 suffixed, within the enclosing "$" characters following this
745 prototype: %0[width]d The width parameter is an unsigned integer that
746 provides the minimum number of characters to be printed. If the
747 value to be printed is shorter than this number, the result shall be
748 padded with zeros. The value is not truncated even if the result is
749 larger. The @contentLocationTemplate shall be authored such that the
750 application of the substitution process results in valid URIs.
751 Strings outside identifiers shall only contain characters that are
752 permitted within URLs according to [RFC3986].
754 +--------------+--------------------------+-------------------------+
755 | $Identifier$ | Substitution parameter | Format |
756 +--------------+--------------------------+-------------------------+
757 | $$ | Is an escape sequence, | not applicable |
758 | | i.e. "$$" is replaced | |
759 | | with a single "$" | |
760 | $PacketID$ | This identifier is | The format tag may be |
761 | | substituted with the | present.If no format |
762 | | value of the packet_id | tag is present, a |
763 | | of the associated MMT | default format tag with |
764 | | flow. | width=1 shall be used. |
765 | $TOI$ | This identifier is | The format tag may be |
766 | | substituted with the | present. If no format |
767 | | Object Identifier of the | tag is present, a |
768 | | corresponding MMTP | default format tag with |
769 | | packet containing the | width=1 shall be used. |
770 | | GFDpayload. | |
771 +--------------+--------------------------+-------------------------+
773 Table 7: Identifiers for URL templates
775 4.2.1.4. File metadata
777 Files can be transported using the GFD mode of the MMT protocol.
778 Furthermore, the GFD mode can also be used to transport entities
779 where an entity is defined according to section 7 of [RFC2616]. An
780 entity consists of meta-information in the form of entity-header
781 fields and content in the form of an entity-body (the file), as
782 described in section 7 of [RFC2616]. This enables that files may get
783 assigned information by inband delivery in a dynamic fashion. For
784 example, it enables the association of a Content-Location, the
785 Content-Size, etc. The file delivery mode shall be signaled in the
786 CodePoint.
788 +--------------+--------------------------------+-------------------+
789 | Value | Description | Definition |
790 | $Identifier$ | | |
791 +--------------+--------------------------------+-------------------+
792 | 1 | The transport object is a file | in Section |
793 | | | 4.2.1.4.1 |
794 | 2 | The delivered object is an | in Section |
795 | | entity consisting of an | 4.2.1.4.2 |
796 | | entity-header and the file | |
797 +--------------+--------------------------------+-------------------+
799 Table 8: File Delivery Modes for GFD
801 4.2.1.4.1. Regular File
803 In case of the regular file, the object represents a file. If the
804 CodePoint defined in the GFD table contains entity-header fields or
805 entity-header fields can be generated, then all of these entity-
806 header fields shall apply to the delivered file.
808 4.2.1.4.2. Regular Entity
810 In case of the regular entity, the object represents an entity as
811 defined in section 7 of [RFC2616]. An entity consists of entity-
812 header fields and an entity-body. If the CodePoint defined in the
813 GFD table contains entity-header fields or entity-header fields can
814 be generated, then all of these entity-header fields apply to the
815 delivered file. If the entity-header field is present in both
816 locations, then the entity header field in the entity-header
817 delivered with the object overwrites the one in the CodePoint.
819 4.2.1.5. MMTP payload header for GFD mode
821 The GFD mode of MMTP delivers regular files. When delivering regular
822 files, the object represents a file. If the CodePoint defined in the
823 MMTP Session description contains entity-header fields or entity-
824 header fields can be generated, then all of these entity-header
825 fields shall apply to the delivered file. The payload packets sent
826 using MMTP shall include a GFD payload header and a GFD payload as
827 shown in Figure 6. In some special cases a MMTP sender may need to
828 produce packets that do not contain any payload. This may be
829 required, for example, to signal the end of a session.
831 0 1 2 3
832 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
833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
834 |C|L|B| CP | RES | TOI |
835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
836 | TOI | start_offset |
837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
838 | start_offset |
839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
840 | Generic File Delivery payload |
841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
843 MMTP payload header for GFD mode
845 Figure 6
847 The GFD payload header as shown in Figure 6 and has a variable size.
848 Bits designated as "padding" or "reserved" (r) MUST by set to 0 by
849 MMTP sender s and ignored by receivers. Unless otherwise noted,
850 numeric constants in this specification are in decimal form
852 C (1 bit)
854 indicates that this is the last packet for this session.
856 L (1 bit)
858 indicates that this is the last delivered packet for this object.
860 B (1 bit)
862 indicates that this packet contains the last byte of the object.
864 CodePoint (CP: 8 bits)
865 An opaque identifier that is passed to the packet payload decoder
866 to convey information on the packet payload. The mapping between
867 the CodePoint and the actual codec is defined on a per session
868 basis and communicated out-of-band as part of the session
869 description information.
871 RES (5 bits)
873 a reserved field that should be set to "0".
875 Transport Object Identifier (TOI: 32 bits)
877 The object identifier should be set to a unique identifier of the
878 generic object that is being delivered. The mapping between the
879 object identifier and the object information (such as URL and MIME
880 type) may be done explicitly or implicitly. For example a
881 sequence of DASH segments may use the segment index as the object
882 identifier and a numerical representation identifier as the
883 packet_id. This mapping may also be performed using a signalling
884 message
886 start_offset (48 bits)
888 the location of the current payload data in the object.
890 5. Protocol Operation
892 In this section, we describe the behavior of an MMTP receiver and of
893 an MMTP sender when operating the MMTP protocol using different
894 payload types.
896 5.1. General Operation
898 An MMTP session consists of one MMTP transport flow. MMTP transport
899 flow is defined as all packet flows that are delivered to the same
900 destination and which may originate from multiple MMTP senders. In
901 the case of IP, destination is the IP address and port number. A
902 single Package may be delivered over one or multiple MMTP transport
903 flows. A single MMTP transport flow may deliver data from multiple
904 Packages. An MMTP transport flow may carry multiple Assets. Each
905 Asset is associated with a unique packet_id within the scope of the
906 MMTP session. MMTP provides a streaming-optimized mode (the ISOBMFF
907 mode) and a file download mode (the GFD mode). The Asset is
908 delivered as a set of related objects denoted as an object flow.
909 Object may either be an ISOBMFF file, file or signalling message.
910 Each object flow shall either be carried in ISOBMFF mode or GFD mode,
911 however, the delivery of one Package may be performed using a mix of
912 the 2(two) modes, i.e. some Assets may be delivered using the ISOBMFF
913 mode and others using the GFD mode. The MMTP packet sub-flow is the
914 subset of the packets of an MMTP packet flow that share the same
915 packet_id. The object flow is transported as an MMTP packet sub-
916 flow. The ISOBMFF mode supports the packetized streaming of an
917 ISOBMFF file. The GFD mode supports flexible file delivery of any
918 type of file or sequence of files. MMTP is suitable for unicast as
919 well as multicast media distribution. To ensure scalability in
920 multicast/ broadcast environments, MMTP relies mainly on FEC instead
921 of retransmissions for coping with packet error. Before joining the
922 MMTP session, the MMTP receiver should obtain sufficient information
923 to enable reception of the delivered data. This minimum required
924 information is specified in Section 6. MMTP requires MMTP receivers
925 to be able to uniquely identify and de-multiplex MMTP packets that
926 belong to a specific object flow. In addition, MMT receivers are
927 required to be able to identify packets carrying AL-FEC repair
928 packets by interpreting the type field of the MMTP packet header.
929 The MMTP receiver shall be able to simultaneously receive, de-
930 multiplex, and reconstruct the data delivered by MMTP packets of
931 different types and from different object flows. A single MMTP
932 packet shall carry exactly one MMTP payload.
934 5.2. Delivery ISOBMFF objects
936 The ISOBMFF mode is used to transport ISOBMFF files sent by a sending
937 entity to a receiving entity.
939 5.2.1. MMTP sender operation
941 5.2.1.1. Timed Media Data
943 The packetization of an ISOBMFF file that contains timed media may be
944 performed in a ISOBMFF file format aware mode or ISOBMFF file format
945 agnostic mode. In the media format agnostic mode, the ISOBMFF file
946 is packetized into data units of equal size (except for the last data
947 unit, of which the size may differ) or predefined size according to
948 the size of MTU of the underlying delivery network by using GFD mode
949 as specified in Section 4.2. It means that the packetization of the
950 ISOBMFF file format agnostic mode only consider the size of data to
951 be carried in the packet. The type field of MMTP packet header
952 specified in Section 4.1 is set to "0x00" to indicate that the
953 packetization is format agnostic mode. In the format agnostic mode
954 the packetization procedure takes into account the boundaries of
955 different types of data in ISOBMFF file to generate packets by using
956 ISOBMFF mode as specified in Section 4.1. The resulting packets
957 shall carry delivery data units of either ISOBMFF file metadata,
958 movie fragment metadata, or a data unit. The resulting packets shall
959 not carry more than two different types of delivery data units. The
960 delivery data unit of ISOBMFF file metadata consists of the "ftyp"
961 box, the "mmpu" box, the "moov" box, and any other boxes that are
962 applied to the whole ISOBMFF file. The FT field of the MMTP payload
963 carrying a delivery data unit of the ISOBMFF file metadata is set to
964 "0x00". The delivery data unit of movie fragment metadata consists
965 of the "moof" box and the "mdat" box header (excluding any media
966 data). The FT field of the MMTP payload carrying a delivery data
967 unit of movie fragment metadata is set to "0x01". The media data,
968 data units in "mdat" box of the ISOBMFF file, is then split into
969 multiple delivery data units in a format aware way. This may for
970 example be performed with the help of the MMT hint track. The FT
971 field of the MMTP payload carrying a delivery data unit is set to
972 "0x02". Each data unit is prepended with a data unit header, which
973 has the syntax and semantics as defined in section Section 4.1.1. It
974 is followed by the media data of the data unit. This procedure is
975 described by Figure 7.
977 +------+ +------+ +------+ +------+ +--------+-------------------------+
978 | ftyp | | mmpu | | moov | | moof | |mdat_hdr| mdat |
979 +------+ +------+ +------+ +------+ +--------+-------------------------+
980 | | | | ... | |
981 | | | | | |
982 | | | | | |
983 +------------------------+ +------------------+ +----+
984 | ISOBMFF metadata | | Fragment metadata| ... | DU |
985 +------------------------+ +------------------+ +----+
987 Payload generation for timed media
989 Figure 7
991 5.2.1.2. Non-Timed Media Data
993 The packetization of non-timed media data may also be performed in
994 two different modes. In the ISOBMFF file format agnostic mode, the
995 ISOBMFF file is packetized into delivery data units of equal size
996 (except for the last data unit, of which the size may differ) or or
997 predefined size according to the size of MTU of the underlying
998 delivery network by using GFD mode as specified in Section 4.2. The
999 type field of MMTP packet header specified in Figure 1 is set to
1000 "0x00" to indicate that the packetization is format agnostic mode.
1001 In the format agnostic mode, the ISOBMFF file shall be packetized
1002 into the packet containing delivery data units of either ISOBMFF file
1003 metadata or data unit by using ISOBMFF mode as defined in
1004 Section 4.1. The delivery data unit of the ISOBMFF file metadata
1005 contains the "ftyp" box, the "moov" box, and the "meta" box and any
1006 other boxes that are applied to the whole ISOBMFF file. The FT field
1007 of the MMTP payload carrying a delivery data unit of the ISOBMFF file
1008 metadata is set to "0x01". Each delivery data unit contains a single
1009 item of the non-timed media. The FT field of the MMTP payload
1010 carrying a delivery data unit is set to "0x02". Each item of the
1011 non-timed data is then used to build a data unit. Each data unit
1012 consists of a data unit header and the item's data. The data unit
1013 header is defined in Section 4.1.1.
1015 +----+ +----+ +----+ +----+ +---------+ +------------------------+
1016 |ftyp| |mmpu| |moov| |meta| | item #1 | | item #2 |
1017 +----+ +----+ +----+ +----+ +---------+ +------------------------+
1018 | | | | | |
1019 | | | | | |
1020 | | | | | |
1021 +-------------------------+ +---------+ +------------------------+
1022 | ISOBMFF metadata | | DU | | DU |
1023 +-------------------------+ +---------+ +------------------------+
1025 Payload generation for non-timed media
1027 Figure 8
1029 5.2.2. MMTP receiver operation
1031 The depacketization procedure is performed at an MMTP receiver to
1032 rebuild the transmitted ISOBMFF file. The depacketization procedure
1033 may operate in one of the following modes, depending on the
1034 application needs:
1036 ISOBMFF mode:
1038 in the ISOBMFF mode, the depacketizer reconstructs the full
1039 ISOBMFF file before forwarding it to the application. This mode
1040 is appropriate for non-time critical delivery, i.e. the ISOBMFF
1041 file's presentation time as indicated by the presentation
1042 information document is sufficiently behind its delivery time.
1044 Fragment mode:
1046 in the Fragment mode, the depacketizer reconstructs a complete
1047 fragment including the fragment metadata and the "mdat" box with
1048 media samples before forwarding it to the application. This mode
1049 does not apply to non-timed media. This mode is suitable for
1050 delay-sensitive applications where the delivery time budget is
1051 limited but is large enough to recover a complete fragment.
1053 Media unit mode:
1055 in the media unit mode, the depacketizer extracts and forwards
1056 media units as fast as possible to the application. This mode is
1057 applicable for very low delay media applications. In this mode,
1058 the recovery of the ISOBMFF file is not required. The processing
1059 of the fragment media data is not required but may be performed to
1060 resynchronize. This mode tolerates out of order delivery of the
1061 fragment metadata data units, which may be generated after the
1062 media units are generated. This mode applies to both timed and
1063 non-timed media. Using the data unit sequence numbers, it is
1064 relatively easy for the receiver to detect missing packets and
1065 apply any error correction procedures such as ARQ to recover the
1066 missing packets. The payload type may be used by the MMTP sender
1067 to determine the importance of the payload for the application and
1068 to apply appropriate error resilience measures.
1070 5.3. Delivering Generic Objects
1072 The files delivered using the GFD mode may have to be provided to an
1073 application, for example Presentation Information documents or a
1074 Media Presentation Description as defined in ISO/IEC 23009-1 may
1075 refer to the files delivered using MMTP as GFD objects. The file
1076 shall be referenced through the URI provided or derived from Content-
1077 Location, either provided in-band as part of an entity header or as
1078 part of a GFDT. In certain cases, the files have an availability
1079 start time in the application. In this case the MMTP session shall
1080 deliver the files such that the last packet of the object is
1081 delivered such that it is available latest at the receiver at the
1082 availability start time as announced in the application.
1083 Applications delivered through the GFD mode may impose additional and
1084 stricter requirements on the sending of the files within a MMTP
1085 session.
1087 5.3.1. MMTP sender operation
1089 If more than one object is to be delivered using the GFD mode, then
1090 the MMTP sender shall use different TOI fields. In this case each
1091 object shall be identified by a unique TOI scoped by the packet_id,
1092 and the MMTP sender shall use that TOI value for all packets
1093 pertaining to the same object. The mapping between TOIs and files
1094 carried in a session is either provided in-band or in a GFDT. The
1095 GFD payload header as defined in Section 4.2.1.5 shall be used. The
1096 GFD payload header contains a CodePoint field that shall be used to
1097 communicate to a MMTP receiver the settings for information that is
1098 established for the current MMTP session and may even vary during a
1099 MMTP session. The mapping between settings and Codepoint values is
1100 communicated in the a GFDT as described in Section 4.2.1.1. Let T >
1101 0 be the Transfer-Length of any object in bytes. The data carried in
1102 the payload of a packet consists of a consecutive portion of the
1103 object. Then for any arbitrary X and any arbitrary Y > 0 as long as
1104 X + Y is at most T, an MMTP packet may be generated. In this case
1105 the followings shall hold:
1107 1. The data carried in the payload of a packet shall consist of a
1108 consecutive portion of the object starting from the beginning of
1109 byte X through the beginning of byte X + Y.
1111 2. The start_offset field in the GFD payload header shall be set to
1112 X and the payload data shall be added into the packet to send.
1114 3. If X + Y is identical to T,
1116 * the payload header flag B shall be set to "1".
1118 * else
1120 * the payload header flag B shall be set to "0".
1122 The following procedure is recommended for a MMTP sender to deliver
1123 an object to generate packets containing start_offset and
1124 corresponding payload data.
1126 1. Set the byte offset counter X to "0"
1128 2. For the next packets to be delivered set the length in bytes of a
1129 payload to a value Y, which is
1131 * reasonable for a packet payload (e.g., ensure that the total
1132 packet size does not exceed the MTU), and
1134 * such that the sum of X and Y is at most T, and
1136 * such that it is suitable for the payload data included in the
1137 packet
1139 3. Generate a packet according to the rules a to c from above
1141 4. If X + Y is equal to T,
1143 * set the payload header flag B to "1"
1145 * else
1147 * set the payload header flag B to "0"
1149 * increment X = X + Y
1151 * goto 2
1153 The order of packet delivery is arbitrary, but in the absence of
1154 other constraints delivery with increasing start_offset number is
1155 recommended. Note that the transfer length may be unknown prior to
1156 sending earlier pieces of the data. In this case, T may be
1157 determined later. However, this does not affect the sending process
1158 above. Additional packets may be sent following the rules in 1 to 3
1159 from above. In this case the B flag shall only be set for the
1160 payload that contains the last portion of the object.
1162 5.3.2. GFD Payload
1164 The bytes of the object are referenced such that byte 0 is the
1165 beginning of the object and byte T-1 is the last byte of the object
1166 with T is the transfer length (in bytes) of the object. The data
1167 carried in the payload of an MMTP packet shall consist of a
1168 consecutive portion of the object starting from the beginning of byte
1169 X and ending at the beginning of byte X + Y where
1171 1. X is the value of start_offset field in the GFD payload header
1173 2. Y is the length of the payload in bytes
1175 Note that Y is not carried in the packet, but framing shall be
1176 provided by the underlying transport protocol.
1178 5.3.3. GFD Table Delivery
1180 When GFD mode is used, the GFD table (GFDT) shall be provided. A
1181 file that is delivered using the GFD mode, but not described in the
1182 GFD table is not considered a 'file' belonging to the MMTP session.
1183 Any object received with an unmapped CodePoint should be ignored by a
1184 MMTP receiver. Other ways of delivery the GFD table may possible,
1185 but out of scope of this specification.
1187 5.3.4. MMTP receiver operation
1189 The GFDT may contain one or multiple CodePoints identified by
1190 different CodePoint values. Upon receipt of each GFD payload, the
1191 receiver proceeds with the following steps in the order listed.
1193 1. The MMTP receiver shall parse the GFD payload header and verify
1194 that it is a valid header. If it is not valid, then the GFD
1195 payload shall be discarded without further processing.
1197 2. The MMTP receiver shall parse the CodePoint value and verify that
1198 the GFDT contains a matching CodePoint. If it is not valid, then
1199 the GFD payload shall be discarded without further processing.
1201 3. The MMTP receiver should process the remainder of the payload,
1202 including interpreting the other payload header fields
1203 appropriately, and using the source_offset and the payload data
1204 to reconstruct the corresponding object as follows:
1206 1. The MMT receiving can determine from which object a received
1207 GFD payload was generated by using the GFDT., and by the TOI
1208 carried in the payload header.
1210 2. Upon receipt of the first GFD payload for an object, the
1211 MMTP receiver uses the Maximum Transfer Length received as
1212 part of the GFDT to determine the maximum length T' of the
1213 object.
1215 3. The MMTP receiver allocates space for the T' bytes that the
1216 object may require.
1218 4. The MMTP receiver also computes the length of the payload,
1219 Y, by subtracting the payload header length from the total
1220 length of the received payload.
1222 5. The MMTP receiver allocates a Boolean array RECEIVED[0..T'-
1223 1] with all T entries initialized to false to track received
1224 object symbols. The MMTP receiver keeps receiving payloads
1225 for the object block as long as there is at least one entry
1226 in RECEIVED still set to false or until the application
1227 decides to give up on this object.
1229 6. For each received GFD payload for the object (including the
1230 first payload), the steps to be taken to help recover the
1231 object are as follows:
1233 7. Let X be the value of the source_offset field in the GFD
1234 payload header of the MMTP packet. and let Y be the length
1235 of the payload, Y, computed by subtracting the MMTP packet
1236 and GFD payload header lengths from the total length of the
1237 received packet.
1239 8. The MMTP receiver copies the data into the appropriate place
1240 within the space reserved for the object and sets RECEIVED[X
1241 ... X+Y-1] = true.
1243 9. If all T entries of RECEIVED are true, then the receiver has
1244 recovered the entire object.
1246 10. Once the MMTP receiver receives a GFD payload with the B
1247 flag set to 1, it can determine the transfer length T of the
1248 object as X+Y of the corresponding GFD payload and adjust
1249 the boolean array RECEIVED[0..T'-1] to RECEIVED[0..T-1].
1251 6. Session Description information
1253 The MMTP session description information may be delivered to
1254 receivers in different ways to accommodate different deployment
1255 environments. Before a receiver is able to join an MMTP session, the
1256 receiver needs to obtain the following information:
1258 The destination information. In an IP environment, the
1259 destination IP address and port number.
1261 An indication that the session is an MMTP session
1263 The version number of the MMT protocol used in the MMTP session
1265 Additionally, the MMTP session description information should contain
1266 the following information:
1268 The start and end time of the MMTP session.
1270 7. Congestion Control
1272 All transport protocols used on the Internet are required to address
1273 congestion control. MMTP provides for means to the sender to adjust
1274 its sending rate to the available bandwidth. Feedback mechanisms
1275 from the client, sent as part of MMT signaling, give the sender the
1276 necessary information to estimate the available bandwidth. A
1277 description file of the content that is being streamed is also
1278 available at the sender to assist with the selection of alternative
1279 representations and in stream thinning through selection of an
1280 appropriate operation point. The MMTP sender SHALL make use of this
1281 available information to timely react to congestion.
1283 8. IANA Considerations
1285 This internet draft includes no request to IANA.
1287 9. Security Considerations
1289 Lower layer protocols may eventually provide all the security
1290 services that may be desired for applications of MMTP, including
1291 authentication, integrity, and confidentiality. These services have
1292 been specified for IP in [RFC4301].
1294 10. References
1296 10.1. Normative References
1298 [isopart12]
1299 ISO/IEC, "Information technology High efficiency coding
1300 and media delivery in heterogeneous environments Part 12:
1301 File Format", 2008, .
1303 [mmt] ISO/IEC, "Information technology High efficiency coding
1304 and media delivery in heterogeneous environments Part 1:
1305 MPEG media transport (MMT)", 2014, .
1307 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1308 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1309 Transfer Protocol -- HTTP/1.1", RFC 2616,
1310 DOI 10.17487/RFC2616, June 1999,
1311 .
1313 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1314 Resource Identifier (URI): Generic Syntax", STD 66,
1315 RFC 3986, DOI 10.17487/RFC3986, January 2005,
1316 .
1318 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
1319 "Network Time Protocol Version 4: Protocol and Algorithms
1320 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
1321 .
1323 10.2. Informative References
1325 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
1326 Jacobson, "RTP: A Transport Protocol for Real-Time
1327 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
1328 July 2003, .
1330 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1331 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
1332 December 2005, .
1334 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
1335 Control Packets on a Single Port", RFC 5761,
1336 DOI 10.17487/RFC5761, April 2010,
1337 .
1339 Author's Address
1341 Imed Bouazizi
1342 Samsung Research America
1343 Richardson, TX
1344 US
1346 Phone: +1 972 761 7023
1347 Email: i.bouazizi@samsung.com