Skip to main content

MSYNC
draft-bichot-msync-13

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Sophie Bale , Remy Brebion , Guillaume Bichot
Last updated 2023-08-24 (Latest revision 2023-04-27)
RFC stream Independent Submission
Formats
Reviews
Stream ISE state In ISE Review
Awaiting Reviews
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bichot-msync-13
Internet-Draft                                                   S. Bale
Intended Status: Informational                                R. Brebion
Expires: October 29, 2023                                      G. Bichot
                                                               Broadpeak
                                                          April 27, 2023

                                 MSYNC 
                         draft-bichot-msync-13  

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) 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 October 29, 2023                [Page 1]
Internet-Draft                   MSYNC                    April 27, 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
     2.1. A typical MSYNC deployment  . . . . . . . . . . . . . . . .  5
     2.2. Unicast Networks  . . . . . . . . . . . . . . . . . . . . .  8
     2.3. Multicast Network and congestion avoidance  . . . . . . . .  8
     2.4. Handling third party content  . . . . . . . . . . . . . . . 10
   3. MSYNC Protocol  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1. MSYNC Packet Format . . . . . . . . . . . . . . . . . . . . 10
     3.2. Object Info Packet  . . . . . . . . . . . . . . . . . . . . 12
     3.3. Object Data Packet  . . . . . . . . . . . . . . . . . . . . 14
     3.4. Object HTTP Header Packet . . . . . . . . . . . . . . . . . 15
     3.5. Object Data-part Packet . . . . . . . . . . . . . . . . . . 16
     3.6. Maximum Size of an MSYNC Packet . . . . . . . . . . . . . . 17
     3.7. Sending and Receiving MSYNC Objects . . . . . . . . . . . . 18
       3.7.1. Mapping over Transport Multicast Sessions . . . . . . . 18
       3.7.2. Detecting the End of an Object Reception  . . . . . . . 19
       3.7.3. Congestion Control  . . . . . . . . . . . . . . . . . . 20
     3.8. HAS Protocol Dependency . . . . . . . . . . . . . . . . . . 21
       3.8.1. Object Info Packet  . . . . . . . . . . . . . . . . . . 21
         3.8.1.1. Media Sequence  . . . . . . . . . . . . . . . . . . 21
         3.8.1.2. Object URI  . . . . . . . . . . . . . . . . . . . . 22
       3.8.2. Sending Rules . . . . . . . . . . . . . . . . . . . . . 23
     3.9. RTP as the Transport Multicast Session Protocol . . . . . . 23
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
   8. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29

 

Bale et aL.             Expires October 29, 2023                [Page 2]
Internet-Draft                   MSYNC                    April 27, 2023

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 October 29, 2023                [Page 3]
Internet-Draft                   MSYNC                    April 27, 2023

   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.

   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 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];
        corresponds to a representation as defined by [MPEGDASH].

 

Bale et aL.             Expires October 29, 2023                [Page 4]
Internet-Draft                   MSYNC                    April 27, 2023

   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 information. As part of the control channel, an MSYNC
        object may transport some control information (as e.g., the
        MSYNC receiver configuration).

   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 over 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
 

Bale et aL.             Expires October 29, 2023                [Page 5]
Internet-Draft                   MSYNC                    April 27, 2023

   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 multicast transport session
   (multicast IP address + port number) whereas all audio
   representations are sent over the same transport multicast session. 

   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 MSYNC receiver joins the multicast IP group associated
   with the HAS representation requested by the HS 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.

 

Bale et aL.             Expires October 29, 2023                [Page 6]
Internet-Draft                   MSYNC                    April 27, 2023

    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 

   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  |  
    | Server  |      Internet    |  Player    |  Sender | 
    + ------- +                  + ---------------------+
         |                                         |
         |                                         |
      unicast                                  multicast
      Internet                                     |
         |                                         |
         v                                         |
    + ----------------- +                          |
    |   HAS   |  MSYNC  |<-------------------------
    | Player  |Receiver |
    + ------------------+
     End-user terminal

         Figure 2: MSYNC receiver in the terminal

 

Bale et aL.             Expires October 29, 2023                [Page 7]
Internet-Draft                   MSYNC                    April 27, 2023

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
   (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
   by [RFC3550] (Section 10). 

   The multicast network must support pre-provisioning bandwidth
 

Bale et aL.             Expires October 29, 2023                [Page 8]
Internet-Draft                   MSYNC                    April 27, 2023

   resources. This assumption permits to configure the MSYNC sender 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
   minimum 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:

      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 file)
      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_RECEIVER 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 configured 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.
 

Bale et aL.             Expires October 29, 2023                [Page 9]
Internet-Draft                   MSYNC                    April 27, 2023

   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
   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

3.1. MSYNC Packet Format

   The MSYNC packet has the following format. All bytes are sent
   according to the conventional network order: big-endian.

 

Bale et aL.             Expires October 29, 2023               [Page 10]
Internet-Draft                   MSYNC                    April 27, 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      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           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
      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. 

 

Bale et aL.             Expires October 29, 2023               [Page 11]
Internet-Draft                   MSYNC                    April 27, 2023

   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.

    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
 

Bale et aL.             Expires October 29, 2023               [Page 12]
Internet-Draft                   MSYNC                    April 27, 2023

      data-part packet (Section 3.5).   

      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).

      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
      packets MUST be null (set to 0).

   object CRC: 32 bits
      A Cyclic Redundancy Check applied to the object data 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.

   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 (not 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].
        0x03: Media HLS playlist as specified in [RFC8216].
        0x04-0xF: Reserved
 

Bale et aL.             Expires October 29, 2023               [Page 13]
Internet-Draft                   MSYNC                    April 27, 2023

   object URI size: 12 bits
      The size in bytes 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 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 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
      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. 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.
      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 prescribed by the associated object info packet. Object
   payloads are 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

 

Bale et aL.             Expires October 29, 2023               [Page 14]
Internet-Draft                   MSYNC                    April 27, 2023

   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 8 bits
      The data 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. 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 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 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 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
 

Bale et aL.             Expires October 29, 2023               [Page 15]
Internet-Draft                   MSYNC                    April 27, 2023

   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 data related to the HTTP header ( e.g., the HTTP header
      associated with 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.

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 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 to. 

   All data-part objects composing a super object have a different
   object identifier. The object info packet (object URI) links data-
   part objects 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. 

 

Bale et aL.             Expires October 29, 2023               [Page 16]
Internet-Draft                   MSYNC                    April 27, 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 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
      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 8 bits
      The data 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 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), 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
 

Bale et aL.             Expires October 29, 2023               [Page 17]
Internet-Draft                   MSYNC                    April 27, 2023

   this document. 

3.7. Sending and Receiving MSYNC Objects

   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.

3.7.1. Mapping over Transport Multicast Sessions  

   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
   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.

   The MSYNC receiver is configured to join the IP transport multicast
   session corresponding to the sub-stream the application (the HAS
   server in figure 1) must receive depending on the incoming requests
   from the end user terminal/player. In general, the MSYNC receiver is
   configured to join the IP multicast stream associated with the
   content stream the application wants to listen/receive.

   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 MSYNC control
   information 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
 

Bale et aL.             Expires October 29, 2023               [Page 18]
Internet-Draft                   MSYNC                    April 27, 2023

   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 MSYNC control channel.

      It is perfectly possible to send all the MSYNC packets in only one
      transport multicast session and therefore one IP multicast
      session.  

   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 more HTTP header packets (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 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).

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.

 

Bale et aL.             Expires October 29, 2023               [Page 19]
Internet-Draft                   MSYNC                    April 27, 2023

   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
   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 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 a new object transmission.

   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
   complemented with the support of a circuit breaker as disclosed in
   [RFC8084].

   The MSYNC receiver or more probably the application exploiting the
   MSYNC receiver may (e.g. the multicast gateway in Figure 1) may
 

Bale et aL.             Expires October 29, 2023               [Page 20]
Internet-Draft                   MSYNC                    April 27, 2023

   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 (when the MSYNC receiver repairs the packets
   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 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 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
 

Bale et aL.             Expires October 29, 2023               [Page 21]
Internet-Draft                   MSYNC                    April 27, 2023

   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$/(divided by)@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$/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 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"

        - 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. 

 

Bale et aL.             Expires October 29, 2023               [Page 22]
Internet-Draft                   MSYNC                    April 27, 2023

      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

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.

        - The manifest MUST refer to 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
 

Bale et aL.             Expires October 29, 2023               [Page 23]
Internet-Draft                   MSYNC                    April 27, 2023

      [RFC3551] according to the following.

        - The RTP header contains 0 (zero) contributing source
        identifier (CSRC) fields.

        - The RTP header timestamp field is computed as indicated in
        [RFC3550]; it corresponds to the instant the MSYNC sender starts
        the MSYNC packet transmission.

        - The RTP header payload type (PT) field 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.

        - 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].

        - 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].

 

Bale et aL.             Expires October 29, 2023               [Page 24]
Internet-Draft                   MSYNC                    April 27, 2023

                     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 October 29, 2023               [Page 25]
Internet-Draft                   MSYNC                    April 27, 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 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.

6.  References

6.1.  Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels",  RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2",
              RFC 2236, November 1997, <https://www.rfc-
              editor.org/info/rfc2236>

   [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP:
              A Transport Protocol for Real-Time Applications", RFC
              3550, July 2003, <https://www.rfc-
              editor.org/info/rfc3550>.

   [RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002, <https://www.rfc-
              editor.org/info/rfc3376>

   [RFC5506] I. Johansson, M. Westerlund. "Support for Reduced-Size
              Real-Time Transport Control Protocol(RTCP): Opportunities
              and Consequences", RFC 5506, April 2009, <https://www.rfc-
 

Bale et aL.             Expires October 29, 2023               [Page 26]
Internet-Draft                   MSYNC                    April 27, 2023

              editor.org/info/rfc5506>.

   [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010,
              <https://www.rfc-editor.org/info/rfc5761>.

   [RFC9112] R. T. Fielding, M. Nottingham, J. Reschke, " HTTP/1.1", RFC
              9112, June 2022, <https://www.rfc-
              editor.org/info/rfc9112>.

   [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 

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.

   [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", RFC 3551, July
              2003, <https://www.rfc-editor.org/info/rfc3551>.

   [RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman.
              "The Secure Real-time Transport Protocol (SRTP)", RFC
              3711, March 2004, <https://www.rfc-
              editor.org/info/rfc3711>.

   [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, <https://www.rfc-editor.org/info/rfc4541>

   [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, <https://www.rfc-editor.org/info/rfc4585>.
 

Bale et aL.             Expires October 29, 2023               [Page 27]
Internet-Draft                   MSYNC                    April 27, 2023

   [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006, <https://www.rfc-editor.org/info/rfc4588>.  

   [RFC5374] B. Weis, G. Gross, D. Ignjatic. "Multicast Extensions to
              the Security Architecture for the Internet Protocol", RFC
              5374, November 2008, <https://www.rfc-
              editor.org/info/rfc5374>.

   [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

   [RFC8216] R. Pantos, Ed., W. May, "HTTP Live Streaming", RFC 8216,
              August 2017, <https://www.rfc-editor.org/info/rfc8216>.

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

      - 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
 

Bale et aL.             Expires October 29, 2023               [Page 28]
Internet-Draft                   MSYNC                    April 27, 2023

      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 HS 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
      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

 

Bale et aL.             Expires October 29, 2023               [Page 29]
Internet-Draft                   MSYNC                    April 27, 2023

      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 October 29, 2023               [Page 30]