idnits 2.17.1 draft-zia-route-06.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 -- The document date (February 4, 2022) is 812 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Lenaig Chaponniere, 4 Giridhar Mandyam, 5 Qualcomm Incorporated 6 Michael Luby, 7 Intended status: Informational BitRipple, Inc. 8 Expires: August 2022 February 4, 2022 10 Real-time Transport Object delivery over Unidirectional Transport 11 (ROUTE) 12 draft-zia-route-06.txt 14 Abstract 16 The Real-time Transport Object delivery over Unidirectional Transport 17 protocol (ROUTE protocol) is specified for robust delivery of 18 Application Objects, including Application Objects with real-time 19 delivery constraints, to receivers over a unidirectional transport. 20 Application Objects consist of data that has meaning to applications 21 that use the ROUTE protocol for delivery of data to receivers, for 22 example, it can be a file, or a DASH or HLS segment, a WAV audio 23 clip, etc. The ROUTE protocol also supports low-latency streaming 24 applications. 26 The ROUTE protocol is suitable for unicast, broadcast, and multicast 27 transport. Therefore, it can be run over UDP/IP including multicast 28 IP. The ROUTE protocol can leverage the features of the underlying 29 protocol layer, e.g. to provide security it can leverage IP security 30 protocols such as IPSec. 32 This document specifies the ROUTE protocol such that it could be used 33 by a variety of services for delivery of Application Objects by 34 specifying their own profiles of this protocol (e.g. by adding or 35 constraining some features). 37 This is not an IETF specification and does not have IETF consensus. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 This document may contain material from IETF Documents or IETF 45 Contributions published or made publicly available before November 46 10, 2008. The person(s) controlling the copyright in some of this 47 material may not have granted the IETF Trust the right to allow 48 modifications of such material outside the IETF Standards Process. 50 Without obtaining an adequate license from the person(s) controlling 51 the copyright in such materials, this document may not be modified 52 outside the IETF Standards Process, and derivative works of it may 53 not be created outside the IETF Standards Process, except to format 54 it for publication as an RFC or to translate it into languages other 55 than English. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF), its areas, and its working groups. Note that 59 other groups may also distribute working documents as Internet- 60 Drafts. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 The list of current Internet-Drafts can be accessed at 68 http://www.ietf.org/ietf/1id-abstracts.txt 70 The list of Internet-Draft Shadow Directories can be accessed at 71 http://www.ietf.org/shadow.html 73 This Internet-Draft will expire on August 4, 2022. 75 Copyright Notice 77 Copyright (c) 2022 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. Code Components extracted from this document must 86 include Simplified BSD License text as described in Section 4.e of 87 the Trust Legal Provisions and are provided without warranty as 88 described in the Simplified BSD License. 90 Table of Contents 92 1. Introduction...................................................4 93 1.1. Overview..................................................4 94 1.2. Protocol Stack for ROUTE..................................6 95 1.3. Data Model................................................6 96 1.4. Architecture and Scope of Specification...................7 97 1.5. Intellectual Property.....................................9 98 1.6. Conventions used in this document.........................9 99 2. ROUTE Packet Format............................................9 100 2.1. Packet Structure and Header Fields........................9 101 2.2. LCT Header Extensions....................................11 102 2.3. FEC Payload ID for Source Flows..........................11 103 2.4. FEC Payload ID for Repair Flows..........................12 104 3. Session Metadata..............................................12 105 3.1. Generic Metadata.........................................12 106 3.2. Session Metadata for Source Flows........................13 107 3.3. Session metadata for Repair Flows........................14 108 4. Delivery Object Mode..........................................15 109 4.1. File Mode................................................15 110 4.1.1. Extensions to FDT...................................15 111 4.1.2. Constraints on Extended FDT.........................16 112 4.2. Entity Mode..............................................16 113 4.3. Unsigned Package Mode....................................17 114 4.4. Signed Package Mode......................................18 115 5. Sender Operation..............................................18 116 5.1. Usage of ALC and LCT for Source Flow.....................18 117 5.2. ROUTE Packetization for Source Flow......................19 118 5.2.1. Basic ROUTE Packetization...........................20 119 5.2.2. ROUTE Packetization for CMAF Chunked Content........20 120 5.3. Timing of Packet Emission................................21 121 5.4. Extended FDT Encoding for File Mode Sending..............21 122 5.5. FEC Framework Considerations.............................21 123 5.6. FEC Transport Object Construction........................22 124 5.7. Super-Object Construction................................24 125 5.8. Repair Packet Considerations.............................24 126 5.9. Summary FEC Information..................................25 127 6. Receiver operation............................................26 128 6.1. Basic Application Object Recovery for Source Flows.......26 129 6.2. Fast Stream Acquisition..................................28 130 6.3. Generating Extended FDT Instance for File Mode...........28 131 6.3.1. File Template Substitution for Content-Location 132 Derivation.................................................28 133 6.3.2. File@Transfer-Length Derivation.....................29 134 6.3.3. FDT-Instance@Expires Derivation.....................29 135 7. FEC Application...............................................30 136 7.1. General FEC Application Guidelines.......................30 137 7.2. TOI Mapping..............................................30 138 7.3. Delivery Object Reception Timeout........................31 139 7.4. Example FEC Operation....................................31 140 8. Considerations for Defining ROUTE Profiles....................32 141 9. ROUTE Concepts................................................33 142 9.1. ROUTE Modes of Delivery..................................33 143 9.2. File Mode Optimizations..................................33 144 9.3. In Band Signaling of Object Transfer Length..............33 145 9.4. Repair Protocol Concepts.................................34 146 10. Interoperability Chart.......................................35 147 11. Security and Privacy Considerations..........................37 148 11.1. Security Considerations.................................37 149 11.2. Privacy Considerations..................................38 150 12. IANA Considerations..........................................38 151 13. References...................................................39 152 13.1. Normative References....................................39 153 13.2. Informative References..................................40 154 14. Acknowledgments..............................................41 156 1. Introduction 158 1.1. Overview 160 The Real-time Transport Object delivery over Unidirectional Transport 161 protocol (ROUTE protocol) can be used for robust delivery of 162 Application Objects, including Application Objects with real-time 163 delivery constraints, to receivers over a unidirectional transport. 164 Unidirectional transport in this document has identical meaning as in 165 RFC 6726 [RFC6726], i.e., transport in the direction of receiver(s) 166 from a sender. The robustness is enabled by a built-in mechanism e.g. 167 signaling for loss detection, enabling loss recovery, and optionally 168 integrating application-layer Forward Error Correction (FEC). 170 Application Objects consist of data that has meaning to applications 171 that use the ROUTE protocol for delivery of data to receivers, e.g., 172 an Application Object can be a file, or an MPEG Dynamic Adaptive 173 Streaming over HTTP (DASH)[DASH] video segment, a WAV audio clip, an 174 MPEG Common Media Application Format (CMAF) [CMAF] addressable 175 resource, an MPEG-4 video clip, etc. 177 The ROUTE protocol is designed to enable delivery of sequences of 178 related Application Objects in a timely manner to receivers, e.g., a 179 sequence of DASH video segments associated to a Representation or a 180 sequence of CMAF addressable resources associated to a CMAF Track. 181 The applications of this protocol target services enabled on media 182 consumption devices such as smartphones, tablets, television sets and 183 so on. Most of these applications are real-time in the sense that 184 they are sensitive to and reply upon such timely reception of data. 185 The ROUTE protocol also supports chunked delivery of real-time 186 Application Objects to enable low latency streaming applications 187 (similar in its properties to chunked delivery using HTTP). The 188 protocol also enables low-latency delivery of DASH and Apple HTTP 189 Live Streaming (HLS) content with CMAF Chunks. 191 Content not intended for rendering in real time as it is received 192 e.g. a downloaded application, or a file comprising continuous or 193 discrete media and belonging to an app-based feature, or a file 194 containing (opaque) data to be consumed by a Digital Rights 195 Management (DRM) system client can also delivered by ROUTE. 197 The ROUTE protocol supports a caching model, where Application 198 Objects are recovered into a cache at the receiver and may be made 199 available to applications via standard HTTP requests from the cache. 200 Many current day applications rely on using HTTP to access content, 201 and hence this approach enables such applications in 202 broadcast/multicast environments. 204 ROUTE is aligned with FLUTE as defined in RFC 6726 [RFC6726] as well 205 as the extensions defined in MBMS [MBMS], but also makes use of some 206 principles of FCAST (Object Delivery for the ALC and NACK-Oriented 207 Reliable Multicast Protocols) as defined in RFC 6968 [RFC6968]; for 208 example, object metadata and the object content may be sent together 209 in a compound object. 211 The alignment to FLUTE is enabled since in addition to reusing 212 several of the basic FLUTE protocol features, as referred to by this 213 document, certain optimizations and restrictions are added that 214 enable optimized support for real-time delivery of media data; hence, 215 the name of the protocol. Among others, the source ROUTE protocol 216 enables or enhances the following functionalities: 218 o Real-time delivery of object-based media data 220 o Flexible packetization, including enabling media-aware 221 packetization as well as transport-aware packetization of delivery 222 objects 224 o Independence of Application Objects and delivery objects, i.e. a 225 delivery object may be a part of a file or may be a group of 226 files. 228 Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE 229 protocol integrated with an ATSC 3.0 services layer. That 230 specification will be referred to as ATSC-ROUTE [ATSCA331] for the 231 remainder of this document. DVB has specified a profile of ATSC-ROUTE 232 in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) 233 [DVBMABR]. This document specifies the Application Object delivery 234 aspects (delivery protocol) for such services, as the corresponding 235 delivery protocol could be used as a reference by a variety of 236 services by specifying profiles of ROUTE in their respective fora, 237 e.g. by adding new optional features atop or by restricting various 238 optional features specified in this document in a specific service 239 standard. Hence in the context of this document, the aforementioned 240 ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition 241 of profiles by the services also have to give due consideration to 242 compatibility issues, and some related guidelines are also provided 243 in this document. 245 This document is not an IETF specification and does not have IETF 246 consensus. It is provided here to aid the production of interoperable 247 implementations. 249 1.2. Protocol Stack for ROUTE 251 ROUTE delivers Application Objects such as MPEG DASH or HLS segments 252 and optionally the associated repair data, operating over UDP/IP 253 networks, as depicted in Figure 1. The session metadata signaling to 254 realize ROUTE session as specified in this document MAY be delivered 255 out-of-band or in-band as well. Since ROUTE delivers objects in an 256 application cache at the receiver from where the application can 257 access them using HTTP, an application like DASH may use its 258 standardized unicast streaming mechanisms in conjunction with ROUTE 259 over broadcast/multicast to augment the services. 261 +-----------------------------------+ 262 |Application (DASH and HLS segments,| 263 | CMAF chunks etc.) | 264 +-----------------------------------+ 265 | ROUTE | 266 +-----------------------------------+ 267 | UDP | 268 +-----------------------------------+ 269 | IP | 270 +-----------------------------------+ 272 Figure 1 Protocol Layering 274 1.3. Data Model 276 The ROUTE data model is constituted by the following key concepts. 278 Application Object - data that has meaning to the application that 279 uses the ROUTE protocol for delivery of data to receivers, e.g., an 280 Application Object can be a file, or a DASH video segment, a WAV 281 audio clip, an MPEG-4 video clip, etc. 283 Delivery Object - An object on course of delivery to the application 284 from the ROUTE sender to ROUTE receiver. 286 Transport Object - an object identified by the Transport Object 287 Identifier (TOI)in RFC 5651 [RFC5651]. It MAY be a either a source 288 or a repair object, if it is carried by a Source Flow or a Repair 289 Flow, respectively. 291 Transport Session - An Layered Coding Transport (LCT) channel, as 292 defined by RFC 5651 [RFC5651]. Transport session SHALL be uniquely 293 identified by a unique Transport Session Identifier (TSI) value in 294 the LCT header. The TSI is scoped by the IP address of the sender, 295 and the IP address of the sender together with the TSI uniquely 296 identify the session. Transport sessions are a subset of a ROUTE 297 session. For media delivery, a Transport Session would typically 298 carry a media component, for example a DASH Representation. Within 299 each transport session, one or more objects are carried, typically 300 objects that are related, e.g. DASH Segments associated to one 301 Representation. 303 ROUTE Session - An ensemble or multiplex of one or more Transport 304 Sessions. Each ROUTE Session is associated with an IP address/port 305 combination. ROUTE session typically carries one or more media 306 components of streaming media e.g. Representations associated with a 307 DASH Media Presentation. 309 Source Flow - Transport session carrying source data. Source Flow is 310 independent of the repair Flow, i.e. the Source Flow MAY be used by 311 a ROUTE receiver without the ROUTE Repair Flows. 313 Repair Flow - Transport session carrying repair data for one or more 314 Source Flows. 316 1.4. Architecture and Scope of Specification 318 The scope of the ROUTE protocol is robust and real-time transport of 319 delivery objects using LCT packets. This architecture is depicted in 320 Figure 2. 321 The normative aspects of the ROUTE protocol focus on the following 322 aspects: 324 o The format of the LCT packets that carry the transport objects. 326 o The robust transport of the delivery object using a repair 327 protocol based on Forward Error Correction (FEC). 329 o The definition and possible carriage of object metadata along with 330 the delivery objects. Metadata may be conveyed in LCT packets 331 and/or separate objects. 333 o The ROUTE session, LCT channel and delivery object description 334 provided as service metadata signaling to enable the reception of 335 objects. 337 o The normative aspects (formats, semantics) of the delivery objects 338 conveyed as a content manifest to be delivered along with the 339 objects to optimize the performance for specific applications; 340 e.g., real-time delivery. The objects and manifest are made 341 available to the application through an Application Object cache. 342 The interface of this cache to the application is not specified in 343 this document, however it will typically be enabled by the 344 application acting as an HTTP Client and the cache as the HTTP 345 server. 347 Application Objects 348 Application to application 349 Objects from ^ 350 an application +--------------------------------------------+ 351 + | ROUTE Receiver | | 352 | | +------+------+ | 353 | | | Application | | 354 | | | Object Cache| | 355 | | +------+------+ | 356 | LCT over| +---------------+ ^ | 357 v UDP/IP | | Source object | +---------+ | | 358 +----+---+ | +->+ recovery +--+ Repair +-+ | 359 | ROUTE | | | +---------------+ +----+----+ | 360 | Sender +----------+ ^ | 361 +----+---+ | | | | 362 | | | +---------------+ | | 363 | | | | Repair object | | | 364 | | +->+ recovery +-------+ | 365 +----------->+ +---------------+ | 366 ROUTE | | 367 Metadata +--------------------------------------------+ 369 Figure 2 Architecture/functional block diagram 371 1.5. Intellectual Property 373 The protocol described in this document may be subject to 374 intellectual property rights disclosed to the IETF in accordance with 375 BCP 78 and recorded in the datatracker entry for this document. 377 1.6. Conventions used in this document 379 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 380 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 381 "OPTIONAL" in this document are to be interpreted as described in BCP 382 14 [RFC2119] [RFC8174] when, and only when, they appear in all 383 capitals, as shown here. 385 2. ROUTE Packet Format 387 2.1. Packet Structure and Header Fields 389 The packet format used by ROUTE Source Flows and Repair Flows follows 390 the ALC packet format specified in RFC 5775 [RFC5775], with the UDP 391 header followed by the default LCT header and the source FEC Payload 392 ID followed by the packet payload. The overall ROUTE packet format is 393 as depicted in Figure 3 below. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | UDP Header | 399 | | 400 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 401 | Default LCT header | 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | FEC Payload ID | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Payload Data | 407 | ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 3 Overall ROUTE packet format 411 The Default LCT header is as defined in the LCT building block in RFC 412 5651 [RFC5651]. 414 The LCT packet header fields SHALL be used as defined by the LCT 415 building block in RFC 5651 [RFC5651]. The semantics and usage of the 416 following LCT header fields SHALL be further constrained in ROUTE as 417 follows: 419 Version number (V) - This 4-bit field indicates the protocol version 420 number. The version number SHALL be set to '0001', as specified in 421 RFC 5651 [RFC5651]. 423 Congestion Control flag (C) field - This 2-bit field, as defined in 424 RFC 5651 [RFC5651], SHALL be set to '00'. 426 Protocol-Specific Indication (PSI) - The most significant bit of this 427 two bit flag is called the Source Packet Indicator (SPI) and 428 indicates whether the current packet is a source packet or an FEC 429 repair packet. The SPI SHALL be set to '1' to indicate a source 430 packet, and SHALL bet set to '0' to indicate a repair packet. 432 Transport Session Identifier flag (S) - This 1-bit field SHALL be set 433 to '1' to indicate a 32-bit word in the TSI field. 435 Transport Object Identifier flag (O) - This 2-bit field SHALL be set 436 to '01' to indicate the number of full 32-bit words in the TOI field. 438 Half-word flag (H) - This 1-bit field SHALL be set to '0' to indicate 439 that no half-word field sizes are used. 441 Codepoint (CP) - This 8-bit field is used to indicate the type of the 442 payload that is carried by this packet, and for ROUTE, is defined as 443 shown below to indicate the type of delivery object carried in the 444 payload of the associated ROUTE packet. The remaining, unmapped 445 Codepoint values can be used by a service using ROUTE. In this case, 446 the Codepoint values SHALL follow the semantics specified in the 447 following table. "IS" stands for Initialization Segment of the media 448 content such as the DASH Initialization Segment [DASH]. The various 449 modes of operation in the table (File/Entity/Package Mode) are 450 specified in Section 4. The table also lists a Codepoint value range 451 that is reserved for future service-specific uses. 453 Codepoint value | Semantics 454 ---------------------------------------------------- 455 0 | Reserved (not used) 456 1 | Non Real Time (NRT) - File Mode 457 2 | NRT - Entity Mode 458 3 | NRT - Unsigned Package Mode 459 4 | NRT - Signed Package Mode 460 5 | New IS, timeline changed 461 6 | New IS, timeline continued 462 7 | Redundant IS 463 8 | Media Segment, File Mode 464 9 | Media Segment, Entity Mode 465 10 | Media Segment, File Mode with CMAF Random 466 | Access Chunk 467 11 - 255 | Reserved, service-specific 469 Congestion Control Information (CCI) - For packets carrying DASH 470 segments, MAY convey the 32-bit earliest presentation time [DASH] of 471 the DASH segment contained in the ROUTE packet. In this case, this 472 information can be used by a ROUTE receiver for fast stream 473 acquisition (details in Section 6.2). Otherwise this field SHALL be 474 set to 0. 476 Transport Session Identifier (TSI) - This 32-bit field identifies the 477 Transport Session in ROUTE. The context of the Transport Session is 478 provided by signaling metadata. The value TSI = 0 SHALL only be used 479 for service-specific signaling. 481 Transport Object Identifier (TOI) - This 32-bit field SHALL identify 482 the object within this session to which the payload of the current 483 packet belongs. The mapping of the TOI field to the object is 484 provided by the Extended File Delivery Table (FDT). 486 2.2. LCT Header Extensions 488 The following LCT header extensions are defined or used by ROUTE: 490 EXT_FTI - as specified in RFC 5775. 492 EXT_TOL - The length in bytes of the multicast transport object shall 493 be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331] with 494 24 bits or, if required, 48 bits of Transfer Length. The frequency of 495 using the EXT_TOL header extension is determined by channel 496 conditions that may cause the loss of the packet carrying Close 497 Object (B) flag [RFC5651]. 499 NOTE: The transport object length can also be determined without the 500 use of EXT_TOL by examining the LCT packet with the Close Object (B) 501 flag. However, if this packet is lost, then the EXT_TOL information 502 can be used by the receiver to determine the transport object length. 504 EXT_TIME Header - as specified in RFC 5651 [RFC5651]. The Sender 505 Current Time SHALL be signaled using EXT_TIME. 507 2.3. FEC Payload ID for Source Flows 509 The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme 510 used in ROUTE Source Flows is a 32-bit unsigned integer value that 511 SHALL express the start_offset, as an octet number corresponding to 512 the first octet of the fragment of the delivery object carried in 513 this packet. The start_offset value for the first fragment of any 514 delivery object SHALL be set to 0. Figure 4 shows the 32-bit 515 start_offset field. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | start_offset | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 4 FEC Payload ID for Source Flows. 524 2.4. FEC Payload ID for Repair Flows 526 FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330]. 528 3. Session Metadata 530 The required session metadata for Source and Repair Flows is 531 specified in the following sections. The list specified here is not 532 exhaustive; a service MAY signal more metadata to meet its needs. The 533 data format is also not specified beyond its cardinality; the exact 534 format of specifying the data is left for the service, e.g. by using 535 XML encoding format, as has been done by [DVBMABR] and [ATSCA331]. 536 It is specified in the following if an attribute is mandatory (m), 537 conditional mandatory (cm) or optional (o) to realize a basic ROUTE 538 session. A mandatory filed SHALL always be present in the session 539 metadata, and a conditional mandatory field SHALL be present if the 540 specified condition is true. The delivery of the session metadata to 541 the ROUTE receiver is beyond scope of this document. 543 3.1. Generic Metadata 545 Generic metadata is applicable to both Source and Repair Flows as 546 follows. Before a receiver can join a ROUTE session, the receiver 547 needs to obtain this generic metadata that contains at least the 548 following information: 550 ROUTE version number (m): The version number of ROUTE used in this 551 session. The version number conforming to this document SHALL be 1. 553 Connection ID (m): unique identifier of a Connection, usually 554 consisting of 4-tuple: source IP address/source port number, 555 destination IP address/destination port number. The IP addresses can 556 be IPv4 or IPv6 addresses, depending upon which IP version is used by 557 the deployment. 559 3.2. Session Metadata for Source Flows 561 stsi (m) - LCT TSI value corresponding to the transport session for 562 the Source Flow. 564 rt (o) - A Boolean flag which SHALL indicate whether the content 565 component carried by this Source Flow corresponds to real-time 566 streaming media, or non-real-time content. When set to "true", it 567 SHALL be an indication of real-time content, and when absent or set 568 to "false", it SHALL be an indication of non-real-time (NRT) content. 570 minBufferSize (o) - A 32-bit unsigned integer which SHALL represent, 571 in kilobytes, the minimum required storage size of the receiver 572 transport buffer, for the parent LCT channel of this Source Flow. The 573 buffer holds the data belonging to a Source Object till its complete 574 reception. This attribute is only applicable when rt = "true". 576 A service which chooses not to signal this attribute relies on 577 receiver implementation, which must discard the received data beyond 578 its buffering capability. Such discarding of data will impact the 579 service quality. 581 EFDT (cm) - when present, SHALL contain a single instance of an FDT- 582 Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain the 583 optional FDT extensions as defined in Section 4.1. The optional EFDT 584 element MAY only be present for File Mode of delivery. In File Mode, 585 it SHALL be present if this Source Flow transports streaming media 586 segments. 588 contentType (o) - A string that SHALL represent the media type for 589 the media content. It SHALL obey the semantics of the Content-Type 590 header as specified by HTTP/1.1 protocol in RFC 7231 [RFC7231]. This 591 document does not define any new contentType strings. In its absence, 592 the signalling of media type for the media content is beyond the 593 scope of this document. 595 applicationMapping (m) - A set of identifiers that provide an 596 application-specific mapping of the received Application Objects to 597 the Source Flows. For example, for DASH, this would provide the 598 mapping a Source Flow to a specific DASH representation from a Media 599 Presentation Description (MPD), the latter identified by its 600 Representation and corresponding Adaptation Set and Period IDs. 602 3.3. Session metadata for Repair Flows 604 minBuffSize (o) - A 32-bit unsigned integer whose value SHALL 605 represent a required size of the receiver transport buffer for AL-FEC 606 decoding processing. When present, this attribute SHALL indicate the 607 minimum buffer size that is required to handle all associated objects 608 that are assigned to a super-object i.e. a delivery object formed by 609 the concatenation of multiple FEC transport objects in order to 610 bundle these FEC transport objects for AL-FEC protection. 612 A service which chooses not to signal this attribute relies on 613 receiver implementation, which must discard the received repair data 614 beyond its buffering capability. Such discarding of data will impact 615 the service quality. 617 fecOTI (m) - A parameter consisting of the concatenation of Common 618 and Scheme-Specific FEC Object Transmission Information (FEC OTI) as 619 defined in Sections 3.3.2 and 3.3.3 of RFC 6330 [RFC6330], and which 620 corresponds to the delivery objects carried in the Source Flow to 621 which this Repair Flow is associated, with the following 622 qualification. The 40-bit Transfer Length (F) field may either 623 represent the actual size of the object, or it is encoded as all 624 zeroes. In the latter case, it means that the FEC transport object 625 size is either unknown, or cannot be represented by this attribute. 626 In other words, for the all-zeroes format, the delivery objects in 627 the Source flow correspond to streaming content - either a live 628 Service whereby content encoding has not yet occurred at the time 629 this session data was generated, or pre-recorded streaming content 630 whose delivery object sizes, albeit known at the time of session data 631 generation, are variable and cannot be represented as a single value 632 by the fecOTI attribute. 634 ptsi (m) - TSI value(s) of each Source Flow protected by this Repair 635 Flow. 637 mappingTOIx (o) - Values of the constant X for use in deriving the 638 TOI of the delivery object of each protected Source Flow from the 639 TOI of the FEC (super-)object. The default value is "1". Multiple 640 mappingTOIx values MAY be provided for each protected Source Flow, 641 depending upon the usage of FEC (super-)object. 643 mappingTOIy (o) - The corresponding constant Y to each mappingTOIx, 644 when present, for use in deriving the parent SourceTOI value from the 645 above equation. The default value is "0". 647 4. Delivery Object Mode 649 ROUTE provides several different delivery object modes, and one of 650 these modes may suite the application needs better for a given 651 transport session. A delivery object is self-contained for the 652 application, typically associated with certain properties, metadata 653 and timing-related information that are of relevance for the 654 application. The signaling of the delivery object mode is done on an 655 object based using Codepoint as specified in Section 2.1. 657 4.1. File Mode 659 File mode uses an out-of-band Extended FDT (EDFT) signaling for 660 recovery of delivery objects with the following extensions and 661 considerations. 663 4.1.1. Extensions to FDT 665 Following extensions are specified to FDT specified in RFC 6726 666 [RFC6726]. An Extended FDT Instance is an instance of FLUTE FDT as 667 specified in [RFC6726], plus optionally one or more of the following 668 extensions. 670 efdtVersion - A value that SHALL represent the version of this 671 Extended FDT Instance. 673 maxExpiresDelta - Let "tp" represent the wall clock time at the 674 receiver when the receiver acquires the first ROUTE packet carrying 675 data of the object described by this Extended FDT Instance. 676 maxExpiresDelta, when present, SHALL represent a time interval which 677 when added to "tp" SHALL represent the expiration time of the 678 associated Extended FDT Instance "te". The time interval is expressed 679 in number of seconds. When maxExpiresDelta is not present, the 680 expiration time of the Extended FDT Instance SHALL be given by the 681 sum of a) the value of the ERT field in the EXT_TIME LCT header 682 extension in the first ROUTE packet carrying data of that file, and 683 b) the current receiver time when parsing the packet header of that 684 ROUTE packet. See Sections 5.4 and 6.3.3 on additional rules for 685 deriving the Extended FDT Instance expiration time. Hence te__= tp + 686 maxExpiresDelta 688 maxTransportSize - An attribute that SHALL represent the maximum 689 transport size in bytes of any delivery object described by this 690 Extended FDT Instance. This attribute SHALL be present if a) the 691 fileTemplate is present in Extended FDT-Instance; or b) one or more 692 File elements, if present in this Extended FDT Instance, do not 693 include the Transfer-Length attribute. When maxTransportSize is not 694 present, the maximum transport size is not signaled, while other 695 signalling such as the Transfer-Length attribute signal the exact 696 transfer length of the object. 698 fileTemplate - A string value, which when present and in conjunction 699 with parameter substitution, is used in deriving the Content-Location 700 attribute, for the delivery object described by this Extended FDT 701 Instance. It SHALL include the "$TOI$" identifier. Each identifier 702 MAY be suffixed as needed by specific file names, within the 703 enclosing '$' characters following this prototype: 704 %0[width]d 705 The width parameter is an unsigned integer that provides the minimum 706 number of characters to be printed. If the value to be printed is 707 shorter than this number, the result SHALL be padded with leading 708 zeroes. The value is not truncated even if the result is larger. When 709 no format tag is present, a default format tag with width=1 SHALL be 710 used. 712 Strings other than identifiers SHALL only contain characters that are 713 permitted within URIs according to RFC 3986 [RFC3986]. 715 $$ Is an escape sequence in fileTemplate value, i.e. "$$" is non- 716 recursively replaced with a single "$" 718 The usage of fileTemplate is described in Sender and Receiver 719 operations in Sections 5.4 and 6.3, respectively. 721 4.1.2. Constraints on Extended FDT 723 The Extended FDT Instance SHALL conform to an FDT Instance according 724 to RFC 6726 [RFC6726], with the following constraints: at least one 725 File element and the @Expires attribute SHALL be present. 727 Content encoding MAY be used for delivery of any file described by an 728 FDT-Instance.File element in the Extended FDT Instance. The content 729 encoding defined in the present document is gzip [RFC1952]. When 730 content encoding is used, the File@Content-Encoding and File@Content- 731 Length attributes SHALL be present in the Extended FDT Instance. 733 4.2. Entity Mode 735 For Entity Mode, the following applies: 737 o Delivery Object metadata SHALL be expressed in the form of entity 738 headers as defined in HTTP/1.1, and which correspond to one or 739 more of the representation header fields, payload header fields 740 and response header fields as defined in Sections 3.1, 3.3 and 7, 741 respectively, of RFC 7231. Additionally, a Digest HTTP response 742 header [RFC7231] MAY be included to enable a receiver to verify 743 the integrity of the multicast transport object. 745 The entity headers sent along with the delivery object provide all 746 information about that multicast transport object. 748 o Sending a media object (if the object is chunked) in Entity Mode 749 may result in one of the following options: 751 o If the length of the chunked object is known at sender, the 752 ROUTE Entity Mode delivery object MAY be sent without using 753 HTTP/1.1 chunked transfer coding, i.e. the object starts with 754 an HTTP header containing the Content Length field, followed 755 by the concatenation of CMAF chunks: 757 |HTTP Header+Length||---chunk ----||---chunk ----||---chunk -- 758 --||---chunk ----| 760 o If the length of the chunked object is unknown at sender when 761 starting to send the object, HTTP/1.1 chunked transfer coding 762 format SHALL be used: 764 |HTTP Header||Separator+Length||---chunk ---- 765 ||Separator+Length||---chunk ----||Separator+Length||---chunk 766 ----||Separator+Length||---chunk ----||Separator+Length=0| 768 Note, however, that it is not required to send a CMAF chunk in 769 exactly one HTTP chunk. 771 4.3. Unsigned Package Mode 773 In this delivery mode, the delivery object consists of a group of 774 files that are packaged for delivery only. If applied, the client is 775 expected to unpack the package and provide each file as an 776 independent object to the application. Packaging is supported by 777 Multipart Multipurpose Internet Mail Extensions (MIME) [RFC2557], 778 where objects are packaged into one document for transport, with 779 Content-Type set to multipart/related. When binary files are 780 included in the package, Content-Transfer-Encoding of "binary" 781 should be used for those files. 783 4.4. Signed Package Mode 785 In Signed Package Mode delivery, the delivery object consists of a 786 group of files that are packaged for delivery, and the package 787 includes one or more signatures for validation. Signed packaging is 788 supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects 789 are packaged into one document for transport and the package includes 790 objects necessary for validation of the package. 792 5. Sender Operation 794 5.1. Usage of ALC and LCT for Source Flow 796 ROUTE Source Flow carry the source data as specified in RFC 5775 797 [RFC5775]. There are several special considerations that ROUTE 798 introduces to the usage of the LCT building block as outlined in the 799 following: 801 o ROUTE limits the usage of the LCT building block to a single 802 channel per session. Congestion control is thus sender-driven in 803 ROUTE. It also signifies that there is no specific congestion 804 control related signalling from sender to the receiver; the CCI 805 field is either set to 0 or used for other purposes as specified 806 in Section 2.1. The functionality of receiver-driven layered 807 multicast may still be offered by the application, allowing the 808 receiver application to select the appropriate delivery session 809 based on the bandwidth requirement of that session. 811 Further, following details apply to LCT: 813 o The Layered Coding Transport (LCT) Building Block as defined in 814 RFC 5651 [RFC5651] is used with the following constraints: 816 o The TSI in the LCT header SHALL be set equal to the value of 817 the stsi attribute in Section 3.2. 819 o The Codepoint (CP) in the LCT header SHALL be used to signal 820 the applied formatting as defined in the signaling metadata. 822 o In accordance to ALC, a source FEC Payload ID header is used to 823 identify, for FEC purposes, the encoding symbols of the 824 delivery object, or a portion thereof, carried by the 825 associated ROUTE packet. This information may be sent in 826 several ways: 828 . As a simple new null FEC scheme with the following usage: 830 . The value of the source FEC Payload ID header SHALL 831 be set to 0, in case the ROUTE packet contains the 832 entire delivery object, or 834 . The value of the source FEC Payload ID header SHALL 835 be set as a direct address (start offset) 836 corresponding to the starting byte position of the 837 portion of the object carried in this packet using a 838 32-bit field. 840 . In a compatible manner to RFC 6330 [RFC6330] where the 841 SBN and ESI defines the start offset together with the 842 symbol size T. 844 . The signaling metadata provides the appropriate 845 parameters to indicate any of the above modes using the 846 srcFecPayloadId attribute. 848 o The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC5651] 849 MAY be used by the sender in the following manner: 851 o The Sender Current Time (SCT), depending on the application, 852 MAY be used to occasionally or frequently signal the sender 853 current time, possibly for reliever time synchronization. 855 o The Expected Residual Time (ERT) MAY be used to indicate the 856 expected remaining time for transmission of the current 857 object, to optimize detection of a lost delivery object. 859 o The Sender Last Changed (SLC) flag is typically not utilized, 860 but MAY be used to indicate addition/removal of Segments. 862 Additional extension headers MAY be used to support real-time 863 delivery. Such extension headers are defined in Section 2.1. 865 5.2. ROUTE Packetization for Source Flow 867 The following description of the ROUTE sender operation on the 868 mapping of the Application Object to the ROUTE packet payloads 869 logically represents an extension of RFC 5445 [RFC5445], which in 870 turn inherits the context, language, declarations and restrictions of 871 the FEC building block in RFC 5052 [RFC5052]. 873 The data carried in the payload of a given ROUTE packet constitute a 874 contiguous portion of the Application Object. ROUTE source delivery 875 can be considered as a special case of the use of the Compact No-Code 876 Scheme associated with FEC Encoding ID = 0 according to Sections 877 3.4.1 and 3.4.2 of RFC 5445 [RFC5445], in which the encoding symbol 878 size is exactly one byte. As specified in Section 2.1, for ROUTE 879 Source Flows, the FEC Payload ID SHALL deliver the 32-bit 880 start_offset. All receivers are expected to support, at minimum, 881 operation with this special case of the Compact No-Code FEC. 883 Note that in the event the source object size is greater than 2^32 884 bytes (approximately 4.3 GB), the applications (in the broadcaster 885 server and the receiver) are expected to perform segmentation/re- 886 assembly using methods beyond the scope of this document. 888 Finally, in some special cases a ROUTE sender MAY need to produce 889 ROUTE packets that do not contain any payload. This may be required, 890 for example, to signal the end of a session. These data-less packets 891 do not contain FEC Payload ID or payload data, but only the LCT 892 header fields. The total datagram length, conveyed by outer protocol 893 headers (e.g., the IP or UDP header), enables receivers to detect the 894 absence of the LCT header, FEC Payload ID and payload data. 896 5.2.1. Basic ROUTE Packetization 898 In the basic operation, it is assumed that the Application Object is 899 fully available at the ROUTE sender. 901 1. The amount of data to be sent in a single ROUTE packet is limited 902 by the maximum transfer unit of the data packets or the size of 903 the remaining data of the Application Object being sent, whichever 904 is smaller. The transfer unit is determined either by knowledge of 905 underlying transport block sizes or by other constraints. 906 2. The start_offset field in the LCT header of the ROUTE packet 907 indicates the byte offset of the carried data in the Application 908 Object being sent. 909 3. The Close Object (B) flag is set to 1 if this is the last ROUTE 910 packet carrying the data of the Application Object. 912 The order of packet delivery is arbitrary, but in the absence of 913 other constraints delivery with increasing start_offset value is 914 recommended. 916 5.2.2. ROUTE Packetization for CMAF Chunked Content 918 Following additional guidelines should be followed for ROUTE 919 packetization of CMAF Chunked Content in addition to the guideline of 920 Section 5.2.1: 922 1. If it is the first ROUTE packet carrying a CMAF Random Access 923 chunk, except for the first CMAF chunk in the segment, the 924 Codepoint value MAY be set to 10, as specified in the Codepoint 925 value table in Section 2.1. The receiver MAY use this information 926 for optimization of random access. 927 2. As soon as the total length of the media object is known, 928 potentially with the packaging of the last CMAF chunk of a 929 segment, the EXT_TOL extension header MAY be added to the LCT 930 header to signal the Transfer Length, so that the receiver may 931 know this information in a timely fashion. 933 5.3. Timing of Packet Emission 935 The sender SHALL use the timing information provided by the 936 application to time the emission of packets for a timely reception. 937 This information may be contained in the Application Objects e.g. 938 DASH Segments and/or the presentation manifest. Hence such packets of 939 streaming media with real time constraints SHALL be sent in such a 940 way to enable their timely reception with respect to the presentation 941 timeline. 943 5.4. Extended FDT Encoding for File Mode Sending 945 For File Mode Sending: 947 o The TOI field in the ROUTE packet header SHALL be set such that 948 Content-Location can be derived at the receiver according to File 949 Template substitution specified in Section 6.3.1. 951 o After sending the first packet with a given TOI value, none of the 952 packets pertaining to this TOI SHALL be sent later than the wall 953 clock time as derived from maxExpiresDelta. The EXT_TIME header 954 with Expected Residual Time (ERT) MAY be used in order to convey 955 more accurate expiry time. 957 5.5. FEC Framework Considerations 959 The FEC framework uses concepts of the FECFRAME work as defined in 960 RFC 6363 [RFC6363], as well as the FEC building block, RFC 5052 961 [RFC5052], which is adopted in the existing FLUTE/ALC/LCT 962 specifications. 963 The FEC design adheres to the following principles: 965 o FEC-related information is provided only where needed. 967 o Receivers not capable of this framework can ignore repair packets. 969 o The FEC is symbol-based with fixed symbol size per protected 970 Source Flow. The ALC protocol and existing FEC schemes are reused. 972 o A FEC Repair Flow provides protection of delivery objects from one 973 or more Source Flows. 975 The FEC-specific components of the FEC framework are: 977 o FEC Repair Flow declaration including all FEC-specific 978 information. 980 o FEC transport object that is the concatenation of a delivery 981 object, padding octets and size information in order to form an N- 982 symbol-sized chunk of data, where N >= 1. 984 o FEC super-object that is the concatenation of one or more FEC 985 transport objects in order to bundle FEC transport objects for FEC 986 protection. 988 o FEC protocol and packet structure. 990 A receiver needs to be able to recover delivery objects from repair 991 packets based on available FEC information. 993 5.6. FEC Transport Object Construction 995 In order to identify a delivery object in the context of the Repair 996 protocol, the following information is needed: 998 o TSI and TOI of the delivery object. In this case, the FEC object 999 corresponds to the (entire) delivery object. 1001 o Octet range of the delivery object, i.e. start offset within the 1002 delivery object and number of subsequent and contiguous octets of 1003 delivery object that constitutes the FEC object (i.e., the FEC- 1004 protected portion of the source object). In this case, the FEC 1005 object corresponds to a contiguous byte range portion of the 1006 delivery object. 1008 Typically, for real-time object delivery with smaller delivery object 1009 sizes, the first mapping is applied; i.e., the delivery object is an 1010 FEC object. 1011 Assuming that the FEC object is the delivery object, for each 1012 delivery object, the associated FEC transport object is comprised of 1013 the concatenation of the delivery object, padding octets (P) and the 1014 FEC object size (F) in octets, where F is carried in a 4-octet field. 1016 The FEC transport object size S, in FEC encoding symbols, SHALL be an 1017 integer multiple of the symbol size Y. 1018 S is determined from the session information and/or the repair packet 1019 headers. 1020 F is carried in the last 4 octets of the FEC transport object. 1021 Specifically, let: 1023 o F be the size of the delivery object in octets, 1025 o F' be the F octets of data of the delivery object, 1027 o f' denote the four octets of data carrying the value of F in 1028 network octet order (high-order octet first), 1030 o S be the size of the FEC transport object with S=ceil((F+4)/Y), 1031 where the ceil() function rounds the result upward to its nearest 1032 integer, 1034 o P' be S*Y-4-F octets of data, i.e. padding placed between the 1035 delivery object and the 4-byte field conveying the value of F and 1036 located at the end of the FEC transport object, and 1038 o O' be the concatenation of F', P' and f'. 1040 O' then constitutes the FEC transport object of size S*Y octets. Note 1041 that padding octets and the object size F are not sent in source 1042 packets of the delivery object, but are only part of an FEC transport 1043 object that FEC decoding recovers in order to extract the FEC object 1044 and thus the delivery object or portion of the delivery object that 1045 constitutes the FEC object. In the above context, the FEC transport 1046 object size in symbols is S. 1048 The general information about an FEC transport object that is 1049 conveyed to an FEC-enabled receiver is the source TSI, source TOI and 1050 the associated octet range within the delivery object comprising the 1051 associated FEC object. However, as the size in octets of the FEC 1052 object is provided in the appended field within the FEC transport 1053 object, the remaining information can be conveyed as: 1055 o TSI and TOI of the delivery object from which the FEC object 1056 associated with the FEC transport object is generated 1058 o Start octet within delivery object for the associated FEC object 1060 o Size in symbols of the FEC transport object, S 1062 5.7. Super-Object Construction 1064 From the FEC Repair Flow declaration, the construction of an FEC 1065 super-object as the concatenation of one or more FEC transport 1066 objects can be determined. The FEC super-object includes the general 1067 information about the FEC transport objects as described in the 1068 previous sections, as well as the placement order of FEC transport 1069 objects within the FEC super-object. 1071 Let: 1072 o N be the total number of FEC transport objects for the FEC super- 1073 object construction. 1075 o For i = 0,..., N-1, let S[i] be the size in symbols of FEC 1076 transport object i. 1078 o B' be the FEC super-object which is the concatenation of the FEC 1079 transport objects in numerical order, comprised of K = Sum of N 1080 source symbols, each symbol denoted as S[i]. 1082 For each FEC super-object, the remaining general information that 1083 needs to be conveyed to an FEC-enabled receiver, beyond what is 1084 already carried in the FEC transport objects that constitute the FEC 1085 super-object, comprises: 1087 o The total number of FEC transport objects N. 1089 o For each FEC transport object, the: 1091 o TSI and TOI of the delivery object from which the FEC object 1092 associated with the FEC transport object is generated, 1094 o Start octet within delivery object for the associated FEC 1095 object, and 1097 o Size in symbols of the FEC transport object. 1099 The carriage of the FEC repair information is discussed below. 1101 5.8. Repair Packet Considerations 1103 The repair protocol is based on Asynchronous Layered Coding (ALC) as 1104 defined in RFC 5775 [RFC5775] and the Layered Coding Transport (LCT) 1105 Building Block as defined in RFC 5651 [RFC5651] with the following 1106 details: 1108 o The Layered Coding Transport (LCT) Building Block as defined in 1109 RFC 5651 [RFC5651] is used as defined in Asynchronous Layered 1110 Coding (ALC), Section 2.1. In addition, the following constraints 1111 apply: 1113 o The TSI in the LCT header SHALL identify the Repair Flow to 1114 which this packet applies, by the matching value of the ptsi 1115 attribute in the signaling metadata among the LCT channels 1116 carrying Repair Flows. 1118 o The FEC building block is used according to RFC 6330 [RFC6330], 1119 but only repair packets are delivered. 1121 o Each repair packet within the scope of the Repair Flow (as 1122 indicated by the TSI field in the LCT header) SHALL carry the 1123 repair symbols for a corresponding FEC transport object/super- 1124 object as identified by its TOI. The repair object/super- 1125 object TOI SHALL be unique for each FEC super-object that is 1126 created within the scope of the TSI. 1128 5.9. Summary FEC Information 1130 For each super-object (identified by a unique TOI within a Repair 1131 Flow that is in turn identified by the TSI in the LCT header) that is 1132 generated, the following information needs to be communicated to the 1133 receiver: 1135 o The FEC configuration consisting of: 1137 o FEC Object Transmission Information (OTI) per RFC 5052 1138 [RFC5052]. 1140 o Additional FEC information (see Section 3.3). 1142 o The total number of FEC objects included in the FEC super- 1143 object, N. 1145 o For each FEC transport object: 1147 o TSI and TOI of the delivery object used to generate the FEC 1148 object associated with the FEC transport object, 1150 o Start octet within the delivery object of the associated FEC 1151 object, if applicable, and 1153 o The size in symbols of the FEC transport object, S. 1155 The above information is delivered: 1157 o Statically in the session metadata as defined in Section 3.3, and 1159 o Dynamically in an LCT extension header. 1161 6. Receiver operation 1163 The receiver receives packets and filters those packets according to 1164 the following. From the ROUTE session and each contained LCT channel, 1165 the receiver regenerates delivery objects from the ROUTE session and 1166 each contained LCT channel. 1168 In the event that the receiver receives data that does not conform to 1169 the ROUTE protocol specified in this document, the receiver SHOULD 1170 attempt to recover gracefully by e.g. informing the application about 1171 the issues using means beyond the scope of this document. The ROUTE 1172 Packetization specified in Section 5.2.1 implies that the receiver 1173 SHALL NOT receive overlapping data: if such a condition is 1174 encountered at the receiver, the packet SHALL be assumed to be 1175 corrupted. 1177 The basic receiver operation is provided below, it assumes an error- 1178 free scenario, while repair considerations are provided in Section 7. 1180 6.1. Basic Application Object Recovery for Source Flows 1182 Upon receipt of each ROUTE packet of a Source Flow, the receiver 1183 proceeds with the following steps in the order listed. 1185 1) The ROUTE receiver is expected to parse the LCT and FEC Payload ID 1186 to verify that it is a valid header. If it is not valid, then the 1187 payload is discarded without further processing. 1188 2) All ROUTE packets used to recover a specific delivery object carry 1189 the same TOI value in the LCT header. 1190 3) The ROUTE receiver is expected to assert that the TSI and the 1191 Codepoint represent valid operation points in the signaling 1192 metadata, i.e. the signaling contains a matching entry to the TSI 1193 value provided in the packet header, as well as for this TSI, and 1194 Codepoint field in the LCT header has a valid Codepoint mapping. 1195 4) The ROUTE receiver should process the remainder of the payload, 1196 including the appropriate interpretation of the other payload 1197 header fields, and using the source FEC Payload ID (to determine 1198 the start_offset) and the payload data to reconstruct the 1199 corresponding object as follows: 1201 a. For File Mode, upon receipt of the first ROUTE packet 1202 payload for an object, the ROUTE receiver uses the 1203 File@Transfer-Length attribute of the associated Extended FDT 1204 Instance, when present, to determine the length T of the 1205 object. When the File@Transfer-Length attribute is not 1206 present in the Extended FDT Instance, the receiver uses the 1207 maxTransportSize attribute of the associated Extended FDT 1208 Instance to determine the maximum length T' of the object. 1209 Alternatively, and specifically for delivery modes other than 1210 File Mode, EXT_TOL header can be used to determine the length 1211 T of the object. 1212 b. The ROUTE receiver allocates buffer space for the T or T' 1213 bytes that the object will or may occupy. 1214 c. The ROUTE receiver computes the length of the payload, Y, by 1215 subtracting the payload header length from the total length 1216 of the received payload. 1217 d. The ROUTE receiver allocates a Boolean array RECEIVED[0..T- 1218 1] or RECEIVED[0..T'-1], as appropriate, with all entries 1219 initialized to false to track received object symbols. The 1220 ROUTE receiver continuously acquires packet payloads for the 1221 object as long as all of the following conditions are 1222 satisfied: i) there is at least one entry in RECEIVED still 1223 set to false; ii) the object has not yet expired; and iii) 1224 the application has not given up on reception of this object. 1225 More details are provided below. 1226 e. For each received ROUTE packet payload for the object 1227 (including the first payload), the steps to be taken to help 1228 recover the object are as follows: 1229 i. If the packet includes an EXT_TOL or EXT_FTI header, 1230 modify the Boolean array RECEIVED[0..T'-1] to become 1231 RECEIVED[0..T-1]. 1232 ii. Let X be the value of the start_offset field in the ROUTE 1233 packet header and let Y be the length of the payload, Y, 1234 computed by subtracting the LCT header size and the FEC 1235 Payload ID size from the total length of the received 1236 packet. 1237 iii. The ROUTE receiver copies the data into the appropriate 1238 place within the space reserved for the object and sets 1239 RECEIVED[X ... X+Y-1] = true. 1240 iv. If all T entries of RECEIVED are true, then the receiver 1241 has recovered the entire object. 1243 Upon recovery of both the complete set of packet payloads for the 1244 delivery object associated with a given TOI value, and the metadata 1245 for that delivery object, the reception of the delivery object, now a 1246 fully received Application Object, is complete. 1248 Given the timely reception of ROUTE packets belonging to an 1249 Application Object, the receiver SHALL make the Application Objects 1250 available to the application in a timely fashion, using the 1251 application-provided timing data (e.g. the timing data signaled via 1252 the presentation manifest file). For example, HTTP/1.1 chunked 1253 transfer may need to be enabled to transfer the Application Objects 1254 if MPD@availabilityTimeOffset is signaled in the DASH presentation 1255 manifest, to allow for timely sending of segment data to the 1256 application. 1258 6.2. Fast Stream Acquisition 1260 When the receiver initially starts reception of ROUTE packets, it is 1261 likely that the reception does not start from the very first packet 1262 carrying the data of a multicast transport object, and in this case 1263 such a partially received object is normally discarded. However, the 1264 channel acquisition or "tune-in" times can be improved if the 1265 partially received object is usable by the application. 1266 One example realization for this is as follows: 1268 o The receiver checks for the first received packet with the 1269 Codepoint value set to 10, indicating the start of a CMAF Random 1270 Access chunk. 1272 o The receiver MAY make the partially received object (a partial 1273 DASH segment starting from the packet above) available to the 1274 application for fast stream acquisition. 1276 o It MAY recover the earliest presentation time of this CMAF Random 1277 Access chunk from the ROUTE packet LCT Congestion Control 1278 Information (CCI) field as specified in Section 2.1 to be able to 1279 add a new Period element in the MPD exposed to the application 1280 containing just the partially received DASH segment with period 1281 continuity signaling. 1283 6.3. Generating Extended FDT Instance for File Mode 1285 An Extended FDT Instance conforming to RFC 6726 [RFC6726], is 1286 produced at the receiver using the service metadata and in band 1287 signaling in the following steps: 1289 6.3.1. File Template Substitution for Content-Location Derivation 1291 The Content-Location element of the Extended FDT for a specific 1292 Application Object is derived as follows: 1294 "$TOI$" is substituted with the unique TOI value in the LCT header of 1295 the ROUTE packets used to recover the given delivery object (as 1296 specified in Section 6.1). 1298 After the substitution, the fileTemplate SHALL be a valid URL 1299 corresponding to the Content-Location attribute of the associated 1300 Application Object. 1302 An example @fileTemplate using a width of 5 is: 1303 fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with 1304 exactly five digits in the number portion. The Media Segment file 1305 name for TOI=33 using this template is myVideo00033.mps. 1307 6.3.2. File@Transfer-Length Derivation 1309 Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL 1310 header, when present, is used to derive the Transport Object Length 1311 (TOL) of the File. If the File@Transfer-Length parameter in the 1312 Extended FDT Instance is not present, then the EXT_TOL header or the 1313 or EXT_FTI header SHALL be present. Note that a header containing the 1314 transport object length (EXT_TOL or EXT_FTI) need not be present in 1315 each packet header. If the broadcaster does not know the length of 1316 the transport object at the beginning of the transfer, an EXT_TOL or 1317 EXT_FTI header SHALL be included in at least the last packet of the 1318 file and should be included in the last few packets of the transfer. 1320 6.3.3. FDT-Instance@Expires Derivation 1322 When present, the maxExpiresDelta attribute SHALL be used to generate 1323 the value of the FDT-Instance@Expires attribute. The receiver is 1324 expected to add this value to its wall clock time when acquiring the 1325 first ROUTE packet carrying the data of a given delivery object to 1326 obtain the value for @Expires. 1328 When maxExpiresDelta is not present, the EXT_TIME header with 1329 Expected Residual Time (ERT) SHALL be used to derive the expiry time 1330 of the Extended FDT Instance. When both maxExpiresDelta and the ERT 1331 of EXT_TIME are present, the smaller of the two values should be used 1332 as the incremental time interval to be added to the receiver's 1333 current time to generate the effective value for @Expires. When 1334 neither maxExpiresDelta nor the ERT field of the EXT_TIME header is 1335 present, then the expiration time of the Extended FDT Instance is 1336 given by its @Expires attribute. 1338 7. FEC Application 1340 7.1. General FEC Application Guidelines 1342 It is up to the receiver to decide to use zero, one or more of the 1343 FEC streams. Hence, the application assigns a recovery property to 1344 each flow, which defines aspects such as the delay and the required 1345 memory if one or the other is chosen. The receiver MAY decide whether 1346 or not to utilize Repair Flows based on the following considerations: 1348 o The desired start-up and end-to-end latency. If a Repair Flow 1349 requires a significant amount of buffering time to be effective, 1350 such Repair Flow might only be used in time-shift operations or in 1351 poor reception conditions, since use of such Repair Flow trades 1352 off end-to-end latency against DASH Media Presentation quality. 1354 o FEC capabilities, i.e. the receiver MAY pick only the FEC 1355 algorithm that it supports. 1357 o Which Source Flows are being protected; for example, if the Repair 1358 Flow protects Source Flows that are not selected by the receiver, 1359 then the receiver may not select the Repair Flow. 1361 o Other considerations such as available buffer size, reception 1362 conditions, etc. 1364 If a receiver decides to acquire a certain Repair Flow then the 1365 receiver must receive data on all Source Flows that are protected by 1366 that Repair Flow to collect the relevant packets. 1368 7.2. TOI Mapping 1370 When mappingTOIx/mappingTOIy are used to signal X and Y values, then 1371 the TOI value(s) of the one or more source objects (sourceTOI) 1372 protected by a given FEC transport object or FEC super-object with a 1373 TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y. 1375 When neither mappingTOIx nor mappingTOIy is present there is a 1:1 1376 relationship between each delivery object carried in the Source Flow 1377 as identified by ptsi to an FEC object carried in this Repair Flow. 1378 In this case the TOI of each of those delivery objects SHALL be 1379 identical to the TOI of the corresponding FEC object. 1381 7.3. Delivery Object Reception Timeout 1383 The permitted start and end times for the receiver to perform the 1384 file repair procedure, in case of unsuccessful broadcast file 1385 reception, and associated rules and parameters are as follows: 1387 o The latest time that the file repair procedure may start is bound 1388 by the @Expires attribute of the FDT-Instance. 1390 o The receiver may choose to start the file repair procedure 1391 earlier, if it detects the occurrence of any of the following 1392 events: 1394 o Presence of the Close Object flag (B) in the LCT header 1395 [RFC5651] for the file of interest; 1397 o Presence of the Close Session flag (A) in the LCT header 1398 [RFC5651] before the nominal expiration of the Extended FDT 1399 Instance as defined by the @Expires attribute. 1401 7.4. Example FEC Operation 1403 To be able to recover the delivery objects that are protected by a 1404 Repair Flow, a receiver needs to obtain the necessary Service 1405 signaling metadata fragments that describe the corresponding 1406 collection of delivery objects that are covered by this Repair Flow. 1407 A Repair Flow is characterized by the combination of an LCT channel, 1408 a unique TSI number, as well as the corresponding protected Source 1409 Flows. 1410 If a receiver acquires data of a Repair Flow, the receiver is 1411 expected to collect all packets of all protected Transport Sessions. 1412 Upon receipt of each packet, whether it is a source or repair packet, 1413 the receiver proceeds with the following steps in the order listed. 1414 1. The receiver is expected to parse the packet header and verify 1415 that it is a valid header. If it is not valid, then the packet 1416 SHALL be discarded without further processing. 1417 2. The receiver is expected to parse the TSI field of the packet 1418 header and verify that a matching value exists in the Service 1419 signaling for the Repair Flow or the associated Protected Source 1420 Flow. If no match is found, the packet SHALL be discarded without 1421 further processing. 1422 3. The receiver processes the remainder of the packet, including 1423 interpretation of the other header fields, and using the source 1424 FEC Payload ID (to determine the start_offset byte position within 1425 the source object), the Repair FEC Payload ID, as well as the 1426 payload data, reconstructs the decoding blocks corresponding to a 1427 FEC super-object as follows: 1428 a. For a source packet, the receiver identifies the delivery 1429 object to which the received packet is associated, using the 1430 session information and the TOI carried in the payload 1431 header. Similarly, for a repair object the receiver 1432 identifies the FEC super-object to which the received packet 1433 is associated, using the session information and the TOI 1434 carried in the payload header. 1435 b. For source packets, the receiver collects the data for each 1436 FEC super-object and recovers FEC super-objects in same way 1437 as Source Flow in Section 6.1. The received FEC super-object 1438 is then mapped to a source block and the corresponding 1439 encoding symbols are generated. 1440 c. With the reception of the repair packets, the FEC super- 1441 object can be recovered. 1442 d. Once the FEC super-object is recovered, the individual 1443 delivery objects can be extracted. 1445 8. Considerations for Defining ROUTE Profiles 1447 Services (e.g. ATSC-ROUTE [ATSCA331], DVB-MABR [DVBMABR] etc.) may 1448 define specific ROUTE "profiles" based on this document in their 1449 respective standards organizations. An example is noted in the 1450 overview section: DVB has specified a profile of ATSC-ROUTE in DVB 1451 Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. The 1452 definition with the following considerations. Services MAY 1454 o Restrict the signaling certain values signaled in the LCT header 1455 and/or provision unused fields in the LCT header. 1457 o Restrict using certain LCT header extensions and/or add new LCT 1458 header extensions. 1460 o Restrict or limit usage of some Codepoints, and/or assign 1461 semantics to service-specific Codepoints marked as reserved in 1462 this document. 1464 o Restrict usage of certain service signaling attributes and/or add 1465 own service metadata. 1467 Services SHALL NOT redefine the semantics of any of the ROUTE 1468 attributes in LCT headers and extension, and service signaling 1469 attributes already specified in this document. 1471 By following these guidelines, services can define profiles that are 1472 interoperable. 1474 9. ROUTE Concepts 1476 9.1. ROUTE Modes of Delivery 1478 Different ROUTE delivery modes specified in Section 4 are optimized 1479 for delivery of different types of media data. For example, File Mode 1480 is specifically optimized for delivering DASH content using Segment 1481 Template with number substitution. Using File Template in EFDT avoids 1482 the need of repeated sending of metadata as outlined in the following 1483 section. Same optimizations however cannot be used for time 1484 substitution and segment timeline where the addressing of each 1485 segment is time dependent and in general does not follow a fixed or 1486 repeated pattern. In this case, Entity mode is more optimized which 1487 carries the file location in band. Also, Entity mode can be used to 1488 deliver a file or part of the file using HTTP Partial Content 1489 response headers. 1491 9.2. File Mode Optimizations 1493 In the file mode, the delivery object represents an Application 1494 Object. This mode replicates FLUTE as defined in RFC 6726 [RFC6726], 1495 but with the ability to send static and pre-known file metadata out 1496 of band. 1497 In FLUTE, FDT Instances are delivered in-band and need to be 1498 generated and delivered in real-time if objects are generated in 1499 real-time at the sender. These FDT Instances have some differences as 1500 compared to the FDT specified in Section 3.4.2 of RFC 6726 [RFC6726] 1501 and Section 7.2.10 of MBMS [MBMS]. The key difference is that besides 1502 separated delivery of file metadata from the delivery object it 1503 describes, the FDT functionality in ROUTE may be extended by 1504 additional file metadata and rules that enable the receiver to 1505 generate the Content-Location attribute of the File element of the 1506 FDT, on-the-fly. This is done by using information in both the 1507 extensions to the FDT and the LCT header. The combination of pre- 1508 delivery of static file metadata and receiver self-generation of 1509 dynamic file metadata avoids the necessity of continuously sending 1510 the FDT Instances for real-time objects. Such modified FDT 1511 functionality in ROUTE is referred to as the Extended FDT. 1513 9.3. In Band Signaling of Object Transfer Length 1515 As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header 1516 extension with 24 bits or, if required, 48 bits of to signal the 1517 Transfer Length directly within the ROUTE packet. 1519 The transport object length can also be determined without the use of 1520 EXT_TOL by examining the LCT packet with the Close Object (B) flag. 1521 However, if this packet is lost, then the EXT_TOL information can be 1522 used by the receiver to determine the transport object length. 1524 Applications using ROUTE for delivery of low-latency streaming 1525 content may make use of this feature for sender-end latency 1526 optimizations: the sender does not have to wait for the completion of 1527 the packaging of a whole Application Object to find its transfer 1528 length to be included in the FDT before the sending can start. 1529 Rather, partially encoded data can already be started to be sent via 1530 the ROUTE sender. As the time approaches when the encoding of the 1531 Application Object is nearing completion, and the length of the 1532 object becomes known (e.g. time of writing the last CMAF Chunk of a 1533 DASH segment), only then the sender can signal the object length 1534 using the EXT TOL LCT header. For example, for a 2 seconds DASH 1535 segment with 100 millisecond chunks, it may result in saving up to 1536 1.9 second latency at the sending end. 1538 9.4. Repair Protocol Concepts 1540 The ROUTE repair protocol is FEC-based and is enabled as an 1541 additional layer between the transport layer (e.g., UDP) and the 1542 object delivery layer protocol. The FEC reuses concepts of FEC 1543 Framework defined in RFC 6363 [RFC6363], but in contrast to the FEC 1544 Framework in RFC 6363 [RFC6363] the ROUTE repair protocol does not 1545 protect packets, but instead it protects delivery objects as 1546 delivered in the source protocol. In addition, as an extension to 1547 FLUTE, it supports the protection of multiple objects in one source 1548 block which is in alignment with the FEC Framework as defined in RFC 1549 6363 [RFC6363]. Each FEC source block may consist of parts of a 1550 delivery object, as a single delivery object (similar to FLUTE) or 1551 multiple delivery objects that are bundled prior to FEC protection. 1552 ROUTE FEC makes use of FEC schemes in a similar way as those defined 1553 in RFC 5052 [RFC5052] and uses the terminology of that document. The 1554 FEC scheme defines the FEC encoding and decoding, as well as the 1555 protocol fields and procedures used to identify packet payload data 1556 in the context of the FEC scheme. 1557 In ROUTE all packets are LCT packets as defined in RFC 5651 1558 [RFC5651]. Source and repair packets may be distinguished by: 1560 o Different ROUTE sessions; i.e., they are carried on different 1561 UDP/IP port combinations. 1563 o Different LCT channels; i.e., they use different TSI values in the 1564 LCT header. 1566 o The most significant PSI bit in the LCT, if carried in the same 1567 LCT channel. This mode of operation is mostly suitable for FLUTE- 1568 compatible deployments. 1570 10. Interoperability Chart 1572 As noted in prevision sections, ATSC-ROUTE [ATSCA331] and DVB-MABR 1573 [DVBMABR] are considered services using this document that constrain 1574 specific features as well as add new ones. In this context, the 1575 following table is an informative comparison of the interoperability 1576 of ROUTE as specified in this document, with the ATSC-ROUTE 1577 [ATSCA331] and DVB-MABR [DVBMABR]: 1579 +---------------+---------------+--------------------+-----------------+ 1580 | Element | ATSC-ROUTE | This Document | DVB-MABR | 1581 | | | | | 1582 +--------+------+---------------+--------------------+-----------------+ 1583 | LCT |PSI | Set to 0 | Not defined | Set to 1 for | 1584 | header |least | for Source | | Source Flow for | 1585 | fields |signi-| Flow. | | CMAF Random | 1586 | |ficant| | | access chunk | 1587 | |bit | | | | 1588 | +------+---------------+--------------------------------------+ 1589 | |CCI | May be set | May be set to EPT for Source Flow | 1590 | | | to 0 | | 1591 +--------+------+---------------+--------------------+-----------------+ 1592 | LCT header | EXT_ROUTE_ | Not defined, | Shall not | 1593 | extensions | PRESENTATION_ | may be added | be used | 1594 | | TIME Header | by a profile. | | 1595 | | used for | | | 1596 | | MDE mode | | | 1597 | +---------------+--------------------+-----------------+ 1598 | | EXT_TIME | EXT_TIME Header may be used | 1599 | | Header | regardless (for | 1600 | | linked to | FDT-Instance@Expires | 1601 | | MDE mode | calculation) | 1602 | | in Annex | | 1603 | | A.3.7.2 | | 1604 +---------------+---------------+--------------------+-----------------+ 1605 | Codepoints | Full set | Does not specify | Restricted | 1606 | | | range 11 - 255 | to 5 - 9 | 1607 | | | (leaves to | | 1608 | | | profiles) | | 1609 +---------------+---------------+--------------------+-----------------+ 1610 | Session | Full set | Only defines | Reuses A/331 | 1611 | metadata | | a small subset | metadata, | 1612 | | | of data necessary | duplicated | 1613 | | | for setting up | from its own | 1614 | | | Source and Repair | service | 1615 | | | Flows. | signaling. | 1616 | | | Does not define | | 1617 | | | format or | | 1618 | | | encoding of data | | 1619 | | | except if data is | | 1620 | | | integral/ | | 1621 | | | alphanumerical. | | 1622 | | | Leaves rest to | | 1623 | | | profiles. | | 1624 +---------------+---------------+--------------------+-----------------+ 1625 | Extended | Instance | Not restricted, | Instance shall | 1626 | FDT | shall not | may be | not be sent | 1627 | | be sent | restricted | with Source | 1628 | | with Source | by a profile. | Flow | 1629 | | Flow | | | 1630 | +---------------+--------------------+-----------------+ 1631 | | No | Only allowed in File Mode | 1632 | | restriction | | 1633 +---------------+---------------+--------------------+-----------------+ 1634 | Delivery | File, Entity, Signed/ | Signed/ | 1635 | Object | unsigned package | unsigned | 1636 | Mode | | package not | 1637 | | | allowed | 1638 +---------------+---------------+--------------------+-----------------+ 1639 | Sender | Defined for | Defined for DASH segment and CMAF | 1640 | operation: | DASH | Chunks | 1641 | Packet- | segment | | 1642 | ization | | | 1643 +---------------+---------------+--------------------------------------+ 1644 | Receiver | Object | Object may be handed before | 1645 | object | handed | completion if | 1646 | recovery | to | MPD@availabilityTimeOffset | 1647 | | application | signaled | 1648 | | upon | | 1649 | | complete | | 1650 | | reception | | 1651 | +---------------+--------------------------------------+ 1652 | | - | Fast Stream acquisition | 1653 | | | guideline provided | 1654 +---------------+---------------+--------------------------------------+ 1655 11. Security and Privacy Considerations 1657 11.1. Security Considerations 1659 As noted in Section 9, ROUTE is aligned with FLUTE as specified in 1660 RFC 6726 [RFC6726] (see Section 9), and only diverges in certain 1661 signaling optimizations, especially for the real-time object delivery 1662 case. Hence most of the security considerations documented in RFC 1663 6726 [RFC6726] for the data flow itself, the session metadata 1664 (session control parameters in RFC 6726 [RFC6726]), and the 1665 associated building blocks apply directly to ROUTE, as elaborated in 1666 the following along with some additional considerations. 1668 Both encryption and integrity protection applied either on file or 1669 packet level, as recommended in file corruption considerations of RFC 1670 6726 [RFC6726] SHOULD be used for ROUTE. Additionally, RFC 3740 1671 [RFC3740] documents multicast security architecture in great detail 1672 with clear security recommendations which SHOULD be followed. 1674 When ROUTE is carried over UDP and a reverse channel from receiver to 1675 sender is available, the security mechanisms provided in RFC 6347 1676 [RFC6347] SHALL apply. At the time, draft DTLS 1.3 based on TSL 1.3 1677 [DTLS13] is pending publication, and may be considered as the 1678 alternate means for security post publication. 1680 In regard to considerations for attacks against session description, 1681 this document does not specify the semantics or mechanism of delivery 1682 of session metadata, though the same threats apply for service using 1683 ROUTE as well. Hence a service using ROUTE SHOULD take these threats 1684 into consideration and address them appropriately following the 1685 guideline provided by RFC 6726 [RFC6726]. Additionally to the 1686 recommendations of RFC 6726 [RFC6726], for Internet connected 1687 devices, services SHOULD enable clients to access the session 1688 description information using HTTPS with customary 1689 authentication/authorization, instead of sending this data via 1690 multicast/broadcast, since considerable security work has been done 1691 already in this unicast domain which can enable highly secure access 1692 of session description data. Accessing via unicast however will have 1693 different privacy considerations, noted in Section 11.2. Note that in 1694 general the multicast/broadcast stream is delayed with respect to the 1695 unicast stream. Therefore, the session description protocol SHOULD 1696 be time-synchronized with the broadcast stream, particularly if the 1697 session description contains security-related information. 1699 In regard to FDT, there is one key difference for File Mode when 1700 using File Template in EFDT, which avoids repeated sending of FDT 1701 instance and hence the corresponding threats noted in RFC 6726 1703 [RFC6726] do not apply directly to ROUTE in this case. The threat 1704 however is shifted to the ALC/LCT headers, since they carry the 1705 additional signaling that enables determining Content-Location and 1706 File@Transfer-Length in this case. Hence integrity protection 1707 recommendations of ALC/LCT header SHOULD be considered with higher 1708 emphasis in this case for ROUTE. 1710 Finally, attacks against the congestion control building block for 1711 the case of ROUTE can impact the optional fast stream acquisition 1712 specified in Section 6.2. Receivers SHOULD have robustness against 1713 timestamp values that are suspicious, e.g. by comparing the signaled 1714 time in the LCT headers with the approximate time signaled by the 1715 MPD, and SHOULD discard outlying values. Additionally, receivers MUST 1716 adhere to the expiry timelines as specified in Section 6. Integrity 1717 protection mechanisms documented in RFC 6726 [RFC6726] SHOULD be used 1718 to address this threat. 1720 11.2. Privacy Considerations 1722 Encryption mechanisms recommended for security considerations in 1723 Section 11.1 SHOULD also be applied to enable privacy and protection 1724 from snooping attacks. 1726 Since this protocol is primarily targeted for IP multicast/broadcast 1727 environment where the end user is mostly listening, identity 1728 protection and user data retention considerations are more protected 1729 than in the unicast case. Best practices for enabling privacy on IP 1730 multicast/broadcast SHOULD be applied by the operators, e.g. 1731 Recommendations for DNS Privacy Service Operators in RFC 8932 1732 [RFC8932]. 1734 However, if clients access session description information via HTTPS, 1735 the same privacy considerations and solutions SHALL apply to this 1736 access as for regular HTTPS communication, an area which is very well 1737 studied and the concepts of which are being integrated directly into 1738 newer transport protocols such as IETF QUIC [RFC9000] enabling HTTP/3 1739 [HTTP3]. Hence such newer protocols SHOULD be used to foster privacy. 1741 Note that streaming services MAY contain content that may only be 1742 accessed via DRM (digital rights management) systems. DRM systems 1743 can prevent unauthorized access to content delivered via ROUTE. 1745 12. IANA Considerations 1747 This document makes no requests for IANA action. 1749 13. References 1751 13.1. Normative References 1753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1754 Requirement Levels", BCP 14, RFC 2119, March 1997. 1755 http://tools.ietf.org/html/rfc2119 1757 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 1758 Key Words", BCP 14, FC 8174, DOI 10.17487/RFC8174, May 2017. 1759 http://tools.ietf.org/html/rfc8174 1761 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1762 Transport (LCT) Building Block", RFC 5651, October 2009. 1763 http://tools.ietf.org/html/rfc5651 1765 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1766 Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010. 1767 http://tools.ietf.org/html/rfc5775 1769 [RFC6726] Paila, T., Luby, M., Lehtonen, R., Roca, V., Walsh, R., 1770 "FLUTE-File Delivery over Unidirectional Transport." 2012. 1771 http://tools.ietf.org/html/rfc6726 1773 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and 1774 Minder, L. "RaptorQ forward error correction scheme for object 1775 delivery", 2011. 1776 http://tools.ietf.org/html/rfc6330 1778 [RFC3986] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform 1779 Resource Identifier (URI): Generic Syntax", January 2005. 1780 http://tools.ietf.org/html/rfc3986 1782 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3," 1783 Internet Engineering Task Force, Reston, VA, May, 1996. 1784 http://tools.ietf.org/html/rfc1952 1786 [RFC2557] Palme, J., Hopmann, A. and Shelness, N., "MIME 1787 Encapsulation of Aggregate Documents, such as HTML (MHTML)", Internet 1788 Engineering Task Force, Reston, VA, March 1999. 1789 http://tools.ietf.org/html/rfc2557 1791 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, 1792 "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 1793 Message Specification," Internet Engineering Task Force, Fremont, CA, 1794 January 2010. 1795 https://tools.ietf.org/html/rfc8551 1797 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes," 1798 Internet Engineering Task Force, Reston, VA, March, 2009. 1799 http://tools.ietf.org/html/rfc5445 1801 [RFC5052] Watson, M., Luby, M., and Vicisano, L., "Forward Error 1802 Correction (FEC) Building Block," Internet Engineering Task Force, 1803 Reston, VA, August 2007. http://tools.ietf.org/html/rfc5052 1805 [RFC6363] Watson, M., Begen, A. and Roca, V., "Forward Error 1806 Correction (FEC) Framework," Internet Engineering Task Force, Reston, 1807 VA, October, 2011. http://tools.ietf.org/html/rfc6363 1809 [RFC7231] IETF RFC 7231 "Hypertext Transfer Protocol (HTTP/1.1): 1810 Semantics and Content", June 2014. 1811 http://tools.ietf.org/html/rfc7231 1813 [ATSCA331] ATSC A/331:2019: "ATSC Standard: Signaling, Delivery, 1814 Synchronization, and Error Protection", 20 June 2019. 1816 13.2. Informative References 1818 [RFC6968] Roca, V. and Adamson, B., "FCAST: Object Delivery for the 1819 Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable 1820 Multicast (NORM) Protocols," Internet Engineering Task Force, Reston, 1821 VA, July, 2013. http://tools.ietf.org/html/rfc6968 1823 [DVBMABR] ETSI: "Digital Video Broadcasting (DVB); Adaptive media 1824 streaming over IP multicast", ETSI TS 103 769 V1.1.1 (2020-11) 1825 November 2020. 1827 [DASH] ISO/IEC 23009-1:2019: "Information technology - Dynamic 1828 adaptive streaming over HTTP (DASH) - Part 1: Media presentation 1829 description and segment formats", Fourth edition, December 2019. 1831 [CMAF] ISO/IEC 23000-19:2018: "Information technology - Multimedia 1832 application format (MPEG-A) - Part 19: Common media application 1833 format (CMAF) for segmented media", First edition, January 2018. 1835 [MBMS] ETSI: "Universal Mobile Telecommunications Systems (UMTS); 1836 LTE; Multimedia Broadcast/Multicast Service (MBMS); Protocols and 1837 codecs (3GPP TS 26.346 version 13.3.0 Release 13)," Doc. ETSI TS 126 1838 346 v13.3.0 (2016-01), European Telecommunications Standards 1839 Institute, January 2016. 1841 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 1842 Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, 1843 https://www.rfc-editor.org/info/rfc3740. 1845 [HTTP3] M. Bishop, Ed, "Hypertext Transfer Protocol Version 3 1846 (HTTP/3)", draft-ietf-quic-http-34, February 2021. 1848 [RFC9000] Iyengar, J., Ed., and M. Thomson, Ed., "QUIC: A UDP-Based 1849 Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, 1850 May 2021, . 1852 [RFC6347] Rescorla E. and N. Modadugu. "Datagram Transport Layer 1853 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, 1854 https://www.rfc-editor.org/info/rfc6347. 1856 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 1857 A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 1858 232, RFC 8932, DOI 10.17487/RFC8932, October 2020, https://www.rfc- 1859 editor.org/info/rfc8932. 1861 [DTLS13] Rescorla, E., Tschofenig, H., Modadugu, N., "The Datagram 1862 Transport Layer Security (DTLS) Protocol Version 1.3", Work in 1863 Progress, draft-ietf-tls-dtls13, February 2022. 1865 14. Acknowledgments 1867 As outlined in the introduction and in ROUTE concepts in Section 9, 1868 the concepts specified in this document are the culmination of the 1869 collaborative work of several experts and organizations over the 1870 years. The authors would especially like to acknowledge the work and 1871 efforts of the following people and organizations to help realize the 1872 technologies described in this document (in no specific order): Mike 1873 Luby, Kent Walker, Charles Lo, and other colleagues from Qualcomm 1874 Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&D. 1876 Authors' Addresses 1878 Waqar Zia 1879 Qualcomm CDMA Technologies GmbH 1880 Anzinger Str. 13, 81671, Munich, Germany 1881 Email: wzia@qti.qualcomm.com 1883 Thomas Stockhammer 1884 Qualcomm CDMA Technologies GmbH 1885 Anzinger Str. 13, 81671, Munich, Germany 1886 Email: tsto@qti.qualcomm.com 1888 Lenaig Chaponniere 1889 Qualcomm Technologies Inc. 1890 5775 Morehouse Drive 1891 San Diego, California 92121 1892 USA 1893 Email: lguellec@qti.qualcomm.com 1895 Giridhar Mandyam 1896 Qualcomm Technologies Inc. 1897 5775 Morehouse Drive 1898 San Diego, California 92121 1899 USA 1900 Email: mandyam@qti.qualcomm.com 1902 Michael Luby 1903 BitRipple, Inc. 1904 1133 Miller Ave 1905 Berkeley CA 94708 1906 USA 1907 Email: luby@bitripple.com