draft-ietf-avtext-rams-scenarios-02.txt		draft-ietf-avtext-rams-scenarios-03.txt
	AVTEXT A. Begen		AVTEXT A. Begen
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Informational January 17, 2012		Intended status: Informational March 9, 2012
	Expires: July 20, 2012		Expires: September 10, 2012
	Considerations for Deploying the Rapid Acquisition of Multicast RTP		Considerations for Deploying the Rapid Acquisition of Multicast RTP
	Sessions (RAMS) Method		Sessions (RAMS) Method
	draft-ietf-avtext-rams-scenarios-02		draft-ietf-avtext-rams-scenarios-03
	Abstract		Abstract
	The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a		The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
	method based on RTP and RTP Control Protocol (RTCP) that enables an		method based on RTP and RTP Control Protocol (RTCP) that enables an
	RTP receiver to rapidly acquire and start consuming the RTP multicast		RTP receiver to rapidly acquire and start consuming the RTP multicast
	data. Upon a request from the RTP receiver, an auxiliary unicast RTP		data. Upon a request from the RTP receiver, an auxiliary unicast RTP
	retransmission session is set up between a retransmission server and		retransmission session is set up between a retransmission server and
	the RTP receiver, over which the reference information about the new		the RTP receiver, over which the reference information about the new
	multicast stream the RTP receiver is about to join is transmitted at		multicast stream the RTP receiver is about to join is transmitted at
	an accelerated rate. This often precedes, but may also accompany,		an accelerated rate. This often precedes, but may also accompany,
	the multicast stream itself. When there is only one multicast stream		the multicast stream itself. When there is only one multicast stream
	to be acquired, the RAMS solution works in a straightforward manner.		to be acquired, the RAMS solution works in a straightforward manner.
	However, when there are two or more multicast streams to be acquired		However, when there are two or more multicast streams to be acquired
	from the same or different multicast RTP sessions, care should be		from the same or different multicast RTP sessions, care should be
	taken to configure each RAMS session appropriately. This document		taken to configure each RAMS session appropriately. This document
	provides example scenarios and offers guidelines.		provides example scenarios and discusses how the RAMS solution could
			be used in such scenarios.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 20, 2012.		This Internet-Draft will expire on September 10, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 18		skipping to change at page 3, line 18
	method based on RTP and RTP Control Protocol (RTCP) that enables an		method based on RTP and RTP Control Protocol (RTCP) that enables an
	RTP receiver to rapidly acquire and start consuming the RTP multicast		RTP receiver to rapidly acquire and start consuming the RTP multicast
	data. Through an auxiliary unicast RTP retransmission session		data. Through an auxiliary unicast RTP retransmission session
	[RFC4588], the RTP receiver receives a reference information about		[RFC4588], the RTP receiver receives a reference information about
	the new multicast stream it is about to join. This often precedes,		the new multicast stream it is about to join. This often precedes,
	but may also accompany, the multicast stream itself. The RAMS		but may also accompany, the multicast stream itself. The RAMS
	solution is documented in detail in [RFC6285].		solution is documented in detail in [RFC6285].
	The RAMS specification [RFC6285] has provisions for concurrently		The RAMS specification [RFC6285] has provisions for concurrently
	acquiring multiple streams inside a multicast RTP session. However,		acquiring multiple streams inside a multicast RTP session. However,
	the specification does not discuss scenarios where an RTP receiver		the RAMS specification does not discuss scenarios where an RTP
	makes use of the RAMS method to rapidly acquire multiple and		receiver makes use of the RAMS method to rapidly acquire multiple and
	associated multicast streams in parallel, or where different RTP		associated multicast streams in parallel, or where different RTP
	sessions are part of the same source-specific multicast (SSM)		sessions are part of the same source-specific multicast (SSM)
	session. The example presented in Section 8.3 of [RFC6285] addresses		session. The example presented in Section 8.3 of [RFC6285] addresses
	only the simple case of an RTP receiver rapidly acquiring only one		only the simple case of an RTP receiver rapidly acquiring only one
	multicast stream to explain the protocol details.		multicast stream to explain the protocol details.
	There are certain deployment models where a multicast RTP session may		There are certain deployment models where a multicast RTP session
	have two or more multicast streams associated with it. There are		might have two or more multicast streams associated with it. There
	also cases, where an RTP receiver may be interested in acquiring one		are also cases, where an RTP receiver might be interested in
	or more multicast streams from several multicast RTP sessions. In		acquiring one or more multicast streams from several multicast RTP
	scenarios where multiple RAMS sessions, each initiated with an		sessions. In scenarios where multiple RAMS sessions, each initiated
	individual RAMS Request message to a different feedback target, will		with an individual RAMS Request message to a different feedback
	be simultaneously run by an RTP receiver, they need to be		target, will be simultaneously run by an RTP receiver, they need to
	coordinated. In this document, we present scenarios from real-life		be coordinated. In this document, we present scenarios from real-
	deployments and provide guidelines.		life deployments and discuss how the RAMS solution could be used in
			such scenarios.
	2. Background		2. Background
	In the following discussion, we assume that there are two RTP streams		In the following discussion, we assume that there are two RTP streams
	(1 and 2) that are somehow associated with each other. These could		(1 and 2) that are somehow associated with each other. These could
	be audio and video elementary streams for the same TV channel, or		be audio and video elementary streams for the same TV channel, or
	they could be an MPEG2-TS stream (that has audio and video		they could be an MPEG2-TS stream (that has audio and video
	multiplexed together) and its Forward Error Correction (FEC) stream.		multiplexed together) and its Forward Error Correction (FEC) stream.
	It is important to note that an SSM session is defined by its		An SSM session is defined by its (distribution) source address and
	(distribution) source address and (destination) multicast group and		(destination) multicast group and there can be only one feedback
	there can be only one feedback target per SSM session [RFC5760]. So,		target per SSM session [RFC5760]. So, if the RTP streams are
	if the RTP streams are distributed by different sources or over		distributed by different sources or over different multicast groups,
	different multicast groups, they are considered different SSM		they are considered different SSM sessions. While different SSM
	sessions. While different SSM sessions can normally share the same		sessions can normally share the same feedback target address and/or
	feedback target address and/or port, RAMS requires each unique		port, RAMS requires each unique feedback target (i.e., the
	feedback target (i.e., the combination of address and port) to be		combination of address and port) to be associated with at most one
	associated with at most one RTP session (See Section 6.2 of		RTP session (See Section 6.2 of [RFC6285]).
	[RFC6285]).
	Two or more multicast RTP streams can be transmitted in the same RTP		Two or more multicast RTP streams can be transmitted in the same RTP
	session (e.g., in a single UDP flow). This is called Synchronization		session (e.g., in a single UDP flow). This is called Synchronization
	Source (SSRC) multiplexing. In this case, (de)multiplexing is done		Source (SSRC) multiplexing. In this case, (de)multiplexing is done
	at the SSRC level. Alternatively, the multicast RTP streams can be		at the SSRC level. Alternatively, the multicast RTP streams can be
	transmitted in different RTP sessions (e.g., in different UDP flows),		transmitted in different RTP sessions (e.g., in different UDP flows),
	which is called session multiplexing. In practice, there are		which is called session multiplexing. In practice, there are
	different deployment models for each multiplexing scheme.		different deployment models for each multiplexing scheme.
	Generally, two different media streams with different clock rates are		Generally, two different media streams with different clock rates are
	skipping to change at page 10, line 47		skipping to change at page 11, line 5
	WGs, and my friends at Cisco for their comments and feedback.		WGs, and my friends at Cisco for their comments and feedback.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,		[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
	"Unicast-Based Rapid Acquisition of Multicast RTP		"Unicast-Based Rapid Acquisition of Multicast RTP
	Sessions", RFC 6285, June 2011.		Sessions", RFC 6285, June 2011.
			9.2. Informative References
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
	July 2006.		July 2006.
	[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.		[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
	Hakenberg, "RTP Retransmission Payload Format", RFC 4588,		Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
	July 2006.		July 2006.
	[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control		[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
	Protocol (RTCP) Extensions for Single-Source Multicast		Protocol (RTCP) Extensions for Single-Source Multicast
	Sessions with Unicast Feedback", RFC 5760, February 2010.		Sessions with Unicast Feedback", RFC 5760, February 2010.
	9.2. Informative References
	[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description		[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
	Protocol (SDP) Grouping Framework", RFC 5888, June 2010.		Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
	[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in		[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
	the Session Description Protocol", RFC 5956,		the Session Description Protocol", RFC 5956,
	September 2010.		September 2010.
	[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error		[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
	Correction (FEC) Framework", RFC 6363, October 2011.		Correction (FEC) Framework", RFC 6363, October 2011.
End of changes. 9 change blocks.
	28 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/