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/