--- 1/draft-ietf-avtext-rams-scenarios-02.txt 2012-03-09 17:13:58.310670945 +0100 +++ 2/draft-ietf-avtext-rams-scenarios-03.txt 2012-03-09 17:13:58.334671074 +0100 @@ -1,53 +1,54 @@ AVTEXT A. Begen Internet-Draft Cisco -Intended status: Informational January 17, 2012 -Expires: July 20, 2012 +Intended status: Informational March 9, 2012 +Expires: September 10, 2012 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method - draft-ietf-avtext-rams-scenarios-02 + draft-ietf-avtext-rams-scenarios-03 Abstract The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on July 20, 2012. + This Internet-Draft will expire on September 10, 2012. Copyright Notice Copyright (c) 2012 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 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 @@ -85,56 +86,56 @@ method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Through an auxiliary unicast RTP retransmission session [RFC4588], the RTP receiver receives a reference information about the new multicast stream it is about to join. This often precedes, but may also accompany, the multicast stream itself. The RAMS solution is documented in detail in [RFC6285]. The RAMS specification [RFC6285] has provisions for concurrently acquiring multiple streams inside a multicast RTP session. However, - the specification does not discuss scenarios where an RTP receiver - makes use of the RAMS method to rapidly acquire multiple and + the RAMS specification does not discuss scenarios where an RTP + receiver makes use of the RAMS method to rapidly acquire multiple and associated multicast streams in parallel, or where different RTP sessions are part of the same source-specific multicast (SSM) session. The example presented in Section 8.3 of [RFC6285] addresses only the simple case of an RTP receiver rapidly acquiring only one multicast stream to explain the protocol details. - There are certain deployment models where a multicast RTP session may - have two or more multicast streams associated with it. There are - also cases, where an RTP receiver may be interested in acquiring one - or more multicast streams from several multicast RTP sessions. In - scenarios where multiple RAMS sessions, each initiated with an - individual RAMS Request message to a different feedback target, will - be simultaneously run by an RTP receiver, they need to be - coordinated. In this document, we present scenarios from real-life - deployments and provide guidelines. + There are certain deployment models where a multicast RTP session + might have two or more multicast streams associated with it. There + are also cases, where an RTP receiver might be interested in + acquiring one or more multicast streams from several multicast RTP + sessions. In scenarios where multiple RAMS sessions, each initiated + with an individual RAMS Request message to a different feedback + target, will be simultaneously run by an RTP receiver, they need to + be coordinated. In this document, we present scenarios from real- + life deployments and discuss how the RAMS solution could be used in + such scenarios. 2. Background In the following discussion, we assume that there are two RTP streams (1 and 2) that are somehow associated with each other. These could be audio and video elementary streams for the same TV channel, or they could be an MPEG2-TS stream (that has audio and video multiplexed together) and its Forward Error Correction (FEC) stream. - It is important to note that an SSM session is defined by its - (distribution) source address and (destination) multicast group and - there can be only one feedback target per SSM session [RFC5760]. So, - if the RTP streams are distributed by different sources or over - different multicast groups, they are considered different SSM - sessions. While different SSM sessions can normally share the same - feedback target address and/or port, RAMS requires each unique - feedback target (i.e., the combination of address and port) to be - associated with at most one RTP session (See Section 6.2 of - [RFC6285]). + An SSM session is defined by its (distribution) source address and + (destination) multicast group and there can be only one feedback + target per SSM session [RFC5760]. So, if the RTP streams are + distributed by different sources or over different multicast groups, + they are considered different SSM sessions. While different SSM + sessions can normally share the same feedback target address and/or + port, RAMS requires each unique feedback target (i.e., the + combination of address and port) to be associated with at most one + RTP session (See Section 6.2 of [RFC6285]). 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 Source (SSRC) multiplexing. In this case, (de)multiplexing is done at the SSRC level. Alternatively, the multicast RTP streams can be transmitted in different RTP sessions (e.g., in different UDP flows), which is called session multiplexing. In practice, there are different deployment models for each multiplexing scheme. Generally, two different media streams with different clock rates are @@ -416,42 +417,42 @@ WGs, and my friends at Cisco for their comments and feedback. 9. References 9.1. Normative References [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011. +9.2. Informative References + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. -9.2. Informative References - [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010. [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.