< draft-bichot-msync-03.txt		draft-bichot-msync-04.txt >
	Internet-Draft S. Bale		Internet-Draft S. Bale
	Intended Status: Informational R. Brebion		Intended Status: Informational R. Brebion
	Expires: October 6, 2022 G. Bichot		Expires: November 3, 2022 G. Bichot
	Broadpeak		Broadpeak
	April 4, 2022		May 2, 2022
	MSYNC		MSYNC
	draft-bichot-msync-03		draft-bichot-msync-04
	Abstract		Abstract
	This document describes the Multicast Synchronization (MSYNC)		This document describes the Multicast Synchronization (MSYNC)
	Protocol that aims at transferring video media objects over IP		Protocol that aims at transferring video media objects over IP
	multicast operating preferably RTP. Although generic, MSYNC has been		multicast operating preferably RTP. Although generic, MSYNC has been
	primarily designed for transporting HTTP adaptive streaming (HAS)		primarily designed for transporting HTTP adaptive streaming (HAS)
	objects including manifest/playlists and media segments (e.g. MP4,		objects including manifest/playlists and media segments (e.g. MP4,
	CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH		CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH
	between a multicast server and a multicast gateway.		between a multicast server and a multicast gateway.
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. MSYNC Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6		3. MSYNC Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. MSYNC packet format . . . . . . . . . . . . . . . . . . . . 6		3.1. MSYNC Packet Format . . . . . . . . . . . . . . . . . . . . 6
	3.2. Object info packet . . . . . . . . . . . . . . . . . . . . 7		3.2. Object Info Packet . . . . . . . . . . . . . . . . . . . . 7
	3.3. Object data packet . . . . . . . . . . . . . . . . . . . . 8		3.3. Object Data Packet . . . . . . . . . . . . . . . . . . . . 9
	3.4. Object HTTP header packet . . . . . . . . . . . . . . . . . 9		3.4. Object HTTP Header Packet . . . . . . . . . . . . . . . . . 9
	3.5. Object data-part packet . . . . . . . . . . . . . . . . . . 10		3.5. Object Data-part Packet . . . . . . . . . . . . . . . . . . 10
	3.6. Maximum size of a MSYNC packet . . . . . . . . . . . . . . 11		3.6. Maximum Size Of A MSYNC Packet . . . . . . . . . . . . . . 11
	3.7. Sending MSYNC objects over IP/transport multicast		3.7. Sending MSYNC Objects Over IP/Transport Multicast
	sessions . . . . . . . . . . . . . . . . . . . . . . . . . 11		Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.9. HAS protocol dependency . . . . . . . . . . . . . . . . . . 13		3.8. HAS Protocol Dependency . . . . . . . . . . . . . . . . . . 13
	3.9.1. Object info packet . . . . . . . . . . . . . . . . . . 13		3.8.1. Object Info Packet . . . . . . . . . . . . . . . . . . 13
	3.9.1.1. media sequence . . . . . . . . . . . . . . . . . . 13		3.8.1.1. Media Sequence . . . . . . . . . . . . . . . . . . 13
	3.9.1.2. object URI . . . . . . . . . . . . . . . . . . . . 13		3.8.1.2. Object URI . . . . . . . . . . . . . . . . . . . . 14
	3.9.2. Sending rules . . . . . . . . . . . . . . . . . . . . . 14		3.8.2. Sending Rules . . . . . . . . . . . . . . . . . . . . . 15
	3.10. RTP as the transport multicast session protocol . . . . . 14		3.9. RTP As The Transport Multicast Session Protocol . . . . . . 15
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 16		5.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	5.2. Informative References . . . . . . . . . . . . . . . . . . 17		5.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1 Introduction		1 Introduction
	MSYNC relies preferably on RTP that makes it particularly suited for		MSYNC relies preferably on RTP that makes it particularly suited for
	transitioning IPTV legacy(MPEG2 TS/RTP) to the HAS ecosystem. MSYNC		transitioning IPTV legacy (MPEG2 TS/RTP) to the HAS ecosystem. MSYNC
	is simple (no flow control, no forward error correction) although		is simple (no flow control, no forward error correction) although
	reliable, flexible and extensible; it has been experimented and		reliable, flexible and extensible; it has been experimented and
	deployed over IPTV infrastructure (xDSL, cable, fiber) and		deployed over IPTV infrastructure (xDSL, cable, fiber) and
	satellite.		satellite.
	1.1 Terminology		1.1 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2 Definitions		1.2 Definitions
	manifest: A file gathering the configuration for conducting a		manifest: A file gathering the configuration for conducting a
	streaming session; corresponds to a play list as defined by HLS		streaming session; corresponds to a play list as defined by HLS
	[RFC8216]. During a HAS streaming session, a manifest or		[RFC8216]. During a HAS streaming session, a manifest or
	playlist can be modified.		playlist can be modified.
	media chunk: A piece of a media segment of a fixed duration as		media chunk: A piece of a media segment of a fixed duration as
	specified in [MPEGCMAF].		specified in [MPEGCMAF].
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	Note that nothing precludes the multicast gateway to be co-located		Note that nothing precludes the multicast gateway to be co-located
	with the media player and therefore embedded in the end-user		with the media player and therefore embedded in the end-user
	terminal.		terminal.
	Note that nothing precludes application dependent features in the		Note that nothing precludes application dependent features in the
	multicast server and/or the multicast gateway that may adapt/modify		multicast server and/or the multicast gateway that may adapt/modify
	the content delivered to the end-user player.		the content delivered to the end-user player.
	3. MSYNC Protocol		3. MSYNC Protocol
	3.1. MSYNC packet format		3.1. MSYNC Packet Format
	The MSYNC packet has the following format.		The MSYNC packet has the following format.
	0 1 2 3		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		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 |		| version | packet type | object identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-header |		| sub-header |
	| .... |		| .... |
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	sub-header: series of N x 32 bits		sub-header: series of N x 32 bits
	The packet sub-header is linked to the packet type. The details of		The packet sub-header is linked to the packet type. The details of
	each packet type is given in the next sections.		each packet type is given in the next sections.
	data: series of D x 8 bits		data: series of D x 8 bits
	This field is optional and is present depending on the packet		This field is optional and is present depending on the packet
	type. D is bounded by the maximum size of a transport multicast		type. D is bounded by the maximum size of a transport multicast
	session protocol packet size and the MTU (Maximum Transfer Unit)		session protocol packet size and the MTU (Maximum Transfer Unit)
	otherwise as depicted in 3.6.		otherwise as depicted in 3.6.
	3.2. Object info packet		3.2. Object Info Packet
	The Object info packet is used to transport the meta-data		The Object info packet is used to transport the meta-data
	associated with an object. It permits to characterize the object		associated with an object. It permits to characterize the object
	in term of e.g. size and type. The object information is carried		in term of e.g. size and type. The object information is carried
	over one object info packet only. The object info packet is		over one object info packet only. The object info packet is
	typically sent along with the object data it describes.		typically sent along with the object data it describes.
	The object identifier corresponds to the object identifier of the		The object identifier corresponds to the object identifier of the
	object data packets or the object data-part packets the object		object data packets or the object data-part packets the object
	info packet relates to.		info packet relates to.
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	| media sequence |		| media sequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| object URI |		| object URI |
	: :		: :
	: :		: :
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	object size: 32 bits		object size: 32 bits
	The number of bytes that compose the transported object.		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 size may be 0 indicating that
			there is no corresponding object's payload transmission foreseen
			(i.e. no expected MSYNC data or MSYNC data-part packets) . 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: 32 bits
	Number of MSYNC packets that compose the transported object.		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		object CRC: 32 bits
	A CRC applied to the object data payload for corruption detection.		A CRC applied to the object data payload for corruption detection.
	mtype: 4 bits		mtype: 4 bits
	The manifest (playlist) type, the MSYNC INFO is compatible with.		The manifest (playlist) type, the MSYNC INFO is compatible with.
	The field can take the following values.		The field can take the following values.
	0x00: Not Applicable		0x00: Not Applicable
	0x01: MPEG Dash as specified in [MPEGDASH].		0x01: MPEG Dash as specified in [MPEGDASH].
	0x02: HLS as specified in [RFC8216].		0x02: HLS as specified in [RFC8216].
	0x03-0xF: Reserved		0x03-0xF: Reserved
	object URI size: 12bits		object URI size: 12bits
	The size in bytes of the object URI field. The value must		The size in bytes of the object URI field. The value MUST
	guarantee that the MSYNC info packet size is not greater than the		guarantee that the MSYNC info packet size is not greater than the
	network MTU.		network MTU.
	object type : 8 bits		object type : 8 bits
	Defines the type of MSYNC data object associated with this MSYNC		Defines the type of MSYNC data object associated with this MSYNC
	info packet		info packet
	0x00: Reserved		0x00: Reserved
	0x01: media manifest (playlist)		0x01: media manifest (playlist)
	0x02: Reserved		0x02: Reserved
	0x03: media data or data-part: Transport stream (MPEG2-TS)		0x03: media data or data-part: Transport stream (MPEG2-TS)
	0x04: media data or data-part: MPEG4 (CMAF)		0x04: media data or data-part: MPEG4 (CMAF)
	0x05: control: control plane information (e.g. multicast gateway		0x05: control: control plane information (e.g. multicast gateway
	configuration)		configuration)
	0x06-0xFF: Reserved		0x06-0xFF: Reserved
	media sequence: 32 bits		media sequence: 32 bits
	It is a sequence number associated with the MSYNC object data		It is a sequence number associated with the MSYNC object data
	(segment or manifest). It is dependent on the mtype value. It is		(segment or manifest). It is dependent on the mtype value. It is
	used to synchronize unicast and multicast receptions in the		used to synchronize unicast and multicast receptions in the
	multicast gateway. The values and rules are detailed in the		multicast gateway. The values and rules are detailed in the
	section 3.9 dedicated to the HAS protocol dependencies. The		section 3.8 dedicated to the HAS protocol dependencies. The
	default value is 0x00.		default value is 0x00.
	object URI: Quotient(object URI size/32) bits		object URI: Quotient(object URI size/32) bits
	This the path name associated with the object. It may corresponds		This the path name associated with the object. It MAY corresponds
	to the storage path in the multicast gateway. There MUST be a		to a storage/Cache path. There SHOULD be a direct relationship
	direct relationship between this URI and the URL associated with		between this URI and the URL associated with the addressable
	an addressable HAS object (segment or CMAF chunk) and/or a		object (e.g. HAS segment or CMAF chunk and/or a manifest). The
	manifest request received by the multicast gateway from the		rules are detailed in the section 3.8 dedicated to the HAS
	terminal/media player. The rules are detailed in the section 3.9		protocol dependencies.
	dedicated to the HAS protocol dependencies.
	3.3. Object data packet		3.3. Object Data Packet
	This MSYNC packet carries part or all of the the object's data		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		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		packets is function of the associated object's info packet. Object
	payload is transported through a series of object data packets.		payload is transported through a series of object data packets.
	0 1 2 3		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		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 | 0x3 | object identifier |		| version | 0x3 | object identifier |
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 37 ¶
	object offset: 32 bits		object offset: 32 bits
	The index from which the MSYNC object data packet payload is to be		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		written in order to compose the object data at the receiver side
	(i.e. the multicast gateway). The first data packet of an object		(i.e. the multicast gateway). The first data packet of an object
	has an offset equal to 0.		has an offset equal to 0.
	data: N x 8bits		data: N x 8bits
	The size N is not declared; it is bounded by the maximum size of		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		the under-laying transport multicast session packet (e.g. RTP) as
	depicted in the section 3.6. The total size (number of bytes) of		depicted in Section 3.6. The total size (number of bytes) of the
	the object data is indicated in the associated object info (field		object data is indicated in the associated object info (field
	object size).		object size).
	3.4. Object HTTP header packet The HTTP header packet carries part or		3.4. Object HTTP Header Packet
	all of an HTTP header related to the object (data) to be sent.
	There is at most one HTTP header per object that can be repeated.		The HTTP header packet carries part or all of an HTTP header
			related to the object (data) to be sent. There is at most one HTTP
			header per object that can be repeated.
	The object identifier is the same than the one present in the		The object identifier is the same than the one present in the
	object data packets or object data-part packets it relates to.		object data packets or object data-part packets it relates to.
	0 1 2 3		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		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 | 0x5 | object identifier |		| version | 0x5 | object identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| header size | header offset |		| header size | header offset |
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 31 ¶
	header offset: 16 bits		header offset: 16 bits
	The index from which this HTTP header MSYNC packet payload data is		The index from which this HTTP header MSYNC packet payload data is
	to be written in order to complement the HTTP header at the		to be written in order to complement the HTTP header at the
	receiver side (i.e the multicast gateway). The first packet of the		receiver side (i.e the multicast gateway). The first packet of the
	HTTP header has an offset equal to 0.		HTTP header has an offset equal to 0.
	data: N x 8bits		data: N x 8bits
	The size N is not declared; it is bounded by either the header		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		size field value or by the maximum size of the under-laying
	transport packet(e.g. RTP)as depicted in the section 3.6.		transport packet(e.g. RTP)as depicted in Section 3.6.
	3.5. Object data-part packet		3.5. Object Data-part Packet
	This MSYNC packet carries part or all of the object data-part		This MSYNC packet carries part or all of the media data-part
	payload. The type of data and the way to process the object's		object payload. The type of data and the way to process the
	data-part packets is function of the associated info packet.		object's data-part packets is function of the associated info
	Object payload is transported through a series of object data-part		packet. Object payload is transported through a series of object
	packets. The data-part is used when the object corresponds to a		data-part packets. The data-part is used when the object
	"part" (a chunk) of a super object for which the size is unknown		corresponds to a "part" (a block) of a super object for which the
	(a super object may correspond to a stream or a media segment not		size is unknown (a super object may correspond to a stream or a
	yet complete and for which the size is therefore unknown).		media segment not yet complete and for which the size is therefore
			unknown).
	All data-part packets belonging to the same data part object has		All data-part packets belonging to the same data part object have
	the same object identifier which is the same one present in the		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 info packet and HTTP header (if any) packets the data-part
	object relates too.		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
	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		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 | 0x6 | object identifier |		| version | 0x6 | object identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| object offset |		| object offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| super object offset |		| super object offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| data |		| data |
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 36 ¶
	in order to compose the object data-part at the receiver side		in order to compose the object data-part at the receiver side
	(i.e. the multicast gateway). The first packet of the data-part		(i.e. the multicast gateway). The first packet of the data-part
	has an offset equal to 0.		has an offset equal to 0.
	super object offset: 32 bits		super object offset: 32 bits
	The index from which the object part-data packet payload is to be		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		written in order to compose the super object data at the receiver
	side (i.e. the multicast gateway). The first data-part object		side (i.e. the multicast gateway). The first data-part object
	composing a super object has the super object offset equal to 0.		composing a super object has the super object offset equal to 0.
	The super object offset is the same for all object data-part		The super object offset is the same for all object data-part
	packets composing the same object data-part. Having this field		packets composing the same object data-part.
	present in the object data-part header (and not in the associated
	object info header) permits to possibly recompose a super object
	without the corresponding object info packet.
	data: N x 8bits		data: N x 8bits
	The size N is not declared; it is bounded by the maximum size of		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		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		section 3.6. The total size (number of bytes) of the object data
	is indicated in the associated object info (field object size).		is indicated in the associated object info (field object size).
	3.6. Maximum size of a MSYNC packet		3.6. Maximum Size Of A MSYNC Packet
	An MSYNC packet is composed with a header part and a data part for		An MSYNC packet is composed with a header part and a data part for
	which the size is bounded by the transport multicast session		which the size is bounded by the transport multicast session
	packet. In case there is no particular restriction as with RTP		packet. In case there is no particular restriction as with RTP
	and/or UDP (which authorize up to 65235 bytes), then the maximum		and/or UDP (which authorize up to 65235 bytes), then the maximum
	size is linked to the path MTU (Maximum Transfer Unit) as the		size is linked to the path MTU (Maximum Transfer Unit) as the
	largest transfer unit supported between the source (the multicast		largest transfer unit supported between the source (the multicast
	server) and the destination (the multicast gateway) without		server) and the destination (the multicast gateway) without
	fragmentation. An MSYNC packet must fit within a link layer		fragmentation. An MSYNC packet MUST fit within a link layer
	packet.		packet.
	For Ethernet, as an example, the MTU is typically 1500 bytes,		For Ethernet, as an example, the MTU is typically 1500 bytes,
	assuming a 20 bytes IPv4 header, a 8 bytes UDP header and the 8		assuming a 20 bytes IPv4 header, a 8 bytes UDP header and the 8
	bytes MSYNC object data packet header, it gives an MTU of 1464		bytes MSYNC object data packet header, it gives an MTU of 1464
	bytes for the MSYNC object data packet. Operating RTP, the MSYNC		bytes for the MSYNC object data packet. Operating RTP, the MSYNC
	object data MTU is decreased by 12 bytes (= 1452 bytes).		object data MTU is decreased by 12 bytes (= 1452 bytes).
	3.7. Sending MSYNC objects over IP/transport multicast sessions		3.7. Sending MSYNC Objects Over IP/Transport Multicast Sessions
	The following considerations are linked to the multicast server		The following considerations are linked to the multicast server
	configuration.		configuration.
	Per MSYNC channel, the way to map MSYNC objects related to a media		Per MSYNC channel, the way to map MSYNC objects related to a media
	stream with an IP or transport multicast session is not		stream with an IP or transport multicast session is not
	constrained. The arrangement is chosen function of the network		constrained. The arrangement is chosen function of the network
	architecture and capacity. For example, in xDSL, the capacity		architecture and capacity. For example, in xDSL, the capacity
	dedicated to multicast is limited which may drive to an		dedicated to multicast is limited which may drive to an
	arrangement where each sub-stream/representation of a HAS		arrangement where each sub-stream/representation of a HAS
	session/MSYNC channel matches with one dedicated IP multicast		session/MSYNC channel matches with one dedicated IP multicast
	session. The MSYNC receiver switches to the IP transport session		session. The MSYNC receiver switches to the IP transport session
	corresponding to the sub-stream/representation it must serve to		corresponding to the sub-stream/representation it should serve to
	the user terminal/player. Alternatively, one would like to have		the user terminal/player. Alternatively, one would like to have
	one IP multicast session (with possibly multiple transport		one IP multicast session (with possibly multiple transport
	multicast sessions, each having a different destination port		multicast sessions, each having a different destination port
	number) for the entire HAS session/MSYNC channel that is an		number) for the entire HAS session/MSYNC channel that is an
	arrangement a la "IPTV", less bandwidth efficient but where only		arrangement a la "IPTV", less bandwidth efficient but where only
	one multicast IP address is allocated per HAS session/MSYNC		one multicast IP address is allocated per HAS session/MSYNC
	channel.		channel.
	Considering a satellite network, as all transport multicast		Considering a satellite network, as all transport multicast
	sessions are carried simultaneously, all arrangements may make		sessions are carried simultaneously, all arrangements may make
	skipping to change at page 12, line 40 ¶		skipping to change at page 13, line 11 ¶
	- One IP multicast session per media (audio or video or		- One IP multicast session per media (audio or video or
	subtitle) sub-stream (representation); each transport multicast		subtitle) sub-stream (representation); each transport multicast
	session having a different destination multicast IP address.		session having a different destination multicast IP address.
	- One transport multicast session for the MSYNC control channel.		- One transport multicast session for the MSYNC control channel.
	- It is perfectly possible to send all the MSYNC packets in only		- It is perfectly possible to send all the MSYNC packets in only
	one transport multicast session.		one transport multicast session.
	For each MSYNC object to be sent, the sender MUST send one object		For each MSYNC object (see object type in 3.2) to be sent, the
	info packet, 0 or more object info redundant packets, zero or more		sender MUST send the following MSYNC packets in the specified
	HTTP header packets and one or more object data packets or object		order: one object info packet, zero or more object info redundant
	data-part packets.		packets, zero or more HTTP header packets and one or more object
			data packets or object data-part packets.
	The sender MUST send the object's HTTP header along with the
	corresponding object's data to be sent through using the MSYNC
	object data packet(s). The sender MUST send the object's HTTP
	header along with the corresponding first object's data-part to be
	sent through using the MSYNC object data-part packet(s)
	Whenever a manifest (playlist) has to be sent, the manifest		When the MSYNC object is a media data-part object of size null
	(playlist) object MUST be sent along with (duplicated in) all the		(used to signal the end of the transmission of a super object)
	transport multicast sessions related to the transmission of the		then only one object info packet MUST be sent.
	video segment objects the manifest/playlist refers to.
	3.9. HAS protocol dependency		3.8. HAS Protocol Dependency
	A certain number of MSYNC packet header fields have a dependency		A certain number of MSYNC packet header fields have a dependency
	on the HAS protocol and therefore on the manifest type. Similarly		on the HAS protocol and therefore on the manifest type. Similarly
	the sending rules may also depend from the HAS protocol.		the sending rules may also depend from the HAS protocol.
	3.9.1. Object info packet		3.8.1. Object Info Packet
	3.9.1.1. media sequence		3.8.1.1. Media Sequence
	The media sequence is used by the multicast gateway to synchronize		The media sequence is used by the multicast gateway to synchronize
	the MSYNC (i.e. multicast) reception with unicast reception. The		the MSYNC (i.e. multicast) reception with unicast reception. The
	multicast gateway may operate jointly MSYNC and unicast retrieval		multicast gateway may operate jointly MSYNC and unicast retrieval
	of HAS objects. This is useful in some occasions like processing a		of HAS objects. This is useful in some occasions like processing a
	new streaming session request (i.e. a manifest request after a		new streaming session request (i.e. a manifest request after a
	channel switch) or in the case of segment repair. The multicast		channel switch) or in the case of segment repair. The multicast
	gateway may attempt to retrieve a manifest object or segment(s)		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		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		order to speed up the start of the session or to repair damaged
	skipping to change at page 13, line 50 ¶		skipping to change at page 14, line 15 ¶
	HLS segment: MUST contain the value of EXT-X-MEDIA-SEQUENCE added		HLS segment: MUST contain the value of EXT-X-MEDIA-SEQUENCE added
	with the position of the segment in the playlist.		with the position of the segment in the playlist.
	DASH manifest: MUST contain $time$/scale or $Number$ corresponding to		DASH manifest: MUST contain $time$/scale or $Number$ corresponding to
	the last segment transmitted or under transmission (and possibly		the last segment transmitted or under transmission (and possibly
	received partially) and declared by the manifest.		received partially) and declared by the manifest.
	DASH segment: MUST contain the $time$/scale or $Number$ value		DASH segment: MUST contain the $time$/scale or $Number$ value
	3.9.1.2. object URI		3.8.1.2. Object URI
	In the context of HTTP adaptive streaming, if the object is a HAS
	addressable entity (e.g. a segment or a CMAF chunk), the path name
	MUST match the absolute path present in the incoming segment
	request.
	The segment S_2: tvChannel1/Q1/S_2.		In the context of HTTP adaptive streaming, The object URI is a URI
	The CMAF chunk C_3 of the segment S_2: tvChannel11/Q1/S_2/C_3.		reference.
	if the object is a non-addressable HAS entity (e.g. a HTTP 1.1 CTE		if the object is a HAS addressable entity (e.g. a segment or a
	block), the URI MUST hierarchically match with the related		CMAF chunk), the object URI MUST match (be a sub-string) with the
	incoming segment request.		URL announced in the corresponding manifest/playlist.
	The HTTP CTE 3rd chunk of the segment S_2:
	tvChannel11/Q1/S_2/3;
	3.9.2. Sending rules		Examples:
	When a manifest/play-list is sent, it must reference addressable		- The object URI: /tvChannel1/Q1/S_2 matches with the segment's
	objects (segment or CMAF chunk) that have already been sent or for		URL that is computed from the associated manifest/playlist:
	which the transmission has started.		".../tvChannel1/Q1/S_2.mp4"
	3.10. RTP as the transport multicast session protocol		- 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".
	RTP [RFC3550] can be used as part of the transport multicast		If the object is a non-addressable HAS entity (e.g. a HTTP 1.1 CTE
	session protocol. Depending on the deployment case (e.g.		block), the object URI is composed with a sub-string (that MUST
	unidirectional) and the infrastructure in place, the companion		match with the URL announced in the corresponding manifest) and a
	RTCP protocol MUST be operated according to the following.		suffix composed with the underscore character and the block
			number).
			Example:
			- The object URI of the 3rd HTTP CTE block of the segment S_2:
			tvChannel11/Q1/S_2.m4s_2 matches with the segment's request URL
			that terminates with ".../tvChannel1/Q1/S_2.m4s"
			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. 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 3.2.
			Example:
			- The object URI of the object info packet associated with the
			1st HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_0
			- The object URI of the object info packet associated with the
			2nd HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_1
			- The object URI of the object info packet associated with the
			3rd HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_2
			- The object URI of the object info packet associated with the
			4st HTTP CTE block of the segment S_2: tvChannel11/Q1/S_2.m4s_3
			- The object URI of the object info packet associated with the
			5st HTTP 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 (playlist) has to be sent:
			- The manifest (playlist) object MUST be sent within (duplicated
			in) all the transport multicast sessions related to the
			transmission of the video segment objects the manifest/playlist
			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] can be used as part of the transport multicast
			session protocol. Depending on the deployment case (e.g.
			unidirectional) and the infrastructure in place, the companion
			RTCP protocol MUST be operated according to the following.
	- RTCP usage SHALL conform to [RFC5506]		- RTCP usage SHALL conform to [RFC5506]
	- RTCP sender report MAY be switched off		- RTCP sender report MAY be switched off
	- RTCP receiver report MAY be switched off		- RTCP receiver report MAY be switched off
	- RCTP destination port number must be configurable but it must		- RCTP destination port number is configurable but it MUST be
	be different than the associated RTP destination port number,		different than the associated RTP destination port number, i.e.
	i.e. the RTCP destination port number is not necessarily the RTP		the RTCP destination port number is not necessarily the RTP
	destination port number + 1 as recommended in [RFC3550].		destination port number + 1 as recommended in [RFC3550].
	- RTCP MAY be used for packet loss recovery (aka "RTP Repair").		- RTCP MAY be used for packet loss recovery (aka "RTP Repair").
	If packet loss recovery through RTCP is activated then the RTP		If packet loss recovery through RTCP is activated then the RTP
	Repair client and server MUST be compliant with [RFC4585] and		Repair client and server MUST be compliant with [RFC4585] and
	[RFC5506]. The RTP Repair client that submit the feedback (FB)		[RFC5506]. The RTP Repair client that submit the feedback (FB)
	messages (according to [RFC5506] and [RFC4585] is the MSYNC		messages (according to [RFC5506] and [RFC4585] is the MSYNC
	receiver (i.e. the multicast gateway). The RTP Repair server		receiver (i.e. the multicast gateway). The RTP Repair server
	that receives, processes and responds to the feedback messages		that receives, processes and responds to the feedback messages
	(FB) MAY be the MSYNC sender (i.e. the multicast server) or it		(FB) MAY be the MSYNC sender (i.e. the multicast server) or it
	skipping to change at page 15, line 4 ¶		skipping to change at page 16, line 21 ¶
	- RTCP MAY be used for packet loss recovery (aka "RTP Repair").		- RTCP MAY be used for packet loss recovery (aka "RTP Repair").
	If packet loss recovery through RTCP is activated then the RTP		If packet loss recovery through RTCP is activated then the RTP
	Repair client and server MUST be compliant with [RFC4585] and		Repair client and server MUST be compliant with [RFC4585] and
	[RFC5506]. The RTP Repair client that submit the feedback (FB)		[RFC5506]. The RTP Repair client that submit the feedback (FB)
	messages (according to [RFC5506] and [RFC4585] is the MSYNC		messages (according to [RFC5506] and [RFC4585] is the MSYNC
	receiver (i.e. the multicast gateway). The RTP Repair server		receiver (i.e. the multicast gateway). The RTP Repair server
	that receives, processes and responds to the feedback messages		that receives, processes and responds to the feedback messages
	(FB) MAY be the MSYNC sender (i.e. the multicast server) or it		(FB) MAY be the MSYNC sender (i.e. the multicast server) or it
	MAY be any intermediate entity acting as a multicast RTP		MAY be any intermediate entity acting as a multicast RTP
	receiver (i.e. capable of receiving the multicast RTP packets).		receiver (i.e. capable of receiving the multicast RTP packets).
	In any case, the RTP Repair server and the RTP Repair client		In any case, the RTP Repair server and the RTP Repair client
	MUST operate a unicast interface.		MUST operate a unicast interface.
	Note that instead of relying on "RTP repair", an MSYNC receiver		Note that instead of relying on "RTP repair", an MSYNC receiver
	(i.e. the multicast gateway) could attempt to recover HAS		(i.e. the multicast gateway) could attempt to recover HAS
	elements (segments, manifest) through HTTP (aka "HTTP repair").		elements (segments, manifest) through HTTP (aka "HTTP repair").
	However the latter method requires a CDN and is less reactive		However the latter method requires a CDN and is less reactive
	than operating RTCP.		than operating RTCP.
	In addition, each RTP multicast session must operate a different		In addition, each RTP multicast session MUST operate a different
	[RFC3550] SSRC number. This guaranties a reparation on the RTP		[RFC3550] SSRC number. This guaranties a reparation on the RTP
	transport multicast session basis.		transport multicast session basis.
	-RTCP MAY be used for Fast Channel change according to		-RTCP MAY be used for Fast Channel change according to
	[RFC6585]. The way to operate [RFC6585] is out of scope of this		[RFC6585]. The way to operate [RFC6585] is out of scope of this
	document.		document.
	4. IANA Considerations		4. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	5. Security Considerations		5. Security Considerations
	The multicast communication between the MSYNC sender (multicast		The multicast communication between the MSYNC sender (multicast
	server) and the MSYNC receiver (the multicast gateway) should be		server) and the MSYNC receiver (the multicast gateway) SHOULD be
	protected for confidentiality, message corruption and replay		protected for confidentiality, message corruption and replay
	attacks. The MSYNC protocol does not gather any security		attacks. The MSYNC protocol does not specify any security
	mechanism. MSYNC relies on possibly content protection (Digital		mechanism. MSYNC relies on possibly content protection (Digital
	Right Management) and on the underlying transport layer and		Right Management) and on the underlying transport layer and
	security extensions for providing message		security extensions for providing message
	integrity/authentication and replay. Secure RTP (SRTP) [RFC3711]		integrity/authentication and replay. Secure RTP (SRTP) [RFC3711]
	and IPSec applied to multicast [RFC5374] are potential		and IPSec applied to multicast [RFC5374] are potential
	candidates for providing such extensions.		candidates for providing such extensions.
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	skipping to change at page 17, line 32 ¶		skipping to change at page 18, line 32 ¶
	[RFC6585] Unicast-Based Rapid Acquisition of Multicast RTP Sessions.		[RFC6585] Unicast-Based Rapid Acquisition of Multicast RTP Sessions.
	B. VerSteeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011.		B. VerSteeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011.
	(Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:		(Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:
	10.17487/RFC6285)		10.17487/RFC6285)
	[RFC8216] HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017.		[RFC8216] HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017.
	(Format:TXT, HTML) (Status: INFORMATIONAL) (DOI:		(Format:TXT, HTML) (Status: INFORMATIONAL) (DOI:
	10.17487/RFC8216)		10.17487/RFC8216)
	Acknowledgments		6. Acknowledgments
	The authors will be ever grateful to their late colleague Arnaud		The authors will be ever grateful to their late colleague Arnaud
	Leclerc who has been the initiator of that work.		Leclerc who has been the initiator of that work.
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	feedback: Yann Barateau (Eutelsat).		feedback: Yann Barateau (Eutelsat).
			7. Change Log
			- 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		Authors' Addresses
	Sophie Bale		Sophie Bale
	Broadpeak		Broadpeak
	15 rue Claude Chappe		15 rue Claude Chappe
	Zone des Champs Blancs		Zone des Champs Blancs
	35510 Cesson-Sevigne		35510 Cesson-Sevigne
	France		France
	Email: sophie.bale@broadpeak.tv		Email: sophie.bale@broadpeak.tv
End of changes. 46 change blocks.
	112 lines changed or deleted		183 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/