idnits 2.17.1 draft-bichot-msync-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 209 has weird spacing: '....g. the media...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ISOBMFF' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'HLS-LL' is defined on line 757, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEGDASH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEGCMAF' == Outdated reference: A later version (-14) exists of draft-pantos-hls-rfc8216bis-07 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft S. Bale 3 Intended Status: Standards track R. Brebion 4 Expires: April 16 2021 G. Bichot 5 Broadpeak 6 October 13 2020 8 MSYNC 9 draft-bichot-msync-00 11 Abstract 13 This document describes the Multicast Synchronisation (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) 2020 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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.8. Mapping player request with IP/transport multicast 73 sessions . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.9. HAS protocol dependency . . . . . . . . . . . . . . . . . . 13 75 3.9.1. Object info packet . . . . . . . . . . . . . . . . . . 13 76 3.9.1.1. media sequence . . . . . . . . . . . . . . . . . . 13 77 3.9.1.3. object URI . . . . . . . . . . . . . . . . . . . . 14 78 3.9.2. Sending rules . . . . . . . . . . . . . . . . . . . . . 14 79 3.10. RTP as the transport multicast session protocol . . . . . 15 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 5.1. Normative References . . . . . . . . . . . . . . . . . . . 16 83 5.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 RFC 2119 [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 terminals 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 The multicast gateway then receives the corresponding MSYNC objects 208 and feeds a local cache. Whenever a HAS request is sent by a user 209 terminal (e.g. the media player) and received by the multicast 210 gateway, the latter reads first its local cache. In case of cache 211 hit, it returns the object. In case of cache miss, the multicast 212 gateway can retrieve the requested object from the associated CDN (or 213 a dedicated server) over an unicast interface (if existing) through 214 operating HTTP conventionally and forwards back to the terminal the 215 object once retrieved. 217 At any time, the multicast gateway can detect corrupted and lost 218 packets and attempt to repair using a repair protocol. This is 219 possible thanks to the RTP protocol if used as the transport layer 220 over UDP. 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). This said nothing precludes application dependent features in 226 the multicast server and/or the multicast gateway that may 227 adapt/modify the content delivered to the end-user player. Depending 228 on the deployment, some differences in term of quality of service may 229 be observed. For instance, as being deployed over a managed multicast 230 capable network, MSYNC ensures a more stable transport than going 231 full "Over The Top" (OTT). 233 3. MSYNC Protocol 235 3.1. MSYNC packet format 237 The MSYNC packet has the following format. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | version | packet type | object identifier | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | sub-header | 245 | .... | 246 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 247 | data | 248 | .... | 250 version: 8 bits 251 version of the MSYNC protocol = 0x3 253 packet type: 8 bits 254 Defines the MSYNC packet type. The sub-header and the associated 255 data (if any) are dependent on the packet type. The following 256 types are defined. 257 0x01: object info 258 0x02: object info redundancy packet 259 0x03: object data 260 0x04: Reserved 261 0x05: object http header 262 0x06: object data-part as a piece of an object data for 263 transporting e.g. an MPEG CMAF chunk, an HTTP 1.1 chunk or yet 264 an HTTP2 frame. 266 object identifier: 16 bits 267 The field identifies the object being transferred. All MSYNC 268 packets associated with the same object carry the same object 269 identifier in their MSYNC packet header. 271 sub-header: series of N x 32 bits 272 The packet sub-header is linked to the packet type. The details of 273 each packet type is given in the next sections. 275 data: series of D x 8 bits 276 This field is optional and is present depending on the packet 277 type. D is bounded by the maximum size of a transport multicast 278 session protocol packet size and the MTU (Maximum Transfer Unit) 279 otherwise as depicted in 3.6. 281 3.2. Object info packet 283 The Object info packet is used to transport the meta-data 284 associated with an object. It permits to characterize the object 285 in term of e.g. size and type. The object information is carried 286 over one object info packet only. The object info packet is 287 typically sent along with the object data it describes. 289 The object identifier corresponds to the object identifier of the 290 object data packets or the object data-part packets the object 291 info packet relates to. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | version | 0x1 or 0x2 | object identifier | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | object size | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | number of MSYNC packets | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | object CRC | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | mtype | object URI size | Reserved | object type | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | media sequence | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 | object URI | 310 : : 311 : : 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 object size: 32 bits 316 The number of bytes that compose the transported object. 318 number of MSYNC packets: 32 bits 319 Number of MSYNC packets that compose the transported object. 321 object CRC: 32 bits 322 A CRC applied to the object data payload for corruption detection. 324 mtype: 4 bits 325 The manifest (playlist) type, the MSYNC INFO is compatible with. 326 The field can take the following values. 327 0x00: Not Applicable 328 0x01: MPEG Dash as specified in [MPEGDASH]. 329 0x02: HLS as specified in [RFC8216]. 330 0x03-0xF: Reserved 332 object URI size: 12bits 333 The size in bytes of the object URI field. The value must 334 guarantee that the MSYNC info packet size is not greater than the 335 network MTU. 337 object type : 8 bits 338 Defines the type of MSYNC data object associated with this MSYNC 339 info packet 340 0x00: Reserved 341 0x01: media manifest (playlist) 342 0x02: Reserved 343 0x03: media data or data-part: Transport stream (MPEG2-TS) 344 0x04: media data or data-part: MPEG4 (CMAF) 345 0x05: control: control plane information (e.g. multicast gateway 346 configuration) 347 0x06-0xFF: Reserved 349 media sequence: 32 bits 350 It is a sequence number associated with the MSYNC object data 351 (segment or manifest). It is dependent on the mtype value. It is 352 used to synchronize unicast and multicast receptions in the 353 multicast gateway. The values and rules are detailed in the 354 section 3.9 dedicated to the HAS protocol dependencies. The 355 default value is 0x00. 357 object URI: Quotient(object URI size/32) bits 358 This the path name associated with the object. It may corresponds 359 to the storage path in the multicast gateway. There MUST be a 360 direct relationship between this URI and the URL associated with 361 an addressable HAS object (segment or CMAF chunk) and/or a 362 manifest request received by the multicast gateway from the 363 terminal/media player. The rules are detailed in the section 3.9 364 dedicated to the HAS protocol dependencies. 366 3.3. Object data packet 368 This MSYNC packet carries part or all of the the object's data 369 payload. The type of data and the way to process the object's data 370 packets is function of the associated object's info packet. Object 371 payload is transported through a series of object data packets. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | version | 0x3 | object identifier | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | object offset | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | data | 381 : : 382 : : 384 object offset: 32 bits 385 The index from which the MSYNC object data packet payload is to be 386 written in order to compose the object data at the receiver side 387 (i.e. the multicast gateway). The first data packet of an object 388 has an offset equal to 0. 390 data: N x 8bits 391 The size N is not declared; it is bounded by the maximum size of 392 the under-laying transport multicast session packet (e.g. RTP) as 393 depicted in the section 3.6. The total size (number of bytes) of 394 the object data is indicated in the associated object info (field 395 object size). 397 3.4. Object HTTP header packet The HTTP header packet carries part or 398 all of an HTTP header related to the object (data) to be sent. 399 There is at most one HTTP header per object that can be repeated. 401 The object identifier is the same than the one present in the 402 object data packets or object data-part packets it relates to. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | version | 0x5 | object identifier | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | header size | header offset | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | data | 412 : : 413 : : 415 header size: 16 bits 416 An object HTTP header can be transported over one or several 417 under-laying transport packets. This field indicates the total 418 size of the HTTP header in bytes and it is indicated in each the 419 HTTP header's packet. 421 header offset: 16 bits 422 The index from which this HTTP header MSYNC packet payload data is 423 to be written in order to complement the HTTP header at the 424 receiver side (i.e the multicast gateway). The first packet of the 425 HTTP header has an offset equal to 0. 427 data: N x 8bits 428 The size N is not declared; it is bounded by either the header 429 size field value or by the maximum size of the under-laying 430 transport packet(e.g. RTP)as depicted in the section 3.6. 432 3.5. Object data-part packet 434 This MSYNC packet carries part or all of the object data-part 435 payload. The type of data and the way to process the object's 436 data-part packets is function of the associated info packet. 437 Object payload is transported through a series of object data-part 438 packets. The data-part is used when the object corresponds to a 439 "part" (a chunk) of a super object for which the size is unknown 440 (a super object may correspond to a stream or a media segment not 441 yet complete and for which the size is therefore unknown). 443 All data-part packets belonging to the same data part object has 444 the same object identifier which is the same one present in the 445 object info packet and HTTP header (if any) packets the data-part 446 object relates too. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | version | 0x6 | object identifier | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | object offset | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | super object offset | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | data | 458 : : 459 : : 461 object offset: 32 bits 462 The index from which the data-part packet payload is to be written 463 in order to compose the object data-part at the receiver side 464 (i.e. the multicast gateway). The first packet of the data-part 465 has an offset equal to 0. 467 super object offset: 32 bits 468 The index from which the object part-data packet payload is to be 469 written in order to compose the super object data at the receiver 470 side (i.e. the multicast gateway). The first data-part object 471 composing a super object has the super object offset equal to 0. 472 The super object offset is the same for all object data-part 473 packets composing the same object data-part. Having this field 474 present in the object data-part header (and not in the associated 475 object info header) permits to possibly recompose a super object 476 without the corresponding object info packet. 478 data: N x 8bits 479 The size N is not declared; it is bounded by the maximum size of 480 the under-laying transport packet (e.g. RTP) as depicted in the 481 section 3.6. The total size (number of bytes) of the object data 482 is indicated in the associated object info (field object size). 484 3.6. Maximum size of a MSYNC packet 486 An MSYNC packet is composed with a header part and a data part for 487 which the size is bounded by the transport multicast session 488 packet. In case there is no particular restriction as with RTP 489 and/or UDP (which authorize up to 65235 bytes), then the maximum 490 size is linked to the path MTU (Maximum Transfer Unit) as the 491 largest transfer unit supported between the source (the multicast 492 server) and the destination (the multicast gateway) without 493 fragmentation. An MSYNC packet must fit within a link layer 494 packet. 495 For Ethernet, as an example, the MTU is typically 1500 bytes, 496 assuming a 20 bytes IPv4 header, a 8 bytes UDP header and the 8 497 bytes MSYNC object data packet header, it gives an MTU of 1464 498 bytes for the MSYNC object data packet. Operating RTP, the MSYNC 499 object data MTU is decreased by 12 bytes (= 1452 bytes). 501 3.7. Sending MSYNC objects over IP/transport multicast sessions 503 The following considerations are linked to the multicast server 504 configuration. 506 Per MSYNC channel, the way to map MSYNC objects related to a media 507 stream with an IP or transport multicast session is not 508 constrained. The arrangement is chosen function of the network 509 architecture and capacity. For example, in xDSL, the capacity 510 dedicated to multicast is limited which may drive to an 511 arrangement where each sub-stream/representation of a HAS 512 session/MSYNC channel matches with one dedicated IP multicast 513 session. The receiver (the multicast gateway) switches to the IP 514 transport session corresponding to the sub-stream/representation 515 it must serve to the user terminal/player. Alternatively, one 516 would like to have one IP multicast session (with possibly 517 multiple transport multicast sessions, each having a different 518 destination port number) for the entire HAS session/MSYNC channel 519 that is an arrangement a la "IPTV", less bandwidth efficient but 520 where only one multicast IP address is allocated per HAS 521 session/MSYNC channel. 523 Considering a satellite network, as all transport multicast 524 sessions are carried simultaneously, all arrangements may make 525 sense. 527 Regarding the mapping with a transport multicast session, the 528 triplet: source IP address, destination multicast IP address and 529 destination transport port number is the discriminator. It is 530 recommended to carry media sub-streams and the control channel in 531 separate transport multicast channels. It facilitates potential 532 error correction procedures. 534 The following granularity is possible: 536 - One IP multicast session per media (audio or video or 537 subtitle) sub-stream (representation); each transport multicast 538 session having a different destination multicast IP address. 540 - One transport multicast session for the MSYNC control channel. 542 - It is perfectly possible to send all the MSYNC packets in only 543 one transport multicast session. 545 For each MSYNC object to be sent, the sender MUST send one object 546 info packet, 0 or more object info redundant packets, zero or more 547 HTTP header packets and one or more object data packets or object 548 data-part packets. 550 The sender MUST send the object's HTTP header along with the 551 corresponding object's data to be sent through using the MSYNC 552 object data packet(s). The sender MUST send the object's HTTP 553 header along with the corresponding first object's data-part to be 554 sent through using the MSYNC object data-part packet(s) 556 Whenever a manifest (playlist) has to be sent, the manifest 557 (playlist) object MUST be sent along with (duplicated in) all the 558 transport multicast sessions related to the transmission of the 559 video segment objects the manifest/playlist refers to. 561 3.8. Mapping player request with IP/transport multicast sessions 562 The multicast gateway MUST be configured in order to associate a 563 transport multicast session with an incoming request (manifest or 564 segment). The configuration format may look like the following. 566 / --> 570 The "host" part must match exactly with the incoming request. The 571 "path" part does not need to cover the entire path but should 572 match from the beginning of the incoming "path" value. Let's 573 consider the following examples. 575 mycontentProvider.com/vChannel1/Q1/ --> @IPs1,@IPM1:3 576 mycontentProvider.com/vChannel1/Q2/ --> @IPs1,@IPM1:4 577 mycontentProvider.com/vChannel1/Q3/ --> @IPs1,@IPM2:3 578 mycontentProvider.com/vChannel2 --> @IPs1,@IPM3:2 580 The first two lines state that the player's requests associated 581 with the quality/bit-rate Q1 and Q2 can be retrieved through the 582 same IP multicast session (but through two separate transport 583 multicast sessions) whereas the third line states that the 584 quality/bit-rate Q3 is retrieved through a different IP multicast 585 session. It is assumed here that the path element "vChannel1" is 586 associated with the video segments and related 587 manifests/playlists. The last line state that all requests having 588 a "path" part of the URL that starts with vChannel2" must be 589 retrieved through one transport multicast sessions. For extracting 590 objects belonging to different qualities/bit-rates, the multicast 591 gateway must match the URL of the incoming request with the object 592 URI (as depicted in the object info packet - see 3.2). 594 3.9. HAS protocol dependency 596 A certain number of MSYNC packet header fields have a dependency 597 on the HAS protocol and therefore on the manifest type. Similarly 598 the sending rules may also depend from the HAS protocol. 600 3.9.1. Object info packet 602 3.9.1.1. media sequence 604 The media sequence is used by the multicast gateway to synchronize 605 the MSYNC (i.e. multicast) reception with unicast reception. The 606 multicast gateway may operate jointly MSYNC and unicast retrieval 607 of HAS objects. This is useful in some occasions like processing a 608 new streaming session request (i.e. a manifest request after a 609 channel switch) or in the case of segment repair. The multicast 610 gateway may attempt to retrieve a manifest object or segment(s) 611 through a unicast mean (e.g. a CDN server or a repair server) in 612 order to speed up the start of the session or to repair damaged 613 object(s). Consequently, the multicast gateway needs to understand 614 whether a HAS object received through unicast (or multicast) has 615 already been received through multicast (or unicast 616 respectively). 618 If no unicast reception is used jointly with MSYNC in the 619 multicast gateway (e.g. like in one way delivery only), the 620 default value MAY be used: 0x00 622 HLS master playlist: 0x00 624 HLS variant playlist; MUST contain the value of EXT-X-MEDIA-SEQUENCE. 626 HLS segment: MUST contain the value of EXT-X-MEDIA-SEQUENCE added 627 with the position of the segment in the playlist. 629 DASH manifest: MUST contain $time$/scale or $Number$ corresponding to 630 the last segment transmitted or under transmission (and possibly 631 received partially) and declared by the manifest. 633 DASH segment: MUST contain the $time$/scale or $Number$ value 635 3.9.1.3. object URI 637 In the context of HTTP adaptive streaming, if the object is a HAS 638 addressable entity (e.g. a segment or a CMAF chunk), the path name 639 MUST match the absolute path present in the incoming segment 640 request. 642 The segment S_2: tvChannel1/Q1/S_2. 643 The CMAF chunk C_3 of the segment S_2: tvChannel11/Q1/S_2/C_3. 645 if the object is a non-addressable HAS entity (e.g. a HTTP 1.1 CTE 646 block), the URI MUST hierarchically match with the related 647 incoming segment request. 648 The HTTP CTE 3rd chunk of the segment S_2 649 tvChannel11/Q1/S_2/3; 651 3.9.2. Sending rules 653 When a manifest/play-list is sent, it must reference addressable 654 objects (segment or CMAF chunk) that have already been sent or for 655 which the transmission has started. 657 3.10. RTP as the transport multicast session protocol 659 RTP [RFC3550] can be used as part of the transport multicast 660 session protocol. Depending on the deployment case (e.g. 661 unidirectional) and the infrastructure in place, the companion 662 RTCP protocol MUST be operated according to the following. 664 - RTCP usage SHALL conform to [RFC5506] 666 - RTCP sender report MAY be switched off 668 - RTCP receiver report MAY be switched off 670 - RCTP destination port number must be configurable but it must 671 be different than the associated RTP destination port number, 672 i.e. the RTCP destination port number is not necessarily the RTP 673 destination port number + 1 as recommended in [RFC3550]. 675 - RTCP MAY be used for packet loss recovery (aka "RTP Repair"). 676 If packet loss recovery through RTCP is activated then the RTP 677 Repair client and server MUST be compliant with [RFC4585] and 678 [RFC5506]. The RTP Repair client that submit the feedback (FB) 679 messages (according to [RFC5506] and [RFC4585] is the MSYNC 680 receiver (i.e. the multicast gateway). The RTP Repair server 681 that receives, processes and responds to the feedback messages 682 (FB) MAY be the MSYNC sender (i.e. the multicast server) or it 683 MAY be any intermediate entity acting as a multicast RTP 684 receiver (i.e. capable of receiving the multicast RTP packets). 685 In any case, the RTP Repair server and the RTP Repair client 686 MUST operate a unicast interface. 688 Note that instead of relying on "RTP repair", an MSYNC receiver 689 (i.e. the multicast gateway) could attempt to recover HAS 690 elements (segments, manifest) through HTTP (aka "HTTP repair"). 691 However the latter method requires a CDN and is less reactive 692 than operating RTCP. 694 In addition, each RTP multicast session must operate a different 695 [RFC3550] SSRC number. This guaranties a reparation on the RTP 696 transport multicast session basis. 698 -RTCP MAY be used for Fast Channel change according to 699 [RFC6585]. The way to operate [RFC6585] is out of scope of this 700 document. 702 4. Security Considerations 704 The multicast communication between the MSYNC sender (multicast 705 server) and the MSYNC receiver (the multicast gateway) should be 706 protected for confidentiality, message corruption and replay 707 attacks. The MSYNC protocol does not gather any security 708 mechanism. MSYNC relies on possibly content protection (Digital 709 Right Management) and on the underlying transport layer and 710 security extensions for providing message 711 integrity/authentication and replay. Secure RTP (SRTP) [RFC3711] 712 and IPSec applied to multicast [RFC5374] are potential 713 candidates for providing such extensions. 715 5. References 717 5.1. Normative References 719 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. 720 S. Bradner. March 1997. (Format: TXT, HTML) (Updated by 721 RFC8174) (Also BCP0014) (Status: BEST CURRENT PRACTICE) 722 (DOI: 10.17487/RFC2119) 724 [RFC3550] RTP: A Transport Protocol for Real-Time Applications. H. 725 Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 726 2003. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1889) 727 (Updated by RFC5506, RFC5761, RFC6051, RFC6222, RFC7022, 728 RFC7160, RFC7164, RFC8083, RFC8108) (Also STD0064) 729 (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3550) 731 [MPEGDASH] "Information technology - Dynamic adaptive streaming over 732 HTTP (DASH) - Part1:Media presentation description and 733 segment formats",ISO/IEC23009-1 735 [MPEGCMAF] "Information technology - Multimedia application format 736 (MPEG-A) - Part 19:Common media application format (CMAF) 737 for segmented media"ISO/IEC 23000-19 739 [RFC5506] Support for Reduced-Size Real-Time Transport Control 740 Protocol(RTCP): Opportunities and Consequences. I. 741 Johansson, M. Westerlund. April 2009. (Format: TXT, HTML) 742 (Updates RFC3550, RFC3711, RFC4585)(Status: PROPOSED 743 STANDARD) (DOI: 10.17487/RFC5506) 745 [RFC4585] Extended RTP Profile for Real-time Transport Control 746 Protocol(RTCP)-Based Feedback (RTP/AVPF). J. Ott, S. 747 Wenger, N. Sato, C. Burmeister, J. Rey. July 2006. 749 (Format: TXT, HTML) (Updated by RFC5506, RFC8108) (Status: 750 PROPOSED STANDARD) (DOI:10.17487/RFC4585) 752 5.2. Informative References 754 [ISOBMFF] "Information technology Coding of audio-visual objects - 755 Part12:ISO base media file format", ISO/IEC 14496-12 757 [HLS-LL] R. Pantos, Ed, Apple Inc., "HTTP Live Streaming 2nd Edition" 758 - draft-pantos-hls-rfc8216bis-07, Internet-Draft, 759 informational 761 [RFC3711] The Secure Real-time Transport Protocol (SRTP). M. Baugher, 762 D. McGrew, M. Naslund, E. Carrara, K. Norrman. March 2004. 763 (Format: TXT, HTML) (Updated by RFC5506, RFC6904) (Status: 764 PROPOSED STANDARD) (DOI: 10.17487/RFC3711) 766 [RFC5374] Multicast Extensions to the Security Architecture for the 767 Internet Protocol. B. Weis, G. Gross, D. Ignjatic. 768 November 2008. (Format: TXT, HTML) (Status: PROPOSED 769 STANDARD) (DOI: 10.17487/RFC5374) 771 [RFC6585] Unicast-Based Rapid Acquisition of Multicast RTP Sessions. 772 B. VerSteeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011. 773 (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 774 10.17487/RFC6285) 776 [RFC8216] HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017. 777 (Format:TXT, HTML) (Status: INFORMATIONAL) (DOI: 778 10.17487/RFC8216) 779 Acknowledgments 781 The authors would like to thank the following people for 782 their feedback: Yann Barateau (Eutelsat). 784 Authors' Addresses 786 Sophie Bale 787 Broadpeak 788 15 rue Claude Chappe 789 Zone des Champs Blancs 790 35510 Cesson-Sevigne 792 Email: sophie.bale@broadpeak.tv 794 Remy Brebion 795 Broadpeak 796 15 rue Claude Chappe 797 Zone des Champs Blancs 798 35510 Cesson-Sevigne 800 Email: remy.brebion@broadpeak.tv 802 Guillaume Bichot (Editor) 803 Broadpeak 804 15 rue Claude Chappe 805 Zone des Champs Blancs 806 35510 Cesson-Sevigne 808 Email: guillaume.bichot@broadpeak.tv