idnits 2.17.1 draft-bichot-msync-04.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 (May 2, 2022) is 718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft S. Bale 3 Intended Status: Informational R. Brebion 4 Expires: November 3, 2022 G. Bichot 5 Broadpeak 6 May 2, 2022 8 MSYNC 9 draft-bichot-msync-04 11 Abstract 13 This document describes the Multicast Synchronization (MSYNC) 14 Protocol that aims at transferring video media objects over IP 15 multicast operating preferably RTP. Although generic, MSYNC has been 16 primarily designed for transporting HTTP adaptive streaming (HAS) 17 objects including manifest/playlists and media segments (e.g. MP4, 18 CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH 19 between a multicast server and a multicast gateway. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. MSYNC Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. MSYNC Packet Format . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Object Info Packet . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Object Data Packet . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Object HTTP Header Packet . . . . . . . . . . . . . . . . . 9 68 3.5. Object Data-part Packet . . . . . . . . . . . . . . . . . . 10 69 3.6. Maximum Size Of A MSYNC Packet . . . . . . . . . . . . . . 11 70 3.7. Sending MSYNC Objects Over IP/Transport Multicast 71 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.8. HAS Protocol Dependency . . . . . . . . . . . . . . . . . . 13 73 3.8.1. Object Info Packet . . . . . . . . . . . . . . . . . . 13 74 3.8.1.1. Media Sequence . . . . . . . . . . . . . . . . . . 13 75 3.8.1.2. Object URI . . . . . . . . . . . . . . . . . . . . 14 76 3.8.2. Sending Rules . . . . . . . . . . . . . . . . . . . . . 15 77 3.9. RTP As The Transport Multicast Session Protocol . . . . . . 15 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 5.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1 Introduction 89 MSYNC relies preferably on RTP that makes it particularly suited for 90 transitioning IPTV legacy (MPEG2 TS/RTP) to the HAS ecosystem. MSYNC 91 is simple (no flow control, no forward error correction) although 92 reliable, flexible and extensible; it has been experimented and 93 deployed over IPTV infrastructure (xDSL, cable, fiber) and 94 satellite. 96 1.1 Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 1.2 Definitions 104 manifest: A file gathering the configuration for conducting a 105 streaming session; corresponds to a play list as defined by HLS 106 [RFC8216]. During a HAS streaming session, a manifest or 107 playlist can be modified. 109 media chunk: A piece of a media segment of a fixed duration as 110 specified in [MPEGCMAF]. 112 media segment: A piece of a media sub-stream of a fixed duration 113 (e.g. 2s) as specified in [MPEGCMAF]. 115 init segment: A piece of a media sub-stream used to initialize the 116 decoder as specified in [MPEGCMAF]. 118 media: A digitalized piece of video, audio, subtitle, image, .... 120 media stream: Gathers one or more media sub-streams. 122 media sub-stream: A version of a media encoded in a particular bit- 123 rate, format and resolution; also called representation or 124 variant stream. 126 variant stream : A media sub-stream as defined by HLS [RFC8216]; 127 corresponds to a representation as defined by [MPEGDASH]. 129 representation: A media sub-stream as defined by [MPEGDASH]; 130 Corresponds to a variant stream as defined by HLS [RFC8216]. 132 HTTP Adaptive Streaming (HAS) session: Transport one or more media 133 streams (e.g. one video, two audios, One subtitle) according to 134 HTTP. A HAS session is triggered by a player downloading first a 135 manifest file(s), then init and/or media segments (belonging to 136 possibly different sub-streams according to the selected 137 representation) and possibly more manifest files according to 138 the HAS protocol. 140 MSYNC object: As part of a HAS session carried over MSYNC, an MSYSNC 141 object can be an addressable HAS entity like an init segment, a 142 media segment (or fragment, or chunk), a manifest. An MSYNC 143 object can also be a non-addressable transport entity like a 144 part of a segment (an HTTP2 frame or an HTTP 1.1 CTE block). As 145 part of the control channel, an MSYNC object may transport some 146 control plane information (for the receiver as e.g. the 147 multicast gateway configuration). An MSYNC object is typically 148 associated with metadata (aka info), data and possibly an HTTP 149 header. 151 MSYNC packet: The transport unit of MSYNC. Several MSYNC packets mays 152 be used to transport an MSYNC object. 154 transport multicast session: Operating a transport protocol that is 155 (possibly based on) UDP over IP multicast. A session is 156 identified by the transport (UDP) port number, the source IP 157 address and the IP multicast address. 159 RTP multicast session: A transport multicast session based on RTP as 160 defined in [RFC3550]. 162 IP multicast session: A session gathering transport multicast 163 sessions having the same source IP address and destination 164 multicast IP address. 166 MSYNC channel: The set of transport multicast sessions carrying a HAS 167 session as a set of MSYNC objects. 169 MSYNC control channel: the transport multicast session carrying 170 control plane MSYNC objects. 172 2. Overview 174 MSYNC is a simple protocol typically used between a multicast server 175 (the MSYNC sender) and a multicast gateway (the MSYNC receiver). The 176 multicast server gets ingested with a unicast HAS session conforming 177 to a HAS protocol as e.g. MPEG DASH [MPEGDASH] or HLS [RFC8216] and 178 sends the HAS session elements over a broadcast/multicast link 179 according to MSYNC supporting [possibly RTP/] UDP/IP multicast up to 180 the multicast gateway(s) that serve the HAS player(s) in unicast 181 conforming to the same HAS protocol. MSYNC can serve simultaneously 182 multiple gateways conforming to one or several HAS protocols and 183 formats. 185 The Multicast server is configured in order to get the unicast HAS 186 feeds. Considering one among several possible ingest methods (e.g. 187 HTTP GET), for each ingested feed, the multicast server behaves as a 188 sort of player, reading the manifest, discovering the available 189 representations and downloading concurrently media segments of all 190 (or a subset) of the available representations. Finally the multicast 191 server is configured for sending all those HAS session elements over 192 [possibly RTP/]UDP/IP multicast according to a certain UDP flow 193 arrangement (for example all the objects related to each video 194 representation are sent over a separate multicast transport session 195 (multicast IP address + port number) whereas all audio 196 representations are sent over the same transport multicast session. 198 The multicast gateway is configured accordingly in order to be 199 attached to the transport multicast sessions (in particular, it has 200 to subscribe to the corresponding multicast IP group address). Note 201 that the multicast gateway might not be capable of being attached to 202 all the concurrent transport multicast sessions in the same time per 203 bandwidth restriction (e.g. ADSL). In that case, the multicast 204 gateway attaches to the transport multicast session corresponding to 205 the player's request (and detaches from the other previous one). 207 At any time, the multicast gateway can detect corrupted and lost 208 packets and attempt to repair using a repair protocol. This is 209 possible thanks to the RTP protocol if used as the transport layer 210 over UDP . 212 The multicast gateway receives the MSYNC objects and is ready to 213 serve it (e.g. feeds a local cache). Whenever a HAS request is sent 214 by a media player and received by the multicast gateway, the latter 215 reads first its local cache. In case of cache hit, it returns the 216 object. In case of cache miss, the multicast gateway can possibly 217 retrieve the requested object from the associated CDN (or a dedicated 218 server) over an unicast interface (if existing) through operating 219 HTTP conventionally and forwards back to the media player the object 220 once retrieved. 222 With MSYNC deployed over a multicast link/network, the end user media 223 player gets basically the HAS content in full transparency (i.e. the 224 player is absolutely unaware of getting the content through MSYNC or 225 not). 227 Note that nothing precludes the multicast gateway to be co-located 228 with the media player and therefore embedded in the end-user 229 terminal. 231 Note that nothing precludes application dependent features in the 232 multicast server and/or the multicast gateway that may adapt/modify 233 the content delivered to the end-user player. 235 3. MSYNC Protocol 237 3.1. MSYNC Packet Format 239 The MSYNC packet has the following format. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | version | packet type | object identifier | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | sub-header | 247 | .... | 248 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 249 | data | 250 | .... | 252 version: 8 bits 253 version of the MSYNC protocol = 0x3 255 packet type: 8 bits 256 Defines the MSYNC packet type. The sub-header and the associated 257 data (if any) are dependent on the packet type. The following 258 types are defined. 259 0x01: object info 260 0x02: object info redundancy packet 261 0x03: object data 262 0x04: Reserved 263 0x05: object http header 264 0x06: object data-part as a piece of an object data for 265 transporting e.g. an MPEG CMAF chunk, an HTTP 1.1 chunk or yet 266 an HTTP2 frame. 268 object identifier: 16 bits 269 The field identifies the object being transferred. All MSYNC 270 packets associated with the same object carry the same object 271 identifier in their MSYNC packet header. 273 sub-header: series of N x 32 bits 274 The packet sub-header is linked to the packet type. The details of 275 each packet type is given in the next sections. 277 data: series of D x 8 bits 278 This field is optional and is present depending on the packet 279 type. D is bounded by the maximum size of a transport multicast 280 session protocol packet size and the MTU (Maximum Transfer Unit) 281 otherwise as depicted in 3.6. 283 3.2. Object Info Packet 285 The Object info packet is used to transport the meta-data 286 associated with an object. It permits to characterize the object 287 in term of e.g. size and type. The object information is carried 288 over one object info packet only. The object info packet is 289 typically sent along with the object data it describes. 291 The object identifier corresponds to the object identifier of the 292 object data packets or the object data-part packets the object 293 info packet relates to. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | version | 0x1 or 0x2 | object identifier | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | object size | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | number of MSYNC packets | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | object CRC | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | object type | Reserved | mtype | object URI size | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | media sequence | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 | object URI | 312 : : 313 : : 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 object size: 32 bits 318 The number of bytes that compose the object payload transported 319 with a MSYNC object data packet (Section 3.3) or MSYNC object 320 data-part packet (Section 3.5). The size may be 0 indicating that 321 there is no corresponding object's payload transmission foreseen 322 (i.e. no expected MSYNC data or MSYNC data-part packets) . In case 323 of a super object transmission (Section 3.5), If the object URI of 324 an object info with an object size set to 0 matches the super 325 object URI then it MUST be interpreted as the end of the super 326 object transmission (Section 3.8.1.2). 328 number of MSYNC packets: 32 bits 329 Number of MSYNC packets that compose the transported object. If 330 the object size is null (set to 0) then the number of MSYNC 331 packets MUST be null (set to 0). 333 object CRC: 32 bits 334 A CRC applied to the object data payload for corruption detection. 336 mtype: 4 bits 337 The manifest (playlist) type, the MSYNC INFO is compatible with. 338 The field can take the following values. 339 0x00: Not Applicable 340 0x01: MPEG Dash as specified in [MPEGDASH]. 341 0x02: HLS as specified in [RFC8216]. 342 0x03-0xF: Reserved 344 object URI size: 12bits 345 The size in bytes of the object URI field. The value MUST 346 guarantee that the MSYNC info packet size is not greater than the 347 network MTU. 349 object type : 8 bits 350 Defines the type of MSYNC data object associated with this MSYNC 351 info packet 352 0x00: Reserved 353 0x01: media manifest (playlist) 354 0x02: Reserved 355 0x03: media data or data-part: Transport stream (MPEG2-TS) 356 0x04: media data or data-part: MPEG4 (CMAF) 357 0x05: control: control plane information (e.g. multicast gateway 358 configuration) 359 0x06-0xFF: Reserved 361 media sequence: 32 bits 362 It is a sequence number associated with the MSYNC object data 363 (segment or manifest). It is dependent on the mtype value. It is 364 used to synchronize unicast and multicast receptions in the 365 multicast gateway. The values and rules are detailed in the 366 section 3.8 dedicated to the HAS protocol dependencies. The 367 default value is 0x00. 369 object URI: Quotient(object URI size/32) bits 370 This the path name associated with the object. It MAY corresponds 371 to a storage/Cache path. There SHOULD be a direct relationship 372 between this URI and the URL associated with the addressable 373 object (e.g. HAS segment or CMAF chunk and/or a manifest). The 374 rules are detailed in the section 3.8 dedicated to the HAS 375 protocol dependencies. 377 3.3. Object Data Packet 379 This MSYNC packet carries part or all of the the object's data 380 payload. The type of data and the way to process the object's data 381 packets is function of the associated object's info packet. Object 382 payload is transported through a series of object data packets. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | version | 0x3 | object identifier | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | object offset | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | data | 392 : : 393 : : 395 object offset: 32 bits 396 The index from which the MSYNC object data packet payload is to be 397 written in order to compose the object data at the receiver side 398 (i.e. the multicast gateway). The first data packet of an object 399 has an offset equal to 0. 401 data: N x 8bits 402 The size N is not declared; it is bounded by the maximum size of 403 the under-laying transport multicast session packet (e.g. RTP) as 404 depicted in Section 3.6. The total size (number of bytes) of the 405 object data is indicated in the associated object info (field 406 object size). 408 3.4. Object HTTP Header Packet 410 The HTTP header packet carries part or all of an HTTP header 411 related to the object (data) to be sent. There is at most one HTTP 412 header per object that can be repeated. 414 The object identifier is the same than the one present in the 415 object data packets or object data-part packets it relates to. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | version | 0x5 | object identifier | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | header size | header offset | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | data | 425 : : 426 : : 428 header size: 16 bits 429 An object HTTP header can be transported over one or several 430 under-laying transport packets. This field indicates the total 431 size of the HTTP header in bytes and it is indicated in each the 432 HTTP header's packet. 434 header offset: 16 bits 435 The index from which this HTTP header MSYNC packet payload data is 436 to be written in order to complement the HTTP header at the 437 receiver side (i.e the multicast gateway). The first packet of the 438 HTTP header has an offset equal to 0. 440 data: N x 8bits 441 The size N is not declared; it is bounded by either the header 442 size field value or by the maximum size of the under-laying 443 transport packet(e.g. RTP)as depicted in Section 3.6. 445 3.5. Object Data-part Packet 447 This MSYNC packet carries part or all of the media data-part 448 object payload. The type of data and the way to process the 449 object's data-part packets is function of the associated info 450 packet. Object payload is transported through a series of object 451 data-part packets. The data-part is used when the object 452 corresponds to a "part" (a block) of a super object for which the 453 size is unknown (a super object may correspond to a stream or a 454 media segment not yet complete and for which the size is therefore 455 unknown). 457 All data-part packets belonging to the same data part object have 458 the same object identifier that is the same one present in the 459 object info packet and HTTP header (if any) packets the data-part 460 object relates too. 462 All data-part objects composing a super object have a different 463 object identifier. The way to link data-part objects with a super 464 object is thanks to the object info packet (object URI) as 465 explained in Section 3.8.1.2. 467 The end of super-object transmission is signaled with an object 468 info packet having both the object size and the number of MSYNC 469 packets set to 0 and having the object URI matching the object URI 470 of the already received parts according to Section 3.8.1.2. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | version | 0x6 | object identifier | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | object offset | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | super object offset | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | data | 482 : : 483 : : 485 object offset: 32 bits 486 The index from which the data-part packet payload is to be written 487 in order to compose the object data-part at the receiver side 488 (i.e. the multicast gateway). The first packet of the data-part 489 has an offset equal to 0. 491 super object offset: 32 bits 492 The index from which the object part-data packet payload is to be 493 written in order to compose the super object data at the receiver 494 side (i.e. the multicast gateway). The first data-part object 495 composing a super object has the super object offset equal to 0. 496 The super object offset is the same for all object data-part 497 packets composing the same object data-part. 499 data: N x 8bits 500 The size N is not declared; it is bounded by the maximum size of 501 the under-laying transport packet (e.g. RTP) as depicted in the 502 section 3.6. The total size (number of bytes) of the object data 503 is indicated in the associated object info (field object size). 505 3.6. Maximum Size Of A MSYNC Packet 507 An MSYNC packet is composed with a header part and a data part for 508 which the size is bounded by the transport multicast session 509 packet. In case there is no particular restriction as with RTP 510 and/or UDP (which authorize up to 65235 bytes), then the maximum 511 size is linked to the path MTU (Maximum Transfer Unit) as the 512 largest transfer unit supported between the source (the multicast 513 server) and the destination (the multicast gateway) without 514 fragmentation. An MSYNC packet MUST fit within a link layer 515 packet. 516 For Ethernet, as an example, the MTU is typically 1500 bytes, 517 assuming a 20 bytes IPv4 header, a 8 bytes UDP header and the 8 518 bytes MSYNC object data packet header, it gives an MTU of 1464 519 bytes for the MSYNC object data packet. Operating RTP, the MSYNC 520 object data MTU is decreased by 12 bytes (= 1452 bytes). 522 3.7. Sending MSYNC Objects Over IP/Transport Multicast Sessions 524 The following considerations are linked to the multicast server 525 configuration. 527 Per MSYNC channel, the way to map MSYNC objects related to a media 528 stream with an IP or transport multicast session is not 529 constrained. The arrangement is chosen function of the network 530 architecture and capacity. For example, in xDSL, the capacity 531 dedicated to multicast is limited which may drive to an 532 arrangement where each sub-stream/representation of a HAS 533 session/MSYNC channel matches with one dedicated IP multicast 534 session. The MSYNC receiver switches to the IP transport session 535 corresponding to the sub-stream/representation it should serve to 536 the user terminal/player. Alternatively, one would like to have 537 one IP multicast session (with possibly multiple transport 538 multicast sessions, each having a different destination port 539 number) for the entire HAS session/MSYNC channel that is an 540 arrangement a la "IPTV", less bandwidth efficient but where only 541 one multicast IP address is allocated per HAS session/MSYNC 542 channel. 544 Considering a satellite network, as all transport multicast 545 sessions are carried simultaneously, all arrangements may make 546 sense. 548 Regarding the mapping with a transport multicast session, the 549 triplet: source IP address, destination multicast IP address and 550 destination transport port number is the discriminator. It is 551 recommended to carry media sub-streams and the control channel in 552 separate transport multicast channels. It facilitates potential 553 error correction procedures. 555 The following granularity is possible: 557 - One IP multicast session per media (audio or video or 558 subtitle) sub-stream (representation); each transport multicast 559 session having a different destination multicast IP address. 561 - One transport multicast session for the MSYNC control channel. 563 - It is perfectly possible to send all the MSYNC packets in only 564 one transport multicast session. 566 For each MSYNC object (see object type in 3.2) to be sent, the 567 sender MUST send the following MSYNC packets in the specified 568 order: one object info packet, zero or more object info redundant 569 packets, zero or more HTTP header packets and one or more object 570 data packets or object data-part packets. 572 When the MSYNC object is a media data-part object of size null 573 (used to signal the end of the transmission of a super object) 574 then only one object info packet MUST be sent. 576 3.8. HAS Protocol Dependency 578 A certain number of MSYNC packet header fields have a dependency 579 on the HAS protocol and therefore on the manifest type. Similarly 580 the sending rules may also depend from the HAS protocol. 582 3.8.1. Object Info Packet 584 3.8.1.1. Media Sequence 586 The media sequence is used by the multicast gateway to synchronize 587 the MSYNC (i.e. multicast) reception with unicast reception. The 588 multicast gateway may operate jointly MSYNC and unicast retrieval 589 of HAS objects. This is useful in some occasions like processing a 590 new streaming session request (i.e. a manifest request after a 591 channel switch) or in the case of segment repair. The multicast 592 gateway may attempt to retrieve a manifest object or segment(s) 593 through a unicast mean (e.g. a CDN server or a repair server) in 594 order to speed up the start of the session or to repair damaged 595 object(s). Consequently, the multicast gateway needs to understand 596 the freshness of the HAS object received through multicast with 597 regard to unicast. 599 If no unicast reception is used jointly with MSYNC in the 600 multicast gateway (e.g. like in one way delivery only), the 601 default value MAY be used: 0x00 603 HLS master playlist: 0x00 605 HLS variant playlist; MUST contain the value of EXT-X-MEDIA-SEQUENCE 606 added with the position in the playlist of the last segment 607 transmitted. 609 HLS segment: MUST contain the value of EXT-X-MEDIA-SEQUENCE added 610 with the position of the segment in the playlist. 612 DASH manifest: MUST contain $time$/scale or $Number$ corresponding to 613 the last segment transmitted or under transmission (and possibly 614 received partially) and declared by the manifest. 616 DASH segment: MUST contain the $time$/scale or $Number$ value 618 3.8.1.2. Object URI 620 In the context of HTTP adaptive streaming, The object URI is a URI 621 reference. 623 if the object is a HAS addressable entity (e.g. a segment or a 624 CMAF chunk), the object URI MUST match (be a sub-string) with the 625 URL announced in the corresponding manifest/playlist. 627 Examples: 629 - The object URI: /tvChannel1/Q1/S_2 matches with the segment's 630 URL that is computed from the associated manifest/playlist: 631 ".../tvChannel1/Q1/S_2.mp4" 633 - The object URI /tvChannel11/Q1/S_2_3 matches with the CMAF 634 chunk URL that is computed from the associated 635 manifest/playlist: ".../tvChannel11/Q1/S_2_3.mp4". 637 If the object is a non-addressable HAS entity (e.g. a HTTP 1.1 CTE 638 block), the object URI is composed with a sub-string (that MUST 639 match with the URL announced in the corresponding manifest) and a 640 suffix composed with the underscore character and the block 641 number). 643 Example: 645 - The object URI of the 3rd HTTP CTE block of the segment S_2: 646 tvChannel11/Q1/S_2.m4s_2 matches with the segment's request URL 647 that terminates with ".../tvChannel1/Q1/S_2.m4s" 649 The block number of an object URI attached to a media data-part 650 object MUST be incremented for each subsequent transmission. 652 When all the MSYNC data-part packets for all the media data-part 653 objects (e.g. CTE blocks) composing a super object (e.g. a media 654 segment) have been sent, the MSYNC sender MUST signal the end of 655 the MSYNC super object transmission through sending an MSYNC 656 object info packet with the object size set to zero (0) . In 657 addition, the object URI MUST contain the URI reference of the 658 next block (never transmitted). see 3.2. 660 Example: 662 - The object URI of the object info packet associated with the 663 1st HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_0 665 - The object URI of the object info packet associated with the 666 2nd HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_1 668 - The object URI of the object info packet associated with the 669 3rd HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_2 671 - The object URI of the object info packet associated with the 672 4st HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_3 674 - The object URI of the object info packet associated with the 675 5st HTTP CTE block (of size null) signaling the end of the super 676 object (i.e. segment) transmission: tvChannel11/Q1/S_2.m4s_4 678 3.8.2. Sending Rules 680 Whenever a manifest (playlist) has to be sent: 682 - The manifest (playlist) object MUST be sent within (duplicated 683 in) all the transport multicast sessions related to the 684 transmission of the video segment objects the manifest/playlist 685 refers to. 687 - It MUST reference addressable objects (segment or CMAF chunk) 688 that have already been sent or for which the transmission has 689 started. 691 3.9. RTP As The Transport Multicast Session Protocol 693 RTP [RFC3550] can be used as part of the transport multicast 694 session protocol. Depending on the deployment case (e.g. 695 unidirectional) and the infrastructure in place, the companion 696 RTCP protocol MUST be operated according to the following. 698 - RTCP usage SHALL conform to [RFC5506] 700 - RTCP sender report MAY be switched off 701 - RTCP receiver report MAY be switched off 703 - RCTP destination port number is configurable but it MUST be 704 different than the associated RTP destination port number, i.e. 705 the RTCP destination port number is not necessarily the RTP 706 destination port number + 1 as recommended in [RFC3550]. 708 - RTCP MAY be used for packet loss recovery (aka "RTP Repair"). 709 If packet loss recovery through RTCP is activated then the RTP 710 Repair client and server MUST be compliant with [RFC4585] and 711 [RFC5506]. The RTP Repair client that submit the feedback (FB) 712 messages (according to [RFC5506] and [RFC4585] is the MSYNC 713 receiver (i.e. the multicast gateway). The RTP Repair server 714 that receives, processes and responds to the feedback messages 715 (FB) MAY be the MSYNC sender (i.e. the multicast server) or it 716 MAY be any intermediate entity acting as a multicast RTP 717 receiver (i.e. capable of receiving the multicast RTP packets). 718 In any case, the RTP Repair server and the RTP Repair client 719 MUST operate a unicast interface. 721 Note that instead of relying on "RTP repair", an MSYNC receiver 722 (i.e. the multicast gateway) could attempt to recover HAS 723 elements (segments, manifest) through HTTP (aka "HTTP repair"). 724 However the latter method requires a CDN and is less reactive 725 than operating RTCP. 727 In addition, each RTP multicast session MUST operate a different 728 [RFC3550] SSRC number. This guaranties a reparation on the RTP 729 transport multicast session basis. 731 -RTCP MAY be used for Fast Channel change according to 732 [RFC6585]. The way to operate [RFC6585] is out of scope of this 733 document. 735 4. IANA Considerations 737 This document has no actions for IANA. 739 5. Security Considerations 741 The multicast communication between the MSYNC sender (multicast 742 server) and the MSYNC receiver (the multicast gateway) SHOULD be 743 protected for confidentiality, message corruption and replay 744 attacks. The MSYNC protocol does not specify any security 745 mechanism. MSYNC relies on possibly content protection (Digital 746 Right Management) and on the underlying transport layer and 747 security extensions for providing message 748 integrity/authentication and replay. Secure RTP (SRTP) [RFC3711] 749 and IPSec applied to multicast [RFC5374] are potential 750 candidates for providing such extensions. 752 5. References 754 5.1. Normative References 756 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. 757 S. Bradner. March 1997. (Format: TXT, HTML) (Updated by 758 RFC8174) (Also BCP0014) (Status: BEST CURRENT PRACTICE) 759 (DOI: 10.17487/RFC2119) 761 [RFC3550] RTP: A Transport Protocol for Real-Time Applications. H. 762 Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 763 2003. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1889) 764 (Updated by RFC5506, RFC5761, RFC6051, RFC6222, RFC7022, 765 RFC7160, RFC7164, RFC8083, RFC8108) (Also STD0064) 766 (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3550) 768 [MPEGDASH] "Information technology - Dynamic adaptive streaming over 769 HTTP (DASH) - Part1:Media presentation description and 770 segment formats",ISO/IEC23009-1 772 [MPEGCMAF] "Information technology - Multimedia application format 773 (MPEG-A) - Part 19:Common media application format (CMAF) 774 for segmented media"ISO/IEC 23000-19 776 [RFC5506] Support for Reduced-Size Real-Time Transport Control 777 Protocol(RTCP): Opportunities and Consequences. I. 778 Johansson, M. Westerlund. April 2009. (Format: TXT, HTML) 779 (Updates RFC3550, RFC3711, RFC4585)(Status: PROPOSED 780 STANDARD) (DOI: 10.17487/RFC5506) 782 [RFC4585] Extended RTP Profile for Real-time Transport Control 783 Protocol(RTCP)-Based Feedback (RTP/AVPF). J. Ott, S. 784 Wenger, N. Sato, C. Burmeister, J. Rey. July 2006. 785 (Format: TXT, HTML) (Updated by RFC5506, RFC8108) (Status: 786 PROPOSED STANDARD) (DOI:10.17487/RFC4585) 788 5.2. Informative References 790 [RFC3711] The Secure Real-time Transport Protocol (SRTP). M. Baugher, 791 D. McGrew, M. Naslund, E. Carrara, K. Norrman. March 2004. 792 (Format: TXT, HTML) (Updated by RFC5506, RFC6904) (Status: 793 PROPOSED STANDARD) (DOI: 10.17487/RFC3711) 795 [RFC5374] Multicast Extensions to the Security Architecture for the 796 Internet Protocol. B. Weis, G. Gross, D. Ignjatic. 797 November 2008. (Format: TXT, HTML) (Status: PROPOSED 798 STANDARD) (DOI: 10.17487/RFC5374) 800 [RFC6585] Unicast-Based Rapid Acquisition of Multicast RTP Sessions. 801 B. VerSteeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011. 802 (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 803 10.17487/RFC6285) 805 [RFC8216] HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017. 806 (Format:TXT, HTML) (Status: INFORMATIONAL) (DOI: 807 10.17487/RFC8216) 809 6. Acknowledgments 811 The authors will be ever grateful to their late colleague Arnaud 812 Leclerc who has been the initiator of that work. 814 The authors would like to thank the following people for their 815 feedback: Yann Barateau (Eutelsat). 817 7. Change Log 819 - 04: Added detection of super object transmission (Section 3.2 820 and Section 3.8.1.2); several adjustments regarding RFC style; 821 Section numbering correction.(Sections 3.9 and 3.10 are now 822 section 3.8 and 3.9 respectively). 824 Authors' Addresses 826 Sophie Bale 827 Broadpeak 828 15 rue Claude Chappe 829 Zone des Champs Blancs 830 35510 Cesson-Sevigne 831 France 833 Email: sophie.bale@broadpeak.tv 835 Remy Brebion 836 Broadpeak 837 15 rue Claude Chappe 838 Zone des Champs Blancs 839 35510 Cesson-Sevigne 840 France 842 Email: remy.brebion@broadpeak.tv 844 Guillaume Bichot (Editor) 845 Broadpeak 846 15 rue Claude Chappe 847 Zone des Champs Blancs 848 35510 Cesson-Sevigne 849 France 851 Email: guillaume.bichot@broadpeak.tv