Internet-Draft S. Bale Intended Status: Informational R. Brebion Expires: September 11, 2023 G. Bichot Broadpeak March 10, 2023 MSYNC draft-bichot-msync-09 Abstract This document describes the Multicast Synchronization (MSYNC) Protocol that aims at transferring video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifest/playlists and media segments (e.g. CMAF) according to an 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) 2023 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 September 11, 2023 [Page 1] Internet-Draft MSYNC March 10, 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. MSYNC Protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. MSYNC Packet Format . . . . . . . . . . . . . . . . . . . . 8 3.2. Object Info Packet . . . . . . . . . . . . . . . . . . . . 9 3.3. Object Data Packet . . . . . . . . . . . . . . . . . . . . 12 3.4. Object HTTP Header Packet . . . . . . . . . . . . . . . . . 12 3.5. Object Data-part Packet . . . . . . . . . . . . . . . . . . 14 3.6. Maximum Size of an MSYNC Packet . . . . . . . . . . . . . . 15 3.7. Sending an receiving MSYNC Objects Over Transport/IP Multicast Sessions . . . . . . . . . . . . . . . . . . . . 15 3.8. HAS Protocol Dependency . . . . . . . . . . . . . . . . . . 17 3.8.1. Object Info Packet . . . . . . . . . . . . . . . . . . 17 3.8.1.1. Media Sequence . . . . . . . . . . . . . . . . . . 17 3.8.1.2. Object URI . . . . . . . . . . . . . . . . . . . . 18 3.8.2. Sending Rules . . . . . . . . . . . . . . . . . . . . . 20 3.9. RTP As The Transport Multicast Session Protocol . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Normative References . . . . . . . . . . . . . . . . . . . 22 6.2. Informative References . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Bale et aL. Expires September 11, 2023 [Page 2] Internet-Draft MSYNC March 10, 2023 1 Introduction Transporting media content over multicast is known to be very effective for saving network resources (bandwidth). Multicast is available and used by Internet service providers for providing IPTV services. The IPTV technology relies essentially on MPEG Transport Stream (MPEG TS) format, UDP transport and IP multicast while the HTTP adaptive bit-rate streaming (HAS), a unicast "Over The Top" technology relies on HTTP /TCP, new container formats (as MP4/CMAF) and signaling protocols (Apple HLS, MPEG DASH). With the generalization of HAS streaming there is a need to operate multicast in order to achieve the same level of bandwidth efficiency provided by an IPTV service. MSYNC allows transporting HTTP based ABR flows over multicast relying on IP/UDP and optionally RTP that makes it particularly suited for transitioning IPTV legacy (MPEG2 TS) to the HAS ecosystem. MSYNC is simple (no congestion control, no forward error correction) although reliable (enable easy coupling with a unicast based repair protocols) and extensible; it has been experimented and deployed over various IPTV infrastructures (xDSL, cable, fiber) and satellite. 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 the method that consist in change 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) 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 downloading first a manifest file(s), then 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. init segment: A piece of a media sub-stream used to initialize the decoder as specified in [MPEGCMAF]. manifest: A file gathering the configuration for conducting a Bale et aL. Expires September 11, 2023 [Page 3] Internet-Draft MSYNC March 10, 2023 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: Gathers one or more media sub-streams. media sub-stream: A version of a media encoded in a particular bit- rate, format and resolution; also called representation or variant stream. media segment: A piece of a media sub-stream of a fixed duration (e.g. 2s) as specified in [MPEGCMAF]. media chunk: A piece of a media segment of a fixed duration as specified in [MPEGCMAF]. MSYNC object: As part of a HAS session carried over MSYNC, an MSYSNC object can be an addressable HAS entity like an initialization segment, a media segment (or fragment, or chunk), a manifest (or playlist). An MSYNC object can also be a non-addressable transport entity like a part of a segment (an HTTP2 frame or an HTTP/1.1 CTE block). An MSYNC object is sent by an MSYNC sender over a transport multicast session and receives by an MSYNC receiver. MSYNC super object. When an object to be transmitted is composed of parts delivered on the fly when available in such a way the size of an object to be transmitted is unknown in advance, it is called a super object. A super object may correspond to a stream or a media segment not yet completely generated/received and for which the size 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 according to MSYNC. It is typically part of a multicast gateway that receives MSYNC objects relying on the MSYNC receiver and reconstructs/serves in unicast the original HAS session on demand (i.e. based on HAS player requests). MSYNC sender. The MSYNC end point that sends MSYNC objects over multicast according to MSYNC. It is typically part of a multicast server that acquire HAS session payload and send it over multicast as MSYNC objects relying on the MSYNC sender. Bale et aL. Expires September 11, 2023 [Page 4] Internet-Draft MSYNC March 10, 2023 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]; corresponds to a representation as defined by [MPEGDASH]. MSYNC channel: The set of transport multicast sessions carrying a HAS session as a set of MSYNC objects. MSYNC control channel: the transport multicast session carrying control plane MSYNC objects. As part of the control channel, an MSYNC object may transport some control plane information (as e.g. the MSYNC receiver configuration). IP multicast session: A session gathering transport multicast sessions having the same source IP address and destination multicast IP address. transport multicast session: Operating a transport protocol that is based UDP over IP multicast. A transport multicast session is identified by the 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 MSYNC is a simple protocol typically (but not only) used between a multicast server (hosting the MSYNC sender) and a multicast gateway (hosting the MSYNC receiver) as represented in the figure 1. 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 link according to MSYNC supporting [possibly RTP/] UDP/IP multicast up to the multicast gateways. A multicast gateway listens the corresponding multicast flows and serve 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 some 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) over a unicast link. Considering one among several possible content ingest methods (e.g. HTTP GET), for each HAS Bale et aL. Expires September 11, 2023 [Page 5] Internet-Draft MSYNC March 10, 2023 session, the multicast server behaves as a sort of HAS player, reading the manifest, discovering the available representations and downloading concurrently media segments of all (or a subset) of the available representations. Finally the multicast server is configured for sending all those HAS session elements over [possibly RTP/]UDP/IP multicast according to a certain UDP flow arrangement (for example all the objects related to each video representation are sent over a separate multicast transport session (multicast IP address + port number) whereas all audio representations are sent over the same transport multicast session. As this is about streaming and even most of the time live streaming, MSYNC does not provide congestion control. The multicast server (the MSYNC sender) is configured for exploiting the UDP flow arrangement with a maximum bandwidth limit. The Multicast gateway is configured (by the same ISP having configured the multicast server) for being aware of the same UDP flow arrangement in order to listen and to receive the right transport multicast sessions (as an example the MSYNC receiver must "Join" the multicast IP group addresses associated with that UDP flow arrangement. Note that the multicast gateway might not be capable of being attached to all the concurrent transport multicast sessions in the same time per bandwidth restriction (e.g. ADSL). In that case, the multicast gateway attaches to the transport multicast session corresponding to the player's request (and detaches from the other previous one). The configuration of the MSYNC sender and MSYNC receiver is out of the scope of this document. At any time, the multicast gateway can detect corrupted and/or lost packets and attempt to repair using a repair protocol. This is possible interacting with the HAS content delivery network (CDN) or thanks to the RTP protocol if used as the transport layer over UDP (see section 3.9). The multicast gateway receives the MSYNC objects and is ready to serve it (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 cache hit, it returns the object. In case of cache miss, the multicast gateway can possibly retrieve the requested object from the associated CDN (or a dedicated server) over an unicast interface (if existing) through operating HTTP conventionally and forwards back to the HAS player the object once retrieved. Bale et aL. Expires September 11, 2023 [Page 6] Internet-Draft MSYNC March 10, 2023 Unicast server Multicast server +-------- + + -------------------- + | HAS | < -- unicast --> | HAS | MSYNC | | CDN | | Ingest | Sender | + ------- + + ---------------------+ ^ ^ | | | | unicast - - - - -unicast - - - - - multicast | | | v v V +-------- + + -------------------- + | HAS | < -- unicast --> | HAS | MSYNC | | Player | | Server |Receiver | + ------- + + ---------------------+ End-user Multicast gateway terminal Figure 1: example of MSYNC deployment The figure 1 shows a typical MSYNC deployment where a HAS player may interacts with an HAS server in a unicast way over e.g. Internet and may also interact with a multicast gateway over e.g. a local network (LAN) according to the same HAS protocol. With MSYNC deployed over a multicast link/network, the HAS player gets basically the 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 to be co-located with the media player and therefore embedded in the end-user terminal as shown in the figure 2. Multicast server +-------- + + -------------------- + | HAS | < -- unicast --> | HAS | MSYNC | | Server | | Player | Sender | + ------- + + ---------------------+ ^ | | | unicast multicast | | v | + ----------------- + | | HAS | MSYNC |<------------------------- | Player |Receiver | + ------------------+ End-user terminal Figure 2: MSYNC receiver in the terminal Bale et aL. Expires September 11, 2023 [Page 7] Internet-Draft MSYNC March 10, 2023 Note that nothing precludes application dependent features in the multicast server and/or the multicast gateway that may adapt/modify the content delivered to the end-user player. 3. MSYNC Protocol 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 = 0x3 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 The field identifies the object being transferred in a multicast transport session. Considering one multicast transport 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 Bale et aL. Expires September 11, 2023 [Page 8] Internet-Draft MSYNC March 10, 2023 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 re-ordering is discussed in 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 is given in the next sections. data: series of D x 8 bits This field is optional and is present depending 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 depicted in 3.6. 3.2. Object Info Packet The Object info packet is used to transport the meta-data associated with an object. It permits to characterize the object in term of e.g. size and type. The 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 the object info packet relates to. Bale et aL. Expires September 11, 2023 [Page 9] Internet-Draft MSYNC March 10, 2023 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 payload transported with a MSYNC object data packet (Section 3.3) or MSYNC object data-part packet (Section 3.5). The maximum size of an object (4.4 Gbytes) authorizes the transfer of a video segment of several tens of seconds, 4K encoded. The size may be 0 indicating that there is no corresponding object's 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). 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 packets MUST be null (set to 0). Bale et aL. Expires September 11, 2023 [Page 10] Internet-Draft MSYNC March 10, 2023 object CRC: 32 bits A CRC-32 applied to the object data payload for corruption detection. 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: reserved for future use. 0x01: media manifest (playlist) 0x02: unknown 0x03: media data or data-part: Transport stream (MPEG2-TS) 0x04: media data or data-part: MPEG4 (CMAF) 0x05: control: control plane information (e.g. multicast gateway configuration) 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 0x00 (non applicable) otherwise. The field can take the following values. 0x00: Not Applicable 0x01: MPEG Dash as specified in [MPEGDASH]. 0x02: Master HLS playlist as specified in [RFC8216]. 0x02: Media HLS playlist as specified in [RFC8216]. 0x03-0xF: Reserved object URI size: 12bits The size in bytes of the object URI field. The value MUST guarantee that the MSYNC info packet size is not greater than the network MTU. media sequence: 32 bits It is a sequence number associated with the MSYNC objects data and data-part (for transporting a segment or a manifest). It is dependent on the mtype value. It is used to synchronize unicast and multicast receptions in the multicast gateway. 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 receivers MUST ignore it. object URI: Quotient((object URI size * 8)/32) bits + 32 bits if remainder ((object URI size * 8)/32) >0 This the path name associated with the object. 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 Bale et aL. Expires September 11, 2023 [Page 11] Internet-Draft MSYNC March 10, 2023 rules for HAS delivery are detailed in the section 3.8 dedicated to the HAS protocol dependencies. The object URI is coded as a series of string characters. Remaining non used bytes of the last 32 bits field MUST be filled with the 0x00 value. 3.3. Object Data Packet This MSYNC packet carries part or all of the the object's data payload. The type of data and the way to process the object's data packets is function of the associated object's info packet. Object payload is transported through a series of object data packets. 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 is to be written in order to compose the object data at the receiver side (i.e. the multicast gateway). The first data packet of an object has an offset equal to 0. data: N x 8bits The size N is not declared; it is bounded by the maximum size of the under-laying transport multicast session packet (e.g. RTP) as depicted in Section 3.6. The total size (number of bytes) of the object data is indicated in the associated object info (field object size). 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 use by the application operating MSYNC. For example, considering the Figure 1, the HAS Ingest Bale et aL. Expires September 11, 2023 [Page 12] Internet-Draft MSYNC March 10, 2023 component in the multicast server may ingest some HTTP headers useful for the HAS server in the multicast gateway to be served to the HAS player. 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 data-part) that can be repeated. The transport of the HTTP header fields MUST be conform to HTTP/1.1 section 5 of [RFC9112]. When 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 identifier is the same than the one present in the object data packets or object data-part packets it relates to. 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 8bits The size N is not declared; it is bounded by either the header size field value or by the maximum size of the under-laying transport packet(e.g. RTP)as depicted in Section 3.6. Bale et aL. Expires September 11, 2023 [Page 13] Internet-Draft MSYNC March 10, 2023 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 is function of the associated info packet. Object 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 too. All data-part objects composing a super object have a different object identifier. The way to link data-part objects with a super object is thanks to the object info packet (object URI) 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. 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 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 Bale et aL. Expires September 11, 2023 [Page 14] Internet-Draft MSYNC March 10, 2023 has an offset equal to 0. 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. data: N x 8bits The size N is not declared; it is bounded by the maximum size of the under-laying transport packet (e.g. RTP) as depicted in the section 3.6. The total size (number of bytes) of the object data is indicated in the associated object info (field object size). 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), then 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. 3.7. Sending an receiving MSYNC Objects Over Transport/IP Multicast Sessions The following considerations are linked to the MSYNC sender and MSYNC receiver configuration. Note that the configuration procedure (protocol and format) is out of the scope of that document. The mapping of MSYNC objects onto transport/IP multicast sessions is not constrained by the MSYNC protocol. The multicast IP flow arrangement is chosen (typically by the ISP) function of the network architecture and capacity. For example, with xDSL, the capacity dedicated to multicast is limited which may drive to a IP multicast flow arrangement where each sub-stream/representation matches with one dedicated IP multicast session. The MSYNC receiver switches to the IP transport multicast session corresponding to the sub-stream/representation it should serve to the end user terminal/player. Alternatively, one would like to have one IP multicast session (with possibly multiple transport multicast sessions, each having a different destination port Bale et aL. Expires September 11, 2023 [Page 15] Internet-Draft MSYNC March 10, 2023 number) for the entire HAS session/MSYNC channel that is an arrangement a la "IPTV", less bandwidth efficient but where only one multicast IP address is allocated per HAS session/MSYNC channel. Considering a satellite network, as all transport multicast sessions are carried simultaneously, all IP multicast flow arrangements may make sense. Regarding the mapping onto a transport multicast session, the triplet: source IP address (MSYNC supports Source Specific Multicast), destination multicast IP address and destination transport port number is the discriminator. It is RECOMMENDED to carry media sub-streams and the control channel in separate transport multicast sessions because It permits the deployment of different error correction (see section 3.9) or content protection procedure (e.g. one ISP may decide to encrypt the control channel). The following arrangement is possible: - 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 MSYNC control channel. It is perfectly possible to send all the MSYNC packets in only one transport multicast session. For each MSYNC object (see object type in 3.2) to be sent over a multicast 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 more HTTP header packets (in a sequential order) and one or more object data packets (or object data-part packets) in a sequential order. Note that when the MSYNC object is a of size null (used to signal the end of the transmission of a super object) then only one object info packet is sent (see 3.2). The transmission time of an MSYNC object MUST be controlled in order to permit time bounded delivery (as e.g. required with HAS streaming). 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 un-ordered. Packet re- Bale et aL. Expires September 11, 2023 [Page 16] Internet-Draft MSYNC March 10, 2023 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 transmission may not be possible. An MSYNC implementation SHOULD 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 stops the timer 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. This is up to the application (e.g. the HAS server in Figure 2) to react with, for instance, an object repair procedure. The MSYNC sender MAY use the same maximum transmission time of a particular MSYNC object type for controlling the object identifier allocation (see 3.1). Note that packet repair and packet re-ordering can be performed at the underlying RTP, based on the RTP sequence number (see 3.9). MSYNC does not specify any rate control policy. However the MSYNC sender MAY be configured (configuration is out of the scope of this document) to apply a rate control policy. Typically when deploying in an environment that is bandwidth limited (e.g. ADSL), for each transport multicast session, the MSYNC sender may be constrained to deliver the MSYNC packets roughly at the rate corresponding to the average bit-rate of the media sub-stream video. 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 from 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 multicast gateway to synchronize the MSYNC (i.e. multicast) reception with unicast reception. The multicast gateway may operate jointly MSYNC/multicast and unicast for retrieving HAS elements as indicated in section 2 and illustrated in figure 1. This is useful in some occasions like processing a new streaming session request (i.e. a manifest request after a channel switch) or in the case of Bale et aL. Expires September 11, 2023 [Page 17] Internet-Draft MSYNC March 10, 2023 segment repair. The multicast gateway may attempt to retrieve a manifest object or segment(s) through a unicast mean (e.g. a CDN server or a repair server) in order to speed up the start of the session or to repair damaged object(s). Consequently, the multicast gateway needs to understand the freshness of the HAS object received through multicast with regard to unicast. If no unicast reception is used jointly with MSYNC in the multicast 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 (Info Packet header field presented in the section 3.2.) as listed below. HLS master playlist: 0x00 HLS variant playlist; MUST contain the value of EXT-X-MEDIA-SEQUENCE added with the position in the playlist of the last segment transmitted. HLS segment: MUST contain the value of EXT-X-MEDIA-SEQUENCE added with the position of the segment in the playlist. DASH manifest: MUST contain $time$/scale or $Number$ corresponding to the last segment transmitted or under transmission (and possibly received partially) and declared by the manifest. DASH segment: MUST contain the $time$/scale or $Number$ value 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 sub-string) 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" - The object URI /tvChannel11/Q1/S_2_3 matches with the CMAF chunk URL that is computed from the associated Bale et aL. Expires September 11, 2023 [Page 18] Internet-Draft MSYNC March 10, 2023 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 September 11, 2023 [Page 19] Internet-Draft MSYNC March 10, 2023 3.8.2. Sending Rules Whenever a manifest has to be sent over MSYNC, the following applies. - The corresponding MSYNC object data packets MUST be sent over all the transport multicast sessions related to the transmission of the media segments the manifest refers to. - It MUST reference addressable objects (segment or CMAF chunk) that have already been sent or for which the transmission has started. 3.9. RTP As The Transport Multicast Session Protocol RTP [RFC3550] MAY be used as part of the transport multicast session protocol with the restrictions defined in section 2 of [RFC3551] according to the following. - There is 0 contributing source identifiers (CSRC). - The timestamp is computed as indicated in [RFC3550]; it corresponds to the instant the MSYNC sender starts the MSYNC packet transmission. - The payload type (PT) MAY correspond to one of the values specified in [RFC3551]. Its value should be communicated to the MSYNC receiver as part of the MSYNC receiver configuration through a separate unspecified mean. - Each RTP multicast session MUST operate a unique different SSRC number [RFC3550]. This allows packet retransmission (if used) on the RTP transport multicast session basis. - RTCP usage is not required. Packet retransmission (see Figure 8 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], [RFC5506] and [RFC5761] according to the followings: - 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 [RFC5506] and [RFC4585]. Bale et aL. Expires September 11, 2023 [Page 20] Internet-Draft MSYNC March 10, 2023 - The RTP Repair server receives, processes and responds to the feedback NACK messages (FB) according to [RFC4588]. The RTP Repair server MAY be located within the multicast server or it MAY be hosted by any intermediate entity acting as a multicast RTP receiver (i.e. capable of receiving the multicast RTP packets). In any case, the RTP Repair server and the RTP Repair client MUST operate a unicast interface. - The Session-multiplexing scheme [RFC4588] MUST be applied: the RTP retransmission (repair) stream MUST be sent on a different RTP session than the original (multicast) RTP stream. - The retransmission stream MUST support multiplexing the RTP and RTCP traffic on a single port according to [RFC5761]. Multicast server + ----------------- + | HAS | MSYNC | | Ingest | Sender | + ----------------- + | | + ------ + multicast | RTP | | ------->| Repair | | | Server | | + ------ + V ^ + ------------------------- + | | HAS | MSYNC | RTP | <--- | | |Repair | unicast | Server |Receiver |Client | + ------------------------- + Multicast gateway Figure 8: RTP repair 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 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). Bale et aL. Expires September 11, 2023 [Page 21] Internet-Draft MSYNC March 10, 2023 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 (multicast server) and the MSYNC receiver (the multicast gateway) 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. 6. References 6.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003, . [MPEGDASH] "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part1:Media presentation description and segment formats",ISO/IEC23009-1 [MPEGCMAF] "Information technology - Multimedia application format (MPEG-A) - Part 19:Common media application format (CMAF) for segmented media"ISO/IEC 23000-19 [RFC5506] I. Johansson, M. Westerlund. "Support for Reduced-Size Real-Time Transport Control Protocol(RTCP): Opportunities and Consequences", RFC 5506, April 2009, . Bale et aL. Expires September 11, 2023 [Page 22] Internet-Draft MSYNC March 10, 2023 [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, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010, . [RFC9112] R. T. Fielding, M. Nottingham, J. Reschke, " HTTP/1.1", RFC 9112, June 2022, . 6.2. Informative References [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, . [RFC5374] B. Weis, G. Gross, D. Ignjatic. "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008, . [RFC8216] R. Pantos, Ed., W. May, "HTTP Live Streaming", RFC 8216, August 2017, . 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 Bale et aL. Expires September 11, 2023 [Page 23] Internet-Draft MSYNC March 10, 2023 - 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 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 section 3.8 and 3.9 respectively). Authors' Addresses Sophie Bale Broadpeak 15 rue Claude Chappe Zone des Champs Blancs 35510 Cesson-Sevigne France Email: sophie.bale@broadpeak.tv Remy Brebion Broadpeak 15 rue Claude Chappe Zone des Champs Blancs 35510 Cesson-Sevigne France Email: remy.brebion@broadpeak.tv Guillaume Bichot (Editor) Broadpeak 15 rue Claude Chappe Zone des Champs Blancs 35510 Cesson-Sevigne France Email: guillaume.bichot@broadpeak.tv Bale et aL. Expires September 11, 2023 [Page 24]