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