idnits 2.17.1
draft-bouazizi-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 149: '... MUST be set to 0 by the sender and ...'
RFC 2119 keyword, line 793: '... or "reserved" (r) MUST by set to 0 by...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 423 has weird spacing: '...16 bits indic...'
== Line 426 has weird spacing: '... 4 bits this ...'
== Line 429 has weird spacing: '...: 1 bit this ...'
== Line 433 has weird spacing: '... 2 bits this ...'
-- The document date (September 30, 2014) is 3494 days in the past. Is
this intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC3550' is defined on line 1266, 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 September 30, 2014
5 Expires: April 3, 2015
7 MPEG Media Transport Protocol (MMTP)
8 draft-bouazizi-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 April 3, 2015.
39 Copyright Notice
41 Copyright (c) 2014 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 3. Packet Header Field . . . . . . . . . . . . . . . . . . . . . 4
59 3.1. MMTP Header Extension . . . . . . . . . . . . . . . . . . 7
60 4. The MMTP payload . . . . . . . . . . . . . . . . . . . . . . 8
61 4.1. The ISOBMFF Mode . . . . . . . . . . . . . . . . . . . . 8
62 4.1.1. MMTP payload header for ISOBMFF mode . . . . . . . . 9
63 4.2. Generic File Delivery Mode . . . . . . . . . . . . . . . 12
64 4.2.1. GFD Information . . . . . . . . . . . . . . . . . . . 13
65 4.2.1.1. GFD Table . . . . . . . . . . . . . . . . . . . . 13
66 4.2.1.2. CodePoints . . . . . . . . . . . . . . . . . . . 14
67 4.2.1.3. Content-Location Template . . . . . . . . . . . . 16
68 4.2.1.4. File metadata . . . . . . . . . . . . . . . . . . 17
69 4.2.1.5. MMTP payload header for GFD mode . . . . . . . . 18
70 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 19
71 5.1. General Operation . . . . . . . . . . . . . . . . . . . . 19
72 5.2. Delivery ISOBMFF objects . . . . . . . . . . . . . . . . 20
73 5.2.1. MMTP sender operation . . . . . . . . . . . . . . . . 20
74 5.2.1.1. Timed Media Data . . . . . . . . . . . . . . . . 20
75 5.2.1.2. Non-Timed Media Data . . . . . . . . . . . . . . 21
76 5.2.2. MMTP receiver operation . . . . . . . . . . . . . . . 22
77 5.3. Delivering Generic Objects . . . . . . . . . . . . . . . 23
78 5.3.1. MMTP sender operation . . . . . . . . . . . . . . . . 23
79 5.3.2. GFD Payload . . . . . . . . . . . . . . . . . . . . . 25
80 5.3.3. GFD Table Delivery . . . . . . . . . . . . . . . . . 25
81 5.3.4. MMTP receiver operation . . . . . . . . . . . . . . . 25
82 6. Session Description information . . . . . . . . . . . . . . . 27
83 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 27
84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
87 10.1. Normative References . . . . . . . . . . . . . . . . . . 28
88 10.2. Informative References . . . . . . . . . . . . . . . . . 28
89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
91 1. Introduction
93 The MMT protocol is an application layer transport protocol that is
94 designed to efficiently and reliably transport multimedia data. MMTP
95 can be used for both timed and non-timed media data. It supports
96 several features, such as media multiplexing and network jitter
97 estimation. These features are designed to deliver content composed
98 of various types of encoded media data more efficiently. MMTP may
99 run on top of existing network protocols such as UDP and IP. In this
100 specification, the carriage of data formatted differently than the
101 MMTP payload format as specified in Section 4 by MMTP is not defined.
102 The MMT protocol is designed to support a wide variety of
103 applications and does not specify congestion control. The congestion
104 control function is left for the application implementation. MMTP
105 supports the multiplexing of different media data such as ISOBMFF
106 files from various Assets over a single MMTP packet flow. It
107 delivers multiple types of data in the order of consumption to the
108 receiving entity to help synchronization between different types of
109 media data without introducing a large delay or requiring large
110 buffer. MMTP defines two packetization modes, Generic File Delivery
111 mode as specified in Section 4.2 and the ISOBMFF mode as specified in
112 Section 4.1. The former defines a mode for packetizing media data
113 based on the size of the payload to be carried and the latter defines
114 a mode for packetizing media data based on the type of data to be
115 carried in the payload. MMTP supports simultaneous transmission of
116 packets using the two different modes in a single delivery session.
117 MMTP also provides means to calculate and remove jitter introduced by
118 the underlying delivery network, so that constant end-to-end delay
119 for data delivery can be achieved. By using the delivery timestamp
120 field in the packet header, jitter can be precisely estimated without
121 requiring any additional signalling information and protocols.
123 2. Rationale
125 MMTP provides a generic media transport protocol that inherently
126 supports virtually any media type and codec. For this purpose, MMTP
127 is designed to support a limited set of payload types agnostic to the
128 media type or coding format, but providing generic information to
129 serve the needs of different multimedia delivery services. The MMTP
130 payload format is defined as a generic payload format for the
131 packetization of media data. It is agnostic to media codecs used for
132 encoded media data, so that any type of media data that are
133 encapsulated in the ISOBMFF format can be packetized into MMTP
134 payloads. The MMTP payload format also supports fragmentation and
135 aggregation of data to be delivered. MMTP supports both streaming
136 and download modes, where the streaming mode is optimized for
137 packetized streaming of ISO-Base Media File formatted files (ISOBMFF
138 mode) and the download mode allows for flexible delivery of generic
139 files (GFD mode). In addition, MMTP delivers streaming support data
140 such as Application Layer Forward Error Correction (AL-FEC) repair
141 data.
143 3. Packet Header Field
145 The MMTP header is of variable size, where the size of the header may
146 be deduced from the header flags. In the MMTP header, all integer
147 fields are carried in "big-endian" or "network order" format, so that
148 the most significant byte is first. Bits marked as "reserved" (r)
149 MUST be set to 0 by the sender and ignored by receivers in this
150 version of the specification. Unless otherwise noted, numeric
151 constants in this specification are in decimal form (base 10). The
152 format of the MMTP header is depicted in Figure 1.
154 0 1 2 3
155 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
156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
157 |V=0|C|FEC|r|X|R|RES| type | packet_id |
158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
159 | timestamp |
160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
161 | packet_sequence_number |
162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
163 | packet_counter |
164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
165 | header_extension ....
166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
167 | payload data ....
168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
170 Figure 1: MMTP Header
172 The function and length of each field in the MMTP header is specified
173 as follows:
175 version (V): 2 bits
177 indicates the version number of the MMTP protocol. This field
178 shall be set to "00" to comply with this specification.
180 packet_counter_flag (C): 1 bit
182 "1" in this field indicates that the packet_counter field is
183 present.
185 FEC_type (FEC): 2 bits
187 indicates whether the payload carries FEC source data or repair
188 data. Valid values of this field are listed in Table 1 below.
189 Depending on the FEC scheme, additional payload header may be
190 added, for instance to identify the contained symbol(s).
192 reserved (r): 1 bit
194 reserved for future use.
196 extension_flag (X): 1 bit
198 when set to "1" this flag indicates that the header_extension
199 field is present.
201 RAP_flag (R): 1 bit
203 when set to "1" this flag indicates that the payload contains a
204 Random Access Point (RAP) to the data stream of that data type.
205 The exact semantics of this flag are defined by the data type
206 itself. The RAP_flag shall be set to mark data units of Fragment
207 Type value "0" and "1" and for data units that contain a sync
208 sample or a fragment thereof in the case of timed media and for
209 the primary item of non-timed data.
211 reserved (RES): 2 bits
213 reserved for future use.
215 type: 6 bits
217 this field indicates the type of payload data. Payload type
218 values are defined in Table 2.
220 packet_id: 16 bits
222 this field is an integer value that can be used to identify
223 related media data, for example media that belong to the same
224 media asset. The packet_id is unique throughout the lifetime of
225 the delivery session and for all MMTP flows delivered by the same
226 MMTP sender.
228 packet_sequence_number: 32 bits
230 an integer value that is used to distinguish between packets that
231 have the same packet_id. The value of this field should start
232 from an arbitrary value and shall be incremented by one for each
233 new MMTP packet. It wraps around to "0" after the maximum value
234 is reached.
236 timestamp: 32 bits
238 specifies the time instance of MMTP packet delivery based on UTC.
239 The format is the "short-format" as defined in clause 6 of
241 [RFC5905], NTP version 4. This timestamp specifies the sending
242 time at the first byte of MMTP packet. It is required that an
243 MMTP sender should provide accurate time information that are
244 synchronized with UTC.
246 packet_counter: 32 bits
248 an integer value for counting MMTP packets. It is incremented by
249 1 when an MMTP packet is sent regardless of its packet_id value.
250 This field starts from arbitrary value and wraps around to "0"
251 after its maximum value is reached.
253 header_extension:
255 this field contains user-defined information. The header
256 extension mechanism is provided to allow for proprietary
257 extensions to the payload format to enable applications and media
258 types that require additional information to be carried in the
259 payload format header. The header extension mechanism is designed
260 in a such way that it may be discarded without impacting the
261 correct processing of the MMTP payload. The header extension
262 shall have the format as shown in Figure 2. This specification
263 does not specify any particular header extension.
265 +-------+--------------------------------------------------------+
266 | Value | Description |
267 +-------+--------------------------------------------------------+
268 | 0 | MMTP packet without AL-FEC protection |
269 | 1 | MMTP packet with AL-FEC protection (FEC source packet) |
270 | 2 | MMTP packet for repair symbol(s) (FEC repair packet) |
271 | 3 | Reserved for future use |
272 +-------+--------------------------------------------------------+
274 Table 1: FEC Type
276 +-----------+------------+------------------------------------------+
277 | Value | Data type | Definition of data unit |
278 +-----------+------------+------------------------------------------+
279 | 0x00 | ISOBMFF | The packet carries a media-aware |
280 | | file | fragment of the ISOBMFF file |
281 | 0x01 | Generic | The packet contains a generic object |
282 | | object | such as a complete ISOBMFF file or an |
283 | | | object of another type or a chunk |
284 | | | thereof. |
285 | 0x02 | signalling | one or more signalling messages or a |
286 | | message | fragment of a signalling message. The |
287 | | | syntax and semantics of signalling |
288 | | | messages are out of scope of the current |
289 | | | memo. |
290 | 0x03 | repair | The packet carries a single complete FEC |
291 | | symbol | repair symbol |
292 | 0x04-0x1F | reserved | reserved for ISO use |
293 | 0x20-0x3F | reserved | reserved for private use |
294 +-----------+------------+------------------------------------------+
296 Table 2: Data type and definition of data unit
298 3.1. MMTP Header Extension
300 0 1 2 3
301 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
302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
303 | type | length |
304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
305 | header_extension_value ....
306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308 Figure 2: MMTP Header Extension
310 The function and length of each field in the MMTP header extension is
311 as follows:
313 type: 16 bits
315 indicates the unique identification of the following header
316 extension.
318 length: 16 bits
320 indicates the length of header_extension_value field in byte.
322 header_extension_value
323 provides the extension information. The format of this field is
324 out of scope of this specification.
326 4. The MMTP payload
328 The MMTP payload is a generic payload format to packetize and carry
329 media data such as ISOBMFF files, generic objects, and other
330 information for consumption of a media service using the MMT
331 protocol. The appropriate MMTP payload format shall be used to
332 packetize ISOBMFF files, and generic objects. An MMTP payload may
333 carry complete ISOBMFF files or fragments of ISOBMFF files,
334 signalling messages, generic objects, repair symbols of AL-FEC
335 schemes, etc. The type of the payload is indicated by the type field
336 in the MMT protocol packet header. For each payload type, a single
337 data unit for delivery as well as a type specific payload header are
338 defined. For example, fragment of an ISOBMFF file (e.g. a data unit)
339 is considered as a single data unit when MMTP payload carries ISOBMFF
340 file fragments. The MMT protocol may aggregate multiple data units
341 with the same data type into a single MMTP payload. It can also
342 fragment a single data unit into multiple MMTP packets. The MMTP
343 payload consists of a payload header and payload data. Some data
344 types may allow for fragmentation and aggregation, in which case a
345 single data unit is split into multiple fragments or a set of data
346 units are delivered in a single MMTP packet. Each data unit may have
347 its own data unit header depending on the type of the payload. For
348 types that do not require a payload type specific header no payload
349 type header is present and the payload data follows the MMTP header
350 immediately. Some fields of the MMTP packet header are interpreted
351 differently depending on the payload type. The semantics of these
352 fields will be defined by the payload type in use.
354 4.1. The ISOBMFF Mode
356 The delivery of ISOBMFF files to MMT receivers using the MMT protocol
357 requires a packetization and depacketization procedure to take place
358 at the MMTP sender and MMTP receiver, respectively. The
359 packetization procedure transforms an ISOBMFF file into a set of MMTP
360 payloads that are then carried in MMTP packets. The MMTP payload
361 format allows for fragmentation of the MMTP payload to enable the
362 delivery of large payloads. It also allows for the aggregation of
363 multiple MMTP payload data units into a single MMTP payload, to cater
364 for smaller data units. At the receiving entity depacketization is
365 performed to recover the original ISOBMFF file data. Several
366 depacketization modes are defined to address the different
367 requirements of the overlaying applications. It the payload type is
368 0x00, the ISOBMFF file is fragmented in a media aware way allowing
369 the transport layer to identify the nature and priority of the
370 fragment that is carried. A fragment of an ISOBMFF file may either
371 be ISOBMFF file metadata, a Movie Fragment metadata, a data unit, or
372 a non-timed media data item.
374 4.1.1. MMTP payload header for ISOBMFF mode
376 The payload type specific header is provided in Figure 3.
378 0 1 2 3
379 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
380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381 | length | FT |T|f_i|A| frag_counter |
382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
383 | sequence_number |
384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
385 | DU_length | DU_Header ....
386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
387 | DU payload ....
388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
390 Figure 3: Structure of the MMTP payload header for the ISOBMFF mode
392 For payload that carries a data unit, the DU header is specified
393 depending on the value of the T flag indicating wether the carried
394 data is timed or non-timed media. For timed media (i.e. when the
395 value of T is set to "1") the DU header fields are shown in Figure 4.
396 For non-timed media (T is set to "0"), the DU header is defined as
397 shown in Figure 4.
399 0 1 2 3
400 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
401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
402 | movie_fragment_sequence_number |
403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
404 | sample_number |
405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406 | offset |
407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408 | priority | dep_counter |
409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
411 Figure 4: The DU header for a timed-media data unit
413 For non-timed media, the DU header fields are shown in Figure 5.
415 0 1 2 3
416 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
417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
418 | item_ID |
419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
421 Figure 5: The DU header for a non-timed media data unit
423 length: 16 bits indicates the length of payload excluding this field
424 in byte.
426 Fragment Type (FT): 4 bits this field indicates the fragment type
427 and its valid values are shown in Table 3.
429 Timed Flag (T): 1 bit this flag indicates if the fragment is from an
430 ISOBMFF file that carries timed (value 1) or non-timed media
431 (value 0).
433 Fragmentation Indicator (f_i) : 2 bits this field indicates the
434 fragmentation indicator contains information about fragmentation
435 of data unit in the payload. The four values are listed in
436 Table 4. If the value is set to "00", the aggregation_flag can be
437 presented.
439 +------+--------------+---------------------------------------------+
440 | FT | Description | Content |
441 +------+--------------+---------------------------------------------+
442 | 0 | ISOBMFF | contains the ftyp, mmpu, moov, and meta |
443 | | metadata | boxes as well as any other boxes that |
444 | | | appear in between. |
445 | 1 | Movie | contains the moof box and the mdat box, |
446 | | fragment | excluding all media data inside the mdat |
447 | | metadata | box. |
448 | 2 | a data unit | contains a sample or sub-sample of timed |
449 | | | media data or an item of non-timed media |
450 | | | data. |
451 | 3~15 | Reserved for | reserved |
452 | | private use | |
453 +------+--------------+---------------------------------------------+
455 Table 3: Data type and definition of data unit
457 +----------------+--------------------------------------------------+
458 | fragmentation | Description |
459 | indicator | |
460 +----------------+--------------------------------------------------+
461 | 00 | Payload contains one or more complete data |
462 | | units. |
463 | 01 | Payload contains the first fragment of data unit |
464 | 10 | Payload contains a fragment of data unit that is |
465 | | neither the first nor the last part. |
466 | 11 | Payload contains the last fragment of data unit. |
467 +----------------+--------------------------------------------------+
469 Table 4: Values for fragmentation indicator
471 The following flags are used to indicate the presence of various
472 information carried in the MMTP payload. Multiple bits can be set
473 simultaneously.
475 aggregation_flag (A: 1 bit)
477 when set to "1" indicates that more than 1 data unit is present in
478 the payload, i.e. multiple data units are aggregated.
480 fragment_counter (frag_count: 8 bits)
482 this field specifies the number of payload containing fragments of
483 same data unit succeeding this MMTP payload. This field shall be
484 "0" if aggregation_flag is set to "1".
486 sequence_number (32 bits)
488 the sequence number of the ISOBMFF to which this fragment belongs.
490 DU_length (16 bits)
492 this field indicates the length of the data following this field.
493 When aggregation_flag is set to "0", this field shall not be
494 present. When aggregation_flag is set to "1", this field shall
495 appear as many times as the number of the data units aggregated in
496 the payload and preceding each aggregated data unit.
498 DU_Header
500 The header of the data unit, which depends on the FT field. A
501 header is only defined for the media unit fragment type, with
502 different semantics for timed and non-timed media as identified by
503 the T flag.
505 movie_fragment_sequence_number (32 bits)
507 the sequence number of the movie fragment to which the media data
508 of this data unit belongs. (see [isopart12] sub-clause 8.5.5)
510 sample_number (32 bits)
512 the sample number of the sample to which the media data of the
513 data unit. (see [isopart12] sub-clause 8.8.8)
515 offset (32 bits)
517 offset of the media data of this data unit inside the referenced
518 sample.
520 subsample_priority (priority: 8 bits)
522 provides the priority of the media data carried by this data unit
523 compared to other media data of the same ISOBMFF file. The value
524 of subsample_priority shall be between "0" and "255", with higher
525 values indicating higher priority.
527 dependency_counter (dep_counter: 8 bits)
529 indicates the number of data units that depend on their media
530 processing upon the media data in this data unit.
532 Item_ID (32 bits)
534 the identifier of the item that is carried as part of this data
535 unit.
537 For the FT types "0" and "1", no additional DU header is defined.
539 4.2. Generic File Delivery Mode
541 MMTP also supports the transport of generic files and Assets and uses
542 payload type "0x01" as defined in Table 3. An Asset consists of one
543 or more files that are logically grouped and share some commonality
544 for an application, e.g. Segments of a Dynamic Adaptive Streaming
545 over HTTP (DASH) Representation, a sequence of ISOBMFF files, etc.
546 In the generic file delivery (GFD) mode, an Asset is transported by
547 using MMTP"s GFD payload type. Each file delivered using the GFD
548 mode requires association of transport delivery information. This
549 includes, but is not limited to information such as the transfer
550 length. Each file delivered using the GFD mode may also have
551 associated content specific parameters such as Name, Identification,
552 and Location of file, media type, size of the file, encoding of the
553 file or message digest of the file. In alignment with HTTP/1.1
554 protocol as defined in [RFC2616], each file within one generic Asset
555 may have assigned any meta-information about the entity body, i.e.
556 the delivered file. The details are also defined in Section 4.2.1.
558 4.2.1. GFD Information
560 In the GFD mode, each file gets assigned the following parameters:
562 o the asset to which each object belongs to. Objects that belong to
563 the same asset are considered as logically connected, e.g. all
564 DASH segments of a Representation and also across Representations
565 that extend over multiple DASH Periods and which carry pieces of
566 the same content.
568 o Each object is associated with a unique identifier within the
569 scope of the packet_id.
571 o each object is associated with a CodePoint. A CodePoint
572 associates a specific object and object transport properties.
573 Packets with the same TOI shall have the same CodePoint value.
574 For more details see 0.
576 4.2.1.1. GFD Table
578 The GFD table provides a list of CodePoints as defined in
579 Section 4.2.1.2. Each CodePoint gets dynamically assigned a
580 CodePoint value. Table 5 shows the structure and semantics of the
581 GFD table.
583 +-----------------------+------+------------------------------------+
584 | Element or Attribute | Use | Description |
585 | Name | | |
586 +-----------------------+------+------------------------------------+
587 | GFDTable | | The element carries a GFDTable |
588 | CodePoint | 1..N | defines all CodePoints in the MMTP |
589 | | | session |
590 +-----------------------+------+------------------------------------+
592 Table 5: GFD Table
594 Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with
595 Default Value, CM=Conditionally Mandatory. For elements:
596 minOccurs..maxOccurs (N=unbounded) Elements are bold; attributes are
597 non-bold and preceded with an @
599 4.2.1.2. CodePoints
601 A CodePoint value can be used to obtain following information:
603 o the maximum transfer length of any object delivered with this
604 CodePoint signalling
606 In addition, a CodePoint may include following information
608 o the actual transfer length of the objects
610 o any information that may be present in the entity-header as
611 defined in [RFC2616] section 7.1.
613 o A Content-Location-Template as defined in Section 4.2.1.3 using
614 the TOI and packet_id parameter, if present. The TOI and
615 packet_id may be used to generate the Content-Location for each
616 TOI and packet_id. If such a template is present, the processing
617 in Section 4.2.1.3 shall be used to generate the Content-Location
618 and the value of the URI shall be treated as the Content-Location
619 field in the entity-header.
621 o Specific information on the content, for example how the content
622 is packaged, etc.
624 Within one session, at most 256 CodePoints may be defined. The
625 definition of CodePoints is dynamically setup in the MMTP Session
626 Description. The CodePoint semantics are described in Table 6.
628 +--------------------------+----------+-----------------------------+
629 | Element or Attribute | Use | Description |
630 | Name | | |
631 +--------------------------+----------+-----------------------------+
632 | @value | M | defines the value of the |
633 | | | CodePoint in the MMTP |
634 | | | session as provided in the |
635 | | | CodePoint value of the MMTP |
636 | | | packet header containing |
637 | | | the GFD payload. The value |
638 | | | shall be between 1 and 255. |
639 | | | The value 0 is reserved. |
640 | @fileDeliveryMode | M | specifies the file delivery |
641 | | | mode according to Section |
642 | | | 4.2. |
643 | @maximumTransferLength | M | specifies the maximum |
644 | | | transfer length in bytes of |
645 | | | any object delivered with |
646 | | | this CodePoint in this MMTP |
647 | | | session. |
648 | @constantTransferLength | OD | specifies if all objects |
649 | | default: | delivered by this CodePoint |
650 | | 'false' | have constant transfer |
651 | | | length. If this attribute |
652 | | | is set to TRUE, all objects |
653 | | | shall have transfer length |
654 | | | as specified in the |
655 | | | @maximumTransferLength |
656 | | | attribute. |
657 | @contentLocationTemplate | O | specifies a template to |
658 | | | generate the Content- |
659 | | | Location of the entity |
660 | | | header. |
661 | EntityHeader | 0..1 | specifies a full entity |
662 | | | header in the format as |
663 | | | defined in [RFC2616] |
664 | | | section 7.1. The entity |
665 | | | header applies for all |
666 | | | objects that are delivered |
667 | | | with the value of this |
668 | | | CodePoint. |
669 +--------------------------+----------+-----------------------------+
671 Table 6: CodePoint Semantics
673 Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with
674 Default Value, CM=Conditionally Mandatory. For elements:
676 minOccurs..maxOccurs (N=unbounded) Elements are bold; attributes are
677 non-bold and preceded with an @
679 4.2.1.3. Content-Location Template
681 A CodePoint may include a @contentLocationTemplate attribute. The
682 value of @contentLocationTemplate attribute may contain one or more
683 of the identifiers listed in Table 7. In each URL, the identifiers
684 from Table 7 shall be replaced by the substitution parameter defined
685 in Table 7. Identifier matching is case-sensitive. If the URL
686 contains unescaped $ symbols which do not enclose a valid identifier
687 then the result of URL formation is undefined. The format of the
688 identifier is also specified in Table 7. Each identifier may be
689 suffixed, within the enclosing "$" characters following this
690 prototype: %0[width]d The width parameter is an unsigned integer that
691 provides the minimum number of characters to be printed. If the
692 value to be printed is shorter than this number, the result shall be
693 padded with zeros. The value is not truncated even if the result is
694 larger. The @contentLocationTemplate shall be authored such that the
695 application of the substitution process results in valid URIs.
696 Strings outside identifiers shall only contain characters that are
697 permitted within URLs according to [RFC3986].
699 +--------------+--------------------------+-------------------------+
700 | $Identifier$ | Substitution parameter | Format |
701 +--------------+--------------------------+-------------------------+
702 | $$ | Is an escape sequence, | not applicable |
703 | | i.e. "$$" is replaced | |
704 | | with a single "$" | |
705 | $PacketID$ | This identifier is | The format tag may be |
706 | | substituted with the | present.If no format |
707 | | value of the packet_id | tag is present, a |
708 | | of the associated MMT | default format tag with |
709 | | flow. | width=1 shall be used. |
710 | $TOI$ | This identifier is | The format tag may be |
711 | | substituted with the | present. If no format |
712 | | Object Identifier of the | tag is present, a |
713 | | corresponding MMTP | default format tag with |
714 | | packet containing the | width=1 shall be used. |
715 | | GFDpayload. | |
716 +--------------+--------------------------+-------------------------+
718 Table 7: Identifiers for URL templates
720 4.2.1.4. File metadata
722 Files can be transported using the GFD mode of the MMT protocol.
723 Furthermore, the GFD mode can also be used to transport entities
724 where an entity is defined according to section 7 of [RFC2616]. An
725 entity consists of meta-information in the form of entity-header
726 fields and content in the form of an entity-body (the file), as
727 described in section 7 of [RFC2616]. This enables that files may get
728 assigned information by inband delivery in a dynamic fashion. For
729 example, it enables the association of a Content-Location, the
730 Content-Size, etc. The file delivery mode shall be signaled in the
731 CodePoint.
733 +--------------+--------------------------------+-------------------+
734 | Value | Description | Definition |
735 | $Identifier$ | | |
736 +--------------+--------------------------------+-------------------+
737 | 1 | The transport object is a file | in Section |
738 | | | 4.2.1.4.1 |
739 | 2 | The delivered object is an | in Section |
740 | | entity consisting of an | 4.2.1.4.2 |
741 | | entity-header and the file | |
742 +--------------+--------------------------------+-------------------+
744 Table 8: File Delivery Modes for GFD
746 4.2.1.4.1. Regular File
748 In case of the regular file, the object represents a file. If the
749 CodePoint defined in the GFD table contains entity-header fields or
750 entity-header fields can be generated, then all of these entity-
751 header fields shall apply to the delivered file.
753 4.2.1.4.2. Regular Entity
755 In case of the regular entity, the object represents an entity as
756 defined in section 7 of [RFC2616]. An entity consists of entity-
757 header fields and an entity-body. If the CodePoint defined in the
758 GFD table contains entity-header fields or entity-header fields can
759 be generated, then all of these entity-header fields apply to the
760 delivered file. If the entity-header field is present in both
761 locations, then the entity header field in the entity-header
762 delivered with the object overwrites the one in the CodePoint.
764 4.2.1.5. MMTP payload header for GFD mode
766 The GFD mode of MMTP delivers regular files. When delivering regular
767 files, the object represents a file. If the CodePoint defined in the
768 MMTP Session description contains entity-header fields or entity-
769 header fields can be generated, then all of these entity-header
770 fields shall apply to the delivered file. The payload packets sent
771 using MMTP shall include a GFD payload header and a GFD payload as
772 shown in Figure 6. In some special cases a MMTP sender may need to
773 produce packets that do not contain any payload. This may be
774 required, for example, to signal the end of a session.
776 0 1 2 3
777 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
778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
779 |C|L|B| CP | RES | TOI |
780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
781 | TOI | start_offset |
782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
783 | start_offset |
784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
785 | Generic File Delivery payload |
786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
788 MMTP payload header for GFD mode
790 Figure 6
792 The GFD payload header as shown in Figure 6 and has a variable size.
793 Bits designated as "padding" or "reserved" (r) MUST by set to 0 by
794 MMTP sender s and ignored by receivers. Unless otherwise noted,
795 numeric constants in this specification are in decimal form
797 C (1 bit)
799 indicates that this is the last packet for this session.
801 L (1 bit)
803 indicates that this is the last delivered packet for this object.
805 B (1 bit)
807 indicates that this packet contains the last byte of the object.
809 CodePoint (CP: 8 bits)
810 An opaque identifier that is passed to the packet payload decoder
811 to convey information on the packet payload. The mapping between
812 the CodePoint and the actual codec is defined on a per session
813 basis and communicated out-of-band as part of the session
814 description information.
816 RES (5 bits)
818 a reserved field that should be set to "0".
820 Transport Object Identifier (TOI: 32 bits)
822 The object identifier should be set to a unique identifier of the
823 generic object that is being delivered. The mapping between the
824 object identifier and the object information (such as URL and MIME
825 type) may be done explicitly or implicitly. For example a
826 sequence of DASH segments may use the segment index as the object
827 identifier and a numerical representation identifier as the
828 packet_id. This mapping may also be performed using a signalling
829 message
831 start_offset (48 bits)
833 the location of the current payload data in the object.
835 5. Protocol Operation
837 In this section, we describe the behavior of an MMTP receiver and of
838 an MMTP sender when operating the MMTP protocol using different
839 payload types.
841 5.1. General Operation
843 An MMTP session consists of one MMTP transport flow. MMTP transport
844 flow is defined as all packet flows that are delivered to the same
845 destination and which may originate from multiple MMTP senders. In
846 the case of IP, destination is the IP address and port number. A
847 single Package may be delivered over one or multiple MMTP transport
848 flows. A single MMTP transport flow may deliver data from multiple
849 Packages. An MMTP transport flow may carry multiple Assets. Each
850 Asset is associated with a unique packet_id within the scope of the
851 MMTP session. MMTP provides a streaming-optimized mode (the ISOBMFF
852 mode) and a file download mode (the GFD mode). The Asset is
853 delivered as a set of related objects denoted as an object flow.
854 Object may either be an ISOBMFF file, file or signalling message.
855 Each object flow shall either be carried in ISOBMFF mode or GFD mode,
856 however, the delivery of one Package may be performed using a mix of
857 the 2(two) modes, i.e. some Assets may be delivered using the ISOBMFF
858 mode and others using the GFD mode. The MMTP packet sub-flow is the
859 subset of the packets of an MMTP packet flow that share the same
860 packet_id. The object flow is transported as an MMTP packet sub-
861 flow. The ISOBMFF mode supports the packetized streaming of an
862 ISOBMFF file. The GFD mode supports flexible file delivery of any
863 type of file or sequence of files. MMTP is suitable for unicast as
864 well as multicast media distribution. To ensure scalability in
865 multicast/ broadcast environments, MMTP relies mainly on FEC instead
866 of retransmissions for coping with packet error. Before joining the
867 MMTP session, the MMTP receiver should obtain sufficient information
868 to enable reception of the delivered data. This minimum required
869 information is specified in Section 6. MMTP requires MMTP receivers
870 to be able to uniquely identify and de-multiplex MMTP packets that
871 belong to a specific object flow. In addition, MMT receivers are
872 required to be able to identify packets carrying AL-FEC repair
873 packets by interpreting the type field of the MMTP packet header.
874 The MMTP receiver shall be able to simultaneously receive, de-
875 multiplex, and reconstruct the data delivered by MMTP packets of
876 different types and from different object flows. A single MMTP
877 packet shall carry exactly one MMTP payload.
879 5.2. Delivery ISOBMFF objects
881 The ISOBMFF mode is used to transport ISOBMFF files sent by a sending
882 entity to a receiving entity.
884 5.2.1. MMTP sender operation
886 5.2.1.1. Timed Media Data
888 The packetization of an ISOBMFF file that contains timed media may be
889 performed in a ISOBMFF file format aware mode or ISOBMFF file format
890 agnostic mode. In the media format agnostic mode, the ISOBMFF file
891 is packetized into data units of equal size (except for the last data
892 unit, of which the size may differ) or predefined size according to
893 the size of MTU of the underlying delivery network by using GFD mode
894 as specified in Section 4.2. It means that the packetization of the
895 ISOBMFF file format agnostic mode only consider the size of data to
896 be carried in the packet. The type field of MMTP packet header
897 specified in Section 4.1 is set to "0x00" to indicate that the
898 packetization is format agnostic mode. In the format agnostic mode
899 the packetization procedure takes into account the boundaries of
900 different types of data in ISOBMFF file to generate packets by using
901 ISOBMFF mode as specified in Section 4.1. The resulting packets
902 shall carry delivery data units of either ISOBMFF file metadata,
903 movie fragment metadata, or a data unit. The resulting packets shall
904 not carry more than two different types of delivery data units. The
905 delivery data unit of ISOBMFF file metadata consists of the "ftyp"
906 box, the "mmpu" box, the "moov" box, and any other boxes that are
907 applied to the whole ISOBMFF file. The FT field of the MMTP payload
908 carrying a delivery data unit of the ISOBMFF file metadata is set to
909 "0x00". The delivery data unit of movie fragment metadata consists
910 of the "moof" box and the "mdat" box header (excluding any media
911 data). The FT field of the MMTP payload carrying a delivery data
912 unit of movie fragment metadata is set to "0x01". The media data,
913 data units in "mdat" box of the ISOBMFF file, is then split into
914 multiple delivery data units in a format aware way. This may for
915 example be performed with the help of the MMT hint track. The FT
916 field of the MMTP payload carrying a delivery data unit is set to
917 "0x02". Each data unit is prepended with a data unit header, which
918 has the syntax and semantics as defined in section Section 4.1.1. It
919 is followed by the media data of the data unit. This procedure is
920 described by Figure 7.
922 +------+ +------+ +------+ +------+ +--------+-------------------------+
923 | ftyp | | mmpu | | moov | | moof | |mdat_hdr| mdat |
924 +------+ +------+ +------+ +------+ +--------+-------------------------+
925 | | | | ... | |
926 | | | | | |
927 | | | | | |
928 +------------------------+ +------------------+ +----+
929 | ISOBMFF metadata | | Fragment metadata| ... | DU |
930 +------------------------+ +------------------+ +----+
932 Payload generation for timed media
934 Figure 7
936 5.2.1.2. Non-Timed Media Data
938 The packetization of non-timed media data may also be performed in
939 two different modes. In the ISOBMFF file format agnostic mode, the
940 ISOBMFF file is packetized into delivery data units of equal size
941 (except for the last data unit, of which the size may differ) or or
942 predefined size according to the size of MTU of the underlying
943 delivery network by using GFD mode as specified in Section 4.2. The
944 type field of MMTP packet header specified in Figure 1 is set to
945 "0x00" to indicate that the packetization is format agnostic mode.
946 In the format agnostic mode, the ISOBMFF file shall be packetized
947 into the packet containing delivery data units of either ISOBMFF file
948 metadata or data unit by using ISOBMFF mode as defined in
949 Section 4.1. The delivery data unit of the ISOBMFF file metadata
950 contains the "ftyp" box, the "moov" box, and the "meta" box and any
951 other boxes that are applied to the whole ISOBMFF file. The FT field
952 of the MMTP payload carrying a delivery data unit of the ISOBMFF file
953 metadata is set to "0x01". Each delivery data unit contains a single
954 item of the non-timed media. The FT field of the MMTP payload
955 carrying a delivery data unit is set to "0x02". Each item of the
956 non-timed data is then used to build a data unit. Each data unit
957 consists of a data unit header and the item's data. The data unit
958 header is defined in Section 4.1.1.
960 +----+ +----+ +----+ +----+ +---------+ +------------------------+
961 |ftyp| |mmpu| |moov| |meta| | item #1 | | item #2 |
962 +----+ +----+ +----+ +----+ +---------+ +------------------------+
963 | | | | | |
964 | | | | | |
965 | | | | | |
966 +-------------------------+ +---------+ +------------------------+
967 | ISOBMFF metadata | | DU | | DU |
968 +-------------------------+ +---------+ +------------------------+
970 Payload generation for non-timed media
972 Figure 8
974 5.2.2. MMTP receiver operation
976 The depacketization procedure is performed at an MMTP receiver to
977 rebuild the transmitted ISOBMFF file. The depacketization procedure
978 may operate in one of the following modes, depending on the
979 application needs:
981 ISOBMFF mode:
983 in the ISOBMFF mode, the depacketizer reconstructs the full
984 ISOBMFF file before forwarding it to the application. This mode
985 is appropriate for non-time critical delivery, i.e. the ISOBMFF
986 file's presentation time as indicated by the presentation
987 information document is sufficiently behind its delivery time.
989 Fragment mode:
991 in the Fragment mode, the depacketizer reconstructs a complete
992 fragment including the fragment metadata and the "mdat" box with
993 media samples before forwarding it to the application. This mode
994 does not apply to non-timed media. This mode is suitable for
995 delay-sensitive applications where the delivery time budget is
996 limited but is large enough to recover a complete fragment.
998 Media unit mode:
1000 in the media unit mode, the depacketizer extracts and forwards
1001 media units as fast as possible to the application. This mode is
1002 applicable for very low delay media applications. In this mode,
1003 the recovery of the ISOBMFF file is not required. The processing
1004 of the fragment media data is not required but may be performed to
1005 resynchronize. This mode tolerates out of order delivery of the
1006 fragment metadata data units, which may be generated after the
1007 media units are generated. This mode applies to both timed and
1008 non-timed media. Using the data unit sequence numbers, it is
1009 relatively easy for the receiver to detect missing packets and
1010 apply any error correction procedures such as ARQ to recover the
1011 missing packets. The payload type may be used by the MMTP sender
1012 to determine the importance of the payload for the application and
1013 to apply appropriate error resilience measures.
1015 5.3. Delivering Generic Objects
1017 The files delivered using the GFD mode may have to be provided to an
1018 application, for example Presentation Information documents or a
1019 Media Presentation Description as defined in ISO/IEC 23009-1 may
1020 refer to the files delivered using MMTP as GFD objects. The file
1021 shall be referenced through the URI provided or derived from Content-
1022 Location, either provided in-band as part of an entity header or as
1023 part of a GFDT. In certain cases, the files have an availability
1024 start time in the application. In this case the MMTP session shall
1025 deliver the files such that the last packet of the object is
1026 delivered such that it is available latest at the receiver at the
1027 availability start time as announced in the application.
1028 Applications delivered through the GFD mode may impose additional and
1029 stricter requirements on the sending of the files within a MMTP
1030 session.
1032 5.3.1. MMTP sender operation
1034 If more than one object is to be delivered using the GFD mode, then
1035 the MMTP sender shall use different TOI fields. In this case each
1036 object shall be identified by a unique TOI scoped by the packet_id,
1037 and the MMTP sender shall use that TOI value for all packets
1038 pertaining to the same object. The mapping between TOIs and files
1039 carried in a session is either provided in-band or in a GFDT. The
1040 GFD payload header as defined in Section 4.2.1.5 shall be used. The
1041 GFD payload header contains a CodePoint field that shall be used to
1042 communicate to a MMTP receiver the settings for information that is
1043 established for the current MMTP session and may even vary during a
1044 MMTP session. The mapping between settings and Codepoint values is
1045 communicated in the a GFDT as described in Section 4.2.1.1. Let T >
1046 0 be the Transfer-Length of any object in bytes. The data carried in
1047 the payload of a packet consists of a consecutive portion of the
1048 object. Then for any arbitrary X and any arbitrary Y > 0 as long as
1049 X + Y is at most T, an MMTP packet may be generated. In this case
1050 the followings shall hold:
1052 1. The data carried in the payload of a packet shall consist of a
1053 consecutive portion of the object starting from the beginning of
1054 byte X through the beginning of byte X + Y.
1056 2. The start_offset field in the GFD payload header shall be set to
1057 X and the payload data shall be added into the packet to send.
1059 3. If X + Y is identical to T,
1061 * the payload header flag B shall be set to "1".
1063 * else
1065 * the payload header flag B shall be set to "0".
1067 The following procedure is recommended for a MMTP sender to deliver
1068 an object to generate packets containing start_offset and
1069 corresponding payload data.
1071 1. Set the byte offset counter X to "0"
1073 2. For the next packets to be delivered set the length in bytes of a
1074 payload to a value Y, which is
1076 * reasonable for a packet payload (e.g., ensure that the total
1077 packet size does not exceed the MTU), and
1079 * such that the sum of X and Y is at most T, and
1081 * such that it is suitable for the payload data included in the
1082 packet
1084 3. Generate a packet according to the rules a to c from above
1086 4. If X + Y is equal to T,
1088 * set the payload header flag B to "1"
1090 * else
1092 * set the payload header flag B to "0"
1094 * increment X = X + Y
1096 * goto 2
1098 The order of packet delivery is arbitrary, but in the absence of
1099 other constraints delivery with increasing start_offset number is
1100 recommended. Note that the transfer length may be unknown prior to
1101 sending earlier pieces of the data. In this case, T may be
1102 determined later. However, this does not affect the sending process
1103 above. Additional packets may be sent following the rules in 1 to 3
1104 from above. In this case the B flag shall only be set for the
1105 payload that contains the last portion of the object.
1107 5.3.2. GFD Payload
1109 The bytes of the object are referenced such that byte 0 is the
1110 beginning of the object and byte T-1 is the last byte of the object
1111 with T is the transfer length (in bytes) of the object. The data
1112 carried in the payload of an MMTP packet shall consist of a
1113 consecutive portion of the object starting from the beginning of byte
1114 X and ending at the beginning of byte X + Y where
1116 1. X is the value of start_offset field in the GFD payload header
1118 2. Y is the length of the payload in bytes
1120 Note that Y is not carried in the packet, but framing shall be
1121 provided by the underlying transport protocol.
1123 5.3.3. GFD Table Delivery
1125 When GFD mode is used, the GFD table (GFDT) shall be provided. A
1126 file that is delivered using the GFD mode, but not described in the
1127 GFD table is not considered a 'file' belonging to the MMTP session.
1128 Any object received with an unmapped CodePoint should be ignored by a
1129 MMTP receiver. Other ways of delivery the GFD table may possible,
1130 but out of scope of this specification.
1132 5.3.4. MMTP receiver operation
1134 The GFDT may contain one or multiple CodePoints identified by
1135 different CodePoint values. Upon receipt of each GFD payload, the
1136 receiver proceeds with the following steps in the order listed.
1138 1. The MMTP receiver shall parse the GFD payload header and verify
1139 that it is a valid header. If it is not valid, then the GFD
1140 payload shall be discarded without further processing.
1142 2. The MMTP receiver shall parse the CodePoint value and verify that
1143 the GFDT contains a matching CodePoint. If it is not valid, then
1144 the GFD payload shall be discarded without further processing.
1146 3. The MMTP receiver should process the remainder of the payload,
1147 including interpreting the other payload header fields
1148 appropriately, and using the source_offset and the payload data
1149 to reconstruct the corresponding object as follows:
1151 1. The MMT receiving can determine from which object a received
1152 GFD payload was generated by using the GFDT., and by the TOI
1153 carried in the payload header.
1155 2. Upon receipt of the first GFD payload for an object, the
1156 MMTP receiver uses the Maximum Transfer Length received as
1157 part of the GFDT to determine the maximum length T' of the
1158 object.
1160 3. The MMTP receiver allocates space for the T' bytes that the
1161 object may require.
1163 4. The MMTP receiver also computes the length of the payload,
1164 Y, by subtracting the payload header length from the total
1165 length of the received payload.
1167 5. The MMTP receiver allocates a Boolean array RECEIVED[0..T'-
1168 1] with all T entries initialized to false to track received
1169 object symbols. The MMTP receiver keeps receiving payloads
1170 for the object block as long as there is at least one entry
1171 in RECEIVED still set to false or until the application
1172 decides to give up on this object.
1174 6. For each received GFD payload for the object (including the
1175 first payload), the steps to be taken to help recover the
1176 object are as follows:
1178 7. Let X be the value of the source_offset field in the GFD
1179 payload header of the MMTP packet. and let Y be the length
1180 of the payload, Y, computed by subtracting the MMTP packet
1181 and GFD payload header lengths from the total length of the
1182 received packet.
1184 8. The MMTP receiver copies the data into the appropriate place
1185 within the space reserved for the object and sets RECEIVED[X
1186 ... X+Y-1] = true.
1188 9. If all T entries of RECEIVED are true, then the receiver has
1189 recovered the entire object.
1191 10. Once the MMTP receiver receives a GFD payload with the B
1192 flag set to 1, it can determine the transfer length T of the
1193 object as X+Y of the corresponding GFD payload and adjust
1194 the boolean array RECEIVED[0..T'-1] to RECEIVED[0..T-1].
1196 6. Session Description information
1198 The MMTP session description information may be delivered to
1199 receivers in different ways to accommodate different deployment
1200 environments. Before a receiver is able to join an MMTP session, the
1201 receiver needs to obtain the following information:
1203 The destination information. In an IP environment, the
1204 destination IP address and port number.
1206 An indication that the session is an MMTP session
1208 The version number of the MMT protocol used in the MMTP session
1210 Additionally, the MMTP session description information should contain
1211 the following information:
1213 The start and end time of the MMTP session.
1215 7. Congestion Control
1217 All transport protocols used on the Internet are required to address
1218 congestion control. MMTP is not an exception, but because the data
1219 transported over MMTP is often inelastic (generated at a fixed or
1220 controlled rate), the means to control congestion in RTP may be quite
1221 different from those for other transport protocols such as TCP. In
1222 one sense, inelasticity reduces the risk of congestion because the
1223 MMTP stream will not expand to consume all available bandwidth as a
1224 TCP stream can. However, inelasticity also means that the MMTP
1225 stream cannot arbitrarily reduce its load on the network to eliminate
1226 congestion when it occurs.
1228 8. IANA Considerations
1230 This internet draft includes no request to IANA.
1232 9. Security Considerations
1234 Lower layer protocols may eventually provide all the security
1235 services that may be desired for applications of MMTP, including
1236 authentication, integrity, and confidentiality. These services have
1237 been specified for IP in [RFC4301].
1239 10. References
1241 10.1. Normative References
1243 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1244 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1245 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1247 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1248 Resource Identifier (URI): Generic Syntax", STD 66, RFC
1249 3986, January 2005.
1251 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
1252 Time Protocol Version 4: Protocol and Algorithms
1253 Specification", RFC 5905, June 2010.
1255 [isopart12]
1256 ISO/IEC, "Information technology High efficiency coding
1257 and media delivery in heterogeneous environments Part 12:
1258 File Format", 2008, .
1260 [mmt] ISO/IEC, "Information technology High efficiency coding
1261 and media delivery in heterogeneous environments Part 1:
1262 MPEG media transport (MMT)", 2014, .
1264 10.2. Informative References
1266 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
1267 Jacobson, "RTP: A Transport Protocol for Real-Time
1268 Applications", STD 64, RFC 3550, July 2003.
1270 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1271 Internet Protocol", RFC 4301, December 2005.
1273 Author's Address
1275 Imed Bouazizi
1276 Samsung Research America
1277 Richardson, TX
1278 US
1280 Phone: +1 972 763 7023
1281 Email: i.bouazizi@samsung.com