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