idnits 2.17.1 draft-zia-route-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1463 has weird spacing: '... format or ...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2020) is 1397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Waqar Zia, 2 Thomas Stockhammer 3 Intended status: Informational Qualcomm Incorporated 4 Expires: December 2020 June 29, 2020 6 Real-time Transport Object delivery over Unidirectional Transport 7 (ROUTE) 8 draft-zia-route-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on December 29, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Abstract 62 The Real-time Transport Object delivery over Unidirectional Transport 63 protocol (ROUTE Protocol) is specified for robust delivery of 64 application objects, including application objects with real-time 65 delivery constraints, to receivers over a unidirectional transport. 66 Application objects consist of data that has meaning to applications 67 that use the ROUTE Protocol for delivery of data to receivers, for 68 example, it can be a file, or a DASH or HLS segment, a WAV audio 69 clip, etc. The ROUTE Protocol also supports low-latency streaming 70 applications. 72 The ROUTE Protocol is suitable for unicast, broadcast, and multicast 73 transport. Therefore, it can be run over IP/UDP including multicast 74 IP. ROUTE Protocol can leverage the features of the underlying 75 protocol layer, e.g. to provide security it can leverage IP security 76 protocols such as IPSec. 78 Conventions used in this document 80 In examples, "C:" and "S:" indicate lines sent by the client and 81 server respectively. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC-2119 [RFC2119]. 87 Table of Contents 89 1. Introduction...................................................4 90 1.1. Overview..................................................4 91 1.2. Protocol Stack for ROUTE..................................5 92 1.3. Data Model................................................5 93 1.4. Architecture and Scope of Specification...................6 94 2. ROUTE Packet Format............................................7 95 2.1. Packet Structure and Header Fields........................7 96 2.2. LCT header extensions.....................................9 97 2.3. FEC Payload ID for Source Flows..........................10 98 2.4. FEC Payload ID for Repair Flows..........................10 99 3. Session metadata..............................................11 100 3.1. Generic metadata.........................................11 101 3.2. Session metadata for Source Flows........................11 102 3.3. Session metadata for Repair Flows........................12 103 4. Delivery object mode..........................................13 104 4.1. File Mode................................................13 105 4.1.1. Extensions to FDT...................................13 106 4.1.2. Constraints on Extended FDT.........................15 107 4.2. Entity Mode..............................................15 108 4.3. Unsigned Package Mode....................................16 109 4.4. Signed Package Mode......................................16 110 5. Sender operation..............................................16 111 5.1. Usage of ALC and LCT for Source Flow.....................16 112 5.2. ROUTE Packetization for Source Flow......................17 113 5.2.1. Basic ROUTE Packetization...........................18 114 5.2.2. ROUTE Packetization for CMAF Chunked Content........18 115 5.3. Timing of Packet Emission................................19 116 5.4. Extended FDT Encoding for File Mode Sending..............19 117 5.5. FEC Framework Considerations.............................19 118 5.6. FEC Transport Object Construction........................20 119 5.7. Super-Object Construction................................21 120 5.8. Repair Packet Considerations.............................22 121 5.9. Summary FEC Information..................................22 122 6. Receiver operation............................................23 123 6.1. Basic Application Object Recovery for Source Flows.......23 124 6.2. Fast Stream Acquisition..................................25 125 6.3. Generating Extended FDT Instance for File Mode...........25 126 6.3.1. File Template Substitution for Content-Location 127 Derivation.................................................25 128 6.3.2. File@Transfer-Length Derivation.....................26 129 6.3.3. FDT-Instance@Expires Derivation.....................26 130 7. FEC Application...............................................26 131 7.1. General FEC Application Guidelines.......................26 132 7.2. TOI Mapping..............................................27 133 7.3. Delivery Object Reception Timeout........................27 134 7.4. Example FEC Operation....................................27 135 8. Considerations for Defining ROUTE Profiles....................28 136 9. ROUTE Concepts................................................29 137 9.1. ROUTE Modes of Delivery..................................29 138 9.2. File Mode Optimizations..................................30 139 9.3. In band Signaling of Object Transfer Length..............30 140 9.4. Repair Protocol Concepts.................................31 141 10. Interoperability Chart.......................................31 142 11. Security Considerations......................................33 143 12. IANA Considerations..........................................33 144 13. References...................................................33 145 13.1. Normative References....................................33 146 13.2. Informative References..................................34 147 14. Acknowledgments..............................................35 149 1. Introduction 151 1.1. Overview 153 The Real-time Transport Object delivery over Unidirectional Transport 154 protocol (ROUTE Protocol) can be used for robust delivery of 155 Application Objects, including Application Objects with real-time 156 delivery constraints, to receivers over a unidirectional transport. 158 Application objects consist of data that has meaning to applications 159 that use the ROUTE Protocol for delivery of data to receivers, e.g., 160 an Application Object can be a file, or a DASH [DASH] video segment, 161 a WAV audio clip, a CMAF [CMAF] addressable resource, an MP4 video 162 clip, etc. The ROUTE Protocol is designed to enable delivery of 163 sequences of related Application Objects in a timely manner to 164 receivers, e.g., a sequence of DASH video segments associated to a 165 Representation or a sequence of CMAF addressable resources associated 166 to a CMAF Track. The ROUTE Protocol supports chunked delivery of 167 real-time Application Objects to enable low latency streaming 168 applications (similar in its properties to chunked delivery using 169 HTTP). The protocol also enables low-latency delivery of DASH and HLS 170 content with CMAF Chunks. 172 Content not intended for rendering in real time as it is received 173 e.g. a downloaded application, or a file comprising continuous or 174 discrete media and belonging to an app-based feature, or a file 175 containing (opaque) data to be consumed by a DRM system client can 176 also delivered by ROUTE. 178 The ROUTE Protocol supports a caching model, where application 179 objects are recovered into a cache at the receiver and may be made 180 available to applications via standard HTTP requests from the cache. 182 Profiles of ROUTE Protocol have already been specified in ATSC 3.0 183 [ATSCA331] and DVB Adaptive Media Streaming over IP Multicast 184 [DVBMABR]. Hence in the context of this RFC, the aforementioned ATSC 185 3.0 and DVB systems are the applications using ROUTE. This RFC serves 186 as a direct reference for such applications in the future and allows 187 for deriving specific profiles based on the protocol specified in 188 this RFC. 190 1.2. Protocol Stack for ROUTE 192 ROUTE delivers application objects such as MPEG DASH or HLS segments 193 and optionally the associated repair data, operating over UDP/IP 194 networks supporting IP multicast. The session metadata signaling to 195 realize ROUTE session as specified in this RFC MAY be delivered out- 196 of-band or in band as well. Additionally, the application may use 197 unicast delivery mechanisms over e.g. HTTP over TCP/IP in conjunction 198 with ROUTE to augment the services. The latter unicast delivery 199 aspects are beyond the scope of this RFC. 201 +-----------------------------------+ 202 |Application (DASH, HLS, CMAF, etc.)| 203 +-----------------------------------+ 204 | ROUTE | 205 +-----------------------------------+ 206 | UDP | 207 +-----------------------------------+ 208 | IP | 209 +-----------------------------------+ 211 Figure 1 Protocol Layering 213 1.3. Data Model 215 The ROUTE data model is constituted by the following key concepts. 217 Application object - data that has meaning to the application that 218 uses the ROUTE Protocol for delivery of data to receivers, e.g., an 219 application object can be a file, or a DASH video segment, a WAV 220 audio clip, an MP4 video clip, etc. 222 Delivery objects - Objects on course of delivery to the application 223 from the ROUTE sender to ROUTE receiver. 225 Transport Object - as defined by RFC 5651 [RFC5651], it MAY be a 226 either a source or a repair object. 228 Transport Session - An LCT channel, as defined by RFC 5651 229 [RFC5651]. Transport session SHALL be uniquely identified by a 230 unique Transport Session Identifier (TSI) value in the LCT header. 231 The TSI is scoped by the IP address of the sender, and the IP address 232 of the sender together with the TSI SHALL uniquely identify the 233 session. Transport sessions are a subset of a ROUTE session. For 234 media delivery, a Transport Session would typically carry a media 235 component, for example a DASH Representation. Within each transport 236 session, one or more objects are carried, typically objects that are 237 related, e.g. DASH Segments associated to one Representation. 239 ROUTE Session - An ensemble or multiplex of one or more Transport 240 Sessions. Each ROUTE Session SHALL be associated with an IP 241 address/port combination. ROUTE session typically carries one or more 242 media components of streaming media e.g. Representations associated 243 with a DASH Media Presentation. 245 Source Flows - Transport sessions carrying source data. Source Flow 246 is independent of the repair Flow, i.e. the Source Flows MAY be used 247 by a ROUTE receiver without the ROUTE Repair Flows. 249 Repair Flows - Transport sessions carrying repair data for one or 250 more Source Flows. 252 1.4. Architecture and Scope of Specification 254 The scope of the ROUTE protocol is robust and real-time transport of 255 delivery objects using LCT packets. This architecture is depicted in 256 Figure 2. 257 The normative aspects of the ROUTE protocol focus on the following 258 aspects: 259 - The format of the LCT packets that carry the transport objects. 260 - The robust transport of the delivery object using a repair 261 protocol based on FEC. 262 - The definition and possible carriage of object metadata along with 263 the delivery objects. Metadata may be conveyed in LCT packets and/or 264 separate objects. 265 - The ROUTE session, LCT channel and delivery object description 266 provided as service metadata signaling to enable the reception of 267 objects. 268 - The normative aspects (formats, semantics) of the delivery objects 269 conveyed as a content manifest to be delivered along with the objects 270 to optimize the performance for specific applications; e.g., real- 271 time delivery. The objects and manifest are made available to the 272 application through an application object cache. The interface of 273 this cache to the application is not specified in this RFC, however 274 it will typically be enabled by the application acting as an HTTP 275 Client and the cache as the HTTP server. 277 application objects 278 Application to application 279 Objects from ^ 280 an application +--------------------------------------------+ 281 + | ROUTE Receiver | | 282 | | +------+------+ | 283 | | | Application | | 284 | | | Object Cache| | 285 | | +------+------+ | 286 | LCT over| +---------------+ ^ | 287 v UDP/IP | | Source object | +---------+ | | 288 +----+---+ | +->+ recovery +--+ Repair +-+ | 289 | ROUTE | | | +---------------+ +----+----+ | 290 | Sender +----------+ ^ | 291 +----+---+ | | | | 292 | | | +---------------+ | | 293 | | | | Repair object | | | 294 | | +->+ recovery +-------+ | 295 +----------->+ +---------------+ | 296 ROUTE | | 297 Metadata +--------------------------------------------+ 299 Figure 2 Architecture/functional block diagram 301 2. ROUTE Packet Format 303 2.1. Packet Structure and Header Fields 305 The packet format used by ROUTE Source Flows and Repair Flows follows 306 the ALC packet format specified in RFC 5775 [RFC5775], with the UDP 307 header followed by the default LCT header and the source FEC Payload 308 ID followed by the packet payload. The overall ROUTE packet format is 309 as depicted in Figure 3 below. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | UDP Header | 315 | | 316 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 317 | Default LCT header | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | FEC Payload ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Payload Data | 323 | ... | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 3 Overall ROUTE packet format 327 The Default LCT header is as defined in the LCT building block in RFC 328 5651 [RFC5651]. 330 The LCT packet header fields SHALL be used as defined by the LCT 331 building block in RFC 5651 [RFC5651]. The semantics and usage of the 332 following LCT header fields SHALL be further constrained in ROUTE as 333 follows: 335 Version number (V) - This 4-bit field indicates the protocol version 336 number. The version number for this specification is '0001'. The 337 version number field of the LCT header SHALL be interpreted as the 338 ROUTE version number field. This version of ROUTE implicitly makes 339 use of version 1 of the LCT building block defined in RFC 5651 340 [RFC5651]. 342 Congestion Control flag (C) field - This 2-bit field, as defined in 343 RFC 5651 [RFC5651], SHALL be set to '00'. 345 Protocol-Specific Indication (PSI) - The first bit of this two bit 346 flag indicates whether the current packet is a source packet or an 347 FEC repair packet. The first bit of the Protocol Specific Indication 348 (PSI bit X), the Source Packet Indicator (SPI), SHALL be set to '1' 349 and '0' to indicate a source packet and a repair packet, 350 respectively. 351 If the payload of this packet is carrying the first part of a CMAF 352 Random Access chunk, except for the first CMAF chunk in a segment, 353 the least significant bit of the Protocol Specific Information (PSI) 354 field MAY be set to 1. 356 Transport Session Identifier flag (S) - This 1-bit field SHALL be set 357 to '1' to indicate a 32-bit word in the TSI field. 359 Transport Object Identifier flag (O) - This 2-bit field SHALL be set 360 to '01' to indicate the number of full 32-bit words in the TOI field. 362 Half-word flag (H) - This 1-bit field SHALL be set to '0' to indicate 363 that no half-word field sizes are used. 365 Codepoint (CP) - This 8-bit field is used to indicate the type of the 366 payload that is carried by this packet, and for ROUTE, is defined as 367 shown below to indicate the type of delivery object carried in the 368 payload of the associated ROUTE packet. The remaining, unmapped 369 Codepoint values MAY be used by an application using ROUTE, as show 370 in the following table: 372 Codepoint value | Semantics 373 ---------------------------------------------------- 374 0 | Reserved (not used) 375 1 | NRT - File Mode 376 2 | NRT - Entity Mode 377 3 | NRT - Unsigned Package Mode 378 4 | NRT - Signed Package Mode 379 5 | New IS, timeline changed 380 6 | New IS, timeline continued 381 7 | Redundant IS 382 8 | Media Segment, File Mode 383 9 | Media Segment, Entity Mode 384 10 - 255 | Application specific 386 Congestion Control Information (CCI) - For packets carrying DASH 387 segments, should convey the earliest presentation time contained in 388 the ROUTE packet. Otherwise this field MAY be set to 0. 390 Transport Session Identifier (TSI) - This 32-bit field SHALL identify 391 the Transport Session in ROUTE. The context of the Transport Session 392 is provided by signaling metadata. The TSI field is constrained to a 393 length of 32 bits because the Transport Session Identifier flag (S) 394 must be set to '1' and the Half-word flag (H) must be set to '0'. 396 Transport Object Identifier (TOI) - This 32-bit field SHALL identify 397 the object within this session to which the payload of the current 398 packet belongs. The mapping of the TOI field to the object is 399 provided by the Extended FDT. The TOI field is constrained to a 400 length of 32 bits because the Transport Object Identifier flag (O) 401 must be set to '01' and the Half-word flag (H) must be set to '0'. 403 2.2. LCT header extensions 405 The following LCT header extensions are defined or used by ROUTE: 407 EXT_FTI - as specified in RFC 5775. 409 EXT_TOL - with 24 bits or, if required, 48 bits of Transfer Length. 410 The frequency of using the EXT_TOL header extension is determined by 411 channel conditions that may cause the loss of the packet carrying 412 Close Object (B) flag. 413 NOTE: The transport object length can also be determined without the 414 use of EXT_TOL by examining the LCT packet with the Close Object (B) 415 flag. However, if this packet is lost, then the EXT_TOL information 416 can be used by the receiver to determine the transport object length. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | HET = 194 | Transfer Length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 0 1 2 3 424 Figure 5. 24-bit format of EXT_TOL Header. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | HET = 67 | HEL | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 431 | Transfer Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 6. 48-bit format of EXT_TOL Header. 435 EXT_TIME Header - as specified in RFC 5651 [RFC5651]. The Sender 436 Current Time SHALL be signaled using EXT_TIME. 438 2.3. FEC Payload ID for Source Flows 440 The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme 441 used in ROUTE Source Flows SHALL be a 32-bit unsigned integer value 442 that expresses the start_offset, as an octet number corresponding to 443 the first octet of the fragment of the delivery object carried in 444 this packet. Figure 7 shows the 32-bit start_offset field. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | start_offset | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 7 FEC Payload ID for Source Flows. 453 2.4. FEC Payload ID for Repair Flows 455 In accordance with RFC 6330 Section 3.2, the FEC Payload ID for the 456 RaptorQ FEC Scheme used for Repair Flows is composed of a Source 457 Block Number (SBN) and an Encoding Symbol ID, formatted as shown in 458 Figure 8. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | SBN | Encoding Symbol ID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 8 FEC Payload ID for Repair Flows. 467 3. Session metadata 469 The required session metadata for Source and Repair Flows is 470 specified in the following sections. The list specified here is not 471 exhaustive; an application MAY signal more metadata to meet its 472 needs. The data format is also not specified beyond its cardinality, 473 and basic type (e.g. integral or alphanumeric data); the exact format 474 of specifying the data is left for the application, e.g. by using XML 475 encoding format. It is specified if an attribute is mandatory (m), 476 conditional mandatory (cm) or optional (o) to realize a basic ROUTE 477 session. The delivery of the session metadata to the ROUTE receiver 478 is beyond scope of this RFC. 480 3.1. Generic metadata 482 Generic metadata is applicable to both Source and Repair Flows as 483 follows. Before a receiver can join a ROUTE session, the receiver 484 needs to obtain this generic metadata that contains at least the 485 following information: 487 - Connection ID (m): unique identifier of a Connection, usually 488 consisting of source IP address/source port number, destination IP 489 address/destination port number. 491 3.2. Session metadata for Source Flows 493 stsi (m) - LCT TSI value corresponding to the transport session for 494 the Source Flow. 496 rt (o) - A Boolean flag which SHALL indicate whether the content 497 component carried by this Source Flow corresponds to real-time 498 streaming media, or non-real-time content. When set to "true", it 499 SHALL be an indication of real-time content, and when absent or set 500 to "false", it SHALL be an indication of non-real-time (NRT) content. 502 minBufferSize (o) - A 32-bit unsigned integer which SHALL represent, 503 in kilobytes, the minimum required storage size of the receiver 504 transport buffer, for the parent LCT channel of this Source Flow. 505 This attribute SHALL only be applicable when rt = "true". When rt 506 "true" and this attribute is absent, the minimum receiver transport 507 buffer size is unknown. 509 EFDT (cm) - when present, SHALL contain a single instance of an FDT- 510 Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain FDT 511 extensions as defined in Section 4.1. The EFDT element MAY only be 512 present for File Mode of delivery. In File Mode, it SHALL be present 513 if this Source Flow transports streaming media segments. 515 contentType (o) - A string that SHALL represent media type assigned 516 by IANA for the media content. contentType SHALL obey the semantics 517 of the Content-Type header of HTTP/1.1 protocol RFC 7231 [RFC7231]. 519 applicationMapping (m) - A set of identifiers that provide an 520 application-specific mapping of the received application objects to 521 the Source Flows. For example, for DASH, this would provide the 522 mapping a Source Flow to a specific DASH representation from an MPD, 523 the latter identified by its Representation and corresponding 524 Adaptation Set and Period IDs. 526 3.3. Session metadata for Repair Flows 528 maximumDelay (o) - An integer value, when present, SHALL represent 529 the maximum delivery delay, in milliseconds, between any source 530 packet in the Source Flow and the repair packet, associated with that 531 source packet, in the Repair Flow. Default semantics of this 532 attribute, when absent, is not defined. 534 overhead (o) - An integer whose value SHALL represent the sum of the 535 AL-FEC related fields in the ROUTE repair packet relative to the size 536 of the repair packet size as a percentage. 538 minBuffSize (o) - A 32-bit unsigned integer whose value SHALL 539 represent a required size of the receiver transport buffer for AL-FEC 540 decoding processing. When present, this attribute SHALL indicate the 541 minimum buffer size that is required to handle all associated objects 542 that are assigned to a super-object i.e. a delivery object formed by 543 the concatenation of multiple FEC transport objects in order to 544 bundle these FEC transport objects for AL-FEC protection. 546 fecOTI (m) - A parameter consisting of the concatenation of Common 547 and Scheme-Specific FEC Object Transmission Information (FEC OTI) as 548 defined in Sections 3.3.2 and 3.3.3 of RFC 6330 [RFC6330], and which 549 corresponds to the delivery objects carried in the Source Flow to 550 which this Repair Flow is associated, with the following 551 qualification. The 40-bit Transfer Length (F) field may either 552 represent the actual size of the object, or it is encoded as all 553 zeroes. In the latter case, it means that the FEC transport object 554 size is either unknown, or cannot be represented by this attribute. 555 In other words, for the all-zeroes format, the delivery objects in 556 the Source flow correspond to streaming content - either a live 557 Service whereby content encoding has not yet occurred at the time 558 this session data was generated, or pre-recorded streaming content 559 whose delivery object sizes, albeit known at the time of session data 560 generation, are variable and cannot be represented as a single value 561 by the fecOTI attribute. 563 ptsi (m) - TSI value(s) of each Source Flow protected by this Repair 564 Flow. 566 mappingTOIx (o) - Values of the constant X for use in deriving the 567 TOI of the delivery object of each protected Source Flow from the 568 TOI of the FEC (super-)object. The default value SHALL be "1". 569 Multiple mappingTOIx values MAY be provided for each protected Source 570 Flow. 572 mappingTOIy (o) - The corresponding constant Y to each mappingTOIx, 573 when present, for use in deriving the parent SourceTOI value from the 574 above equation. The default value SHALL be "0". 576 4. Delivery object mode 578 ROUTE provides several different delivery object modes, and one of 579 these modes may suite the application needs better for a given 580 transport session. A delivery object is self-contained for the 581 application, typically associated with certain properties, metadata 582 and timing-related information that are of relevance for the 583 application. The signaling of the delivery object mode is done on an 584 object based using Codepoint as specified in Section 2.1. 586 4.1. File Mode 588 File mode uses an out-of-band EDFT signaling for recovery of delivery 589 objects with the following extensions and considerations. 591 4.1.1. Extensions to FDT 593 Following extensions are specified to FDT specified in RFC 6726 594 [RFC6726]. Here an Extended FDT Instance is an instance of the FLUTE 595 [RFC6726] FDT that includes extensions. 597 efdtVersion - A value that SHALL represent the version of this 598 Extended FDT Instance. 600 maxExpiresDelta - A value, which when present, SHALL represent a time 601 interval in number of seconds, which when added to the wall clock 602 time at the receiver when the receiver acquires the first ROUTE 603 packet carrying data of the object described by this Extended FDT 604 Instance, SHALL represent the expiration time of the associated 605 Extended FDT Instance. When maxExpiresDelta is not present, the 606 expiration time of the Extended FDT Instance SHALL be given by the 607 sum of a) the value of the ERT field in the EXT_TIME LCT header 608 extension in the first ROUTE packet carrying data of that file, and 609 b) the current receiver time when parsing the packet header of that 610 ROUTE packet. See Sections 5.4 and 6.3.3 on additional rules for 611 deriving the Extended FDT Instance expiration time. 613 maxTransportSize - An attribute that SHALL represent the maximum 614 transport size in bytes of any delivery object described by this 615 Extended FDT Instance. This attribute SHALL be present if a) the 616 fileTemplate is present in Extended FDT-Instance; or b) one or more 617 File elements, if present in this Extended FDT Instance, do not 618 include the Transfer-Length attribute. When maxTransportSize is not 619 present, the maximum transport size is not signaled. 621 fileTemplate - A string value, which when present and in conjunction 622 with parameter substitution, SHALL be used in deriving the Content- 623 Location attribute, for the delivery object described by this 624 Extended FDT Instance. It SHALL include the "$TOI$" identifier. Each 625 identifier MAY be suffixed, within the enclosing '$' characters 626 following this prototype: 627 %0[width]d 628 The width parameter is an unsigned integer that provides the minimum 629 number of characters to be printed. If the value to be printed is 630 shorter than this number, the result SHALL be padded with leading 631 zeroes. The value is not truncated even if the result is larger. When 632 no format tag is present, a default format tag with width=1 SHALL be 633 used. 635 Strings other than identifiers SHALL only contain characters that are 636 permitted within URIs according to RFC 3986 [RFC3986]. 638 $$ Is an escape sequence in fileTemplate value, i.e. "$$" is non- 639 recursively replaced with a single "$" 641 The usage of fileTemplate is described in Sender and Receiver 642 operations in Sections 5.4 and 6.3, respectively. 644 4.1.2. Constraints on Extended FDT 646 The Extended FDT Instance SHALL conform to an FDT Instance according 647 to RFC 6726 [RFC6726], with the following constraints: at least one 648 File element and the @Expires attribute SHALL be present. 650 Content encoding MAY be used for delivery of any file described by an 651 FDT-Instance.File element in the Extended FDT Instance. The content 652 encoding defined in the present RFC is gzip [RFC1952]. When content 653 encoding is used, the File@Content-Encoding and File@Content-Length 654 attributes SHALL be present in the Extended FDT Instance. 656 4.2. Entity Mode 658 For Entity Mode, the following applies: 660 - Delivery object metadata SHALL be expressed in the form of entity 661 headers as defined in HTTP/1.1, and which correspond to one or 662 more of the representation header fields, payload header fields 663 and response header fields as defined in Sections 3.1, 3.3 and 7, 664 respectively, of RFC 7231. Additionally, a Digest HTTP response 665 header [RFC7231] MAY be included to enable a receiver to verify 666 the integrity of the multicast transport object. 667 - The entity headers sent along with the delivery object provide all 668 information about that multicast transport object. 670 Sending a media object (if the object is chunked) in Entity Mode 671 may result in one of the following options: 673 If the length of the chunked object is known at sender, the ROUTE 674 Entity Mode delivery object MAY be sent without using HTTP/1.1 675 chunked transfer coding, i.e. the object starts with an HTTP 676 header containing the Content Length field, followed by the 677 concatenation of CMAF chunks: 679 |HTTP Header+Length||---chunk ----||---chunk ----||---chunk ---- 680 ||---chunk ----| 682 If the length of the chunked object is unknown at sender when 683 starting to send the object, HTTP/1.1 chunked transfer coding 684 format SHALL be used: 686 |HTTP Header||Separator+Length||---chunk ----||Separator+Length||- 687 --chunk ----||Separator+Length||---chunk ----||Separator+Length||- 688 --chunk ----||Separator+Length=0| 689 Note, however, that it is not required to send a CMAF chunk in 690 exactly one HTTP chunk. 692 4.3. Unsigned Package Mode 694 In this delivery mode, the delivery object consists of a group of 695 files that are packaged for delivery only. If applied, the client is 696 expected to unpack the package and provide each file as an 697 independent object to the application. Packaging is supported by 698 Multipart MIME [RFC2557], where objects are packaged into one 699 document for transport. 701 4.4. Signed Package Mode 703 In Signed Package Mode delivery, the delivery object consists of a 704 group of files that are packaged for delivery, and the package 705 includes one or more signatures for validation. Signed packaging is 706 supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects 707 are packaged into one document for transport and the package includes 708 objects necessary for validation of the package. 710 5. Sender operation 712 5.1. Usage of ALC and LCT for Source Flow 714 The usage of ALC for ROUTE Source Flow is as defined in RFC 5775 715 [RFC5775]. There are several special considerations that ROUTE 716 introduces to the usage of the LCT building block as outlined in the 717 following: 719 - ROUTE limits the usage of the LCT building block to a single 720 channel per session. Congestion control is thus sender-driven in 721 ROUTE. The functionality of receiver-driven layered multicast may 722 still be offered by the application, allowing the receiver 723 application to select the appropriate delivery session based on 724 the bandwidth requirement of that session. 726 Further, following details apply to LCT: 728 - The Layered Coding Transport (LCT) Building Block as defined in 729 RFC 5651 [RFC5651] is used with the following constraints: 730 oThe TSI in the LCT header SHALL be set equal to the value of 731 the stsi attribute in Section 3.2. 732 oThe Codepoint (CP) in the LCT header SHALL be used to signal 733 the applied formatting as defined in the signaling metadata. 735 oIn accordance to ALC, a source FEC Payload ID header is used to 736 identify, for FEC purposes, the encoding symbols of the 737 delivery object, or a portion thereof, carried by the 738 associated ROUTE packet. This information may be sent in 739 several ways: 740 . As a simple new null FEC scheme with the following usage: 741 . The value of the source FEC Payload ID header SHALL 742 be set to 0, in case the ROUTE packet contains the 743 entire delivery object, or 744 . The value of the source FEC Payload ID header SHALL 745 be set as a direct address (start offset) 746 corresponding to the starting byte position of the 747 portion of the object carried in this packet using 748 a 32-bit field. 749 . In a compatible manner to RFC 6330 [RFC6330] where the 750 SBN and ESI defines the start offset together with the 751 symbol size T. 752 . The signaling metadata provides the appropriate 753 parameters to indicate any of the above modes using the 754 srcFecPayloadId attribute. 755 - The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC5651] 756 MAY be used by the sender in the following manner: 757 oThe Sender Current Time (SCT), depending on the application, 758 MAY be used to occasionally or frequently signal the sender 759 current time. 760 oThe Expected Residual Time (ERT) MAY be used to indicate the 761 expected remaining time for transmission of the current 762 object. 763 oThe Sender Last Changed (SLC) flag is typically not utilized, 764 but MAY be used to indicate addition/removal of Segments. 765 - Additional extension headers MAY be used to support real-time 766 delivery. Such extension headers are defined in Section 2.1. 768 5.2. ROUTE Packetization for Source Flow 770 The following description of the ROUTE sender operation on the 771 mapping of the application object to the ROUTE packet payloads 772 logically represents an extension of RFC 5445 [RFC5445], which in 773 turn inherits the context, language, declarations and restrictions of 774 the FEC building block in RFC 5052 [RFC5052]. 776 The data carried in the payload of a given ROUTE packet constitute a 777 contiguous portion of the application object. ROUTE source delivery 778 can be considered as a special case of the use of the Compact No-Code 779 Scheme associated with FEC Encoding ID = 0 according to Sections 780 3.4.1 and 3.4.2 of RFC 5445 [RFC5445], in which the encoding symbol 781 size is exactly one byte. As specified in Section 2.1, for ROUTE 782 Source Flows, the FEC Payload ID SHALL deliver the 32-bit 783 start_offset. All receivers are expected to support, at minimum, 784 operation with this special case of the Compact No-Code FEC. 786 Note that in the event the source object size is greater than 2^32 787 bytes (approximately 4.3 GB), the applications (in the broadcaster 788 server and the receiver) are expected to perform segmentation/re- 789 assembly using methods beyond the scope of this transport Standard. 791 Finally, in some special cases a ROUTE sender MAY need to produce 792 ROUTE packets that do not contain any payload. This may be required, 793 for example, to signal the end of a session or to convey congestion 794 control information. These data-less packets do not contain FEC 795 Payload ID or payload data, but only the LCT header fields. The total 796 datagram length, conveyed by outer protocol headers (e.g., the IP or 797 UDP header), enables receivers to detect the absence of the LCT 798 header, FEC Payload ID and payload data. 800 5.2.1. Basic ROUTE Packetization 802 In the basic operation, it is assumed that the application object is 803 fully available at the ROUTE sender. 805 1. The amount of data to be sent in a single ROUTE packet is limited 806 by the maximum transfer unit of the data packets or the size of the 807 remaining data of the application object being sent, whichever is 808 smaller. The transfer unit is determined either by knowledge of 809 underlying transport block sizes or by other constraints. 810 2. The start_offset field in the LCT header of the ROUTE packet 811 indicates the byte offset of the carried data in the application 812 object being sent. 813 3. The Close Object (B) flag is set to 1 if this is the last ROUTE 814 packet carrying the data of the application object. 816 The order of packet delivery is arbitrary, but in the absence of 817 other constraints delivery with increasing start_offset value is 818 recommended. 820 5.2.2. ROUTE Packetization for CMAF Chunked Content 822 Following additional guidelines should be followed for ROUTE 823 packetization of CMAF Chunked Content in addition to the guideline of 824 Section 5.2.1: 826 1. As specified in Section 2.1, if it is the first ROUTE packet 827 carrying a CMAF Random Access chunk, except for the first CMAF chunk 828 in the segment, the least significant bit of the Protocol Specific 829 Information (PSI) field in the LCT header MAY be set to 1. The 830 receiver MAY use this information for optimization of random access. 831 2. As soon as the total length of the media object is known, 832 potentially with the packaging of the last CMAF chunk of a segment, 833 the EXT_TOL extension header MAY be added to the LCT header to signal 834 the Transfer Length. 836 5.3. Timing of Packet Emission 838 The sender SHALL use the timing information provided by the 839 application to time the emission of packets for a timely reception. 840 This information may be contained in the application objects e.g. 841 DASH Segments and/or the presentation manifest. Hence such packets of 842 streaming media with real time constraints SHALL be sent in such a 843 way to enable their timely reception with respect to the presentation 844 timeline. 846 5.4. Extended FDT Encoding for File Mode Sending 848 For File Mode Sending: 850 - The TOI field in the ROUTE packet header SHALL be set such that 851 Content-Location can be derived at the receiver according to File 852 Template substitution specified in Section 6.3.1. 853 - After sending the first packet with a given TOI value, none of the 854 packets pertaining to this TOI SHALL be sent later than the wall 855 clock time as derived from maxExpiresDelta. The EXT_TIME header 856 with Expected Residual Time (ERT) MAY be used in order to convey 857 more accurate expiry time. 859 5.5. FEC Framework Considerations 861 The FEC framework uses concepts of the FECFRAME work as defined in 862 RFC 6363 [RFC6363], as well as the FEC building block, RFC 5052 863 [RFC5052], which is adopted in the existing FLUTE/ALC/LCT 864 specifications. 865 The FEC design adheres to the following principles: 866 - FEC-related information is provided only where needed. 867 - Receivers not capable of this framework can ignore repair packets. 868 - The FEC is symbol-based with fixed symbol size per protected 869 Repair Flow. The ALC protocol and existing FEC schemes are reused. 870 - A FEC Repair Flow provides protection of delivery objects from one 871 or more Source Flows. 872 The FEC-specific components of the FEC framework are: 873 - FEC Repair Flow declaration including all FEC-specific 874 information. 876 - FEC transport object that is the concatenation of a delivery 877 object, padding octets and size information in order to form an N- 878 symbol-sized chunk of data, where N >= 1. 879 - FEC super-object that is the concatenation of one or more FEC 880 transport objects in order to bundle FEC transport objects for FEC 881 protection. 882 - FEC protocol and packet structure. 883 A receiver needs to be able to recover delivery objects from repair 884 packets based on available FEC information. 886 5.6. FEC Transport Object Construction 888 In order to identify a delivery object in the context of the Repair 889 protocol, the following information is needed: 891 - TSI and TOI of the delivery object. In this case, the FEC object 892 corresponds to the (entire) delivery object. 893 - Octet range of the delivery object, i.e. start offset within the 894 delivery object and number of subsequent and contiguous octets of 895 delivery object that constitutes the FEC object (i.e., the FEC- 896 protected portion of the source object). In this case, the FEC 897 object corresponds to a contiguous byte range portion of the 898 delivery object. 900 Typically, the first mapping is applied; i.e., the delivery object is 901 an FEC object. 902 Assuming that the FEC object is the delivery object, for each 903 delivery object, the associated FEC transport object is comprised of 904 the concatenation of the delivery object, padding octets (P) and the 905 FEC object size (F) in octets, where F is carried in a 4-octet field. 906 The FEC transport object size S, in FEC encoding symbols, SHALL be an 907 integer multiple of the symbol size Y. 908 S is determined from the session information and/or the repair packet 909 headers. 910 F is carried in the last 4 octets of the FEC transport object. 911 Specifically, let: 913 - F be the size of the delivery object in octets, 914 - F' be the F octets of data of the delivery object, 915 - f' denote the four octets of data carrying the value of F in 916 network octet order (high-order octet first), 917 - S be the size of the FEC transport object with S=ceil((F+4)/Y), 918 where the ceil() function rounds the result upward to its nearest 919 integer, 920 - P' be S*Y-4-F octets of data, i.e. padding placed between the 921 delivery object and the 4-byte field conveying the value of F and 922 located at the end of the FEC transport object, and 924 - O' be the concatenation of F', P' and f'. 926 O' then constitutes the FEC transport object of size S*Y octets. Note 927 that padding octets and the object size F are NOT sent in source 928 packets of the delivery object, but are only part of an FEC transport 929 object that FEC decoding recovers in order to extract the FEC object 930 and thus the delivery object or portion of the delivery object that 931 constitutes the FEC object. In the above context, the FEC transport 932 object size in symbols is S. 934 The general information about an FEC transport object that is 935 conveyed to an FEC-enabled receiver is the source TSI, source TOI and 936 the associated octet range within the delivery object comprising the 937 associated FEC object. However, as the size in octets of the FEC 938 object is provided in the appended field within the FEC transport 939 object, the remaining information can be conveyed as: 940 - TSI and TOI of the delivery object from which the FEC object 941 associated with the FEC transport object is generated 942 - Start octet within delivery object for the associated FEC object 943 - Size in symbols of the FEC transport object, S 945 5.7. Super-Object Construction 947 From the FEC Repair Flow declaration, the construction of an FEC 948 super-object as the concatenation of one or more FEC transport 949 objects can be determined. The FEC super-object includes the general 950 information about the FEC transport objects as described in the 951 previous sections, as well as the placement order of FEC transport 952 objects within the FEC super-object. 954 Let: 955 - N be the total number of FEC transport objects for the FEC super- 956 object construction. 957 - For i = 0,..., N-1, let S[i] be the size in symbols of FEC 958 transport object i. 959 - B' be the FEC super-object which is the concatenation of the FEC 960 transport objects in numerical order, comprised of K = 961 .((i=0)to(N-1))S[i] source symbols. 963 For each FEC super-object, the remaining general information that 964 needs to be conveyed to an FEC-enabled receiver, beyond what is 965 already carried in the FEC transport objects that constitute the FEC 966 super-object, comprises: 968 - The total number of FEC transport objects N. 969 - For each FEC transport object, the: 971 oTSI and TOI of the delivery object from which the FEC object 972 associated with the FEC transport object is generated, 973 oStart octet within delivery object for the associated FEC 974 object, and 975 oSize in symbols of the FEC transport object. 977 The carriage of the FEC repair information is discussed below. 979 5.8. Repair Packet Considerations 981 The repair protocol is based on Asynchronous Layered Coding (ALC) as 982 defined in RFC 5775 [RFC5775] and the Layered Coding Transport (LCT) 983 Building Block as defined in RFC 5651 [RFC5651] with the following 984 details: 986 - The Layered Coding Transport (LCT) Building Block as defined in RFC 987 5651 [RFC5651] is used as defined in Asynchronous Layered Coding 988 (ALC), Section 2.1. In addition, the following constraints apply: 989 - The TSI in the LCT header SHALL identify the Repair Flow to 990 which this packet applies, by the matching value of the ptsi 991 attribute in the signaling metadata among the LCT channels 992 carrying Repair Flows. 993 - The FEC building block is used according to RFC 6330 [RFC6330], but 994 only repair packets are delivered. 995 - Each repair packet within the scope of the Repair Flow (as 996 indicated by the TSI field in the LCT header) SHALL carry the 997 repair symbols for a corresponding FEC transport object/super- 998 object as identified by its TOI. The repair object/super-object 999 TOI SHALL be unique for each FEC super-object that is created 1000 within the scope of the TSI. 1002 5.9. Summary FEC Information 1004 For each super-object (identified by a unique TOI within a Repair 1005 Flow that is in turn identified by the TSI in the LCT header) that is 1006 generated, the following information needs to be communicated to the 1007 receiver: 1009 . The FEC configuration consisting of: 1010 oFEC Object Transmission Information (OTI) per RFC 5052 1011 [RFC5052]. 1012 oAdditional FEC information (see Section 3.3). 1013 . The total number of FEC objects included in the FEC super-object, 1014 N. 1015 . For each FEC transport object: 1016 oTSI and TOI of the delivery object used to generate the FEC 1017 object associated with the FEC transport object, 1019 oStart octet within the delivery object of the associated FEC 1020 object, if applicable, and 1021 oThe size in symbols of the FEC transport object, S. 1023 The above information is delivered: 1024 . Statically in the session metadata as defined in Section 3.3, 1025 and 1026 . Dynamically in an LCT extension header. 1028 6. Receiver operation 1030 The receiver receives packets and filters those packets according to 1031 the following. From the ROUTE session and each contained LCT channel, 1032 the receiver regenerates delivery objects from the ROUTE session and 1033 each contained LCT channel. The basic receiver information is 1034 provided below. 1036 6.1. Basic Application Object Recovery for Source Flows 1038 Upon receipt of each ROUTE packet of a Source Flow, the receiver 1039 proceeds with the following steps in the order listed. 1040 1) The ROUTE receiver is expected to parse the LCT and FEC Payload ID 1041 to verify that it is a valid header. If it is not valid, then the 1042 payload is discarded without further processing. 1043 2) All ROUTE packets used to recover a specific delivery object carry 1044 the same TOI value in the LCT header. 1045 3) The ROUTE receiver is expected to assert that the TSI and the 1046 Codepoint represent valid operation points in the signaling 1047 metadata, i.e. the signaling contains a matching entry to the TSI 1048 value provided in the packet header, as well as for this TSI, and 1049 Codepoint field in the LCT header has a valid Codepoint mapping. 1050 4) The ROUTE receiver should process the remainder of the payload, 1051 including the appropriate interpretation of the other payload 1052 header fields, and using the source FEC Payload ID (to determine 1053 the start_offset) and the payload data to reconstruct the 1054 corresponding object as follows: 1055 a. For File Mode, upon receipt of the first ROUTE packet 1056 payload for an object, the ROUTE receiver uses the 1057 File@Transfer-Length attribute of the associated Extended FDT 1058 Instance, when present, to determine the length T of the 1059 object. When the File@Transfer-Length attribute is not 1060 present in the Extended FDT Instance, the receiver uses the 1061 maxTransportSize attribute of the associated Extended FDT 1062 Instance to determine the maximum length T' of the object. 1063 Alternatively, and specifically for delivery modes other than 1064 File Mode, EXT_TOL header can be used to determine the length 1065 T of the object. 1066 b. The ROUTE receiver allocates buffer space for the T or T' 1067 bytes that the object will or may occupy. 1068 c. The ROUTE receiver computes the length of the payload, Y, by 1069 subtracting the payload header length from the total length 1070 of the received payload. 1071 d. The ROUTE receiver allocates a Boolean array RECEIVED[0..T- 1072 1] or RECEIVED[0..T'-1], as appropriate, with all entries 1073 initialized to false to track received object symbols. The 1074 ROUTE receiver continuously acquires packet payloads for the 1075 object as long as all of the following conditions are 1076 satisfied: i) there is at least one entry in RECEIVED still 1077 set to false; ii) the object has not yet expired; and iii) 1078 the application has not given up on reception of this object. 1079 More details are provided below. 1080 e. For each received ROUTE packet payload for the object 1081 (including the first payload), the steps to be taken to help 1082 recover the object are as follows: 1083 i. If the packet includes an EXT_TOL or EXT_FTI header, 1084 modify the Boolean array RECEIVED[0..T'-1] to become 1085 RECEIVED[0..T-1]. 1086 ii. Let X be the value of the start_offset field in the ROUTE 1087 packet header and let Y be the length of the payload, Y, 1088 computed by subtracting the LCT header size and the FEC 1089 Payload ID size from the total length of the received 1090 packet. 1091 iii. The ROUTE receiver copies the data into the appropriate 1092 place within the space reserved for the object and sets 1093 RECEIVED[X ... X+Y-1] = true. 1094 iv. If all T entries of RECEIVED are true, then the receiver 1095 has recovered the entire object. 1097 Upon recovery of both the complete set of packet payloads for the 1098 delivery object associated with a given TOI value, and the metadata 1099 for that delivery object, the reception of the delivery object, now a 1100 fully received application object, is complete. 1102 The receiver SHALL ensure making availability of application objects 1103 in a timely fashion to the application, based on the application 1104 provided timing data e.g. via presentation manifest file. For 1105 example, HTTP/1.1 chunked transfer may need to be enabled to transfer 1106 the application objects if MPD@availabilityTimeOffset is signaled in 1107 the DASH presentation manifest, to allow for timely sending of 1108 segment data to the application. 1110 6.2. Fast Stream Acquisition 1112 When the receiver initially starts reception of ROUTE packets, it is 1113 likely that the reception does not start from the very first packet 1114 carrying the data of a multicast transport object, and in this case 1115 such a partially received object is normally discarded. However, the 1116 channel acquisition or "tune-in" times can be improved if the 1117 partially received object is usable by the application. 1118 One example realization for this is as follows: 1120 - The receiver checks for the first received packet with the least 1121 significant bit of the PSI set to 1, indicating the start of a 1122 CMAF Random Access chunk. 1123 - The receiver MAY make the partially received object (a partial 1124 DASH segment starting from the packet above) available to the 1125 application. 1126 - It MAY recover the earliest presentation time of this CMAF Random 1127 Access chunk from the ROUTE packet LCT Congestion Control 1128 Information field as specified in Section 2.1 and add a new Period 1129 element in the MPD exposed to the application containing just the 1130 partially received DASH segment with period continuity signaling. 1132 6.3. Generating Extended FDT Instance for File Mode 1134 An Extended FDT Instance conforming to RFC 6726 [RFC6726], is 1135 produced at the receiver using the service metadata and in band 1136 signaling as follows: 1138 6.3.1. File Template Substitution for Content-Location Derivation 1140 The Content-Location of an application object is derived as follows: 1141 "$TOI$" SHALL be substituted with the unique TOI value in the LCT 1142 header of the ROUTE packets used to recover the given delivery object 1143 (as specified in Section 6.1). 1145 After the substitution, the fileTemplate SHALL be a valid URL 1146 corresponding to the Content-Location attribute of the associated 1147 application object. 1149 An example @fileTemplate using a width of 5 is: 1150 fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with 1151 exactly five digits in the number portion. The Media Segment file 1152 name for TOI=33 using this template is myVideo00033.mps. 1154 6.3.2. File@Transfer-Length Derivation 1156 Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL 1157 header, when present, SHALL be used to derive the Transport Object 1158 Length (TOL) of the File. If the File@Transfer-Length parameter in 1159 the Extended FDT Instance is not present, then the EXT_TOL header or 1160 the or EXT_FTI header SHALL be present. Note that a header containing 1161 the transport object length (EXT_TOL or EXT_FTI) need not be present 1162 in each packet header. If the broadcaster does not know the length of 1163 the transport object at the beginning of the transfer, an EXT_TOL or 1164 EXT_FTI header SHALL be included in at least the last packet of the 1165 file and should be included in the last few packets of the transfer. 1167 6.3.3. FDT-Instance@Expires Derivation 1169 When present, the maxExpiresDelta attribute SHALL be used to generate 1170 the value of the FDT-Instance@Expires attribute. The receiver is 1171 expected to add this value to its wall clock time when acquiring the 1172 first ROUTE packet carrying the data of a given delivery object to 1173 obtain the value for @Expires. 1175 When maxExpiresDelta is not present, the EXT_TIME header with 1176 Expected Residual Time (ERT) SHALL be used to derive the expiry time 1177 of the Extended FDT Instance. When both maxExpiresDelta and the ERT 1178 of EXT_TIME are present, the smaller of the two values should be used 1179 as the incremental time interval to be added to the receiver's 1180 current time to generate the effective value for @Expires. When 1181 neither maxExpiresDelta nor the ERT field of the EXT_TIME header is 1182 present, then the expiration time of the Extended FDT Instance is 1183 given by its @Expires attribute. 1185 7. FEC Application 1187 7.1. General FEC Application Guidelines 1189 It is up to the receiver to decide to use zero, one or more of the 1190 FEC streams. Hence, each flow is typically assigned an individual 1191 recovery property, which defines aspects such as the delay and the 1192 required memory if one or the other is chosen. The receiver MAY 1193 decide whether or not to utilize Repair Flows based on the following 1194 considerations: 1195 - The desired start-up and end-to-end latency. If a Repair Flow 1196 requires a significant amount of buffering time to be effective, 1197 such Repair Flow might only be used in time-shift operations or in 1198 poor reception conditions, since use of such Repair Flow trades 1199 off end-to-end latency against DASH Media Presentation quality. 1201 - FEC capabilities, i.e. the receiver MAY pick only the FEC 1202 algorithm that it supports. 1203 - Which Source Flows are being protected; for example, if the Repair 1204 Flow protects Source Flows that are not selected by the receiver, 1205 then the receiver may not select the Repair Flow. 1206 - Other considerations such as available buffer size, reception 1207 conditions, etc. 1209 If a receiver decides to acquire a certain Repair Flow then the 1210 receiver must receive data on all Source Flows that are protected by 1211 that Repair Flow to collect the relevant packets. 1213 7.2. TOI Mapping 1215 When mappingTOIx/mappingTOIy are used to signal X and Y values, then 1216 the TOI value(s) of the one or more source objects (sourceTOI) 1217 protected by a given FEC transport object or FEC super-object with a 1218 TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y. 1220 When neither mappingTOIx nor mappingTOIy is present there is a 1:1 1221 relationship between each delivery object carried in the Source Flow 1222 as identified by ptsi to an FEC object carried in this Repair Flow. 1223 In this case the TOI of each of those delivery objects SHALL be 1224 identical to the TOI of the corresponding FEC object. 1226 7.3. Delivery Object Reception Timeout 1228 The permitted start and end times for the receiver to perform the 1229 file repair procedure, in case of unsuccessful broadcast file 1230 reception, and associated rules and parameters are as follows: 1232 - The latest time that the file repair procedure may start is bound 1233 by the @Expires attribute of the FDT-Instance. 1234 - The receiver may choose to start the file repair procedure 1235 earlier, if it detects the occurrence of any of the following 1236 events: 1237 o Presence of the Close Object flag (B) in the LCT header 1238 [RFC5651] for the file of interest; 1239 o Presence of the Close Session flag (A) in the LCT header 1240 [RFC5651] before the nominal expiration of the Extended FDT 1241 Instance as defined by the @Expires attribute. 1243 7.4. Example FEC Operation 1245 To be able to recover the delivery objects that are protected by a 1246 Repair Flow, a receiver needs to obtain the necessary Service 1247 signaling metadata fragments that describe the corresponding 1248 collection of delivery objects that are covered by this Repair Flow. 1249 A Repair Flow is characterized by the combination of an LCT channel, 1250 a unique TSI number, as well as the corresponding protected Source 1251 Flows. 1252 If a receiver acquires data of a Repair Flow, the receiver is 1253 expected to collect all packets of all protected Transport Sessions. 1254 Upon receipt of each packet, whether it is a source or repair packet, 1255 the receiver proceeds with the following steps in the order listed. 1256 1) The receiver is expected to parse the packet header and verify 1257 that it is a valid header. If it is not valid, then the packet SHALL 1258 be discarded without further processing. 1259 2) The receiver is expected to parse the TSI field of the packet 1260 header and verify that a matching value exists in the Service 1261 signaling for the Repair Flow or the associated Protected Source 1262 Flow. If no match is found, the packet SHALL be discarded without 1263 further processing. 1264 3) The receiver processes the remainder of the packet, including 1265 interpretation of the other header fields, and using the source FEC 1266 Payload ID (to determine the start_offset byte position within the 1267 source object), the Repair FEC Payload ID, as well as the payload 1268 data, reconstructs the decoding blocks corresponding to a FEC super- 1269 object as follows: 1270 a) For a source packet, the receiver identifies the delivery object 1271 to which the received packet is associated, using the session 1272 information and the TOI carried in the payload header. Similarly, for 1273 a repair object the receiver identifies the FEC super-object to which 1274 the received packet is associated, using the session information and 1275 the TOI carried in the payload header. 1276 b) For source packets, the receiver collects the data for each FEC 1277 super-object and recovers FEC super-objects in same way as Source 1278 Flow in Section 6.1. The received FEC super-object is then mapped to 1279 a source block and the corresponding encoding symbols are generated. 1280 c) With the reception of the repair packets, the FEC super-object can 1281 be recovered. 1282 d) Once the FEC super-object is recovered, the individual delivery 1283 objects can be extracted. 1285 8. Considerations for Defining ROUTE Profiles 1287 Applications may define specific ROUTE profiles based on this RFC 1288 with the following considerations. Applications MAY 1290 . Restrict the signaling certain values signaled in the LCT 1291 header and/or provision unused fields in the LCT header. 1292 . Restrict using certain LCT header extensions and/or add new LCT 1293 header extensions. 1295 . Restrict or limit certain Codepoints, and/or add of application 1296 specific Codepoints marked as reserved in this RFC. 1297 . Restrict usage of certain service signaling attributes and/or 1298 add own service metadata. 1300 Applications SHALL NOT redefine the semantics of any of the ROUTE 1301 attributes in LCT headers and extension, and service signaling 1302 attributes already specified in this RFC. 1304 Following these guidelines, profiles MAY be defined that are 1305 interoperable. 1307 9. ROUTE Concepts 1309 ROUTE is aligned with FLUTE as defined in RFC 6726 [RFC6726] as well 1310 as the extensions defined in MBMS [MBMS], but also makes use of some 1311 principles of FCAST as defined in RFC 6968 [RFC6968]; for example, 1312 object metadata and the object content may be sent together in a 1313 compound object. 1315 In addition to the basic FLUTE protocol, certain optimizations and 1316 restrictions are added that enable optimized support for real-time 1317 delivery of media data; hence, the name of the protocol. Among 1318 others, the source ROUTE protocol enables or enhances the following 1319 functionalities: 1321 - Real-time delivery of object-based media data 1322 - Flexible packetization, including enabling media-aware 1323 packetization as well as transport-aware packetization of delivery 1324 objects 1325 - Independence of application objects and delivery objects, i.e. a 1326 delivery object may be a part of a file or may be a group of files. 1328 9.1. ROUTE Modes of Delivery 1330 Different ROUTE delivery modes specified in Section 4 are optimized 1331 for delivery of different types of media data. For example, File Mode 1332 is specifically optimized for delivering DASH content using Segment 1333 Template with number substitution. Using File Template in EFDT avoids 1334 the need of repeated sending of metadata as outlined in the following 1335 section. Same optimizations however cannot be used for time 1336 substitution and segment timeline where the addressing of each 1337 segment is time dependent and in general does not follow a fixed or 1338 repeated pattern. In this case, Entity mode is more optimized which 1339 carries the file location in band. Also, Entity mode can be used to 1340 deliver a file or part of the file using HTTP Partial Content 1341 response headers. 1343 9.2. File Mode Optimizations 1345 In the file mode, the delivery object represents an application 1346 object. This mode replicates FLUTE as defined in RFC 6726 [RFC6726], 1347 but with the ability to send static and pre-known file metadata out 1348 of band. 1349 In FLUTE, FDT Instances are delivered in-band and need to be 1350 generated and delivered in real-time if objects are generated in 1351 real-time at the sender. In contrast to the FDT in RFC 6726 1352 [RFC6726], Section 3.4.2 and MBMS [MBMS], Section 7.2.10, besides 1353 separated delivery of file metadata from the delivery object it 1354 describes, the FDT functionality in ROUTE may be extended by 1355 additional file metadata and rules that enable the receiver to 1356 generate the Content-Location attribute of the File element of the 1357 FDT, on-the-fly, by using information in both the extensions to the 1358 FDT and the LCT header. The combination of pre-delivery of static 1359 file metadata and receiver self-generation of dynamic file metadata 1360 avoids the necessity of continuously sending the FDT Instances for 1361 real-time objects. Such modified FDT functionality in ROUTE is 1362 referred to as the Extended FDT. 1364 9.3. In band Signaling of Object Transfer Length 1366 As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header 1367 extension with 24 bits or, if required, 48 bits of to signal the 1368 Transfer Length directly within the ROUTE packet. 1370 The transport object length can also be determined without the use of 1371 EXT_TOL by examining the LCT packet with the Close Object (B) flag. 1372 However, if this packet is lost, then the EXT_TOL information can be 1373 used by the receiver to determine the transport object length. 1375 Applications using ROUTE for delivery of low-latency streaming 1376 content may make use of this feature for sender-end latency 1377 optimizations: the sender does not have to wait for the completion of 1378 the packaging of a whole application object to find its transfer 1379 length to be included in the FDT before the sending can start. 1380 Rather, partially encoded data can already be started to be sent via 1381 the ROUTE sender. As the time approaches when the encoding of the 1382 application object is nearing completion, and the length of the 1383 object becomes known (e.g. time of writing the last CMAF Chunk of a 1384 DASH segment), only then the sender can signal the object length 1385 using the EXT TOL LCT header. For example, for a 2 seconds DASH 1386 segment with 100 millisecond chunks, it may result in saving up to 1387 1.9 second latency at the sending end. 1389 9.4. Repair Protocol Concepts 1391 The ROUTE repair protocol is FEC-based and is enabled as an 1392 additional layer between the transport layer (e.g., UDP) and the 1393 object delivery layer protocol. The FEC reuses concepts of FEC 1394 Framework defined in RFC 6363 [RFC6363], but in contrast to the FEC 1395 Framework in RFC 6363 [RFC6363] the ROUTE repair protocol does not 1396 protect packets, but instead it protects delivery objects as 1397 delivered in the source protocol. In addition, as an extension to 1398 FLUTE, it supports the protection of multiple objects in one source 1399 block which is in alignment with the FEC Framework as defined in RFC 1400 6363 [RFC6363]. Each FEC source block may consist of parts of a 1401 delivery object, as a single delivery object (similar to FLUTE) or 1402 multiple delivery objects that are bundled prior to FEC protection. 1403 ROUTE FEC makes use of FEC schemes in a similar way as those defined 1404 in RFC 5052 [RFC5052] and uses the terminology of that document. The 1405 FEC scheme defines the FEC encoding and decoding, as well as the 1406 protocol fields and procedures used to identify packet payload data 1407 in the context of the FEC scheme. 1408 In ROUTE all packets are LCT packets as defined in RFC 5651 1409 [RFC5651]. Source and repair packets may be distinguished by: 1410 - Different ROUTE sessions; i.e., they are carried on different 1411 IP/UDP port combinations. 1412 - Different LCT channels; i.e., they use different TSI values in the 1413 LCT header. 1414 - The PSI bit in the LCT, if carried in the same LCT channel. This 1415 mode of operation is mostly suitable for FLUTE-compatible 1416 deployments. 1418 10. Interoperability Chart 1420 The following table is an informative comparison of the 1421 interoperability of ROUTE as specified in this RFC, with the ROUTE 1422 specification in ATSC A/331 [ATSCA331] and DVB Adaptive media 1423 streaming over IP multicast [DVBMABR]: 1425 +---------------+---------------+--------------------+-----------------+ 1426 | Element | ATSC A/331 | IETF RFC | DVB ROUTE | 1427 | | | | Profile | 1428 +--------+------+---------------+--------------------+-----------------+ 1429 | LCT | PSI | Set to 0 | Set to 1 for source flow for CMAF | 1430 | header | 2nd | for source | Random access chunk | 1431 | fields | bit | flow, though | | 1432 | | | not used by | | 1433 | | | receiver. | | 1434 | +------+---------------+--------------------------------------+ 1435 | | CCI | May be set | May be set to EPT for source flow | 1436 | | | to 0 | | 1437 +--------+------+---------------+--------------------+-----------------+ 1438 | LCT header | EXT_ROUTE_ | Not defined, | Shall not | 1439 | extensions | PRESENTATION_ | may be added | be used | 1440 | | TIME Header | by a profile. | | 1441 | | used for | | | 1442 | | MDE mode | | | 1443 | +---------------+--------------------+-----------------+ 1444 | | EXT_TIME | EXT_TIME Header may be used | 1445 | | Header | regardless (for | 1446 | | linked to | FDT-Instance@Expires | 1447 | | MDE mode | calculation) | 1448 | | in Annex | | 1449 | | A.3.7.2 | | 1450 +---------------+---------------+--------------------+-----------------+ 1451 | Codepoints | Full set | Does not specify | Restricted | 1452 | | | range 10 - 255 | to 5 - 9 | 1453 | | | (leaves to | | 1454 | | | profiles) | | 1455 +---------------+---------------+--------------------+-----------------+ 1456 | Session | Full set | Only defines | Reuses A/331 | 1457 | metadata | | a small subset | metadata, | 1458 | | | of data necessary | duplicated | 1459 | | | for setting up | from its own | 1460 | | | Source and Repair | service | 1461 | | | Flows. | signaling. | 1462 | | | Does not define | | 1463 | | | format or | | 1464 | | | encoding of data | | 1465 | | | except if data is | | 1466 | | | integral/ | | 1467 | | | alphanumerical. | | 1468 | | | Leaves rest to | | 1469 | | | profiles. | | 1470 +---------------+---------------+--------------------+-----------------+ 1471 | Extended | Instance | Not restricted, | Instance shall | 1472 | FDT | shall not | may be | not be sent | 1473 | | be sent | restricted | with source | 1474 | | with source | by a profile. | flow | 1475 | | flow | | | 1476 | +---------------+--------------------+-----------------+ 1477 | | No | Only allowed in File Mode | 1478 | | restriction | | 1479 +---------------+---------------+--------------------+-----------------+ 1480 | Delivery | File, Entity, Signed/ | Signed/ | 1481 | Object | unsigned package | unsigned | 1482 | Mode | | package not | 1483 | | | allowed | 1484 +---------------+---------------+--------------------+-----------------+ 1485 | Sender | Defined for | Defined for DASH segment and CMAF | 1486 | operation: | DASH | Chunks | 1487 | Packet- | segment | | 1488 | ization | | | 1489 +---------------+---------------+--------------------------------------+ 1490 | Receiver | Object | Object may be handed before | 1491 | object | handed | completion if | 1492 | recovery | to | MPD@availabilityTimeOffset | 1493 | | application | signaled | 1494 | | upon | | 1495 | | complete | | 1496 | | reception | | 1497 | +---------------+--------------------------------------+ 1498 | | - | Fast Stream acquisition | 1499 | | | guideline provided | 1500 +---------------+---------------+--------------------------------------+ 1502 11. Security Considerations 1504 Refer to ALC as defined in RFC 5775 [RFC5775]. 1506 12. IANA Considerations 1508 None. 1510 13. References 1512 13.1. Normative References 1514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1515 Requirement Levels", BCP 14, RFC 2119, March 1997. 1516 http://tools.ietf.org/html/rfc2119 1518 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1519 Transport (LCT) Building Block", RFC 5651, October 2009. 1520 http://tools.ietf.org/html/rfc5651 1522 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1523 Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010. 1524 http://tools.ietf.org/html/rfc5775 1526 [RFC6726] Paila, T., Luby, M., Lehtonen, R., Roca, V., Walsh, R., 1527 "FLUTE-File Delivery over Unidirectional Transport." 2012. 1528 http://tools.ietf.org/html/rfc6726 1530 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and 1531 Minder, L. "RaptorQ forward error correction scheme for object 1532 delivery", 2011. 1533 http://tools.ietf.org/html/rfc6330 1535 [RFC3986] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform 1536 Resource Identifier (URI): Generic Syntax", January 2005. 1537 http://tools.ietf.org/html/rfc3986 1539 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3," 1540 Internet Engineering Task Force, Reston, VA, May, 1996. 1541 http://tools.ietf.org/html/rfc1952 1543 [RFC2557] Palme, J., Hopmann, A. and Shelness, N., "MIME 1544 Encapsulation of Aggregate Documents, such as HTML (MHTML)", Internet 1545 Engineering Task Force, Reston, VA, March 1999. 1546 http://tools.ietf.org/html/rfc2557 1548 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, 1549 "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 1550 Message Specification," Internet Engineering Task Force, Fremont, CA, 1551 January 2010. 1552 https://tools.ietf.org/html/rfc8551 1554 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes," 1555 Internet Engineering Task Force, Reston, VA, March, 2009. 1556 http://tools.ietf.org/html/rfc5445 1558 [RFC5052] Watson, M., Luby, M., and Vicisano, L., "Forward Error 1559 Correction (FEC) Building Block," Internet Engineering Task Force, 1560 Reston, VA, August 2007. http://tools.ietf.org/html/rfc5052 1562 [RFC6363] Watson, M., Begen, A. and Roca, V., "Forward Error 1563 Correction (FEC) Framework," Internet Engineering Task Force, Reston, 1564 VA, October, 2011. http://tools.ietf.org/html/rfc6363 1566 13.2. Informative References 1568 [RFC7231] IETF RFC 7231 "Hypertext Transfer Protocol (HTTP/1.1): 1569 Semantics and Content", June 2014. 1570 http://tools.ietf.org/html/rfc7231 1572 [RFC6968] Roca, V. and Adamson, B., "FCAST: Object Delivery for the 1573 Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable 1574 Multicast (NORM) Protocols," Internet Engineering Task Force, Reston, 1575 VA, July, 2013. http://tools.ietf.org/html/rfc6968 1577 [ATSCA331] ATSC A/331:2019: "ATSC Standard: Signaling, Delivery, 1578 Synchronization, and Error Protection", 20 June 2019. 1580 [DVBMABR] DVB Document A176 (Second edition), "Adaptive media 1581 streaming over IP multicast", March 2020. 1583 [DASH] ISO/IEC 23009-1:2019: "Information technology - Dynamic 1584 adaptive streaming over HTTP (DASH) - Part 1: Media presentation 1585 description and segment formats", Fourth edition, December 2019. 1587 [CMAF] ISO/IEC 23000-19:2018: "Information technology - Multimedia 1588 application format (MPEG-A) - Part 19: Common media application 1589 format (CMAF) for segmented media", First edition, January 2018. 1591 [MBMS] ETSI: "Universal Mobile Telecommunications Systems (UMTS); 1592 LTE; Multimedia Broadcast/Multicast Service (MBMS); Protocols and 1593 codecs (3GPP TS 26.346 version 13.3.0 Release 13)," Doc. ETSI TS 126 1594 346 v13.3.0 (2016-01), European Telecommunications Standards 1595 Institute, January 2016. 1597 14. Acknowledgments 1599 As outlined in the introduction and in ROUTE concepts, the concepts 1600 specified in this draft are the culmination of the collaborative work 1601 of several experts and organizations over the years. The authors 1602 would especially like to acknowledge the work and efforts of the 1603 following people and organizations to help realize the technologies 1604 described in this draft (in no specific order): Mike Luby, Kent 1605 Walker, Charles Lo, Giridhar Mandyam, and other colleagues from 1606 Qualcomm Incorporated, LG Electronics, Nomor Research, Sony, and BBC 1607 R&D. 1609 Authors' Addresses 1611 Waqar Zia 1612 Qualcomm CDMA Technologies GmbH 1613 Anzinger Str. 13, 81671, Munich, Germany 1614 Email: wzia@qti.qualcomm.com 1616 Thomas Stockhammer 1617 Qualcomm CDMA Technologies GmbH 1618 Anzinger Str. 13, 81671, Munich, Germany 1619 Email: tsto@qti.qualcomm.com