Internet-Draft S. Bale Intended Status: Informational R. Brebion Expires: June 5, 2025 G. Bichot Broadpeak December 2, 2024 MSYNC draft-bichot-msync-17 Abstract This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Bale et aL. Expires June 5, 2025 [Page 1] Internet-Draft MSYNC December 2, 2024 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. A typical MSYNC deployment . . . . . . . . . . . . . . . . 6 2.2. Unicast Networks . . . . . . . . . . . . . . . . . . . . . 8 2.3. Multicast Network and congestion avoidance . . . . . . . . 9 2.4. Handling third party content . . . . . . . . . . . . . . . 10 3. MSYNC Protocol . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. MSYNC Packet Format . . . . . . . . . . . . . . . . . . . . 12 3.2. Object Info Packet . . . . . . . . . . . . . . . . . . . . 13 3.3. Object Data Packet . . . . . . . . . . . . . . . . . . . . 16 3.4. Object HTTP Header Packet . . . . . . . . . . . . . . . . . 17 3.5. Object Data-part Packet . . . . . . . . . . . . . . . . . . 18 3.6. Maximum Size of an MSYNC Packet . . . . . . . . . . . . . . 20 3.7. Sending and Receiving MSYNC Objects . . . . . . . . . . . . 20 3.7.1. Mapping over Transport Multicast Sessions . . . . . . . 20 3.7.2. Detecting the End of an Object Reception . . . . . . . 22 3.7.3. Congestion Control . . . . . . . . . . . . . . . . . . 23 3.8. HAS Protocol Dependency . . . . . . . . . . . . . . . . . . 24 3.8.1. Object Info Packet . . . . . . . . . . . . . . . . . . 24 3.8.1.1. Media Sequence . . . . . . . . . . . . . . . . . . 24 3.8.1.2. Object URI . . . . . . . . . . . . . . . . . . . . 25 3.9. RTP Multicast Session . . . . . . . . . . . . . . . . . . . 27 3.9.1. RTP as the MSYNC packet container format . . . . . . . 27 3.9.2. RTP packet retransmission . . . . . . . . . . . . . . . 28 3.10. Configuration . . . . . . . . . . . . . . . . . . . . . . 31 3.10.1 MSYNC Configuration . . . . . . . . . . . . . . . . . . 31 3.11. MSYNC workflow example . . . . . . . . . . . . . . . . . . 31 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Normative References . . . . . . . . . . . . . . . . . . . 37 6.2. Informative References . . . . . . . . . . . . . . . . . . 39 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 40 Bale et aL. Expires June 5, 2025 [Page 2] Internet-Draft MSYNC December 2, 2024 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Bale et aL. Expires June 5, 2025 [Page 3] Internet-Draft MSYNC December 2, 2024 1 Introduction Transporting media content over multicast is known to be very effective for saving network resources (bandwidth). Multicast is used by Internet service providers for providing IPTV services. IPTV technology relies essentially on MPEG Transport Stream (MPEG TS) format, UDP transport, and IP multicast, whereas the HTTP adaptive bit-rate streaming (HAS), a unicast "Over The Top" technology relies on HTTP /TCP, new container formats such as MP4/CMAF, and signaling protocols such as Apple HLS and MPEG DASH. With the generalization of HAS streaming there is a need to operate an IPTV service in association with HAS streaming technology for unifying the two ecosystems. MSYNC allows transporting HTTP based ABR flows over multicast relying on IP/UDP and optionally RTP that makes it suited for transitioning IPTV legacy (MPEG2 TS) to the HAS ecosystem. Various IPTV infrastructures (xDSL, cable, fiber) and broadcast networks have experimented with, and deployed this protocol. MSYNC is deployable within a controlled environment wherein multicast distribution relies on a pre-arranged capacity planning. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Definitions ABR: Adaptive Bit Rate streaming is a method that consist of changing the media encoding bit-rate function of the network condition. HTTP/1.1 CTE: Chunked Transfer Encoding. A method for object delivery over HTTP1.1 of unknown size. See Section 7.1 of [RFC9112] HTTP Adaptive Streaming (HAS) protocol: an ABR method based on HTTP and signaling procedures described in [MPEGDASH] and in [RFC8216]. HTTP Adaptive Streaming (HAS) session: Transport one or more media streams (e.g., one video, two audios, One subtitle) according to HTTP. A HAS session is triggered by a player initially downloading a manifest file, then an init segment and/or media segments belonging to possibly different sub-streams according to the selected representation and possibly more manifest files according to the HAS protocol. Bale et aL. Expires June 5, 2025 [Page 4] Internet-Draft MSYNC December 2, 2024 init segment: A part of a media sub-stream used to initialize the decoder as specified in [MPEGCMAF]. manifest: A file containing the configuration for conducting a streaming session; corresponds to a play list as defined by HLS [RFC8216]. During a HAS streaming session, a manifest or playlist can be modified. media: A digitalized piece of video, audio, subtitle, image, etc. media stream: The aggregate of one or more media sub-streams. This should not be confused with the RTP media stream. media sub-stream: A version of a media encoded in a particular bit- rate, format and resolution; also called representation or variant stream. A media sub-stream corresponds to the RTP media stream. media segment: A part of a media sub-stream of a fixed duration (e.g., 2s) as specified in [MPEGCMAF]. media chunk: A part of a media segment of a fixed duration as specified in [MPEGCMAF]. MSYNC object: An MSYSNC object can be an addressable HAS entity like an initialization segment, a media segment or chunk, a manifest or playlist. An MSYNC object can also be a non-addressable transport entity as an HTTP2 frame or an HTTP/1.1 CTE block. MSYNC super object. An object composed of parts delivered on the fly when the size of this object to be transmitted is unknown in advance. A super object may correspond to a stream or a media segment not yet completely generated/received and the size of which is therefore unknown. MSYNC packet: The transport unit of MSYNC. Several MSYNC packets MAY be used to transport an MSYNC object. MSYNC receiver. The MSYNC end point that receives MSYNC objects over multicast. MSYNC sender. The MSYNC end point that sends MSYNC objects over multicast according to MSYNC. representation: A media sub-stream as defined by [MPEGDASH]; corresponds to a variant stream as defined by HLS [RFC8216]. variant stream: A media sub-stream as defined by HLS [RFC8216]; Bale et aL. Expires June 5, 2025 [Page 5] Internet-Draft MSYNC December 2, 2024 corresponds to a representation as defined by [MPEGDASH]. IP multicast session: A session consisting of transport multicast sessions having the same source IP address and destination multicast IP address. transport multicast session: Operating a transport protocol that is based on UDP over IP multicast. A transport multicast session is identified by the destination transport (UDP) port number, the source IP address and the IP multicast address. RTP multicast session: A transport multicast session based on RTP as defined in [RFC3550]. 2. Overview 2.1. A typical MSYNC deployment MSYNC is a protocol typically used between a multicast server that hosts the MSYNC sender and a multicast gateway that hosts the MSYNC receiver. This is depicted in Figure 1. Arrows represent the HAS session elements directional flows. The multicast server acquires HAS session elements in unicast conforming to a HAS protocol as e.g., MPEG DASH [MPEGDASH] or HLS [RFC8216] and sends those HAS session elements over a multicast network, supporting possibly RTP and UDP/IP multicast, to the multicast gateways. A multicast gateway listens the corresponding multicast flows and serves the HAS player(s) in unicast conforming to the same HAS protocol. MSYNC permits a sender to serve simultaneously multiple receivers conforming to one or several HAS protocols and formats (e.g., assuming one shared multicast network, one sender could serve some receivers with MPEG DASH compliant content and other receivers with HLS compliant content). The multicast server is configured (by e.g., the ISP operating the multicast network) in order to acquire HAS content from a Content Distribution Network (CDN) via a unicast protocol, typically over the Internet. Considering one among several possible content ingest methods (e.g., HTTP GET), for each HAS session, the multicast server behaves as a HAS player, reading the manifest, discovering the available representations and downloading concurrently media segments of all (or a subset) of the available representations. The multicast server is configured for sending all those HAS session elements over possibly RTP and UDP/IP multicast according to a certain UDP/IP flow arrangement. For example, the objects related to each video representation are sent over a separate transport multicast session (multicast IP address + port number) whereas all audio representations are sent over the same transport multicast session. Bale et aL. Expires June 5, 2025 [Page 6] Internet-Draft MSYNC December 2, 2024 The Multicast gateway is configured by the same ISP having configured the multicast server for being aware of the same UDP/IP flow arrangement. Depending on this arrangement and on the HAS player request, the Multicast gateway joins the multicast IP group associated with the HAS representation requested by the HAS player. Note that the multicast gateway might not be capable of receiving all the concurrent transport multicast sessions at the same time due to bandwidth limitations (e.g., ADSL). At any time, the multicast gateway can detect corrupted and/or lost packets and attempt to repair using a repair protocol. This is possible with the HAS server interacting with the HAS content delivery network (CDN) or thanks to RTP when used as the transport layer over UDP (See Section 3.9). The multicast gateway receives the MSYNC objects and is ready to serve them (e.g., acts as a local cache). Whenever a HAS request is sent by a media player and received by the multicast gateway, the latter reads first its local cache. In case of hit, it returns the object. In case of miss, the multicast gateway can retrieve the requested object from the associated CDN (or a dedicated server) over a unicast interface through operating HTTP conventionally and forwards back to the HAS player the object once retrieved. If no unicast interface exists, the multicast gateway can wait some time for the local cache to be updated with the element requested by the media player and/or returns an error. unicast server multicast server +-------- + + -------------------- + | HAS | ---- unicast --> | HAS | MSYNC | | CDN | Internet | ingest | sender | + ------- + + ---------------------+ | | | | -----------unicast ---------- multicast Internet | | | | v V +-------- + + -------------------- + | HAS | <--- unicast --- | HAS | MSYNC | | player | Local | server |receiver | + ------- + + ---------------------+ end-user multicast gateway terminal Figure 1: example of MSYNC deployment Bale et aL. Expires June 5, 2025 [Page 7] Internet-Draft MSYNC December 2, 2024 Section 3.11 discloses a video streaming workflow example that involve MSYNC and application elements. It clarifies the roles and operations attached to the MSYNC sender and receiver and those attached to the application elements (i.e. HAS ingest and HAS server respectively). With MSYNC deployed over a multicast network, the HAS player receives HAS content in full transparency (i.e. the player is absolutely unaware of getting the content through MSYNC or not). Note that nothing precludes the MSYNC receiver or even the multicast gateway from be co-located with the media player and therefore embedded in the end-user terminal as shown in Figure 2. multicast server +-------- + + -------------------- + | HAS | <--- unicast --> | HAS | MSYNC | | CDN | Internet | ingest | sender | + ------- + + ---------------------+ | | | | unicast multicast Internet | |--------- | | | | v v | + --------------------------- + | | HAS | HAS | MSYNC |<--------------- | player | server |receiver | + ----------------------------+ end-user terminal Figure 2: MSYNC receiver in the terminal 2.2. Unicast Networks Figure 1 shows a typical MSYNC deployment where a HAS player interacts with a HAS server in an unicast way over e.g., Internet and interacts with a multicast gateway over e.g., a local network according to the same HAS protocol. Note that the multicast gateway may reside in the local area network (LAN) or upstream, in the ISP's network premises. In theory, all interfaces labeled "unicast" in Figure 1 could be deployed over an Internet network, although practically, the interface between the end-user terminal and the multicast gateway corresponds to a broadband access network or a Local area network Bale et aL. Expires June 5, 2025 [Page 8] Internet-Draft MSYNC December 2, 2024 (LAN) controlled by the ISP. 2.3. Multicast Network and congestion avoidance In this document "multicast network" means a network supporting IP multicast in addition to supporting IP unicast. A multicast network is typically provided and controlled by a broadband Internet service Provider following the design principles depicted in [BFTR145] and [BFTR178]. A multicast network is composed with one or several multicast sub-networks interconnected with multicast routers and/or layer 2 bridge/switches performing IGMP snooping (Multicast Listener Discovery in IPv6) as discussed in [RFC4541] allowing to duplicate/forward multicast IP packets based on IGMP messaging. In a broadband multicast infrastructure the multicast network interconnects a service end-point (e.g., an IPTV service) with a broadband gateway located in the end-user premises. The last multicast sub-network is typically a point-to point circuit/line between the end-user broadband gateway and the first access network infrastructure aggregation point (e.g., a DSL access module or DSLAM). It has a rather limited [bandwidth] capacity comparing with the other multicast sub-networks being part of the ISP's access, aggregation and core networks. The MSYNC sender is connected to the first multicast sub-network whereas the MSYNC receiver is connected to the last multicast sub- network. A multicast network provides a certain capacity (i.e., bandwidth) attached to the first sub-network (connected to the MSYNC sender) that may be different from the capacity attached to the last sub-network connected to the MSYNC receiver. The data transported (i.e., HAS session elements) by MSYNC is not assumed elastic, i.e., it SHOULD be ingested at a fixed rate, sharing the concerns expressed in [RFC3550], Section 10. The multicast network must support pre-provisioning bandwidth resources. This assumption permits to have the MSYNC sender able to transmit one HAS session or concurrently several HAS sessions operating one or more transport multicast session up to a certain maximum bandwidth, said MAX_BW_SEND. MAX_BW_SEND corresponds to the maximum guaranteed bandwidth dedicated to MSYNC allowing to transport the provisioned HAS session(s) across all multicast sub-networks up to the last multicast sub-network ingress point (e.g., the last router or bridge) before reaching the MSYNC receiver. The MSYNC sender MUST control the sending rate of each HAS media sub- stream (and generally speaking of all MSYNC object to be transmitted) in such a way the maximum bandwidth MAX_BW_SEND corresponds to the following: Bale et aL. Expires June 5, 2025 [Page 9] Internet-Draft MSYNC December 2, 2024 1. the sum of all individual media sub-stream bit-rate composing the set of provisioned HAS session(s) and 2. an additional bandwidth reserve for supporting control (initialization segments, manifest file, configuration information) transmission. In addition, the MSYNC sender MUST be configured in such way that the minimum bandwidth consumed by a HAS session as advertised by a manifest (the least bandwidth consuming combination of media sub- streams as e.g., video, audio, subtitling) remains within the smallest provisioned bandwidth dedicated to MSYNC over the last multicast sub-network (connected to the N MSYNC receivers), said min (MAX_BW_RECEIVE_1, MAX_BW_RECEIVE_2, MAX_BW_RECEIVE_3,..., MAX_BW_RECEIVE_N). There is one MAX_BW_RECEIVE restriction per MSYNC receiver as there might be up to one different multicast sub-network connected to each MSYNC receiver. With this approach, any MSYNC receiver (whatever the last multicast sub-network capacity) fed by the MSYNC sender is ensured to receive at least one HAS sub-streams combination for each HAS session. The MSYNC sender MAY send a manifest and related media sub-streams whose combination could result in a throughput higher than the MAX_BW_RECEIVE of some MSYNC receivers. The MSYNC receiver is instructed to join one or more IP multicast sessions up to its maximum bandwidth constraint (MAX_BW_RECEIVE) that represents the provisioned capacity dedicated to MSYNC over the last multicast sub-network it is connected to. As an example, the capacity of the last multicast sub-network can be limited to a few Mbps with ADSL and up to several hundred of Mbps with fiber to the home (FTTH). In the case of a broadcast network (e.g., satellite) the capacity exposed to the MSYNC sender may be equivalent to the capacity exposed to the MSYNC receiver if the broadcast network is composed with only one sub-network. The MSYNC receiver MUST support IGMP version 2 [RFC2236] or above versions in order to "join" and "leave" an IP multicast session, When source filtering ( Source-Specific Multicast or SSM) is required the MSYNC receiver MUST support IGMP version 3 [RFC3376]. Sending and receiving MSYNC packets over a transport multicast session is detailed in 3.7. 2.4. Handling third party content As introduced above, MSYNC is an enabler for allowing HAS content to be distributed over a controlled multicast network. Ideally any content provider or content delivery network provider on the Internet Bale et aL. Expires June 5, 2025 [Page 10] Internet-Draft MSYNC December 2, 2024 should be able to benefit from MSYNC. Content Distribution Network Interconnection (CDNi) is a framework [RFC7336] for a content provider or an upstream CDN provider to delegate streaming to a downstream CDN. Regarding HAS streaming, CDNi is used to improve the user experience, allowing the third party content provider to operate a downstream CDN owned, shared and exposed by an ISP through the Open caching interfaces specified by the CDNi framework. The delegation is basically done through request routing where an upstream request router on the Internet redirects a request to a cache server located in the ISP network. Advantages and benefits are disclosed in [RFC6770] and in particular in Section 2.3 that discusses the mutual benefits for the ISP and the content/CDN provider in the context of video streaming. Let's now assume that the ISP desires to share and open its multicast delivery service and infrastructure powered by MSYNC in a similar way. This may be completely transparent for the content provider. According to the CDNi framework, HAS session request can be delegated to (i.e., routed) down to the ISP's HAS server hosted by the multicast gateway in figure 1. In summary with the CDNi framework and MSYNC combined together, HAS streaming over Internet can leverage the ISP's multicast network delivery (powered by MSYNC) in an open/standard way. 3. MSYNC Protocol The MSYNC protocol allows an MSYNC sender to transmit MSYNC objects (e.g. a media segment or a manifest) to an MSYNC receiver. An MSYNC object is composed with several elements (Info, HTTP header, data) where each element is composed with one or multiple MSYNC packets. For instance, sending a media segment object requires the sender to send: one object info element (The object info element always fits to only one MSYNC info packet), one object HTTP header (optional) that is composed with one or more object HTTP header packets and finally the object data element that is composed with one or more object data packets. When the object to be sent is known to be part of a bigger super object of unknown size then the sender uses the data-part element instead of the data element. An object data-part element is composed with one or more object data-part packets. All MSYNC packets carrying elements or parts of elements associated with the same MSYNC object carries the same MSYNC object identifier. The MSYNC sender sends an object over one transport multicast session (possibly a RTP multicast session). All objects belonging to the same media sub-stream are typically sent over the same multicast transport session although it is not mandatory. The MSYNC sender is instructed Bale et aL. Expires June 5, 2025 [Page 11] Internet-Draft MSYNC December 2, 2024 to send media sub-streams over one or more multicast transport sessions according to a mapping configuration file that is shared at the application level (i.e., between the Multicast server and the Multicast gateway in Figure 1). The minimum set of required configuration parameters related to MSYNC is summarized in Section 3.10. The format of this MSYNC configuration document as well as parameters that are not directly linked to MSYNC are not specified. This is the subject of standard specification such as [DVB-MABR]. The MSYNC receiver behavior is driven by the application as envisaged in Section 2.1 for example. The end user application (e.g. a HAS player) may request a media object (e.g., a manifest or a segment) that makes the MSYNC receiver be instructed by the HAS Server to listen the corresponding multicast transport sessions (joining the corresponding IP multicast session if not already done); the mapping information (request URL to multicast transport session) is the responsibility of the Application. The MSYNC receiver delivers to the application (e.g., the HAS Server in Figure 1) any received object from any listening multicast transport session along with the useful metadata such as the object URI, an information of the object info element (see Section 3.2) that may be used as a cache key as envisaged in Section 2.1. The details of the MSYNC protocol are disclosed in the following sub- sections. 3.1. MSYNC Packet Format The MSYNC packet has the following format. All bytes are sent according to the conventional network order: big-endian. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | packet type | object identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-header | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | data | | .... | Figure 3: MSYNC Packet version: 8 bits Version of the MSYNC protocol = 0x03 Bale et aL. Expires June 5, 2025 [Page 12] Internet-Draft MSYNC December 2, 2024 packet type: 8 bits Defines the MSYNC packet type. The sub-header and the associated data (if any) are dependent on the packet type. The following types are defined. 0x01: Object info 0x02: Object info redundancy packet 0x03: Object data 0x04: Reserved 0x05: Object http header 0x06: Object data-part as a piece of an object data for transporting e.g., an MPEG CMAF chunk, an HTTP/1.1 chunk or yet an HTTP/2 frame. object identifier: 16 bits This field identifies the object being transferred in a multicast transport session. Considering one transport multicast session, all MSYNC packets associated with the same object carry the same object identifier in their MSYNC packet header. Whenever this object ID change that means the sending of the previous object is finished but not necessarily the reception (packets might have been possibly reordered). Depending on the deployment, un-ordered packet reception is either not possible or acceptable within a certain time limit. When transmitting a new object, the MSYNC sender MUST NOT reuse an object ID that corresponds to an ongoing MSYNC object transmission. The way to deal with packet reordering is discussed in Section 3.7. sub-header: series of N x 32 bits The packet sub-header is linked to the packet type. The details of each packet type are specified in the next sections. data: series of D x 8 bits The presence and contents of field is optional and is present depends on the packet type. D is bounded by the maximum size of a transport multicast session protocol packet size and the MTU (Maximum Transfer Unit) otherwise as explained in Section 3.6. 3.2. Object Info Packet The Object info packet is used to transport meta-data associated with an object. It is used to describe the object. Object information is carried over one object info packet only. The object info packet is typically sent along with the object data it describes. The object identifier corresponds to the object identifier of the object data packets or the object data-part packets that the object info packet relates to. Bale et aL. Expires June 5, 2025 [Page 13] Internet-Draft MSYNC December 2, 2024 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | packet type | object identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number of MSYNC packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object type | Reserved | mtype | object URI size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | media sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | object URI | : : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Object Info packet packet type: 0x01 or 0x02 Redundant object INFO packets (packet type 02) MAY be sent in addition to the "main" object info packet according to Section 3.7. object size: 32 bits The number of bytes that compose the object data payload transported with one or more MSYNC object data packets (Section 3.3) or MSYNC object data-part packets (Section 3.5). The size may be 0 indicating that there is no corresponding object's data payload transmission foreseen (i.e., no expected MSYNC data packet or MSYNC data-part packet). In case of a super object transmission (Section 3.5), if the object URI of an object info with an object size set to 0 matches the super object URI then it MUST be interpreted as the end of the super object transmission (Section 3.8.1.2). Note that 32 bits is sufficient when transporting HAS elements.The maximum size of an object (4.4 GBytes) authorizes the transfer of a video segment of several tens of seconds, 4K encoded. number of MSYNC packets: 32 bits Number of MSYNC packets that compose the transported object. If the object size is null (set to 0) then the number of MSYNC Bale et aL. Expires June 5, 2025 [Page 14] Internet-Draft MSYNC December 2, 2024 packets MUST be null (set to 0). object CRC: 32 bits A Cyclic Redundancy Check applied to the object data payload or the object data-part payload for corruption detection according to the CRC-32 algorithm defined in the ISO/IEC 3309:1999 specification revised by the ISO/IEC 13239:2002 specification. The object data payload is composed with the "data" field of all data packets associated with the object (see section 3.3). The object data-part payload is composed with the "data" field of all data- part packets associated with the object (see Section 3.5). object type: 8 bits Defines the type of object, i.e., the content type transported with Object data (or data-part) packets, associated with this MSYNC Object info packet. 0x00: Unknown. 0x01: Media manifest (playlist). 0x02: Reserved. 0x03: Media content. Data plane elements formatted according to e.g. MPEG-TS [MPEG2TS], MP4 or yet fragmented MP4 [MPEGCMAF]. 0x04: Reserved. 0x05: control: control plane information (e.g., MSYNC configuration elements as discussed in Section 3.10). 0x06-0xFF: Reserved. mtype: 4 bits Characterizes the media manifest. This field MUST only be used in association with the object type 0x01 (media manifest). It MUST be set to 0x0 (not applicable) otherwise. The field can take the following values. 0x0: Not Applicable 0x1: MPEG Dash as specified in [MPEGDASH]. 0x2: Master HLS playlist as specified in [RFC8216]. 0x3: Media HLS playlist as specified in [RFC8216]. 0x4-0xF: Reserved object URI size: 12 bits The size in bytes (as an unsigned integer) of the object URI field. The object URI maximum size depends on the network MTU as discussed in Section 3.7. media sequence: 32 bits A sequence number (as an unsigned integer) associated with the MSYNC objects data and data-part (for transporting a segment or a manifest) that depends on the mtype value. It is used by the application operating MSYNC (e.g. the multicast gateway) to facilitate/accelerate the synchronization between unicast and Bale et aL. Expires June 5, 2025 [Page 15] Internet-Draft MSYNC December 2, 2024 MSYNC reception. The multicast gateway may operate jointly MSYNC/multicast and conventional HTTP/unicast for retrieving HAS elements as indicated in Section 2 and illustrated in Figure 1. The values and rules are detailed in the Section 3.8 dedicated to the HAS protocol dependencies. If this field is unused, it MUST be set to 0x00, and MSYNC receivers MUST ignore it. object URI: Quotient ((object URI size * 8)/32) bits + 32 bits if remainder ((object URI size * 8)/32) >0 This is the path name associated with the object as the URI reference to be resolved according to [RFC3986]. It MAY corresponds to a storage/Cache path. There SHOULD be a direct relationship between this URI and the URL associated with the addressable object (e.g., HAS segment or CMAF chunk and/or a manifest). The rules for HAS delivery are detailed in Section 3.8 dedicated to the HAS protocol dependencies. The object URI is coded as a series of string characters conforming to UTF-8 [STD63]. Remaining unused bytes of the last 32 bits field MUST be filled with the 0x00 value. 3.3. Object Data Packet The Object Data Packet carries part or all of the object's data payload. The type of data and the way to process the object's data packets are determined by the associated object info packet. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | packet type | object identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | : : : : Figure 5: Object Data packet packet type: 0x03 object offset: 32 bits The index from which the MSYNC object data packet payload (data field) is to be written in order to compose the object data payload at the receiver side (i.e., the multicast gateway). The first data packet of an object has an offset equal to 0. The MSYNC sender MUST NOT send a data packet that exhibit an object offset Bale et aL. Expires June 5, 2025 [Page 16] Internet-Draft MSYNC December 2, 2024 that makes the data range overlapping with a previously transmitted data packet belonging to the same object. Likewise,the MSYNC receiver MUST ignore a data packet that exhibit an object offset that makes the data range overlapping with a previously received data packet belonging to the same object. data: N x 8 bits The data payload (or part of data payload) related to the carried object ( e.g., part or all of a HAS segment or a manifest). The maximum size of the object data packet depends on the network MTU as discussed in Section 3.7. This data payload represents all or part of the object data payload. The total size (number of bytes) of the object data payload is indicated in the associated object info packet (field object size). The object CRC in the associated object info packet applies to the object data payload (i.e. composed with one or more data payloads). 3.4. Object HTTP Header Packet Using the object HTTP header is optional (see 3.7). The MSYNC sender and the MSYNC receiver do not exploit directly the HTTP header. HTTP header fields can be used by the application operating MSYNC. For example, considering the Figure 1, the HAS Ingest component in the Multicast server may ingest some HTTP headers useful for the HAS server in the Multicast gateway and/or the end user application. As an example a security mechanism based on HTTP may exploit this possibility (see Section 5). The HTTP header packet carries part or all of HTTP header fields related to the object to be sent. There is at most one object HTTP header per object data (or per object data-part) that means the MSYNC sender MUST NOT send more than one object HTTP header element with a different content (i.e. different set of HTTP header fields) associated with the same object identifier. The exact same object HTTP header element can be repeated (sent several times) according to the sending rules detailed in Section 3.7. The transport of the HTTP header fields MUST be conformed to HTTP/1.1 Section 5 of [RFC9112]. Carrying HTTP header fields of a version of HTTP greater than HTTP/1.1, the MSYNC sender MUST convert the format according to HTTP/1.1 Section 5 of [RFC9112]. The object HTTP header MAY also be used in association with Object Data-part. The fields (name/value pairs) MUST be transported according to HTTP/1.1 Section 5 of [RFC9112]. The object identifier is the same than the one present in the object data packets or object data-part packets it relates to. Bale et aL. Expires June 5, 2025 [Page 17] Internet-Draft MSYNC December 2, 2024 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | packet type | object identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header size | header offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | : : : : Figure 6: Object HTTP Header packet packet type: 0x05 header size: 16 bits An object HTTP header can be transported over one or several under-laying transport packets. This field indicates the total size of the HTTP header in bytes and it is indicated in each the HTTP header's packet. header offset: 16 bits The index from which this HTTP header MSYNC packet payload data is to be written in order to complement the HTTP header at the receiver side (i.e the multicast gateway). The first packet of the HTTP header has an offset equal to 0. data: N x 8 bits The payload data related to the HTTP header. The maximum size of the Object HTTP header packet depends on the network MTU as discussed in Section 3.7. 3.5. Object Data-part Packet This MSYNC packet carries part or all of the media data-part object payload. The type of data and the way to process the object's data- part packets are determined by the associated object info packet. Object data-part payload is transported through a series of object data-part packets. The data-part is used when the object corresponds to a "part" (a block) of a super object for which the size is unknown (a super object may correspond to a stream or a media segment not yet complete and for which the size is therefore unknown). All data-part packets belonging to the same data part object have the same object identifier that is the same one present in the object info packet and HTTP header (if any) packets the data-part object relates to. Bale et aL. Expires June 5, 2025 [Page 18] Internet-Draft MSYNC December 2, 2024 All data-part objects composing a super object have a different object identifier. The object info packet (object URI) links a data- part object with a super object as explained in Section 3.8.1.2. The end of super-object transmission is signaled with an object info packet having both the object size and the number of MSYNC packets set to 0 and having the object URI matching the object URI of the already received parts according to Section 3.8.1.2. Detecting missing data-part packets of a data-part object is based on detecting the end of an object transmission as depicted in Section 3.7.2 possibly assisted with the CRC. The receiver detects missing packets through the Object Info packet that indicate the number of MSYNC packets composing the object. The receiver detects corrupted packets through processing the CRC. Regarding the super object transmission, the MSYNC receiver does not know how many data-part objects composes a super object but knows when the super object transmission ends and knows the super object offset as well as the object URI of each of the already received data-part objects (object info contains the object size set to zero and the object URI referencing the last block +1) that permits the MSYNC receiver to avoid missing data-part objects belonging to the same super object. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | packet type | object identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | super object offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | : : : : Figure 7: Object Data-part packet packet type: 0x06 object offset: 32 bits The index from which the data-part packet payload (data field) is to be written in order to compose the object data-part at the receiver side (i.e., the multicast gateway). The first packet of the data-part has an offset equal to 0. The MSYNC sender MUST NOT send a data-part packet that exhibit an object offset that makes the data range overlapping with a previously transmitted data-part packet belonging to the same object. Likewise,the MSYNC receiver Bale et aL. Expires June 5, 2025 [Page 19] Internet-Draft MSYNC December 2, 2024 MUST ignore a data-part packet that exhibit an object offset that makes the data range overlapping with a previously received data- part packet belonging to the same object. super object offset: 32 bits The index from which the object part-data packet payload is to be written in order to compose the super object data at the receiver side (i.e., the multicast gateway). The first data-part object composing a super object has the super object offset equal to 0. The super object offset is the same for all object data-part packets composing the same object data-part. The MSYNC sender MUST NOT send a data packet that exhibit a super object offset that makes the data range overlapping with a previously transmitted data-part object belonging to the same super object. Likewise,the MSYNC receiver MUST ignore a data-part packet that exhibit a super object offset that makes the data range overlapping with a previously received data-part object belonging to the same super object. All data-part objects belonging to the same super object share the same object URI prefix (see Section 3.2) data: N x 8 bits The data payload related to the carried object ( e.g., part or all of a HAS segment or a manifest). The maximum size of the object data-part packet depends on the network MTU as discussed in Section 3.7. The total size (number of bytes) of the object data- part payload is indicated in the associated object info packet (field object size). The object CRC in the associated object info packet applies to the object data-part payload (i.e. composed with one or more "data" payloads). 3.6. Maximum Size of an MSYNC Packet An MSYNC packet MUST fit within the underlying protocol packet. As detailed in Section 3, an MSYNC packet is composed with a header part and a data part for which the size is limited by the transport multicast protocol. With RTP and/or UDP (which authorize up to 65535 bytes), the maximum size is linked to the path MTU (Maximum Transfer Unit) as the largest transfer unit supported between the source (the multicast sender) and the destination (the multicast receiver) without fragmentation. The mean to compute the MTU is out of scope of this document. 3.7. Sending and Receiving MSYNC Objects The following considerations are linked to the MSYNC configuration (3.10). 3.7.1. Mapping over Transport Multicast Sessions Bale et aL. Expires June 5, 2025 [Page 20] Internet-Draft MSYNC December 2, 2024 The mapping of MSYNC objects onto transport and IP multicast sessions is not constrained by the MSYNC protocol but by the multicast network capacity (i.e., the bandwidth) provisioned for MSYNC as indicated in Section 2.3. For example, with ADSL (Asymmetric Digital Subscriber Line), the capacity dedicated to multicast is limited which may drive to an IP multicast flow arrangement where one IP multicast session carries the elements related to only one video sub-stream and another one that carries the elements related to all audio sub-streams (each of the audio sub-stream being associated with a different transport multicast session). In that case, the MSYNC receiver must join at most three IP multicast sessions (one for the video representation packets, another one for the audio representations packets and the last one for the control information). Another arrangement could dedicate one IP multicast session per HAS stream gathering all media sub-streams (one transport multicast session per sub-stream). Considering a satellite network, as all transport multicast sessions are carried simultaneously, all IP multicast flow arrangements may make sense. The MSYNC receiver may be configured to join all IP multicast sessions in advance (see Section 3.10). In general, the MSYNC receiver is instructed to join the IP multicast session associated with the media sub-stream(s) the application (the HAS server in figure 1) wants to listen/receive that is itself linked with the incoming requests from the end user media player. A transport multicast session is identified with the triplet: source IP address (MSYNC supports Source Specific Multicast), destination multicast IP address and destination transport port number. It is RECOMMENDED to carry media sub-streams and the control information (Section 3.2) in separate transport multicast sessions; it allows the deployment of different error correction (see Section 3.9) or content protection procedure (e.g., one ISP may decide to encrypt the transport multicast session dedicated to the transmission of control information). The following arrangement is typical in ADSL: - One IP multicast session per media (audio or video or subtitle) sub-stream (representation); each transport multicast session having a different destination multicast IP address. - One transport multicast session for the the control information. It is perfectly possible to send the MSYNC packets attached to different objects in one transport multicast session only (and Bale et aL. Expires June 5, 2025 [Page 21] Internet-Draft MSYNC December 2, 2024 therefore one IP multicast session) as long as the following statement is respected. For each MSYNC object (see object type in 3.2) to be sent over a transport multicast session, the MSYNC sender MUST send the following MSYNC packets in the specified order: - One object info packet - Zero or more object info redundant packets - Zero or one object HTTP header, the object HTTP header being compose with one or more packets (sent in a sequential order), - Zero, one or more redundant object HTTP header elements (all identical to the previously sent object HTTP header if any), each repeated object HTTP header being composed with one or more packets (sent in a sequential order), - Zero, one or more object data packets (or object data-part packets) in a sequential order. The MSYNC receiver MUST continuously control that it does respect its MAX_BW_RECEIVE constraint (see Section 2.3) and therefore the MSYNC receiver MUST NOT attempt to join a new IP multicast group if that condition cannot be respected. When the MSYNC object is of size null (used to signal the end of the transmission of a super object) then only one object info packet is sent (see Section 3.2). 3.7.2. Detecting the End of an Object Reception Detecting the end of an MSYNC object (or super object) transmission is done thanks to the Object Info (see 3.2) information. However, packet loss is possible and MSYNC packets related to an MSYNC object may be received out of order. Packet re-ordering may be acceptable or not depending on the deployment scenario (it is generally bounded by the potential latency introduced by un-ordered MSYNC packets reception). As a consequence, the detection of the end of the MSYNC object reception MUST NOT be based solely on the detection of the end of the object transmission. An MSYNC receiver implementation MAY rely on a timer associated with the maximum transmission time of a particular MSYNC object type in order to detect the end of the MSYNC object transmission. The MSYNC receiver MAY arm a timer when the reception starts (e.g., first received packet related to a new object) and MAY stop the timer Bale et aL. Expires June 5, 2025 [Page 22] Internet-Draft MSYNC December 2, 2024 whenever the object is completely received. When the timer reaches the time limit, the MSYNC receiver SHOULD consider the transmission of that object done while the object being partially received. Note that the MSYNC sender MAY use the same maximum transmission time of a particular MSYNC object type for controlling the object identifier (re-)allocation (see Section 3.1). Assuming receiving unordered packets is not possible, an MSYNC implementation MAY rely on the detection of a new object transmission and decide that the previous object transmission (and reception) is done while the object being possibly partially received. After the transmission of an object is considered done, The MSYNC receiver MUST consider subsequent packets related to the same object identifier as being part of new object transmission only if the previously received object associated with the object identifier has been completely received or partially received but after a maximum transmission time. If this condition is not verified the MSYNC receiver MUST discard the packets. When a new object transmission is detected (an object data or data- part with a new object identifier) and there is no associated object info packet received within a certain time limit ( linked to the support of packet re-ordering) the object MUST be ignored and related packets MUST be discarded. In the case of a partially received MSYNC object, this is up to the application (e.g., the HAS server in Figure 2) to react, triggering, for instance, an object repair procedure. Note that packet repair and packet reordering can be performed at the underlying RTP, based on the RTP sequence number (see Section 3.9). 3.7.3. Congestion Control MSYNC is applicable and deployable in a controlled environment according to Section 3.1.9 of [RFC8085]. MSYNC MUST be used in a single operator network that operates network capacity provisioning. As indicated in Section 2.3, the MSYNC sender MUST control its sending rate according to a pre-provisioned capacity (i.e., bandwidth) dedicated to MSYNC. The deployment SHOULD prevent any potential "leaks out into unprovisioned Internet paths" in conformance with Section 3.1.9 of [RFC8085]. This can be achieved through logical and physical traffic isolation and filtering as commonly implemented in broadband networks following the design principles depicted in [BFTR145] and [BFTR178]. This may also be Bale et aL. Expires June 5, 2025 [Page 23] Internet-Draft MSYNC December 2, 2024 complemented with the support of a circuit breaker as disclosed in [RFC8084]. The MSYNC receiver or more probably the application exploiting the MSYNC receiver (e.g. the multicast gateway in Figure 1) may detect and mitigate potential congestions according to the receiver-driven congestion control method as detailed in Section 4.1 of [RFC8085]. When congestion occurs, the received objects are subject to a growing number of missing bytes and therefore a growing number of repair procedures (the MSYNC receiver repairs the packets possibly based on RTP - see 3.9). On congestion detection, the MSYNC receiver, under the control of the application SHOULD leave one or more IP multicast groups and may even terminate the multicast reception. Regarding HAS streaming, one mitigation action would be to switch to a less bandwidth consuming IP multicast session, forcing the end-user terminal/player somehow to request HAS sub-stream elements related to that less bandwidth consuming IP multicast session. 3.8. HAS Protocol Dependency A certain number of MSYNC packet header fields have a dependency on the HAS protocol and therefore on the manifest type. Similarly the sending rules may also depend on the HAS protocol. 3.8.1. Object Info Packet 3.8.1.1. Media Sequence The media sequence (an object Info Packet header field presented in the Section 3.2) is used by the application operating MSYNC (e.g. the multicast gateway) to facilitate the synchronization of the MSYNC (i.e., multicast) reception with the unicast reception. The multicast gateway may operate jointly MSYNC/multicast and conventional HTTP/unicast for retrieving HAS elements as indicated in section 3.2. For example, considering a HAS session, the application (e.g. the multicast gateway) starts to fetch a manifest from unicast as the MSYNC receiver is not ready. When the MSYNC receiver becomes ready and is receiving segments related to the HAS session, the application must quickly determine the level of freshness of the last segment received via MSYNC, meaning whether this segment is more recent than the last one fetched from unicast. Without the media sequence information field present in the Object info packet, the multicast gateway would need to parse the manifest received from MSYNC that takes time and consumes CPU. Similarly, the application may also need to understand the level of freshness of a manifest file received via MSYNC versus the last one received over unicast. If no unicast reception is used jointly with MSYNC in the multicast Bale et aL. Expires June 5, 2025 [Page 24] Internet-Draft MSYNC December 2, 2024 gateway (e.g., like in one way delivery only), the default value of 0x00 MAY be used. If unicast reception is used jointly with MSYNC then the media sequence MUST be set depending on the object type and mtype values (Info Packet header fields presented in Section 3.2.) as listed below. HLS master playlist: 0x00 HLS variant playlist; MUST contain the Media Sequence Number according to Section 3 of [RFC8216] of either the last segment transmitted (i.e. the last declared segment in the playlist) or the last segment under transmission, i.e. the last declared segment in the playlist plus one (+1) also called parent segment in the the case of partial segment(s) declared after the last declared segment in the playlist (see Section 3.2 of [ID-HTTPLIVESTREAM]). HLS segment: MUST contain the Media Sequence Number according to Section 3 of [RFC8216] corresponding to either the declared segment in the associated playlist or the last declared segment in the playlist plus one (+1) also called parent segment in the the case of partial segment(s) declared after the last declared segment in the playlist (see Section 3.2 of [ID-HTTPLIVESTREAM]). DASH manifest: MUST contain $time$/(integer division)@timescale or $Number$ corresponding to the last segment transmitted or under transmission (and possibly received partially) and declared in the manifest. see [MPEGDASH] for the definition of $time$, @timescale and $Number$. DASH segment: MUST contain the $time$/(integer division)@timescale or $Number$ value corresponding to the segment declared in the manifest. 3.8.1.2. Object URI In the context of HTTP adaptive streaming, the object URI is a URI reference. If the object is a HAS addressable entity (e.g., a segment or a CMAF chunk), the object URI MUST match (be a substring) with the URL announced in the corresponding manifest/playlist. Examples: - The object URI: /tvChannel1/Q1/S_2 matches with the segment's URL that is computed from the associated manifest/playlist: ".../tvChannel1/Q1/S_2.mp4" Bale et aL. Expires June 5, 2025 [Page 25] Internet-Draft MSYNC December 2, 2024 - The object URI /tvChannel11/Q1/S_2_3 matches with the CMAF chunk URL that is computed from the associated manifest/playlist: ".../tvChannel11/Q1/S_2_3.mp4". If the object is a non-addressable HAS entity (e.g., a HTTP/1.1 CTE block), the object URI is composed with a sub-string (that MUST match with the URL announced in the corresponding manifest) and a suffix composed with the hash sign/character (#) and the block number). Example: - The object URI of the 3rd HTTP/1.1 CTE block of the segment S_2: tvChannel11/Q1/S_2.mp4#2 matches with the segment's request URL that terminates with ".../tvChannel1/Q1/S_2.mp4" The block number of an object URI attached to a media data-part object MUST be incremented for each subsequent transmission. When all the MSYNC data-part packets for all the media data-part objects (e.g., HTTP/1.1 CTE blocks) composing a super object (e.g., a media segment) have been sent, the MSYNC sender MUST signal the end of the MSYNC super object transmission through sending an MSYNC object info packet with the object size set to zero (0). In addition, the object URI MUST contain the URI reference of the next block (never transmitted). see Section 3.2. Example: - The object URI of the object info packet associated with the 1st HTTP/1.1 CTE block of the segment S_2: tvChannel11/Q1/S_2.mp4#0 - The object URI of the object info packet associated with the 2nd HTTP/1.1 CTE block of the segment S_2: tvChannel11/Q1/S_2.mp4#1 - The object URI of the object info packet associated with the 3rd HTTP/1.1 CTE block of the segment S_2: tvChannel11/Q1/S_2.mp4#2 - The object URI of the object info packet associated with the 4st HTTP/1.1 CTE block of the segment S_2: tvChannel11/Q1/S_2.mp4#3 - The object URI of the object info packet associated with the 5st HTTP/1.1 CTE block (of size null) signaling the end of the super object (i.e., segment) transmission: tvChannel11/Q1/S_2.m4s#4 Bale et aL. Expires June 5, 2025 [Page 26] Internet-Draft MSYNC December 2, 2024 3.9. RTP Multicast Session RTP [RFC3550] being popular in the IPTV ecosystem is a motivation to consider RTP as an MSYNC transport multicast session protocol. The RTP support would allow an MSYNC deployment to benefit from the RTP infrastructure already in place such as RTP based monitoring tools. 3.9.1. RTP as the MSYNC packet container format With MSYNC, RTP is used as a container format wrapping MSYNC packets. As such, There is no need to use RTP for media multiplexing or source/receiver synchronization. The following lines list the restrictions in using RTP based on [RFC3550] and Section 2 of [RFC3551]. - One RTP multicast session corresponds to one Transport multicast session as indicated in Section 1.2.- RTCP usage is not required if packet retransmission (see Section 3.9.2.) is not used. - There is no support, no need to announce/describe the RTP multicast session using SDP or any other equivalent announcement protocol.- MSYNC does not support RTP translators and mixers. Accordingly, the MSYNC sender (the RTP sender) MUST NOT list contributing source (CSRC) identifiers in the RTP header (see below). The RTP packet header used to wrap a MSYNC packet is represented in Figure 8. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: RTP Header for MSYNC P: Padding. Not used. MUST be set to 0. X: Extension. Not used. MUST be set to 0. CC: CSRC Count.. MSYNC does not support contributing sources. The RTP header contains 0 (zero) contributing source identifier (CSRC) fields. MUST be set to 0. M: Marker. Not used. MUST be set to 0. PT: Marker. Bale et aL. Expires June 5, 2025 [Page 27] Internet-Draft MSYNC December 2, 2024 The RTP header payload type (PT) field SHOULD correspond to one of the dynamic value specified in [RFC3551]. Its value should be communicated to the MSYNC receiver as part of the MSYNC receiver configuration (Section 3.10). This payload type MUST be the same whatever the multicast transport session. sequence number: see [RFC3550]. timestamp: The RTP header timestamp field is computed as indicated in [RFC3550]; it corresponds to the instant the MSYNC sender starts the MSYNC packet transmission. SSRC: Each RTP multicast session MUST operate a unique different SSRC number [RFC3550]. This allows packet retransmission (if used) on the RTP multicast session basis. 3.9.2. RTP packet retransmission Packet retransmission (see Figure 9 below) MAY be used in association with the RTP multicast session for packet loss recovery. If this is the case then the RTP Repair client and RTP repair server MUST be compliant with [RFC4585], [RFC4588] and [RFC5506] according to the followings. - Reduced sized RTCP (Section 4 of [RFC5506]) MUST be used with sending feedback NACK messages operating the immediate Feedback mode [RFC4585]. The RTP Repair client does not send Receiver Report (RR). There is no regular RTCP transmission but only feedback messages when appropriate (RTP packet loss detected). - The RTP Repair client (coupled to the MSYNC receiver) submits transport layer feedback (FB) messages in NACK mode (Generic NACK) to the RTP Repair Server according to [RFC4585] and [RFC5506]. The format of the feedback message is based on Section 6.1 and Section 6.2 of [RFC4585] with the following setting: padding bit cleared (0), payload type set to "RTPFB" (205), FMT set to "Generic NACK" (1). The SSRC of packet sender MUST be unique. It is attached to the MSYNC receiver. It MAY be based on the IPv4 or IPv6 address of the MSYNC receiver unicast interface. The SSRC of media source MUST correspond to the SSRC of the RTP multicast session to be repaired (see Section 3.9.1). The Feedback Control Information (FCI) format is detailed in Section 6.2.1 of [RFC4585]. - The RTP Repair server receives, processes and responds to the feedback NACK messages (FB) according to [RFC4588]. It matches the SSRC media source present in the feedback (FB) message with the SSRC or the original RTP multicast session. The RTP Repair server MAY be located within the multicast server or it MAY be Bale et aL. Expires June 5, 2025 [Page 28] Internet-Draft MSYNC December 2, 2024 hosted by any intermediate entity acting as a multicast RTP receiver (i.e., capable of receiving the multicast RTP packets gathering MSYNC packets). In any case, the RTP Repair server and the RTP Repair client MUST operate a unicast interface. The format of the retransmission packets is based on Section 4 of [RFC4588] with the following setting: when sending a retransmission packet (an RTP packet indeed), the RTP Repair Server MUST use the same payload type (PT) as the one used in the original RTP header transporting the MSYNC packets (see Section 3.9.1). The SSRC value MUST be identical to the SSRC of media source value, present in the corresponding feedback message. - The Session-multiplexing scheme [RFC5761] MUST be applied. The RTP retransmission (repair) stream MUST be sent over a unicast interface to the Repair client and therefore MUST NOT be part of the RTP multicast session used to transmit the original (multicast) RTP stream. - The RTP Repair client and the RTP repair server SHOULD use the same UDP port numbers arrangement in order to facilitate the firewall traversal. The source port number of a RTCP packet (feedback NACK message) SHOULD correspond to the destination port number of the RTP retransmission packet. Multicast server + ----------------- + | HAS | MSYNC | | Ingest | Sender | + ----------------- + | | + ------ + multicast | RTP | | ------->| Repair | | | Server | | + ------ + V ^ + ------------------------- + | | HAS | MSYNC | RTP | <--- | | |Repair | unicast | Server |Receiver |Client | + ------------------------- + Multicast gateway Figure 9: RTP repair The Figure 10 represents a typical repair workflow. The interface between the MSYNC Receiver and the RTP Repair Client is Bale et aL. Expires June 5, 2025 [Page 29] Internet-Draft MSYNC December 2, 2024 implementation dependent. Whenever the MSYNC receiver detects one or more packet losses attached to a RTP multicast session, it generates a Repair request (step 1 in Figure 10). One possible implementation of this interface consists into communicating the parameters SSRC (of the media source, i.e. the RTP multicast session), PID and BLP as defined in Section 6.2.1 of [RFC4585]. PID is the RTP sequence number of the first lost RTP packet of a potential series of lost RTP packets to be retrieved. BLP is a 16 bits field reporting loss of any of the 16 RTP packet following the first RTP packet represented by the PID parameter. Note that implementation dependent interface could allow a request with several PID/BLP parameters pairs as this is possible with [RFC4585]. The RTP Repair Client submits a RTCP packet to the RTP Repair Server (step 2 of Figure 10) that contains the Feedback NACK message with the Feedback Control Information (FCI) gathering the PID and BLP parameters as specified in [RFC4585]. The RTP Repair Server processes the request and retrieves in its cache the set of requested RTP packets and send them back to the RTP Repair Client conforming to [RFC4588] and the restrictions specified above (step 3 of Figure 10). The size of the RTP Repair server cache is application dependent. Finally, the RTP Repair Client communicates the retransmitted packets to the MSYNC receiver. MSYNC RTP Repair RTP Repair Receiver Client Server | Repair(SSRC, PID, BLP) | | |------------------------>| | (1) | | RTCP FB NACK | | |------------------------>| (2) | | | | | RTP Retrans. packets | (3) | |<------------------------| | RTP Retrans. Packets | | |<------------------------| | (4) | | | Figure 10: RTP Repair workflow Note that instead of relying on "RTP retransmission", the MSYNC receiver (i.e., the multicast gateway) could attempt to recover/repair damaged HAS elements (e.g., segments, manifest) through HTTP (aka "HTTP repair") and byte-range requests. However the latter method requires a CDN, relies on HTTP Byte-range request for Bale et aL. Expires June 5, 2025 [Page 30] Internet-Draft MSYNC December 2, 2024 which the support is not harmonized and is less reactive than operating RTCP (UDP transactions over a dedicated path are typically much quicker than HTTP/TCP transactions over the unicast broadband data path). 3.10. Configuration 3.10.1 MSYNC Configuration This section lists the essential configuration parameters related to the MSYNC sender and the MSYNC receiver. The goal is neither to specify the parameters list attached to the whole application exploiting MSYNC such as the Multicast Server or the Multicast Gateway (see Figure 1) nor the format of such configuration list that are both the subject of external specifications as [DVB-MABR]. Congestion avoidance: parameters for avoiding congestion as discussed in Section 2.3. - Maximum Sender bandwidth (MAX_BW_SEND): corresponds to the maximum guaranteed bandwidth dedicated to MSYNC allowing to transport the provisioned HAS session(s) across all multicast sub-networks up to the last multicast sub-network ingress point (e.g., the last router or bridge) before reaching the MSYNC receiver. - Maximum Receiver bandwidth (MAX_BW_RECEIVE): Represents the provisioned capacity dedicated to MSYNC over the last multicast sub-network the MSYNC receiver is connected to. RTP Encapsulation: This is optional but required for relying on RTP retransmission as discussed in Section 3.9. - RTP Repair Server: If RTP retransmission is available, IP address (or fully qualified domain name) and UDP port number of the RTP Repair Server. - RTP Payload type: One parameter that cannot be fixed whatever the deployment is the RTP Payload type. This parameter concerns the MSYNC Sender when operating RTP. 3.11. MSYNC workflow example In this section we depict a sequence diagram that illustrate a full MSYNC sequence as part of a media streaming application example that involves a multicast server and a multicast gateway (Figure 1). The workflow allows to better understand and separate the operations Bale et aL. Expires June 5, 2025 [Page 31] Internet-Draft MSYNC December 2, 2024 attached to MSYNC from those attached to the application elements. An application programmable interface (API) exposed by the MSYNC sender and MSYNC receiver is assumed for the sake of clarity but is purely informative. In the following Figure 10, the '*' character indicates a repetition of the transaction. The number in parenthesis refers to an explanation of the transaction given below the figure. HAS MSYNC MSYNC HAS terminal ingest sender receiver server player | | | | | |<--(1) (2)-->| |<--(3) | | |<----(4)---->| | | | |-----(5*)--->| |<----(7)---->| | | |-----(6*)--->| | | | | |-----(8)---->| | | | |<----(10)----|<----(9)-----| | | |----(11*)--->|-----(12)--->| | | | |<---(13*)----| | | | |----(14*)--->| | | |<----(16)----|<----(15)----| | | |----(17*)--->|-----(18)--->| | | | |<---(19*)----| | | | |----(20*)--->| Figure 10: RTP Repair workflow (1): The multicast server is configured for delivering a new HAS live service over multicast that means configuring the HAS ingest and the MSYNC sender. The HAS ingest gets configured to fetch all the elements announced in the manifest file associated with the new service. We assume a DASH [MPEGDASH] manifest file that describes a service with 2 adaptation sets (audio, video) and 2 representations for each of those adaptation sets. The HAS ingest is configured for delivering the new elements related to that live service. A transport multicast session arrangement (said HAS configuration) is provided targeting ADSL access, according to the following (the bandwidth and relative URL parameters are extracted from the manifest file). - Service Live1: manifest url: https://provider.cdn.com/live/channel2/dash/manifest.mpd. - Video1: transport multicast session = 232.0.0.1:17000; relative URL= "video1/$number$.mp4"; bandwidth="1000000". - Video2: transport multicast session = 232.0.0.2:17000; relative URL= "video2/$number$.mp4"; bandwidth="2500000" Bale et aL. Expires June 5, 2025 [Page 32] Internet-Draft MSYNC December 2, 2024 - Audio1: transport multicast session = 232.0.0.3:17000; relative URL= "audio1/$number$.mp4"; bandwidth="192000" - Audio2: transport multicast session = 232.0.0.3:17001; relative URL= "audio2/$number$.mp4"; bandwidth="384000" In addition , The HAS ingest is configured to operate a dedicated Control channel according to the following. - Control: transport multicast session = 232.0.0.4:17002. Note that the Control session is used by the application to communicate to the HAS Server the transport multicast session arrangement. (2): The MSYNC sender is configured with the following information. RTP encapsulation with RTP retransmission (see 3.10). The Maximum MSYNC Sender bandwidth is configured: MAX_BW_SEND = 4500000 bps. (3): The MSYNC receivers are configured for supporting RTP reception as well as RTP retransmission conforming to Section 3.10. The maximum MSYNC receiver bandwidth is configured: MAX_BW_RECEIVE = 3500000 bps that is the same configuration for all MSYNC receivers assuming they are all connected to the same access network that guaranties this minimum available bandwidth. (4): The HAS ingest and the MSYNC sender establish a connection wherein the MSYNC sender communicates its limitation (MAX_BW_SEND) and in return gets the new provisioned service "Live1" and the provisioned Control channel that is accepted. (5): The HAS ingest sends continuously (carousel) the transport multicast session arrangement for all configured services (here only one service: Live1) to the MSYNC sender along with the transmission parameters (Control transport multicast session, object type = "Control", Object URI="HAS/config"). In parallel, the HAS Ingest fetches the representation elements concurrently and according to the manifest. Those elements and the manifest itself are sent to MSYNC sender with, for each, the indication of the channel (i.e. the transport multicast session) to be used for the transmission, the object type, the media sequence and the manifest type (only for the manifest) and the object URI. The objects are sent of the transport multicast session according to the following arrangement. - initialization segments: sent over the corresponding video transport multicast session and repeated after every segment. Note that the HAS ingest could also decide to send the initialization segment over the Control multicast session or Bale et aL. Expires June 5, 2025 [Page 33] Internet-Draft MSYNC December 2, 2024 even decide not to rely on MSYNC but on the CDN (i.e. the HAS server, in the multicast gateway when the initialization segment is requested would fetch it from the unicast path). Object URI = "provider.cdn.com/live/channel2/dash/video[x]/init.mp4" - video segments: sent over the corresponding video transport multicast session. Object URI = "provider.cdn.com/live/channel2/dash/video[x]/[segment name]" - audio segment: sent over the corresponding video transport multicast session. Object URI = "provider.cdn.com/live/channel2/dash/audio[x]/[segment name]" - manifest file: sent (duplicated) over each of the 2 video transport multicast sessions, after a video segment is sent. Note that the HAS ingest could also decide to send the manifest file over the Control multicast session. Object URI = "provider.cdn.com/live/channel2/dash/manifest.mpd" (6): The MSYNC sender transmits the objects on demand (from the HAS ingest) and according to Section 3.8 in each of the indicated Transport multicast session. The MSYNC sender MUST continuously adapt the transmission rate to its maximum permitted MAX_BW_SEND. (7): The HAS server and MSYNC receiver establish a connection wherein the MSYNC receiver communicates its bandwidth restriction (MAX_BW_RECEIVE) and in return, the HAS server instructs the MSYNC Receiver to join the control multicast session. (8): The MSYNC receiver joins the control multicast session, receives the transport multicast session arrangement ("HAS/config" ) and communicates that HAS configuration file to the HAS server. (9): The player requests the manifest: https://provider.cdn.com/live/channel2/dash/manifest.mpd. In this example, the application indicates the original CDN FQDN (full qualified domain name) in the URL per convention. (10): The HAS server matches the requested URL with the manifest URL attached to the configured service and instructs the MSYNC receiver to join one of the representations combination (i.e. one of the video transport multicast session and the audio transport multicast session) by default. Note that the HAS server can decide to hold the player's request until the requested manifest is received through MSYNC or it can fetch the manifest from the CDN over the unicast path to accelerate the work flow. - Video1: transport multicast session = 232.0.0.2:17000; Bale et aL. Expires June 5, 2025 [Page 34] Internet-Draft MSYNC December 2, 2024 relative URL= "video2/$number$.mp4"; bandwidth="2500000" - Audio1: transport multicast session = 232.0.0.3:17001; relative URL= "audio2/$number$.mp4"; bandwidth="384000" (11) The MSYNC receiver joins the Video1 and Audio IP multicast groups, receives MSYNC packets and delivers the media manifests and segments to the HAS Server along with their Object URI. The HAS Server stores the element in its cache along with its cache key (built with the Object URI). (12) The HAS server detects the presence of the requested manifest in its cache and returns it to the player. Note that the manifest object should be complete; potential transmission errors have been managed by the MSYNC receiver through RTP retransmission (Section 3.9.2). Note that without RTP retransmission, the MSYNC receiver would have communicated the received object to the HAS server with possibly the list of missing byte ranges. (13) The player parses the manifest and requests the segments from video1/Audio1 representations as well as the manifest (possibly updated). (14) The HAS server either find the requested element in its cache or fetch it from the CDN and return them to the Player. Note that the element should be complete. Potential transmission errors would have been managed by the MSYNC receiver through RTP retransmission (Section 3.9.2). Note that without RTP retransmission, the MSYNC receiver would have communicated each received object to the HAS server with the list of any missing byte ranges. (15) The player wishes to switch to an higher sub-stream representation and requests an element from the Video2 representation. (16) The HAS server gets a cache miss, detects that the MSYNC receiver is not tuned to the right channel. It instructs the MSYNC receiver to first leave Video1 and then join Video2. The HAS server does that as it knows the bandwidth restriction announced by the MSYNC receiver. Note that the MSYNC receiver would have refused to Join Video2 while being still attached to Video1. Note also that the HAS server can decide to hold the player's request until the requested object is received through MSYNC or it can fetch the object from the CDN over the unicast path to accelerate the work flow. (17) The MSYNC receiver leaves the current IP multicast group Bale et aL. Expires June 5, 2025 [Page 35] Internet-Draft MSYNC December 2, 2024 corresponding to Video1 and joins the IP multicast group corresponding to Video2, receives MSYNC packets and sends media manifests/segments to the HAS Server along with their Object URI. (18) The HAS server receives the objects, store them in its local cache and returns the requested element to the player. (19) The player requests the segment from video2/Audio2 representations or the manifest (possibly updated). (20) The HAS server either find the requested element in its cache or fetch it from the CDN and return it to the Player. Bale et aL. Expires June 5, 2025 [Page 36] Internet-Draft MSYNC December 2, 2024 4. IANA Considerations This document has no actions for IANA. 5. Security Considerations MSYNC is exposed to the risks linked to the underlying transport protocols: UDP and RTP. An attacker can spoof the source and destination addresses, modify any MSYNC headers and, because MSYNC applies to IP multicast, the MSYNC sender has no control about the MSYNC receivers which may represent a non-authorized party. The multicast communication between the MSYNC sender and the MSYNC receiver SHOULD be protected against confidentiality leaks, message tampering and replay attacks. The MSYNC protocol does not specify any security mechanism . MSYNC relies on possibly content protection (Digital Right Management) and on the underlying transport layer and security extensions for providing message integrity, authentication and encryption. Secure RTP (SRTP) [RFC3711] and IPsec applied to multicast [RFC5374] are potential candidates for providing such extensions. As MSYNC supports transporting HTTP headers, it MAY also supports HTTP based mechanisms for integrity protection and authentication as specified by [RFC9530] and [RFC9421] respectively and profiled for multicast by [DVB-MABR]. Based on asymmetric cryptography, the authentication method specifies a digital signature [RFC9421] protecting a content digest [RFC9530] and a certain number of HTTP headers complemented with derived components such as the MSYNC Object URI. The signature itself is computed with a well identified/permitted algorithm and a private key attached to a X.509 certificate [RFC5280] . A dedicated HTTP header transports the algorithm identifier and the public key identifier that corresponds to the subject key identifier of the same X.509 certificate [RFC5280]. The content digest [RFC9530] is transported as a dedicated HTTP header field and is applied to the payload data of an MSYNC object transported with MSYNC Object data packets or MSYNC Object data-part packets. . 6. References 6.1. Normative References [ID-HTTPLIVESTREAM] R Pantos, IETF Internet draft: "HTTP Live Streaming 2nd Edition", draft-pantos-hls-rfc8216bis-14, 10 November 2023 Bale et aL. Expires June 5, 2025 [Page 37] Internet-Draft MSYNC December 2, 2024 [MPEGCMAF] "Information technology - Multimedia application format (MPEG-A) - Part 19: Common media application format (CMAF) for segmented media", ISO/IEC 23000-19 [MPEGDASH] "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part1: Media presentation description and segment formats", ISO/IEC23009-1 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, November 1997, [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003, . [RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005, https://www.rfc-editor.org/rfc/rfc3986.html [RFC5506] I. Johansson, M. Westerlund. "Support for Reduced-Size Real-Time Transport Control Protocol(RTCP): Opportunities and Consequences", RFC 5506, April 2009, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010, . [RFC8216] R. Pantos, Ed., W. May, "HTTP Live Streaming", RFC 8216, August 2017, [RFC9112] R. T. Fielding, M. Nottingham, J. Reschke, " HTTP/1.1", RFC 9112, June 2022, . [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. Bale et aL. Expires June 5, 2025 [Page 38] Internet-Draft MSYNC December 2, 2024 6.2. Informative References [BFTR145] "TR-145 Multi-service Broadband Network Functional Modules and Architecture, Issue: 1, Iddue date: November 2012", Technical report, Broadband Forum. [BFTR178] "TR-178 Multi-service Broadband Network Architecture and Nodal Requirements, Issue: 2, Issue Date: September 2017", Technical report, Broadband Forum. [MPEG2TS] "ISO/IEC 13818-1 Generic coding of moving pictures and associated audio information: MPEG2 Systems" [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003, . [RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004, . [RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4585, July 2006, [RFC4585] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey. "Extended RTP Profile for Real-time Transport Control Protocol(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006, . [RFC5280] : D. Cooper, S. Santesson, S. Farrel, S. Boeyen, R. Housley, W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", IETF RFC 5280, May 2008, [RFC5374] B. Weis, G. Gross, D. Ignjatic. "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008, . Bale et aL. Expires June 5, 2025 [Page 39] Internet-Draft MSYNC December 2, 2024 [RFC6770] G. Bertrand, E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012 [RFC7336] L. Peterson, B. Davie, R. van Brandenburg, "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, August 2014 [RFC8084] G. Fairhurst, "Network Transport Circuit Breakers", RFC 8084, March 2017 [RFC8085] L. Eggert, G. Fairhurst, G. Shepherd, "UDP Usage Guidelines", RFC 8085, March 2017 [RFC9530] R. Polli, L. Pardue, "Digest Fields", RFC 9530, February 2024 [RFC9421] A. Backman J. Richer, M. Sporny, "HTTP Message Signatures", RFC 9421, February 2024 [DVB-MABR] "Adaptive media streaming over IP multicast", DVB BlueBook A176r4, July 2023 7. Acknowledgments The authors will be ever grateful to their late colleague Arnaud Leclerc who has been the initiator of that work. The authors would like to thank the following people for their feedback: Yann Barateau (Eutelsat). 8. Change Log - 17: Clarify the role and operations strictly attached to the MSYNC sender and receiver (sections 2.1 and 3.11). Harmonize some editorial choices. - 16: "Digest Fields" and "HTTP Messages signatures" Internet drafts became RFC 9530 and RFC 9421 respectively. Authors address updated. - 15: Section 3.9 detailed including a figure about the RTP repair workflow. Two new sections dedicated to MSYNC configuration (3.10) and a complete MSYNC transport session workflow (3.11). Various editorial updates including some more details in the Security section . - 14: A set of editorial changes after a review from Markus . Bale et aL. Expires June 5, 2025 [Page 40] Internet-Draft MSYNC December 2, 2024 - 13: A minor edit in Section 3.7.3. - 12: An extensive review of grammatical and orthographical bugs. Adding clarification regarding congestion control. - 11: Another round of grammatical/orthographical errors correction. Clarified the Figures 1 and 2 regarding the directional media flows, adding a statement in the introduction about multicast and capacity planning - 10: Introduced sub-sections in Section 2 allowing to describe the multicast network assumptions and in particular related to congestion avoidance (pre-provisioning the bandwidth resources) . Similarly introduced new sub-sections in Section 3.7 for describing congestion control. Performed several minor editorial corrections. Corrected the new mtype value associated with the media HAS playlist. - 09: New set of editorial/clarification changes. Added a new mtype value (Section 3.2) for differentiating master and media HLS playlist backward compatible. - 08: Another round of editorial changes - 07: Lots of editorial changes - 06: Example in Section 3.8.1.2. update the example for using the "#" character as the bloc number prefix instead of the "_" character. - 05: Updated Section 3.9 adding reference (RFC4588) and details for RTP retransmission. Updated/normalized references in Section 5.1 and Section 5.2. - 04: Added detection of super object transmission (Section 3.2 and Section 3.8.1.2); several adjustments regarding RFC style; Section numbering correction.(Sections 3.9 and 3.10 are now Sections 3.8 and 3.9 respectively). Authors' Addresses Sophie Bale Broadpeak 3771 Bd des Allies, 35510 Cesson-Sevigne France Email: sophie.bale@broadpeak.tv Bale et aL. Expires June 5, 2025 [Page 41] Internet-Draft MSYNC December 2, 2024 Remy Brebion Broadpeak 3771 Bd des Allies, 35510 Cesson-Sevigne France Email: remy.brebion@broadpeak.tv Guillaume Bichot (Editor) Broadpeak 3771 Bd des Allies, 35510 Cesson-Sevigne France Email: guillaume.bichot@broadpeak.tv Bale et aL. Expires June 5, 2025 [Page 42]